Creación de entornos Hana robustos

Además del enfoque de implementación de dispositivos (caja negra) y la integración personalizada del centro de datos (TDI, Tailored Datacenter Integration), existen varias formas de diseñar la disponibilidad de un entorno Hana.

Estos, a su vez, están directamente influenciados por la propia arquitectura. Se hace una distinción básica entre la alta disponibilidad (HA) asíncrona o basada en almacenamiento y los mecanismos de HA síncrona que Hana DB proporciona de serie.

Además del modo "asíncrono", existen tres interpretaciones diferentes dentro de la HA síncrona: Sync, Sync-MEM y Full Sync. Mientras que el modo de sincronización estándar puede compararse con un método de "disparar y olvidar" para la instancia sombra, los otros dos mecanismos esperan a que el lado espejo haya escrito los comandos de la base de datos, ya sea en memoria, en modo completo o incluso en el almacenamiento.

Los mayores niveles de seguridad resultantes de la sincronización tienen el precio de una mayor dependencia y mayores requisitos de rendimiento en el sitio espejo. En el peor de los casos, con una sincronización total, un sitio espejo puede ralentizar o paralizar por completo el sitio de producción.

Dependiendo del nivel de HA deseado, el sitio espejo debe configurarse con el rendimiento adecuado para el sitio de producción. También existe la opción de conmutación por error en entornos scale-out para evitar fallos en los servidores.

Además, actualmente existen dos variantes de clúster a nivel de sistema operativo para complementar los métodos de sincronización del propio Hana. Manual (manual o basado en scripts) o totalmente automatizado con un marco de clúster (complemento de alta disponibilidad de Red Hat Enterprise Linux o extensión de Suse).

En consecuencia, la cuestión se plantea ya en la fase de arquitectura y diseño: ¿Quién lleva a cabo la toma de control (planificada o no)? ¿Es el administrador de la base de datos a nivel de Hana o el administrador de Linux en el Cluster Resource Manager (Pacemaker)? El administrador de SAP Basis también es necesario a más tardar para configurar la función de suspensión de DBSL.

En general, puede afirmarse que la mayoría de los clientes de SAP prefieren hoy claramente un entorno TDI a un appliance, por un lado para seguir utilizando las inversiones existentes y, por otro, para adaptar la arquitectura global de forma sólida y en función de sus necesidades.

En términos de arquitectura de HA, los puntos de vista son tan diferentes como los requisitos. En la mayoría de los casos, los escenarios de conmutación por error se complementan con el mecanismo de sincronización estándar para tomar precauciones a nivel de HW y SW.

Ciclo de vida de Hana y consecuencias

Debido al rápido desarrollo de la tecnología Hana, el ciclo de mantenimiento de SAP para un PLC sólo prevé nueve meses de soporte. Teniendo en cuenta que los DSP (Data Centre Service Points) solo deben utilizarse en entornos de producción (se lanzan aproximadamente cada seis meses), las ventanas de mantenimiento son muy ajustadas.

Especialmente si deduce una fase de prueba de uno a dos meses. Si además quieres instalar y operar Hana de forma independiente, necesitas al menos dos certificaciones Hana.

Sin embargo, la novedad es que estas certificaciones sólo son válidas para tres PLC, es decir, aprox. 3 x 6 meses. Actualmente sigue sin estar claro (consulta directa a SAP) a partir de cuándo es válida la certificación, es decir, en el momento de la certificación o en el momento de la liberación.

Independientemente de esto, actualmente los empleados deben volver a certificarse para Hana cada año y medio como máximo. Esto nunca ha sido así para el resto de BD aprobadas por SAP (AnyDB). Se plantea la cuestión de si se trata de un requisito necesario o sólo de una fuente adicional de ingresos para SAP.

¿Quién es responsable?

Como ya se ha mencionado, las arquitecturas de los TDI de Hana específicas para cada cliente plantean cuestiones de responsabilidad con respecto al funcionamiento, la supervisión y el mantenimiento. ¿Qué departamento es responsable de qué en el Hana TDI? ¿Insourcing, externalización/nube o servicios gestionados?

