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 :
Créez un fichier de dépôt
systemd
:systemctl edit corosync.service
Ajoutez les lignes suivantes au fichier :
[Service] ExecStartPre=/bin/sleep 60
Enregistrez le fichier et quittez l'éditeur.
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 :
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.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.
- Délai avant expiration de
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'étatstopped
.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 :
Affichez les contraintes d'emplacement :
cibadmin --query --scope constraints | grep rsc_location
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
oucli-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 :
- Guide de configuration d'un scaling à la hausse sur un cluster à haute disponibilité pour SAP HANA sur RHEL
- Guide de configuration d'un scaling à la hausse sur un cluster à haute disponibilité pour SAP HANA sur SLES
- Guide de configuration d'un cluster à haute disponibilité pour SAP NetWeaver sur RHEL
- Guide de configuration d'un cluster à haute disponibilité pour SAP NetWeaver sur SLES
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 cloisonnementDURATION
: 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.