Configuración de la réplica del sistema de ampliación SAP HANA en un clúster de SUSE Linux Enterprise High Availability Extension

La siguiente información describe la configuración de un clúster de SUSE Enterprise Linux Server (SLES) High Availability Extension (HAE)para la gestión de SAP HANA Scale-Up System Replication. El clúster utiliza instancias de servidor virtual en IBM® Power® Virtual Server como nodos del clúster.

Las instrucciones describen cómo automatizar SAP HANA Scale-Up System Replication para una única implementación de base de datos en un escenario de rendimiento optimizado en un clúster SLES HA Extension.

Esta información va dirigida a arquitectos y especialistas que estén planificando una implantación de alta disponibilidad de SAP HANA en Power Virtual Server.

Antes de empezar

Revise los requisitos generales, la documentación del producto, los artículos de soporte y las notas de SAP que aparecen en Implementación de alta disponibilidad para aplicaciones SAP en IBM Power Virtual Server Referencias.

Requisitos previos

Un clúster de alta disponibilidad de SUSE se implanta en dos instancias de servidor virtual en Power Virtual Server.
- Instale y configure el clúster SLES High Availability Extension de acuerdo con Implementación de un clúster de alta disponibilidad SUSE Linux Enterprise Server.
- Configure y verifique el vallado como se describe en el documento anterior.
Las instancias de servidor virtual deben cumplir los requisitos de hardware y recursos de los sistemas SAP HANA en cuestión. Siga las directrices de Planificación de la implantación.
Los nombres de host de las instancias del servidor virtual deben cumplir el requisito SAP HANA.
SAP HANA se instala en ambas instancias de servidor virtual y se configura SAP HANA System Replication La instalación de SAP HANA y la configuración de HANA System Replication no son específicas del entorno Power Virtual Server. Debe seguir los procedimientos estándar de instalación y configuración.
Se necesita una licencia SUSE Linux Enterprise Server for SAP Applications para habilitar los repositorios que necesita para instalar SAP HANA y los agentes de recursos para configuraciones de HA.
Consulte el capítulo Requisitos previos de la guía de aplicaciones SUSE Linux Enterprise Server para SAP.

Configuración de la replicación de sistemas SAP HANA en un clúster SLES HA Extension en IBM Power Virtual Server

Las instrucciones se basan en la documentación del producto SUSE y en los artículos que se enumeran en Implantación de alta disponibilidad para aplicaciones SAP en IBM Power Virtual Server Referencias.

Preparación de las variables de entorno

Para simplificar la configuración, prepare las siguientes variables de entorno para root en ambos nodos. Estas variables de entorno se utilizan con comandos posteriores del sistema operativo en esta información.

En ambos nodos, establezca las siguientes variables de entorno.

# General settings
export SID=<SID>            # SAP HANA System ID (uppercase)
export sid=<sid>            # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO>      # SAP HANA instance number

# Cluster node 1
export NODE1=<HOSTNAME_1>   # Virtual server instance hostname
export DC1="Site1"          # HANA System Replication site name

# Cluster node 2
export NODE2=<HOSTNAME_2>   # Virtual server instance hostname
export DC2="Site2"          # HANA System Replication site name

# Single zone
export VIP=<IP address>     # SAP HANA System Replication cluster virtual IP address

Establecimiento de variables de entorno adicionales para implementar una única zona

Revise la información en Reservar direcciones IP virtuales y reserve una dirección IP virtual para el clúster SAP HANA System Replication. Establezca la variable de entorno VIP en la dirección IP reservada.

Instalación de agentes de recursos SAP HANA

El agente de recursos SAP Hana y el agente de recursos SAP HanaTopology forman parte de la distribución de aplicaciones SLES para SAP.

Para instalar el agente de recursos y topología, asegúrese de que el paquete yast2-sap-ha esté instalado, como se describe en Configuración de un clúster SAP HANA y siga los pasos para configurar el clúster HANA mediante yast2.

Para escenarios de escalamiento horizontal, siga la sección Instalación de software adicional de la guía Escalamiento vertical de replicación del sistema SAP HANA: escenario con rendimiento optimizado.

