I have become comfortably numb

El martes estuve en la Real Academia de Ingeniería. Se celebraba el acto con el que Juan Antonio Zufiria, actual presidente de IBM para España, Portugal, Grecia e Israel, tomaba la plaza como académico de número. Su discurso de aceptación se tituló: La Supercomputación: Ampliando el Ámbito de lo Posible: un paradigma de los nuevos espacios de la Ingeniería al servicio del progreso. Fui invitado por mi jefe, que fue el encargado de la contestación.

Era un evento en el que gente muy lista se junta y habla de sus cosas, a los que voy con la esperanza que se me pegue algo y a cenar jamón de gratis. Lo de lista lo digo en serio. Juan Antonio Zufiria es considerado por muchos el estudiante más brillante de la historia de la escuela de Aeronáuticos. Digamos que está en otro nivel distinto del mío.

El discurso tenía, bajo mi punto de vista, una tesis clara: los ordenadores han hecho posible lo que antes era imposible y romper las barreras tecnológicas puede conseguir que la sociedad cambie significativamente. Hasta ahora los grandes ordenadores eran utilizados por gente como yo: investigadores con la intención de aprendar algo o construir algo. Sin embargo hoy empezamos a ver cómo estos cacharros tan exóticos y complicados de utilizar se emplean en Economía, Medicina o Farmacología. Zufiria puso el ejemplo de la gestión de la red eléctrica europea y de Watson.

Dijo algo parecido a que los ordenadores son una herramienta que está al servicio de nuestras neuronas, distinta de las demás, que están al servicio de nuestros músculos. Los ingenieros los hemos utilizado para lograr una vida más fácil pero ahora estamos ante el reto de crear un mundo más inteligente. Bueno, ahí le delató su deje corporativo porque "smarter solutions for a smarter planet" es el actual eslogan de IBM.

Fue un discurso interesante, habló de lo que es hoy mi trabajo y mi vida, pero pudo resultar algo aburrido para los profanos. Me gustaría centrarme en una parte de la contestación de Javier, que se limitó a propagar en el tiempo la idea de la capacidad de cálculo aplicada a la vida y de los efectos del aumento de las capacidades. Copio literalmente de la redacción de su discurso

Las disciplinas intelectuales pueden dividirse en dos grandes clases: las que podríamos llamar externalizantes, y las introspectivas. Las primeras tratan del mundo exterior, generalmente de la Naturaleza, y una de sus premisas es que los resultados deben ser, en la medida de lo posible, independientes del observador. Los ejemplos clásicos son la Física y la Química, las Ciencias Naturales y las Matemáticas.

La segunda clase la forman las disciplinas que se ocupan directamente del ser humano, como la Sociología, la Economía, las artes y, como representante extremo, la Filosofía. Podría pensarse que esta segunda clase es menos importante que la primera porque su sujeto es mucho más reducido. Lo más probable es que la Humanidad no sea un sujeto especialmente interesante ni singular en el esquema general de las cosas, pero no interesa porque somos nosotros y se trata de nuestra especie estudiándose a sí misma.

Las ciencias introspectivas tienen fama de ser blandas y faltas de rigor; al menos entre los practicantes de las otras ciencias. Se han citado muchas razones para ello tales como que las personas somos complicadas y que, por ejemplo, no hay ecuaciones que describan la sociedad. Todo eso es verdad pero el resto de los seres vivos y de los ecosistemas también son complicados y eso no ha impedido que la Biología y la Ecología se hayan ido conviriendo cada vez más en ciencias tradicionales.

Yo creo que el problema es otro. Las ciencias externalizantes son, al fin y al cabo, ventanas por las que miramos al mundo mientras que las introspectivas son espejos en los que nos miramos a nosotros mismos; y es mucho más difícil ser objetivo frente a un espejo que frente a una ventana.

Todo esto viene a que la Ingeniería se ha centrado hasta ahora en hacer útiles las ciencias externalizantes, con frutos tecnológicos espectaculares. Esa Ingeniería es la que ha hecho posible el mundo que conocemos y la inmensa mayoría de la Humanidad no podría existir sin ella. Un mundo de cazadores-recolectores tendría que estar infinitamente menos poblado que el nuestro. Sin embargo es verdad que la Ingeniería tradicional ha prestado poca atención a la Humanidad como objetivo directo de actuación. Si he entendido bien lo quenos ha dicho hoy Zufiria es que la teconología, y en particular la supercomputación, han llegado al punto en que la Ingeniería debería preocuparse de optimizar la Filosofía.

