Dépannage des configurations à haute disponibilité pour SAP

Dans les configurations à haute disponibilité pour SAP sur Google Cloud, la cause première des problèmes peut être le logiciel de clustering, le logiciel SAP, l'infrastructure Google Cloud ou une combinaison de ces éléments.

Analyser les journaux Pacemaker dans Cloud Logging

La vidéo suivante explique comment résoudre les problèmes de configurations de haute disponibilité pour SAP sur Google Cloud à l'aide de Cloud Logging.

Le nœud défaillant dans un cluster Linux ne redémarre pas correctement après un basculement

Si votre cluster à haute disponibilité Linux utilise l'agent de cloisonnement fence_gce et qu'une VM cloisonnée ne parvient pas à rejoindre le cluster après un basculement, vous devrez peut-être retarder le démarrage du logiciel Corosync lors du redémarrage des VM cloisonnées.

Problème

Lors d'un basculement, l'agent fence_gce cloisonne la VM Compute Engine en échec qui redémarre et rejoint le cluster avant que Pacemaker n'enregistre l'action de cloisonnement comme terminée. Comme l'action de cloisonnement n'est pas enregistrée comme terminée, la VM redémarrée arrête ses services Pacemaker et Corosync et quitte le cluster.

Diagnostic

Pour confirmer que vous êtes bien concerné par ce problème, procédez comme suit :

  • Assurez-vous que votre cluster utilise l'agent fence_gce :

    RHEL 

    pcs config

    SLES

    crm config show

    La définition de l'agent de clôture inclut 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

  • Recherchez les messages suivants dans le journal système :

    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

Solution

Configurez les systèmes d'exploitation dans les deux nœuds de cluster pour retarder le démarrage de Corosync afin de donner à Pacemaker suffisamment de temps pour enregistrer l'action de cloisonnement sur le nouveau nœud principal. Définissez également la valeur du délai d'expiration de redémarrage de Pacemaker pour tenir compte du délai.

Pour configurer le démarrage différé de Corosync, procédez comme suit :

  1. Faites passer le cluster en mode de maintenance :

    RHEL 

    pcs property set maintenance-mode=true

    SLES

    crm configure property maintenance-mode="true"

  2. Sur chaque nœud de cluster, en tant qu'utilisateur racine, définissez un délai de démarrage pour Corosync :

    1. Créez un fichier de dépôt systemd :

      systemctl edit corosync.service

    2. Ajoutez les lignes suivantes au fichier :

      [Service]
ExecStartPre=/bin/sleep 60

    3. Enregistrez le fichier et quittez l'éditeur.

    4. Rechargez la configuration du gestionnaire systemd.

      systemctl daemon-reload

  3. Sur l'un des nœuds de cluster en tant qu'utilisateur racine, vérifiez que la valeur du délai d'expiration de Pacemaker pour les redémarrages est définie pour les deux agents de cloisonnement :

    1. Vérifiez la valeur pcmk_reboot_timeout :

      crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout

      Remplacez FENCE_AGENT_NAME par le nom de l'agent de cloisonnement.

    2. Si le paramètre pcmk_reboot_timeout est introuvable ou défini sur une valeur inférieure à 300, définissez la valeur sur les deux agents de cloisonnement :

      crm_resource --resource FENCE_AGENT_NAME --set-parameter=pcmk_reboot_timeout --parameter-value=300

      Remplacez FENCE_AGENT_NAME par le nom de l'agent de cloisonnement.

      La valeur pcmk_reboot_timeout doit être supérieure à la somme des éléments suivants :

      • Délai avant expiration de token dans Corosync
      • Le délai avant expiration de consensus Corosync, qui est par défaut le produit de token * 1,2
      • Durée d'exécution d'une opération de redémarrage, en incluant tout délai applicable.

      Sur Google Cloud, 300 secondes suffisent pour la plupart des clusters.

    3. Confirmez la nouvelle valeur pcmk_reboot_timeout :

      crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout

      Remplacez FENCE_AGENT_NAME par le nom de l'agent de cloisonnement.

  4. Désactivez le mode de maintenance pour le cluster :

    RHEL 

    pcs property set maintenance-mode=false

    SLES

    crm configure property maintenance-mode="false"

Affinité de nœuds involontaire qui favorise un nœud particulier

Lorsque vous déplacez manuellement des ressources dans un cluster haute disponibilité à l'aide des commandes du cluster, vous constatez qu'une affinité automatique ou une préférence client est définie pour favoriser un nœud particulier.

