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

Configuración de la replicación del sistema SAP HANA multitier 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 la replicación del sistema SAP HANA en un escenario de replicación multinivel. El clúster utiliza instancias de servidor virtual en IBM® Power® Virtual Server como nodos del clúster.

Puede conectar varios sistemas en una topología de replicación de sistemas multinivel SAP HANA para lograr un mayor nivel de disponibilidad. La instancia terciaria SAP HANA se ejecuta en una tercera instancia de servidor virtual en IBM Power Virtual Server en otro espacio de trabajo. Los agentes de recursos para SAP HANA en el complemento HA de Red Hat Enterprise Linux 8 (RHEL) requieren que la instancia terciaria SAP HANA se gestione manualmente. El sistema terciario SAP HANA se instala en una instancia de servidor virtual fuera del clúster. Tras una toma de control en el clúster, la instancia terciaria SAP HANA debe volver a registrarse manualmente.

En un escenario de replicación de sistemas multinivel, un sistema terciario SAP HANA se ejecuta en una tercera instancia de servidor virtual. La tercera instancia de servidor virtual se despliega en un espacio de trabajo diferente de IBM Power Virtual Server en otra ubicación geográfica o zona. El modo de operación de replicación del sistema SAP HANA debe ser idéntico para todos los niveles de replicación multinivel. La única excepción es logreplay_readaccess entre el primario y el secundario combinado con logreplay entre el secundario y el terciario.

La transferencia al sistema terciario en el sitio de recuperación de desastres (DR) debe activarse manualmente.

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

Configuración del escenario multinivel

El escenario multinivel es una extensión de la configuración que se describe en Configuración de la replicación de sistemas escalables de SAP HANA en un clúster de complemento de alta disponibilidad de Red Hat Enterprise Linux. Complete la configuración del clúster de replicación del sistema antes de continuar con los pasos siguientes.

Si el atributo de clúster AUTOMATED_REGISTER se establece en true, la reintegración de un nodo fallido en el clúster puede conducir a una configuración con un modo de replicación del sistema SAP HANA incorrecto o una topología de replicación del sistema SAP HANA no deseada. Para evitar estos problemas, desactive el registro automático y utilice el comando hdbnsutil para registrar el sistema SAP HANA manualmente antes de iniciar el clúster en un nodo que haya fallado.

En un nodo del clúster, ejecute el siguiente comando para desactivar el registro automático.

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

Proporcionar conectividad de red entre los espacios de trabajo

  1. Utilice la información de Crear el espacio de trabajo para crear otro espacio de trabajo en una ubicación geográfica o región diferente.

  2. Cree subredes y asegúrese de que los rangos de IP no se solapan con ninguna subred del espacio de trabajo que aloja las instancias de servidor virtual para el clúster. Para obtener más información, consulte Creación de subredes de redes privadas.

  3. Configure las conexiones IBM Cloud® en ambos espacios de trabajo y active Habilitar IBM Transit Gateway. Para obtener más información, consulte el apartado Creación de conexiones de nube de Power Virtual Server.

  4. Despliegue un IBM Cloud Transit Gateway para interconectar los dos espacios de trabajo IBM Power Virtual Server.

    IBM Cloud Transit Gateway permite la interconexión de las infraestructuras IBM Power Virtual Server, IBM Cloud classic y Virtual Private Cloud (VPC) y mantiene los datos dentro de las redes IBM Cloud. Para obtener más información sobre la planificación e implantación de IBM Cloud Transit Gateway, consulte Planificación de IBM Cloud Transit Gateway y Pedidos IBM Cloud Transit Gateway.

  5. Para añadir las conexiones a su pasarela de tránsito para establecer la conectividad de red entre su IBM Power Virtual Server, abra la página Transit Gateway página

  6. Seleccione el nombre de su pasarela de tránsito.

  7. Pulse Añadir conexión.

  8. Elija Power Systems Virtual Serverk como conexión de red y seleccione la Ubicación de su espacio de trabajo.

  9. Pulse Añadir para crear la nueva conexión.

Preparación de variables de entorno en NODE3

Para simplificar la configuración, prepare las siguientes variables de entorno para el ID de usuario root en NODE3. Estas variables de entorno se utilizan en los comandos subsiguientes en el resto de las instrucciones.

En NODE3, cree un archivo con las siguientes variables de entorno. A continuación, adáptelas en función de la configuración de su sistema SAP HANA.

export SID=<SID>            # SAP HANA System ID (uppercase)
export sid=<sid>            # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO>      # SAP HANA Instance Number

export DC3=<Site3>          # HANA System Replication Site Name 3

export NODE1=<Hostname 1>   # Hostname of virtual server instance 1 (production primary)
export NODE2=<Hostname 2>   # Hostname of virtual server instance 2 (production secondary)
export NODE3=<Hostname 3>   # Hostname of virtual server instance 3 (production tertiary)

Debe obtener este archivo antes de utilizar los comandos de ejemplo del resto de este documento.

Por ejemplo, si ha creado un archivo que se llama sap_tier3.sh, ejecute el siguiente comando en NODE3 para establecer las variables de entorno.

source sap_tier3.sh

Cada vez que inicie una nueva sesión de terminal, deberá ejecutar el comando source anterior. Como alternativa, puede mover añadir el archivo de variables de entorno al directorio /etc/profile.d durante la configuración del clúster. En este ejemplo, el archivo se obtiene automáticamente cada vez que se inicia sesión en el servidor.

Verificación de la conectividad de red entre las instancias del servidor virtual

Compruebe la conectividad de red entre los dos nodos del clúster ( NODE1 y NODE2 ) y NODE3.

  1. Conéctese tanto a NODE1 como a NODE2, y a ping NODE3.

    ping -c 3 ${NODE3}

    Salida de ejemplo:

    # ping -c 3 cl-hdb-3
