Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a: ✔️ macchine virtuali Linux
Questo articolo illustra scenari comuni in cui il servizio STONITH Block Device (SBD) non viene avviato in un cluster Red Hat Enterprise Server (RHEL) Pacemaker e fornisce indicazioni per identificare e risolvere questo problema.
Funzionamento di SBD
Il dispositivo SBD richiede almeno una macchina virtuale (VM) aggiunta che funga da server di destinazione iSCSI (Internet Small Computer System Interface) e fornisce un dispositivo SBD. Questi server di destinazione iSCSI possono anche essere condivisi con altri cluster Pacemaker. Il vantaggio dell'uso di un dispositivo SBD consiste nel fatto che se già si usano dispositivi SBD in locale, tali dispositivi non richiedono alcuna modifica alla modalità di utilizzo del cluster Pacemaker.
Per configurare un cluster Di Azure Pacemaker con il meccanismo di isolamento SBD, usare una delle due opzioni seguenti:
Sintomi
Il dispositivo SBD non è accessibile nei nodi del cluster. In questo caso, il daemon SBD non viene avviato e impedisce l'avvio del cluster Pacemaker.
Per ottenere i dettagli del server SBD, usare i metodi seguenti nei nodi del cluster:
- Controllare i log nel file /var/log/messages .
- Controllare l'output del
iscsiadm discovery
comando. - Controllare lo stato del servizio iSCSI che indica gli indirizzi IP del server SBD.
Scenario 1: Il servizio SBD non viene avviato a causa di errori del servizio iSCSI
I servizi iSCSI usano iSCSI Qualified Name (IQN) per la comunicazione tra i nodi iniziatori e di destinazione. Se i servizi iSCSI hanno esito negativo, i dischi SBD diventano inaccessibili, causando l'avvio del servizio SBD e l'esecuzione del servizio Pacemaker nei nodi del cluster.
Gli esempi seguenti illustrano come diagnosticare gli errori del servizio SBD e Pacemaker:
Controllare lo stato del cluster Pacemaker:
sudo pcs status
Se il cluster Pacemaker non viene eseguito, verrà visualizzato l'output del comando simile al testo seguente:
Error: error running crm_mon, is pacemaker running? error: Could not connect to launcher: Connection refused crm_mon: Connection to cluster failed: Connection refused
Controllare lo stato del servizio Corosync:
sudo systemctl status corosync
Se il servizio Corosync è in esecuzione, verrà visualizzato l'output del comando simile al testo seguente:
● corosync.service - Corosync Cluster Engine Loaded: loaded (/usr/lib/systemd/system/corosync.service; enabled; preset: disabled) Active: active (running) since Thu 2024-08-01 11:22:28 UTC; 1min 22s ago Docs: man:corosync man:corosync.conf man:corosync_overview Main PID: 12793 (corosync) Tasks: 9 (limit: 48956) Memory: 113.9M CPU: 401ms CGroup: /system.slice/corosync.service └─12793 /usr/sbin/corosync -f Aug 01 11:22:43 node1 corosync[12793]: [KNET ] link: Resetting MTU for link 0 because host 2 joined Aug 01 11:22:43 node1 corosync[12793]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1) Aug 01 11:22:43 node1 corosync[12793]: [KNET ] pmtud: PMTUD link change for host: 2 link: 0 from 469 to 1397 Aug 01 11:22:43 node1 corosync[12793]: [KNET ] pmtud: Global data MTU changed to: 1397 Aug 01 11:22:45 node1 corosync[12793]: [QUORUM] Sync members[2]: 1 2 Aug 01 11:22:45 node1 corosync[12793]: [QUORUM] Sync joined[1]: 2 Aug 01 11:22:45 node1 corosync[12793]: [TOTEM ] A new membership (1.3e) was formed. Members joined: 2 Aug 01 11:22:45 node1 corosync[12793]: [QUORUM] This node is within the primary component and will provide service. Aug 01 11:22:45 node1 corosync[12793]: [QUORUM] Members[2]: 1 2 Aug 01 11:22:45 node1 corosync[12793]: [MAIN ] Completed service synchronization, ready to provide service.
Controllare lo stato del servizio Pacemaker:
sudo systemctl status pacemaker
Il servizio SBD è necessario per l'avvio del servizio Pacemaker. Se il servizio Pacemaker non viene avviato a causa di errori di dipendenza, verrà visualizzato l'output del comando simile al testo seguente:
○ pacemaker.service - Pacemaker High Availability Cluster Manager Loaded: loaded (/usr/lib/systemd/system/pacemaker.service; enabled; preset: disabled) Active: inactive (dead) since Thu 2024-08-01 11:22:22 UTC; 2min 9s ago Docs: man:pacemakerd https://clusterlabs.org/pacemaker/doc/ Aug 01 11:24:28 node1 systemd[1]: Dependency failed for Pacemaker High Availability Cluster Manager. Aug 01 11:24:28 node1 systemd[1]: pacemaker.service: Job pacemaker.service/start failed with result 'dependency'.
Elencare l'albero dei servizi di dipendenza del servizio Pacemaker:
sudo systemctl list-dependencies pacemaker
Se il servizio Pacemaker non ha il servizio SBD come dipendenza, verrà visualizzato l'output del comando simile al testo seguente:
pacemaker.service ● ├─corosync.service ● ├─dbus-broker.service × ├─sbd.service ● ├─system.slice ● ├─resource-agents-deps.target ● └─sysinit.target
Controllare lo stato del servizio SBD:
sudo systemctl status sbd
Se l'esecuzione del servizio SBD non riesce, verrà visualizzato l'output del comando simile al testo seguente:
× sbd.service - Shared-storage based fencing daemon Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; preset: disabled) Drop-In: /etc/systemd/system/sbd.service.d └─sbd_delay_start.conf Active: failed (Result: exit-code) since Thu 2024-08-01 11:24:28 UTC; 1min 56s ago Duration: 55min 34.369s Docs: man:sbd(8) Process: 12794 ExecStart=/usr/sbin/sbd $SBD_OPTS -p /run/sbd.pid watch (code=exited, status=1/FAILURE) CPU: 46ms Aug 01 11:22:27 node1 systemd[1]: Starting Shared-storage based fencing daemon... Aug 01 11:22:27 node1 sbd[12794]: warning: open_any_device: Failed to open /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779. Trying any other config> Aug 01 11:24:28 node1 sbd[12794]: error: open_any_device: No devices were available at start-up within 120 seconds. Aug 01 11:24:28 node1 systemd[1]: sbd.service: Control process exited, code=exited, status=1/FAILURE Aug 01 11:24:28 node1 systemd[1]: sbd.service: Failed with result 'exit-code'. Aug 01 11:24:28 node1 systemd[1]: Failed to start Shared-storage based fencing daemon.
Soluzione: assicurarsi che i servizi iscsid e iscsi siano abilitati ed in esecuzione
Per risolvere il problema, seguire questa procedura:
Assicurarsi di configurare la configurazione corretta come descritto in RHEL - Configurare Pacemaker in Red Hat Enterprise Linux in Azure
Abilitare entrambi
iscsid
i servizi eiscsi
:sudo systemctl enable iscsi
sudo systemctl enable iscsid
Verificare lo stato dei
iscsid
servizi eiscsi
:sudo systemctl status iscsi
sudo systemctl status iscsid
Se i servizi sono abilitati ed eseguiti, verrà visualizzato l'output del comando simile al testo seguente:
● iscsi.service - Login and scanning of iSCSI devices Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled; preset: enabled) Active: active (exited) since Thu 2024-08-01 10:28:36 UTC; 1h 0min ago Docs: man:iscsiadm(8) man:iscsid(8) Process: 11174 ExecStart=/usr/sbin/iscsiadm -m node --loginall=automatic (code=exited, status=24) Main PID: 11174 (code=exited, status=24) CPU: 33ms Aug 01 10:28:36 nfs-0 systemd[1]: Starting Login and scanning of iSCSI devices... Aug 01 10:28:36 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260] Aug 01 10:28:36 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.18,3260] Aug 01 10:28:36 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.19,3260] Aug 01 10:28:36 nfs-0 systemd[1]: Started Login and scanning of iSCSI devices.
Scenario 2: Il servizio SBD non viene avviato a causa di problemi di configurazione sbd
L'avvio del servizio SBD non riesce a causa dei problemi seguenti:
- Configurazioni SBD mancanti.
- Configurazioni SBD non corrette, ad esempio nomi di dispositivi SBD non corretti o errori di sintassi.
Soluzione: verificare che la configurazione SBD corretta esista
Verificare che la configurazione SBD esista:
sudo pcs stonith config sbd
Se la configurazione SBD esiste, verrà visualizzato l'output del comando simile al testo seguente:
Resource: sbd (class=stonith type=fence_sbd) Attributes: sbd-instance_attributes devices=/dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779,/dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a,/dev/disk/by- id/scsi-36001405a29a443e4a6e4ceeae822e5eb Operations: monitor: sbd-monitor-interval-600 interval=600 timeout=15
Convalidare e verificare che il file di configurazione SBD /etc/sysconfig/sbd disponga dei parametri consigliati seguenti e dei dispositivi SBD corretti:
SBD_PACEMAKER=yes SBD_STARTMODE=always SBD_DELAY_START=no SBD_WATCHDOG_DEV=/dev/watchdog SBD_WATCHDOG_TIMEOUT=5 SBD_TIMEOUT_ACTION=flush,reboot SBD_MOVE_TO_ROOT_CGROUP=auto SBD_OPTS= SBD_DEVICE="/dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d77;/dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a;/dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb”
Scenario 3: i dispositivi iSCSI non sono disponibili nei nodi del cluster
Per verificare se i dispositivi iSCSI sono disponibili nei nodi del cluster, eseguire il comando o lsblk
seguentelsscsi
. Se i dispositivi iSCSI non sono disponibili, i dischi SBD non verranno visualizzati nell'output del comando.
sudo lsscsi
[0:0:0:0] disk Msft Virtual Disk 1.0 /dev/sda
[1:0:1:0] disk Msft Virtual Disk 1.0 /dev/sdb
[5:0:0:0] cd/dvd Msft Virtual CD/ROM 1.0 /dev/sr0
sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 64G 0 disk
├─sda1 8:1 0 200M 0 part /boot/efi
├─sda2 8:2 0 500M 0 part /boot
├─sda3 8:3 0 1M 0 part
└─sda4 8:4 0 63.3G 0 part
├─rootvg-tmplv 253:0 0 2G 0 lvm /tmp
├─rootvg-usrlv 253:1 0 10G 0 lvm /usr
├─rootvg-homelv 253:2 0 1G 0 lvm /home
├─rootvg-varlv 253:3 0 8G 0 lvm /var
└─rootvg-rootlv 253:4 0 2G 0 lvm /
sdb 8:16 0 16G 0 disk
└─sdb1 8:17 0 16G 0 part /mnt
sr0 11:0 1 628K 0 rom
Soluzione: abilitare l'accesso automatico ai server di destinazione iSCSI
Convalidare i nomi degli iniziatori in tutti i nodi del cluster:
sudo cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2006-04.nfs-0.local:nfs-0
sudo cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2006-04.nfs-1.local:nfs-1
Elencare tutti i dispositivi SBD nel file di configurazione SBD.
sudo grep SBD_DEVICE /etc/sysconfig/sbd
# SBD_DEVICE specifies the devices to use for exchanging sbd messages SBD_DEVICE="/dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779;/dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a;/dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb"
Controllare se i dispositivi SBD sono in esecuzione e accessibili. Se i servizi SBD non sono in esecuzione e accessibili, verrà visualizzato il messaggio "sbd failed; controllare i log." messaggio di errore.
sudo /usr/sbin/sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 list
== disk /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 unreadable! sbd failed; please check the logs.
sudo /usr/sbin/sbd -d /dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a list
== disk /dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a unreadable! sbd failed; please check the logs.
sudo /usr/sbin/sbd -d /dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb list
== disk /dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb unreadable! sbd failed; please check the logs.
Abilitare l'accesso automatico ai server di destinazione iSCSI.
Eseguire un'individuazione
iscsiadm
in un nodo del cluster:sudo iscsiadm -m discovery
L'output del comando mostra gli indirizzi IP di tutti i server di destinazione iSCSI e la porta predefinita 3260:
10.0.0.17:3260 via sendtargets 10.0.0.18:3260 via sendtargets 10.0.0.19:3260 via sendtargets
Individuazione del server di destinazione iSCSI in un determinato indirizzo IP:
sudo iscsiadm -m discovery --type=st --portal=10.0.0.17:3260
L'output del comando mostra un nome di destinazione,
iqn.2006-04.nfs.local:nfs
ad esempio :10.0.0.17:3260,1 iqn.2006-04.dbnw1.local:dbnw1 10.0.0.17:3260,1 iqn.2006-04.ascsnw1.local:ascsnw1 10.0.0.17:3260,1 iqn.2006-04.nfs.local:nfs
Accedere al dispositivo iSCSI:
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.17:3260
Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260] Login to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260] successful.
Abilitare l'accesso automatico al dispositivo iSCSI:
sudo iscsiadm -m node -p 10.0.0.17:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic
Verificare se il dispositivo iSCSI è disponibile:
sudo lsscsi
[0:0:0:0] disk Msft Virtual Disk 1.0 /dev/sda [1:0:1:0] disk Msft Virtual Disk 1.0 /dev/sdb [5:0:0:0] cd/dvd Msft Virtual CD/ROM 1.0 /dev/sr0 [6:0:0:0] disk LIO-ORG sbdnfs 4.0 /dev/sdc
Ripetere il passaggio b-f per assicurarsi che altri dispositivi iSCSI siano disponibili.
Ripetere il passaggio a-f in un altro nodo del cluster per assicurarsi che tutti i dispositivi iSCSI in un altro nodo del cluster siano disponibili.
Quando i dispositivi iSCSI sono disponibili, l'output del lsscsi
comando o lsblk
dovrebbe visualizzare i dischi SBD.
sudo lsscsi
[0:0:0:0] disk Msft Virtual Disk 1.0 /dev/sda
[1:0:1:0] disk Msft Virtual Disk 1.0 /dev/sdb
[5:0:0:0] cd/dvd Msft Virtual CD/ROM 1.0 /dev/sr0
[6:0:0:0] disk LIO-ORG sbdnfs 4.0 /dev/sdc
[7:0:0:0] disk LIO-ORG sbdnfs 4.0 /dev/sdd
[8:0:0:0] disk LIO-ORG sbdnfs 4.0 /dev/sde
sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 64G 0 disk
├─sda1 8:1 0 200M 0 part /boot/efi
├─sda2 8:2 0 500M 0 part /boot
├─sda3 8:3 0 1M 0 part
└─sda4 8:4 0 63.3G 0 part
├─rootvg-tmplv 253:0 0 2G 0 lvm /tmp
├─rootvg-usrlv 253:1 0 10G 0 lvm /usr
├─rootvg-homelv 253:2 0 1G 0 lvm /home
├─rootvg-varlv 253:3 0 8G 0 lvm /var
└─rootvg-rootlv 253:4 0 2G 0 lvm /
sdb 8:16 0 16G 0 disk
└─sdb1 8:17 0 16G 0 part /mnt
sdc 8:32 0 50M 0 disk
sdd 8:48 0 50M 0 disk
sde 8:64 0 50M 0 disk
sr0 11:0 1 628K 0 rom
Scenario 4: il nodo non riesce a ricongiuscrirsi al cluster dopo essere stato delimitato
Se lo slot SBD non è in uno stato pulito, il nodo non riuscirà a completare nuovamente il cluster dopo essere stato delimitato. Ciò causa che il dispositivo SBD è in stato di errore e un altro nodo è in sospeso.
Per convalidare lo stato dello slot SBD, eseguire i comandi seguenti:
sudo lsscsi
[0:0:0:0] disk Msft Virtual Disk 1.0 /dev/sda
[1:0:1:0] disk Msft Virtual Disk 1.0 /dev/sdb
[5:0:0:0] cd/dvd Msft Virtual CD/ROM 1.0 /dev/sr0
[6:0:0:0] disk LIO-ORG sbdnfs 4.0 /dev/sdc
[7:0:0:0] disk LIO-ORG sbdnfs 4.0 /dev/sdd
[8:0:0:0] disk LIO-ORG sbdnfs 4.0 /dev/sde
sudo sbd -d /dev/sdc list
0 node1 clear
1 node2 reset node1
sudo sbd -d /dev/sdd list
0 node1 clear
1 node2 reset node1
sudo sbd -d /dev/sde list
0 node1 clear
1 node2 reset node1
Risoluzione: cancellare lo slot SBD
Verificare se il
SBD_STARTMODE
parametro è impostato sualways
oclean
nel file di configurazione SBD /etc/sysconfig/sbd:sudo grep -i SBD_STARTMODE /etc/sysconfig/sbd
SBD_STARTMODE=clean
Il
SBD_STARTMODE
parametro determina se un nodo si rielabora o meno. Se è impostato sualways
, anche se il nodo è stato delimitato in precedenza, rielabora il cluster. Se è impostato suclean
, il nodo rielabora il cluster dopo la cancellazione dello slot SBD. Si tratta di un comportamento previsto. Rileva un messaggio di tipo di isolamento nello slot SBD per il nodo e non consente al nodo di ricongiunrsi al cluster a meno che lo slot SBD non venga cancellato manualmente.Cancellare lo slot SBD nel nodo precedentemente delimitato e non è stato in grado di rientrare nel cluster:
sudo sbd -d <SBD_DEVICE> message LOCAL clear
Se si conosce il nome del nodo, è possibile cancellare lo slot SBD usando il comando seguente:
sudo sbd -d <DEVICE_NAME> message <NODENAME> clear
Note
Sostituire
<SBD_DEVICE>
e<DEVICE_NAME>
<NODENAME>
di conseguenza.Ad esempio, il comando potrebbe essere il seguente:
sudo sbd -d /dev/sdc message node2 clear
Dopo aver cancellato lo slot SBD, avviare il servizio cluster.
Se il servizio cluster non riesce di nuovo, eseguire i comandi seguenti per risolvere il problema:
sudo iscsiadm -m node -u
sudo iscsiadm -m node -l
Scenario 5: Il servizio SBD non viene avviato dopo l'aggiunta di un nuovo dispositivo SBD
Dopo aver aggiunto un nuovo dispositivo SBD nel cluster, vengono visualizzati i sintomi seguenti:
Quando si controlla lo stato del servizio SBD eseguendo il
sudo systemctl status sbd
comando , viene visualizzato il messaggio di errore "sbd failed; Controllare i log e "Non è stato possibile avviare sbd.service: operazione rifiutata".Quando si invia un messaggio di test a un nodo dai dispositivi SBD eseguendo il comando seguente, viene visualizzato anche lo stesso messaggio di errore:
sudo sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 message node1 test
sbd failed; please check the logs.
Nel file /var/log/messages sono disponibili anche i log seguenti:
Mar 2 06:58:06 node1 sbd[11105]: /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779: error: slot_msg: slot_msg(): No recipient / cmd specified. Mar 2 06:58:06 node1 sbd[11104]: warning: messenger: Process 11105 failed to deliver!
Quando si esegue il
sbd -d list
comando, viene visualizzato un output vuoto. Per altre informazioni, vedere Elenco di dispositivi SBD che mostra l'output vuoto.
Soluzione: riavviare il cluster Pacemaker
Quando si usa SBD come dispositivo di isolamento e lo si abilita per un cluster Pacemaker, i servizi devono essere gestiti sotto il controllo del cluster. Pertanto, non è possibile avviarlo/arrestarlo manualmente. Dopo aver aggiunto un nuovo dispositivo SBD nel cluster Pacemaker, è necessario riavviare il cluster Pacemaker per rendere effettivo il dispositivo SBD sotto il controllo del cluster.
Arrestare e riavviare i servizi cluster in tutti i nodi del cluster.
sudo pcs cluster stop --all
sudo pcs cluster start --all
Controllare se il servizio SBD viene avviato correttamente.
sudo systemctl status sbd.service
● sbd.service - Shared-storage based fencing daemon Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor preset: disabled) Active: active (running)
Quando il servizio SBD è in esecuzione, il sbd -d list
comando non visualizzerà un output vuoto:
sudo sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 list
0 node1 clear
1 node2 clear
Passaggi successivi
Se il problema non viene risolto, raccogliere i log di sistema dai sistemi Red Hat, generare un report sos e quindi contattare il supporto tecnico. Per altre informazioni, vedere Che cos'è un report sos e come crearne uno in Red Hat Enterprise Linux?.
Dichiarazione di non responsabilità sulle informazioni di terze parti
I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti
Contattaci per ricevere assistenza
In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.