Soluciona problemas de configuraciones de alta disponibilidad para SAP

En las opciones de configuración de alta disponibilidad para SAP en Google Cloud, la causa raíz de los problemas puede estar en el software de agrupamiento en clústeres, el software de SAP, la infraestructura de Google Cloud o algunas combinaciones de estos factores.

Analiza los registros de Pacemaker en Cloud Logging

En el siguiente video, se muestra cómo comenzar a solucionar problemas de configuración de alta disponibilidad para SAP en Google Cloud mediante Cloud Logging.

Un nodo con errores en un clúster de Linux no se reinicia de forma correcta después de una conmutación por error

Si tu clúster de alta disponibilidad de Linux usa el agente de protección fence_gce y una VM protegida no vuelve a unirse al clúster después de una conmutación por error, es posible que debas retrasar el inicio del software de Corosync cuando se reinicien las VMs protegidas.

Problema

Durante una conmutación por error, el agente fence_gce protege la VM de Compute Engine con errores, lo que reinicia y vuelve a unir el clúster antes de que Pacemaker registre la acción de valla como completa. Debido a que la acción de protección no se registró como completa, la VM reiniciada cierra los servicios de Pacemaker y Corosync, y abandona el clúster.

Diagnóstico

Para confirmar que este es tu problema, haz lo siguiente:

Asegúrate de que tu clúster esté usando el agente fence_gce:

RHEL

pcs config

SLES

crm config show

La definición del agente de protección incluye fence_gce.

RHEL

Stonith Devices:
Resource: STONITH-example-ha-vm1 (class=stonith type=fence_gce)
Attributes: port=example-ha-vm1 project=example-project-123456 zone=us-central1-a
Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm1-monitor-interval-60s)
Resource: STONITH-example-ha-vm2 (class=stonith type=fence_gce)
Attributes: port=example-ha-vm2 project=example-project-123456 zone=us-central1-c
Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm2-monitor-interval-60s)

SLES

primitive fence-example-ha-vm1 stonith:fence_gce \
 op monitor interval=300s timeout=120s \
 op start interval=0 timeout=60s \
 params port=example-ha-vm1 zone=us-central1-a project=example-project-123456
primitive fence-example-ha-vm2 stonith:fence_gce \
 op monitor interval=300s timeout=120s \
 op start interval=0 timeout=60s \
 params port=example-ha-vm2 zone=us-central1-c project=example-project-123456

Verifica el registro del sistema en busca de los siguientes mensajes:

DATESTAMP> node2 stonith-ng[1106]:  notice: Operation reboot of node2 by node1 for stonith_admin.1366@node1.c3382af8: OK
DATESTAMP> node2 stonith-ng[1106]:   error: stonith_construct_reply: Triggered assert at commands.c:2343 : request != NULL
DATESTAMP> node2 stonith-ng[1106]: warning: Can't create a sane reply
DATESTAMP> node2 crmd[1110]:    crit: We were allegedly just fenced by node1 for node1!
DATESTAMP> node2 pacemakerd[1055]: warning: Shutting cluster down because crmd[1110] had fatal failure

Solución

Configura los sistemas operativos en ambos nodos del clúster para retrasar el inicio de Corosync y garantizar que la acción de protección tenga tiempo de registrarse como completa con Pacemaker en el nodo principal nuevo. Además, configura el valor del tiempo de espera de reinicio de Pacemaker para que tenga en cuenta la demora.

Para configurar un inicio retrasado de Corosync, haz lo siguiente:

Coloca el clúster en modo de mantenimiento:

RHEL

pcs property set maintenance-mode=true

SLES

crm configure property maintenance-mode="true"

En cada nodo del clúster como raíz, establece un retraso de inicio para Corosync:
1. Crea un archivo directo systemd:
```
systemctl edit corosync.service
```
2. Agrega las siguientes líneas al archivo:
```
[Service]
ExecStartPre=/bin/sleep 60
```
3. Guarda el archivo y sal del editor.
4. Vuelve a cargar la configuración del administrador del sistema.
```
systemctl daemon-reload
```
En cualquiera de los nodos del clúster como raíz, verifica que el valor de tiempo de espera de Pacemaker para el reinicio esté configurado para ambos agentes de protección:
1. Verifica el valor de pcmk_reboot_timeout:
```
crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout
```
  Reemplaza FENCE_AGENT_NAME por el nombre del agente de protección.