PING cl-hdb-3 (10.40.20.70) 56(84) bytes of data.
64 bytes from 10.40.20.70 (10.40.20.70): icmp_seq=1 ttl=46 time=78.2 ms
64 bytes from 10.40.20.70 (10.40.20.70): icmp_seq=2 ttl=46 time=78.3 ms
64 bytes from 10.40.20.70 (10.40.20.70): icmp_seq=3 ttl=46 time=78.2 ms

--- cl-hdb-3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 78.197/78.233/78.264/0.027 ms

  2. Conéctese a NODE3 y ping NODE1.

    ping -c 3 ${NODE1}

    Salida de ejemplo:

    # ping -c 3 cl-hdb-1
PING cl-hdb-1 (10.40.10.60) 56(84) bytes of data.
64 bytes from cl-hdb-1 (10.40.10.60): icmp_seq=1 ttl=46 time=78.3 ms
64 bytes from cl-hdb-1 (10.40.10.60): icmp_seq=2 ttl=46 time=78.2 ms
64 bytes from cl-hdb-1 (10.40.10.60): icmp_seq=3 ttl=46 time=78.3 ms

--- cl-hdb-1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 78.245/78.268/78.287/0.229 ms

  3. Conéctese a NODE3 y ping NODE2.

    ping -c 3 ${NODE2}

    Salida de ejemplo:

    # ping -c 3 cl-hdb-2
PING cl-hdb-2 (10.40.10.194) 56(84) bytes of data.
64 bytes from cl-hdb-2 (10.40.10.194): icmp_seq=1 ttl=46 time=77.6 ms
64 bytes from cl-hdb-2 (10.40.10.194): icmp_seq=2 ttl=46 time=79.1 ms
64 bytes from cl-hdb-2 (10.40.10.194): icmp_seq=3 ttl=46 time=77.7 ms

--- cl-hdb-2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 77.649/78.129/79.071/0.703 ms

Copia de archivos de certificado de almacenamiento SSFS de PKI en NODE3

Los canales de transmisión de datos y registros de SAP HANA 2.0 para el proceso de replicación requieren autenticación mediante el uso de los archivos de certificados de almacenamiento PKI SSFS del sistema.

Los archivos de certificados de almacenamiento SSFS de PKI del sistema se almacenan en /usr/sap/${SID}/SYS/global/security/rsecssfs/ en los subdirectorios data y key.

En NODE3, ejecute los siguientes comandos para copiar los archivos SSFS_${SID}.DAT y SSFS_${SID}.KEY desde NODE2.

scp ${NODE2}:/usr/sap/${SID}/SYS/global/security/rsecssfs/data/SSFS_${SID}.DAT /usr/sap/${SID}/SYS/global/security/rsecssfs/data/SSFS_${SID}.DAT

scp ${NODE2}:/usr/sap/${SID}/SYS/global/security/rsecssfs/key/SSFS_${SID}.KEY /usr/sap/${SID}/SYS/global/security/rsecssfs/key/SSFS_${SID}.KEY

Los certificados de almacenamiento PKI SSFS copiados en NODE3 se activan durante el inicio del sistema SAP HANA. Por lo tanto, se recomienda copiar los archivos cuando el sistema SAP HANA en NODE3 esté parado.

Registro de NODE3 como sistema terciario de replicación del sistema SAP HANA

Registre el sistema SAP HANA como instancia de replicación del sistema terciario.

  1. En NODE2, ejecute el siguiente comando para habilitar este sitio como sistema de origen de replicación del sistema.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_enable

    Salida de ejemplo:

    $ hdbnsutil -sr_enable
nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.

  2. En NODE3, detenga el sistema SAP HANA.

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

  3. En NODE3, registre el sistema terciario en NODE2.

    sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC3} \
      --remoteHost=${NODE2} \
      --remoteInstance=${INSTNO} \
      --replicationMode=async \
      --operationMode=logreplay \
      --online

  4. En NODE3, inicie el sistema terciario SAP HANA.

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

Comprobación del estado de replicación del sistema SAP HANA

Puede supervisar el estado de replicación del sistema utilizando las siguientes herramientas.

  • SAP HANA cabina
  • SAP HANA estudio
  • hdbnsutil Herramienta de línea de mandatos
  • systemReplicationStatus.py Script de Python
  • Consultas SQL

La salida completa del script systemReplicationStatus.py sólo está disponible en el sistema primario, ya que se requiere una conexión a la base de datos para obtener parte de la información de estado.

En NODE1, compruebe el estado de replicación del sistema mediante el script systemReplicationStatus.py Python.

sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

Salida de ejemplo:

# sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-1 |30001 |nameserver   |        1 |      1 |SiteA     |cl-hdb-2 |    30001 |        2 |SiteB     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30007 |xsengine     |        2 |      1 |SiteA     |cl-hdb-2 |    30007 |        2 |SiteB     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30003 |indexserver  |        3 |      1 |SiteA     |cl-hdb-2 |    30003 |        2 |SiteB     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3 |    30001 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3 |    30007 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3 |    30003 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |

status system replication site "2": ACTIVE
status system replication site "3": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: SiteA

Una vista alternativa del estado de replicación del sistema está disponible con el comando hdbnsutil.

En todos los nodos, ejecute el siguiente comando para comprobar el estado de replicación del sistema.

sudo -i -u ${sid}adm -- hdbnsutil -sr_state

Muestra de salida en NODE1:

# sudo -i -u hdbadm -- hdbnsutil -sr_state

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: true

mode: primary
operation mode: primary
site id: 1
site name: SiteA

is source system: true
is secondary/consumer system: false
has secondaries/consumers attached: true
is a takeover active: false
is primary suspended: false

Host Mappings:
~~~~~~~~~~~~~~

cl-hdb-1 -> [SiteC] cl-hdb-3
cl-hdb-1 -> [SiteB] cl-hdb-2
cl-hdb-1 -> [SiteA] cl-hdb-1


Site Mappings:
~~~~~~~~~~~~~~
SiteA (primary/primary)
    |---SiteB (syncmem/logreplay)
    |    |---SiteC (async/logreplay)

Tier of SiteA: 1
Tier of SiteB: 2
Tier of SiteC: 3

