Anterior: SloMo 2 | Siguiente: Centímetros
Blah blah blah (muy aburrido)
Supercomputación
Hay relativamente pocas diferencias entre un cluster de pequeño tamaño como el que tenemos en el laboratorio y los monstruos en los que corremos las grandes simulaciones. El primer gran escollo, la escalabilidad, depende en gran medida del algoritmo. Por norma general, si funciona bien en 8000 nodos, funcionará en 32. En nuestro caso el cálculo en un BG/P o en un Xeon no tiene ninguna diferencia. Cuando ejecutamos la versión de BG/P en nuestro cluster las comunicaciones funcionan mejor mientras que el cálculo es un poco más lento debido a la pobre escalabilidad en OpenMP del Xeon 5450.
Sí hay algo que es completamente distinto: el I/O. Escribir en un BG/P no tiene nada que ver con escribir en un cluster de 32 nodos. El motivo principal es que, en el momento en el que lo que tienes que grabar en disco más de 100 GBi, es una mala idea hacerlo en serie.
Escribir en serie es fácil. Da igual cómo lo hagas y el formato que uses. Sólo hay un procesador escribiendo a la vez y el sistema de ficheros no se puede liar. En resumen: hay un único identificador de archivo. Incluso en superordenadores con sistemas de ficheros paralelos, como el Mare nostrum, la mayoría de códigos escriben sólo con el nodo maestro.
Esto nos enfrenta a un serio problema. El ancho de banda de un sistema RAID no suele pasar el GBi/s, que es lo que te da un interfaz Fibre Channel. Pero difícilmente eres el único usando el disco así que lo más normal es que nunca llegues a ver el pico de ancho de banda. Dejémoslo en que vemos 0.5 GBi/s. Supongamos que tenemos que leer 300 GBi, algo bastante habitual cuando pasas de los 1024 nodos, con lo que tardamos 600 s en leer y 600 s más en escribir. Esto hace 20 minutos, 0.36 horas, que puede parecer poco. Cuando tienes que multiplicar esta cifra por el número de cores ya no te parece tan poco. Así, un proceso que no era intensivo en I/O se convierte en un devorador de horas de cálculo que podrías perfectamente gastar haciendo ciencia.
Hoy todo el mundo le dedica una gran atención a cómo escalar en superordenadores, cómo sacarles el máximo rendimiento a las horas de cálculo, como si lo único que se hiciera en ellas fuera calcular. En cambio el I/O siempre se soluciona con la misma receta: hacerlo asíncrono. Sin embargo no puedes hacer asíncrona la lectura inicial ni la escritura final.
Esta es la manera en la que estamos solucionando el problema:
- El nodo maestro abre el archivo con un
posix_open
.
- Manda el identificador de archivo al resto de nodos.
- Cada nodo hace un
fseek
y pone el puntero de escritura donde debe.
- Cuando se escribe se hace en bloques del mismo tamaño que el bloque del sistema de ficheros para aumentar la velocidad. En el caso de gpfs 2MBi.
Este método nos permite conseguir prácticamente el ancho de banda pico del sistema de ficheros. Nuestro récord son 26GBi/s -un blue ray por segundo- con 8096 nodos. Pero presenta el problema de tener un formato de archivo fragmentado. Si la variable se corta antes de los 2MBi nos queda una zona llena de mierda.
Los sistemas de ficheros distribuidos irán consolidándose a medida que el número de procesadores aumente. No necesariamente para conseguir más ancho de banda -el ancho de banda de cualquier red de altas prestaciones es un orden de magnitud mayor que el de un controlador de disco- sino para conseguir que más nodos accedan a un disco que no tienen de manera concurrente. Demasiadas infraestructuras utilizan NFS para este tipo de concurrencia cuando nunca se diseñó para ello. Leer y escribir en paralelo en un formato portable será cada vez más una necesidad de modo que, si la brecha de la supercomputación es un problema cultural, más nos vale que empecemos a ver cursos sobre HDF5 por ahí.
Parece que si la comunidad científica ya ha escogido HDF5, Linus ha apostado por Ceph como sistema de ficheros. Por otro lado, PVFS2 sigue siendo una incógnita, Lustre puede tener un futuro muy negro e IBM sigue vendiendo como churros GPFS a precio de oro.
-
Tags:
Ingeniería
Hay relativamente pocas diferencias entre un cluster de pequeño tamaño como el que tenemos en el laboratorio y los monstruos en los que corremos las grandes simulaciones. El primer gran escollo, la escalabilidad, depende en gran medida del algoritmo. Por norma general, si funciona bien en 8000 nodos, funcionará en 32. En nuestro caso el cálculo en un BG/P o en un Xeon no tiene ninguna diferencia. Cuando ejecutamos la versión de BG/P en nuestro cluster las comunicaciones funcionan mejor mientras que el cálculo es un poco más lento debido a la pobre escalabilidad en OpenMP del Xeon 5450.
Sí hay algo que es completamente distinto: el I/O. Escribir en un BG/P no tiene nada que ver con escribir en un cluster de 32 nodos. El motivo principal es que, en el momento en el que lo que tienes que grabar en disco más de 100 GBi, es una mala idea hacerlo en serie.
Escribir en serie es fácil. Da igual cómo lo hagas y el formato que uses. Sólo hay un procesador escribiendo a la vez y el sistema de ficheros no se puede liar. En resumen: hay un único identificador de archivo. Incluso en superordenadores con sistemas de ficheros paralelos, como el Mare nostrum, la mayoría de códigos escriben sólo con el nodo maestro.
Esto nos enfrenta a un serio problema. El ancho de banda de un sistema RAID no suele pasar el GBi/s, que es lo que te da un interfaz Fibre Channel. Pero difícilmente eres el único usando el disco así que lo más normal es que nunca llegues a ver el pico de ancho de banda. Dejémoslo en que vemos 0.5 GBi/s. Supongamos que tenemos que leer 300 GBi, algo bastante habitual cuando pasas de los 1024 nodos, con lo que tardamos 600 s en leer y 600 s más en escribir. Esto hace 20 minutos, 0.36 horas, que puede parecer poco. Cuando tienes que multiplicar esta cifra por el número de cores ya no te parece tan poco. Así, un proceso que no era intensivo en I/O se convierte en un devorador de horas de cálculo que podrías perfectamente gastar haciendo ciencia.
Hoy todo el mundo le dedica una gran atención a cómo escalar en superordenadores, cómo sacarles el máximo rendimiento a las horas de cálculo, como si lo único que se hiciera en ellas fuera calcular. En cambio el I/O siempre se soluciona con la misma receta: hacerlo asíncrono. Sin embargo no puedes hacer asíncrona la lectura inicial ni la escritura final.
Esta es la manera en la que estamos solucionando el problema:
- El nodo maestro abre el archivo con un
posix_open
. - Manda el identificador de archivo al resto de nodos.
- Cada nodo hace un
fseek
y pone el puntero de escritura donde debe. - Cuando se escribe se hace en bloques del mismo tamaño que el bloque del sistema de ficheros para aumentar la velocidad. En el caso de gpfs 2MBi.
Este método nos permite conseguir prácticamente el ancho de banda pico del sistema de ficheros. Nuestro récord son 26GBi/s -un blue ray por segundo- con 8096 nodos. Pero presenta el problema de tener un formato de archivo fragmentado. Si la variable se corta antes de los 2MBi nos queda una zona llena de mierda.
Los sistemas de ficheros distribuidos irán consolidándose a medida que el número de procesadores aumente. No necesariamente para conseguir más ancho de banda -el ancho de banda de cualquier red de altas prestaciones es un orden de magnitud mayor que el de un controlador de disco- sino para conseguir que más nodos accedan a un disco que no tienen de manera concurrente. Demasiadas infraestructuras utilizan NFS para este tipo de concurrencia cuando nunca se diseñó para ello. Leer y escribir en paralelo en un formato portable será cada vez más una necesidad de modo que, si la brecha de la supercomputación es un problema cultural, más nos vale que empecemos a ver cursos sobre HDF5 por ahí.
Parece que si la comunidad científica ya ha escogido HDF5, Linus ha apostado por Ceph como sistema de ficheros. Por otro lado, PVFS2 sigue siendo una incógnita, Lustre puede tener un futuro muy negro e IBM sigue vendiendo como churros GPFS a precio de oro.