Partager via

Résoudre les problèmes de démarrage pour les services et ressources du cluster Pacemaker

S’applique à : ✔️ Machines virtuelles Linux

Cet article traite des causes les plus courantes des problèmes de démarrage dans les ressources ou services de cluster Pacemaker RedHat Enterprise Linux (RHEL) et fournit également des conseils pour identifier et résoudre les problèmes.

Scénario 1 : Impossible de démarrer le service de cluster en raison du quorum

Symptôme pour le scénario 1

  • Le nœud de cluster ne joint pas de cluster après le redémarrage d’un cluster.

  • Les nœuds sont signalés en tant que UNCLEAN (offline).

  • Le contrôleur de domaine actuel est signalé en tant que NONE.

    sudo pcs status

    Cluster name: my_cluster
Status of pacemakerd: 'Pacemaker is running' (last updated 2024-06-25 16:34:49 -04:00)
Cluster Summary:
* Stack: corosync
* **Current DC: NONE**
* Last updated: Tue Jun 25 14:34:49 2024
* Last change:  Tue Jun 25 14:29:51 2024 by root via cibadmin on node-0
* 2 nodes configured
* 9 resource instances configured

Node List:
* **Node node-0: UNCLEAN (offline)**
* **Node node-1: UNCLEAN (offline)**

  • sudo pcs quorum status retourne le message d’erreur suivant :

    sudo pcs quorum status

    Error: Unable to get quorum status: Unable to start votequorum status tracking: CS_ERR_BAD_HANDLE
Check for the error: Corosync quorum is not configured in /var/log/messeges:
Jun 16 11:17:53 node-0 pacemaker-controld[509433]: error: Corosync quorum is not configured

Cause du scénario 1

Le service VoteQuorum est un composant du projet corosync. Pour éviter les scénarios de fractionnement de cerveau, ce service peut éventuellement être chargé dans les nœuds d’un cluster corosync. Chaque système du cluster reçoit un certain nombre de votes pour atteindre ce quorum. Cela permet de s’assurer que les actions de cluster ne peuvent se produire que si la plupart des votes sont exprimés. Chaque nœud ou aucun nœud doit avoir le service chargé. Les résultats sont incertains si le service est chargé dans un sous-ensemble de nœuds de cluster.

Le paramètre suivant /etc/corosync/corosync.conf active le service VoteQuorum dans corosync :

quorum {
    provider: corosync_votequorum
}

VoteQuorum lit sa configuration à partir de /etc/corosync/corosync.conf. Certaines valeurs peuvent être modifiées au moment de l’exécution et d’autres sont lues uniquement au démarrage corosync. Il est important que ces valeurs soient cohérentes sur tous les nœuds participant au cluster. Sinon, le comportement du quorum de vote est imprévisible.

Résolution du scénario 1

  1. Avant d’apporter des modifications, vérifiez que vous disposez d’une sauvegarde ou d’un instantané. Pour plus d’informations, consultez Sauvegarde de machine virtuelle Azure.

  2. Recherchez la section de quorum manquante dans /etc/corosync/corosync.conf. Comparez l’existant corosync.conf avec n’importe quelle sauvegarde disponible dans /etc/corosync/.

  3. Placez le cluster en mode maintenance :

    sudo pcs property set maintenance-mode=true

  4. Mettez à jour les modifications dans /etc/corosync/corosync.conf.

    Exemple de cluster à deux nœuds :

    sudo cat /etc/corosync/corosync.conf

    totem {
version: 2
cluster_name: my_cluster
transport: knet
token: 30000
crypto_cipher: aes256
crypto_hash: sha256
cluster_uuid: afd62fe2045b43b9a102de76fdf4659a
}
nodelist {
node {
    ring0_addr: node-0
    name: node-0
    nodeid: 1
}

node {
    ring0_addr: node-1
    name: node-1
    nodeid: 2
}
}

**quorum {
provider: corosync_votequorum
two_node: 1
}**

logging {
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
timestamp: on
}

  5. Supprimez le cluster du mode maintenance.

    sudo pcs property set maintenance-mode=false

  6. Synchronisez le cluster :

    sudo pcs cluster sync

  7. Rechargez corosync :

    sudo pcs cluster reload corosync

Scénario 2 : Problème dans la ressource d’adresse IP virtuelle du cluster

Symptôme pour le scénario 2

