Archivo por meses: noviembre 2013

Estadísticas de uso del clúster

El sistema de colas PBS/Torque instalado en el clúster de computación ctcomp2 permite realizar una traza de cada trabajo enviado a las colas del sistema. Esta traza registra el Unix Time de todos los eventos relacionados con el sistema de colas (como, por ejemplo, el registro en las colas, el envío a los nodos de ejecución y la finalización del trabajo), así como otros parámetros no temporales (como el tipo de cola, el contenido del script o los recursos solicitados/consumidos). En este artículo os mostraremos un resumen de algunas de las estadísticas de uso del clúster en los últimos meses, a partir del momento en el que se instalaron los últimos nodos de computación adquiridos. En concreto, consideraremos el período 1/9/2013 a 15/11/2013.

Como sabéis, ctcomp2 dispone de un sistema de gestión de energía, CLUES, que permite apagar/encender los nodos computacionales en función de la demanda de recursos de los trabajos registrados en las colas PBS. En el período considerado, los nodos han estado, en media, un 38,55% del tiempo apagados y un 25,32% ociosos. Podéis ver los resultados por nodo en la siguiente imagen (tened en cuenta que los nodos node1, inode11 e inode20 están fuera del sistema CLUES, por lo que deberían estar siempre encendidos aunque no haya trabajos):

ctcomp2_usage

En este período se han contabilizado 36929 trabajos, con un tiempo de ejecución medio de 1 hora 20 minutos (siendo la mediana 3 minutos y el tiempo máximo de ejecución 280 horas). En esta métrica hay que tener en cuenta que se están contabilizando los trabajos que han fallado (es decir, que no han realizado las tareas que el usuario esperaba por algún tipo de error en la ejecución del script), pero que desde el punto de vista del sistema de colas se han ejecutado correctamente. El tiempo medio de espera en cola de los trabajos ha sido 4 minutos 27 segundos (siendo la mediana 44 segundos y el tiempo máximo de espera 43 horas 25 minutos). Curiosamente, el usuario que más ha esperado es el mismo que el que ostenta la ejecución más costosa temporalmente…

En cuanto a los usuarios, actualmente hay 35 usuarios activos en el clúster. Extraoficialmente, ya que no existen estadísticas oficiales, hay 6-8 usuarios muy activos. Técnicamente, sería posible realizar una estadística del consumo de recursos por usuario pero, por un lado, no me gusta “señalar” y, por otro lado, teniendo en cuenta las estadísticas de uso mostradas, no existe necesidad. En cualquier caso, desde un punto de vista global, la intensidad de uso del clúster en una semana sigue el patrón que se muestra en la siguiente figura (rojo: trabajos en cola, azul: trabajos en ejecución, negro: trabajos totales):

zabbix_colas

Simplemente destacar que, tal y como refleja la figura, los mayores picos de intensidad suelen ser los lunes a las 18:00 y los viernes a las 12:00.

Por último, en cuanto al tipo de trabajos, el que más recursos consume es, con diferencia, MATLAB: pbs_modulesEsta gráfica está generada a partir de los comandos ‘module’ que se utilizan en los scripts. El tipo de trabajos ‘none’ incluye a los trabajos que no utilizan módulos (C, Fortran, Python, Octave…).

Sistemas de archivos de disco compartido

Introducción

A la hora de diseñar e implementar un servicio como el Cloud o el cluster de computación del Citius hay que incluir una solución para el almacenamiento que tenga las características requeridas. En este caso el requisito más relevante es que el servicio lo componen un número variable de servidores físicos que deben poder acceder a la vez al mismo almacenamiento. Esto permite, por ejemplo, que en el caso del Cloud si un servidor físico se cae otro pueda levantar las máquinas virtuales que estaban en funcionamiento en él ya que puede acceder a sus ficheros de manera inmediata. En el caso del cluster de computación, todos los nodos de computación tienen acceso a los mismos datos, incluso aunque cada nodo los vaya actualizando con el resultado de sus cálculos.

Hay varias aproximaciones posibles a este problema; es posible por ejemplo usar DRBD , o también podría resolverse mediante un servidor NFS que ofreciera el almacenamiento a través de la red local. Otra posibilidad sería implementar una SAN que permita a los servidores conectarse al almacenamiento a través de una red dedicada.

