SAP HANA está transformando la forma como las empresas compiten permitiéndoles recopilar, almacenar y analizar grandes volúmenes de información en tiempo real. Pero contar con una solución poderosa como SAP HANA no es suficiente para generar ventajas competitivas actualmente. También es fundamental ¬que las soluciones residan en una infraestructura que asegure el nivel de alta disponibilidad (HA) que requiere un ambiente de aplicaciones SAP complejas e interconectadas. Lógicamente, a medida que aumenta la información creada y almacenada también crece la necesidad de protegerla en caso de una interrupción.
De acuerdo con informes del Gartner Group, la causa principal de interrupciones tanto planificadas como no planificadas no está relacionada con fallas de hardware, cortes de electricidad o desastres naturales. En el caso de interrupciones no planificadas, 80% (cuatro de cada cinco) son causadas por error humano y problemas con procesos en las áreas de redes o almacenamiento, fallo de las aplicaciones y errores operativos. ¿El costo financiero de esas interrupciones? Aproximadamente $25,000 por hora para 29.3% de las empresas, cualquiera sea su tamaño.1 Obviamente, en el caso de las empresas más grandes donde el impacto financiero podría ser mucho mayor, los costos en la productividad y la reputación de la organización también entran en juego.
Un concepto erróneo es pensar que al instalar SAP HANA ya se tiene la protección necesaria porque la base en memoria tiene su propia persistencia, capturas, e incluso SAP HANA System Replication (SHSR). Esta falsa seguridad de protección hará que más de uno tenga dolores de cabeza al descubrir, por ejemplo, que si bien SHR es el método preferido de replicación nativo de SAP HANA aún se requiere un método de automatización de alta disponibilidad para que el nodo replicado garantice la accesibilidad del sistema.
¿Cómo se mide la fiabilidad de un sistema?
Hay dos parámetros clave a tener en cuenta: el punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO).
El RPO es el nivel máximo permisible de pérdida de datos introducidos desde el último backup, hasta la caída del sistema. El RTO es la mayor cantidad de tiempo permitido entre cuando ocurre un incidente y cuando todos los sistemas vuelven a la normalidad.
La idea es tener una infraestructura que ayude a reducir tanto el RPO como el RTO. Afortunadamente, HPE puede proporcionar la infraestructura necesaria para lograr niveles de tiempo de inactividad "casi cero" en una implementación de SAP HANA. Es justamente allí donde HPE Serviceguard para Linux (SGXL) hace una diferencia significativa en comparación a otras soluciones en el mercado.
SGLX garantiza la disponibilidad de las aplicaciones 24x7, se integra “out-of-the-box” con SAP y SAP HANA a través de su correspondiente extensión, soporta todos los modos de replicación de SAP HANA (asincrónico, sincrónico en memoria y sincrónico) y es capaz de lograr una recuperación hasta 20 veces más rápida ante una falla de la base de datos SAP HANA.
La edición Premium de HPE Serviceguard para Linux, una mejora agregada en 2021, es la primera solución de alta disponibilidad (HA) y de recuperación ante desastres en la industria2 completamente automática que aprovecha la replicación del sistema SAP HANA Multi-target para proporcionar recuperación desatendida en varios niveles de SAP HANA.
La integración de aplicaciones con SAP HANA y asegurar una eficiente interoperabilidad al mismo tiempo no es tarea fácil. SGLX simplifica y acelera enormemente la integración con una aplicación compleja como SAP HANA en un marco estandarizado y probado. El nivel de integración es tal, que hace posible RTOs iguales a cero y RPOs en el orden de segundos (en lugar de minutos) en entornos físicos y virtuales, a cualquier distancia y con ancho de banda restringido sin comprometer la integridad de los datos.
¿Por qué es necesario un árbitro independiente?
El arbitraje de clústeres es esencial para garantizar el más alto nivel de disponibilidad e integridad de datos, evitando una situación de cerebro dividido o split-brain, que se produce cuando cada miembro del clúster asume que el otro está imposibilitado de proveer servicio, cada uno haciéndose cargo de los recursos mientras trata de convertirse en el nodo primario, lo que lleva a la inconsistencia de datos.
La función Smart Quorum de SGLX actúa como un árbitro independiente y resuelve la partición: si los grupos de nodos de igual tamaño deben estar separados entre sí, el servidor de quórum permite que un grupo logre el quórum y forme el clúster, mientras que al otro grupo se le niega el quórum y no puede iniciar un clúster.
A diferencia de los métodos de toma de decisiones para cerebro dividido que se basan simplemente en el número de nodos sobrevivientes disponibles o que usan el método llamado STONITH (Shoot The Other Node In The Head), el SGLX Smart Quorum realiza conmutaciones por error de recuperación ante desastres (DR) automáticas que funcionan de manera confiable en coexistencia con la solución de conmutación por error automática de SAP HANA.
Otras funciones únicas de HPE Serviceguard para Linux son:
- Los bloques Safesync que maximizan la protección y aseguran la consistencia de los datos.
- La suspensión momentánea de la base de datos, la cual a través de un cierre normal de SAP HANA reduce o elimina los tiempos de baja planificada por mantenimiento.
- La redundancia mejorada extendida a través de múltiples niveles de HANA y la capacidad de implementar hasta tres instancias en espera en un solo clúster de SGLX.
Administración simplificada y bajo costo de propiedad
Una pregunta frecuente que hacen los CIO, CFO e incluso los CEO cuando investigan soluciones de HA y DR es cuál es el costo total de propiedad (TCO) de un software que monitoree continuamente el estado de la infraestructura del negocio. HPE SGLX brinda el equilibrio correcto entre asequibilidad, alta disponibilidad, fiabilidad y opciones flexibles que se adaptan a los ciclos de vida de los sistemas de cada negocio. Tener la posibilidad de escoger entre una licencia de un año, tres años o perpetua (o incluirla en el proyecto de SAP HANA bajo modelo de consumo con Greenlake) contribuye significativamente a la disminución del TCO.
En HPE entendemos que tener opciones como éstas hacen una diferencia en la toma de decisiones. Nuestro compromiso, cualquiera sea el desafío, es ayudar a nuestros clientes a navegar la mejor ruta en una implementación de SAP y SAP HANA.
Karina Paez
Hewlett Packard Enterprise
linkedin.com/company/hewlett-packard-enterprise
hpe.com/lamerica/es/
_________________
1 Fuente: IDC, mayo de 2019. ¿Cuáles son algunas de las principales causas del tiempo de inactividad de las aplicaciones? ¿Cuánto cuesta a las empresas el tiempo de inactividad de las aplicaciones? | Mayo 2019. Basado en datos de la encuesta de disponibilidad de infraestructura de almacenamiento y servidores, IDC, diciembre de 2018
2 Fuente: Información interna de HPE. A la fecha (abril 2021) ninguna otra solución comparable ofrece esta capacidad
Relacionado: ESG-Solution Showcase | HPE: Tiempo de inactividad casi cero para SAP HANA[Disponible únicamente en inglés]
KarinaP
Karina has been in HPE Presales for 16 years working with Workload Solutions; although she covers the entire portfolio and a variety of implementations she specializes in SAP, SAP HANA and Mission Critical Solutions. She has 23 years of experience in IT and is passionate about helping customers and making and impact. // Karina ha estado en Preventas de HPE por 16 años trabajando con Workload Solutions; aunque cubre todo el portafolio y una variedad de implementaciones, se especializa en SAP, SAP HANA y Mission Critical Solutions. Tiene 23 años de experiencia en IT y le apasiona ayudar y generar un impacto en los clientes.
