La Escalabilidad en SAP HANA (y V), notas SAP a tener presente

Complementado la información que hemos compartido sobre la Escalabilidad de un appliance o sistema SAP HANA, creemos que se deben tener presente las siguientes notas SAP al abordar este tema:


Complementado la información que hemos compartido sobre la Escalabilidad de un appliance o sistema SAP HANA (aquí entradas anteriores: I, II, III y IV) creemos que se deben tener presente las siguientes notas SAP al abordar este tema:

En estos documentos encontraremos recomendaciones y restricciones sobre la clusterización en SAP HANA, una característica técnica para la que se van presentando novedades en las actualizaciones de esta plataforma.

La Escalabilidad en SAP HANA (IV). Enfoque Scale-out, tipos de configuración

Las posibilidades de ampliación horizontal (Scale-out) están determinados por el fabricante, los cuales han diseñado posibles configuraciones de escalabilidad horizontal SAP HANA y están certificadas por SAP. En estas configuraciones se deben tener presente que puede haber limitaciones en cuanto al número de nodos soportados por las aplicaciones a utilizar (tales como BW on HANA o ERP on HANA) y las configuraciones que deben tener estos hosts


Las posibilidades de ampliación horizontal (Scale-out) están determinados por el fabricante, los cuales han diseñado posibles configuraciones de escalabilidad horizontal SAP HANA y están certificadas por SAP.  En estas configuraciones se deben tener presente que puede haber limitaciones en cuanto al número de nodos soportados  por las aplicaciones a utilizar (tales como BW on HANA o ERP on HANA) y las configuraciones que deben tener estos hosts (Según un documento de IBM – “In-memory Computing with SAP HANA on IBM eX5 Systems” – una clusterización en SAP HANA podría estar conformada por un máximo de cuatro nodos homogéneos, con similar configuración, sea esta de tipo “S” o “M” – aquí ver configuraciones-).

Un Sistema SAP HANA con un único nodo

En una configuración Scale-out, se obtiene beneficios por el particionado de los datos para aumentar las posibilidades de gestionar más información y con mayor eficiencia. Por otro lado se puede brindar mayor seguridad a la plataforma por la incorporación de  “nodos backup” para que entren en funcionamiento si algún nodo que este brindando un servicio fallase (sistema de tolerancia a fallos).

Clusterización de un sistema SAP HANA (enfoque Scale-Out) sin tolerancia a fallos

 

Actualmente existen dos posibles tipos de configuración:

  • Scale-out solution without high-availability capabilities.  Los nodos que conforman la solución actúan como un única instancia, si hay un fallo en cualquiera de ellos, la partición de datos que pudiese contener no estará disponible, por consiguiente, el sistema estará fuera de servicio en su totalidad. (según el documento de referencia, al no brindar tolerancia a fallos, esta solución no es recomendable y tendería a no ser considerada en el futuro).
  • Scale-out solution with high-availability capabilities.  Esta configuración incluye el concepto de nodos Standby, los cuales asumen la labor de cualquier nodo´que deje de funcionar, incluyendo el soporte de los datos de su partición.

Clusterización de un sistema SAP HANA (enfoque Scale-Out) con tolerancia a fallos (node04, nodo Standby)

Clusterización de un sistema SAP HANA (enfoque Scale-Out) el node03 falla, asume su rol el node04

Clusterización de un sistema SAP HANA (enfoque Scale-Out) el node03 es restituido, asumiendo el papel de nodo Standby

Referencia: IBM RedBooks (“In-memory Computing with SAP HANA on IBM eX5 Systems”)

La Escalabilidad en SAP HANA (III). Enfoque Scale-out, tipos de nodos

El enfoque Scale-up para escalar un sistema SAP HANA se basa en potenciar el servidor único que lo conforma. En cuanto al enfoque horizontal o Scale-out consiste en ampliar el número de hosts que conforman el sistema. Un Appliance SAP HANA puede incluir varios servidores para particionar los datos y facilitar el almacenamiento y procesamiento de grandes volúmenes de datos, muchos más de lo que se podría lograr con un sistema de un único servidor.


