HANA – Página 18 – aníbal goicochea

Consideraciones para el despliegue de más de una base de datos SAP HANA

Con el término SAP HANA Appliance se hace referencia a un servidor o un sistema SAP HANA el cual puede estar compuesto por un único nodo o por un conjunto (cluster) de nodos (arquitectura con escalabilidad horizontal o sclae-out) dónde en al menos un nodo reside la base de datos SAP HANA y los componentes del sistema.

Con el término SAP HANA Appliance se hace referencia a un servidor o un sistema SAP HANA el cual puede estar compuesto por un único nodo o por un conjunto (cluster) de nodos (arquitectura con escalabilidad horizontal o sclae-out) dónde en al menos un nodo reside la base de datos SAP HANA y los componentes del sistema.

Hace unos días leíamos un listado de acrónimos y términos vinculados al mundo SAP HANA, una buena referencia, pero faltaría considerar otros como MCOS que corresponden a las iniciales de “Multiple Components One System” que describen la arquitectura de múltiple nodo que se señala en el párrafo anterior. Otro término que también se utiliza en el contexto SAP HANA es “Multi-SID” o MSID (Multiple Database on one SAP HANA appliance) que hace referencia a la posibilidad de configurar más de una base de datos en un sistema SAP HANA.

Cabe recordar que en un entorno productivo HANA sólo tendrá soporte si tiene una única base de datos en el sistema (SIDS). Es posible tener más de una base de datos HANA, pero sólo debería ser considerado en entornos que no son con fines de producción, tales como los clásicos entornos de pruebas o desarrollo. Esta consideración se aplica tanto si se trata de una arquitectura de un nodo o multinodo.

Un appliance HANA, recién entregada por los partners de hardware, lo encontraremos con una base de datos SAP HANA, usando “On-Site Configuration tool” se podrá configurar una base de datos adicional, para lo cual deberá considerar lo siguiente:

No debería realizarse en un entorno productivo.
Se debería contar con la configuración de hardware necesaria para soportar el despliegue de más de una base de datos (especialmente en cuanto a memoria).
Se debe tener en cuenta que se puede perder rendimiento o velocidad en la ejecución de varios procesos.
Si hubiera problemas en el sistema y se solicitará el servicio de soporte de SAP, podría indicarse detener las bases de datos para comprobar si el problema es originado por la configuración de las bases de datos adicionales.
Para más información y futuras novedades revisar las notas 1681092 y 1661202.

Opciones de instalación de «SAP LT Replication Server»

SAP LT Replication Server (LT = Landscape Transformation) es la tecnología para replicar en sistemas SAP HANA información provenientes de fuentes de datos SAP y no-SAP. Los servidores SAP LT Replication identifican los cambios en las bases de datos origen a través de disparadores (triggers) para luego llevarla a SAP HA Database con la frecuencia definida.

SAP LT Replication Server (LT = Landscape Transformation) es la tecnología para replicar en sistemas SAP HANA información provenientes de fuentes de datos SAP y no-SAP. Los servidores SAP LT Replication identifican los cambios en las bases de datos origen a través de disparadores (triggers) para luego llevarla a SAP HA Database con la frecuencia definida.

Dependiendo del tipo de la fuente de datos y de la configuración de los sistemas, se optará por un tipo u otro tipo de despliegue:

Un servidor dedicado (Para fuentes de datos SAP. Enfoque de 3 capas). Necesario en los casos que el sistema SAP origen no se ajuste a los requerimientos básicos de nivel de actualización de SAP Netweaver y SAP Kernel. Lo positivo: Mayor flexibilidad en el despliegue al no existir dependencia del mantenimiento del software. Lo negativo: Inversión y manteamiento en una nueva instancia de servidor NW.

Instalación en el sistema origen (Para fuentes de datos SAP. enfoque 2 capas). Opción posible si los sistemas están alineados con el nivel de actualización requerido. Positivo: Mínima inversión y lo Negativo: Podría haber un menor rendimiento con relación a la opción anterior y habría una dependencia en el mantenimiento del software el cual debería ir alineado entre los sistemas fuentes y el servidor de SAP LT Replication.

Instalación para fuentes de datos no-SAP. En estos casos se requiere un servidor dedicado de SAP LT Replication.

Referencia: Doc. SAP HANA

«Datos no-activos» de «SAP BW on SAP HANA»

El concepto de datos no activos (non-active data concept) que se aplica en SAP NW BW powered by SAP HANA (BW on SAP HANA) nace de la característica común que podemos encontrar en cualquier repositorio de datos o data warehouse: los datos históricos que pueden contener, los cuales pueden ser de gran volumen y suelen tener un uso ocasional.

El concepto de datos no activos (non-active data concept) que se aplica en SAP NW BW powered by SAP HANA (BW on SAP HANA) nace de la característica común que podemos encontrar en cualquier repositorio de datos o data warehouse: los datos históricos que pueden contener, los cuales pueden ser de gran volumen y suelen tener un uso ocasional.

Identificando y gestionando adecuadamente los datos históricos con los que se cuenta, se puede hacer un uso más eficiente de la memoria principal, permitiendo que se cargue en ella los datos que requieran los usuarios en el momento que sea necesario. Inclusive para las tareas de estimaciones de las necesidades de recursos de hardware (sizing), la correcta aplicación de este concepto puede tener impacto en una menor necesidad de memoria principal (nota 1736976).

Al igual que todo lo que concierne a SAP HANA, el concepto de datos no-activos es relativamente muy nuevo, por lo que SAP prevé ampliar el alcance y funcionamiento de esta técnica para hacer un uso más óptimo de la memoria.

Referencia: Nota SAP 1767880

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 (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-).

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

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.