Une ressource IP virtuelle (IPaddr2 ressource) ne démarre pas ou ne s’arrête pas dans Pacemaker.

Les entrées d’erreur suivantes sont consignées /var/log/pacemaker.log:

25167 IPaddr2(VIP)[16985]:    2024/09/07_15:44:19 ERROR: Unable to find nic or netmask.
25168 IPaddr2(VIP)[16985]:    2024/09/07_15:44:19 ERROR: [findif] failed

L’erreur peut également être observée lors de l’exécution sudo pcs status:

sudo pcs status

vip_HN1_03_start_0 on node-1 'unknown error' (1): call=30, status=complete, exit-reason='[findif] failed', last-rc-change='Thu Jan 07 17:25:52 2025', queued=0ms, exec=57ms

Cause du scénario 2

  1. Pour choisir la carte réseau sur laquelle démarrer la IPAddr2 ressource, IPaddr2 appelle la findif() fonction, telle que définie dans /usr/lib/ocf/resource.d/heartbeat/IPaddr2 ce qui est contenu dans le resource-agents package.

  2. La carte réseau correcte est déterminée par les options définies sur la IPAddr2 ressource, telles que ip (obligatoire), cidr_netmasket broadcast.

    Par exemple :

    Vérifiez les IPaddr2 paramètres :

    sudo pcs resource show vip_HN1_03

    Resource: vip_HN1_03 (class=ocf provider=heartbeat type=IPaddr2)
Attributes: ip=172.17.10.10 cidr_netmask=24 nic=ens6
Operations: start interval=0s timeout=20s (vip_HN1_03-start-timeout-20s)
            stop interval=0s timeout=20s (vip_HN1_03-stop-timeout-20s)
            monitor interval=10s timeout=20s (vip_HN1_03-monitor-interval-10s)

  3. Essayez de déterminer les NIC informations manuellement. Dans cet exemple, en fonction de l’adresse IP et du masque net, nous pouvons trouver ens6 à partir de la table de routage :

    sudo ip -o -f inet route list match 172.17.10.10/24 scope link

    172.17.10.0/24 dev ens6 proto kernel src 172.17.10.7

  4. Dans une situation dans laquelle NIC (ens6) vous êtes arrêté, vous ne pouvez pas trouver manuellement les NIC informations et cela peut entraîner [findif] l’échec. Remplacez 172.17.10.10/24 et ens6 le cas échéant.

    sudo ip link set ens6 down

    sudo ip -o -f inet route list match 172.17.10.10/24 scope link

Résolution du scénario 2

Si un itinéraire qui correspond à ce VIP qui ne se trouve pas dans la table de routage par défaut, vous pouvez spécifier le NIC nom dans la ressource Pacemaker afin qu’il puisse être configuré pour contourner la vérification :

  1. Avant d’apporter des modifications, vérifiez que vous disposez d’une sauvegarde ou d’un instantané. Pour plus d’informations, consultez Sauvegarde de machine virtuelle Azure.

  2. Placez le cluster en mode maintenance :

    sudo pcs property set maintenance-mode=true

  3. Mettez à jour les NIC ressources :

    sudo pcs resource update vip_HN1_03 nic=ens6

  4. Redémarrez les NIC ressources :

    sudo pcs resource restart vip_HN1_03

    vip_HN1_03 successfully restarted

  5. Supprimez le cluster de maintenance-mode:

    sudo pcs property set maintenance-mode=false

  6. Vérifiez la IP ressource :

    sudo pcs resource show vip_HN1_03

    Warning: This command is deprecated and will be removed. Please use 'pcs resource config' instead.
