Compartir a través de

Solución de problemas de errores del servicio SBD en clústeres de RHEL 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 Pacemaker de Red Hat Enterprise Server (RHEL) y proporciona instrucciones para identificar y resolver este problema.

Funcionamiento de SBD

El dispositivo SBD requiere al menos una máquina virtual adicional que actúe como servidor de destino de la 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 dispositivo SBD es que, si ya utiliza dispositivos SBD en un entorno local, no se necesitan cambios en el modo de operar con el clúster de Pacemaker.

Para configurar un clúster de Azure Pacemaker con el mecanismo de barrera de SBD, use cualquiera de las dos opciones:

Síntomas

El dispositivo SBD no es accesible en los nodos del clúster. En este caso, el demonio de SBD no se inicia y evita que el clúster de Pacemaker se inicie.

Para obtener los detalles del servidor SBD, use los métodos siguientes en los nodos del clúster:

  • Compruebe los registros en el archivo /var/log/messages .
  • Compruebe la salida del iscsiadm discovery comando.
  • Compruebe el estado del servicio iSCSI que indica las direcciones IP del servidor SBD.

Escenario 1: El servicio SBD no se puede iniciar debido a errores de servicio iSCSI

Los servicios iSCSI usan el nombre completo de iSCSI (IQN) para la comunicación entre el iniciador y los nodos de destino. Si se produce un error en los servicios iSCSI, los discos SBD dejan de estar accesibles, lo que provoca que el servicio SBD no se inicie y el servicio Pacemaker no se ejecute en los nodos del clúster.

En los ejemplos siguientes se muestra cómo diagnosticar errores del servicio SBD y Pacemaker:

  1. Compruebe el estado del clúster de Pacemaker:

    sudo pcs status

    Si el clúster de Pacemaker no se ejecuta, verá la salida del comando similar al texto siguiente:

    Error: error running crm_mon, is pacemaker running?
  error: Could not connect to launcher: Connection refused
  crm_mon: Connection to cluster failed: Connection refused

  2. Compruebe el estado del servicio Corosync:

    sudo systemctl status corosync

    Si el servicio Corosync se está ejecutando, verá la salida del comando similar al texto siguiente:

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

  3. Compruebe el estado del servicio Pacemaker:

    sudo systemctl status pacemaker

    El servicio SBD es necesario para que se inicie el servicio Pacemaker. Si el servicio Pacemaker no se inicia debido a errores de dependencia, verá la salida del comando similar al texto siguiente:

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

  4. Enumere el árbol de servicios de dependencia del servicio Pacemaker:

    sudo systemctl list-dependencies pacemaker

    Si el servicio Pacemaker no tiene el servicio SBD como dependencia, verá la salida del comando similar al texto siguiente:

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

  5. Compruebe el estado del servicio SBD:

    sudo systemctl status sbd

    Si el servicio SBD no se puede ejecutar, verá la salida del comando similar al texto siguiente:

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

Resolución: asegúrese de que los servicios iscsid e iscsi están habilitados y en ejecución.

Para resolver el problema, siga estos pasos:

  1. Asegúrese de configurar la configuración correcta como se describe en RHEL: Configuración de Pacemaker en Red Hat Enterprise Linux en Azure

  2. Habilite ambos iscsid servicios y iscsi :

    sudo systemctl enable iscsi

    sudo systemctl enable iscsid

  3. Compruebe el estado de los iscsid servicios y iscsi :

    sudo systemctl status iscsi 

    sudo systemctl status iscsid

    Si los servicios están habilitados y ejecutados, verá la salida del comando similar al texto siguiente:

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

Escenario 2: El servicio SBD no se puede iniciar debido a problemas de configuración de SBD

El servicio SBD no se puede iniciar debido a los siguientes problemas:

  • Faltan configuraciones de SBD.
  • Configuraciones de SBD incorrectas, como nombres de dispositivos SBD incorrectos o errores de sintaxis.

Resolución: asegúrese de que existe la configuración correcta de SBD.

  1. Valide que existe la configuración de SBD:

    sudo pcs stonith config sbd

    Si existe la configuración de SBD, verá la salida del comando similar al texto siguiente:

    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

  2. Valide y asegúrese de que el archivo de configuración de SBD /etc/sysconfig/sbd tiene los siguientes parámetros recomendados 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-360014056eadbecfeca042d4a66b9d77;/dev/disk/by-id/scsi-36001405cbac988092e448059d25d1a4a;/dev/disk/by-id/scsi-36001405a29a443e4a6e4ceeae822e5eb”

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

Para validar si los dispositivos iSCSI están disponibles en los nodos del clúster, ejecute el siguiente lsscsi comando o lsblk . Si los dispositivos iSCSI no están disponibles, los discos SBD no se mostrarán en la salida 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