Replication mode of SiteA: primary
Replication mode of SiteB: syncmem
Replication mode of SiteC: async

Operation mode of SiteA: primary
Operation mode of SiteB: logreplay
Operation mode of SiteC: logreplay

Mapping: SiteA -> SiteB
Mapping: SiteB -> SiteC

Hint based routing site:
done.

Muestra de salida en NODE2:

# sudo -i -u hdbadm -- hdbnsutil -sr_state

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: true

mode: syncmem
operation mode: logreplay
site id: 2
site name: SiteB

is source system: true
is secondary/consumer system: true
has secondaries/consumers attached: true
is a takeover active: false
is primary suspended: false
is timetravel enabled: false
replay mode: auto
active primary site: 1

primary masters: cl-hdb-1

Host Mappings:
~~~~~~~~~~~~~~

cl-hdb-2 -> [SiteC] cl-hdb-3
cl-hdb-2 -> [SiteB] cl-hdb-2
cl-hdb-2 -> [SiteA] cl-hdb-1


Site Mappings:
~~~~~~~~~~~~~~
SiteA (primary/primary)
    |---SiteB (syncmem/logreplay)
    |    |---SiteC (async/logreplay)

Tier of SiteA: 1
Tier of SiteB: 2
Tier of SiteC: 3

Replication mode of SiteA: primary
Replication mode of SiteB: syncmem
Replication mode of SiteC: async

Operation mode of SiteA: primary
Operation mode of SiteB: logreplay
Operation mode of SiteC: logreplay

Mapping: SiteA -> SiteB
Mapping: SiteB -> SiteC

Hint based routing site:
done.

Muestra de salida en NODE3:

# sudo -i -u hdbadm -- hdbnsutil -sr_state

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: true

mode: async
operation mode: logreplay
site id: 3
site name: SiteC

is source system: false
is secondary/consumer system: true
has secondaries/consumers attached: false
is a takeover active: false
is primary suspended: false
is timetravel enabled: false
replay mode: auto
active primary site: 2

primary masters: cl-hdb-2

Host Mappings:
~~~~~~~~~~~~~~

cl-hdb-3 -> [SiteC] cl-hdb-3
cl-hdb-3 -> [SiteB] cl-hdb-2
cl-hdb-3 -> [SiteA] cl-hdb-1


Site Mappings:
~~~~~~~~~~~~~~
SiteA (primary/primary)
    |---SiteB (syncmem/logreplay)
    |    |---SiteC (async/logreplay)

Tier of SiteA: 1
Tier of SiteB: 2
Tier of SiteC: 3

Replication mode of SiteA: primary
Replication mode of SiteB: syncmem
Replication mode of SiteC: async

Operation mode of SiteA: primary
Operation mode of SiteB: logreplay
Operation mode of SiteC: logreplay

Mapping: SiteA -> SiteB
Mapping: SiteB -> SiteC

Hint based routing site:
done.

Prueba 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 somete a prueba
  • Descripción de la prueba
  • Requisitos previos y estado inicial antes de la prueba de conmutación por error
  • Procedimiento de ensayo
  • Comportamiento y resultados esperados
  • Procedimiento de recuperación

Test1- Comprobación del 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.

Test1- Descripción

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

Test1- 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.
  • El clúster se inicia en NODE1 y NODE2.
  • El recurso de clúster SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=false.
  • Compruebe el estado de replicación del sistema SAP HANA:
    • SAP HANA la replicación del sistema multinivel está activada y sincronizada.
    • El sistema primario SAP HANA funciona en NODE1.
    • El sistema secundario SAP HANA funciona en NODE2.
    • El sistema terciario SAP HANA funciona en NODE3 y está registrado en NODE2.

Compruebe el estado actual de replicación del sistema en NODE1.

sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

Salida de ejemplo:

# sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-1 |30001 |nameserver   |        1 |      1 |SiteA     |cl-hdb-2 |    30001 |        2 |SiteB     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30007 |xsengine     |        2 |      1 |SiteA     |cl-hdb-2 |    30007 |        2 |SiteB     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30003 |indexserver  |        3 |      1 |SiteA     |cl-hdb-2 |    30003 |        2 |SiteB     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3 |    30001 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3 |    30007 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3 |    30003 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |

status system replication site "2": ACTIVE
status system replication site "3": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: SiteA

Test1- Procedimiento de ensayo

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

En NODE1, ejecute el siguiente comando.

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

Test1- Comportamiento esperado

  • SAP HANA la instancia primaria en NODE1 se bloquea.
  • El clúster detecta el primario detenido y marca el recurso como undefined.
  • El clúster promueve el sistema secundario SAP HANA en NODE2, que toma el relevo como primario.
  • El clúster libera la dirección IP virtual en NODE1, y la adquiere en el 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.

En NODE1, ejecute el siguiente comando para comprobar el estado del clúster.

pcs status --full

Salida de ejemplo:

pcs status --full