2. Si no se encuentra el parámetro pcmk_reboot_timeout o se configuró en un valor inferior a 300, establece el valor en ambos agentes de protección:
```
crm_resource --resource FENCE_AGENT_NAME --set-parameter=pcmk_reboot_timeout --parameter-value=300
```
  Reemplaza FENCE_AGENT_NAME por el nombre del agente de protección.
  
  El valor de pcmk_reboot_timeout debe ser mayor que la suma de los siguientes elementos:
  - El tiempo de espera de token de Corosync
  - El tiempo de espera de consenso de Corosync, que de forma predeterminada es el producto de token * 1.2
  - El tiempo que tarda en completarse una operación de reinicio, incluido cualquier atributo de retraso
  En Google Cloud, 300 segundos son suficientes para la mayoría de los clústeres.
3. Confirma el valor pcmk_reboot_timeout nuevo:
```
crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout
```
  Reemplaza FENCE_AGENT_NAME por el nombre del agente de protección.

Quita el clúster del modo de mantenimiento:

RHEL

pcs property set maintenance-mode=false

SLES

crm configure property maintenance-mode="false"

Afinidad de nodos no intencional que favorece un nodo en particular

Cuando mueves recursos de forma manual en un clúster de alta disponibilidad mediante los comandos del clúster, descubres que se configuró una afinidad automática o preferencia de cliente para favorecer un nodo en particular.

Problema

En tu clúster de alta disponibilidad de Linux Pacemaker para SAP HANA o SAP NetWeaver, los recursos como el sistema SAP HANA o los servicios centrales de SAP NetWeaver solo se ejecutan en un nodo de clúster en particular y no conmutan por error como se espera durante un evento de falla de nodo.

Por lo tanto, podrías experimentar problemas como los siguientes:

Cuando activas la conmutación por error del servicio de ASCS de SAP NetWeaver mediante la emisión de un comando de Pacemaker a move un recurso a un nodo del clúster, el recurso no se inicia y muestra el estado stopped.
Cuando emites el comando standby a un nodo del clúster para forzar a todos los recursos a moverse al otro nodo, los recursos no se inician.

Diagnóstico

Revisa los registros de Pacemaker para ver el mensaje que menciona un recurso en particular que no se puede ejecutar en ningún lugar. Por ejemplo:
```
2021-05-24 21:39:58 node_1 pacemaker-schedulerd (native_color) info:
 Resource NW1-ASCS01 cannot run anywhere
```
Verifica la configuración de la restricción de ubicación de Pacemaker para identificar las restricciones que podrían impedir que los recursos se ejecuten en un nodo de clúster determinado.

Para verificar la configuración de la restricción de ubicación de Pacemaker, sigue estos pasos:
1. Muestra las restricciones de ubicación:
```
cibadmin --query --scope constraints | grep rsc_location
```
2. Verifica las restricciones de ubicación:
  - Restricción de ubicación explícita: encontrarás restricciones de ubicación con puntuación INFINITY (preferir el nodo) o -INFINITY (evitar el nodo). Por ejemplo:
```
<rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>
```
    No debe haber ninguna restricción de ubicación con una puntuación INFINITY o -INFINITY que no sean los agentes de protección. En todos los clústeres de alta disponibilidad, los agentes de protección se definen en una restricción de ubicación con una puntuación de -INFINITY, para evitar que se ejecuten en el nodo que es el objetivo de protección.
  - Restricción de ubicación implícita: Cuando emites el comando Pacemaker para mover un recurso a un nodo de clúster o bloquear un recurso a fin de que se ejecute en un nodo de clúster, una restricción de ubicación implícita con el prefijo cli-ban o cli-prefer se agrega al ID de restricción. Por ejemplo:
```
<rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>
```

Solución

Asegúrate de que las restricciones de ubicación se especifiquen como se explica en nuestras guías de implementación:
Para corregir una restricción de ubicación explícita, bórrala:
RHEL
```
pcs constraint remove RESOURCE_LOCATION_ID
```
SLES
```
crm configure delete RESOURCE_LOCATION_ID
```
Reemplaza RESOURCE_LOCATION_ID por el ID de restricción de ubicación.
Para corregir una restricción de ubicación implícita, quita todas las restricciones definidas en el recurso especificado.

Después de cada comando que usas para mover o bloquear un recurso, ejecuta el siguiente comando a fin de quitar todas las restricciones:
RHEL
```
pcs resource clear RESOURCE_NAME
```
SLES
```
crm resource clear RESOURCE_NAME
```
Reemplaza RESOURCE_NAME por el nombre del recurso que deseas mover.

El agente de protección experimentó un error operativo

El agente de protección informó un error en el estado del clúster.

Problema

En tu clúster de alta disponibilidad de Linux Pacemaker para SAP HANA o SAP NetWeaver, el agente de protección informó un error en el estado del clúster. Por ejemplo:

Failed Resource Actions:
   STONITH-ha-node-01_monitor_300000 on ha-node-02 'unknown error' (1): call=153, status=Timed Out, exitreason='',  last-rc-change='Mon Dec 21 23:40:47 2023', queued=0ms, exec=60003ms

