Поделиться через

Устранение неполадок службы SBD в кластерах RHEL Pacemaker

Область применения: ✔️ виртуальные машины Linux

В этой статье описаны распространенные сценарии, в которых служба STONITH Block Device (SBD) не запускается в кластере Red Hat Enterprise Server (RHEL) Pacemaker и предоставляет рекомендации по выявлению и устранению этой проблемы.

Как работает SBD

Для устройства SBD требуется по крайней мере одна дополнительная виртуальная машина, выступающая в роли сервера цели интерфейса малых вычислительных систем Интернета (iSCSI) и предоставляющая устройство SBD. Эти целевые серверы iSCSI также можно совместно использовать с другими кластерами Pacemaker. Преимуществом использования устройства SBD является то, что если вы уже используете устройства SBD в локальной среде, вам не понадобиться изменять способ эксплуатации кластера Pacemaker.

Чтобы настроить кластер Azure Pacemaker с помощью механизма ограждения SBD, используйте один из двух вариантов:

Симптомы

Устройство SBD недоступно на узлах кластера. В этом случае управляющая программа SBD не запускается и предотвращает запуск кластера Pacemaker.

Чтобы получить сведения о сервере SBD, используйте следующие методы на узлах кластера:

  • Проверьте журналы в файле /var/log/messages .
  • Проверьте выходные iscsiadm discovery данные команды.
  • Проверьте состояние службы iSCSI, указывающей IP-адреса сервера SBD.

Сценарий 1. Служба SBD не запускается из-за сбоев службы iSCSI

Службы iSCSI используют полное имя iSCSI (IQN) для обмена данными между инициатором и целевыми узлами. Если службы iSCSI завершаются ошибкой, диски SBD становятся недоступными, что приводит к сбою запуска службы SBD, и служба Pacemaker не выполняется на узлах кластера.

В следующих примерах показано, как диагностировать сбои служб SBD и Pacemaker:

  1. Проверьте состояние кластера Pacemaker:

    sudo pcs status

    Если кластер Pacemaker не выполняется, вы увидите выходные данные команды, похожие на следующий текст:

    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. Проверьте состояние службы Corosync:

    sudo systemctl status corosync

    Если служба Corosync запущена, вы увидите выходные данные команды, похожие на следующий текст:

    ● 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. Проверьте состояние службы Pacemaker:

    sudo systemctl status pacemaker

    Служба SBD необходима для запуска службы Pacemaker. Если служба Pacemaker не запускается из-за сбоев зависимостей, вы увидите выходные данные команды, похожие на следующий текст:

    ○ 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. Перечислить дерево служб зависимостей службы Pacemaker:

    sudo systemctl list-dependencies pacemaker

    Если у службы Pacemaker нет службы SBD в качестве зависимости, вы увидите выходные данные команды, похожие на следующий текст:

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

  5. Проверьте состояние службы SBD:

    sudo systemctl status sbd

    Если служба SBD не выполняется, вы увидите выходные данные команды, похожие на следующий текст:

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

Разрешение. Убедитесь, что службы iscsid и iscsi включены и запущены

Проблему можно устранить следующим способом.

  1. Убедитесь, что настроена правильная конфигурация, как описано в RHEL. Настройка Pacemaker в Red Hat Enterprise Linux в Azure

  2. Включите обе iscsid службы и iscsi службы:

    sudo systemctl enable iscsi

    sudo systemctl enable iscsid

  3. Проверьте состояние iscsid и iscsi службы:

    sudo systemctl status iscsi 

    sudo systemctl status iscsid

    Если службы включены и выполняются, вы увидите выходные данные команды, похожие на следующий текст:

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

Сценарий 2. Служба SBD не запускается из-за проблем конфигурации SBD

Служба SBD не запускается из-за следующих проблем:

  • Отсутствуют конфигурации SBD.
  • Неправильные конфигурации SBD, такие как неправильные имена устройств SBD или синтаксические ошибки.

Разрешение. Убедитесь, что существует правильная конфигурация SBD

  1. Проверьте наличие конфигурации SBD:

    sudo pcs stonith config sbd

    Если конфигурация SBD существует, вы увидите выходные данные команды, похожие на следующий текст:

    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. Проверьте и убедитесь, что файл конфигурации SBD /etc/sysconfig/sbd имеет следующие рекомендуемые параметры и правильные устройства SBD:

    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”

Сценарий 3. Устройства iSCSI недоступны на узлах кластера

Чтобы проверить, доступны ли устройства iSCSI на узлах кластера, выполните следующую lsscsi или lsblk команду. Если устройства iSCSI недоступны, диски 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

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

