IBM Cloud Docs
Configuración de la replicación de sistemas escalables SAP HANA en un clúster Red Hat Enterprise Linux High Availability Add-On

Configuración de la replicación de sistemas escalables SAP HANA en un clúster Red Hat Enterprise Linux High Availability Add-On

La siguiente información describe la configuración de un clúster Red Hat Enterprise Linux (RHEL) High Availability Add-On para gestionar 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 un despliegue de base de datos única en un escenario de rendimiento optimizado en un clúster RHEL HA Add-on.

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 de SAP en IBM Power Virtual Server Referencias.

Requisitos previos

  • Se despliega un clúster de alta disponibilidad Red Hat en dos instancias de servidor virtual en Power Virtual Server.
  • Las instancias de servidor virtual deben cumplir los requisitos de hardware y recursos de los sistemas SAP HANA en cuestión. Siga las directrices del documento Planificación de la implantación.
  • Los nombres de host de las instancias del servidor virtual deben cumplir el requisito SAP HANA.
  • SAP HANA está instalado en ambas instancias del servidor virtual y SAP HANA System Replication está configurado. La instalación de SAP HANA y la configuración de HANA System Replication no son específicas del entorno Power Virtual Server, y es necesario seguir los procedimientos estándar.
  • Se requiere una suscripción válida a RHEL for SAP Applications o RHEL for SAP Solutions para habilitar los repositorios que necesita para instalar SAP HANA y los agentes de recursos para configuraciones HA.

Configuración de la replicación de sistemas SAP HANA en un clúster RHEL HA Add-On en IBM Power Virtual Server

Las instrucciones se basan en la documentación del producto Red Hat y en los artículos que aparecen en Implementació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

# Multizone region
export CLOUD_REGION=<CLOUD_REGION>       # Multizone region name
export APIKEY="APIKEY or path to file"   # API Key of the IBM Cloud IAM ServiceID for the resource agent
export API_TYPE="private or public"      # Use private or public API endpoints
export IBMCLOUD_CRN_1=<IBMCLOUD_CRN_1>   # Workspace 1 CRN
export IBMCLOUD_CRN_2=<IBMCLOUD_CRN_2>   # Workspace 2 CRN
export POWERVSI_1=<POWERVSI_1>           # Virtual server instance 1 id
export POWERVSI_2=<POWERVSI_2>           # Virtual server instance 2 id
export SUBNET_NAME="vip-${sid}-net"      # Name which is used to define the subnet in IBM Cloud
export CIDR="CIDR of subnet"             # CIDR of the subnet containing the service IP address
export VIP="Service IP address"          # IP address in the subnet
export JUMBO="true or false"             # Enable Jumbo frames

Establecimiento de variables de entorno adicionales para la implantación de una zona única

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.

Establecimiento de variables de entorno adicionales para la implantación de una región multizona

Establezca las variables CLOUD_REGION, APIKEY, IBMCLOUD_CRN_?, POWERVSI_? tal y como se describe en la sección Recopilación de parámetros para configurar un clúster de alta disponibilidad. Establezca la variable API_TYPE en private para comunicarse con IBM Cloud IAM y IBM Power Cloud API a través de endpoints privados. La variable SUBNET_NAME contiene el nombre de la subred. La variable CIDR representa la notación Classless Inter-Domain Routing (CIDR ) para la subred en el formato <IPv4_address>/number. La variable VIP es la dirección IP del recurso de dirección IP virtual y debe pertenecer a la CIDR de la subred. Establezca la variable JUMBO en true si desea habilitar la subred para un tamaño de MTU grande.

A continuación se muestra un ejemplo de cómo configurar las variables de entorno adicionales necesarias para la implementación de una región multizona.

export CLOUD_REGION="eu-de"
export IBMCLOUD_CRN_1="crn:v1:bluemix:public:power-iaas:eu-de-2:a/a1b2c3d4e5f60123456789a1b2c3d4e5:a1b2c3d4-0123-4567-89ab-a1b2c3d4e5f6::"
export IBMCLOUD_CRN_2="crn:v1:bluemix:public:power-iaas:eu-de-1:a/a1b2c3d4e5f60123456789a1b2c3d4e5:e5f6a1b2-cdef-0123-4567-a1b2c3d4e5f6::"
export POWERVSI_1="a1b2c3d4-0123-890a-f012-0123456789ab"
export POWERVSI_2="e5f6a1b2-4567-bcde-3456-cdef01234567"
export APIKEY="@/root/.apikey.json"
export API_TYPE="private"
export SUBNET_NAME="vip-mha-net"
export CIDR="10.40.11.100/30"
export VIP="10.40.11.102"
export JUMBO="true"

