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 cloisonnement 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 :

Faites passer le cluster en mode de maintenance :

RHEL

pcs property set maintenance-mode=true

SLES

crm configure property maintenance-mode="true"

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

Désactivez le mode de maintenance pour le cluster :

RHEL

pcs property set maintenance-mode=false

SLES

crm configure property maintenance-mode="false"

Affinité involontaire des nœuds favorisant 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 préférence d'affinité automatique ou de 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 toutes les ressources à être transférées vers l'autre nœud, les ressources ne démarrent pas.

Diagnostic

Vérifiez dans vos journaux Pacemaker que le message indiquant une ressource particulière ne peut pas être exécuté ailleurs. 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 votre contrainte d'emplacement Pacemaker pour identifier les contraintes susceptibles d'empêcher l'exécution des ressources sur un nœud de cluster spécifique.

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 y avoir aucune contrainte d'emplacement 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 d'emplacement avec un score -INFINITY, pour empêcher leur exécution sur le nœud correspondant à la cible de cloisonnement.
  - Contrainte d'emplacement implicite: lorsque vous exécutez la commande Pacemaker pour déplacer une ressource vers un nœud de cluster ou pour exclure une ressource à exécuter sur un nœud de cluster, une contrainte d'emplacement implicite avec le préfixe cli-ban ou cli-prefer est ajouté à l'ID de contrainte. Exemple :
```
<rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>
```

Solution

Assurez-vous que les contraintes d'emplacement sont spécifiées comme expliqué dans nos guides de déploiement :
Pour corriger une contrainte d'emplacement explicite, supprimez la contrainte d'emplacement:
RHEL
```
pcs constraint remove RESOURCE_LOCATION_ID
```
SLES
```
crm configure delete RESOURCE_LOCATION_ID
```
Remplacez RESOURCE_LOCATION_ID par l'ID de contrainte de l'emplacement.
Pour corriger une contrainte d'emplacement implicite, supprimez toutes les contraintes définies sur la ressource spécifiée.

Après chaque commande que vous utilisez pour déplacer ou exclure une ressource, exécutez la commande suivante afin de supprimer toutes les contraintes:
RHEL
```
pcs resource clear RESOURCE_NAME
```
SLES
```
crm resource clear RESOURCE_NAME
```
Remplacez RESOURCE_NAME par le nom de la ressource que vous déplacez.

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 SAP HANA ou SAP NetWeaver à haute disponibilité accède régulièrement au serveur d'API Compute Engine pour vérifier l'état de l'instance cible de cloisonnement. En cas de retard temporaire dans la réponse à l'appel d'API ou en cas d'interruption du réseau, l'opération de surveillance de l'agent de cloisonnement peut échouer ou expirer.

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 instruction d'arrêt dans un événement de cloisonnement.

Solution

Si l'état de l'agent de cloisonnement est stopped, effectuez l'une des opérations suivantes:

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 les erreurs opérationnelles. L'application de ce paramètre ne vous oblige pas à redémarrer le cluster ni à 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 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 ressource 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 ressource en cours d'exécution échoue, Pacemaker tente d'arrêter l'agent et de le redémarrer. Si l'opération de démarrage échoue pour une raison quelconque, Pacemaker définit le nombre d'échecs des ressources 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: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

Solution

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

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