Resolución: Habilitar el inicio de sesión automático en servidores de destino iSCSI

  1. Valide los nombres del iniciador en todos los nodos del 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. Enumere todos los dispositivos SBD 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. Compruebe si los dispositivos SBD están en ejecución y accesibles. Si los servicios SBD no se ejecutan y son accesibles, verá el error "sbd; Compruebe los registros". Mensaje de error.

    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.

  4. Habilite el inicio de sesión automático en servidores de destino iSCSI.

    1. Realice una iscsiadm detección en un nodo de clúster:

      sudo iscsiadm -m discovery

      La salida del comando muestra las direcciones IP de todos los servidores de destino iSCSI y el puerto predeterminado 3260:

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

    2. Detección del servidor de destino iSCSI en una dirección IP determinada:

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

      La salida del comando muestra un nombre de destino como iqn.2006-04.nfs.local:nfs:

      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

    3. Inicie sesión en el 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.

    4. Habilite el inicio de sesión automático en el 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

    5. Compruebe si el dispositivo iSCSI está disponible:

      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

    6. Repita el paso b-f para asegurarse de que hay otros dispositivos iSCSI disponibles.

    7. Repita el paso a-f en otro nodo de clúster para asegurarse de que todos los dispositivos iSCSI de otro nodo de clúster estén disponibles.

Una vez que los dispositivos iSCSI estén disponibles, la lsscsi salida del comando o lsblk debe mostrar discos 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

Escenario 4: El nodo no puede volver a unir el clúster después de estar cercado

Si la ranura SBD no está en un estado limpio, el nodo no podrá volver a unir el clúster después de estar cercado. Esto hace que el dispositivo SBD esté en estado de error y otro nodo esté en estado pendiente.

Para validar el estado de la ranura SBD, ejecute los siguientes comandos:

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

Resolución: borrar la ranura SBD

  1. Valide si el SBD_STARTMODE parámetro está establecido always en o clean en el archivo de configuración sbD /etc/sysconfig/sbd:

    sudo grep -i SBD_STARTMODE  /etc/sysconfig/sbd

    SBD_STARTMODE=clean

    El SBD_STARTMODE parámetro determina si un nodo se vuelve a unir o no. Si se establece en always, incluso si el nodo se ha cercado anteriormente, se vuelve a unir al clúster. Si se establece en , el nodo vuelve a cleanunir el clúster después de borrar el espacio SBD. Este es un comportamiento esperado. Detecta un mensaje de tipo de barrera en la ranura SBD para el nodo y no permite que el nodo se vuelva a unir al clúster a menos que se borre manualmente la ranura SBD.

  2. Borre la ranura SBD en el nodo que estaba previamente cercada y no pudo volver a unir el clúster:

    sudo sbd -d <SBD_DEVICE> message LOCAL clear

    Si conoce el nombre del nodo, puede borrar la ranura SBD mediante el siguiente comando:

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

    Nota:

    Reemplace <SBD_DEVICE>y<DEVICE_NAME> <NODENAME> en consecuencia.

    Por ejemplo, el comando podría ser el siguiente:

    sudo sbd -d /dev/sdc message node2 clear

  3. Una vez desactivada la ranura SBD, inicie el servicio de clúster.

    Si se produce un error en el servicio de clúster de nuevo, ejecute los siguientes comandos para corregir el problema:

    sudo iscsiadm -m node -u

    sudo iscsiadm -m node -l

Escenario 5: El servicio SBD no se inicia después de agregar un nuevo dispositivo SBD

Después de agregar un nuevo dispositivo SBD al clúster, verá los siguientes síntomas:

  • Al comprobar el estado del servicio SBD ejecutando el sudo systemctl status sbd comando , recibirá el mensaje de error "sbd failed; Compruebe los registros" y "No se pudo iniciar sbd.service: Operación rechazada".

  • Al enviar un mensaje de prueba a un nodo por dispositivos SBD mediante la ejecución del siguiente comando, también recibirá el mismo mensaje de error:

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

    sbd failed; please check the logs.

    En el archivo /var/log/messages , también encontrará los registros siguientes:

    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!

  • Al ejecutar el sbd -d list comando, se muestra una salida en blanco. Para obtener más información, consulte SBD device list (Lista de dispositivos SBD) que muestra la salida en blanco.

Solución: reinicio del clúster de Pacemaker

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 puede iniciar o detener manualmente. Después de agregar cualquier dispositivo SBD nuevo en el clúster de Pacemaker, debe reiniciar el clúster de Pacemaker para que el dispositivo SBD surta efecto en el control del clúster.

  1. Detenga y reinicie los servicios de clúster en todos los nodos del clúster.

    sudo pcs cluster stop --all

    sudo pcs cluster start --all

  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)

Una vez que se esté ejecutando el servicio SBD, el sbd -d list comando no mostrará una salida en blanco:

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

0   node1   clear   
1   node2   clear

Pasos siguientes

Si el problema no se resuelve, recopile registros del sistema de sistemas de Red Hat, genere un informe sos y póngase en contacto con el soporte técnico. Para obtener más información, consulte ¿Qué es un informe sos y cómo crear uno en Red Hat Enterprise Linux?.

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.

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.