Solución de problemas de error del servicio SBD en clústeres de SUSE Pacemaker

Se aplica a: ✔️ Máquinas virtuales Linux

En este artículo se describen escenarios comunes en los que el servicio STONITH Block Device (SBD) no se inicia en un clúster de SUSE Enterprise Linux Pacemaker. En este artículo también se proporcionan instrucciones para identificar y resolver este problema.

Funcionamiento de SBD

Un dispositivo SBD requiere al menos una máquina virtual adicional (VM) que actúa como un servidor de destino de interfaz de sistema de equipos pequeños (iSCSI) de Internet y proporciona un dispositivo SBD. Estos servidores de destino iSCSI también se pueden compartir con otros clústeres de Pacemaker. La ventaja de usar un SBD es que, si ya las usa de forma local, los dispositivos SBD no requieren que cambie cómo funciona el clúster de Pacemaker.

Para un clúster de Microsoft Azure Pacemaker que tenga protección de almacenamiento SBD, puede usar cualquiera de las siguientes opciones para la configuración. Para obtener más información sobre estos mecanismos, consulte:

• SBD con un servidor de destino iscsi
• SBD con un disco compartido de Azure

Diagnóstico del problema

En el ejemplo siguiente se muestra cómo determinar que el problema de inicio del clúster se debe a un error del servicio SBD.

1. Compruebe el estado del clúster:

   sudo crm status
   

   ERROR: status: crm_mon (rc=102): Error: cluster is not available on this node
   

2. Compruebe si se inicia el servicio Pacemaker. La siguiente salida de ejemplo indica que se produjo un error en el servicio Pacemaker porque uno o varios servicios dependientes no funcionan:

   sudo systemctl status pacemaker
   

   pacemaker.service - Pacemaker High Availability Cluster Manager
      Loaded: loaded (/usr/lib/systemd/system/pacemaker.service; enabled; vendor preset: disabled)
      Active: inactive (dead) since Thu 2024-08-01 04:56:39 UTC; 2min 39s ago
        Docs: man:pacemakerd
   https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/index.html
   
   Aug 01 04:59:07 nfs-0 systemd[1]: Dependency failed for Pacemaker High Availability Cluster Manager.
   Aug 01 04:59:07 nfs-0 systemd[1]: pacemaker.service: Job pacemaker.service/start failed with result 'dependency'.
   

3. Compruebe el árbol de servicios de dependencia del servicio Pacemaker:

   sudo  systemctl list-dependencies pacemaker
   

   pacemaker.service
   ● ├─corosync.service
   ● ├─dbus.service
   ● ├─sbd.service
   ● ├─system.slice
   ● ├─resource-agents-deps.target
   ● └─sysinit.target
   

4. Compruebe el estado de cada servicio. En el ejemplo siguiente, puede ver que todos los servicios de dependencia, como Corosync, están activos, pero el servicio SBD no se está ejecutando:

   sudo systemctl status corosync
   

   corosync.service - Corosync Cluster Engine
     Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
     Active: active (running) since Thu 2024-08-01 04:49:15 UTC; 38s ago
    Process: 23972 ExecStop=/usr/share/corosync/corosync stop (code=exited, status=0/SUCCESS)
    Process: 24075 ExecStart=/usr/share/corosync/corosync start (code=exited, status=0/SUCCESS)
   Main PID: 24094 (corosync)
      Tasks: 2 (limit: 4096)
     CGroup: /system.slice/corosync.service
             └─24094 corosync
   
   Aug 01 04:49:15 nfs-0 corosync[24094]:   [TOTEM ] A new membership (10.0.0.6:32) was formed. Members joined: 2
   Aug 01 04:49:15 nfs-0 corosync[24094]:   [CPG  ] downlist left_list: 0 received in state 2
   Aug 01 04:49:15 nfs-0 corosync[24094]:   [VOTEQ ] Waiting for all cluster members. Current votes: 1 expected_votes: 2
   Aug 01 04:49:15 nfs-0 corosync[24094]:   [QUORUM] This node is within the primary component and will provide service.
   Aug 01 04:49:15 nfs-0 corosync[24094]:   [QUORUM] Members[2]: 1 2
   Aug 01 04:49:15 nfs-0 corosync[24094]:   [MAIN ] Completed service synchronization, ready to provide service.
   Aug 01 04:49:15 nfs-0 corosync[24075]: Starting Corosync Cluster Engine (corosync): [ OK ]
   

