Experiencia práctica con Hana on Power

El "Appliance Hana System" significaba que los clientes que estaban acostumbrados a recibir un sistema clásico en nuestra nube privada en pocas semanas tenían que esperar más de un mes para recibir un sistema Hana, porque el fabricante tenía que construir primero el dispositivo del tamaño correspondiente, transportarlo por avión y despacharlo en aduana antes de poder instalarlo en nuestro centro de datos en la nube.

Luego estaba el problema de insertar un sistema "bare metal" como un "bloque especial a medida" en un entorno optimizado para la estandarización, la virtualización y el despliegue automatizado. Por no hablar de la supervisión, la aplicación de parches y la ampliación.

Tallas de las camisetas Hana

La rígida restricción de las tallas de las camisetas también impedía ajustarse a las necesidades del cliente, ya que, por desgracia, la flexibilidad es un concepto extraño para los electrodomésticos. Siempre había que redondear la memoria y adivinar lo que el cliente podría necesitar dentro de tres años, lo que, por supuesto, suponía unos costes de adquisición mucho más elevados.

En el caso de muchos clientes, también nos encontramos con el problema de que sus necesidades de memoria principal aumentaban mucho más rápido de lo esperado. Sin embargo, la única forma de "actualizar" un dispositivo es instalar físicamente más módulos DIMM y CPU, si la placa base seleccionada originalmente aún tenía espacio para ellos. Si no era así, había que adquirir un aparato más grande.

No toque nunca un aparato en marcha

Aquí aprendimos que el viejo adagio informático "nunca toques un sistema en funcionamiento" sigue siendo válido. Como los módulos DIMM y las CPU adicionales tienen que introducirse en sus zócalos con cierta fuerza y la placa base se flexiona un poco en el proceso, podría ocurrir que un conector se saliera del zócalo en otro punto.

Al intentar reiniciar, de repente todos los ventiladores dejaban de funcionar o el sistema no podía volver a la vida en absoluto, lo que requería de nuevo la intervención de técnicos de servicio de los fabricantes, ¡y todo ello mientras el cliente esperaba poder volver a trabajar!

En conjunto, era una situación insatisfactoria para todos los implicados: Hana como appliance era simplemente una contradicción con la nube. Tal vez uno de los motivos de las bajas cifras de implantación de Hana en los primeros años.

Integración de centros de datos a medida

Afortunadamente, con la ayuda de algunos grandes clientes, los fabricantes de hardware consiguieron persuadir gradualmente a SAP para que suavizara el rígido modelo de dispositivo. En una primera fase, se permitió el uso de matrices de almacenamiento externas en lugar de discos internos, más tarde se autorizó el uso de los procesadores E5, más baratos, para sistemas pequeños, a lo que siguió la compatibilidad con VMware y, por último, IBM Power, todo ello bajo la etiqueta: Tailored Datacenter Integration (TDI).

Traje a medida en lugar de camisa de fuerza

Esto también nos dio la oportunidad de ofrecer a los clientes de SAP un traje flexible y personalizado en lugar de una camisa de fuerza estándar, que también podría integrarse en un moderno entorno de nube privada. ¿Pero en qué plataforma?

Una comparación de las restricciones de Intel con VMware frente a IBM Power con virtualización "integrada" reveló diferencias en el posible tamaño y número de sistemas Hana virtualizados.

Además, varios clientes habían señalado que necesitaban bastante más memoria que los 3 TB que permitían los sistemas Intel de 4 zócalos habituales en aquella época. Y todo ello "en la menor instancia posible", ya que no habían tenido precisamente las mejores experiencias con el escalado.

Basándose en esto y en la experiencia de la empresa con IBM Power, se tomó la decisión de adquirir dos tipos de máquinas: la S824L para sistemas Hana de hasta 2 TB y la E880 para los de mayor capacidad. Más tarde, se añadió un E850 que, con sus 4 TB, se estableció como el caballo de batalla ideal.

En la versión "sólo Linux", como se requiere para Hana, las máquinas Power también son considerablemente más baratas que para AIX. Esta decisión se reveló rápidamente como un éxito total, tanto desde el punto de vista técnico como comercial.

Virtualización

Gracias a la virtualización procedente del mundo mainframe (¿quién se acuerda de MVS?) a nivel de firmware, fue posible evitar las pérdidas habituales asociadas a la virtualización de terceros debido a latencias adicionales, especialmente en IO - para Hana, esto significa "rendimiento bare metal".

Tanto la memoria como el rendimiento de la CPU pueden personalizarse hasta un nivel de 1 MB y 1/20 núcleos. Como los sistemas Hana generalmente sólo requieren una fracción del rendimiento de la CPU especificado por las reglas de SAP como "acero de miedo", el exceso de rendimiento de la CPU se puede colocar en un pool compartido por todos los sistemas Hana que se ejecutan en la máquina. (Los ingenieros de estructuras se refieren a un refuerzo completamente sobredimensionado de hormigón armado como "acero asustadizo" para estar "mil por cien" seguros de que el cliente no presentará una demanda debido a grietas en la pared). Un sistema que necesite más potencia de la prevista puede recurrir a ella sin que ello suponga costes adicionales para el cliente.