La solución de DRBD escala mal a medida que aumenta el número de servidores y añade mucha sobrecarga en la red y NFS no obtiene el mismo rendimiento que un disco conectado localmente, por lo que optamos por la SAN.

Una vez decidido que el almacenamiento consistirá en una cabina de discos accesible a través de una red SAN queda la elección del sistema de ficheros. El problema consiste en que necesitamos un sistema de ficheros que permita montarlo simultáneamente desde varios servidores para realizar lecturas y escrituras concurrentes, es decir, necesitamos un sistema de ficheros de disco compartido.

De entre todos los sistemas de ficheros de este tipo vamos a centrarnos en dos que son libres:

  • GFS2 (Global File System 2) desarrollado por RedHat
  • OCFS2 (Oracle Cluster File System 2) desarrollado por Oracle.

Antes de elegir uno de los dos  hemos realizado unas pruebas de rendimiento “informales” para ver si alguno de los dos destaca en ese aspecto.

Las pruebas

Descripción del sistema

Damos como referencia las características del sistema en el que se ha hecho el benchmark:

La cabina es una HP P2000 G3 accedida por iSCSI 1Gb desde 2 Broadcom NetXtreme II BCM57810 10Gb con driver bnx2X v1.70.30-0. La Lun ofrecida desde la cabina está formada por 6 discos de 2TB de 7.2k rpm en RAID 6.

En el caso de OCFS2 el sistema operativo es Ubuntu 12.04 con un kernel 3.20-45-generic con open-iscsi 2.0.871-0ubuntu9.12.04.2 y multipath-tools 0.4.9-3ubuntu5.

En el caso de GFS2 el sistema operativo es CentOS 6.4  con un kernel  2.6.32-358.14.1.el6.x86_64 con iscsi-initiator-utils 6.2.0.873-2.el6.x86_64 y device-mapper-multipath-0.4.9-64.el6_4.1.x86_64. Se ha usado CentOS porque los paquetes de GFS2 de Debian/Ubuntu estan marcados como “experimental, no usar en producción”.

Hay que aclarar que el objetivo de las pruebas no es obtener una medida real sobre las capacidades de entrada/salida del conjunto del sistema sino simplemente poder comparar las diferencias de rendimiento entre los sistemas de ficheros de modo que tengamos un nuevo elemento de juicio antes de elegir uno. Para conocer las complicaciones de realizar un benchmark “serio” recomiendo la lectura de este post.

Copia de un fichero con dd

Como primera prueba realizamos la copia de un archivo con el comando dd. Con esta prueba medimos la velocidad de lectura y escritura secuencial en el disco. Hay que resaltar que las conexiones iSCSI de 1Gb nos fijan un máximo teórico de transferencia de unos 125 MB/s.
Los parámetros son los siguientes:

  • if define el dispositivo de origen, para la prueba de escritura usamos /dev/zero que es un dispositivo especial que devuelve tantos ceros como caracteres se intenten leer de él. Para la prueba de lectura el origen es el fichero creado en la prueba anterior.
  • of define el dispositivo de destino, en la prueba de escritura es un fichero en el almacenamiento remoto, en la prueba de lectura es /dev/null que es un dispositivo especial que descarta lo que se escribe en él pero informando de una escritura correcta.
  • bs número de bytes que se escriben o leen en un bloque.
  • count número de bloques que se leen o escriben en total.
  • conv=fsync (solo para la escritura) hace que se escriban físicamente los datos y metadatos en disco antes de terminar. Si no se usa esta opción hay un pequeñio desfase de  tiempo ya que dd da por terminada la escritura en cuanto los últimos datos entran en la cache, y no cuando se escriben físicamente en el disco.

La elección del tamaño del fichero (que sale de multiplicar bs * count) no es trivial, ya que si se escoge un tamaño menor que la memoria RAM del equipo, lo que medimos es el rendimiento de lectura o escritura a la caché del sistema, no al disco. Eligiendo un tamaño el doble de la RAM del equipo nos aseguramos de saturar la cache y que deje de ser un factor.

Escritura:

dd if=/dev/zero of=/mnt/secundario/kk2.img bs=1k count=128000000 conv=fsync