Para muchos clientes, esto se redefine con la introducción de Hana. En este caso, es aconsejable utilizar un SLA de Hana para crear una matriz RACI que determine qué tareas se implementan y de cuáles es responsable el administrador de Linux, HDB o SAP Basis.

Esto también se puede utilizar para determinar los requisitos de abastecimiento y formación con poco esfuerzo. También hay que mencionar que un sistema de alertas sensato integrado en Hana solo está disponible actualmente a través de Solution Manager.

Otro punto importante es Hana Housekeeping. El catálogo de copias de seguridad contiene todos los datos importantes y las copias de seguridad de registro y se copia con cada copia de seguridad. Este debe ser limpiado cíclicamente, ya que no existe una función automatizada para esto en Hana.

Conclusión

Desde el punto de vista tecnológico, puede decirse que Hana se encuentra todavía en una curva de desarrollo pronunciada y dinámica. Es aconsejable prepararse a largo plazo, tanto desde el punto de vista arquitectónico como organizativo, para beneficiarse de las innovaciones y establecer la tecnología Hana como una competencia básica dentro de su propia empresa.

Esto también incluye la comprobación y el escaneo con visión de futuro de los componentes ERP existentes en dirección a S/4 Hana utilizando el informe R_S4_PRE_TRANSITION_CHECKS (nota 2182725), que debe comprobar los sistemas SAP existentes en dirección a la preparación para S/4 Hana durante aproximadamente un año.

Hana y no ERP

"Debería ser comparativamente difícil para esto"

dice Matthias Kneissl.

"Por supuesto, con la pila Hana, SAP también proporciona una solución que puede competir con creces con un JBoss.

Sin embargo, también está la cuestión de los precios y las licencias. Además, los desarrolladores clásicos de Java Enterprise están acostumbrados a sus respectivos stacks, por lo que será difícil desbancar a los conocidos candidatos JBoss o WebSphere.

Para que un cliente cambie la pila -lo que es mucho más complicado en el entorno J2EE que en el mundo SAP, donde la migración OS/DB es posible con herramientas estándar- debe obtener beneficios claros de ello.

Las bibliotecas para la búsqueda de texto y la lógica difusa son ciertamente magníficas, pero en nuestra opinión SAP aún no las está comercializando con suficiente fuerza en la comunidad. Además, SAP es también un actor nuevo y en gran medida desconocido en la comunidad Java".

Guido Hoepfner añade que los clientes de Q-Partners están innovando en el ámbito de las soluciones móviles, utilizando aplicaciones Fiori y desarrollando sus propias aplicaciones basadas en SAPUI5.

"En el ámbito de la tecnología, un gran número de nuestros clientes están realmente interesados en SAP Hana y actualmente estamos llevando a cabo diversas conversiones de soluciones existentes a Hana"

informa desde su práctica profesional.

"Una vez sentadas estas bases, se dan las condiciones para la innovación en las aplicaciones. Es una evolución que vemos venir. El primer paso lógico es el cambio técnico basado en SAP a la nueva plataforma".

Los retos residen sobre todo en la integración de los nuevos modelos de programación, tecnologías y arquitecturas. Históricamente, en Abap puede utilizarse tanto la programación estructural orientada a objetos como la históricamente no orientada a objetos.

"Esto sigue siendo habitual en los informes actuales y a veces tiene sentido"

subraya Kneissl.

Con la nueva tecnología en la dirección de Hana, SAPUI5 y NetWeaver Gateway, tienes que moverte mucho más en la dirección de la orientación a objetos.

"Esto es especialmente importante para que los usuarios puedan utilizar las nuevas tecnologías con sensatez y beneficiarse también de sus ventajas. Por supuesto, se trata de un cambio significativo del que el usuario no se dará cuenta de la noche a la mañana. La situación es similar en el ámbito de la tecnología".

añade Hoepfner.