Puesta en marcha del sistema SAP HANA

Inicie SAP HANA y compruebe que la replicación del sistema HANA está activa. Para obtener más información, consulte Comprobación de los detalles de estado de la replicación del sistema.

En ambos nodos, ejecute los siguientes comandos.

sudo -i -u ${sid}adm -- HDB start

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

Activación del gancho SAP HANA srConnectionChanged( )

Las versiones recientes de SAP HANA proporcionan ganchos para que SAP HANA pueda enviar notificaciones de determinados eventos. Para obtener más información, consulte Implementación de un proveedor de HA/DR.

El hook srConnectionChanged( ) mejora la capacidad del clúster para detectar un cambio de estado de HANA System Replication que requiera una acción por parte del clúster. El objetivo es evitar la pérdida y corrupción de datos impidiendo las tomas accidentales.

Activación del gancho srConnectionChanged( ) en todas las instancias de SAP HANA

Detener el clúster.

En NODE1, ejecute el siguiente comando.
```
crm cluster stop --all
```
A continuación, siga los pasos descritos en Configuración de proveedores de HA/DR en SAP HANA.
Compruebe que el gancho funciona.
- Reinicie ambas instancias de HANA y compruebe que el script de gancho funciona como se espera.
- Realice una acción para activar el gancho, como detener una instancia de HANA.
- Comprueba si el gancho ha registrado algo en los archivos de rastreo.
En ambos nodos, ejecute los siguientes comandos.

Detenga la instancia de HANA.
```
sudo -i -u ${sid}adm -- HDB stop
```
Inicie la instancia de HANA.
```
sudo -i -u ${sid}adm -- HDB start
```
Compruebe que el gancho registra mensajes en los archivos de rastreo.
```
sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_SAPHanaSR.*crm_attribute" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,5,17'
```
Tras comprobar que los ganchos funcionan, puede reiniciar el clúster de HA.
Inicie el clúster.

En NODE1, ejecute los siguientes comandos.

Inicie el clúster.
```
crm cluster start --all
```
Compruebe el estado del clúster.
```
crm status --full
```

Configuración de las propiedades generales del clúster

Para evitar la conmutación por error de los recursos durante las pruebas iniciales y la postproducción, establezca los siguientes valores predeterminados para los parámetros de adherencia de recursos y umbral de migración.

Estos pasos se describen en Configuración del clúster.

Los sistemas IBM Power10 proporcionan un temporizador de vigilancia de hardware integrado que está activado por defecto. Las descripciones de Configuring the cluster sugieren como alternativa utilizar softdog como temporizador de vigilancia de software. Utilice en su lugar el temporizador de vigilancia por hardware IBM Power10, más fiable.

Pruebas del clúster de replicación del sistema SAP HANA

Es fundamental probar a fondo la configuración del clúster para asegurarse de que funciona correctamente. La siguiente información proporciona algunos ejemplos de escenarios de prueba de conmutación por error. No es una lista completa de escenarios de prueba.

Por ejemplo, la descripción de cada caso de prueba incluye la siguiente información.

Componente que se está probando
Descripción de la prueba
Requisitos previos y estado del clúster antes de iniciar la prueba de conmutación por error
Procedimiento de ensayo
Comportamiento y resultados esperados
Procedimiento de recuperación

Prueba 1 - Prueba de un fallo de la instancia primaria de la base de datos

Utilice la siguiente información para probar el fallo de la instancia de base de datos primaria.

Prueba 1 - Descripción

Simule una caída de la instancia primaria de la base de datos HANA que se ejecuta en NODE1.

Prueba 1 - Requisitos previos

Un clúster funcional SLES HA Extension de dos nodos para la replicación del sistema HANA.
Ambos nodos del clúster están activos.
Cluster que se inicia en NODE1 y NODE2.
Cluster Resource SAPHana_${SID}_${INSTNO} que está configurado con AUTOMATED_REGISTER=false.
Compruebe el estado de la replicación del sistema SAP HANA:
- La base de datos primaria SAP HANA se ejecuta en NODE1
- La base de datos secundaria SAP HANA se ejecuta en NODE2
- La replicación del sistema HANA está activada y sincronizada

