In-memory computing – Página 9

Gestión de datos “no-activos” en BW on HANA

La inmediatez de respuesta de SAP HANA es debido, entre otras cosas, porque los datos que podrían ser procesados son cargados en memoria, evitando el acceso a dispositivos electromecánicos como pueden ser los discos. Pero no todos los datos que tiene una organización son necesarios en las tareas habituales, en muchos casos se conserva información histórica por motivos legales o por políticas internas, e inclusive puede haber datos operativos temporales con ninguna utilidad para las tareas de análisis.

La inmediatez de respuesta de SAP HANA es debido, entre otras cosas, porque los datos que podrían ser procesados son cargados en memoria, evitando el acceso a dispositivos electromecánicos, como pueden ser los discos, cada vez que se requieran. Pero no todos los datos que pueda tener una organización son necesarios en las tareas habituales, en muchos casos, se conserva información histórica por motivos legales o por políticas internas, e inclusive puede haber datos operativos temporales con ninguna utilidad para las tareas de análisis.

Cargar todos los datos que podría tener SAP NetWeaver BW on SAP HANA podría originar problemas de rendimiento o cuellos de botella. A través de la identificación de los denominados “datos no-activos” se puede configurar la información que se cargará en memoria, inclusive se puede detallar a nivel de columna de lastablas de datos, para lograr un mayor rendimiento de la plataforma.

SAP ofrece un monitor que clasifica la información según el tipo de objeto BW que la contiene y la frecuencia de acceso, lo que facilitaría las tareas de identificación de los «datos no activos» para evitar que consuman memoria innecesariamente. Para mayor información consultar las notas SAP 1767880 y 1741844.

“Rapid database migration of SAP NetWeaver Business Warehouse to SAP HANA”

El Rapid Deployment Solutions de SAP (RDS) para cambiar la base de datos relacional de un sistemas SAP NW BW por una base de datos SAP HANA se denomina “Rapid database migration of SAP NetWeaver Business Warehouse to SAP HANA”. Como todo RDS, se ofrece la aplicación de buenas prácticas para minimizar el riesgo y asegurar el éxito del proyecto de migración.

El Rapid Deployment Solutions de SAP (RDS) para cambiar la base de datos relacional de un sistemas SAP NW BW por una base de datos SAP HANA se denomina “Rapid database migration of SAP NetWeaver Business Warehouse to SAP HANA”. Como todo RDS, se ofrece la aplicación de buenas prácticas para minimizar el riesgo y asegurar el éxito del proyecto de migración.

Con el fin de eliminar los riesgos y minimizar los tiempos de inoperatividad de los sistemas, este RDS evita los procesos manuales, lo que se traduce en una migración sencilla con la menor interrupción a los usuarios de negocio. . Para este fin, se valoran dos posibles escenarios:

Direct Migration (In-place migration). El sistema actual es migrado directamente para la nueva base de datos y el nuevo sistema reemplaza al anterior.
New system and transportation (Copy, upgrade and migrate). Un nuevo sistema SAP NW BW es configurado con HANA Database. Los datos y demás elementos del sistema anterior son transportados o reconstruidos en el nuevo sistema.

La fórmula seleccionada dependerá del volumen de datos o de las necesidades de rediseño de las estructuras de datos, necesidad de definir fases o la inmediatez con la que se requiera ejecutar estas tareas. Pero por la parametrización que pudiese tener un sistema fuente, la opción que incluye la copia previa puede ser la alternativa más recomendada

SAP HANA Tailored Data Center Integration (SAP HANA TDI)

SAP HANA TDI (SAP HANA Tailored Data Center Integration) es la tercera vía para desplegar una plataforma SAP HANA, las otras alternativas son a través de un appliance certificado y la opción Cloud. El principal cuestionamiento que se le ha señalado a SAP HANA, desde sus inicios, es el costo elevado que puede llegar a alcanzar un appliance y la poca flexibilidad en la elección de la configuración de hardware que se debe utilizar (aquí listas de partners de hardware SAP HANA).

SAP HANA TDI (SAP HANA Tailored Data Center Integration) es la tercera vía para desplegar una plataforma SAP HANA, las otras alternativas son a través de un appliance certificado y la opción Cloud. El principal cuestionamiento que se le ha señalado a SAP HANA, desde sus inicios, es el costo elevado que puede llegar a alcanzar un appliance y la poca flexibilidad en la elección de la configuración de hardware que se debe utilizar (aquí listas de partners de hardware SAP HANA).

SAP HANA TDI es el concepto introducido por SAP a mediados del pasado año, el cual se base en la ampliación de las posibilidades de elección del hardware y configuración que se podría utilizar en una plataforma HANA. La mayor flexibilidad y seguro que menor coste, son los principales beneficios de esta nueva opción con respecto a un appliance, el cual tiene como ventajas el software pre-instalado y el hardware configurado.

