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 alguna combinación 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:

1. Coloca el clúster en modo de mantenimiento:

   RHEL

   pcs property set maintenance-mode=true

   SLES

   crm configure property maintenance-mode="true"

2. 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

3. 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.

4. 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:

  • Guía de configuración de clústeres con escalamiento vertical de alta disponibilidad para SAP HANA en RHEL
  • Guía de configuración de clústeres con escalamiento vertical de alta disponibilidad para SAP HANA en SLES
  • Guía de configuración de clústeres de alta disponibilidad para SAP NetWeaver en RHEL
  • Guía de configuración manual de clústeres de alta disponibilidad para SAP NetWeaver en SLES

• 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.

El agente de protección gcpstonith está obsoleto

El agente de perímetro gcpstonith está activo en tu configuración. Este agente está obsoleto y el equipo de Atención al cliente te informó que debes cambiar a fence_gce.

Problema

En tu clúster de alta disponibilidad de Linux Pacemaker para SAP HANA en SUSE Linux, se usa el agente de protección gcpstonith. Por ejemplo:

 # crm status | grep gcpstonith
   * STONITH-hana-vm1   (stonith:external/gcpstonith):   Started hana-vm2
   * STONITH-hana-vm2   (stonith:external/gcpstonith):   Started hana-vm1

Diagnóstico

El agente de protección implementado en tu clúster de alta disponibilidad de SAP HANA se debe actualizar para usar el agente de protección fence_gce incluido en el SO. La secuencia de comandos del agente gcpstonith se entregó en sistemas heredados y fence_gce la reemplazó. fence_gce se proporciona como parte del paquete fence-agents de SUSE Linux. gcpstonith solo se entregaba como parte de las implementaciones de HANA en SUSE Linux.

Solución

Para migrar desde gcpstonith en SUSE Linux, completa los siguientes pasos:

1. Instala los siguientes paquetes adicionales específicos de tu sistema operativo:

   • Para SLES 15: python3-oauth2client y python3-google-api-python-client

   • Para SLES 12: python-google-api-python-client, python-oauth2client y python-oauth2client-gce

   Para instalar estos paquetes en tu sistema operativo, usa el siguiente comando:

   SLES 15

   zypper in -y python3-oauth2client python3-google-api-python-client

   SLES 12

   zypper in -y python-google-api-python-client python-oauth2client python-oauth2client-gce

2. Actualiza el paquete fence-agents para asegurarte de tener instalada la versión más reciente:

   zypper update -y fence-agents

3. Coloca el clúster en modo de mantenimiento:

   crm configure property maintenance-mode=true

4. Borra todos los dispositivos de protección de tu clúster. Cuando borres el último dispositivo de cercado, es posible que se te solicite que confirmes que no se definen recursos STONITH en tu clúster.

   crm configure delete FENCING_RESOURCE_PRIMARY

   crm configure delete FENCING_RESOURCE_SECONDARY

5. Vuelve a crear el dispositivo de protección para la instancia principal:

   crm configure primitive FENCING_RESOURCE_PRIMARY stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="PRIMARY_INSTANCE_NAME" zone="PRIMARY_ZONE" \
    project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

6. Vuelve a crear el dispositivo de protección para la instancia secundaria:

   crm configure primitive FENCING_RESOURCE_SECONDARY stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="SECONDARY_INSTANCE_NAME" zone="SECONDARY_ZONE" \
    project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4

7. Establece las restricciones de ubicación:

   crm configure location FENCING_LOCATION_NAME_PRIMARY \
    FENCING_RESOURCE_PRIMARY -inf: "PRIMARY_INSTANCE_NAME"
   
   crm configure location FENCING_LOCATION_NAME_SECONDARY \
    FENCING_RESOURCE_SECONDARY -inf: "SECONDARY_INSTANCE_NAME"
   

8. Quita el clúster del modo de mantenimiento:

   crm configure property maintenance-mode=false

9. Verifica la configuración:

   crm config show related:FENCING_RESOURCE_PRIMARY
   

10. Verifica el estado del clúster:

    # crm status | grep fence_gce
      STONITH-hana-vm1   (stonith:fence_gce):   Started hana-vm2
      STONITH-hana-vm2   (stonith:fence_gce):   Started hana-vm1
    

Se detuvo el agente de recursos

Un agente de recursos no se pudo iniciar 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:fence_gce):   Started hana-b
  * STONITH-hana-b        (stonith:fence_gce):   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:fence_gce):   Started hana-b

Solución

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

1. Para iniciar el agente de recursos de forma manual, restablece el 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.

2. 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.

Falla de comunicación entre VMs debido a las rutas de red locales para las IP virtuales

El tráfico de red de una VM de backend a otra falla debido a las rutas de red locales para las IP virtuales.

Problema

Cuando las VMs forman parte de un balanceador de cargas de red de transferencia interno, la comunicación de red del backend a las rutas de IP virtual (VIP) del ILB se considera local y la controla el dispositivo de bucle invertido.

Este comportamiento de bucle invertido evita que una VM de backend use correctamente el VIP del ILB para llegar a servicios que podrían estar alojados en otras VMs de backend que usan el ILB, lo que genera una falla de comunicación.

Por ejemplo, una falla de comunicación entre ASCS y ERS en un clúster de alta disponibilidad de SAP Netweaver configurado como backend de balanceador de cargas.

