Anterior: HDP | Siguiente: Yo no he sido
Sube a mi nube. Tu amiga gorda no cabe.
Supercomputación
Para quien no lo haya pillado, el título de la entrada es un homenaje a Mamá Ladilla.
Hace un tiempo escribí una entrada alegando que lo más dificil de hacer bien cuando tienes una carga analítica son los datos, los procesadores son la parte trivial. Es algo que te reconocen veladamente todos los directores de centros de supercomputación, incluso me ha llegado por terceros que en IBM conocen el desequilibrio entre procesadores y discos y que se verá claramente en las listas de precios futuras.
He estado esta semana —mis vacaciones son mías y las malgasto como quiero— viendo cómo las nubes grandes (Amazon, Azure, Rackspace...) llevan el tema de los discos y me he convencido más aún que si dependes de tu ancho de banda las nubes públicas no son necesariamente una buena idea. Uno las puede evaluar pero si se las plantea como única opción puede pillarse los dedos seriamente.
Hay muchas maneras de manejar los datos en paralelo. En entornos científicos, donde sólo movemos archivos, la estrella son los sistemas de ficheros paralelos. Escribimos archivos enormes (como de cien gigas) y muchos procesadores leen y escriben a la vez. En entornos empresariales está el Mapreduce, también basado en archivos, en el que cada nodo tiene sus propios datos, calcula sobre ellos y devuelve un resultado. El rey en esto parece seer Hadoop y su infraestructura adicional, HDFS y Hive. Finalmente tenemos las bases de datos paralelas, una maravilla de la tecnología —o no, como veremos después— con precios desorbitados que rozan los 200K por terabyte de datos.
Si ignoramos las bases de datos paralelas como Teradata, Oracle Exadata y demás, el denominador común es el mismo: utilizar hardware commodity y agregar recursos. Hacer más por menos.
La diferencia entre los sistemas de ficheros paralelos y el Mapreduce es la misma que entre el HPC y el cloud. Cuando uno monta un superordenador se esfuerza principalmente en dos cosas:
-
Que todos los nodos sean idénticos para poder darles exactamente la misma carga de trabajo. Como decimos en el gremio, el mejor algoritmo de balanceo de carga es que todos los nodos hagan exactamente lo mismo.
-
Que estén conectados por una red rápida. Por red rápida entendemos algo que está más cerca de un bus que de una red. En el caso de Infiniband QDR4x, lo que se está instalando hoy, 40 gbits/s de ancho de banda y 1.07 ms de latencia MPI end to end. De este modo los algoritmos no evitan sistemáticamente la comunicación, simplemente comunican cuando deben.
De manera un poco difusa se puede decir que, desde el punto de vista del hardware, la nube es un superordenador que no cumple estas condiciones. El sobrecoste por nodo de una red rápida está entre los 1000 y los 1500. Es una pasta pero el nodo típico de almacenamiento con 24 TB te cuesta 10K. Estas dos premisas sirven para que escalar hasta los centenares de nodos sea relativamente simple.
Pero en la nube el hardware es heterogéneo —son instancias de máquina virtual, no tenemos ni idea de quién más hay corriendo en el mismo procesador y qué está haciendo con él— y la red suele ser una gigabit sin RDMA.
Hay un proyecto que intenta acercar las cargas analíticas a las bases de datos paralelas llamado HadoopDB, una base de datos relacional pensada para hacer Mapreduce con Hadoop sobre un cloud. Su arquitectura es realmente simple: cada nodo tiene un servidor de base de datos (PostgreSQL) con parte de los datos, supongo que haciendo striping como en cualquier sistema de ficheros paralelo, la operación de map va entonces con su query a la base de datos. Aunque tengo que leer un poco más sobre cómo funcionan los detalles. Los tíos que lo están programamdo perecen saber lo que hacen.
Su gran problema es, oh sorpresa, la escalabilidad. Necesitan hacer auténticos malabarismos para escalar hasta el centenar o el millar de nodos. Lo que hacen es un pequeño test antes de cada transacción a la base de datos para luego balancear la carga en función de los resultados, porque ahora no sólo hay que balancear el cálculo, hay que balancear también el acceso a la base de datos. Además este test lo tienen que rehacer cada poco tiempo porque al tratarse la nube de una infraestructura dinámica, las condiciones pueden cambiar en cualquier momento. Es un coste muy elevado para solucionar un problema que se puede evitar completamente con hardware específico y no muy caro.
De hecho, si eliminamos la magia del balanceo de carga, programar una base de datos paralela no es en absoluto difícil. De hecho he terminado un prototipo en Python en un par de días.
Me parece curioso como algunas corporaciones se están planteando pasar del mainframe salvaje como un SGI Origin o un System z a la nube ignorando el centenar de pasos intermedios. El hardware que te ofrece el cloud es malo y para cargas analíticas puede representar una pérdida de dinero importante respecto a algo que recuerde más a un superordenador.
Cada día me estoy convenciendo más que esto de la nube en grandes corporaciones se debe a que sus infraestructuras de cálculo funcionan mal. Tengo la sospecha que cuando alguien de métodos o de cálculo va al director técnico y le dice que necesita mil procesadores le rebota al jefe de soporte que no tiene ni idea de lo que le está hablando. Luego los de IT lo resuelven con la típica llamada a PWC —o similar— que, en vez de derivarles a HPC, les derivan a data warehouse, knowledge management y demás conceptos de puro marketing que suelen significar "caro de pelotas". Entonces deciden externalizar par huir de esta pesadilla y empiezan a ver el cloud con buenos ojos.
El problema de la computación por agregación de recursos (HPC y cloud) es que cada sistema es de su padre y de su madre. Ante eso caben dos posibilidades.
- Comprar una solución cerrada de HW+SW.
- Comprar una solución HW y ponerte a picar código como un poseso para adaptar tu SW.
La diferencia entre una solución y la otra suelen ser un par de ceros en la factura. La decisión depende casi siempre de balancear valor y riesgo. Creo que no hay que pensar mucho para saber qué es lo que se suele hacer en este caso.
Desde mi humilde experiencia en HPC pienso que la única opción real es picar código como un poseso y hacer supercomputación es mucho más sencillo que hacer cloud. Pero que mucho más.
-
Tags:
Ingeniería
-
Para quien no lo haya pillado, el título de la entrada es un homenaje a Mamá Ladilla.
Hace un tiempo escribí una entrada alegando que lo más dificil de hacer bien cuando tienes una carga analítica son los datos, los procesadores son la parte trivial. Es algo que te reconocen veladamente todos los directores de centros de supercomputación, incluso me ha llegado por terceros que en IBM conocen el desequilibrio entre procesadores y discos y que se verá claramente en las listas de precios futuras.
He estado esta semana —mis vacaciones son mías y las malgasto como quiero— viendo cómo las nubes grandes (Amazon, Azure, Rackspace...) llevan el tema de los discos y me he convencido más aún que si dependes de tu ancho de banda las nubes públicas no son necesariamente una buena idea. Uno las puede evaluar pero si se las plantea como única opción puede pillarse los dedos seriamente.
Hay muchas maneras de manejar los datos en paralelo. En entornos científicos, donde sólo movemos archivos, la estrella son los sistemas de ficheros paralelos. Escribimos archivos enormes (como de cien gigas) y muchos procesadores leen y escriben a la vez. En entornos empresariales está el Mapreduce, también basado en archivos, en el que cada nodo tiene sus propios datos, calcula sobre ellos y devuelve un resultado. El rey en esto parece seer Hadoop y su infraestructura adicional, HDFS y Hive. Finalmente tenemos las bases de datos paralelas, una maravilla de la tecnología —o no, como veremos después— con precios desorbitados que rozan los 200K por terabyte de datos.
Si ignoramos las bases de datos paralelas como Teradata, Oracle Exadata y demás, el denominador común es el mismo: utilizar hardware commodity y agregar recursos. Hacer más por menos.
La diferencia entre los sistemas de ficheros paralelos y el Mapreduce es la misma que entre el HPC y el cloud. Cuando uno monta un superordenador se esfuerza principalmente en dos cosas:
- Que todos los nodos sean idénticos para poder darles exactamente la misma carga de trabajo. Como decimos en el gremio, el mejor algoritmo de balanceo de carga es que todos los nodos hagan exactamente lo mismo.
- Que estén conectados por una red rápida. Por red rápida entendemos algo que está más cerca de un bus que de una red. En el caso de Infiniband QDR4x, lo que se está instalando hoy, 40 gbits/s de ancho de banda y 1.07 ms de latencia MPI end to end. De este modo los algoritmos no evitan sistemáticamente la comunicación, simplemente comunican cuando deben.
De manera un poco difusa se puede decir que, desde el punto de vista del hardware, la nube es un superordenador que no cumple estas condiciones. El sobrecoste por nodo de una red rápida está entre los 1000 y los 1500. Es una pasta pero el nodo típico de almacenamiento con 24 TB te cuesta 10K. Estas dos premisas sirven para que escalar hasta los centenares de nodos sea relativamente simple.
Pero en la nube el hardware es heterogéneo —son instancias de máquina virtual, no tenemos ni idea de quién más hay corriendo en el mismo procesador y qué está haciendo con él— y la red suele ser una gigabit sin RDMA.
Hay un proyecto que intenta acercar las cargas analíticas a las bases de datos paralelas llamado HadoopDB, una base de datos relacional pensada para hacer Mapreduce con Hadoop sobre un cloud. Su arquitectura es realmente simple: cada nodo tiene un servidor de base de datos (PostgreSQL) con parte de los datos, supongo que haciendo striping como en cualquier sistema de ficheros paralelo, la operación de map va entonces con su query a la base de datos. Aunque tengo que leer un poco más sobre cómo funcionan los detalles. Los tíos que lo están programamdo perecen saber lo que hacen.
Su gran problema es, oh sorpresa, la escalabilidad. Necesitan hacer auténticos malabarismos para escalar hasta el centenar o el millar de nodos. Lo que hacen es un pequeño test antes de cada transacción a la base de datos para luego balancear la carga en función de los resultados, porque ahora no sólo hay que balancear el cálculo, hay que balancear también el acceso a la base de datos. Además este test lo tienen que rehacer cada poco tiempo porque al tratarse la nube de una infraestructura dinámica, las condiciones pueden cambiar en cualquier momento. Es un coste muy elevado para solucionar un problema que se puede evitar completamente con hardware específico y no muy caro.
De hecho, si eliminamos la magia del balanceo de carga, programar una base de datos paralela no es en absoluto difícil. De hecho he terminado un prototipo en Python en un par de días.
Me parece curioso como algunas corporaciones se están planteando pasar del mainframe salvaje como un SGI Origin o un System z a la nube ignorando el centenar de pasos intermedios. El hardware que te ofrece el cloud es malo y para cargas analíticas puede representar una pérdida de dinero importante respecto a algo que recuerde más a un superordenador.
Cada día me estoy convenciendo más que esto de la nube en grandes corporaciones se debe a que sus infraestructuras de cálculo funcionan mal. Tengo la sospecha que cuando alguien de métodos o de cálculo va al director técnico y le dice que necesita mil procesadores le rebota al jefe de soporte que no tiene ni idea de lo que le está hablando. Luego los de IT lo resuelven con la típica llamada a PWC —o similar— que, en vez de derivarles a HPC, les derivan a data warehouse, knowledge management y demás conceptos de puro marketing que suelen significar "caro de pelotas". Entonces deciden externalizar par huir de esta pesadilla y empiezan a ver el cloud con buenos ojos.
El problema de la computación por agregación de recursos (HPC y cloud) es que cada sistema es de su padre y de su madre. Ante eso caben dos posibilidades.
- Comprar una solución cerrada de HW+SW.
- Comprar una solución HW y ponerte a picar código como un poseso para adaptar tu SW.
Desde mi humilde experiencia en HPC pienso que la única opción real es picar código como un poseso y hacer supercomputación es mucho más sencillo que hacer cloud. Pero que mucho más.