5. Compruebe el estado del servicio SBD. En este ejemplo, el servicio no se inicia y devuelve un Failed to start Shared-storage based fencing daemon mensaje de error:

   sudo systemctl status sbd
   

   ● sbd.service - Shared-storage based fencing daemon
      Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor preset: disabled)
      Active: failed (Result: timeout) since Thu 2024-08-01 04:59:07 UTC; 3min 3s ago
        Docs: man:sbd(8)
     Process: 25251 ExecStart=/usr/sbin/sbd $SBD_OPTS -p //run/sbd.pid watch (code=killed, signal=TERM)
   
   Aug 01 04:57:37 nfs-0 systemd[1]: Starting Shared-storage based fencing daemon...
   Aug 01 04:57:37 nfs-0 sbd[25251]:  warning: open_any_device: Failed to open /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779. Trying any o...ithin 120s
   Aug 01 04:59:07 nfs-0 systemd[1]: sbd.service: Start operation timed out. Terminating.
   Aug 01 04:59:07 nfs-0 systemd[1]: Failed to start Shared-storage based fencing daemon.
   Aug 01 04:59:07 nfs-0 systemd[1]: sbd.service: Unit entered failed state.
   Aug 01 04:59:07 nfs-0 systemd[1]: sbd.service: Failed with result 'timeout'.
   

Causa 1: error en el servicio SBD debido a un error iSCSI

El servicio Pacemaker no se está ejecutando y el servicio SBD está en estado de error en ambos nodos de clúster. Los servicios iSCSI usan el nombre calificado (IQN) iSCSI para la comunicación entre el iniciador y los nodos de destino. Los discos SBD pueden ser inaccesibles si no se ejecutan los servicios. Esto, a su vez, hace que se produzca un error en los servicios SBD y Pacemaker.

Solución

1. Asegúrese de que la configuración está configurada correctamente como se documenta en SUSE: configure Pacemaker en SUSE Linux Enterprise Server en Azure .
2. Coloque el clúster en modo de mantenimiento:

   sudo crm configure property maintenance-mode=true
   

3. Asegúrese de que los iscsid servicios y iscsi están habilitados:

   sudo systemctl enable iscsi
   

   sudo systemctl enable iscsid
   

4. Compruebe que el de iscsid y iscsi los servicios se están ejecutando:

   sudo systemctl status iscsi
   

   sudo systemctl status iscsid
   

   Si los servicios funcionan, la salida debe ser similar a la siguiente:

   iscsi.service - Login and scanning of iSCSI devices
   Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2024-08-01 04:18:51 UTC; 31min ago
   Docs: man:iscsiadm(8)
   man:iscsid(8)
   Main PID: 1823 (code=exited, status=0/SUCCESS)
   Tasks: 0 (limit: 4096)
   CGroup: /system.slice/iscsi.service
   
   Aug 01 04:18:51 nfs-0 systemd[1]: Starting Login and scanning of iSCSI devices...
   Aug 01 04:18:51 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.17,3260]
   Aug 01 04:18:51 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.18,3260]
   Aug 01 04:18:51 nfs-0 iscsiadm[1823]: Logging in to [iface: default, target: iqn.2006-04.nfs.local:nfs, portal: 10.0.0.19,3260]
   Aug 01 04:18:51 nfs-0 systemd[1]: Started Login and scanning of iSCSI devices.
   

5. Quite el clúster del modo de mantenimiento:

   sudo crm configure property maintenance-mode=false
   

Causa 2: Problemas de configuraciones

Las configuraciones de SBD incorrectas que tienen, por ejemplo, errores de sintaxis o dispositivos SBD con nombre incorrectos pueden provocar un error en el servicio SBD.

Resolución 1

Compruebe que el archivo de configuración de SBD, /etc/sysconfig/sbd, contiene el parámetro recomendado y los dispositivos SBD correctos:

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-xxxxxxxxxxxxxxxxxx;/dev/disk/by-id/scsi-xxxxxxxxxxxxxxxxx;/dev/disk/by-id/scsi-xxxxxxxxxxxxxxxxxx”

Resolución 2

Ejecute el siguiente comando para comprobar la configuración del recurso STONITH:

sudo crm configure show

primitive stonith-sbd stonith:external/sbd \
params pcmk_delay_max=30s \
op monitor interval="600" timeout="15"
stonith-enabled=true \
stonith-timeout=144 \