Es una proposición extraordinariamente interesante, que abre un mundo de nuevas posibilidades que no podemos despreciar pero que también está llena de peligros. [...] Por mi parte, jugando el papel de abogado del diablo, querría apuntar al menos un peligro. Uno de los rasgos más queridos y centrales de las ciencias tradicionales es su objetividad. En la Ingeniería ese aspecto es aún más crítico porque lo que hace un ingeniero tiene consecuencias prácticas y esas consecuencias son independientes de que la solución que adoptemos nos guste o no.

Sin embargo, cuando el objeto de la Ingeniería somos nosotros mismos, las reglas pueden ser algo distintas. No es que el problema cambie, las consecuencias siguen siendo reales y tan objetivas como siempre, pero la percepción de la sociedad podría ser otra y depender de aspectos estéticos o morales en vez de técnicos. Es algo que tenemos que pensar con cuidado y decidir qué camino tomar en caso de conflicto. Podemos relajar nuestra objetividad y adoptar a sabiendas soluciones subóptimas o podemos seguir ciñéndonos a las soluciones óptimas y afrontar las consecuencias sociales. Pero he dicho antes que, en este caso, estamos tratando con espejos y tanto los mitos clásicos como los cuentos infantiles nos avisan que los espejos que dicen la verdad son peligrosos y que no siempre tienen garantizada su integridad física.

La contestación aborda un problema con el que algún día nos encontraremos y que, según Javier, puede que yo viva. Puede que el desarrollo de las computadoras las haga más listas que nosotros. No es aún el caso. Nuestros cerebros tienen aún más FLOPS que el mayor ordenador del planeta con un consumo ridículo, de unos 20W, pero si la tendencia actual se mantiene esta situación cambiará tarde o temprano. Quizás la Ingeniería debería empezar a imaginar cómo conseguir que las máquinas piensen mejor para hacerlas mejores que nosotros. Luego podremos aplicar su "inteligencia" a nuestra vida para vencer nuestras propias limitaciones. Pero que una máquina pensara por nosotros tendría gravísimas implicaciones sociales y filosóficas, especialmente si empieza a darnos respuestas que no nos gustan o simplemente nos responde 42.

Juan estaba en Santorini, pero yo estaba en espíritu.

Hybrid OpenMP-MPI Turbulent Boundary +Layer Code Over 32k Cores

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:

1. 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.
2. 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.

1. Comprar una solución cerrada de HW+SW.
2. 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.

Seguimos en el laboratorio montando el centro de datos: cluster nuevo, 200TB de cinta con TSM, nuevo cuarto, aire acondicionado pata negra... Está siendo complicado y cansado, porque como os podéis imaginar esto no es excusa para dejar tirada la simulación y la tesis doctoral.

Nuestro objetivo es dar a nuestra infraestructura suficiente convergencia y estabilidad como para que no tenga que preocuparnos mucho durante los próximos 2-3 años. Ya que tenemos que cambiar de cuarto nos hemos puesto también a cambiar todo, incluso el servidor web.

Pero lo que está siendo con diferencia más difícil está siendo evacuar 70kW de potencia de un cuarto de menos de 30m cuadrados. Encima sin tener ni idea sobre aire acondicionado así que he tenido que hacer un cursillo acelerado sobre la expansión directa, los water chillers, unidades condensadoras, diferenciales de trifásica, PDUs, SAIs...

Suerte que la escuela se está haciendo cargo de la obra, que si no ya me veía sin vacaciones por tercer año consecutivo.

El martes estuve tomando un café con Luis, que para uno que conozco que es realmente emprendedor no le gusta que le definan con ese adjetivo. Él cree, como yo, que el futuro del proceso de conocimiento está en la gestión dinámica de recursos, los clouds. Es más; también coincido con él en que los clouds deben estar basados en estándares revisados por alguna organización con verdadero criterio como la W3C o la ISO.

Fijar un estándar llevará a todos los proveedores un buen rato y a los usuarios muchos disgustos. Cada gran proveedor usa una tecnología distinta y métodos propios para configurar claves, mandar imágenes de SO, gestionar dinámicamente las instancias... Cada uno intentará imponer como estándar su propio así que el riesgo que se corre es que cada uno termine imponiendo el suyo y terminemos con media docena de estándares parecidos pero distintos. Algunos recordarán lo que sucedió dentro de la ISO cuando se intentó estandarizar los formatos de documento de suite ofimática. Un desastre, vamos.

En lo que llevo de año natural he visto en primera persona o probado los clouds de Amazon, Google, IBM y Microsoft. Cada uno tiene sus ventajas e inconvenientes; hasta su propio método de facturación. Además todos han convergido a los precios de Amazon que parece ser el verdadero "elephant in the room".

