martes, 16 de septiembre de 2008

Aceleradores hardware

[Nota: en este artículo hago publicidad de marcas y modelos que conozco, sin otro ánimo que el ilustrativo y en ningún caso quiere decir que alternativas de la competencia sean peores opciones].

Actualizado el 19/9/2008


Con los avances en paralelización y multithreading de los últimos años (aunque con un cierto estancamiento de la velocidad por core), actualmente los responsables de servicios podemos adquirir servidores muy potentes a un coste relativamente bajo si lo comparamos con años anteriores. Ejemplos como Supermicro dan opciones muy económicas para entornos de "no tan misión crítica", pero fabricantes como HP e incluso Sun dan opciones x64 tremendamente interesantes (donde sube el precio es en el soporte).

En cualquier caso, hay situaciones que requieren "algo más". Y me explico. Si tenemos un entorno web de mucha concurrencia y computacionalmente "denso" puede ser que con un crecimiento horizontal en granja no sea suficiente. O mejor dicho, para mi gusto hay otras opciones que no requieren incrementar el número de máquinas.

Me estoy refiriendo a los aceleradores hardware. Los principales usos son la aceleración de SSL (operaciones de criptografía simétrica y asimétrica específicas para comunicaciones), HSM (operaciones criptográficas de propósito general) y GZIP (para la compresión de contenidos como se menciona en el post Compresión HTTP). He visto en una gran entidad financiera, con mis propios ojos, "morirse" un pedazo de servidor cuando hacía las operaciones SSL en los procesadores de propósito general, creedme.

Es cierto que muchos balanceadores y otros appliance de red nos solucionan parte de esta problática, pero en aquellos casos en los que esto no es una opción (o en los que precisamente lo que estamos construyendo es un appliance o proxy inverso) lo que debemos es adquirir los elementos hardware aceleradores adecuados. Hoy en día las opciones son mucho más económicas y mucho más potentes que lo que mucha gente se piensa.

Algunas opciones que hay en el mercado y que yo he tenido la oportunidad de probar (y poner en producción) son:
  • nFast SSL Offload (de nCipher): Tarjeta de red PCI (10/100/1000) que realiza las funciones criptográficas tanto asimétricas como simétricas (esta segunda parte es relativamente novedoso) necesarias para dar servicio SSL. Lo interesante de esta tarjeta es que actúa como un proxy inverso interno. Es decir, el interfaz de red atiende mediante canal SSL pero nuestro software servidores lo configuramos para que escuche "en plano", por lo que su integración es limpia e inmediata, y compatible con cualquier software.
    • Rendimiento nominal: 10.000 transacciones SSL/TSL por segundo
    • Throughput: 300 MBit/sec Full Duplex
  • AHA363 (de Comtech AHA): Tarjeta PCIe aceleradora GZIP, la más rápida del mercado. Trae una API y un módulo para Apache (aunque pueden desarrollarse otros.
    • Throughput: 5 GBit/sec
  • nShield 500 F2 (de nCipher): HSM completo que implementa todos los algoritmos de criptografía simétrica y asimétrica (incluso curvas elípticas). No se trata sólo de acelerador sino que su uso principal es la securización de claves privadas. Dentro de toda la gama de velocidades y niveles de securización, esta es más que suficiente para la mayoría de los propósitos, pero hay otras muchas opciones.
    • Rendimiento nominal: 500 firmas RSA de 1024 bits por segundo.
¿Os imagináis un sistema de servidores frontales x64 con dos procesadores XEON Quadcore y que además incorpore estas tarjetas? Imbatible. Y sorprendentemente económico, en órdenes de magnitud los elementos que he enumerado anteriormente rondan unos PVP de 3000€, 1000€ y 5000€ respectivamente. Es decir, obviando el HSM estaríamos aproximadamente duplicando el coste de un servidor promedio de las características mencionadas. Por unos 8000-9000 € tendríamos este sistema que aceptaría una concurrencia salvaje.

Obviamente tiene también sus inconvenientes, y es que cada elemento hard adicional incrementa las posibilidades de fallo, por lo que hay que considerar spare units y todo lo que conlleva.

Por cierto, respecto a la aceleradora GZIP no sólo estoy hablando de usarlo en la capa de servidor web / frontal, sino que fácilmente podríamos adaptar las bibliotecas Java o C de compresión para que en nuestra aplicación también utilizáramos el hardware de aceleración, e incluso hacer un JDK adaptado...

En algunos casos, en realidad, no hace falta irse tan lejos. ¿Sabíais que muchas de las capacidades de nuestros procesadores modernos están infrautilizadas? Para algunos propósitos no hay mejor acelerador hardware que el procesador que ya tenemos. Tanto AMD como Intel tienen bibliotecas de alto rendimiento para operaciones de copia de arrays, matemáticas, otras útiles para compresión, cifrado, procesamiento multimedia, etc).