Resource: vip_HN1_03 (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: cidr_netmask=32 ip=172.17.223.36 nic=vlan10
  Meta Attrs: resource-stickiness=INFINITY
  Operations: monitor interval=10s timeout=20s (vip_HN1_03-monitor-interval-10s)
              start interval=0s timeout=20s (vip_HN1_03-start-interval-0s)
              stop interval=0s timeout=20s (vip_HN1_03-stop-interval-0s)

Pour plus d’informations sur ce scénario, consultez l’article Red Hat suivant : « ERROR : [findif] failed » (ERREUR : [findif] failed) indiqué dans Pacemaker ».

Scénario 3 : Problème dans SAP HANA (appliance analytique haute performance)

Scénario 3, Symptôme 1 : la base de données SAP HANA ne démarre pas et génère une erreur inconnue

SAP HANA DB ne démarre pas et retourne un message d’erreur unknown error .

  1. Dans la section journal /var/log/messages , une SRHOOK=SFAIL entrée est journalisée. Cela indique que les nœuds de cluster ne sont pas synchronisés.

  2. Le nœud de cluster secondaire est dans l’état WAITING4PRIM .

    sudo pcs status --full

    * Node node-0 (1):
    + hana_XXX_clone_state              : PROMOTED  
    + hana_XXX_sync_state               : PRIM      
    + hana_XXX_roles                    : 2:P:master1:master:worker:slave

* Node node-1 (2):
    + hana_XXX_clone_state              : WAITING4PRIM  
    + hana_XX_sync_state                : SFAIL      
    + hana_XXX_roles                    : 2:S:master1:master:worker:slave

  3. Lorsque vous exécutez sudo pcs status, l’état du cluster s’affiche comme suit :

    sudo pcs status

    2 nodes configured
8 resources configured

Online: [ node-0 node-1 ]

Full list of resources:

  rsc_st_azure	(stonith:fence_azure_arm):	Started node-1
  Clone Set: cln_SAPHanaTopology [rsc_SAPHanaTopology]
      Started: [ node-0 node-1 ]
  Master/Slave Set: msl_SAPHana [rsc_SAPHana]
      Master: [ node-1 ]
      Slave:  [ node-0 ]
  Resource Group: g_ip_HN1_HBD00
      vip_HN1_HBD00	(ocf::heartbeat:IPaddr2):	Started node-0 
      nc_HN1_HBD00	(ocf::heartbeat:azure-lb):	Started node-0 


Failed Resource Actions:
* rsc_SAPHana_monitor_61000 on node-0 'unknown error' (1): call=32, status=complete, exitreason='',
    last-rc-change='Sat May 22 09:29:20 2021', queued=0ms, exec=0ms
* rsc_SAPHana_start_0 on node-1 'not running' (7): call=55, status=complete, exitreason='',
    last-rc-change='Sat May 22 09:36:32 2021', queued=0ms, exec=3093ms

Cause du scénario 3, symptôme 1

Pacemaker ne peut pas démarrer la ressource SAP HANA en SYN cas de défaillance entre les nœuds principaux et secondaires :

sudo SAPHanaSR-showAttr

Global cib-time                 maintenance
--------------------------------------------
global Fri Aug 23 11:47:32 2024 false

Hosts	clone_state	lpa_fh9_lpt	node_state	op_mode	        remoteHost  	  roles		            score	 site   srmode	sync_state	version         vhost
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
node-0	DEMOTED		10		online		logreplay	node-1 	4:S:master1:master:worker:master	5	SITEA	syncmem	SOK	2.00.046.00.1581325702	node-0
node-1	PROMOTED	1693237652	online		logreplay	node-0 	4:P:master1:master:worker:master	150	SITEA	syncmem	PRIM	2.00.046.00.1581325702	node-1

Solution de contournement pour le scénario 3, symptôme 1

La ressource SAP HANA ne peut pas être démarrée par Pacemaker en SYN cas de défaillance entre les nœuds de cluster principal et secondaire. Pour atténuer ce problème, vous devez activer SYN manuellement entre les nœuds principaux et secondaires.

Important

Les étapes 2, 3 et 4 doivent être effectuées à l’aide d’un compte d’administrateur SAP. Cela est dû au fait que ces étapes utilisent un ID système SAP pour arrêter, démarrer et réactiver la réplication manuellement.

  1. Avant d’apporter des modifications, vérifiez que vous disposez d’une sauvegarde ou d’un instantané. Pour plus d’informations, consultez Sauvegarde de machine virtuelle Azure.

  2. Placez le cluster en mode maintenance :

    sudo pcs property set maintenance-mode=true

  3. Vérifiez l’état de la base de données SAP HANA et des processus :

    a. Vérifiez que les nœuds principaux et secondaires exécutent la base de données SAP et les processus SAP associés. L’un doit fonctionner comme nœud principal et l’autre comme secondaire. Cela permet de s’assurer que les bases de données sur les deux nœuds restent synchronisées.

    b. Exécutez HDB info sur chaque nœud pour vérifier les processus liés à SAP qui s’exécutent dans le nœud. L’administrateur SAP doit pouvoir confirmer que le processus requis s’exécute sur les deux nœuds.

    HDB info

    USER        PID   PPID %CPU    VSZ   RSS COMMAND
a00adm     5183   5178  0.0  87684  1804 sshd: a00adm@pts/0
a00adm     5184   5183  0.0  14808  3624  \_ -sh
a00adm     5994   5184  0.0  13200  1824      \_ /bin/sh /usr/sap/A00/HDB00/HDB info
a00adm     6019   5994  0.0  26668  1356          \_ ps fx -U a00adm -o user,pid,ppid,pcpu,vsz,rss,args
a00adm     5369      1  0.0  20932  1644 sapstart pf=/usr/sap/A00/SYS/profile/A00_HDB00_node-0
a00adm     5377   5369  1.8 582944 292720  \_ /usr/sap/A00/HDB00/node-0/trace/hdb.sapA00_HDB00 -d -nw -f /usr/sap/A00/HDB00/node-0/daemon.ini pf=/usr/sap/A00/SYS/profile/A00_HDB00_node-0
a00adm     5394   5377  9.3 3930388 1146444      \_ hdbnameserver
a00adm     5548   5377 21.3 2943472 529672      \_ hdbcompileserver
a00adm     5550   5377  4.4 2838792 465664      \_ hdbpreprocessor
a00adm     5571   5377 91.6 7151116 4019640      \_ hdbindexserver
a00adm     5573   5377 21.8 4323488 1203128      \_ hdbxsengine
a00adm     5905   5377 18.9 3182120 710680      \_ hdbwebdispatcher
a00adm     2104      1  0.0 428748 27760 /usr/sap/A00/HDB00/exe/sapstartsrv pf=/usr/sap/A00/SYS/profile/A00_HDB00_node-0 -D -u a00adm
a00adm     2004      1  0.0  31844  2352 /usr/lib/systemd/systemd --user
a00adm     2008   2004  0.0  63796  2620  \_ (sd-pam)

    c. Si la base de données SAP et les services ne sont pas actifs sur le nœud, nous vous recommandons de contacter votre administrateur SAP pour examiner et arrêter les services SAP DB, tout d’abord dans le nœud secondaire, puis dans le nœud principal :

    sudo HDB stop

    ou :

    sudo sapcontrol -nr <SAPInstanceNo> -function stop

    d. Une fois l’opération d’arrêt terminée, démarrez la base de données HANA dans le nœud principal, puis dans le nœud secondaire. Modifiez <SAPInstanceNo> le cas échéant.

    sudo HDB start

    ou :

    sudo sapcontrol -nr <SAPInstanceNo> -function start

  4. Si les nœuds de base de données ne sont toujours pas synchronisés, l’administrateur SAP doit résoudre le problème en examinant les journaux SAP pour vous assurer que les nœuds de base de données sont correctement synchronisés.

    Remarque

    L’administrateur SAP doit déterminer quel nœud doit être désigné comme principal et qui est le serveur secondaire pour s’assurer qu’aucune donnée de base de données n’est perdue dans le processus.

  5. Après avoir activé la réplication, vérifiez l’état de réplication du système à l’aide du compte d’administrateur système SAP. Dans ce cas, le compte d’administrateur d’utilisateur est hn1adm.

    Sur le nœud principal, vérifiez que l’état global de la réplication du système est ACTIVE.

    Si les nœuds de base de données ne sont toujours pas synchronisés, l’administrateur SAP doit résoudre le problème en examinant les journaux SAP pour vous assurer que les nœuds de base de données sont correctement synchronisés :

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

    | Host   | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
|        |       |              |           |         |           | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details | 
| ------ | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
| node-0 | 30007 | xsengine     |         2 |       1 | node-0    | sapn2     |     30007 |         2 | node-1     | YES          | SYNC        | ACTIVE      |                |
| node-0 | 30001 | nameserver   |         1 |       1 | node-0    | sapn2     |     30001 |         2 | node-1     | YES          | SYNC        | ACTIVE      |                |
| node-0 | 30003 | indexserver  |         3 |       1 | node-0    | sapn2     |     30003 |         2 | node-1     | YES          | SYNC        | ACTIVE      |                |

status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  mode: PRIMARY
  site id: 1
  site name: node-0

  6. Vérifiez à nouveau l’état de réplication du système SAP HANA en exécutant la commande suivante :

    sudo SAPHanaSR-showAttr

    Global cib-time                 maintenance
--------------------------------------------
global Mon Oct 14 10:25:51 2024 false

Hosts	clone_state	lpa_fh9_lpt	node_state	op_mode	        remoteHost  	  roles		            score	 site   srmode	sync_state	version         vhost
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
node-0	DEMOTED		10		online		logreplay	node-1 	4:S:master1:master:worker:master	5	SITEA	syncmem	SOK	2.00.046.00.1581325702	node-0
node-1	PROMOTED	1693237652	online		logreplay	node-0 	4:P:master1:master:worker:master	150	SITEA	syncmem	PRIM	2.00.046.00.1581325702	node-1

  7. Quittez le compte Administrateur SAP, puis supprimez le cluster du mode maintenance :

    sudo pcs property set maintenance-mode=false

  8. Assurez-vous que les ressources du cluster Pacemaker s’exécutent correctement.

Scénario 3, Symptôme 2 : SAP HANA ne démarre pas en raison d’un échec de réplication

La ressource SAP HANA rencontre des échecs de démarrage et son hana_xxx_roles attribut s’affiche 1:N:master1::worker:. L’état N indique que la ressource est hors synchronisation et s’exécute en mode autonome. La ressource de base de données n’est ni primaire ni secondaire sur n’importe quel nœud.

Lorsque vous exécutez la sudo pcs status --full commande, l’état node attributes s’affiche comme suit :

sudo pcs status --full

Node Attributes:
  * Node: node-0 (1):
    * hana_XXX_clone_state            : UNDEFINED
    * hana_XXX_op_mode			          : logreplay
    * hana_XXX_remoteHost             : node-1
    * hana_XXX_roles                  : 1:N:master1::worker:
    * hana_XXX_site                   : SITE1    
    * hana_XXX_srah                   : -        
    * hana_XXX_srmode                 : sync     
    * hana_XXX_version                : 2.00.079.00
    * hana_XXX_vhost                  : node-0
    * lpa_XXX_lpt                     : 10       
  * Node: node-1 (2):
    * hana_XXX_clone_state            : UNDEFINED
    * hana_XXX_op_mode                : logreplay
    * hana_XXX_remoteHost             : node-0
    * hana_XXX_roles                  : 4:N:master1:master:worker:master
    * hana_XXX_site                   : SITE2
    * hana_XXX_sra                    : -        
    * hana_XXX_srah                   : -        
    * hana_XXX_srmode                 : sync     
    * hana_XXX_sync_state		          : PRIM     
    * hana_XXX_version			          : 2.00.079.00
    * hana_XXX_vhost				          : node-1
    * lpa_XXX_lpt				              : 1733552029
    * master-SAPHana_XXX_00		        : 150

Ce résumé de la migration indique que la ressource SAP HANA (SAPHana_XXX_00) n’a pas pu démarrer sur les deux nœuds (node-0 et node-1). Le nombre d’échecs est défini sur 1000000 (infini).

sudo pcs status

Migration Summary:
  * Node: node-0 (1):
    * SAPHana_XXX_00: migration-threshold=1000000 fail-count=1000000 last-failure='Sat Dec  7 15:17:16 2024'
  * Node: node-1 (2):
    * SAPHana_XXX_00: migration-threshold=1000000 fail-count=1000000 last-failure='Sat Dec  7 15:48:57 2024'

Failed Resource Actions:
  * SAPHana_XXX_00_start_0 on node-1 'not running' (7): call=74, status='complete', last-rc-change='Sat Dec  7 15:17:14 2024', queued=0ms, exec=1715ms
  * SAPHana_XXX_00_start_0 on node-0 'not running' (7): call=30, status='complete', last-rc-change='Sat Dec  7 15:49:12 2024', queued=0ms, exec=1680ms

Cause du scénario 3, symptôme 2

Ce problème se produit fréquemment si la base de données est modifiée (arrêtée ou démarrée manuellement, la réplication est suspendue, et ainsi de suite) pendant que le cluster est en mode maintenance.

Résolution du scénario 3, symptôme 2

Remarque

Les étapes 1 à 5 doivent être effectuées par un administrateur SAP.

  1. Avant d’apporter des modifications, vérifiez que vous disposez d’une sauvegarde ou d’un instantané. Pour plus d’informations, consultez Sauvegarde de machine virtuelle Azure.

  2. Placez le cluster en mode maintenance :

    sudo pcs property set maintenance-mode=true

  3. Démarrez manuellement la base de données en dehors du cluster sur le nœud principal :

    sudo HDB start

  4. Démarrez la réplication sur le nœud principal. Remplacez <site id> le cas échéant.

    sudo hdbnsutil -sr_enable --name=<site id>

  5. Initialiser la réplication sur le nœud secondaire. Remplacez <primary node>, <Instance ##> et <side id> le cas échéant.

    sudo hdbnsutil -sr_register --remoteHost=<primary node> --remoteInstance=<Instance ##> --replicationMode=syncmem --name=<site id>

  6. Démarrez manuellement la base de données en dehors du cluster sur le nœud secondaire :

    sudo HDB start

  7. Vérifiez que les réplications s’exécutent comme prévu. Pour ce faire, exécutez la commande suivante sur les deux nœuds :

    sudo hdbnsutil -sr_state

  8. Supprimez le cluster du mode maintenance.

    sudo pcs property set maintenance-mode=false

  9. Effacez le nombre d’échecs de la ressource SAP HANA. Remplacez par <SAPHana resource name> la configuration de votre cluster SAP Pacemaker.

    sudo pcs resource cleanup <SAPHana resource name>

Pour plus d’informations sur ce scénario, consultez l’article Red Hat suivant : Échecs de démarrage des ressources SAPHana avec hana_xxx_roles Reporting N (autonome) ».

Scénario 3, Symptôme 3 : La ressource SAP HANA ne démarre pas en raison de problèmes hdbdaemon

Échec de démarrage de la ressource SAP HANA avec message d’erreur comme indiqué :

'FAIL: process hdbdaemon HDB Daemon not running'

La sudo pcs status --full commande peut également être utilisée pour afficher cette erreur, car elle a également entraîné l’erreur de basculement des ressources de cluster SAP HANA Pacemaker.

Failed Resource Actions:
  * SAPHana_XXX_00_start_0 on node-0 'error' (1): call=44, status='complete', exitreason='', last-rc-change='2024-07-07 06:15:45 -08:00', queued=0ms, exec=51659ms

Cause du scénario 3, symptôme 3

Un examen du /var/log/messages journal indique qu’il hbddaemon n’a pas démarré en raison de l’erreur suivante :

Jun  7 02:25:09 node-0 SAPHana(SAPHana_XXX_00)[12336]: ERROR: ACT: SAPHana Instance ECR-HDB00 start failed: #01201.03.2024 02:25:09#012WaitforStarted#012FAIL: process hdbdaemon HDB Daemon not running
Jun  7 02:25:09 node-0 SAPHana(SAPHana_XXX_00)[12336]: INFO: RA ==== end action start_clone with rc=1 (0.154.0) (25s)====
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ tput: No value for $TERM and no -T specified ]
Jun  7 02:25:09 node-0 pacemaker-execd[8567]: notice: SAPHana_XXX_00_start_0[12336] error output [ Error performing operation: No such device or address ]
Jun  7 02:25:09 node-0 pacemaker-controld[8570]: notice: Result of start operation for SAPHana_XXX_00 on node-0: error
Jun  7 02:25:09 node-0 pacemaker-controld[8570]: notice: node-0-SAPHana_XXX_00_start_0:33 [ tput: No value for $TERM and no -T specified\ntput: No value for $TERM and no -T specified\ntput: No value for $TERM and no -T specified\nError performing operation: No such device or address\n ]
Jun  7 02:25:09 node-0 pacemaker-attrd[8568]: notice: Setting fail-count-SAPHana_XXX_00#start_0[node-0]: (unset) -> INFINITY
Jun  7 02:25:09 node-0 pacemaker-attrd[8568]: notice: Setting last-failure-SAPHana_XXX_00#start_0[node-0]: (unset) -> 1709288709