Instalación de agentes de recursos SAP HANA

Ejecute el siguiente comando para instalar los agentes de recursos RHEL HA Add-On para SAP HANA System Replication.

dnf install -y resource-agents-sap-hana

Puesta en marcha del sistema SAP HANA

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

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 para ciertos eventos. Para obtener más información, consulte Implementación de un proveedor de HA/DR.

El hook srConnectionChanged( ) mejora la capacidad del cluster para detectar un cambio de estado de HANA System Replication que requiera una acción por parte del cluster. 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

  1. Detener el clúster.

    En NODE1, ejecute el siguiente comando.

    pcs cluster stop --all
    
  2. Instale la secuencia de comandos de gancho proporcionada por el paquete resource-agents-sap-hana en el directorio /hana/shared/myHooks para cada instancia de HANA y establezca la propiedad necesaria.

    En ambos nodos, ejecute los siguientes comandos.

    mkdir -p /hana/shared/myHooks
    
    cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
    
    chown -R ${sid}adm:sapsys /hana/shared/myHooks
    
  3. Actualice el archivo global.ini en cada nodo HANA para habilitar el script hook.

    En ambos nodos, ejecute el siguiente comando.

    sudo -i -u ${sid}adm -- <<EOT
        python \$DIR_INSTANCE/exe/python_support/setParameter.py \
          -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/provider=SAPHanaSR \
          -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/path=/hana/shared/myHooks \
          -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/execution_order=1 \
          -set SYSTEM/global.ini/trace/ha_dr_saphanasr=info
    EOT
    
  4. Verifique el archivo modificado.

    En ambos nodos, ejecute el siguiente comando.

    cat /hana/shared/${SID}/global/hdb/custom/config/global.ini
    
  5. Crear configuraciones sudo para el usuario SAP HANA OS.

    Necesita la siguiente configuración sudo para permitir que el script de usuario ${sid}adm pueda actualizar los atributos del nodo cuando se ejecute el hook srConnectionChanged( ).

    En ambos nodos, ejecute los siguientes comandos.

    Cree un archivo con los alias sudo y las especificaciones de usuario necesarias.

    cat >> /etc/sudoers.d/20-saphana << EOT
    Cmnd_Alias DC1_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SOK -t crm_config -s SAPHanaSR
    Cmnd_Alias DC1_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SFAIL -t crm_config -s SAPHanaSR
    Cmnd_Alias DC2_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SOK -t crm_config -s SAPHanaSR
    Cmnd_Alias DC2_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SFAIL -t crm_config -s SAPHanaSR
    ${sid}adm ALL=(ALL) NOPASSWD: DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL
    Defaults!DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL !requiretty
    EOT
    

    Ajuste los permisos y compruebe si hay errores de sintaxis.

    chown root:root /etc/sudoers.d/20-saphana
    
    chmod 0440 /etc/sudoers.d/20-saphana
    
    cat /etc/sudoers.d/20-saphana
    
    visudo -c
    

Cualquier problema reportado por el comando visudo -c debe ser corregido.

  1. 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 ha registrado algunos 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.

  2. Inicie el clúster.

    En NODE1, ejecute los siguientes comandos.

    Inicie el clúster.

    pcs cluster start --all
    

    Compruebe el estado del clúster.

    pcs 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 posteriores a la producción, establezca los siguientes valores predeterminados para los parámetros de adherencia de recursos y umbral de migración.

Tenga en cuenta que los valores por defecto no se aplican a los recursos que los anulan con sus propios valores definidos.

En NODE1, ejecute los siguientes comandos.

pcs resource defaults update resource-stickiness=1000
pcs resource defaults update migration-threshold=5000

Creación de un recurso clónico SAPHanaTopology