En principio, también se podría ajustar la memoria de forma dinámica si Hana no intentara acceder a recursos que ya no están disponibles tras una reducción de la memoria. Por lo tanto, es aconsejable reiniciar Hana cuando cambien los recursos de memoria.

LPAR Live Mobility ha demostrado ser especialmente beneficiosa, ya que permite trasladar incluso sistemas Hana muy grandes de una máquina a otra durante el funcionamiento.

Aunque el hardware de Power sea extremadamente estable, es puramente estadístico que se produzca un problema con un parque de máquinas grande que obligue a sustituir algún componente. Afortunadamente, todos los problemas que se han producido hasta ahora han tenido la amabilidad de anunciarse con antelación o han sido interceptados por la redundancia.

Gracias a Live Mobility, pudimos limpiar las máquinas en cuestión de los sistemas del cliente durante su funcionamiento, sustituir la placa base o la tarjeta de red en cuestión y volver a trasladar los sistemas sin que el cliente se diera cuenta.

Incluso un cambio completo de arquitectura de clúster compartido a arranque SAN, en el que cada máquina individual de la red pudiera borrarse y reconfigurarse una vez de forma continua, fue posible sin afectar a las operaciones del cliente.

Memoria Tetris

Las ventas y los clientes estaban especialmente entusiasmados porque, con un poco de planificación previa, siempre era posible mantener suficientes reservas en reserva para que los sistemas Hana de tamaño medio estuvieran disponibles ad hoc llenando las ranuras libres de las máquinas. Y si no quedaba espacio libre en una máquina lo suficientemente grande, siempre era posible liberar el suficiente cambiando a sistemas más pequeños.

El conjunto recuerda mucho al juego de ordenador Tetris, en el que bloques de distintos tamaños "caen del cielo" y hay que distribuirlos de tal manera que se cree un "paquete de bolas más denso".

Eso es lo que hacemos en las operaciones de Hana. Lo que llega "de sopetón" son las peticiones de los clientes de nuevos sistemas Hana de cualquier tamaño, todos ellos supuestamente disponibles para ayer.

Como en un juego de ordenador, una distribución inteligente garantiza que la memoria de todas las máquinas se utilice casi al cien por cien en el menor tiempo posible, lo que a su vez complace al director financiero, aunque se queje constantemente profesionalmente de que hay que comprar máquinas nuevas cada pocas semanas debido a la demanda cada vez mayor de los clientes para volver a tener tragaperras gratis.

También es posible adaptar los sistemas en funcionamiento de los clientes a las necesidades reales mediante una hábil reasignación. Gracias a nuestro "Observatorio de la memoria de Hana", podemos ofrecer a los clientes actuales de SAP una previsión de cuándo será necesario asignar más memoria principal a un sistema Hana para evitar las consabidas cancelaciones de grandes informes por "falta de memoria" (OOM).

Lo que muchos clientes también aprecian es que también pueden utilizar sistemas Hana más grandes temporalmente para PoCs. Una vez finalizado el PoC, los recursos se devuelven al pool y no se incurre en más costes.

Esto significa que, incluso con grandes sistemas Hana, los clientes sólo tienen que pagar por lo que necesitan en ese momento, a diferencia de los proveedores de servicios en la nube, para los que las grandes instancias de Hana que no caben en sus hojas estándar tienen que reservarse y pagarse con tres años de antelación.

El único inconveniente es que 4096 GB no están disponibles en una máquina Power de 4 TB, por ejemplo, ya que la propia virtualización consume unos cuantos GB. En la mayoría de los casos, sin embargo, es posible acordar con el cliente que 1 TB equivale a 1000 GB, lo que resulta muy cómodo.

Las nuevas máquinas IBM Power 9, que ofrecen un máximo de 16 TB con 4 zócalos y 8 TB con DIMM asequibles, mejoran aún más la posibilidad de optimizar el panorama del sistema.

Conclusión

Hana on Power nos ha permitido integrar Hana de forma flexible y rentable en una nube privada, lo que ha aumentado enormemente la satisfacción de los clientes, las ventas y el departamento financiero.

Los tamaños flexibles de los sistemas, la rápida disponibilidad de nuevos sistemas y el uso temporal de los recursos hacen felices a los clientes y a las ventas, y la utilización casi completa de las inversiones en un corto espacio de tiempo hace feliz al departamento financiero. También podemos ofrecer sistemas Hana más grandes con funcionamiento 7x24 a un precio mucho más bajo que cualquier proveedor de nube pública.

Esto se refleja en unas cifras de instalación en constante aumento. Nuestro panorama de sistemas Hana on Power crece actualmente 1 TB a la semana debido a un flujo constante de instalaciones de nuevos clientes, con tendencia a duplicarse. Hana on Power es Hana como cabría esperar en una nube: en Syntax (antes Freudenberg IT) lo llamamos flexHana.