En el laboratorio no tenemos un cloud porque no nos serviría para nada. Los clouds utilizan la virtualización para segregar recursos. Nosotros buscamos la agregación masiva de recursos porque un procesador o una porción de un disco duro no nos sirven absolutamente para nada. Pero si tenemos en cuenta que tenemos encerrados 700 procesadores y varios centenares de terabytes en un cuarto —por no hablar de lo que usamos fuera— sí me creo capaz de opinar sobre infraestructura en general.

Afortunadamente para nosotros, en temas de infraestructura los entornos científicos están varios años por delante de cualquier proveedor de servicios en la nube y han resuelto muchos de los problemas que estos grandes nombres de Internet tendrán que resolver. Los centros de supercomputación tienen mejores procesadores, mejores redes, mejores sistemas de almacenamiento y backup... Pero otra vez aparece el problema de la estandarización. Cada centro tiene sus reglas y opera de manera completamente distinta. Ni siquiera usan el mismo método para hacer login: ssh interactivo, ssh con par de claves, ssh interactivo con una cryptocard... También cada uno tiene su propio gestor de colas.

El problema es distinto pero parecido. No puedo coger un job que corre en Jugene y llevármelo al Mare Nostrum. De hecho no tengo ninguna garantía que lo que corre en un BG/P correrá en un Power o en un Xeon sin cambiar partes relevantes de la aplicación. En nuestro caso no habrá solución, ya sabemos que nunca se estandarizará el acceso a estas máquinas. De todos modos no es algo que sea imposible de solucionar, simplemente debes programar un poco más y abstraer tu aplicación de estas diferencias. Lo importante son tanto las diferencias sino que estén bien documentadas.

Lo que sí nos ha demostrado nuestro trabajo día a día es que, una vez ya has encontrado una solución subóptima para poder procesar, llegas al problema realmente importante. ¿Qué hago con mis datos? Parece que a todo el mundo se le está olvidando que lo importante de la informática son los datos. No pones a correr miles de procesadores durante millones de horas para llegar a un resultado como π/2. Generas un montón de bytes y un buen día tienes que hacer algo con ellos a parte de recordar dónde los tienes: moverlos, almacenarlos, distribuirlos...

Ahí es donde empieza la pesadilla de verdad. Cuando tienes que mover algo del orden de un terabyte —parece mucho pero es lo que cabe en un disco duro moderno, así que no es tanto— ya no puedes hacerlo con el navegador a través de tu ADSL guarrindonga. Más te vale hacerlo por un cable de fibra óptica con un protocolo específico si no quieres tener que partir tus datos en cachitos realmente pequeños. Y quien dice bajar, dice subir o mover de un sitio a otro.

Cuando miro la documentación de los proveedores de cloud están hablando de particiones de dos o cuatro gigas. Quizás es suficiente para guardar la contabilidad de una PYME pero es ridículo para una empresa de verdad o una PYME tecnológica. Y tampoco es verdad que la solución universal para los datos es una base de datos. Así se resuelve el problema de los datos en aplicaciones web, pero poco más.

Luego está el problema realmente importante. Los proveedores de cloud están en Carolina del Norte, Washington, Irlanda... ¿Cómo mando mis datos ahí? Cuando me traigo datos desde Alemania lo hago por el cable de fibra óptica que me dijeron que usara, con el protocolo que me recomendaron y entre dos centros de supercomputación para ir a 20 MB/s. Y si quiero traerme algo a Aeronáuticos ya puedo dar gracias a Rediris porque de otro modo ya me podría ir olvidando de tenerlos en "casa". Tampoco me serviría de mucho que un proveedor de cloud me dijera que está en Logroño si no hay un buen tubo hasta ahí. Al final la proximidad geográfica es sólo un tipo de proximidad. No uso mi PC para ver resultados porque hasta el array de discos tengo una fast ethernet, aunque sólo sean 20 metros de cable. Prefiero hacer login a un servidor conectado con el disco por 1.5m de fibra a 4 Gbps.

Los proveedores de hardware conocen el problema. El cálculo es fácil, lo realmente complicado es gestionar los datos. Si necesito cálculo me entiendo con el tío de ventas en una tarde. Si pido almacenamiento es probable que después de dos semanas aún no me hayan ofrecido lo que necesito (me ha pasado).