Cluster name: HDB_cluster
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-hdb-1 (1) (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
  * Last updated: Mon Jul 10 16:00:38 2023
  * Last change:  Mon Jul 10 15:58:50 2023 by root via crm_attribute on cl-hdb-2
  * 2 nodes configured
  * 6 resource instances configured

Node List:
  * Online: [ cl-hdb-1 (1) cl-hdb-2 (2) ]

Full List of Resources:
  * res_fence_ibm_powervs       (stonith:fence_ibm_powervs):     Started cl-hdb-1
  * vip_HDB_00_primary  (ocf::heartbeat:IPaddr2):        Started cl-hdb-2
  * Clone Set: SAPHanaTopology_HDB_00-clone [SAPHanaTopology_HDB_00]:
    * SAPHanaTopology_HDB_00    (ocf::heartbeat:SAPHanaTopology):        Started cl-hdb-1
    * SAPHanaTopology_HDB_00    (ocf::heartbeat:SAPHanaTopology):        Started cl-hdb-2
  * Clone Set: SAPHana_HDB_00-clone [SAPHana_HDB_00] (promotable):
    * SAPHana_HDB_00    (ocf::heartbeat:SAPHana):        Master cl-hdb-2
    * SAPHana_HDB_00    (ocf::heartbeat:SAPHana):        Stopped

Node Attributes:
  * Node: cl-hdb-1 (1):
    * hana_hdb_clone_state              : UNDEFINED
    * hana_hdb_op_mode                  : logreplay
    * hana_hdb_remoteHost               : cl-hdb-2
    * hana_hdb_roles                    : 1:P:master1::worker:
    * hana_hdb_site                     : SiteA
    * hana_hdb_srah                     : -
    * hana_hdb_srmode                   : sync
    * hana_hdb_sync_state               : SFAIL
    * hana_hdb_version                  : 2.00.070.00.1679989823
    * hana_hdb_vhost                    : cl-hdb-1
    * lpa_hdb_lpt                       : 10
    * master-SAPHana_HDB_00             : -9000
  * Node: cl-hdb-2 (2):
    * hana_hdb_clone_state              : PROMOTED
    * hana_hdb_op_mode                  : logreplay
    * hana_hdb_remoteHost               : cl-hdb-1
    * hana_hdb_roles                    : 4:P:master1:master:worker:master
    * hana_hdb_site                     : SiteB
    * hana_hdb_sra                      : -
    * hana_hdb_srah                     : -
    * hana_hdb_srmode                   : sync
    * hana_hdb_sync_state               : PRIM
    * hana_hdb_version                  : 2.00.070.00.1679989823
    * hana_hdb_vhost                    : cl-hdb-2
    * lpa_hdb_lpt                       : 1688997529
    * master-SAPHana_HDB_00             : 150

Migration Summary:
  * Node: cl-hdb-1 (1):
    * SAPHana_HDB_00: migration-threshold=5000 fail-count=1000000 last-failure='Mon Jul 10 15:56:06 2023'

Failed Resource Actions:
  * SAPHana_HDB_00_start_0 on cl-hdb-1 'not running' (7): call=51, status='complete', exitreason='', last-rc-change='2023-07-10 15:56:04 +02:00', queued=0ms, exec=1527ms

Tickets:

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

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

En NODE2, ejecute el siguiente comando para comprobar el estado de replicación del sistema.

sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

Salida de ejemplo:

# sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3 |    30001 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3 |    30007 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3 |    30003 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |

status system replication site "3": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 2
site name: SiteB

Test1- Procedimiento de recuperación

Como el recurso de clúster SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=false, es necesario registrar manualmente el sistema SAP HANA en NODE1 con el primario en NODE2.

Al registrar SAP HANA en NODE1 como secundario, cambia la topología de replicación del sistema SAP HANA. Ambos sistemas SAP HANA en NODE3 en SiteC y NODE1 en SiteA se registran entonces como secundarios de la base de datos primaria SAP HANA que se ejecuta en NODE2 en SiteB.

Si desea seguir con una topología multinivel, primero debe anular el registro del sistema SAP HANA en NODE3 en SiteC. A continuación, se registra el sistema SAP HANA en NODE1 en SiteA con el primario en NODE2 en SiteB. Por último, se registra el sistema SAP HANA en NODE3 en SiteC con secundario en NODE1 en SiteA.

En NODE1, ejecute el siguiente comando para registrar el sistema con el primario en NODE2.

sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE2} \
      --remoteInstance=${INSTNO} \
      --replicationMode=syncmem \
      --operationMode=logreplay \
      --online

En NODE1, ejecute el siguiente comando para verificar el estado de los recursos.

pcs resource status

El recurso de clúster SAPHana_${SID}_${INSTNO}-clone permanece en estado Stopped en NODE1.

Salida de ejemplo:

# pcs resource status
  * vip_HDB_00_primary  (ocf::heartbeat:IPaddr2):        Started cl-hdb-2
  * Clone Set: SAPHanaTopology_HDB_00-clone [SAPHanaTopology_HDB_00]:
    * Started: [ cl-hdb-1 cl-hdb-2 ]
  * Clone Set: SAPHana_HDB_00-clone [SAPHana_HDB_00] (promotable):
    * Masters: [ cl-hdb-2 ]
    * Stopped: [ cl-hdb-1 ]

En un nodo del clúster, ejecute el siguiente comando para borrar el estado de fallo del recurso.

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

Salida de ejemplo:

# pcs resource cleanup SAPHana_HDB_00-clone
Cleaned up SAPHana_HDB_00:0 on cl-hdb-2
Cleaned up SAPHana_HDB_00:0 on cl-hdb-1
Cleaned up SAPHana_HDB_00:1 on cl-hdb-2
Cleaned up SAPHana_HDB_00:1 on cl-hdb-1
Waiting for 1 reply from the controller
... got reply (done)

Al cabo de un rato, verifique el estado de replicación del sistema en NODE2.

sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

Salida de ejemplo:

# sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3 |    30001 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3 |    30007 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3 |    30003 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-1 |    30001 |        1 |SiteA     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-1 |    30007 |        1 |SiteA     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-1 |    30003 |        1 |SiteA     |YES           |SYNCMEM     |ACTIVE      |               |        True |

status system replication site "3": ACTIVE
status system replication site "1": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 2
site name: SiteB

La topología de replicación del sistema SAP HANA que se cambia a un entorno multidestino. El primario funciona en NODE2 en SiteB. Tanto NODE3 en SiteC como NODE1 en SiteA están registrados como secundarios. Si se produce otra absorción y NODE1 en SiteA vuelve a ser promocionado a primario, NODE3 en SiteC se desacopla.

Para crear un entorno de varios niveles con NODE3 en SiteC como sistema terciario, repita los pasos similares a Registro de NODE3 como sistema terciario SAP HANA sistema de replicación y registre NODE3 en el secundario en NODE1.

  1. En NODE1, ejecute el siguiente comando para habilitar este sitio como sistema de origen de replicación del sistema.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_enable

    Salida de ejemplo:

    # sudo -i -u hdbadm -- hdbnsutil -sr_enable
nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.

  2. En NODE3, registre el sistema en NODE1 en SiteA.

    sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC3} \
      --remoteHost=${NODE1} \
      --remoteInstance=${INSTNO} \
      --replicationMode=async \
      --operationMode=logreplay \
      --online

    # sudo -i -u hdbadm -- hdbnsutil -sr_register --name=SiteC --remoteHost=cl-hdb-1 --remoteInstance=00 --replicationMode=async --operationMode=logreplay --online
adding site ...
collecting information ...
updating local ini files ...
done.

  3. Verifique el estado de replicación del sistema en los tres nodos como se describe en Comprobación del estado de replicación del sistema SAP HANA.

Test2- Prueba del traslado manual de un recurso SAPHana a otro nodo

Utilice la siguiente información para probar el traslado manual del recurso SAPHana a otro nodo.

Test2- Descripción

Utilice los comandos del clúster para mover la instancia primaria al otro nodo del clúster.

Test2- 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.
  • El clúster se inicia en NODE1 y NODE2.
  • Cluster Resource SAPHana_${SID}_${INSTNO} se configura con AUTOMATED_REGISTER=false.
  • Compruebe el estado de replicación del sistema SAP HANA:
    • La replicación del sistema HANA está activada y sincronizada.
    • El sistema primario SAP HANA funciona en NODE2.
    • El sistema secundario SAP HANA funciona en NODE1.
    • El sistema terciario SAP HANA funciona en NODE3 y está registrado en NODE1.

Test2- Procedimiento de ensayo

  1. En NODE3, detenga el sistema terciario HANA antes de realizar el traslado controlado del primario a NODE1.

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

  2. En un nodo del clúster, ejecute el siguiente comando para volver a mover el primario a NODE1.

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

  3. Espera a que las primarias estén en NODE1. A continuación, registre NODE2 con el primario en NODE1.

    En NODE2, ejecute el siguiente comando.

    sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC2} \
      --remoteHost=${NODE1} \
      --remoteInstance=${INSTNO} \
      --replicationMode=syncmem \
      --operationMode=logreplay \
      --online

  4. En un nodo del clúster, ejecute el siguiente comando para borrar el recurso.

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

    Este comando borra la restricción de ubicación, que fue creada por el comando mover. El clúster inicia el sistema SAP HANA en NODE2.

  5. En NODE2, ejecute el siguiente comando para habilitar este sitio como sistema de origen de replicación del sistema.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_enable

  6. En NODE3, ejecute el siguiente comando para registrar el sistema en NODE2.

    sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC3} \
      --remoteHost=${NODE2} \
      --remoteInstance=${INSTNO} \
      --replicationMode=async \
      --operationMode=logreplay \
      --online

  7. En NODE3, inicie el sistema terciario HANA.

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

  8. Verifique el estado de replicación del sistema en los tres nodos como se describe en Comprobación del estado de replicación del sistema SAP HANA.

Test2- Comportamiento esperado

  • El clúster crea una restricción de ubicación para mover el recurso.
  • El clúster activa una transferencia al sistema HANA secundario en NODE1.
  • 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.
  • Registre NODE2 con el primario en NODE1.
  • Ejecute el comando pcs resource clear para eliminar la restricción de ubicación. Este comando activa el inicio de la instancia secundaria en NODE2.
  • Tras registrar e iniciar el sistema HANA en NODE3 en SiteC, el sistema HANA terciario se registra en NODE2.

Test2- Procedimiento de recuperación

No es necesario ningún procedimiento de recuperación. La secuencia de prueba restableció la topología inicial de replicación del sistema multinivel SAP HANA.

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

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

Test3- Descripción

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

Test3- 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.
  • El clúster se inicia en NODE1 y NODE2.
  • Cluster Resource SAPHana_${SID}_${INSTNO} se configura con AUTOMATED_REGISTER=false.
  • Compruebe el estado de replicación del sistema SAP HANA:
    • La replicación del sistema HANA está activada y sincronizada.
    • El sistema primario SAP HANA funciona en NODE1.
    • El sistema secundario SAP HANA funciona en NODE2.
    • El sistema secundario SAP HANA se ejecuta en NODE3 y está registrado en NODE2.

Test3- Procedimiento de ensayo

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

En NODE1, ejecute el siguiente comando.

sync; echo c > /proc/sysrq-trigger

Test3- Comportamiento esperado

  • NODE1 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 NODE2 para que asuma el papel de nueva primaria.
  • El clúster adquiere la dirección IP virtual 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.
  • El sistema terciario SAP HANA que funciona en NODE3 sigue registrado en NODE2.

Verifique el estado de replicación del sistema SAP HANA en NODE2.

sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

Salida de ejemplo:

# sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3 |    30001 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3 |    30007 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3 |    30003 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |

status system replication site "3": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 2
site name: SiteB

Test3- Procedimiento de recuperación

Acceda a la consola IBM Cloud e inicie NODE1.

  1. En NODE1, ejecute el siguiente comando para registrar el sistema con el primario en NODE2.

    sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE2} \
      --remoteInstance=${INSTNO} \
      --replicationMode=syncmem \
      --operationMode=logreplay \
      --online

  2. En NODE1, ejecute el siguiente comando para iniciar los servicios de clúster.

    pcs cluster start

  3. En un nodo del clúster, ejecute el siguiente comando para comprobar el estado del clúster.

    pcs status --full

  4. En NODE2, verifique el estado de replicación del sistema SAP HANA.

    sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

    Salida de ejemplo:

    # sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3 |    30001 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3 |    30007 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3 |    30003 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-1 |    30001 |        1 |SiteA     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-1 |    30007 |        1 |SiteA     |YES           |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-1 |    30003 |        1 |SiteA     |YES           |SYNCMEM     |ACTIVE      |               |        True |

