In-memory computing – Página 16

Consideraciones básicas para el despliegue de “BW on HANA” (I)

Complementando la entrada anterior, si contáramos con SAP Netweaver BW powered by SAP HANA” (BW on HANA ) se debería considerar los siguientes aspectos al planificar su configuración:

Complementando la entrada anterior, si contáramos con SAP Netweaver BW powered by SAP HANA (BW on HANA ) se debería considerar los siguientes aspectos al planificar su configuración:

SAP no da soporte al despliegue de múltiples sistemas SAP NW BW en un sistema productivo SAP HANA.
SAP brinda soporte al despliegue de múltiples sistemas SAP NW BW on HANA en arquitecturas de nodo único o multinodo con fines distintos a un entorno productivo, con una base de datos por cada sistema SAP NW BW.
El servidor de base de datos de un sistema BW es desplegado en un esquema de la base de datos SAP HANA. La instancia central del sistema BW y todas las aplicaciones de servidor asociadas no se instalan en el appliance SAP HANA, son instalados en un servidor aparte.
Con respecto al párrafo anterior, existen “excepciones” señaladas en la nota 1661202 que permiten aplicaciones residan en el sistema SAP HANA en un entorno productivo. Si una aplicación que no figura en el listado de excepciones es instalada en BW on HANA en un entorno productivo, esta aplicación no tendría soporte por parte de SAP. En un entono distinto a producción si tendría soporte.
BW on HANA permite la aplicación de técnicas de alta disponibilidad (High Availability – HA) y tolerancia a fallos (Disaster Tolerance – DT). En cuanto a HA sigue los mismos mecanismos que un sistema SAP HANA, a través de la activación de nodos pasivos. En general, especialmente en los casos de DT, estas técnicas pueden variar en función del proveedor de Hardware.
Las técnicas que se aplican en un sistema SAP HANA para evitar que los datos en memoria se pierdan ante un fallo en el servicio eléctrico también incluye los datos de BW on HANA.
Es recomendable tener por los menos tres nodos en un sistema SAP HANA en el que se despliegue BW on HANA. En el nodo principal estarían las tablas con almacenamiento basado en filas y en lo nodos esclavos se tendría las particiones de los infocubos y ODSs (Ref. nota 1702409).
Para información adicional y futuras novedades sobre los aspectos comentados en esta entrada revisar las notas 1666670 y 1661202.

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.

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