Разрешение. Включение автоматического входа на целевые серверы iSCSI

  1. Проверьте имена инициаторов на всех узлах кластера:

    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. Вывод списка всех устройств SBD в файле конфигурации 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. Проверьте, работают ли и доступны устройства SBD. Если службы SBD не запущены и доступны, отобразится сообщение "Сбой sbd; Проверьте журналы". Сообщение об ошибке.

    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. Включите автоматическое вход на целевые серверы iSCSI.

    1. iscsiadm Выполните обнаружение на узле кластера:

      sudo iscsiadm -m discovery

      В выходных данных команды показаны IP-адреса всех целевых серверов iSCSI и порт по умолчанию 3260:

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

    2. Обнаружение целевого сервера iSCSI на заданном IP-адресе:

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

      В выходных данных команды отображается целевое имя, например 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. Войдите на устройство 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. Включите автоматическое вход на устройство 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. Проверьте, доступно ли устройство iSCSI:

      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. Повторите шаг b-f, чтобы обеспечить доступность других устройств iSCSI.

    7. Повторите шаг a-f на другом узле кластера, чтобы убедиться, что все устройства iSCSI на другом узле кластера доступны.

После того как устройства iSCSI будут доступны, lsscsi выходные данные или lsblk команды должны отображать диски 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

Сценарий 4. Узел не сможет повторно присоединиться к кластеру после забора

Если слот SBD не находится в чистом состоянии, узел не сможет повторно присоединиться к кластеру после забора. Это приводит к тому, что устройство SBD находится в состоянии сбоя, а другой узел находится в состоянии ожидания.

Чтобы проверить состояние слота 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 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

Разрешение. Очистка слота SBD

  1. SBD_STARTMODE Проверьте, задан always ли параметр или clean в файле конфигурации SBD /etc/sysconfig/sbd:

    sudo grep -i SBD_STARTMODE  /etc/sysconfig/sbd

    SBD_STARTMODE=clean

    Параметр SBD_STARTMODE определяет, выполняется ли повторное присоединение узла. Если задано alwaysзначение , даже если узел был ранее заборирован, он повторно присоединит кластер. Если задано значение clean, узел повторно присоединит кластер после очистки слота SBD. Это ожидаемое поведение. Он обнаруживает сообщение типа ограждения в слоте SBD для узла и не позволяет узлу повторно присоединиться к кластеру, если только слот SBD не очищается вручную.

  2. Снимите слот SBD на узле, который ранее был заборирован и не смог повторно присоединиться к кластеру:

    sudo sbd -d <SBD_DEVICE> message LOCAL clear

    Если вы знаете имя узла, можно очистить слот SBD с помощью следующей команды:

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

    Примечание.

    Замените <SBD_DEVICE>и <NODENAME><DEVICE_NAME> соответственно.

    Например, команда может быть следующей:

    sudo sbd -d /dev/sdc message node2 clear

  3. После очистки слота SBD запустите службу кластера.

    Если служба кластера снова завершается ошибкой, выполните следующие команды, чтобы устранить проблему:

    sudo iscsiadm -m node -u

    sudo iscsiadm -m node -l

Сценарий 5. Служба SBD не запускается после добавления нового устройства SBD

После добавления нового устройства SBD в кластер вы увидите следующие симптомы:

  • При проверке состояния службы SBD, выполнив sudo systemctl status sbd команду, вы получите сообщение об ошибке "сбой sbd; Проверьте журналы и "Не удалось запустить sbd.service: операция отказалась".

  • При отправке тестового сообщения на узел устройствами SBD, выполнив следующую команду, вы также получите то же сообщение об ошибке:

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

    sbd failed; please check the logs.

    В файле /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!

  • При выполнении sbd -d list команды отображается пустой результат. Дополнительные сведения см. в списке устройств SBD с пустыми выходными данными.

Разрешение. Перезапуск кластера Pacemaker

При использовании SBD в качестве устройства ограждения и включения его для кластера Pacemaker службы должны управляться под управлением кластера. Таким образом, вы не можете запустить или остановить его вручную. После добавления нового устройства SBD в кластер Pacemaker необходимо перезапустить кластер Pacemaker, чтобы устройство SBD вступило в силу под контролем кластера.

  1. Остановите и перезапустите службы кластера на всех узлах кластера.

    sudo pcs cluster stop --all

    sudo pcs cluster start --all

  2. Проверьте, успешно ли запускается служба SBD.

    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)

После запуска sbd -d list службы SBD команда не будет отображать пустые выходные данные:

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

0   node1   clear   
1   node2   clear

Следующие шаги

Если проблема не устранена, соберите системные журналы из систем Red Hat, создайте отчет sos и обратитесь в службу поддержки. Дополнительные сведения см. в разделе "Что такое отчет sos" и как создать его в Red Hat Enterprise Linux?.

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

В этой статье упомянуты программные продукты независимых производителей. Корпорация Microsoft не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.