Configuración de S/4 HANA en alta disponibilidad con AWS Launch Wizard y pruebas del despliegue

Por: Manuel Cuellar, Arquitecto de Soluciones para Amazon Web Services en Sector Público.

Los aplicativos de SAP son una parte vital de las empresas para operar correctamente sus negocios, diferentes operaciones críticas tales cómo procesos de manufactura, logística, compras, ventas y servicio al cliente dependen en gran manera de ellos. Por esta razón la Alta Disponibilidad se ha convertido en la preocupación principal de los altos mandos de las empresas cuando se discute la infraestructura de los sistemas SAP.

En este blog se describe el procedimiento para utilizar el servicio AWS Launch Wizard para desplegar ambientes SAP en alta disponibilidad y realizar pruebas de disponibilidad para corroborar que funciona de manera adecuada.

AWS Launch Wizard es un servicio que provee al usuario final de una guía para configurar y desplegar Aplicativos SAP en Amazon Web Services, siguiendo las mejores prácticas de implementación recomendadas por SAP y AWS.

Launch Wizard de AWS automatiza la instalación de los ambientes SAP en AWS, con base en el servicio de Cloud Formation, permitiendo introducir parámetros de configuración del aplicativo, incluidos los de base de datos SAP HANA, el aplicativo de SAP y los detalles generales del despliegue; una vez ingresada la información, Launch Wizard automáticamente identifica los recursos de AWS necesarios para ejecutar correctamente la solución. Ademas de esto, previo al despliegue, muestra un estimado de la configuración de instancias seleccionadas. Launch Wizard finalmente despliega los recursos e instala SAP HANA en conjunto con las aplicaciones seleccionadas.

AWS Launch Wizard actualmente soporta el despliegue de recursos de AWS para los siguientes escenarios SAP:

Base de Datos SAP HANA en una instancia Amazon EC2 individual
SAP Netweaver en un sistema SAP HANA en una instancia Amazon EC2 individual
Base de datos SAP HANA en múltiples instancias de Amazon Ec2
SAP Netweaver en múltiples instancias Amazon EC2
Despliegue en Alta Disponibilidad de SAP HANA en múltiples zonas de disponibilidad
SAP Netweaver en múltiples zonas de disponibilidad
Despliegue de cluster SUSE/RHEL para SAP HANA y Netweaver/S4 en despliegues de HANA en Alta Disponibilidad

El último escenario del listado anterior integra el despliegue de un ambiente en Alta Disponibilidad de HANA, mediante la creación de un cluster de SUSE en los servidores de SAP HANA, ademas de la instalación de S4/HANA..

El diagrama de la infraestructura desplegada por Launch Wizard en AWS para este escenario se muestra a continuación:

Figura 1. Arquitectura desplegada por Launch Wizard

A alto nivel, este despliegue consiste en implementar un Servidor Bastion (Bastion Host), junto con un NAT Gateway en una red pública. El Bastion Host permite tráfico externo con propósito de administración de forma segura a los componentes internos, mientras que el NAT Gateway permite que los servicios privados inicien tráfico a Internet en caso de ser necesario. Se despliegan además, 2 redes privadas, en diferentes Zonas de Disponibilidad, que incluyen los servicios Centrales de SAP; mas abajo, una segunda capa de 2 redes privadas adicionales en las cuales se despliegan los servidores de base de datos en distintas zonas de disponibilidad, asegurando resiliencia.

En general los servicios de AWS que se despliegan, son los siguientes:

Amazon Virtual Private Cloud (VPC) – Servicio que permite desplegar recursos de AWS en una red lógica privada.
Internet Gateway – Componente que permite la comunicación de los servicios dentro del VPC hacia el internet
Public Subnet – Los servicios desplegados en esta subred tienen conexión directa al Internet
Private Subnet – Contrario a las Subredes Públicas, los componentes de esta subred no pueden ser accesados públicamente
NAT Gateway – Permite a los servicios creados en una red privada iniciar tráfico hacia internet, sin ser públicos
Amazon Elastic Compute Cloud (Amazon EC2)– Servicio web que provee de capacidad de cómputo en la nube
- Bastion Host – Servidor con acceso público restringido qué, a su vez, permite acceso a servicios en redes privadas
- App Server – Servidor de aplicaciones de productos SAP
- Central Services Server (ASCS) – Servidor de mensajería del sistema SAP
- Enqueue Replication Server (ERS) – Servidor de réplica de encolamiento del sistema SAP.
- DataBase Servers – Servidores con la base de datos SAP HANA

La implementación de la solución, descrita en la sección anterior, se realiza mediante plantillas de AWS Cloudformation, creadas y administradas por Amazon Web Services. Estas plantillas utilizan como insumo los parámetros definidos por el usuario en la consola de Launch Wizard; las siguientes imágenes corresponden al paso final de Launch Wizard y muestran la configuración del ambiente representado en el diagrama de la Figura 1:

Figura 2. Configuración de la infraestructura en AWS