Con respecto a un Appliance, SAP HANA TDI ofrece mayor facilidad para la ampliación del espacio de almacenamiento (denominado “Enterprise Storage” en la variante TDI). Para verificar que una plataforma SAP HANA TDI cumple las especificaciones de configuración HANA, se cuenta con una herramienta denominada SAP HANA hardware configuration check tool. SAP actualiza constantemente el listado de hardware compatible para SAP HANA (aquí).

SAP HANA Tailored DataCenter Integration es una alternativa que irá madurando en los próximos meses, y a la que auguramos un buen futuro. SAP HANA TDI, al brindar la posibilidad de utilizar las inversiones actuales de hardware que podría tener una organización, la convertirá en el principal mecanismo para que SAP HANA sea adoptada por más empresas, algunas veces, poco partidarias de realizar inversiones en hardware específicos que establece un fabricante de software, más propio de décadas pasadas.

Referencia: (aquí y aquí)

Información para virtualizar SAP HANA con VMware

Desde la actualización SPS05 un sistema SAP HANA puede ser virtualizado con VMware VSphere 5.1 (o versiones superiores) con la finalidad de facilitar la implementación de una política de entornos (p.e.: desarrollo, pruebas y producción). SAP HANA on VMware vSphere, no implica la asquisición de una licencia adicional, sólo es necesario contar con las versiones adecuadas de ambos sistemas, el cual sólo puede ser configurado, por el momento, sobre un appliance SAP HANA.

Desde la actualización SPS05 un sistema SAP HANA puede ser virtualizado con VMware VSphere 5.1 (o versiones superiores) con la finalidad de facilitar la implementación de una política de entornos (p.e.: desarrollo, pruebas y producción). SAP HANA on VMware vSphere, no implica la asquisición de una licencia adicional, sólo es necesario contar con las versiones adecuadas de ambos sistemas, el cual sólo puede ser configurado, por el momento, sobre un appliance SAP HANA.

Las diferencias de rendimiento entre un sistema HANA sobre un hardware certificado (“bare metal”) y un sistema virtualizado, dependiendo de los tipos de procesos que se ejecuten, pueden ser muy importantes, por lo que se establece que un entorno virtualizado debería tener cualquier uso, menos los propios de un entorno de Producción.

Adicionalmente, destacamos los siguientes aspectos:

Un entorno virtualizado SAP HANA sólo puede ser de un único nodo, por lo que configuraciones “scale out” o “multi-nodo” no son soportadas.
En cuanto a la configuración de CPU y memoria debe ser de acuerdo a las medidas estándar definidas para un appliance HANA (t-shirt sizing).
El soporte a los entorno virtualizados HANA puede ser brindando tanto por SAP como por VMware, según el tipo de incidencia, siempre y cuando no se trata de un entorno de Producción.
Absolutamente todas las aplicaciones que funcionan sobre un appliance SAP HANA funcionarán sobre un sistema virtual SAP HANA.
El modo de realizar las tareas de diseño o modelado de datos será exactamente igual en ambos tipos de instalación.
Estas características, posibilidades o limitaciones pueden variar en el tiempo por lo que se recomienda consultar la nota SAP de referencia.

Referencia: SAP Note 1788665

«Code pushdown» clave en el rendimineto SAP HANA

Los grandes beneficios de SAP HANA se encuentran en el procesamiento de grandes volúmenes de información, no tan sólo por tener los datos en memoria (además del almacenamiento físico en disco), sino también por la aplicación de técnicas, que en su conjunto, constituyen un nuevo paradigma en el concepto de base de datos.

Los grandes beneficios de SAP HANA se encuentran en el procesamiento de grandes volúmenes de información, no tan sólo por tener los datos en memoria (además del almacenamiento físico en disco), sino también por la aplicación de técnicas, que en su conjunto, constituyen un nuevo paradigma en el concepto de base de datos.

Uno de los cambios planteados por HANA es el procesamiento de datos en la capa de base de datos (code pushdown). Los sistemas tradicionales se basan en el principio denominado Data-to-code, el cual ejecuta todo el procesamiento de datos en la capa de aplicación, generando un tráfico de datos elevado que ocasiona bajos niveles de rendimiento e incremento de los tiempos de latencia o espera hasta ver los resultados.

Una aplicación diseñada o adaptada para una plataforma SAP HANA utiliza el principio Code-to-Data, el cual procesa los datos en la capa de base de datos, quedando la capa de aplicación sólo para controlar el flujo del procesamiento y tratar los datos procesados (Orchestration logic).