Résolution du scénario 3, symptôme 3

Consultez l’article Red Hat suivant : Échec de démarrage de la ressource SAPHana avec l’erreur « FAIL : traiter hdbdaemon HDB Daemon non en cours d’exécution ».

Scénario 4 : Problème qui affecte les ressources ASCS et ERS

Symptôme pour le scénario 4

Les instances ASCS et ERS ne peuvent pas démarrer sous contrôle de cluster. Le /var/log/messages journal indique les erreurs suivantes :

Jun  9 23:29:16 nodeci SAPRh2_10[340480]: Unable to change to Directory /usr/sap/RH2/ERS10/work. (Error 2 No such file or directory) [ntservsserver.cpp 3845]
Jun  9 23:29:16 nodeci SAPRH2_00[340486]: Unable to change to Directory /usr/sap/Rh2/ASCS00/work. (Error 2 No such file or directory) [ntservsserver.cpp 3845]

Cause du scénario 4

En raison d’attributs et START_PROFILE incorrectsInstanceName, les instances SAP telles que ASCS et ERS, ne démarrent pas sous le contrôle de cluster.

Résolution du scénario 4

Remarque

Cette résolution s’applique si InstanceName et START_PROFILE sont des fichiers distincts.

  1. Avant d’apporter des modifications, vérifiez que vous disposez d’une sauvegarde ou d’un instantané. Pour plus d’informations, consultez Sauvegarde de machine virtuelle Azure.

  2. Placez le cluster en mode maintenance :

    sudo pcs property set maintenance-mode=true

  3. Vérifiez le chemin d’accès pf(profile) du /usr/sap/sapservices fichier :

    sudo cat /usr/sap/sapservices

    LD_LIBRARY_PATH=/usr/sap/RH2/ASCS00/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/RH2/ASCS00/exe/sapstartsrv pf=/usr/sap/RH2/SYS/profile/START_ASCS00_nodeci -D -u rh2adm