status system replication site "3": ACTIVE
status system replication site "1": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 2
site name: SiteB

  5. Ejecute los pasos de Test1- Procedimiento de recuperación para reconstruir la topología multinivel de replicación del sistema SAP HANA para NODE3 en SiteC.

  6. Ejecute los pasos en Test2- Pruebe el movimiento manual del recurso SAPHana a otro nodo para volver a la topología inicial.

Test4- Prueba de 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.

Test4- Descripción

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

Test4- 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=false.
  • Compruebe el estado de replicación del sistema SAP HANA:
    • La replicación del sistema HANA está activa y sincronizada.
    • El sistema primario SAP HANA funciona en NODE1.
    • El sistema secundario SAP HANA funciona en NODE2.
    • El sistema terciario SAP HANA funciona en NODE3 y está registrado en NODE2.

Test4- Procedimiento de ensayo

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

En NODE2, ejecute el siguiente comando.

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

Test4- Comportamiento esperado

  • SAP HANA secundario en NODE2 accidentes.
  • El clúster detecta el sistema HANA secundario detenido y marca el recurso como failed.
  • El clúster reinicia el sistema HANA secundario.
  • El clúster detecta que la replicación del sistema vuelve a estar sincronizada.
  • El sistema terciario SAP HANA que funciona en NODE3 vuelve a estar sincronizado.

En NODE1, compruebe periódicamente el estado de replicación del sistema SAP HANA para observar los pasos de recuperación.

watch -n 5 sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

Salida de ejemplo:

# sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary          |Replication |Replication |Replication                       |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status      |Mode        |Status      |Status Details                    |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------------ |----------- |----------- |--------------------------------- |------------ |
|SYSTEMDB |cl-hdb-1 |30001 |nameserver   |        1 |      1 |SiteA     |cl-hdb-2 |    30001 |        2 |SiteB     |CONNECTION TIMEOUT |SYNCMEM     |ERROR       |Communication channel closed      |       False |
|HDB      |cl-hdb-1 |30007 |xsengine     |        2 |      1 |SiteA     |cl-hdb-2 |    30007 |        2 |SiteB     |CONNECTION TIMEOUT |SYNCMEM     |ERROR       |Communication channel closed      |       False |
|HDB      |cl-hdb-1 |30003 |indexserver  |        3 |      1 |SiteA     |cl-hdb-2 |    30003 |        2 |SiteB     |CONNECTION TIMEOUT |SYNCMEM     |ERROR       |Communication channel closed      |       False |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3 |    30001 |        3 |SiteC     |                   |UNKNOWN     |UNKNOWN     |Site with id '2' is not reachable |       False |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3 |    30007 |        3 |SiteC     |                   |UNKNOWN     |UNKNOWN     |Site with id '2' is not reachable |       False |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3 |    30003 |        3 |SiteC     |                   |UNKNOWN     |UNKNOWN     |Site with id '2' is not reachable |       False |

status system replication site "2": ERROR
status system replication site "3": UNKNOWN
overall system replication status: ERROR

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: SiteA

Test4- 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 que se muestran en la salida de pcs status.

  1. En un nodo del clúster, ejecute el siguiente comando.

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

  2. Compruebe el estado del clúster.

    pcs status --full

Test5- Probar la activación de DR en el nodo que ejecuta la base de datos terciaria

Utilice la siguiente información para probar el fallo de ambos nodos en el espacio de trabajo primario.

Test5- Descripción

Simule una caída de los nodos que ejecutan la base de datos primaria y secundaria SAP HANA.

Test5- 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.
  • El clúster se inicia en NODE1 y NODE2.
  • Cluster Resource SAPHana_${SID}_${INSTNO} se configura con AUTOMATED_REGISTER=false.
  • Compruebe el estado de replicación del sistema SAP HANA:
    • La replicación del sistema HANA está activa y sincronizada.
    • El sistema primario SAP HANA funciona en NODE1.
    • El sistema secundario SAP HANA funciona en NODE2.
    • El sistema terciario SAP HANA funciona en NODE3 y está registrado en NODE2.

Test5- Procedimiento de ensayo

Bloquea el primario en NODE1 y el secundario en NODE2 enviando una petición de bloqueo del sistema en ambos nodos.

  1. En NODE1, ejecute el siguiente comando.

    sync; echo c > /proc/sysrq-trigger

  2. En NODE2, ejecute el siguiente comando.

    sync; echo c > /proc/sysrq-trigger

  3. En NODE3, ejecute el siguiente comando para activar el sistema HANA como nuevo primario.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_takeover

    Salida de ejemplo:

    # sudo -i -u hdbadm -- hdbnsutil -sr_takeover
done.

Test5- Comportamiento esperado

  • NODE1 y NODE2 se detienen inmediatamente.
  • Tras la toma de posesión manual, NODE3 ejecuta el sistema primario SAP HANA.
  • Una aplicación, como SAP NetWeaver, puede conectarse al sistema SAP HANA en NODE3.

En NODE3, ejecute el siguiente comando para verificar que el sistema SAP HANA se ejecuta como primario.

sudo -i -u ${sid}adm -- hdbnsutil -sr_state

Salida de ejemplo:

# sudo -i -u hdbadm -- hdbnsutil -sr_state

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: true

mode: primary
operation mode: primary
site id: 3
site name: SiteC

is source system: true
is secondary/consumer system: false
has secondaries/consumers attached: false
is a takeover active: false
is primary suspended: false

Host Mappings:
~~~~~~~~~~~~~~

cl-hdb-3 -> [SiteC] cl-hdb-3


Site Mappings:
~~~~~~~~~~~~~~
SiteC (primary/primary)

Tier of SiteC: 1

Replication mode of SiteC: primary

Operation mode of SiteC: primary


Hint based routing site:
done.

Test5- Procedimiento de recuperación

El procedimiento de recuperación tras una toma de control al sistema terciario SAP HANA es complejo y se documenta como una prueba independiente en la Test6 sección.

Test6- Restauración de la topología original de replicación del sistema multinivel SAP HANA

Utilice la siguiente información para volver a la topología de replicación del sistema original después de un traspaso al sistema terciario SAP HANA.