Lectura:

dd if=/mnt/secundario/kk2.img of=/dev/null bs=1k count=128000000

Para tener una referencia se ha realizado la misma prueba con el sistema de ficheros ext4 montado localmente y como curiosidad también servido mediante NFS con las opciones de montaje por defecto.
Los resultados fueron:

  • ext4:

Lectura: 80,1 MB/s
Escritura: 129,6 MB/s

  • OCFS2:

Lectura:  79,6 MB/s
Escritura:  85,2 MB/s

  • GFS2:

Lectura: 82,5 MB/s
Escritura:  73,4 MB/s

  • NFS

Lectura: ~5 MB/s
Escritura:  ~5 MB/s

Se observa en principio que ext4 es sensiblemente más rápido que los otros escribiendo, que entre OCFS2 y GFS2 el rendimiento es parecido y que NFS da valores anormalmente bajos muy probablemente por las opciones de montaje.

Benchmarking con Bonnie++

Para hacer una prueba un poco más seria hemos usado el programa de benchmark Bonnie++, en su versión 1.96. El comando es:

bonnie++ -d /mnt -n 128 -s 128g

donde:

  • -d indica el directorio de trabajo
  • -n el numero de ficheros múltiplo de 1024 que se usaran en las pruebas de creación de ficheros.
  • -s el tamaño de fichero que se usará en las pruebas de lectura/escritura. De nuevo el doble que la RAM.

Bonnie da los resultados en forma de tabla. He resaltado en rojo los dos resultados más relevantes para nuestra comparación, que son las velocidades de lectura/escritura secuencial:

Ext4

Version 1.96 Sequential Output Sequential Input Random
Seeks
Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
ctusercld02 126G 678 99 125342 44 52368 19 2558 98 115157 24 980.9 16 128 38900 66 +++++ +++ 10706 17 35788 67 +++++ +++ 12181 21
Latency 21643us 10012ms 9435ms 17472us 10342ms 1059ms Latency 307ms 808us 4626ms 317ms 36us 1738ms

GFS2

Version 1.96 Sequential Output Sequential Input Random
Seeks
Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
ctusercld01.user.cloud.citius 126G 324 98 104253 32 46590 27 656 28 65339 9 744.2 20 128 1474 55 150173 99 6754 62 1287 71 160639 99 7433 65
Latency 156ms 78807ms 23230ms 1652ms 768ms 1585ms Latency 3175ms 561us 508ms 1239ms 133us 79623us

OCFS2

Version 1.96 Sequential Output Sequential Input Random
Seeks
Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
ctusercld02 126G 354 99 128296 65 55756 31 1323 99 99257 21 919.9 16 128 306 97 +++++ +++ 6960 44 322 97 +++++ +++ 737 59
Latency 46812us 31391ms 1173ms 20976us 78835us 976ms Latency 480ms 45us 1229ms 383ms 128us 11242ms

Una breve explicación de lo que significa cada valor de la tabla:

Para las pruebas de lectura/escritura Bonnie usa tantos ficheros de hasta 1GB como sean necesarios para llegar al valor indicado por el parámetro -s, en este caso 126. Para las pruebas de creación de ficheros Bonnie usa tantos ficheros como se le indica en el parámetro -n multiplicado por 1024.

Para cada prueba Bonnie informa del uso de CPU (el valor %CPU) . Si algún valor es demasiado pequeño como para medirlo con exactitud, Bonnie muestra ++++ .

  • El sequential output per char escribe un byte cada vez usando la macro stdio putc(). La CPU debe ejecutar el código y asignar el espacio de archivo.
  • El sequential output block escribe el fichero usando invocaciones a write() más eficientes porque son a nivel de bloque. Aquí la CPU sólo asigna el espacio de archivo.
  • El sequential output rewrite  lee los metadatos del fichero, los modifica y los reescribe físicamente de modo que se requiera una operación lseek.filesystem cache and the speed of data transfer. LA CPU no realiza asignación de espacio de archivo en esta prueba, por lo que se mide la efectividad de la caché del sistema de archivos y la velocidad de transferencia.
  • El sequential input per char es igual que el output pero en lectura.
  • El sequential input block es igual que el output pero en lectura.
  • Random seeks realiza más de 8000 llamadas lseek() aleatorias para hacer un read() del resultado, y en un 10% de los casos además un write(). El resultado está fuertemente influenciado por el número de discos presentes en un RAID.
  • Sequential y random create crean y luego borran el número de ficheros designado de forma secuencial y aleatoria respectivamente.

