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.
Comentarios
Amazon
- Gazuderajuvi
- karma: 0
- lun 08 Ago 2011
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.
Supongo que ya lo habrás visto: fallo en Amazon Irlanda afecta a multitud de servicios, ht tp://barrapunto .co m/articles/11/08/08/0957229.shtml
depende
- depende
- karma: 0
- lun 08 Ago 2011
la nube ya ofrece servicios HPC dentro de ella (busca por hpc y amazon) incluso incluye gpus. Es decir, te puedes alquilar algo tan potente como lo que te has montado tu en la oficina, copiar los datos, calcular y de vuelta. Que es mas barato ?
Dificil de decir. Las nubes no son claramente superiores en terminos de precio. Tecnologicamente si lo son. Tal vez para usuarios que solo tienen que hazcer calculos un par de veces al anyo les sale a cuenta (vease el caso new york times).
Respecto al tema de hadoop, bueno no escala porque la ingenieria es de yahoo ;-) y aparte de ser un usuario hpc tienes que ser un muy buen desarrollador e ingeniero de sistemas hpc para configurarlo. Yahoo, linkedin y muchos lo tienen bien tuneado. Google tiene esta infraestructura, y sin necesidad de sistemas hpc ultracaros, es capaz de escalar a millones de nodos. Pero claro ellos no solo se gastan el dinero en hw si no que tambien invierten en talento (la parte mas high-performance).
Montar un hadoop es mucho mas barato que las cpus que te vende el lobby de supercomputacion (otro termino de marketing mas), escala mejor en terminos energeticos y tecnologicos ya que utiliza placas como de desktops donde el tema energetico esta muy estudiado y donde hay nuevos procesadores en camino etc etc.
HPC es para unos pocos virtuosos de la politica y del despilfarro de las epocas de burbuja. Las verdaderas empresas del futuro optimizaran los sistemas mas baratos para sus calculos.
El despilfarro de HPC a gran escala esta acabado, ya que no escala economicamente.
Por otro lado, falta nos hace en este pais que se acaben las corruptelas de principio a fin y con dinero publico (elmundo.es/navegante/2005/02/10/empresas/1108051681.html). El software libre les acabara barriendo.
@depende
- guillem
- karma: 0
- mar 09 Ago 2011
Las tarjetas gráficas resuelven un conjunto de problemas muy pequeño dentro del mundo del HPC. Amazon ofrece tarjetas como reclamo a banca de inversión e ignoro la demanda que tienen.
Amazon no te permite hacer MPI, los procesadores son malos (bus lento), la red es una castaña y la alimentación eléctrica una mierda.
Las placas y los procesadores de destktop gastan mucho más por Gflops que los procesadores de servidor, y no hablemos de las fuentes de alimentación que les montan. Y aún mucho más si los comparamos con arquitecturas RISC de bajo consumo. El Blue Gene, la joya de lo que tú llamas el lobby de la supercomputación, es la infraestructura de cálculo más eficiente que existe, muy por delante de lo que monta Google. De hecho, la granja de Google no es tampoco un prodigio de eficiencia energética.
Algunos están empezando a montar cosas con Atoms y ARMs que no nos sirven a los que hacemos ciencia porque no llevan unidades vectoriales, necesarias para hacer cuentas en doble precisión. Se la quitan porque es de lo que consume más energía.
Creo que no entiendes el HPC y no te da la gana hacerlo. Si me dejaran utilizar todo el centro de datos que tiene Google en NC no me serviría para nada porque NECESITO una red rápida y de baja latencia. Yo no hago Mapreduce y no encontraré un algoritmo para reducir mi problema a un Mapreduce por mucho que me empeñe. No existe.
Cuando te encuentras con una tarea fuertemente analítica en la que no te sirve el Mapreduce como correlaciones temporales, búsqueda de patrones, creación de árboles n-arios, métodos numéricos de alto orden... una unfraestructura tipo nube poco acoplada no es rentable; sería tirar dinero. Para ello mejor comprar un buen switch Infiniband, unos buenos procesadores de 64 bits y conseguir un buen manual de MPI. Todo lo demás es marketing de los que están en contra de la supercomputación.
Estas cosas que dices que son tan caras son las más baratas para hacer lo que hacemos. Lo sabemos porque hemos probado de todo, desde la época de los Digital alpha hasta los Xeon Westmere pasando por Pentium III en caja de PC normal y corriente. Te equivocas porque nunca has montado un superordenador, has cogido un amperímetro y has medido el consumo. Yo sí lo he hecho. Y Google puede decir misa que de CFD no tienen ni puta idea.
Otra cosa más. HP puede decir lo que quiera sobre el Mare Nostrum. Todas las multinacionales tienen chanchullos de estos. Se va a hacer un centro de supercomputación en Mieres, lo anunció el anterior presidente de Asturias en las oficinas de HP, supongo que sin saber que estas cosas van por narices a concurso público. El pliego del concurso lo hizo una empresa llamada Catón que, casualidad, es un socio de HP. Estoy seguro que HP no puede proporcionar el nivel de soporte que pide el BSC en España. Probablemente lo puede ofrecer en Francia, Italia, Suiza o Alemania. Pero no en España. Y no tengo que leerlo en artículos de Febrero del 2005.
El HPC a gran escala tiene mucho futuro. Es una infraestructura imprescindible para hacer ciencia. Si estás en contra de ello pide también que cierren el CERN, el CSIB, el Fermilab y todos los sitios donde también hacen ciencia y gastan un montón de dinero.
Lenovo
- jgpallero
- karma: 0
- mar 09 Ago 2011
Yepa,
¿Qué te parecen estos dos pepinos?:
shop.lenovo.com/SEUILibrary/controller/e/gbweb/LenovoPortal/en_GB/catalog.workflow:category.details?action=init¤t-catalog-id=FD6DB49790C7411D933567FC361231FB¤t-category-id=7169546BFB61412BA52F819D914F4A03#/?facet-1=4&page-index=1&facet-2=3&page-size=10&facet-3=4&facet-4=9&facet-5=1
¿Será tirar el dinero? ¿Me puedo fiar de Lenovo como me fiaba de la antigua IBM?
El uso va a ser, preferentemente, la resolución de sistema de ecuaciones lineales llamando a Lapack y BLAS y código escrito en OpenMP. Me mola que ya vengan con NVIDIA que soporta CUDA 2.0 (cálculos en doble precisión)
Lenovo
- jgpallero
- karma: 0
- mar 09 Ago 2011
Yepa,
¿Qué te parecen estos dos pepinos?:
shop.lenovo.com/SEUILibrary/controller/e/gbweb/LenovoPortal/en_GB/catalog.workflow:category.details?action=init¤t-catalog-id=FD6DB49790C7411D933567FC361231FB¤t-category-id=7169546BFB61412BA52F819D914F4A03#/?facet-1=4&page-index=1&facet-2=3&page-size=10&facet-3=4&facet-4=9&facet-5=1
¿Será tirar el dinero? ¿Me puedo fiar de Lenovo como me fiaba de la antigua IBM?
El uso va a ser, preferentemente, la resolución de sistema de ecuaciones lineales llamando a Lapack y BLAS y código escrito en OpenMP. Me mola que ya vengan con NVIDIA que soporta CUDA 2.0 (cálculos en doble precisión)
@jgpallero
- guillem
- karma: 0
- mar 09 Ago 2011
Mi jefe y algunos colegas del BSC tienen Thinkpads serie T de 15 pulgadas. Ellos ya tuvieron los antiguos IBM serie T. Me cuentan que el portátil tiene calidades muy parecidas a cuando era IBM. De momento no me cuentan nada del soporte porque aún no se les ha estropeado.
ThinkPad
- jgpallero
- karma: 0
- mar 09 Ago 2011
Gracias por la info. Cuando eran IBM tenían fama de duros e indestructibles. Es en este aspecto donde no acabo yo de fiarme de los chinos.
depende
- depende
- karma: 0
- mar 09 Ago 2011
Tus afirmaciones suenan un poco fuertes.
Nadie ha dicho que todo sean GPUs tambien hay pequenyas instancias capaces de correr linpack dentro de amazon;
insidehpc.com/2010/07/13/amazon-adds-support-for-traditional-hpc-workloads-with-cluster-compute-instance/
Este es el futuro. Respecto a las unidades vectoriales en los ARM, tranquilo que seguro que intel no va conseguir reducir sus numeros tan facilmente... sin embargo ARM es un especialista en consumo bajo. Todo llega, todo pasa en tecnologia.
A veces nos gusta y a veces no. La HPC esta destinada a desaparecer en un clima economico como el que se avecina. Se van a trabajar en voltajes bajos, rendimiento y los que no puedan comprarse un cluster o no les acepten en el lobby publico de supercomputacion acabaran pagando por un buen servicio. Si, yo creo que de aqui a 5 anyos es mas que posible.
Si ya se que ahora va a llegar mariano y va a injectar millones en MN, otra vez que pasara a manos de multinacionales. Es cierto que algunos cientificos lo necesitan (incluido tu), pero mi comentario trata de reflejar que el futuro es otro rollo y no el despilfarro al que estamos acostumbrados (mira lo que esta pasando con Blue Waters ...)
Ante todo buena suerte con tu proyecto, no te lo tomes a mal conyo parece que no se puede hablar de otras religiones ....
@depende
- guillem
- karma: 0
- mar 09 Ago 2011
Perdon por el tono. Releyendo el comentario tienes razón con que suena un poco fuerte. Lo escribí demasiado tarde.
Insisto. Una nube no es un superordenador. Que se puede hacer MPI con un cloud no significa que sea una buena idea hacerlo. La clave está en que la red es muy mala. Pero es que no te puedes ni imaginar lo mala que es. He hecho pruebas con MPI sobre TCP/IP con un switch gigabit bueno y es una mala idea. No estoy hablando de un cincuenta por ciento más; hablo de un factor de cien.
Seguirá habiendo un gran superordenador en España, al igual que tenemos telescopios y máquinas de secuenciación genética. Más que probablemente estará en el BSC y costará muchos millones, pero menos que diez km de autopista o que los viajes de los europarlamentarios. Lo que no habrá será un superordenador en cada comunidad autónoma. Un centro de supercomputación no es rentable. Parece que algunos presidentes regionales no lo sabían y han tirado los últimos cartuchos de fondos europeos.
Y lo reitero. Lo que hago no se puede hacer en la nube. No es cuestión de ser listo o tonto; es que no se puede hacer. Google hace full text search y Amazon tiene una tienda. Lo que a ellos les va bien no tiene por qué irme bien a mi.
El HPC no desaparecerá. La eficiencia energética de un Blue Gene o del Cray XE6 está por encima de cualquier nube, que no dejan de ser servidores convencionales metidos en una sala muy grande. Los procesadores del Blue Gene/P consumen 12W, más o menos lo que un Atom; y saca cuatro veces más flops.
Los superordenadores usan ya procesadores de bajo consumo específicamente diseñados para una carga de trabajo concreta, cosa que de momento no hacen las nubes.
Sobre el Blue Waters. Vi in situ el nodo que IBM había diseñado específicamente para la máquina y me pareció una locura. Era la hostia, pero era evidente que tenía que ser caro de pelotas. El gran problema es que IBM ya está desarrollando el BG/Q, del que ya tiene tres pedidos muy grandes en firme (LLNL, ANL y Cineca). Desarrollar dos superordenadores es muy caro y lo que IBM simplemente ha llegado a la conclusión que perdía demasiado dinero haciéndolo. Era algo que muchos nos temíamos pero confiábamos más en el prestigio de IBM para con sus clientes.
depende
- depende
- karma: 0
- dom 14 Ago 2011
Los flops por KW los miden usando linpack. Nada mas lejos de un codigo que haga algo util, como por ejemplo el tuyo.
Las comparaciones son odiosas lo se, -y si las latencias de tu codigo son importantes-. PEro yo me queria referir a la eficiencia energetica de los DC de la nube, que en algunos casos van por el 1.1. De los DC academicos de supercomputing ya sabemos.... Cuando mas cristal y mas bonito el edificio mejor.
En un pais con unas condiciones climaticas y energeticas tan cambiantes, me parece aberrante tener un supercomputador tostandose al sol en verano ademas de las carencias energeticas evidentes de algunas grandes ciudades espanyolas.
Aqui es donde me revelo contra el lobby, eso es politica por politica.
Y siendo claros, preferiria que la maquina estuviera mas dividida y cerca de donce hace realmente falta. Pocos codigos escalan hoy en dia a maquinas petaflop, asi que tal vez, deberian de preguntarse que pasa con la gente que necesita tanto paralelismo. Con las medidas draconianas que nos acechan a partir de noviembre, estoy convencido de que el lobby hara su trabajo. Eso si la productividad cientifica de este pais no crecera necesiariamente. No todo el mundo hace la misma ciencia.