Consulte la siguiente documentación SAP.

Test6- Descripción

Reactive el clúster en el espacio de trabajo primario y restaure la topología original de replicación del sistema.

Test6- Requisitos previos

  • Un clúster RHEL HA Add-On de dos nodos para la replicación del sistema HANA en el espacio de trabajo primario.
  • Se detienen las dos instancias de servidor virtual del clúster.
  • El sistema primario SAP HANA funciona en NODE3.

Test6- Procedimiento de ensayo

  1. Acceda a la consola IBM Cloud e inicie tanto NODE1 como NODE2.

  2. Espere hasta que ambos nodos vuelvan a estar disponibles.

  3. Asegúrese de que los servicios de clúster del complemento de HA Red Hat están detenidos en ambos nodos de clúster NODE1 y NODE2.

  4. En NODE3, compruebe que la replicación del sistema SAP HANA está activada.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_state

  5. En NODE1, ejecute el siguiente comando para establecer una variable de entorno con el nombre de host NODE3.

    export NODE3=<Hostname 3>   # Hostname of virtual server instance 3 (production tertiary)

  6. En NODE1, ejecute el siguiente comando para registrar el sistema SAP HANA con el primario en NODE3.

    sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE3} \
      --remoteInstance=${INSTNO} \
      --replicationMode=async \
      --operationMode=logreplay \
      --online

  7. En NODE1, compruebe la configuración de replicación del sistema.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_state

    Salida de ejemplo:

    
System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: false

mode: async
operation mode: unknown
site id: 1
site name: SiteA

is source system: unknown
is secondary/consumer system: true
has secondaries/consumers attached: unknown
is a takeover active: false
is primary suspended: false
is timetravel enabled: false
replay mode: auto
active primary site: 3

primary masters: cl-hdb-3
done.

  8. En NODE1, inicie el sistema SAP HANA para iniciar la replicación del sistema.

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

  9. En NODE3, compruebe el estado de replicación del sistema y espere hasta que el secundario en NODE1 esté totalmente sincronizado.

    sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

    Salida de ejemplo:

    # sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary |Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host      |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |--------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-3 |30001 |nameserver   |        1 |      3 |SiteC     |cl-hdb-1  |    30001 |        1 |SiteA     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-3 |30007 |xsengine     |        2 |      3 |SiteC     |cl-hdb-1  |    30007 |        1 |SiteA     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-3 |30003 |indexserver  |        3 |      3 |SiteC     |cl-hdb-1  |    30003 |        1 |SiteA     |YES           |ASYNC       |ACTIVE      |               |        True |

status system replication site "1": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 3
site name: SiteC

Necesita una ventana de tiempo de inactividad para volver a mover el rol primario a NODE1. Todos los servidores de aplicaciones conectados a NODE3 deben detenerse.

Una toma de control con handshake suspende todas las transacciones en el sistema primario en NODE3 y la toma de control sólo se ejecuta cuando todo el redo log restante está disponible en NODE1.

  1. En NODE1, ejecute el siguiente comando para asumir el rol primario.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_takeover --suspendPrimary

  2. En NODE1, compruebe que el sistema HANA se ejecuta como primario.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_state

  3. En NODE3, ejecute el siguiente comando para verificar el estado de replicación del sistema.

    sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

    # sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication                      |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details                   |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------------------------- |------------ |
|SYSTEMDB |cl-hdb-3 |30001 |nameserver   |        1 |      3 |SiteC     |cl-hdb-1 |    30001 |        1 |          |PRIMARY       |            |            |IS PRIMARY (e.g. after takeover) |       False |
|HDB      |cl-hdb-3 |30007 |xsengine     |        2 |      3 |SiteC     |cl-hdb-1 |    30007 |        1 |          |PRIMARY       |            |            |IS PRIMARY (e.g. after takeover) |       False |
|HDB      |cl-hdb-3 |30003 |indexserver  |        3 |      3 |SiteC     |cl-hdb-1 |    30003 |        1 |          |PRIMARY       |            |            |IS PRIMARY (e.g. after takeover) |       False |

status system replication site "1": ERROR
overall system replication status: ERROR

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 3
site name: SiteC

El siguiente resumen muestra el estado después de estos pasos.

  • NODE1 se ejecuta como primario, pero no hay ninguna aplicación conectada.
  • NODE2 está activada, pero SAP HANA no se ha iniciado.
  • NODE3 está activado y SAP HANA está bloqueado en suspendPrimary modo.
  • Red Hat Los servicios de clúster del complemento de HA se detienen en NODE1 y NODE2.

  1. En NODE2, ejecute el siguiente comando para registrarse con el primario en NODE1.

    sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC2} \
      --remoteHost=${NODE1} \
      --remoteInstance=${INSTNO} \
      --replicationMode=syncmem \
      --operationMode=logreplay \
      --online

  2. En NODE2, inicie SAP HANA para iniciar la replicación.

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

  3. En NODE1, compruebe el estado de replicación del sistema y espere hasta que el secundario en NODE2 esté totalmente sincronizado.

    sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

    Salida de ejemplo:

    # sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary |Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host      |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |--------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-1 |30001 |nameserver   |        1 |      1 |SiteA     |cl-hdb-2  |    30001 |        2 |SiteB     |YES           |SYNC        |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30007 |xsengine     |        2 |      1 |SiteA     |cl-hdb-2  |    30007 |        2 |SiteB     |YES           |SYNC        |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30003 |indexserver  |        3 |      1 |SiteA     |cl-hdb-2  |    30003 |        2 |SiteB     |YES           |SYNC        |ACTIVE      |               |        True |

status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: SiteA

El siguiente resumen muestra el estado después de estos pasos.

  • NODE1 se ejecuta como primario, pero no hay ninguna aplicación conectada.
  • NODE2 corre como secundario.
  • NODE3 está activado y SAP HANA está bloqueado en suspendPrimary modo.
  • Red Hat Los servicios de clúster del complemento de HA se detienen en NODE1 y NODE2.

  1. En un nodo de clúster, ejecute el siguiente comando para iniciar el clúster.

    pcs cluster start --all

  2. Compruebe el estado del clúster y verifique que vuelve a estar plenamente operativo.

    pcs status --full