LD_LIBRARY_PATH=/usr/sap/RH2/ERS10/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/RH2/ERS10/exe/sapstartsrv pf=/usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi -D -u rh2adm

  4. Corrigez les InstanceName valeurs et START_PROFILE les valeurs d’attribut dans l’agent de ressource de configuration du SAPInstance cluster.

    Exemple:

    sudo pcs resource update ASCS_RH2_ASCS00 InstanceName=RH2_ASCS00_nodeci START_PROFILE=/usr/sap/RH2/SYS/profile/START_ASCS00_nodeci

    Remplacez RH2_ASCS00_nodeci et /usr/sap/RH2/SYS/profile/START_ASCS00_nodeci par les valeurs appropriées.

    sudo pcs resource update ERS_RH2_ERS10 InstanceName=RH2_ERS10_nodersvi START_PROFILE=/usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi

    Remplacez RH2_ERS10_nodersvi et /usr/sap/RH2/ERS10/profile/START_ERS10_nodersvi par les valeurs appropriées.

  5. Supprimez le cluster du mode maintenance :

    sudo pcs property set maintenance-mode=false

Scénario 5 : Le nœud clôturé ne rejoint pas le cluster

Symptôme pour le scénario 5

Une fois l’opération de clôture terminée, le nœud affecté ne rejoint généralement pas le cluster Pacemaker, et les services Pacemaker et Corosync restent arrêtés, sauf s’ils sont démarrés manuellement pour restaurer le cluster en ligne.

