TDI Fase 5 - Hana el doble de rápido

Con TDI 5, los clientes de SAP pueden determinar las dimensiones o configuraciones de sus servidores Hana de forma independiente junto con los proveedores de hardware. Al menos en gran medida. Similar a los tiempos clásicos de SAP. TDI 5 supone un ahorro de costes para los clientes.

Durante mucho tiempo, los clientes de SAP tuvieron que configurar y utilizar Hana exclusivamente como un appliance. Todo en términos de diseño/configuración en una caja como una solución de sistema preconfigurada, preinstalada y probada con los componentes principales (capas): Servidor y almacenamiento, incluido Linux como plataforma de sistema operativo, software SAP y también funcionalidad de red.

Las principales ventajas desde el punto de vista de SAP son que todos los componentes están armonizados y probados; SAP y sus socios evaluaron soluciones para los dispositivos, que se diseñaron como sistemas ScaleUp de nodo único o sistemas ScaleOut multinodo.

El dimensionamiento, por así decirlo, se llevó a cabo de acuerdo con los requisitos del cliente, seguido de la instalación y prueba del sistema, así como de su instalación y funcionamiento.

Pero entonces hubo un cambio de rumbo y una opción adicional de diseño/configuración: el llamado "concepto de integración de centros de datos a medida de SAP Hana", o TDI para abreviar.

Desde otoño de 2014, los clientes de SAP que lo desearon pudieron diseñar o configurar su propio entorno de sistemas SAP Hana (sistemas ScaleUp y ScaleOut) sobre la base de TDI.

La principal diferencia entre los elementos centrales del diseño de Hana y un dispositivo es que, con el enfoque TDI, las capas de servidor, almacenamiento y red pueden seleccionarse con mayor o menor libertad.

Sin embargo, los sistemas de servidor, almacenamiento y red de los distintos proveedores deben estar certificados por SAP. Hasta la fecha, Linux sigue siendo el único sistema operativo que puede utilizarse junto con Hana, con Suse SLES for SAP Applications como plataforma de sistema operativo preferida.

Quicksizer de SAP proporciona

Ahora, según información consistente de la comunidad SAP, la Fase 5 de TDI, o TDI 5 para abreviar, está entrando en una nueva ronda. Y eso no es todo. TDI 5 representa un punto de inflexión, pero también podría verse así: SAP está remando hacia atrás en lo que respecta a los servidores Hana. Y a un estado similar al de los sistemas clásicos basados en SAP Netweaver.

En respuesta a las consultas de los partners de SAP, TDI 5 significa que "los clientes de SAP volverán a tener más flexibilidad o margen de maniobra a la hora de dimensionar sus servidores Hana.

Ahora, el cliente y el proveedor de hardware pueden volver a determinar juntos en gran medida las especificaciones del sistema y vuelven a ser corresponsables de ellas, sobre todo de las especificaciones principales", como afirma un experto de un fabricante de hardware de Hana. "Lo que también es nuevo es que vuelve el término SAPS", se informa.

Como antes, una herramienta de SAP llamada Qucksizer escupe las dimensiones del hardware, en primer lugar el tamaño de la memoria y el número de núcleos, clasificados según el tamaño de las camisetas.

Sin embargo, además del TDI 5, también se vuelve a utilizar SAPSen, una unidad para el rendimiento de un sistema SAP del mundo SAP Netweaver/Classic. Sirve de base para determinar el número de núcleos necesarios para un sistema Hana. Cuando no se puede utilizar SAPSen, entra en juego, según las explicaciones, la denominada relación núcleo-memoria.

Además del quicksizer, también se puede utilizar el llamado informe de migración para el dimensionamiento de Hana. Muestra más información durante una migración de SAP classic Hana, por ejemplo, las cargas de trabajo creadas y mucho más.

A continuación se describe una importante innovación asociada:

"Ahora los clientes pueden trabajar con su proveedor de hardware para determinar ellos mismos el dimensionamiento adecuado o especificar si es L, M o S, con un menor número de núcleos que antes y con el uso de servidores más pequeños".

Por ejemplo, una carga de datos Hana, una carga de datos en memoria de otros sistemas fuente, también podría llevar a que el quicksizer sugiriera o especificara el uso de un tamaño L con muchos núcleos en lugar de un tamaño M con menos núcleos - pero aún así se podría utilizar un tamaño M con menos núcleos.

Por lo tanto, estás de acuerdo con el cliente en un sistema de tamaño M con menos núcleos, porque una carga de datos en sí misma tiene lugar con menos frecuencia durante el funcionamiento de Hana y puedes tomarte tu tiempo con ella si es necesario.

En otras palabras:

Según la información disponible, con TDI 5 se pueden ahorrar núcleos. Esto conduce en última instancia a una reducción de los costes. La obligación de utilizar sistemas Hana sobrepotenciados con muchos núcleos, de los cuales un elevado número prácticamente no se utiliza, se ha planteado varias veces a SAP, explica un experto en la escena y pinta el siguiente panorama:

"Era y sigue siendo frecuente que un deportivo con unos 400 CV funcione al ralentí, pero apenas se ponga en marcha". Concretamente: de los 120 núcleos disponibles, por ejemplo, no se utilizan ni 20.

Por otro lado, es obvio que los nuevos avances en procesadores -además de aumentar constantemente la visualización- también están incrementando el rendimiento de los servidores Hana actuales y, en consecuencia, es necesario instalar menos núcleos para obtener el mismo rendimiento.

En el entorno Intel (Hana-on-Intel), los actuales procesadores Skylake están generando un nuevo impulso, al igual que el entorno Hana-on-Power con las recién anunciadas máquinas Hana de IBM con procesadores Power 9.

Nada sucede sin la presión del cliente

Por tanto, los clientes de SAP deberían estar satisfechos con TDI 5 por las innovaciones, que por un lado suponen un ahorro de costes y, por otro, una especie de back-to-the-roots con mayor autodeterminación del servidor Hana o más flexibilidad por sí mismo.

Hablando de clientes. En conversaciones con expertos de la comunidad SAP, surgió la pregunta: ¿Qué ha impulsado ahora a SAP a aplicar los cambios fundamentales asociados al TDI 5 y los esbozados anteriormente?

Se escuchó casi unánimemente: "Sólo la presión de los clientes hizo cambiar de opinión a SAP".

Un miembro de la comunidad, que como otros no desea ser nombrado, informó del siguiente incidente interesante: Un gran cliente de SAP, con muchas filiales, quería contratar licencias de Hana o S/4.

Sin embargo, la empresa ha hecho depender esto de que se le permita utilizar menos núcleos de los especificados realmente. De hecho, aproximadamente el mismo número que antes con SAP Classic. Las licencias de SAP sólo se cerraron cuando SAP lo garantizó.

Las razones por las que SAP, como guardián tecnológico en términos de hardware de servidores Hana, siempre ha favorecido una línea más bien restrictiva, a pesar de que los propios servidores Hana en realidad ofrecen más rendimiento del necesario o podrían aprovecharse en mayor medida (con una mayor relación núcleo-memoria), las responden los miembros de la comunidad de la siguiente manera:

"Al parecer, en SAP simplemente temen que una utilización excesiva de los servidores o núcleos de Hana no haga más que empeorar los tiempos de respuesta de la base de datos de Hana en fracciones de segundo."

"Los clientes pueden utilizar tanto los servidores potentes existentes como los nuevos, ya que TDI 5 mejora significativamente la relación memoria-núcleo. Hay que utilizar menos núcleos para la misma cantidad de memoria.

Esto puede reducir la huella del servidor, ya que se necesitarán menos servidores y se reducirán los costes de activación y mantenimiento de los núcleos.

Para el dimensionamiento de todas las nuevas ofertas, pero también para los clientes que ya utilizan Hana-on-Power (redimensionamiento según TDI 5), el hardware puede utilizarse de forma más eficiente y rentable.

El cambio de TDI 4 con Core to Memory a TDI 5 con SAPSen se traduce en una necesidad de recursos significativamente mejorada, más justa, reducida y, por tanto, más rentable de la capacidad de CPU necesaria para el cliente, así como en una mejor utilización del procesador de los sistemas Hana-on-Power.

Esto representa un claro paso en la dirección correcta en cuanto a la potencia informática necesaria y, sobre todo, la recuperación de la responsabilidad del cliente en la adquisición y utilización de los recursos informáticos en colaboración con el fabricante y el socio comercial, como siempre ha ocurrido con los sistemas SAP clásicos".

"A primera vista, Hana TDI 5 no tiene un gran impacto en los entornos Hana virtualizados con VMware. Incluso antes de TDI 5, el uso de VMware vSphere para Hana permitía a los clientes utilizar los sistemas de servidores de Hana de forma más sólida y flexible que las configuraciones fijas de servidores de dispositivos de Hana.

Antes de TDI 5, el único factor para calcular el rendimiento era la memoria necesaria para una instancia de Hana. La configuración de CPU definida para ello se describía mediante la denominada relación núcleo/memoria.

TDI 5 puede utilizarse para calcular la carga de trabajo prevista en SAPS y utilizar esta información para determinar el tamaño máximo de la memoria de trabajo de un sistema Hana (Hana físico o virtual).

Ahora es posible configurar Hana VM que se acercan al límite de 4 TB. La flexibilidad adicional que aporta TDI 5 a la configuración de una Hana VM hace que la configuración conforme de una VM sea más compleja.

VMware ha desarrollado una herramienta de configuración que admite un enfoque basado en SAPS además del dimensionamiento de camisas de dispositivos SAP Hana existente y utiliza estos dimensionamientos como base para la creación de configuraciones de VM Hana conformes, facilitándolas.