Problème

Dans votre cluster à haute disponibilité Linux Pacemaker pour SAP HANA ou SAP NetWeaver, les ressources telles que le système SAP HANA ou les services centraux SAP NetWeaver ne s'exécutent que sur un nœud de cluster particulier et ne basculent pas comme prévu pendant un événement de défaillance de nœud

Par conséquent, vous pouvez rencontrer les problèmes suivants :

  • Lorsque vous déclenchez le basculement du service SAP NetWeaver ASCS en exécutant une commande Pacemaker pour une ressource move vers un nœud de cluster, la ressource ne démarre pas et affiche l'état stopped.

  • Lorsque vous exécutez la commande standby sur un nœud de cluster pour forcer le déplacement de toutes les ressources vers l'autre nœud, les ressources ne démarrent pas.

Diagnostic

  • Recherchez dans les journaux Pacemaker le message indiquant qu'une ressource particulière ne peut pas s'exécuter nulle part. Exemple :

    2021-05-24 21:39:58 node_1 pacemaker-schedulerd (native_color) info:
 Resource NW1-ASCS01 cannot run anywhere

  • Vérifiez la configuration de la contrainte d'emplacement Pacemaker pour identifier les contraintes susceptibles d'empêcher l'exécution des ressources sur un nœud de cluster donné.

    Pour vérifier la configuration de la contrainte d'emplacement Pacemaker, procédez comme suit :

    1. Affichez les contraintes d'emplacement :

      cibadmin --query --scope constraints | grep rsc_location

    2. Vérifiez les contraintes d'emplacement :

      • Contrainte d'emplacement explicite : vous trouvez des contraintes d'emplacement avec le score INFINITY (préférez le nœud) ou -INFINITY (évitez le nœud). Exemple :

        <rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>

        Il ne doit pas y avoir de contrainte de localisation avec un score INFINITY ou -INFINITY autre que les agents de cloisonnement. Dans tous les clusters haute disponibilité, les agents de cloisonnement sont définis dans une contrainte de localisation avec un score -INFINITY pour les empêcher de s'exécuter sur le nœud qui est la cible du cloisonnement.

      • Contrainte d'emplacement implicite: lorsque vous exécutez la commande Pacemaker pour déplacer une ressource vers un nœud de cluster ou interdire l'exécution d'une ressource sur un nœud de cluster, une contrainte d'emplacement implicite avec le préfixe cli-ban ou cli-prefer est ajoutée à l'ID de contrainte. Exemple :

        <rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>

Solution

L'agent de cloisonnement a rencontré une erreur opérationnelle

L'agent de cloisonnement a signalé une erreur dans l'état du cluster.

Problème

Dans votre cluster à haute disponibilité Linux Pacemaker pour SAP HANA ou SAP NetWeaver, l'agent de cloisonnement a signalé une erreur dans l'état du cluster. Exemple : 

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

Diagnostic

L'agent de cloisonnement déployé dans votre cluster haute disponibilité SAP HANA ou SAP NetWeaver accède régulièrement au serveur d'API Compute Engine pour vérifier l'état de l'instance cible du cloisonnement. En cas de délai temporaire dans la réponse de l'appel d'API ou d'interruption du réseau, l'opération de surveillance de l'agent de cloisonnement peut échouer ou dépasser le délai imparti.

Pour vérifier l'état de l'agent de cloisonnement, exécutez la commande suivante :

RHEL 

pcs status

SLES

crm status

Si l'état de l'agent de cloisonnement est stopped, utilisez l'une des options de solution pour résoudre l'erreur.

L'erreur opérationnelle de l'agent de cloisonnement peut entraîner l'arrêt de l'agent de cloisonnement, mais Pacemaker appelle toujours les agents de cloisonnement avec une directive d'arrêt dans un événement de cloisonnement.

Solution

