Hana y Linux en Power: De Big a Little Endian
La disponibilidad de los sistemas IBM Power para SAP Hana ha ampliado el círculo de proveedores de servidores Hana. Y es claramente perceptible que IBM ha incrementado las actividades de ventas y marketing en el entorno SAP con sus servidores Hana-on-Power (HoP) desde principios de año aproximadamente.
Al mismo tiempo, los sistemas HoP basados en procesadores Power 8 se están adaptando técnicamente a determinadas condiciones o estándares de Hana. El cambio Hana 1.0-Hana 2.0 representa una especie de cambio de rumbo.
El tema relevante aquí es que con Hana 2.0 y Suse Enterprise Linux Server (SLES) 12 for SAP Applications, los sistemas HoP con procesadores P8 pasarán de big endian a little endian en términos de procesamiento/almacenamiento de orden de bytes interno - lo que significa que a partir de ahora todos los sistemas de servidor Hana tendrán procesamiento/almacenamiento de orden de bytes little endian; tanto los sistemas Hana-on-Intel como los sistemas Hana-on-Power en las versiones scale-out y scale-up.
Cuál de los tipos de procesamiento, little endian por aquí o big endian por allá, se utiliza suele venir determinado por el fabricante del procesador. Los procesadores Sparc o también los procesadores de Motorola -y hasta la fecha también los de IBM- utilizan el procesamiento big-endian; los procesadores Intel, en cambio, siempre han utilizado el procesamiento little-endian.
Poco primero
El tipo de procesamiento seleccionado no influye en el rendimiento o la velocidad de un procesador. Big endian significa "primero el extremo grande" y significa que la ordenación y el almacenamiento de datos en un procesador, como un número de varios dígitos que incluye letras (campo de datos multibyte), se realiza de mayor a menor.
Con el procesamiento little-endian ("primero el extremo pequeño"), es el caso inverso, es decir, de pequeño a grande. El cambio big-endian-little-endian significa esencialmente dos cosas: una cierta estandarización en los servidores Hana a partir de Hana 2.0, pero también un procedimiento más sencillo en el futuro a la hora de desplegar/portar un sistema operativo, por ejemplo, porque sólo hay que soportar un tipo de procesamiento, el little endian.
En el caso de SLES for SAP y HoP, esto empieza con la versión 12. SLES for SAP 11 (SP4) también es compatible con sistemas HoP con Big Endian. Mientras que Hana 1.0 requería NetWeaver 7.40, Hana 2.0 requiere la versión 7.50.
Alta disponibilidad y recuperación en caso de catástrofe
Con SLES for SAP 12 de Suse, las innovaciones asociadas también pueden ser utilizadas por primera vez por los sistemas Hana-on-Power. Por ejemplo, la funcionalidad automatizada ampliada de alta disponibilidad (HA) y recuperación ante desastres (DR).
SAP proporciona mecanismos de SAP Hana System Replication (SR) para HA, que normalmente se manejan y utilizan manualmente. El aumento del SLA mediante la automatización lo proporciona Suse High Availability Solution (HAE) de SLES 12.
La replicación del sistema mediante una precarga de memoria en un clúster (por ejemplo, un clúster de 2 nodos) suele preferirse como solución de HA central para SAP Hana.
Agentes de recursos Hana
Otro aspecto destacado de SLES for SAP 12 son los agentes de recursos (RA) de SAP Hana para configuraciones de clúster. Esto también permite gestionar, supervisar y controlar las instancias de base de datos Hana y las réplicas.
Además, se pueden configurar las RA. Hasta la fecha, Suse Linux/SLES for SAP Applications es la única plataforma de sistema operativo para Hana on Power.