Una variación de la prueba 1 se describe en Casos de prueba para semiautomatización.

Procedimiento de la prueba 1

Utilice el siguiente comando para ejecutar la Prueba 1.

Crash SAP HANA primaria mediante el envío de una señal SIGKILL como el usuario ${sid}adm.

En NODE1, ejecute el siguiente comando.

sudo -i -u ${sid}adm -- HDB kill-9

Prueba 1 - Comportamiento esperado

Puede esperar el siguiente comportamiento de la prueba.

SAP HANA la instancia primaria en NODE1 se bloquea.
El clúster detecta la base de datos HANA primaria detenida y marca el recurso como failed.
El clúster promueve la base de datos HANA secundaria en NODE2 para que asuma el papel de la nueva primaria.
El clúster libera la dirección IP virtual en NODE1, y la adquiere en el nuevo primario en NODE2.
Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.

Prueba 1 - Procedimiento de recuperación

Como el recurso de cluster SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=false, el cluster no reinicia la base de datos HANA fallida y no la registra contra el nuevo primario. Lo que significa que el estado en el nuevo primario ( NODE2 ) también muestra el secundario en estado 'CONNECTION TIMEOUT'.

Para volver a registrar el primario anterior como nuevo secundario utilice los siguientes comandos.

En NODE1, ejecute el siguiente comando.

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE2} \
      --remoteInstance=00 \
      --replicationMode=sync \
      --operationMode=logreplay \
      --online
EOT

Verifique el estado de replicación del sistema utilizando el siguiente comando.

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

Tras el registro manual y la actualización de recursos, la nueva instancia secundaria se reinicia y muestra un estado sincronizado (SOK).

En NODE1, ejecute el siguiente comando.

crm resource refresh SAPHana_${SID}_${INSTNO}

Prueba 2 - Prueba de un fallo del nodo que ejecuta la base de datos primaria

Utilice la siguiente información para probar el fallo del nodo que está ejecutando la base de datos primaria.

Prueba 2 - Descripción

Simule una caída del nodo que ejecuta la base de datos HANA primaria.

Prueba 2 - Requisitos previos

Consulte los siguientes requisitos previos antes de realizar la Prueba 2.

Se necesita un clúster funcional SLES HA Extension de dos nodos para la replicación del sistema HANA.
Asegúrese de que ambos nodos están activos.
Confirme que el clúster se ha iniciado en NODE1 y NODE2.
Compruebe el estado de la replicación del sistema SAP HANA.
- La base de datos primaria SAP HANA se ejecuta en NODE2.
- La base de datos secundaria SAP HANA se ejecuta en NODE1.
- La replicación del sistema HANA está activada y sincronizada.

Prueba 2 - Preparación

Asegúrese de que el recurso de clúster SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=true.

En NODE1, ejecute los siguientes comandos.

crm resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true

crm resource config SAPHana_${SID}_${INSTNO}

Prueba 2 - Procedimiento de prueba

Bloquea el sistema primario en NODE2 enviando una petición de bloqueo del sistema.

En NODE2, ejecute el siguiente comando.

sync; echo c > /proc/sysrq-trigger

Prueba 2 - Comportamiento esperado

Puede esperar el siguiente comportamiento de la prueba.

NODE2 se apaga.
El clúster detecta el nodo que ha fallado y establece su estado en OFFLINE.
El clúster promueve la base de datos HANA secundaria en NODE1 para que asuma el papel de la nueva primaria.
El clúster adquiere la dirección IP virtual en NODE1 en el nuevo primario.
Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.

Prueba 2 - Procedimiento de recuperación

Utilice la siguiente información para recuperarse de la Prueba 2.

Acceda a la consola IBM Cloud® e inicie la instancia NODE2.
Espere hasta que NODE2 vuelva a estar disponible y, a continuación, reinicie el marco del clúster.
- En NODE2, ejecute los siguientes comandos.
```
crm cluster start
```
```
crm status --full
```