El recurso SAPHanaTopology recurso recoge el estado y la configuración de SAP HANA System Replication en cada nodo. También inicia y supervisa el SAP HostAgent local, que es necesario para iniciar, detener y supervisar instancias SAP HANA.

En NODE1, ejecute los siguientes comandos.

Cree el SAPHanaTopology recurso.

pcs resource create SAPHanaTopology_${SID}_${INSTNO} SAPHanaTopology \
    SID=${SID} InstanceNumber=${INSTNO} \
    op start timeout=600 \
    op stop timeout=300 \
    op monitor interval=10 timeout=600 \
    clone clone-max=2 clone-node-max=1 interleave=true

Compruebe la configuración y el estado del clúster ejecutando los siguientes comandos.

pcs resource config SAPHanaTopology_${SID}_${INSTNO}
pcs resource config SAPHanaTopology_${SID}_${INSTNO}-clone
pcs status --full

Creación de un recurso SAPHana promocionable

El recurso SAPHana gestiona dos instancias de SAP HANA configuradas como nodos de replicación del sistema HANA.

En NODE1, cree el recurso SAPHana ejecutando el siguiente comando.

pcs resource create SAPHana_${SID}_${INSTNO} SAPHana \
    SID=${SID} InstanceNumber=${INSTNO} \
    PREFER_SITE_TAKEOVER=true \
    DUPLICATE_PRIMARY_TIMEOUT=7200 \
    AUTOMATED_REGISTER=false \
    op start timeout=3600 \
    op stop timeout=3600 \
    op monitor interval=61 role="Unpromoted" timeout=700 \
    op monitor interval=59 role="Promoted" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    promotable notify=true clone-max=2 clone-node-max=1 interleave=true

Compruebe la configuración y el estado del clúster.

pcs resource config SAPHana_${SID}_${INSTNO}
pcs status --full

Creación de un recurso de clúster de direcciones IP virtuales

Dependiendo del escenario, proceda a una de las siguientes secciones:

Creación de un recurso de clúster de direcciones IP virtuales en un entorno de zona única

Utilice la dirección IP reservada para crear un recurso de clúster de dirección IP virtual. Esta dirección IP virtual se utiliza para acceder a la instancia primaria de SAP HANA System Replication.

Cree el recurso de cluster de direcciones IP virtuales con el siguiente comando.

pcs resource create vip_${SID}_${INSTNO} IPaddr2 ip=$VIP

Compruebe el recurso de clúster de dirección IP virtual configurado y el estado del clúster.

pcs resource config vip_${SID}_${INSTNO}
pcs status --full

Continúe con la sección Creación de restricciones de recursos de clúster.

Creación de un recurso de clúster de direcciones IP virtuales en un entorno de regiones multizona

Compruebe que ha completado todos los pasos de la sección Preparación de un clúster RHEL HA Add-On multizona para un recurso de dirección IP virtual.

Ejecute el comando pcs resource describe powervs-subnet para obtener información sobre los parámetros del agente de recursos.

En NODE1, cree un recurso de clúster powervs-subnet ejecutando el siguiente comando.

pcs resource create vip_${SID}_${INSTNO} powervs-subnet \
    api_key=${APIKEY} \
    api_type=${API_TYPE} \
    cidr=${CIDR} \
    ip=${VIP} \
    crn_host_map="${NODE1}:${IBMCLOUD_CRN_1};${NODE2}:${IBMCLOUD_CRN_2}" \
    vsi_host_map="${NODE1}:${POWERVSI_1};${NODE2}:${POWERVSI_2}" \
    jumbo=${JUMBO} \
    region=${CLOUD_REGION} \
    subnet_name=${SUBNET_NAME} \
    op start timeout=720 \
    op stop timeout=300 \
    op monitor interval=60 timeout=30

Si establece API_TYPE en public, también debe especificar un parámetro proxy.

Asegúrese de que ambas instancias de servidor virtual del clúster tienen el estado Active y el estado de salud OK antes de ejecutar el comando pcs resource config.

Compruebe el recurso de dirección IP virtual configurado y el estado del clúster.

pcs resource config vip_${SID}_${INSTNO}

Salida de ejemplo:

# pcs resource config vip_MHA_00
Resource: vip_MHA_00 (class=ocf provider=heartbeat type=powervs-subnet)
  Attributes: vip_MHA_00-instance_attributes
    api_key=@/root/.apikey.json
    api_type=private
    cidr=10.40.11.100/30
    crn_host_map=cl-mha-1:crn:v1:bluemix:public:power-iaas:eu-de-2:**********************************:************************************::;cl-mha-2:crn:v1:bluemix:public:power-iaas:eu-
        de-1:**********************************:************************************::
    ip=10.40.11.102
    jumbo=true
    proxy=http://10.30.40.4:3128
    region=eu-de
    subnet_name=vip-mha-net
    vsi_host_map=cl-mha-1:************************************;cl-mha-2:************************************
  Operations:
    monitor: res_vip_MHA_00-monitor-interval-60
      interval=60
      timeout=60
    start: res_vip_MHA_00-start-interval-0s
      interval=0s
      timeout=720
    stop: res_vip_MHA_00-stop-interval-0s
      interval=0s
      timeout=300
pcs status --full

El siguiente ejemplo es una salida de muestra de un clúster de Replicación del Sistema SAP HANA en una configuración de región multizona.

# pcs status --full
Cluster name: SAP_MHA
Status of pacemakerd: 'Pacemaker is running' (last updated 2024-07-31 11:37:49 +02:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-mha-2 (2) (version 2.1.5-9.el9_2.4-a3f44794f94) - partition with quorum
  * Last updated: Wed Jul 31 11:37:50 2024
  * Last change:  Wed Jul 31 11:37:31 2024 by root via crm_attribute on cl-mha-1
  * 2 nodes configured
  * 7 resource instances configured

Node List:
  * Node cl-mha-1 (1): online, feature set 3.16.2
  * Node cl-mha-2 (2): online, feature set 3.16.2

Full List of Resources:
  * fence_node1	(stonith:fence_ibm_powervs):	 Started cl-mha-1
  * fence_node2	(stonith:fence_ibm_powervs):	 Started cl-mha-2
  * Clone Set: SAPHanaTopology_MHA_00-clone [SAPHanaTopology_MHA_00]:
    * SAPHanaTopology_MHA_00	(ocf:heartbeat:SAPHanaTopology):	 Started cl-mha-2
    * SAPHanaTopology_MHA_00	(ocf:heartbeat:SAPHanaTopology):	 Started cl-mha-1
  * Clone Set: SAPHana_MHA_00-clone [SAPHana_MHA_00] (promotable):
    * SAPHana_MHA_00	(ocf:heartbeat:SAPHana):	 Unpromoted cl-mha-2
    * SAPHana_MHA_00	(ocf:heartbeat:SAPHana):	 Promoted cl-mha-1
  * vip_MHA_00	(ocf:heartbeat:powervs-subnet):	 Started cl-mha-1

Node Attributes:
  * Node: cl-mha-1 (1):
    * hana_mha_clone_state            	: PROMOTED
    * hana_mha_op_mode                	: logreplay
    * hana_mha_remoteHost             	: cl-mha-2
    * hana_mha_roles                  	: 4:P:master1:master:worker:master
    * hana_mha_site                   	: SiteA
    * hana_mha_sra                    	: -
    * hana_mha_srah                   	: -
    * hana_mha_srmode                 	: syncmem
    * hana_mha_sync_state             	: PRIM
    * hana_mha_version                	: 2.00.075.00
    * hana_mha_vhost                  	: cl-mha-1
    * lpa_mha_lpt                     	: 1722418651
    * master-SAPHana_MHA_00           	: 150
  * Node: cl-mha-2 (2):
    * hana_mha_clone_state            	: DEMOTED
    * hana_mha_op_mode                	: logreplay
    * hana_mha_remoteHost             	: cl-mha-1
    * hana_mha_roles                  	: 4:S:master1:master:worker:master
    * hana_mha_site                   	: SiteB
    * hana_mha_sra                    	: -
    * hana_mha_srah                   	: -
    * hana_mha_srmode                 	: syncmem
    * hana_mha_sync_state             	: SOK
    * hana_mha_version                	: 2.00.075.00
    * hana_mha_vhost                  	: cl-mha-2
    * lpa_mha_lpt                     	: 30
    * master-SAPHana_MHA_00           	: 100

Migration Summary:

Tickets:

PCSD Status:
  cl-mha-1: Online
  cl-mha-2: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

Continúe con la sección Creación de restricciones de recursos de clúster.

Creación de restricciones de recursos del clúster

Asegúrese de que SAPHanaTopology antes de iniciar los recursos SAPHana.

La dirección IP virtual debe estar presente en el nodo donde se ejecuta el recurso primario de "SAPHana".

  1. Cree una restricción de recursos para iniciar "SAPHanaTopology" antes que "SAPHana". Esta restricción impone el orden de inicio de estos recursos.

    En NODE1, utilice el siguiente comando para crear la restricción de orden SAPHanaTopology restricción de orden:

    pcs constraint order SAPHanaTopology_${SID}_${INSTNO}-clone \
        then SAPHana_${SID}_${INSTNO}-clone symmetrical=false
    

    Comprueba la configuración.

    pcs constraint
    
  2. Cree una restricción de recursos para colocar la dirección IP virtual con la primaria. Esta restricción coloca el recurso de dirección IP virtual con el recurso SAPHana que fue promovido como primario.

    En NODE1, ejecute el siguiente comando para crear la restricción de colocación de direcciones IP virtuales.

    pcs constraint colocation add vip_${SID}_${INSTNO} \
        with Promoted SAPHana_${SID}_${INSTNO}-clone 2000
    

    Compruebe la configuración y el estado del clúster.

    pcs constraint
    

    Salida de ejemplo:

    # pcs constraint
    Location Constraints:
    Ordering Constraints:
      start SAPHanaTopology_HDB_00-clone then start SAPHana_HDB_00-clone (kind:Mandatory) (non-symmetrical)
    Colocation Constraints:
      vip_HDB_00 with SAPHana_HDB_00-clone (score:2000) (rsc-role:Started) (with-rsc-role:Promoted)
    Ticket Constraints:
    

    Compruebe el estado del clúster.

    pcs status --full
    

    En el nodo de clúster promovido, compruebe que la dirección IP del servicio de clúster está activa.

    ip addr show
    

Activación del gancho SAP HANA srServiceStateChanged( ) (opcional)

SAP HANA dispone de funciones integradas para controlar su indexserver. En caso de problema, SAP HANA intenta recuperarse automáticamente deteniendo y reiniciando el proceso. Para detener el proceso o limpiarlo después de un fallo, el núcleo Linux debe liberar toda la memoria asignada por el proceso. En el caso de bases de datos grandes, esta limpieza puede llevar mucho tiempo. Durante este tiempo, SAP HANA sigue funcionando y aceptando nuevas solicitudes de clientes. Como resultado, la replicación del sistema SAP HANA puede desincronizarse. Si se produce otro error en la instancia SAP HANA antes de que finalice el reinicio y la recuperación de indexserver, la coherencia de los datos corre peligro.

El script ChkSrv.py para el hook srServiceStateChanged() reacciona ante tal situación y puede detener toda la instancia SAP HANA para una recuperación más rápida. Si automated failover está habilitado en el clúster, y el nodo secundario se encuentra en un estado saludable, se inicia una operación de toma de control. En caso contrario, la recuperación debe continuar localmente, pero se acelera mediante el reinicio forzado de la instancia SAP HANA.

El hook SAP HANA srServiceStateChanged() está disponible con la versión resource-agents-sap-hana 0.162.3 y posteriores.

El script gancho analiza los eventos de la instancia, aplica filtros a los detalles del evento y desencadena acciones basadas en los resultados. Distingue entre un proceso SAP HANA indexserver que es detenido y reiniciado por SAP HANA y el proceso que se detiene durante el apagado de una instancia.

Dependiendo de la configuración del parámetro action_on_lost, el gancho realiza diferentes acciones:

Ignorar
Esta acción simplemente registra los eventos y la información de la decisión en un archivo de registro.
Detener
Esta acción desencadena una parada graceful de la instancia SAP HANA mediante el comando sapcontrol.
Destruir
Esta acción activa el comando HDB kill-<signal> con una señal por defecto 9. La señal se puede configurar.

Tanto la acción de parar como la de matar dan como resultado una instancia de SAP HANA parada, la acción de matar es ligeramente más rápida.

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

El hook srServiceStateChanged() puede añadirse mientras SAP HANA se está ejecutando en ambos nodos.

  1. Para cada instancia de HANA, instale el script de gancho que proporciona el paquete resource-agents-sap-hana en el directorio /hana/shared/myHooks y establezca la propiedad necesaria.

    En ambos nodos, ejecute los siguientes comandos.

    cp /usr/share/SAPHanaSR/srHook/ChkSrv.py /hana/shared/myHooks
    
    chown ${sid}adm:sapsys /hana/shared/myHooks/ChkSrv.py
    
  2. Actualice el archivo global.ini en cada nodo SAP HANA para habilitar el script hook.

    En ambos nodos, ejecute el siguiente comando.

    sudo -i -u ${sid}adm -- <<EOT
        python \$DIR_INSTANCE/exe/python_support/setParameter.py \
          -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/provider=ChkSrv \
          -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/path=/hana/shared/myHooks \
          -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/execution_order=2 \
          -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/action_on_lost=stop \
          -set SYSTEM/global.ini/trace/ha_dr_chksrv=info
    EOT
    

    El parámetro action_on_lost en este ejemplo se establece en stop, el ajuste por defecto es ignore. Puede configurar opcionalmente los parámetros stop_timeout (por defecto: 20 segundos) y kill_signal (por defecto: 9).

  3. Activar el gancho ChkSrv.py

    En ambos nodos, ejecute el siguiente comando para recargar los proveedores HA-DR.

    sudo -i -u ${sid}adm -- hdbnsutil -reloadHADRProviders
    
  4. Compruebe que el gancho ha registrado algunos mensajes en los archivos de rastreo.

    En ambos nodos, ejecute el siguiente comando.

    sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_ChkSrv" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,6-'
    

Registro automático de una instancia secundaria

Debe ajustar el parámetro AUTOMATED_REGISTER en función de sus necesidades operativas. Si desea mantener la capacidad de volver al estado de la instancia primaria anterior SAP HANA, entonces AUTOMATED_REGISTER=false evita un registro automático del primario anterior como nuevo secundario.

Si experimenta un problema con los datos después de una toma de control desencadenada por el clúster, puede revertirlo manualmente si AUTOMATED_REGISTER está configurado en false.

Si AUTOMATED_REGISTER se establece en true, la instancia primaria anterior SAP HANA se registra automáticamente como secundaria, y no puede activarse en su historial anterior. La ventaja de AUTOMATED_REGISTER=true es que la capacidad de alta disponibilidad se restablece automáticamente tras la reaparición del nodo averiado en el clúster.

Por ahora, se recomienda mantener AUTOMATED_REGISTER en el valor predeterminado false hasta que el clúster esté completamente probado y se verifique que los escenarios de conmutación por error funcionan como se espera.

El comando pcs resource update se utiliza para modificar los atributos de los recursos y pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true establece el atributo en true.

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, pero 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 RHEL HA Add-On de dos nodos para la replicación de sistemas 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

Prueba 1 - Procedimiento de prueba

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

  • 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

Verificar el estado de replicación del sistema:

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 aparece en estado sincronizado (SOK).

En NODE1, ejecute el siguiente comando.

pcs resource refresh SAPHana_${SID}_${INSTNO}
pcs status --full

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 - Preparación

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

En NODE1, ejecute el siguiente comando.

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

Prueba 2 - Requisitos previos

  • Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
  • Ambos nodos están activos.
  • El clúster se inicia 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 - 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

  • 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

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 el siguiente comando.

pcs cluster start
pcs status --full

Como el recurso de clúster SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=true, SAP HANA se reinicia cuando NODE2 se reincorpora 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

  • Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas 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

  • 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

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 pcs status.

En NODE2, ejecute el siguiente comando.

pcs resource refresh SAPHana_${SID}_${INSTNO}
pcs status --full

Prueba 4 - Prueba de traslado manual de un recurso SAPHana a otro nodo

Utilice la siguiente información para probar el traslado manual de un recurso SAPHana 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

  • Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas 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 pcs resource move.

En NODE1, ejecute el siguiente comando.

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

Prueba 4 - Comportamiento esperado

  • 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

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.

pcs constraint
pcs resource clear SAPHana_${SID}_${INSTNO}-clone
pcs constraint
pcs status --full