Si l'état de l'agent de cloisonnement est stopped, procédez comme suit :

  • Pour réinitialiser manuellement le nombre d'échecs et redémarrer l'agent de cloisonnement, exécutez la commande suivante :

    RHEL 

    pcs resource cleanup FENCE_AGENT_NAME

    SLES

    crm resource cleanup FENCE_AGENT_NAME

    Remplacez FENCE_AGENT_NAME par le nom de l'agent de cloisonnement.

  • Pour supprimer automatiquement l'erreur opérationnelle de l'agent de cloisonnement, configurez le paramètre failure-timeout.

    Le paramètre failure-timeout réinitialise le nombre d'échecs après la durée spécifiée et efface toutes les erreurs opérationnelles. L'application de ce paramètre ne nécessite pas de redémarrer le cluster ni de le mettre en mode de maintenance.

    Pour configurer le paramètre failure-timeout, exécutez la commande suivante:

    crm_resource --meta --resource FENCE_AGENT_NAME --set-parameter failure-timeout --parameter-value DURATION

    Remplacez les éléments suivants :

    • FENCE_AGENT_NAME : nom de l'agent de cloisonnement.
    • DURATION: durée après la dernière défaillance opérationnelle après laquelle le nombre d'échecs est réinitialisé et l'agent de cloisonnement redémarré.

L'agent de cloisonnement gcpstonith est obsolète

L'agent de cloisonnement gcpstonith est actif dans votre configuration. Cet agent est obsolète et l'équipe Customer Care vous a indiqué que vous devez passer à fence_gce.

Problème

Dans votre cluster Linux Pacemaker à haute disponibilité pour SAP HANA sur SUSE Linux, l'agent de cloisonnement gcpstonith est utilisé. Exemple :

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

Diagnostic

L'agent de cloisonnement déployé dans votre cluster à haute disponibilité SAP HANA doit être mis à jour pour utiliser l'agent de cloisonnement fence_gce fourni avec l'OS. Le script de l'agent gcpstonith était fourni sur les anciens systèmes et a été remplacé par fence_gce. fence_gce est fourni dans le package fence-agents SUSE Linux. gcpstonith n'était fourni que dans le cadre des déploiements SUSE Linux HANA.

Solution

Pour migrer depuis gcpstonith sur SUSE Linux, procédez comme suit:

  1. Installez les packages supplémentaires suivants, spécifiques à votre système d'exploitation:

    • Pour SLES 15: python3-oauth2client et python3-google-api-python-client

    • Pour SLES 12: python-google-api-python-client, python-oauth2client et python-oauth2client-gce

    Pour installer ces paquets sur votre système d'exploitation, exécutez la commande suivante:

    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. Mettez à jour le package fence-agents pour vous assurer que vous disposez de la dernière version installée:

    zypper update -y fence-agents

  3. Placez le cluster en mode de maintenance:

    crm configure property maintenance-mode=true

  4. Supprimez tous les appareils de cloisonnement de votre cluster. Lorsque vous supprimez le dernier appareil de cloisonnement, vous pouvez être invité à confirmer qu'aucune ressource STONITH n'est définie dans votre cluster.

    crm configure delete FENCING_RESOURCE_PRIMARY
     
    crm configure delete FENCING_RESOURCE_SECONDARY

  5. Recréez l'appareil de cloisonnement pour l'instance principale:

    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. Recréez l'appareil de cloisonnement pour l'instance secondaire:

    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. Définissez les contraintes d'emplacement:

    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. Désactivez le mode de maintenance pour le cluster : 

    crm configure property maintenance-mode=false

  9. Vérifiez la configuration :

    crm config show related:FENCING_RESOURCE_PRIMARY

  10. Vérifiez l'état du cluster:

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

L'agent de ressources est arrêté

Un agent de ressource n'a pas réussi à démarrer et reste à l'état Stopped.

Problème

Dans votre cluster à haute disponibilité Linux Pacemaker pour SAP HANA ou SAP NetWeaver, un agent de ressources a signalé une erreur dans l'état du cluster. Par exemple :

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

Diagnostic

Si un agent de ressources en cours d'exécution rencontre un échec, Pacemaker tente de l'arrêter et de le redémarrer. Si l'opération de démarrage échoue pour une raison quelconque, Pacemaker définit le nombre d'échecs de la ressource sur INFINITY et tente de démarrer l'agent sur un autre nœud. Si l'agent de ressources ne démarre pas sur un nœud, il reste à l'état Stopped.

Pour vérifier l'état de l'agent de ressources, exécutez la commande suivante :

RHEL 

pcs status

SLES

crm status

Pour SAP HANA, l'exemple suivant montre l'agent de ressources à l'état Stopped sur le nœud 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

Solution

Si un agent de ressource est à l'état Stopped, procédez comme suit :

  1. Démarrez manuellement l'agent de ressources en réinitialisant le nombre d'échecs :

    RHEL 

    pcs resource cleanup RESOURCE_AGENT_NAME

    SLES

    crm resource cleanup RESOURCE_AGENT_NAME

    Remplacez RESOURCE_AGENT_NAME par le nom de l'agent de ressources. Par exemple, rsc_SAPHana_DV0_HDB00.

  2. Assurez-vous que l'agent de ressources passe à l'état Started : 

    crm_mon

    Si l'agent de ressources ne parvient toujours pas à démarrer, rassemblez les informations de diagnostic pertinentes et contactez l'assistance.