Los resultados ordenados de mayor a menor  en lectura secuencial:

  • Ext4:  115 MB/s
  • OCFS2:  99 MB/s
  • GFS2:   65  MB/s

Se observa claramente el mejor comportamiento del sistema de archivos no compartido frente a los compartidos, y especialmente frente a GFS2, que ofrece un rendimiento especialmente pobre.

Los resultados ordenados de mayor a menor  en escritura secuencial (aquí hay que hacer notar el límite máximo impuesto por la conexión iSCSI de 125MB/s) :

  • OCFS2:  128 MB/s
  • Ext4 :  125 MB/s
  • GFS2:   103  MB/s

En este caso hay un empate virtual entre OCFS2 y ext4 que no es posible deshacer porque en el entorno de los 125 MB/s el cuello de botella pasa a ser la conexión iSCSI. En todo caso mencionar el buen rendimiento de todos los sistemas de ficheros aunque de nuevo GFS2 queda un poco por detrás.

Los resultados ordenados de mayor a menor de la re-escritura:

  • OCFS2:  55,7 MB/s
  • Ext4:  52,3 MB/s
  • GFS2:   46,6  MB/s

De nuevo un rendimiento parecido aunque otra vez GFS2 queda por detrás.

Conclusiones

Para obtener unos resultados realmente fiables y precisos sería necesario cambiar la metodología del benchmarking repitiendo las pruebas más veces, variando los parámetros y asegurándose de limpiar las cachés entre cada una. Cada prueba de Bonnie o de dd tarda en torno a las dos horas, así que teniendo en cuenta que el objetivo solo era tener un elemento de decisión entre GFS2 y OCFS2 estas pruebas sencillas nos bastan.

El benchmark indica que OCFS2 ofrece un rendimiento mayor que GFS2. Este resultado coincide con las pocas informaciones al respecto que pueden encontrarse en internet, por lo que finalmente escogimos OCFS2 como sistema de archivos.

Sin embargo, en la práctica resulto que OCFS2 es un sistema de archivos menos estable que GFS2, sobre todo cuando hay “movimiento” de nodos. Esto ocurría por ejemplo en el cluster de computación, donde los nodos se apagan y se encienden en función de la carga del sistema. Es por eso que poco a poco lo estamos sustituyendo por GFS2 donde es posible (ya que lo hemos probado y efectivamente en debian/ubuntu es muy inestable aún).

Acceso remoto á rede do centro: ¿como e para que?

É posible acceder á rede do centro e ó teu equipo dende outros centros ou dende a casa, e non é moi complicado. O primeiro é conseguir acceso á rede do centro. Para facelo, hai dúas alternativas:

  • A VPN, ou rede privada virtual, unha tecnoloxía que permite extender a rede do centro a través de Internet. Unha vez configurada a VPN nun equipo, é coma si estivera conectado á mesma rede do centro, polo que pódese acceder a todos os recursos da rede.
  • A pasarela SSH, unha máquina que está na rede do centro á que se pode conectar un por SSH dende calquera sitio.

Acceder á rede do centro non só serve para acceder a recursos propios do CiTIUS. Tamén pode ser unha forma de acceder a recursos que normalmente só están accesibles dende a rede da universidade, como a información de nóminas ou o acceso a certos catálogos de publicacións. Ten en conta que o acceso ó exterior usando a VPN está restrinxido, e só se pode acceder ós sitios no Listado de sitios accesibles a través da VPN (require autenticación).

A pasarela SSH tamén pode ser moi útil para saltarse restriccións de redes con firewalls, que limitan o acceso a determinados portos ou de determinado tipo de tráfico. Por exemplo, dalgunhas redes públicas onde só é posible acceder a portos como o 80 e o 443. Usando un túnel inverso SSH, a información viaxa ata a rede da universidade en paquetes SSH, e dende aí ó destino.