Esta iniciativa de estandarización está siendo debatida actualmente por VMware y SAP en el SAP Sizing Meeting con todos los socios tecnológicos de SAP. En pocas palabras, desde la perspectiva del cliente, TDI 5 cambia lo siguiente desde el punto de vista de VMware: es posible más RAM por Hana VM (dependiendo del dimensionamiento de SAPS), más RAM de Hana por licencia de CPU de VMware, mejor utilización de los recursos y el uso del servidor existente, se puede utilizar un tipo de CPU más pequeño (menos núcleos de CPU) si es necesario o ya no es necesario cambiar el hardware debido a las limitaciones de RAM.

Cualquier dimensionamiento, con o sin TDI 5, debe considerarse un proceso iterativo (Planificar, Hacer, Comprobar, Actuar), ya que los sistemas cambian a lo largo de su vida útil. La configuración de la máquina virtual debe adaptarse en función de estos cambios. La posibilidad de utilizar más RAM por CPU o CPU más pequeñas aporta flexibilidad y, en última instancia, ahorra dinero".

"SAP TDI Fase 5 no cambia la relación núcleo-memoria: sigue siendo de 768 GB para BW y de 1,5 TB para SoH (para procesadores Skylake).

Una novedad es que tanto el quickizer para sistemas nuevos como el informe de dimensionamiento para sistemas existentes ofrecen un valor SAPS. Esta información permite seleccionar una solución más pequeña y, por tanto, más rentable.

Además de abordar la memoria, el objetivo de SAP es permitir a los clientes seleccionar la CPU en función de sus necesidades y evitar así configuraciones con procesadores excesivamente potentes (sobredimensionados). El proceso se asegura a la baja mediante el requisito de un mínimo de 8 núcleos por CPU.

Para HPE, como fabricante, esto supone la oportunidad de ofrecer soluciones basadas en las necesidades y, por tanto, optimizadas en costes. La fase 5 de TDI se centra en la optimización: actualmente no se necesita más potencia de CPU en el mercado de Hana. El foco sigue estando en el direccionamiento de la memoria".

"TDI 5 continúa las optimizaciones que SAP ha introducido en general con Tailored Datacenter Integration para el uso del servidor SAP Hana. Ahora, los clientes de SAP pueden gestionar sus requisitos de infraestructura de TI individuales de forma aún más flexible.

Desde el punto de vista del cliente, incluidos los proveedores de servicios SAP, esto aporta beneficios, entre ellos ventajas de costes. Como socio de SAP desde hace muchos años, Suse es conocido por apoyar tanto el concepto de appliance como el enfoque Tailor Data Centre Integration (TDI) de SAP.

Como proveedor de Linux preferido y seleccionado con SLES para aplicaciones SAP, Suse naturalmente también trabaja estrechamente con Hana en proveedores Intel y con IBM Hana en sistemas Power.

En cuanto a los desarrollos, pero también a diario en proyectos SAP Hana o en proyectos que se centran en el uso de soluciones de aplicación basadas en Hana como SAP S/4 Hana "

"Con TDI Phase 5, SAP abre la posibilidad de alinear las infraestructuras de Hana con la carga de trabajo específica del cliente según sea necesario. Fujitsu utiliza conceptos inteligentes para optimizar las inversiones en una infraestructura de TI SAP y mejorar el ROI de la solución global SAP Hana.

En muchos casos, los clientes han experimentado una utilización insuficiente de los procesadores utilizados en sus sistemas debido a la vinculación previa de la memoria de trabajo a la CPU utilizada. Especialmente con las aplicaciones Suite-on-Hana, no es infrecuente una utilización de la CPU del 10 al 15 por ciento durante el funcionamiento estándar.

La fase 5 de TDI abre ahora las siguientes posibilidades adicionales: una evaluación de necesidades con SAP Quicksizer, en la que los requisitos de rendimiento esperados se almacenan sobre la base de datos empíricos. Estos datos pueden utilizarse para hacerse una idea de los requisitos esperados antes de una nueva instalación de Hana.

Especificando los valores SAPS para el servidor de base de datos se obtiene generalmente una mayor cantidad de RAM por CPU y, en consecuencia, "más Hana/Euro". Además, la relación entre CPU y RAM se puede adaptar individualmente al cliente y se puede lograr una utilización óptima de la infraestructura.

Con TDI Fase 5, el cliente se desvincula de facto de la relación fija entre CPU y memoria, siendo las únicas restricciones el uso de sistemas liberados para SAP Hana. Esto conlleva una mejora de la relación núcleo/memoria y de la relación precio/rendimiento.

Por ejemplo, para una base de datos Hana con un requisito de memoria principal, se puede seleccionar un sistema de dos CPU en lugar de uno de cuatro CPU, que cumple los requisitos en términos de rendimiento de SAPS.

Además del puro funcionamiento de la base de datos SAP Hana, Fujitsu también ofrece a sus clientes la integración en un modelo operativo que integra Hana de forma homogénea en los procesos de trabajo y lo libera de su papel especial."