Cause du scénario 5

Une fois le nœud fermé et redémarré et redémarré ses services de cluster, il reçoit par la suite un message qui indique . We were allegedly just fenced Cela entraîne l’arrêt de ses services Pacemaker et Corosync et empêche le démarrage du cluster. Node1 lance une action STONITH sur node2. Lorsque 03:27:23le problème réseau est résolu, node2 rejoint l’appartenance Corosync. Par conséquent, une nouvelle appartenance à deux nœuds est établie, comme indiqué pour /var/log/messages node1 :

Feb 20 03:26:56 node1 corosync[1722]:  [TOTEM ] A processor failed, forming new configuration.
Feb 20 03:27:23 node1 corosync[1722]:  [TOTEM ] A new membership (1.116f4) was formed. Members left: 2
Feb 20 03:27:24 node1 corosync[1722]:  [QUORUM] Members[1]: 1
...
Feb 20 03:27:24 node1 pacemaker-schedulerd[1739]: warning: Cluster node node2 will be fenced: peer is no longer part of the cluster
...
Feb 20 03:27:24 node1 pacemaker-fenced[1736]: notice: Delaying 'reboot' action targeting node2 using  for 20s
Feb 20 03:27:25 node1 corosync[1722]:  [TOTEM ] A new membership (1.116f8) was formed. Members joined: 2
Feb 20 03:27:25 node1 corosync[1722]:  [QUORUM] Members[2]: 1 2
Feb 20 03:27:25 node1 corosync[1722]:  [MAIN  ] Completed service synchronization, ready to provide service.

