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.