La prueba telnet genera un error Connection Refused porque este enrutamiento local no permitiría que el tráfico llegue a la VM prevista:

   [root@test-server-ha ~]# telnet IP_ADDRESS_OF_ILB PORT_NUMBER
   Trying IP_ADDRESS_OF_ILB...
   telnet: connect to address IP_ADDRESS_OF_ILB: Connection refused

Diagnóstico

Requisito:

Las VMs afectadas aparecen como miembros de un grupo de instancias no administrado que se configura como un backend de balanceador de cargas.

Cuando una VM de backend dentro de un balanceador de cargas interno (ILB) inicia la comunicación con la IP virtual (VIP) del ILB, se produce un comportamiento de enrutamiento específico.

Aunque el VIP se configura en una interfaz de red estándar, como eth0, y se muestra en la tabla de enrutamiento local, el kernel enruta los paquetes destinados a este VIP local con la interfaz de bucle invertido lo. Este bucle invertido interno significa que el paquete nunca sale de la VM de origen para que el ILB lo procese.

Si bien funciona la comunicación directa entre las VMs de backend con sus IP individuales, este comportamiento de bucle invertido evita que una VM de backend use correctamente el VIP del ILB para llegar a servicios que podrían estar alojados en otras VMs de backend con el equilibrador de carga de red de transferencia interna.

   [root@test-server-ha ~]# ip route show table local
   local IP_ADDRESS_OF_ILB dev eth0 proto 66 kernel scope host src IP_ADDRESS_OF_ILB
   local IP_ADDRESS_OF_THE_CURRENT_NODE dev eth0 proto kernel scope host src IP_ADDRESS_OF_THE_CURRENT_NODE
   local IP_ADDRESS_OF_THE_OTHER_NODE dev eth0 proto kernel scope host src IP_ADDRESS_OF_THE_OTHER_NODE
   broadcast IP_ADDRESS dev lo proto kernel scope link src IP_ADDRESS
   local IP_ADDRESS dev lo proto kernel scope host src IP_ADDRESS
   broadcast IP_ADDRESS dev lo proto kernel scope link src IP_ADDRESS

   ip route get IP_ADDRESS_OF_ILB

El resultado de este comando muestra una interfaz de bucle invertido lo:

   [root@test-server-ha ~]# ip route get IP_ADDRESS_OF_ILB
   local IP_ADDRESS_OF_ILB dev lo src IP_ADDRESS_OF_ILB uid 0
   cache <local>

Solución

Para habilitar la comunicación de backend entre las VMs, modifica la configuración de google-guest-agent, que se incluye en el entorno invitado de Linux para todas las imágenes públicas de Linux que proporciona Google Cloud.

Para habilitar las comunicaciones de backend del balanceador de cargas, realiza los siguientes pasos en cada VM que forma parte de tu clúster:

1. Detén el agente:

   sudo service google-guest-agent stop
   

2. Abre o crea el archivo /etc/default/instance_configs.cfg para editarlo:

   sudo vi /etc/default/instance_configs.cfg
   

3. En el archivo /etc/default/instance_configs.cfg, especifica las propiedades de configuración que se muestran a continuación. Si las secciones no existen, créalas. En especial, asegúrate de que las propiedades target_instance_ips y ip_forwarding estén configuradas como falsas:

   [IpForwarding]
   ethernet_proto_id = 66
   ip_aliases = true
   target_instance_ips = false
   
   [NetworkInterfaces]
   dhclient_script = /sbin/google-dhclient-script
   dhcp_command =
   ip_forwarding = false
   setup = true
   

4. Inicia el servicio del agente invitado:

   sudo service google-guest-agent start
   

Para aplicar los cambios, reinicia la VM o sigue los pasos que se indican a continuación para borrar la ruta local.

1. Borra la ruta local que envía tráfico de vuelta:

   sudo ip route del table local $(ip route show table local | grep "proto 66" | awk '{print $2}') dev eth0
   

   El comando anterior es una secuencia de comandos de Linux unidos para borrar la VIP de la tabla de enrutamiento local. Desglosamos cada uno de estos puntos:

   Identificamos la dirección IP con los siguientes métodos:

   ip route show table local | grep "proto 66" | awk '{print $2}'
   

   Luego, envíalo al comando de eliminación real:

   ip route del table local
   

2. Reinicia el agente invitado de Google:

   systemctl google-guest-agent restart
   

Este cambio no es disruptivo. Si reinicias google-guest-agent, se vuelve a crear una ruta de red nueva que le indica al tráfico de red que use eth0 en lugar del dispositivo de bucle invertido para enviar tráfico a la VIP.

Para verificar los cambios, haz lo siguiente:

   ip route get IP_ADDRESS_OF_ILB

El resultado de este comando debe mostrar la interfaz de red como eth0 y no la interfaz de bucle invertido lo:

   [root@test-server-ha ~]# ip route get IP_ADDRESS_OF_ILB
   IP_ADDRESS_OF_ILB via IP_ADDRESS_OF_ILB dev eth0 src IP_ADDRESS_OF_ILB uid 0
   cache

Intenta la prueba telnet:

   [root@test-server-ha ~]# telnet IP_ADDRESS_OF_ILB PORT_NUMBER
   Trying IP_ADDRESS_OF_ILB...
   Connected to IP_ADDRESS_OF_ILB.
   Escape character is '^]'.