Estoy hablando de Intel Integrated Performance Primitives (IPP) y de AMD Performance Library (APL). Un colega mío utiliza IPP para tratamiento de señales y asegura que es una auténtica maravilla, de hecho lo definió como "los ingenieros de Intel van 20 años por delante nuestro".

Una de las cosas con las que algunas veces he "soñado despierto" es con que las JVM/JDK puedan estar adaptados a estos aceleradores y también utilizar esas bibliotecas de Intel y AMD. Incluso llegué a mantener una conversación con Henrik Ståhl (Product Manager de JRockit en el momento de la conversación) preguntándole/proponiéndole sobre algunas de esas especializaciones. No lo veía claro y además los costes de mantenimiento sería brutal.

Por cierto que no soy el único que lo ha pensado, como puede verse en este hilo: http://forums.java.net/jive/thread.jspa?messageID=224530.

Pero volviendo al mundo real y asumible, os aseguro que el uso de aceleración SSL es una prioridad y la aceleración GZIP una auténtica necesidad si tenemos una concurrencia tremenda (¿cómo lo hará Google Inc.? ¿con aceleradores hard con los procesadores genéricos de las nubes de servidores?)

P.D.1: No he nombrado aceleradoras de gráficos, o el uso de las GPUs porque es un mundo que desconozco y que no he necesitado...

P.D.2: Sólo he nombrado esas marcas y modelos porque son los que yo conozco / he tenido experiencia satisfactoria. Hay otros fabricantes como http://www.safenet-inc.com/ o http://www.indranetworks.com/ con soluciones probablemente igual de válidas que las yo nombro arriba...

Actualización 19/9/2008: En otra conversación reciente con Henrik Ståhl, me sorprendió diciéndome que el uso de código / bibliotecas específicas para cierto hardware no es algo que hayan descartado para JRockit, aunque sea complicado. Digo que me sorprende porque en la primera conversación fue bastante tajante sobre los problemas que supondría y dudaba de los beneficios, sin embargo ahora ha dejado la puerta abierta. A mi ego le gusta pensar que he podido servir de empujoncito/inspiración...

4 comentarios:

CmaJ dijo...

Una pena el "oscurantismo / protección de negocio" de Google.

Diseñar un sistema para los niveles
de concurrencia que "sufren" debe ser algo realmente impresionante. Soy uno de los muchos que firmaría un contrato de confidencialidad y después pagaría por que me lo explicaran.

Server Performance dijo...

Yo apostaría a que el caso concreto de la compresión GZIP lo hacen con los procesadores genéricos.

Tienen nubles de decenas de miles de servidores en unos cuantos datacenters de EEUU (hasta donde yo sé eran Linux dualcore y ahora queadcore). Creo que sería inmanejable gestionar problemas, cientos de spare units en cada datacenter, etc.

Anónimo dijo...

Estaba buscando informacion sobre la implementacion de SSL de las IPP ("Intel IPP SSL support" en google) y me ha salido esta página como uno de los primeros enlaces.

La ganancia con IPP en el SSL es de un 40%. (Por cierto, IPP no implementa el SSL, sino que "parchea" determinadas operaciones con numeros grandes (BIGNUMs) de la OpenSSL.
Para un servidor no es espectacular porque con apilar mas servidores consigues lo mismo. (suponiendo que tu flujo de datos permita que puedas paralelizar las operaciones independientes. En un sistema en que nada es "petición-respuesta" sino mas bien "todos con todos" eso no es tan fácil...)
Pero si tu aplicacion es un cliente que hace cosas en tu PC, ganar un 40% en las comunicaciones puede ser ganar quizá un 20% en tu aplicación, y tener un 20% mas de CPU en una aplicacion local es muy importante.

"Volvemos a encontrarnos Obi Wan..."

Saludos
PJRM

serverperformance dijo...

Je je, me has pillado! Como ves hablo de ti en el artículo...

Viva STefFI Graf!