Diagnóstico

El agente de protección implementado en tu clúster de alta disponibilidad de SAP HANA o SAP NetWeaver accede al servidor de la API de Compute Engine con regularidad para verificar el estado de la instancia de destino de la protección. Si hay un retraso temporal en la respuesta de la llamada a la API o si hay una interrupción en la red, la operación de supervisión del agente de protección puede fallar o agotar el tiempo de espera.

Para verificar el estado del agente de protección, ejecuta el siguiente comando:

RHEL

pcs status

SLES

crm status

Si el estado del agente de protección es stopped, usa una de las opciones de la solución para resolver el error.

El error operativo del agente de protección puede hacer que el agente de protección se detenga, pero Pacemaker aún llama a los agentes de protección con una directiva de detención en un evento de protección.

Solución

Si el estado de la protección de la protección es stopped, realiza una de las siguientes acciones:

Para restablecer de forma manual el recuento de fallas y reiniciar la protección, ejecuta el siguiente comando:
RHEL
```
pcs resource cleanup FENCE_AGENT_NAME
```
SLES
```
crm resource cleanup FENCE_AGENT_NAME
```
Reemplaza FENCE_AGENT_NAME por el nombre del agente de protección.
Para quitar de forma automática el error operativo del agente de protección, configura el parámetro failure-timeout.

El parámetro failure-timeout restablece el recuento de fallas después de la duración especificada y borra los errores operativos. La aplicación de este parámetro no requiere que reinicies el clúster ni que coloques el clúster en modo de mantenimiento.

Para configurar el parámetro failure-timeout, ejecuta el siguiente comando:
```
crm_resource --meta --resource FENCE_AGENT_NAME --set-parameter failure-timeout --parameter-value DURATION
```
Reemplaza lo siguiente:
- FENCE_AGENT_NAME: es el nombre del agente de protección.
- DURATION: la duración que sigue a la última falla operativa después de la cual se restablece el recuento de fallas y se reinicia el agente de protección.

Se detuvo el agente de recursos

No se pudo iniciar un agente de recursos y permanece en el estado Stopped.

Problema

En tu clúster de alta disponibilidad de Linux Pacemaker para SAP HANA o SAP NetWeaver, el agente de protección informó un error en el estado del clúster. Por ejemplo:

Failed Resource Actions:
   rsc_SAPHana_DV0_HDB00_start_0 on ha-node-02 'error' (1): call=91, status='complete', last-rc-change='Wed Oct 18 18:00:31 2023', queued=0ms, exec=19010ms

Diagnóstico

Si falla un agente de recursos en ejecución, Pacemaker intenta detener el agente y volver a iniciarlo. Si por algún motivo la operación de inicio falla, Pacemaker establece el recuento de fallas del recurso en INFINITY y, luego, intenta iniciar el agente en otro nodo. Si el agente de recursos no se inicia en ningún nodo, el agente de recursos permanece en el estado Stopped.

Para verificar el estado del agente de protección, ejecuta el siguiente comando:

RHEL

pcs status

SLES

crm status

Para SAP HANA, en el siguiente ejemplo, se muestra el agente de recursos en el estado Stopped en el nodo hana-b:

Full List of Resources:
  * STONITH-hana-a        (stonith:external/gcpstonith):   Started hana-b
  * STONITH-hana-b        (stonith:external/gcpstonith):   Started hana-a
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started hana-a
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started hana-a
  * Clone Set: cln_SAPHanaTopology_DV0_HDB00 [rsc_SAPHanaTopology_DV0_HDB00]:
    * Started: [ hana-a hana-b ]
  * Clone Set: msl_SAPHana_DV0_HDB00 [rsc_SAPHana_DV0_HDB00] (promotable):
    * Masters: [ hana-a ]
    * Stopped: [ hana-b ]
  * STONITH-scaleup-majority    (stonith:external/gcpstonith):   Started hana-b

Solución

Si un agente de recursos está en el estado Stopped, haz lo siguiente:

Inicia el agente de recursos de forma manual mediante el restablecimiento del recuento de fallas:
RHEL
```
pcs resource cleanup RESOURCE_AGENT_NAME
```
SLES
```
crm resource cleanup RESOURCE_AGENT_NAME
```
Reemplaza RESOURCE_AGENT_NAME por el nombre del recurso. Por ejemplo, rsc_SAPHana_DV0_HDB00.
Asegúrate de que el estado del agente de recursos alcance el estado Started:
```
crm_mon
```
Si el agente de recursos aún no se inicia, recopila la información de diagnóstico relevante y comunícate con el equipo de asistencia.