Causa 3: los dispositivos iSCSI no están disponibles en los nodos del clúster

Al ejecutar el lscsi comando o lsblk , los discos SBD no se muestran en la salida:

sudo lsscsi

[0:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sda
[0:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdb
[1:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sdc
[1:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdd

sudo lsblk

NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                   8:0    0  100G  0 disk
├─sda1                 8:1    0   2M  0 part
├─sda2                 8:2    0 512M  0 part /boot/efi
├─sda3                 8:3    0   1G  0 part /boot
└─sda4                8:4    0 98.5G  0 part /
sdb                   8:16   0   14G  0 disk
└─sdb1                8:17   0   14G  0 part /mnt
sdc                   8:32   0  100G  0 disk
└─sdc1                8:33   0  100G  0 part
 └─vg--NW1--NFS-NW1 254:0    0  100G  0 lvm
sdd                   8:48   0  100G  0 disk
└─sdd1                8:49   0  100G  0 part
 └─vg--NW2--NFS-NW2 254:1    0  100G  0 lvm

Solución

Realice las siguientes comprobaciones:

1. Compruebe el nombre del iniciador en ambos nodos de clúster:

   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
   

2. Pruebe a enumerar todos los dispositivos SBD que se mencionan en el archivo de configuración de 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"
   

3. En función del mensaje de error que se proporciona, compruebe si los servidores SBD se ejecutan y son accesibles:

   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.
   

4. Para corregir el error, ejecute los pasos siguientes en ambos nodos del clúster para conectarse a los dispositivos iSCSI después de asegurarse de que los servidores SBD están en ejecución y accesibles. En el ejemplo siguiente, iqn.2006-04.nfs.local:nfs es el nombre de destino que aparece al ejecutar el primer comando: iscsiadm -m discovery

   sudo iscsiadm -m discovery
   

   10.0.0.17:3260 via sendtargets
   10.0.0.18:3260 via sendtargets
   10.0.0.19:3260 via sendtargets
   

   sudo iscsiadm -m discovery --type=st --portal=10.0.0.17:3260
   

   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
   

   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.
   

   sudo iscsiadm -m node -p 10.0.0.17:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic
   

   sudo  lsscsi
   

   [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
   [0:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdb
   [1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc
   [1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdd
   [2:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sde
   

   Ejecute los mismos comandos para conectarse al resto de los dispositivos. Además, ejecute el mismo conjunto de comandos en el otro nodo del clúster.

5. Una vez detectados los dispositivos iSCSI, la salida del comando debe reflejar los dispositivos SBD:

   sudo lsscsi
   

   [0:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sda
   [0:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdb
   [1:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sdc
   [1:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdd
   [2:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sde
   [3:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sdf
   [4:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sdg
   

   sudo lsblk
   

   NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
   sda                   8:0    0  100G  0 disk
   ├─sda1                 8:1    0   2M  0 part
   ├─sda2                 8:2    0 512M  0 part /boot/efi
   ├─sda3                 8:3    0   1G  0 part /boot
   └─sda4                8:4    0 98.5G  0 part /
   sdb                   8:16   0   14G  0 disk
   └─sdb1                8:17   0   14G  0 part /mnt
   sdc                   8:32   0  100G  0 disk
   └─sdc1                8:33   0  100G  0 part
   └─vg--NW1--NFS-NW1 254:0    0  100G  0 lvm
   sdd                   8:48   0  100G  0 disk
   └─sdd1                8:49   0  100G  0 part
   └─vg--NW2--NFS-NW2 254:1    0  100G  0 lvm
   sde                   8:64   0   50M  0 disk
   sdf                   8:80   0   50M  0 disk
   sdg                   8:96   0   50M  0 disk
   

Causa 4: El nodo no se vuelve a unir al clúster después de la barrera

Uno de los nodos no vuelve a unir el clúster después de que finalice el proceso de barrera. SBD está en estado de error y el otro nodo está en estado pendiente.

Resolución 1

Es posible que la ranura SBD no esté en un estado limpio. Por lo tanto, el nodo no puede volver a unir el clúster después de reiniciar una barrera. Para comprobar el estado de SBD, ejecute los siguientes comandos. Si la ranura SBD no está limpia, el estado de SBD muestra reset:

sudo lsscsi

[0:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sda
[0:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdb
[1:0:0:0]    disk    Msft    Virtual Disk     1.0   /dev/sdc
[1:0:0:1]    disk    Msft    Virtual Disk     1.0   /dev/sdd
[2:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sde
[3:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sdf
[4:0:0:0]    disk    LIO-ORG sbdnfs           4.0   /dev/sdg

sudo ls -l /dev/disk/by-id/scsi-*

sudo sbd -d /dev/sde list

0       nfs-0   clear
1       nfs-1   reset  nfs-0

Resolución 2

Compruebe el /etc/sysconfig/sbd archivo de configuración y compruebe si el SBD_STARTMODE parámetro está establecido always en o clean:

sudo grep -i SBD_STARTMODE  /etc/sysconfig/sbd

SBD_STARTMODE=clean

El SBD_STARTMODE parámetro determina si un nodo puede volver a unir el clúster. Si se establece alwaysen , el nodo se volverá a unir al clúster aunque se haya cercado anteriormente. Si el parámetro se establece cleanen , el nodo se volverá a unir solo después de que se produzca un estado limpio.

Este comportamiento es normal. SBD detecta un mensaje de barrera en la ranura del nodo e impide que se una al clúster hasta que se borre manualmente el problema.

Para borrar la ranura de nodo, siga estos pasos:

1. Borre el mensaje de barrera para el nodo local:

   sudo sbd -d <SBD_DEVICE> message LOCAL clear
   

   También puede ejecutar el comando desde cualquier nodo del clúster especificando el nombre del nodo en lugar de LOCAL:

   sudo sbd -d <DEVICE_NAME> message <NODENAME> clear
   

   El nombre del nodo que especificó debe ser el nodo cercado y no puede unirse al clúster:

   sudo sbd -d /dev/sde message nfs-1 clear
   

2. Una vez desactivada la ranura de nodo, debería poder iniciar el servicio de agrupación en clústeres. Si se produce un error en el servicio de nuevo, ejecute los siguientes comandos para corregir el problema:

   sudo iscsiadm -m node -u
   

   sudo iscsiadm -m node -l
   

Nota:

En estos comandos, reemplace <SBD_DEVICE>y<DEVICE_NAME><NODENAME> por los valores reales por la configuración del clúster.

Causa 5: el servicio SBD no se inicia después de agregar un nuevo dispositivo SBD

Después de crear un dispositivo SBD o agregar uno a un clúster, recibirá un sbd failed; please check the logs mensaje de error.

Compruebe si recibe mensajes de error al enviar mensajes a dispositivos SBD:

sudo sbd -d  /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 message node1 test

Si llega a este problema, verá el siguiente error:

sbd failed; please check the logs.

Desde /var/log/messages:

/var/log/messages 
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!

Solución

Cuando se usa SBD como dispositivo de barrera y se habilita para un clúster de Pacemaker, los servicios deben administrarse bajo el control del clúster. Por lo tanto, no se pueden iniciar ni detener manualmente. Además, al habilitar un dispositivo SBD o agregarlo al clúster, debe reiniciar el clúster de Pacemaker para que los cambios surtan efecto en el control del clúster:

1. Reinicie los servicios de clúster en todos los nodos de clúster:

   sudo crm cluster stop
   sudo crm cluster start
   

2. Compruebe si el servicio SBD se inicia correctamente:

   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)
   

3. Compruebe si la lista de dispositivos SBD proporciona la salida deseada:

   sudo sbd -d /dev/disk/by-id/scsi-360014056eadbecfeca042d4a66b9d779 list
   

   0   node1   clear   
   1   node2   clear   
   

Causa 6: SBD no se inicia después de la actualización de SLES 12 a SLES 15

Después de actualizar un sistema SLES 12 a SLES 15, es posible que la información del cliente iSCSI no exista. Esta condición hace que las conexiones a sistemas de archivos remotos a través de iSCSI produzcan un error.

Solución

En SLES 15, el paquete en desuso se reemplazó targetcli-fb por python3-targetcli-fb o python2-targetcli-fb. Esto hace que la información del servicio del sistema se restablezca al valor predeterminado (deshabilitado o detenido). Para resolver el problema, debe habilitar e iniciar manualmente el targetcli servicio. Para obtener más información, consulte Error de SBD después de la actualización de SLES15.

Pasos siguientes

Para obtener ayuda adicional, abra una solicitud de soporte técnico mediante las instrucciones siguientes. Al enviar la solicitud, adjunte supportconfig y hb_report registros para solucionar problemas.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.