Figura 3. Configuración del Aplicativo y Modelo de Despligue de SAP

Figura 4. Repositorio de Instaladores SAP

Posterior al despliegue de los servicios de AWS, AWS Launch Wizard ejecuta la configuración de componentes, la cual consiste en los siguientes pasos:

Configuración de Sistema Operativo
Instalación de la Base de datos SAP HANA
Configuración de SAP HANA System Replication

Setup de Providers de SAP HANA/DR
Configuración del Cluster de SUSE

TIP: Para asegurar que esta implementación sea funcional, es indispensable utilizar, ya sea, SUSE for SAP Applications o Red Hat Enterprise Linux for SAP específicamente, dado que los medios de instalación de estas distribuciones incluyen las extensiones necesarias para la configuración de un cluster para la Alta Disponibilidad.

Configuración de SAP HANA System Replication y Provider de SAP HANA/DR

La base de la Alta Disponibilidad y a su vez, la estabilidad del sistema SAP dependen de dos componentes específicos:

SAP HANA System Replication (HSR), el cuál se encarga de que los componentes de SAP HANA se mantengan en el mismo estado en todos los nodos miembros del cluster
Los llamados «hooks» o provider’s de HA / DR se pueden utilizar para operaciones arbitrarias que deben ejecutarse durante un Failover. Uno de los usos más importantes de los hooks de error, es mover una dirección IP virtual. Existen otros propósitos como iniciar herramientas y aplicaciones en ciertos hosts después del Failover o incluso detener instancias DEV o QA SAP HANA en sitios secundarios antes de la toma de control de las instancias EC2.

A continuación se detalla la configuración y funcionamiento de los componentes mencionados:

**NOTA: La configuración se realiza de forma automática por AWS Launch Wizard

a. SAP HANA System Replication

Mecanismo nativo de SAP HANA que asegura la sincronización de datos en el sistema; es recomendado para minimizar afectaciones por mantenimientos, fallas o desastres. Dependiendo del escenario, soporta RPOs (Recovery Point Objective) y RTOs (Recovery Time Objective) muy bajos.
El objetivo de HANA System Replication es que el sistema secundario sea una copia exacta del sistema primario. Cada uno de los servicios en el sistema primario se sincroniza con su contraparte en el sistema secundario; la única diferencia entre sistemas es que el sistema secundario no recibe peticiones de usuarios.
En primera instancia, cuando los servicios establecen comunicación entre ambos sistemas, el sistema secundario solicita un snapshot inicial y, a partir de ese momento, todos los cambios registrados en el sistema primario se replican de forma continua.

b. Provider de SAP HANA/DR

Además de las fallas de Sistema Operativo, o infraestructura, es necesario preveer posibles fallas en la base datos o en el sistema SAP en general. El sistema debe ser capaz de identificar si el nodo secundario no está en sincronía con el primario. SAP HANA provee de mecanismos, denominados “hooks”, que permiten al sistema enviar notificaciones para determinados eventos; estos mecanismos se utilizan para mejorar la detección de situaciones que requieren de un relevo o “takeover”.
Para el caso de uso especifico, SLES y RHEL proveen de un hook especial que permite al SAP HANA reportar inmediatamente al cluster cuando la replicación al nodo secundario pierde sincronía y es necesario un “failover”.

Configuración del Clúster de SUSE

A nivel de sistema operativo, la extensión de SUSE Linux Enterprise High Availability es la encargada de la resiliencia del sistema.

Los nodos del ambiente se configuran en Clúster de Sistema Operativo mediante el servicio de Pacemaker, el cuál, por default, se encuentra inhabilitado de arranque. Los pasos para la configuración incial del cluster se listan a continuación:

**NOTA: La configuración se realiza de forma automática por AWS Launch Wizard

Generación de llaves secretas necesarias para el cifrado de la comunicación entre nodos del clúster.
Creación del archivo de configuración de Corosync
- Corosync es un programa de código abierto que provee al cluster con la capacidad de definir a los miembros, ademas de la capa de mensajería entre ellos. En escencia, Corosync permite que los nodos se comuniquen como miembros de un clúster o grupo conocido, mientras que Pacemaker le indica a estos miembros, cómo se deben comportar.
Al arranque inicial del clúster, se activa el servicio de Pacemaker a nivel SO; validación de miembros activos.
Definición de propiedades y recursos de clúster
- Las propiedades y recursos del clúster se refieren a los parámetros de Pacemaker; definen cuales son los recursos y limitantes, que acciones debe realizar y como se debe proteger el clúster en caso de una falla. Estos parámetros son los siguientes:

- - Timeouts en recursos y operaciones por defecto a realizar en caso de que los Timeouts se venzan.
  - Componente STONITH (Shoot The Other Node In The Head), especifica como proteger el clúster de un nodo zombie, corrupto o con riesgo de corrupción de datos. Existen diferentes mecanismos, pero específicamente para AWS se define que, en caso de falla, la instancia EC2 afectada sea apagada por completo.
  - Definición de la IP Flotante (Overlay IP), la cuál deberá asignarse de forma automática al nodo Activo del clúster. Esto implica la asignación de la IP a la Elastic Network Interface (ENI) del servidor correspondiente y el ajuste en la tabla de ruteo.
  - Definición de la Topología SAP HANA que incluye la información referente al ambiente. El SID e Instance Number siendo los principales y únicos parámetros necesarios.
  - Recursos y Acciones de SAP HANA, los cuales definen los recursos necesarios para la operación y como debe comportarse el clúster en caso de una falla, por ejemplo, si un nodo que ha fallado se enciende ¿el clúster debería integrarlo de forma automática? ¿debería registrarlo en el ambiente SAP como secundario e iniciar el servicio de réplica automáticamente?
  - Restricciones – Como mínimo se definen dos restricciones en el clúster, 1) La IP Virtual o Flotante puede estar asignada única y exclusivamente al nodo de SAP HANA definido como “Principal”, nunca a un nodo distinto. 2) El orden en que se ejecutarán los pasos para restaurar el clúster, es decir, primero el cluster debe asegurarse que el recurso SAP HanaTopology se encuentre estable para después inicializar el recurso SAP HANA.

Validación del Clúster de SUSE

Una vez que el clúster ha sido configurado, ingresando por línea de comandos a cualquiera de los nodos miembro, se puede validar el estado del mismo. En el caso de la arquitectura que se ha desplegado con AWS Launch Wizard,se observan dos nodos en-línea y seis recursos activos:

sudo crm status

Figura 5. Monitor del Clúster de Sistema Operativo

El clúster de SUSE también cuenta con una interfaz web que simplifica el monitoreo de los recursos y nodos del cluster, esta consola gráfica se accede mediante navegador a la IP del nodo y por el puerto 7630.

TIP: El usuario default de la consola gráfica es: hacluster.

TIP: AWS Launch Wizard asigna al usuario la contraseña definida para SAP HANA en la configuración inicial.

La consola cuenta con un dashboard inicial que facilita identificar el status del cluster:

Figura 6. Dashboard gráfico del Monitor del Clúster

También, permite observar, analizar y, si es necesario, editar la configuración del clúster creada por AWS Launch Wizard:

Figura 7. Consola para realizar cambios a la configuración del Clúster

TIP: En caso de una falla, el servicio de Pacemaker ejecuta automáticamente la modificación de la ruta estática que permite la comunicación entre servicios externos de SAP a la IP Flotante del clúster. En caso de requerir que otra tabla de ruteo también se ajuste en automático, se debe modificar el recurso IP del clúster, listando el identificador de las tablas de ruteo en formato <rtb-XXXXXXXXXXXXXXXXX,rtb -YYYYYYYYYYYYYYYY>:

Pruebas de Alta Disponibilidad

En el siguiente video se observa cómo se realiza una prueba de disponibilidad efectiva de un clúster de SAP HANA mientras se ejecutan cambios en el sistema de S4.

Conclusión

AWS Launch Wizard permite a los administradores SAP definir la configuración del ambiente necesario, en infraestructura certificada, basado en las mejores prácticas de SAP.

Mediante templates de CloudFormation, Launch Wizard orquesta el despliegue de la infraestructura redundante a nivel SAP HANA y Sistema Operativo, integrando funcionalidades como SAP HANA System Replication y Clúster de Sistema Operativo. Trabajando de la mano, estas funcionalidades permiten que, al momento de detectar una falla, el sistema mantenga el servicio activo, sin afectar a los usuarios finales.
Esto se logra definiendo los parámetros de configuración en Launch Wizard y ejecutando el despliegue prácticamente sin interacción humana y, en cuestión de horas.

Sobre el autor

Manuel Cuellar es Arquitecto de Soluciones para Amazon Web Services en Sector Público. Manuel colabora con Dependencias de Gobierno, Instituciones Educativas y Organizaciones sin fines de lucro en el territorio de CentroAmérica y Caribe, apoyándolos en su camino a la innovación y adopción tecnológica.

Sobre los revisores técnicos

Sinuhé Sánchez es Arquitecto de Soluciones Especialista SAP en Amazon Web Services. Cuenta con más de 20 años de experiencia en IT y en este tiempo se ha desempeñado como consultor de SAP Basis, SAP Technical Consultant, Consultor de migraciones SAP y actualmente atendiendo a la región de Canadá. Ha participado en múltiples colaboraciones y revisiones de Blogs, White Papers y mejores prácticas para SAP.

Hans Hahn es Arquitecto de Soluciones SAP para Partners en Amazon Web Services Mexico. Con más de 15 años de experiencia en SAP, durante los que desempeño funciones como consultor SAP PO, arquitecto e instructor SAP HANA y SAP BASIS. Actualmente apoya ahora a los partners de AWS en su habilitación en SAP sobre AWS, colaborando en revisión de arquitecturas y estimaciones, basándose en las mejores prácticas.

Blog de Amazon Web Services (AWS)