El siguiente resumen muestra el estado después de estos pasos.

  • NODE1 se ejecuta como primaria.
  • NODE2 corre como secundario.
  • Red Hat Los servicios de clúster de HA Add-On se inician y el clúster gestiona la replicación del sistema SAP HANA en NODE1 y NODE2.
  • NODE3 está activado y SAP HANA está bloqueado en suspendPrimary modo.

  1. En NODE2, ejecute el siguiente comando para habilitarlo como sitio de origen de replicación del sistema.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_enable

    Salida de ejemplo:

    # sudo -i -u hdbadm -- hdbnsutil -sr_enable
nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.

  2. En NODE2, compruebe la configuración de replicación del sistema.

    sudo -i -u ${sid}adm -- hdbnsutil -sr_state

    Salida de ejemplo:

    # sudo -i -u hdbadm -- hdbnsutil -sr_state

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: true

mode: sync
operation mode: logreplay
site id: 2
site name: SiteB

is source system: true
is secondary/consumer system: true
has secondaries/consumers attached: false
is a takeover active: false
is primary suspended: false
is timetravel enabled: false
replay mode: auto
active primary site: 1

primary masters: cl-hdb-1

Host Mappings:
~~~~~~~~~~~~~~

cl-hdb-2 -> [SiteB] cl-hdb-2
cl-hdb-2 -> [SiteA] cl-hdb-1


Site Mappings:
~~~~~~~~~~~~~~
SiteA (primary/primary)
    |---SiteB (sync/logreplay)

Tier of SiteA: 1
Tier of SiteB: 2

Replication mode of SiteA: primary
Replication mode of SiteB: sync

Operation mode of SiteA: primary
Operation mode of SiteB: logreplay

Mapping: SiteA -> SiteB

Hint based routing site:
done.

  3. En NODE3, ejecute el siguiente comando para registrar el sistema en NODE2.

    sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_register \
      --name=${DC3} \
      --remoteHost=${NODE2} \
      --remoteInstance=${INSTNO} \
      --replicationMode=async \
      --operationMode=logreplay \
      --online

  4. En NODE1, ejecute el siguiente comando para verificar la nueva topología de replicación del sistema SAP HANA.

    sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

    El sistema SAP HANA en NODE3 en SiteC reaparece en la topología de replicación del sistema SAP HANA. Cuando se ejecuta el comando hdbnsutil -sr_register, el sistema se detiene y se muestra CONNECTION TIMEOUT en la salida.

    Salida de ejemplo:

    # sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary|Secondary |Secondary |Secondary |Secondary          |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host     |Port      |Site ID   |Site Name |Active Status      |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |-------- |--------- |--------- |--------- |------------------ |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-1 |30001 |nameserver   |        1 |      1 |SiteA     |cl-hdb-2 |    30001 |        2 |SiteB     |YES                |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30007 |xsengine     |        2 |      1 |SiteA     |cl-hdb-2 |    30007 |        2 |SiteB     |YES                |SYNCMEM     |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30003 |indexserver  |        3 |      1 |SiteA     |cl-hdb-2 |    30003 |        2 |SiteB     |YES                |SYNCMEM     |ACTIVE      |               |        True |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3 |    30001 |        3 |SiteC     |CONNECTION TIMEOUT |ASYNC       |UNKNOWN     |               |       False |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3 |    30007 |        3 |SiteC     |CONNECTION TIMEOUT |ASYNC       |UNKNOWN     |               |       False |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3 |    30003 |        3 |SiteC     |CONNECTION TIMEOUT |ASYNC       |UNKNOWN     |               |       False |

status system replication site "2": ACTIVE
status system replication site "3": UNKNOWN
overall system replication status: UNKNOWN

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: SiteA

  5. En NODE3, ejecute el siguiente comando para iniciar el sistema terciario HANA.

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

El siguiente resumen muestra el estado final después de estos pasos.

  • NODE1 se ejecuta como primaria.
  • NODE2 corre como secundario.
  • Red Hat Los servicios de clúster de HA Add-On se inician y el clúster gestiona la replicación del sistema SAP HANA en NODE1 y NODE2.
  • NODE3 funciona como terciaria.

En NODE1, ejecute el siguiente comando para verificar la topología de replicación del sistema SAP HANA.

sudo -i -u ${sid}adm -- HDBSettings.sh systemReplicationStatus.py

Salida de ejemplo:

# sudo -i -u hdbadm -- HDBSettings.sh systemReplicationStatus.py
|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary |Secondary |Secondary |Secondary |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host      |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |---------|----- |------------ |--------- |------- |--------- |--------- |--------- |--------- |--------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |cl-hdb-1 |30001 |nameserver   |        1 |      1 |SiteA     |cl-hdb-2  |    30001 |        2 |SiteB     |YES           |SYNC        |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30007 |xsengine     |        2 |      1 |SiteA     |cl-hdb-2  |    30007 |        2 |SiteB     |YES           |SYNC        |ACTIVE      |               |        True |
|HDB      |cl-hdb-1 |30003 |indexserver  |        3 |      1 |SiteA     |cl-hdb-2  |    30003 |        2 |SiteB     |YES           |SYNC        |ACTIVE      |               |        True |
|SYSTEMDB |cl-hdb-2 |30001 |nameserver   |        1 |      2 |SiteB     |cl-hdb-3  |    30001 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30007 |xsengine     |        2 |      2 |SiteB     |cl-hdb-3  |    30007 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |
|HDB      |cl-hdb-2 |30003 |indexserver  |        3 |      2 |SiteB     |cl-hdb-3  |    30003 |        3 |SiteC     |YES           |ASYNC       |ACTIVE      |               |        True |

status system replication site "2": ACTIVE
status system replication site "3": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: SiteA