La solución a todo esto es tener un cloud relativamente cerca con una red lo suficientemente buena. Y esto no es tan difícil porque incluso las grandes ciudades de un país que lucha por crecer como España están cableadas con fibra óptica. Con esto bastaría con adoptar una solución N-Tier, como sucede con los centros de supercomputación. Un enorme CPD en Irlanda o en NC será una solución para algunos pero, por muy bien que lo vendan, no será una solución para todos. Pero contar además con un cloud más pequeño pero más cercano sí podría ser una solución para casi todos. Un servicio de nube realmente cercano no sólo puede proveer de cálculo y disco sino de otros servicios: escritorios remotos, sistemas operativos cloud como eyeOS... Podría abaratar significativamente el coste de IT de cualquier empresa, especialmente una PYME.

El problema de un sistema N-Tier es que para crearlo la estandarización es sencillamente imprescindible así que habrá que estar atentos a qué sucede con estos primeros pasitos de este mundo que está aún en pañales. Luego ya llegarán los problemas políticos como que venga Telefónica y se folle todo el negocio por intentar sacar cuatro perras más.

O quizás todo esto sea un cuento chino y el motivo por el que la nube tiene éxito es que todo el mundo odia la los administradores de sistemas.

Edit... No es necesario crear un cloud de la nada.

Cuando oyes a todo el mundo hablando sobre la nube desde el punto de vista del hardware siempre oyes a proveedores específicos que son capaces de ofrecer una cosa o otra. Amazon, Rackspace, Dreamhost, Arsys... Todos hablan de el negocio de convertirse en broker de recursos de su nube.

Este es el punto de vista de quien quiere ganar dinero con la nube. Es algo legítimo y no se les puede criticar pero no es la manera óptima de aprovechar dinámicamente recursos.

La gran ventaja de todo este middleware creado para la nube es que uno es capaz de abstraer el hardware de el dónde y el cómo así que a uno le da igual si una instancia se está ejecutando en Madrid o en Reijkiavik.

Antes de llegar al argumento de mi discurso pensemos un rato en el cloud de Amazon. Amazon tenía un enorme centro de datos necesario para mantener a flote su negocio de venta. Su equipo de infraestructura dimensionó todo para picos de compras como, por ejemplo, Thanksgivings. Esto implicaba que el resto del año los servidores estaban tocándose el escroto. Hoy uno lo haría al revés, diseñaría un gateway para soltar el excedente de conexiones a otro recurso pero ellos hicieron lo contrario: buscaron una manera de vender los recursos que les sobraban. Hoy son el mayor proveedor de recursos de hardware externos.

Creo que en España muchas empresas pueden seguir exactamente el mismo camino. Una vez ya manejas tu propia infraestructura de manera dinámica nada te impide ofrecerla al público. La tecnología actual permite hacer este tipo de ofertas sin que ello signifique un problema de seguridad. Entiendo que si le propongo a un banco que haga negocio dejando entrar a desconocidos en sus sistemas me tratarán de loco y después me echarán a patadas de sus oficinas pero lo harían sin justificación.

El coste importante de un servicio cloud son el edificio, los SAI, las PDU, la red de interconexión, los cables de fibra óptica armados hasta el switch gordo de Telefónica... Si tienes que dar servicio a 20K empleados seguro que tienes que construir algo así. El resto es más sencillo de lo que parece y, lo que es importante, también es relativamente barato.

Creo que es una situación win/win delante de las narices de todo el mundo.

Si todo va bien, no me muero, el vuelo llega, ningún meteorito devasta el planeta ni nada de eso, dentro de un par de semanas estaré en París. Me han aceptado la charla en el ScicomP 17 que se celebrará en el IDRIS (Institut du développement et des ressources en informatique Scientifique)

Es el encuentro de usuarios de superordenadores IBM. Dado que somos algunos de los mayores usuarios europeos del Blue Gene/P creímos que nuestras aventuras podían ser interesantes... Y que es en París. Durante una semana. Fuck yeah. Y el evento social será una cena de gala en un Bateaux Mouche. Fuck Yeah. Es la primera vez en mucho tiempo que tendré la oportunidad de disfrutar con la cámara.

Supongo que nos hablarán del Blue Gene/Q. Ya hay máquinas de prueba en Argonne, el Lawrence Livermore y se espera que termine también en el Cineca y el BSC si nuestro miserable país no se hunde antes.

Ya que tengo datos para mi tesis gracias, en parte, a IBM y que mi jefe estuvo trabajando para ellos hace unos años, he decidido hacerles un poco de publicidad gratuita. Este año su empresa cumple un siglo y están todos muy empalmados. El vídeo es el típico marketing americano diseñado para empalmar al personal eslogan tras eslogan, pero no está mal.