Échec de la communication entre les VM en raison de routes réseau locales pour les adresses IP virtuelles

Le trafic réseau d'une VM de backend vers une autre VM échoue en raison des routes réseau locales pour les adresses IP virtuelles.

Problème

Lorsque les VM font partie d'un équilibreur de charge réseau passthrough interne, la communication réseau du backend vers les routes d'adresse IP virtuelle (VIP) de l'ILB est considérée comme locale et est gérée par l'appareil de bouclage.

Ce comportement de bouclage empêche une VM de backend d'utiliser correctement l'adresse VIP de l'ILB pour atteindre les services potentiellement hébergés sur d'autres VM de backend utilisant l'ILB, ce qui entraîne une défaillance de communication.

Par exemple: Échec de la communication entre ASCS et ERS dans un cluster HA SAP Netweaver configuré en tant que backend d'équilibreur de charge.

Le test telnet génère une erreur Connection Refused, car ce routage local ne permet pas au trafic d'atteindre la VM souhaitée:

   [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

Diagnostic

Prérequis :

Les VM concernées sont listées comme membres d'un groupe d'instances non géré configuré en tant que backend d'équilibreur de charge.

Lorsqu'une VM de backend dans un équilibreur de charge interne (ILB) lance la communication avec l'adresse IP virtuelle (VIP) de l'ILB, un comportement d'acheminement spécifique se produit.

Bien que le VIP soit configuré sur une interface réseau standard telle que eth0 et listé dans la table de routage locale, le noyau achemine les paquets destinés à ce VIP local à l'aide de l'interface de bouclage lo. Ce bouclage interne signifie que le paquet ne quitte jamais la VM d'origine pour être traité par l'ILB.

Bien que la communication directe entre les VM de backend utilisant leurs adresses IP individuelles fonctionne, ce comportement de bouclage empêche une VM de backend d'utiliser correctement l'adresse VIP de l'équilibreur de charge réseau pour atteindre les services potentiellement hébergés sur d'autres VM de backend à l'aide de l'équilibreur de charge réseau passthrough interne.

   [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

Le résultat de cette commande affiche une interface de bouclage 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>

Solution

Activez la communication backend entre les VM en modifiant la configuration de google-guest-agent, qui est incluse dans l'environnement invité Linux pour toutes les images publiques Linux fournies par Google Cloud.

Pour activer les communications backend de l'équilibreur de charge, procédez comme suit sur chaque VM de votre cluster :

  1. Arrêtez l'agent :

    sudo service google-guest-agent stop

  2. Ouvrez ou créez le fichier /etc/default/instance_configs.cfg pour le modifier:

    sudo vi /etc/default/instance_configs.cfg

  3. Dans le fichier /etc/default/instance_configs.cfg, spécifiez les propriétés de configuration suivantes comme indiqué. Si les sections n'existent pas, créez-les. Assurez-vous tout particulièrement que les propriétés target_instance_ips et ip_forwarding sont définies sur "false" :

    [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. Démarrez le service de l'agent invité :

    sudo service google-guest-agent start

Pour appliquer les modifications, redémarrez la VM ou suivez les étapes ci-dessous pour supprimer la route locale.

  1. Supprimez la route locale qui renvoie du trafic:

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

    La commande précédente est une séquence de commandes Linux transmises ensemble pour supprimer l'adresse IP virtuelle de la table de routage locale. Voici le détail:

    Nous identifions l'adresse IP à l'aide des éléments suivants :

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

    Ensuite, transmettez-le à la commande de suppression:

    ip route del table local

  2. Redémarrez l'agent invité Google:

    systemctl google-guest-agent restart

Ce changement n'est pas perturbateur. Redémarrer le google-guest-agent recrée une nouvelle route réseau qui indique au trafic réseau d'utiliser eth0 au lieu de l'appareil de bouclage pour envoyer du trafic à l'adresse IP virtuelle.

Pour vérifier les modifications :

   ip route get IP_ADDRESS_OF_ILB

Le résultat de cette commande doit afficher une interface réseau comme eth0 et non l'interface de bouclage 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

Essayez le test 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 '^]'.