El enfoque Scale-up  para escalar un sistema SAP HANA se basa en potenciar el servidor único que lo conforma.   En cuanto al enfoque horizontal o Scale-out consiste en ampliar el número de hosts que conforman el sistema. Un Appliance SAP HANA puede incluir varios servidores para particionar los datos y facilitar el almacenamiento y procesamiento de grandes volúmenes de datos, muchos más de lo que se podría lograr con un sistema de un único servidor.

En un enfoque Scale Out, nos encontramos con conceptos tales como “nodo principal” (Master node), “nodos esclavos” (Slave nodes) o nodos en espera (Standby nodes), dependiendo de los usos que tenga nuestro Sistema SAP HANA, estos nodos cumplirán un papel u otro.

HANA BW Scale Out Concept, Setup with 1 TB Nodes

Por ejemplo en una instalación SAP NW BW powered on SAP HANA, los nodos maestros se encargarán de la carga del sistema, carga de datos transaccionales y sentencias DDL.  Los nodos esclavos aseguran un uso óptimo y balanceado de los recursos de memoria y CPU, para ello almacenarán parte (particionado de datos) o todo el contenido de los datos maestros, tablas de hechos u ODSs.  Los opcionales nodos Standby en un enfoque Sclae Out permanecerán a la espera para asumir el rol de un nodo maestro o esclavo.

Referencia: (aquí)

SAP, tengo una «sospecha», los Environments de BPC tienen limitaciones

Con las experiencias o padecimientos de los usuarios se logra la madurez de un producto, lo que se puede corregir el fabricante lo corrige y lo que no, se señala como restricciones, limitaciones o fuera de alcance. Hay muchos cambios que hemos visto en productos tan nuevos como SAP BusinessObjects BI 4.0 y SAP Business Planning and Consolidation (SAP BPC) 10.0


Con las experiencias o padecimientos de los usuarios se logra la madurez de un producto, lo que se puede corregir el fabricante lo corrige y lo que no, se señala como restricciones, limitaciones o fuera de alcance.  Hay muchos cambios que hemos visto en productos tan nuevos como SAP BusinessObjects BI 4.0 y SAP Business Planning and Consolidation (SAP BPC) 10.0, algunos cambios de funcionamiento y también advertencias y restricciones. Indudablemente estos cambios han sido gracias a los primeros usuarios que «descubrieron» alguna anomalía y lo comunicaron al equipo de soporte de SAP, que al final deriva en una nota para el resto de los usuarios.

En el caso de SAP BPC 10.0 NW, tenemos una «sospecha», nos referimos así porque no hay documentación o nota que niegue o afirme nuestra «hipótesis». Cuando trabajamos con SAP BPC NW por cada «Environment» (antes Application Set) se crea una InfoArea en SAP NW BW, en este espacio se van guardando la serie de objetos que vamos definiendo, necesarios para nuestros proyectos (dimensiones, modelos – cubos -, lógicas e inclusive ficheros temporales). Nuestra «sospecha» es que, al igual que otros objetos de BPC que se reflejan en BW, no pueden ser tratados del mismo modo.

Es decir, creemos que las InfoAreas creadas por la definición de un Environment de BPC tienen limitaciones, tales como la cantidad de objetos que puedan contener o inclusive, su origen, por ejemplo que no pueda contener cubos creados desde BW. Seguro que por el momento son muy pocos los que superen los 35 modelos en un Environment de BPC para que hasta la fecha no exista una nota con «restricciones» al respecto. Algunas veces no es necesario esperar una «comunicación oficial», si vemos los contratiempos, podemos actuar. La nota de referencia refuerza un poco nuestra sospecha.

Referencia: (aquí)

La Escalabilidad en SAP HANA (II). Enfoque Scale-up


La capacidad de ampliación Scale-up de un sistema SAP HANA, no tiene mayor complejidad, viene determinada por las configuraciones disponibles que ha definido SAP (SAP HANA T-shirt sizes) y los modelos que ofrece el partner de hardware de SAP HANA que se ha elegido.  SAP recomienda adquirir la máxima recomendación que nos puedan brindar las estimaciones de las herramientas de sizing (notas relacionadas al sizing: aquí, aquí y aquí)

SAP HANA T-shirt sizes and their relation to the IBM custom models

Por ejemplo, tomando como referencia la tabla anterior, para mejorar la capacidad de un appliance SAP HANA con una configuración “XS” a una configuración “S”, bastaría con incrementar la memoria principal a 128 GB.