Node1 a reçu la confirmation que node2 a été correctement redémarré, comme indiqué pour /var/log/messages node2.

Feb 20 03:27:46 node1 pacemaker-fenced[1736]: notice: Operation 'reboot' [43895] (call 28 from pacemaker-controld.1740) targeting node2 using xvm2 returned 0 (OK)

Pour terminer entièrement l’action STONITH, le système a dû remettre le message de confirmation à chaque nœud. Étant donné que node2 est joint au groupe et 03:27:25 qu’aucune nouvelle appartenance qui exclut node2 n’a encore été formée en raison du jeton et des délais d’expiration du consensus, le message de confirmation est retardé jusqu’à ce que node2 redémarre ses services de cluster après le démarrage. Lors de la réception du message, node2 reconnaît qu’il a été fermé et, par conséquent, arrêter ses services comme indiqué :

/var/log/messages dans node1 :

Feb 20 03:29:02 node1 corosync[1722]:  [TOTEM ] A processor failed, forming new configuration.
Feb 20 03:29:10 node1 corosync[1722]:  [TOTEM ] A new membership (1.116fc) was formed. Members joined: 2 left: 2
Feb 20 03:29:10 node1 corosync[1722]:  [QUORUM] Members[2]: 1 2
Feb 20 03:29:10 node1 pacemaker-fenced[1736]: notice: Operation 'reboot' targeting node2 by node1 for pacemaker-controld.1740@node1: OK
Feb 20 03:29:10 node1 pacemaker-controld[1740]: notice: Peer node2 was terminated (reboot) by node1 on behalf of pacemaker-controld.1740: OK
...
Feb 20 03:29:11 node1 corosync[1722]:  [CFG   ] Node 2 was shut down by sysadmin
Feb 20 03:29:11 node1 corosync[1722]:  [TOTEM ] A new membership (1.11700) was formed. Members left: 2
Feb 20 03:29:11 node1 corosync[1722]:  [QUORUM] Members[1]: 1
Feb 20 03:29:11 node1 corosync[1722]:  [MAIN  ] Completed service synchronization, ready to provide service.

