Etiqueta: HANA

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.

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í)

Escalabilidad es la capacidad que tiene un sistema para gestionar una cantidad creciente de tareas o su capacidad para ser ampliado para ajustarse a ese crecimiento.  Un sistema cuyo rendimiento mejora después de la adición de hardware, proporcionalmente a la capacidad añadida, se dice que es un sistema escalable, por otro lado, si el sistema falla después de este incremento de hardware, esto significa que no es un sistema escalable (Referencia).  

En SAP HANA, al igual que en otras arquitecturas, la escalabilidad tiene dos enfoques o criterios:

• Escalabilidad vertical (scale up): Consiste en incrementar los recursos de un único nodo del sistema, por ejemplo, la cantidad de memoria RAM.
• Escalabilidad horizontal (scale out): También llamado “sistema distribuido”, consiste en agregar más nodos a un sistema, para que trabajen como uno sólo (cluster).

Ninguna de las dos estrategias es mejor que la otra, ambas obedecen a necesidades o circunstancias distintas.  Por ejemplo, para aumentar la capacidad de procesamiento puede ser necesario ampliar la memoria RAM (scale up) o para  mejorar la eficiencia de procesamiento podría ser necesario distribuir la capacidad de procesamiento en más de un host (scale out), complementando esta medida con acciones tales como el particionado de las tablas o la distribución de las tablas de datos entre los hosts que conforman el sistema.

Referencia: Documentación SAP

Contar con más de un Appliance SAP HANA para desplegar una arquitectura clásica de tres ambientes o entornos, tales como “Desarrollo”, “Integración” y Producción”, sería una “locura millonaria” imposible de aplicar.  En principio, un Sistema SAP HANA es desarrollo y producción, para este doble papel se han barajado varias “soluciones”, teniendo en el horizonte la promesa de SAP de brindar mejores mecanismos para definir una estrategia de entornos como se desarrolla con otras arquitecturas.

Hasta la fecha, los “mecanismos” que ha ofrecido SAP, para este fin, han sido algo complejos y podrían afectar el rendimiento del sistema.  Nos referimos a soluciones como la creación de una segunda base de datos o el uso SAP HANA One de Amazon Web Services para cubrir las necesidades de un entorno de desarrollo.

La alternativa que nos parece más “limpia” y segura es la que consiste en la creación de entornos virtualizados con VMware vSphere sobre un Appliance SAP HANA, al cual se le asignaría una porción (balanceada) de CPU y memoria para su configuración.  Por el momento, esta solución es posible sólo en despliegues mono-nodo y aplicable con fines distintos a un entorno de producción.

Referencia: Alternativa VMWare (aquí y aquí) Otras alternativas (aquí y aquí)