Como el recurso de clúster SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=true, SAP HANA se reinicia cuando NODE2 se vuelve a unir al clúster y el antiguo primario se vuelve a registrar como secundario.

Prueba 3 - Prueba de un fallo de la instancia secundaria de la base de datos

Utilice la siguiente información para probar el fallo de la instancia de base de datos secundaria.

Prueba 3 - Descripción

Simular una caída de la base de datos secundaria HANA.

Prueba 3 - Requisitos previos

Consulte los siguientes requisitos previos antes de realizar la Prueba 3.

Un clúster funcional SLES HA Extension de dos nodos para la replicación del sistema HANA.
Ambos nodos están activos.
El clúster se inicia en NODE1 y NODE2.
Cluster Resource SAPHana_${SID}_${INSTNO} se configura con AUTOMATED_REGISTER=true.
Compruebe el estado de la replicación del sistema SAP HANA.
- La base de datos primaria SAP HANA se ejecuta en NODE1.
- La base de datos secundaria SAP HANA se ejecuta en NODE2.
- La replicación del sistema HANA está activada y sincronizada.

Prueba 3 - Procedimiento de prueba

Crash SAP HANA secundaria mediante el envío de una señal SIGKILL como el usuario ${sid}adm.

En NODE2, ejecute el siguiente comando.

sudo -i -u ${sid}adm -- HDB kill-9

Prueba 3 - Comportamiento esperado

Puede esperar el siguiente comportamiento de la prueba.

SAP HANA secundaria en NODE2 accidentes.
El clúster detecta la base de datos HANA secundaria detenida y marca el recurso como failed.
El clúster reinicia la base de datos HANA secundaria.
El clúster detecta que la replicación del sistema vuelve a estar sincronizada.

Prueba 3 - Procedimiento de recuperación

Utilice la siguiente información para recuperarse de la Prueba 2.

Espere hasta que la instancia secundaria de HANA se inicie y sincronice de nuevo (SOK), luego limpie las acciones de recursos fallidas como se muestra en crm status.

En NODE2, ejecute el siguiente comando.

crm resource refresh SAPHana_${SID}_${INSTNO}

crm status --full

Prueba 4 - Prueba de traslado manual de un recurso SAP Hana a otro nodo

Utilice la siguiente información para probar el traslado manual de un recurso SAP Hana a otro nodo.

Prueba 4 - Descripción

Utilice los comandos de clúster para mover la instancia primaria al otro nodo con fines de mantenimiento.

Prueba 4 - Requisitos previos

Consulte los siguientes requisitos previos antes de realizar la Prueba 4.

Un clúster funcional SLES HA Extension de dos nodos para la replicación del sistema HANA.
Ambos nodos están activos.
El clúster se inicia en NODE1 y NODE2.
Cluster Resource SAPHana_${SID}_${INSTNO} se configura con AUTOMATED_REGISTER=true.
Compruebe el estado de la replicación del sistema SAP HANA:
- La base de datos primaria SAP HANA se ejecuta en NODE1
- La base de datos secundaria SAP HANA se ejecuta en NODE2
- La replicación del sistema HANA está activada y sincronizada

Prueba 4 - Procedimiento de prueba

Mueva el SAP HANA primario a otro nodo utilizando el comando crm resource move.

En NODE1, ejecute el siguiente comando.

crm resource move SAPHana_${SID}_${INSTNO}-clone

Prueba 4 - Comportamiento esperado

Puede esperar el siguiente comportamiento de la prueba.

El clúster crea restricciones de ubicación para mover el recurso.
El clúster activa una transferencia a la base de datos HANA secundaria.
Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.

Prueba 4 - Procedimiento de recuperación

Utilice la siguiente información para recuperarse de la Prueba 2.

Las restricciones de ubicación creadas automáticamente deben eliminarse para permitir la conmutación por error automática en el futuro.

Espere hasta que la instancia primaria de HANA esté activa y elimine las restricciones.

El clúster registra e inicia la base de datos HANA como una nueva instancia secundaria.

En NODE1, ejecute el siguiente comando.

crm constraint

crm resource clear SAPHana_${SID}_${INSTNO}-clone

crm constraint

crm status --full