/var/log/messages dans node2 :

Feb 20 03:29:11 [1155] node2 corosync notice  [TOTEM ] A new membership (1.116fc) was formed. Members joined: 1
Feb 20 03:29:11 [1155] node2 corosync notice  [QUORUM] Members[2]: 1 2
Feb 20 03:29:09 node2 pacemaker-controld  [1323] (tengine_stonith_notify)  crit: We were allegedly just fenced by node1 for node1!

Résolution du scénario 5

Configurez un délai de démarrage pour le service Crosync. Cette pause fournit suffisamment de temps pour qu’une nouvelle appartenance au groupe de processus fermé (CPG) forme et exclue le nœud fermé afin que le processus de redémarrage STONITH puisse se terminer en s’assurant que le message d’achèvement atteint tous les nœuds de l’appartenance.

Pour obtenir cet effet, exécutez les commandes suivantes :

  1. Placez le cluster en mode maintenance :

    sudo pcs property set maintenance-mode=true

  2. Créez un fichier déroulant système sur tous les nœuds du cluster :

  • Modifiez le fichier Corosync : 
    sudo systemctl edit corosync.service
  • Ajoutez les lignes suivantes : 
    [Service]
ExecStartPre=/bin/sleep 60
  • Après avoir enregistré le fichier et quitté l’éditeur de texte, rechargez la configuration systemd manager : 
    sudo systemctl daemon-reload
  1. Supprimez le cluster du mode maintenance :
sudo pcs property set maintenance-mode=false

Pour plus d’informations, reportez-vous au nœud clôturé qui ne parvient pas à rejoindre le cluster sans intervention manuelle

Prochaines étapes

Pour obtenir de l’aide supplémentaire, ouvrez une demande de support à l’aide des instructions suivantes. Lorsque vous envoyez votre demande, joignez le rapport SOS à partir de tous les nœuds du cluster pour la résolution des problèmes.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.