Настройка кластера Pacemaker в SUSE Linux Enterprise Server в Azure

  • Статья

В этой статье описано, как настроить Pacemaker в SUSE Linux Enterprise Server (SLES) в Azure.

Обзор

В Azure есть два варианта для настройки ограничения в кластере Pacemaker для SLES. Вы можете использовать агент ограничения Azure, который перезапускает узел со сбоем через API Azure, или устройство SBD.

Использование устройства SBD

Настроить устройство SBD можно одним из двух способов:

  • SBD с сервером цели iSCSI:

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

    В кластере Pacemaker можно использовать до трех устройств SBD, что позволяет сделать устройство SBD недоступным (например, во время установки исправлений ОС на сервере цели iSCSI). Если вы хотите использовать несколько устройств SBD в Pacemaker, разверните несколько серверов цели iSCSI и подключите одно устройство SBD из каждого из этих серверов цели. Мы рекомендуем использовать одно устройство SBD или три. Если настроить только два устройства SBD и одно из них будет недоступно, Pacemaker не сможет автоматически изолировать узел кластера. Если вы хотите иметь возможность ограждения, когда один сервер цели iSCSI не работает, необходимо использовать три устройства SBD и, следовательно, три сервера цели iSCSI. Это самая устойчивая конфигурация при использовании устройств SBD.

    Схема обзора кластера Pacemaker на SLES.

    Внимание

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

    События обслуживания и другие проблемы с виртуальным сетевым устройством могут иметь негативное влияние на стабильность и надежность общей конфигурации кластера. Дополнительные сведения см. в статье о определяемых пользователем правилах маршрутизации.

  • SBD с общим диском Azure:

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

    Схема устройства SBD с общим диском Azure для кластера Pacemaker SLES.

    Ниже приведены некоторые важные замечания об использовании устройств SBD с общим диском Azure.

    • Как устройство SBD поддерживается общий диск Azure с SSD (цен. категория "Премиум").
    • Устройства SBD, использующие общий диск Azure, поддерживаются в SLES 15 SP01 с высоким уровнем доступности и более поздних версиях.
    • Устройства SBD, использующие общий диск Azure уровня "Премиум", поддерживаются в локально избыточном хранилище (LRS) и хранилище, избыточном между зонами (ZRS).
    • В зависимости от типа развертывания выберите соответствующее избыточное хранилище для общего диска Azure в качестве устройства SBD.
    • Устройство SBD, использующее LRS для общего диска Azure уровня "Премиум" (название SKU —Premium_LRS), поддерживается только при развертывании в группе доступности.
    • Устройство SBD, использующее ZRS для общего диска Azure уровня "Премиум" (название SKU — Premium_ZRS), рекомендуется использовать только при развертывании в зонах доступности.
    • Использование ZRS для управляемого диска сейчас не поддерживается во всех регионах с зонами доступности. Дополнительные сведения см. в разделе "Ограничения" (сведения касаются ZRS) статьи Возможности обеспечения избыточности для управляемых дисков.
    • Общий диск Azure, используемый для устройств SBD, не должен быть большим. Значение maxShares определяет, сколько узлов кластера может использовать общий диск. Например, вы можете использовать размеры дисков P1 или P2 для устройства SBD в кластере с двумя узлами, таком как SAP ASCS/ERS или SAP HANA для вертикального увеличения масштаба.
    • Для HANA для вертикального увеличения масштаба с репликацией системы HANA (HSR) и Pacemaker можно использовать общий диск Azure для устройств SBD в кластерах с максимум четырьмя узлами на сайт репликации из-за текущего ограничения maxShares.
    • Мы не рекомендуем присоединять устройство SBD на основе общего диска Azure между кластерами Pacemaker.
    • Если вы используете несколько устройств SBD на основе общего диска Azure, проверьте ограничение на максимальное число дисков данных, которые можно подключить к виртуальной машине.
    • Дополнительные сведения об ограничениях для общих дисков Azure см. в разделе "Ограничения" документации по общим дискам Azure.

Использование сетевого агента Azure

Вы можете настроить ограничение с помощью агента ограничения Azure. Агент ограждения Azure требует управляемых удостоверений для виртуальных машин кластера или субъекта-службы, который управляет перезапуском неудачных узлов через API Azure. При этом для агента ограничения сети Azure не требуется развертывание дополнительных виртуальных машин.

SBD с сервером цели iSCSI

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

Настройка сервера цели iSCSI

Сначала необходимо создать целевые виртуальные машины iSCSI. Серверы цели iSCSI могут совместно использовать несколько кластеров Pacemaker.

  1. Разверните новую виртуальную машину под управлением SLES 12 с пакетом обновления 3 (SP3) или более поздней версии и подключите ее по протоколу SSH. Размер таких виртуальных машин не обязательно должен быть большим. Будет достаточно выбрать размер Standard_E2s_v3 или Standard_D2s_v3. Убедитесь в том, что для диска ОС используется хранилище класса "Премиум".

  2. Выполните следующие команды на всех виртуальных машинах цели iSCSI.

    a. Обновите SLES.

    sudo zypper update

    Примечание.

    После обновления ОС может потребоваться ее перезагрузка.

    b. Удалите пакеты.

    Чтобы избежать проблем с targetcli и SLES 12 с пакетом обновления 3 (SP3), удалите указанные ниже пакеты. Можно игнорировать сообщения об ошибках со сведениями о том, что пакет не удается обнаружить.

    sudo zypper remove lio-utils python-rtslib python-configshell targetcli

    c. Установите пакеты цели iSCSI.

    sudo zypper install targetcli-fb dbus-1-python

    d. Включите службу цели iSCSI.

    sudo systemctl enable targetcli
sudo systemctl start targetcli

Создание устройства iSCSI на сервере цели iSCSI

Чтобы создать диски iSCSI для кластеров, используемых вашими системами SAP, выполните на всех виртуальных машинах цели iSCSI следующие команды. В примере создаются устройства SBD для нескольких кластеров. В нем показано, как использовать один сервер цели iSCSI для нескольких кластеров. Устройства SBD размещаются на диске операционной системы. Убедитесь, что на диске достаточно места.

  • nfs: указывает на кластер NFS.
  • ascsnw1: указывает на кластер ASCS NW1.
  • dbnw1: указывает на кластер базы данных NW1.
  • nfs-0 и nfs-1: имена узлов кластеров NFS.
  • nw1-xscs-0 и nw1-xscs-1: имена узлов кластеров ASCS NW1.
  • nw1-db-0 и nw1-db-1: имена узлов кластеров базы данных.

В следующих инструкциях замените имена узлов кластера и идентификатор безопасности системы SAP.

  1. Создайте корневую папку для всех устройств SBD.

    sudo mkdir /sbd

  2. Создайте устройство SBD для сервера NFS.

    sudo targetcli backstores/fileio create sbdnfs /sbd/sbdnfs 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.nfs.local:nfs
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/luns/ create /backstores/fileio/sbdnfs
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/acls/ create iqn.2006-04.nfs-0.local:nfs-0
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/acls/ create iqn.2006-04.nfs-1.local:nfs-1

  3. Создайте устройство SBD для сервера ASCS системы SAP NW1.

    sudo targetcli backstores/fileio create sbdascsnw1 /sbd/sbdascsnw1 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.ascsnw1.local:ascsnw1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/luns/ create /backstores/fileio/sbdascsnw1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-0.local:nw1-xscs-0
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-1.local:nw1-xscs-1

  4. Создайте устройство SBD для кластера базы данных системы SAP NW1.

    sudo targetcli backstores/fileio create sbddbnw1 /sbd/sbddbnw1 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.dbnw1.local:dbnw1
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/luns/ create /backstores/fileio/sbddbnw1
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/acls/ create iqn.2006-04.nw1-db-0.local:nw1-db-0
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/acls/ create iqn.2006-04.nw1-db-1.local:nw1-db-1

  5. Сохраните изменения для targetcli.

    sudo targetcli saveconfig

  6. Проверьте правильность настройки.

    sudo targetcli ls

o- / .......................................................................................................... [...]
o- backstores ............................................................................................... [...]
| o- block ................................................................................... [Storage Objects: 0]
| o- fileio .................................................................................. [Storage Objects: 3]
| | o- sbdascsnw1 ................................................ [/sbd/sbdascsnw1 (50.0MiB) write-thru activated]
| | | o- alua .................................................................................... [ALUA Groups: 1]
| | |   o- default_tg_pt_gp ........................................................ [ALUA state: Active/optimized]
| | o- sbddbnw1 .................................................... [/sbd/sbddbnw1 (50.0MiB) write-thru activated]
| | | o- alua .................................................................................... [ALUA Groups: 1]
| | |   o- default_tg_pt_gp ........................................................ [ALUA state: Active/optimized]
| | o- sbdnfs ........................................................ [/sbd/sbdnfs (50.0MiB) write-thru activated]
| |   o- alua .................................................................................... [ALUA Groups: 1]
| |     o- default_tg_pt_gp ........................................................ [ALUA state: Active/optimized]
| o- pscsi ................................................................................... [Storage Objects: 0]
| o- ramdisk ................................................................................. [Storage Objects: 0]
o- iscsi ............................................................................................. [Targets: 3]
| o- iqn.2006-04.ascsnw1.local:ascsnw1 .................................................................. [TPGs: 1]
| | o- tpg1 ................................................................................ [no-gen-acls, no-auth]
| |   o- acls ........................................................................................... [ACLs: 2]
| |   | o- iqn.2006-04.nw1-xscs-0.local:nw1-xscs-0 ............................................... [Mapped LUNs: 1]
| |   | | o- mapped_lun0 ............................................................ [lun0 fileio/sbdascsnw1 (rw)]
| |   | o- iqn.2006-04.nw1-xscs-1.local:nw1-xscs-1 ............................................... [Mapped LUNs: 1]
| |   |   o- mapped_lun0 ............................................................ [lun0 fileio/sbdascsnw1 (rw)]
| |   o- luns ........................................................................................... [LUNs: 1]
| |   | o- lun0 .......................................... [fileio/sbdascsnw1 (/sbd/sbdascsnw1) (default_tg_pt_gp)]
| |   o- portals ..................................................................................... [Portals: 1]
| |     o- 0.0.0.0:3260 ...................................................................................... [OK]
| o- iqn.2006-04.dbnw1.local:dbnw1 ...................................................................... [TPGs: 1]
| | o- tpg1 ................................................................................ [no-gen-acls, no-auth]
| |   o- acls ........................................................................................... [ACLs: 2]
| |   | o- iqn.2006-04.nw1-db-0.local:nw1-db-0 ................................................... [Mapped LUNs: 1]
| |   | | o- mapped_lun0 .............................................................. [lun0 fileio/sbddbnw1 (rw)]
| |   | o- iqn.2006-04.nw1-db-1.local:nw1-db-1 ................................................... [Mapped LUNs: 1]
| |   |   o- mapped_lun0 .............................................................. [lun0 fileio/sbddbnw1 (rw)]
| |   o- luns ........................................................................................... [LUNs: 1]
| |   | o- lun0 .............................................. [fileio/sbddbnw1 (/sbd/sbddbnw1) (default_tg_pt_gp)]
| |   o- portals ..................................................................................... [Portals: 1]
| |     o- 0.0.0.0:3260 ...................................................................................... [OK]
| o- iqn.2006-04.nfs.local:nfs .......................................................................... [TPGs: 1]
|   o- tpg1 ................................................................................ [no-gen-acls, no-auth]
|     o- acls ........................................................................................... [ACLs: 2]
|     | o- iqn.2006-04.nfs-0.local:nfs-0 ......................................................... [Mapped LUNs: 1]
|     | | o- mapped_lun0 ................................................................ [lun0 fileio/sbdnfs (rw)]
|     | o- iqn.2006-04.nfs-1.local:nfs-1 ......................................................... [Mapped LUNs: 1]
|     |   o- mapped_lun0 ................................................................ [lun0 fileio/sbdnfs (rw)]
|     o- luns ........................................................................................... [LUNs: 1]
|     | o- lun0 .................................................. [fileio/sbdnfs (/sbd/sbdnfs) (default_tg_pt_gp)]
|     o- portals ..................................................................................... [Portals: 1]
|       o- 0.0.0.0:3260 ...................................................................................... [OK]
o- loopback .......................................................................................... [Targets: 0]
o- vhost ............................................................................................. [Targets: 0]
o- xen-pvscsi ........................................................................................ [Targets: 0]

Настройка устройства SBD на основе сервера цели iSCSI

Подключитесь к устройству iSCSI, созданному на предыдущем шаге, из кластера. Выполните следующие команды для узлов нового кластера, которые нужно создать.

Примечание.

  • [A]: применяется ко всем узлам.
  • [1]: применяется только к узлу 1.
  • [2]: применяется только к узлу 2.

  1. [A] Установите пакет iSCSI.

    sudo zypper install open-iscsi

  2. [A] Подключитесь к устройствам iSCSI. Сначала включите службы iSCSI и SBD.

    sudo systemctl enable iscsid
sudo systemctl enable iscsi
sudo systemctl enable sbd

  3. [1] Измените имя инициатора на первом узле.

    sudo vi /etc/iscsi/initiatorname.iscsi

  4. [1] Измените содержимое файла в соответствии со списками управления доступом (ACL), использованными при создании устройства iSCSI на сервере цели iSCSI (например, на NFS-сервере).

    InitiatorName=iqn.2006-04.nfs-0.local:nfs-0

  5. [2] Измените имя инициатора на втором узле.

    sudo vi /etc/iscsi/initiatorname.iscsi

  6. [2] Измените содержимое файла в соответствии со списками управления доступом, использованными при создании устройства iSCSI на сервере цели iSCSI.

    InitiatorName=iqn.2006-04.nfs-1.local:nfs-1

  7. [A] Перезапустите службу iSCSI для применения изменений.

    sudo systemctl restart iscsid
sudo systemctl restart iscsi

  8. [A] Подключитесь к устройствам iSCSI. В следующем примере 10.0.0.17 является IP-адресом сервера цели iSCSI, а 3260 — это порт по умолчанию. iqn.2006-04.nfs.local:nfs является одним из имен цели, которые возвращаются при выполнении первой приведенной ниже команды, iscsiadm -m discovery.

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

  9. [A] Если вы хотите использовать несколько устройств SBD, подключитесь также ко второму серверу цели iSCSI.

    sudo iscsiadm -m discovery --type=st --portal=10.0.0.18:3260   
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.18:3260
sudo iscsiadm -m node -p 10.0.0.18:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

  10. [A] Если вы хотите использовать несколько устройств SBD, подключитесь также к третьему серверу цели iSCSI.

    sudo iscsiadm -m discovery --type=st --portal=10.0.0.19:3260   
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.19:3260
sudo iscsiadm -m node -p 10.0.0.19:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

  11. [A] Убедитесь, что устройства iSCSI доступны, и запишите имя устройства (в следующем примере это /dev/sde).

    lsscsi

# [2:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
# [3:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
# [5:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc
# [5:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdd
# [6:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdd
# [7:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sde
# [8:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdf

  12. [A] Получите идентификаторы устройств iSCSI.

    ls -l /dev/disk/by-id/scsi-* | grep sdd

# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-1LIO-ORG_sbdnfs:afb0ba8d-3a3c-413b-8cc2-cca03e63ef42 -> ../../sdd
# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03 -> ../../sdd
# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-SLIO-ORG_sbdnfs_afb0ba8d-3a3c-413b-8cc2-cca03e63ef42 -> ../../sdd

ls -l /dev/disk/by-id/scsi-* | grep sde

# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-1LIO-ORG_cl1:3fe4da37-1a5a-4bb6-9a41-9a4df57770e4 -> ../../sde
# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df -> ../../sde
# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-SLIO-ORG_cl1_3fe4da37-1a5a-4bb6-9a41-9a4df57770e4 -> ../../sde

ls -l /dev/disk/by-id/scsi-* | grep sdf

# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-1LIO-ORG_sbdnfs:f88f30e7-c968-4678-bc87-fe7bfcbdb625 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf -> ../../sdf
# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-SLIO-ORG_sbdnfs_f88f30e7-c968-4678-bc87-fe7bfcbdb625 -> ../../sdf

    Команда выдает три идентификатора для каждого устройства SBD. Мы рекомендуем использовать идентификатор, начинающийся со scsi-3. В приведенном примере это:

    • /dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03
    • /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df
    • /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf

  13. [1] Создайте устройство SBD.

    a. Используйте идентификаторы устройств iSCSI, чтобы создать устройства SBD на первом узле кластера.

    sudo sbd -d /dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03 -1 60 -4 120 create

    b. Если вы хотите использовать несколько устройств, создайте второе и третье устройства SBD.

    sudo sbd -d /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df -1 60 -4 120 create
sudo sbd -d /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf -1 60 -4 120 create

  14. [A] Адаптируйте конфигурацию SBD.

    a. Откройте файл конфигурации SBD.

    sudo vi /etc/sysconfig/sbd

    b. Измените значение свойства устройства SBD, включите интеграцию Pacemaker и измените режим запуска SBD.

    [...]
SBD_DEVICE="/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]

    Примечание.

    Если значение свойства SBD_DELAY_START имеет значение "нет", измените значение на "да". Необходимо также проверка файл службы SBD, чтобы убедиться, что значение TimeoutStartSec больше значения SBD_DELAY_START. Дополнительные сведения см. в разделе "Настройка SBD-файла"

  15. [A] Создайте файл конфигурации softdog.

    echo softdog | sudo tee /etc/modules-load.d/softdog.conf

  16. [A] Загрузите модуль.

    sudo modprobe -v softdog

SBD с общим диском Azure

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

Создание и подключение общего диска Azure с помощью PowerShell

  1. Измените значения для группы ресурсов, региона Azure, виртуальных машин, логических номеров устройств (LUN) и т. д.

    $ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"

  2. Определите размер диска на основе доступного размера диска для SSD (цен. категория "Премиум"). В этом примере упоминается размер диска P1 4G.

    $DiskSizeInGB = 4
$DiskName = "SBD-disk1"

  3. Определите максимальное число узлов кластера для подключения общего диска к устройству SBD, используя параметр -MaxSharesCount.

    $ShareNodes = 2

  4. Для устройства SBD, использующего LRS для общего диска Azure класса "Премиум", используйте следующее название SKU хранилища:

    $SkuName = "Premium_LRS"

  5. Для устройства SBD, использующего ZRS для общего диска Azure класса "Премиум", используйте следующее название SKU хранилища:

    $SkuName = "Premium_ZRS"

  6. Настройте общий диск Azure.

    $diskConfig = New-AzDiskConfig -Location $Location -SkuName $SkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $diskConfig

  7. Подключите диск к виртуальным машинам кластера.

    $VM1 = "prod-cl1-0"
$VM2 = "prod-cl1-1"

    a. Добавьте общий диск Azure в узел кластера 1.

    $vm = Get-AzVM -ResourceGroupName $ResourceGroup -Name $VM1
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroup -Verbose

    b. Добавьте общий диск Azure в узел кластера 2.

    $vm = Get-AzVM -ResourceGroupName $ResourceGroup -Name $VM2
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroup -Verbose

Если вам нужно развернуть ресурсы с помощью Azure CLI или портала Azure, ознакомьтесь со сведениями о том, как это сделать, в статье Развертывание диска ZRS.

Настройка устройства SBD на основе общего диска Azure

  1. [A] Включите службы SBD.

    sudo systemctl enable sbd

  2. [A] Убедитесь, что подключенный диск доступен.

    # lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0      2:0    1    4K  0 disk
sda      8:0    0   30G  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 28.5G  0 part /
sdb      8:16   0  256G  0 disk
├─sdb1   8:17   0  256G  0 part /mnt
sdc      8:32   0    4G  0 disk
sr0     11:0    1 1024M  0 rom

# lsscsi
[1:0:0:0]    cd/dvd  Msft     Virtual CD/ROM   1.0   /dev/sr0
[2:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[3:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[5:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc

  3. [A] Получите идентификаторы подключенных дисков.

    # ls -l /dev/disk/by-id/scsi-* | grep sdc
lrwxrwxrwx 1 root root  9 Nov  8 16:55 /dev/disk/by-id/scsi-14d534654202020204208a67da80744439b513b2a9728af19 -> ../../sdc
lrwxrwxrwx 1 root root  9 Nov  8 16:55 /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 -> ../../sdc

    В командах перечислены идентификаторы для устройства SBD. Мы рекомендуем использовать идентификатор, начинающийся со scsi-3. В предыдущем примере идентификатором является /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19.

  4. [1] Создайте устройство SBD.

    Используйте идентификаторы устройств с шага 2, чтобы создать устройства SBD на первом узле кластера.

    # sudo sbd -d /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 -1 60 -4 120 create

  5. [A] Адаптируйте конфигурацию SBD.

    a. Откройте файл конфигурации SBD.

    sudo vi /etc/sysconfig/sbd

    b. Измените значение свойства устройства SBD, включите интеграцию Pacemaker и измените режим запуска устройства SBD.

    [...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]

    Примечание.

    Если значение свойства SBD_DELAY_START имеет значение "нет", измените значение на "да". Необходимо также проверка файл службы SBD, чтобы убедиться, что значение TimeoutStartSec больше значения SBD_DELAY_START. Дополнительные сведения см. в разделе "Настройка SBD-файла"

  6. Создайте файл конфигурации softdog.

    echo softdog | sudo tee /etc/modules-load.d/softdog.conf

  7. Загрузите модуль.

    sudo modprobe -v softdog

Использование сетевого агента Azure

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

Создание устройства ограничения на основе агента ограничения Azure

Этот раздел применим, только если вы используете устройство ограничения, основанное на агенте ограничения Azure. Устройство ограничения использует управляемое удостоверение или субъект-службу для авторизации в Microsoft Azure.

Чтобы создать управляемое удостоверение (MSI), создайте назначаемое системой управляемое удостоверение для каждой виртуальной машины в кластере. Если управляемое удостоверение, назначаемое системой, уже существует, оно будет использоваться. Назначенные пользователем управляемые удостоверения не должны использоваться в Pacemaker в настоящее время. Агент забора Azure, основанный на управляемом удостоверении, поддерживается для SLES 12 с пакетом обновления 5 (SP5) и SLES 15 с пакетом обновления 1 (SP1) и более поздних версий.

[1] Создайте пользовательскую роль для агента ограждения.

По умолчанию ни управляемое удостоверение, ни субъект-служба не имеют разрешений на доступ к ресурсам Azure. Поэтому необходимо предоставить управляемому удостоверению или субъекту-службе разрешения на запуск и остановку (освобождение) всех виртуальных машин в кластере. Если вы еще не создали настраиваемую роль, ее можно создать с помощью PowerShell или Azure CLI.

Используйте следующее содержимое для входного файла. Вам необходимо адаптировать содержание в соответствии с вашими подписками. Для этого замените xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx и yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy реальными идентификаторами подписок. Если у вас есть только одна подписка, удалите вторую запись в AssignableScopes.

{
      "Name": "Linux fence agent Role",
      "description": "Allows to power-off and start virtual machines",
      "assignableScopes": [
              "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
              "/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
      ],
      "actions": [
              "Microsoft.Compute/*/read",
              "Microsoft.Compute/virtualMachines/powerOff/action",
              "Microsoft.Compute/virtualMachines/start/action"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
}

[А] Назначение настраиваемой роли

Используйте управляемое удостоверение или субъект-службу.

Каждому управляемому удостоверению виртуальной машины в кластере назначьте пользовательскую роль Linux Fence Agent Role, созданную в последней главе. Каждое назначаемое системой управляемое удостоверение виртуальной машины требует назначения роли для каждого ресурса виртуальной машины. Подробные инструкции см. в статье Назначение доступа на основе управляемого удостоверения к ресурсу с помощью портала Azure. Убедитесь, что назначение ролей каждого управляемого удостоверения виртуальной машины включает все виртуальные машины кластера.

Внимание

Помните, что назначение и удаление авторизации с управляемыми удостоверениями может задерживаться, пока не закончится срок действия маркера.

Установка кластера

Примечание.

  • [A]: применяется ко всем узлам.
  • [1]: применяется только к узлу 1.
  • [2]: применяется только к узлу 2.

  1. [A] Обновите SLES.

    sudo zypper update

    Примечание.

    В SLES 15 с пакетом обновления 4 (SP4) проверка версию crmsh и pacemaker и убедитесь, что выполнены требования к версии miniumum:

    • crmsh-4.4.0+20221028.3e41444-150400.3.9.1 или более поздней версии
    • pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 или более поздней версии

  2. [A] Установите компонент, необходимый для ресурсов кластера.

    sudo zypper in socat

  3. [A] Установите компонент azure-lb, необходимый для ресурсов кластера.

    sudo zypper in resource-agents

    Примечание.

    Проверьте версию пакета resource-agents и убедитесь, что выполняются минимальные требования к версии.

    • SLES 12 с пакетом обновления 4 или 5 (SP4/SP5) — resource-agents-4.3.018.a7fb5035-3.30.1 или более поздняя.
    • SLES 15/15 с пакетом обновления 1 (SP1) — resource-agents-4.3.0184.6ee15eb2-4.13.1 или более поздняя.

  4. [A] Настройте операционную систему.

    a. Pacemaker время от времени создает много процессов, что может привести к превышению допустимого количества процессов. В таком случае пульс между узлами кластера может завершиться ошибкой и привести к отработке отказа ресурсов. Мы рекомендуем увеличить максимальное число разрешенных процессов, установив следующий параметр.

    # Edit the configuration file
sudo vi /etc/systemd/system.conf

# Change the DefaultTasksMax
#DefaultTasksMax=512
DefaultTasksMax=4096

# Activate this setting
sudo systemctl daemon-reload

# Test to ensure that the change was successful
sudo systemctl --no-pager show | grep DefaultTasksMax

    b. Уменьшите размер "грязного" кэша. Дополнительные сведения см. в статье Low write performance on SLES 11/12 servers with large RAM (Низкая производительность записи на серверах SLES 11/12 с большим объем ОЗУ).

    sudo vi /etc/sysctl.conf
# Change/set the following settings
vm.dirty_bytes = 629145600
vm.dirty_background_bytes = 314572800

    c. Убедитесь, что vm.swappiness имеет значение 10, чтобы уменьшить использование буферов и использовать память.

    sudo vi /etc/sysctl.conf
# Change/set the following setting
vm.swappiness = 10

  5. [A] Проверьте версию пакета cloud-netconfig-azure .

    Проверьте установленную версию пакета cloud-netconfig-azure, выполнив zypper info cloud-netconfig-azure. Если версия более ранняя чем 1.3, мы рекомендуем обновить пакет cloud-netconfig-azure до последней доступной версии.

    Совет

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

    Только если версия cloud-netconfig-azure ниже 1.3, измените файл конфигурации сетевого интерфейса, как показано в следующем коде, чтобы предотвратить удаление виртуального IP-адреса (Pacemaker должен контролировать назначение). См. сведения здесь: SUSE KB 7023633.

    # Edit the configuration file
sudo vi /etc/sysconfig/network/ifcfg-eth0 

# Change CLOUD_NETCONFIG_MANAGE
# CLOUD_NETCONFIG_MANAGE="yes"
CLOUD_NETCONFIG_MANAGE="no"

  6. [1] Включите доступ по протоколу SSH.

    sudo ssh-keygen

# Enter file in which to save the key (/root/.ssh/id_rsa), and then select Enter
# Enter passphrase (empty for no passphrase), and then select Enter
# Enter same passphrase again, and then select Enter

# copy the public key
sudo cat /root/.ssh/id_rsa.pub

  7. [2] Включите доступ по протоколу SSH.

    sudo ssh-keygen

# Enter file in which to save the key (/root/.ssh/id_rsa), and then select Enter
# Enter passphrase (empty for no passphrase), and then select Enter
# Enter same passphrase again, and then select Enter

# Insert the public key you copied in the last step into the authorized keys file on the second server
sudo vi /root/.ssh/authorized_keys   

# copy the public key
sudo cat /root/.ssh/id_rsa.pub

  8. [1] Включите доступ по протоколу SSH.

    # insert the public key you copied in the last step into the authorized keys file on the first server
sudo vi /root/.ssh/authorized_keys

  9. [A] Установите пакет fence-agents, если вы используете устройство ограничения на основе агента ограничения Azure.

    sudo zypper install fence-agents

    Внимание

    Чтобы воспользоваться преимуществами более быстрой отработки отказа с использованием сетевого агента Azure, когда узел кластера изолирован, вашей установленной версией пакета fence-agents должна быть версия 4.4.0 или более поздняя. Если вы используете более раннюю версию, рекомендуется обновить пакет.

    Внимание

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

    • SLES 12 SP5: забор-агенты 4.9.0+git.1624456340.8d746be9-3.35.2 или более поздней версии
    • SLES 15 с пакетом обновления 1 (SP1) и выше: забор-агенты 4.5.2+git.1592573838.1eee0863 или более поздней версии.

    Более ранние версии не будут правильно работать с конфигурацией управляемого удостоверения.

  10. [A] Установите пакет Azure Python SDK и модуль Python Azure Identity.

    Установите пакет SDK для Python на SLES 12 с пакетом обновления 4 (SP4) или SLES 12 с пакетом обновления 5 (SP5).

    # You might need to activate the public cloud extension first
SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper install python-azure-mgmt-compute
sudo zypper install python-azure-identity

    Установите пакет SDK для Python на SLES 15 или более поздней версии:

    # You might need to activate the public cloud extension first. In this example, the SUSEConnect command is for SLES 15 SP1
SUSEConnect -p sle-module-public-cloud/15.1/x86_64
sudo zypper install python3-azure-mgmt-compute
sudo zypper install python3-azure-identity

    Внимание

    Прежде чем можно будет установить пакет SDK для Azure Python, в зависимости от версии и типа образа может потребоваться активировать расширение общедоступного облака для выпуска ОС. Проверьте версию расширения, выполнив SUSEConnect ---list-extensions. Чтобы ускорить отработку отказа с помощью сетевого агента Azure, выполните следующее:

    • Для SLES 12 с пакетом обновления 4 (SP4) или SLES 12 с пакетом обновления 5 (SP5) установите 4.6.2 или более позднюю версию пакета python-azure-mgmt-compute.
    • Если версией пакета python-azure-mgmt-compute или python3-azure-mgmt-compute является 17.0.0-6.7.1, следуйте инструкциям в базе знаний по SUSE, чтобы обновить версию fence-agents и установить клиентскую библиотеку удостоверений Azure для модуля Python, если она отсутствует.

  11. [A] Настройте разрешение имени узлов.

    Вы можете использовать DNS-сервер или внести изменения в файл /etc/hosts на всех узлах. В этом примере показано, как использовать файл /etc/hosts.

    Замените IP-адрес и имя узла в следующих командах.

    Внимание

    Если имена узлов используются в конфигурации кластера, важно иметь надежное разрешение имен узлов. Соединение с кластером завершится ошибкой, если имена недоступны, а это может привести к задержкам при отработке отказа кластера.

    Преимущество использования /etc/hosts состоит в том, что кластер становится независимым от службы DNS, которая также может являться единой точкой отказа.

    sudo vi /etc/hosts

    Вставьте следующие строки в файл /etc/hosts. Измените IP-адрес и имя узла в соответствии с параметрами среды.

    # IP address of the first cluster node
10.0.0.6 prod-cl1-0
# IP address of the second cluster node
10.0.0.7 prod-cl1-1

  12. [1] Установите кластер.

    • Если вы используете устройства SBD для изоляции (как для сервера цели iSCSI, так и для общего диска Azure):

      sudo crm cluster init
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n
# Address for ring0 [10.0.0.6] Select Enter
# Port for ring0 [5405] Select Enter
# SBD is already configured to use /dev/disk/by-id/scsi-36001405639245768818458b930abdf69;/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf - overwrite (y/n)? n
# Do you wish to configure an administration IP (y/n)? n

    • Если устройства SBD не используются для изоляции:

      sudo crm cluster init
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n
# Address for ring0 [10.0.0.6] Select Enter
# Port for ring0 [5405] Select Enter
# Do you wish to use SBD (y/n)? n
# WARNING: Not configuring SBD - STONITH will be disabled.
# Do you wish to configure an administration IP (y/n)? n

  13. [2] Добавьте узел к кластеру.

    sudo crm cluster join
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# IP address or hostname of existing node (for example, 192.168.1.1) []10.0.0.6
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n

  14. [A] Измените пароль hacluster, введя тот же пароль.

    sudo passwd hacluster

  15. [A] Настройте параметры corosync.

    sudo vi /etc/corosync/corosync.conf

    a. Проверьте следующий раздел в файле и измените их, если значения отсутствуют или отличаются. Не забудьте заменить токен на 30000, чтобы разрешить обслуживание с сохранением памяти. Дополнительные сведения см. в статье "Обслуживание виртуальных машин в Azure" для Linux или Windows.

    [...]
  token:          30000
  token_retransmits_before_loss_const: 10
  join:           60
  consensus:      36000
  max_messages:   20

  interface { 
     [...] 
  }
  transport:      udpu
} 
nodelist {
  node {
   ring0_addr:10.0.0.6
  }
  node {
   ring0_addr:10.0.0.7
  } 
}
logging {
  [...]
}
quorum {
     # Enable and configure quorum subsystem (default: off)
     # See also corosync.conf.5 and votequorum.5
     provider: corosync_votequorum
     expected_votes: 2
     two_node: 1
}

    b. Перезапустите службу corosync.

    sudo service corosync restart

Создание устройства ограничения в кластере Pacemaker

Совет

  • Чтобы избежать рас заборов в кластере pacemaker с двумя узлами, можно настроить дополнительное свойство кластера priority-fencing-delay. Это свойство вводит дополнительную задержку в ограждении узла, имеющего более высокий общий приоритет ресурсов при возникновении сценария разделения мозга. Дополнительные сведения см . в руководстве по администрированию расширений расширения высокой доступности SUSE Linux Enterprise Server.
  • Инструкции по настройке свойства кластера priority-fencing-delay можно найти в соответствующем документе SAP ASCS/ERS (применимо только в ENSA2) и документе с высоким уровнем доступности SAP HANA.

  1. [1] Если вы используете устройство SBD (целевой сервер iSCSI или общий диск Azure) в качестве устройства ограждения, выполните следующие команды. Активируйте использование устройства ограничения и задайте задержку ограничения.

    sudo crm configure property stonith-timeout=144
sudo crm configure property stonith-enabled=true

# List the resources to find the name of the SBD device
sudo crm resource list
sudo crm resource stop stonith-sbd
sudo crm configure delete stonith-sbd
sudo crm configure primitive stonith-sbd stonith:external/sbd \
   params pcmk_delay_max="15" \
   op monitor interval="600" timeout="15"

  2. [1] Если вы используете агент ограничения Azure для ограничения, выполните следующие команды. После назначения ролей обоим узлам кластера вы можете перейти к настройке устройств ограничения в кластере.

    sudo crm configure property stonith-enabled=true
sudo crm configure property concurrent-fencing=true

    Примечание.

    Параметр pcmk_host_map требуется в команде, только если имена узлов и имена виртуальных машин Azure не совпадают. Задайте сопоставление в формате имя_узла:имя_виртуальной_машины.

# Adjust the command with your subscription ID and resource group of the VM

sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm \
params msi=true subscriptionId="subscription ID" resourceGroup="resource group" \
pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_delay_max=15 pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
op monitor interval=3600 timeout=120

sudo crm configure property stonith-timeout=900

Если вы используете устройство ограждения на основе конфигурации субъекта-службы, прочитайте статью "Изменение имени участника-службы на MSI для кластеров Pacemaker" с помощью ограждения Azure и узнайте, как преобразовать ее в конфигурацию управляемого удостоверения.

Внимание

Операции мониторинга и ограждения десериализованы. В результате, если во время выполнения более длительной операции мониторинга возникает событие изоляции, задержка отработки отказа кластера отсутствует из-за уже запущенной операции мониторинга.

Совет

Для сетевого агента Azure требуется исходящее подключение к общедоступным конечным точкам. См. сведения об этом требовании и о возможных решениях в статье Подключение к общедоступной конечной точке для виртуальных машин с помощью Azure Load Balancer (цен. категория "Стандартный") в сценариях обеспечения высокого уровня доступности SAP.

Конфигурация Pacemaker для запланированных событий Azure

Azure предлагает запланированные события. Запланированные события предоставляются через службу метаданных и позволяют приложению подготовиться к таким событиям. Агент ресурсов azure-events-az monitors для запланированных событий Azure. Если обнаружены события и агент ресурсов определяет, что доступен другой узел кластера, он задает атрибут работоспособности кластера. Если для узла задан атрибут работоспособности кластера, триггеры ограничения расположения и все ресурсы, имя которого не начинается с "работоспособности", переносятся с узла с запланированным событием. После того как затронутый узел кластера свободен от запуска ресурсов кластера, запланированное событие будет подтверждено и может выполнить его действие, например перезапуск.

Внимание

Ранее в этом документе описано использование azure-events агента ресурсов. Новый агент ресурсов azure-events-az полностью поддерживает среды Azure, развернутые в разных зонах доступности. Рекомендуется использовать новый агент azure-events-az для всех высокодоступных систем SAP с помощью Pacemaker.

  1. [A] Убедитесь, что пакет для агента azure-events установлен и обновлен.

    sudo zypper info resource-agents

    Минимальные требования к версии:

    • SLES 12 с пакетом обновления 5 (SP5): resource-agents-4.3.018.a7fb5035-3.98.1
    • SLES 15 с пакетом обновления 1 (SP1): resource-agents-4.3.0184.6ee15eb2-150100.4.72.1
    • SLES 15 с пакетом обновления 2 (SP2): resource-agents-4.4.0+git57.70549516-150200.3.56.1
    • SLES 15 с пакетом обновления 3 (SP3): resource-agents-4.8.0+git30.d0077df0-150300.8.31.1
    • SLES 15 с пакетом обновления 4 (SP4) и более поздней версии: resource-agents-4.10.0+git40.0f4de473-150400.3.19.1

  2. [1] Настройте ресурсы в Pacemaker.

    #Place the cluster in maintenance mode
sudo crm configure property maintenance-mode=true

  3. [1] Задайте стратегию и ограничение узла работоспособности кластера Pacemaker

    sudo crm configure property node-health-strategy=custom
sudo crm configure location loc_azure_health \
/'!health-.*'/ rule '#health-azure': defined '#uname'

    Внимание

    Не определяйте другие ресурсы в кластере, начиная с "работоспособности", помимо ресурсов, описанных в следующих шагах документации.

  4. [1] Задайте начальное значение атрибутов кластера. Запустите для каждого узла кластера. Для сред горизонтального масштабирования, включая виртуальную машину разработчика большинства.

    sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0
sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0

  5. [1] Настройте ресурсы в Pacemaker. Важно. Ресурсы должны начинаться с "health-azure".

    sudo crm configure primitive health-azure-events ocf:heartbeat:azure-events-az \ 
meta allow-unhealthy-nodes=true failure-timeout=120s \ 
op start start-delay=90s \ 
op monitor interval=10s

sudo crm configure clone health-azure-events-cln health-azure-events

    Примечание.

    При настройке ресурса health-azure-events можно игнорировать следующее предупреждение.

    ПРЕДУПРЕЖДЕНИЕ: health-azure-events: неизвестный атрибут allow-неработоспособные узлы.

  6. Выход кластера Pacemaker из режима обслуживания

    sudo crm configure property maintenance-mode=false

  7. Снимите все ошибки во время включения и убедитесь, что ресурсы health-azure-events успешно запущены на всех узлах кластера.

    sudo crm resource cleanup

    Выполнение первого запроса для запланированных событий может занять до 2 минут. Тестирование Pacemaker с запланированными событиями может использовать действия перезагрузки или повторного развертывания для виртуальных машин кластера. Дополнительные сведения см . в документации по запланированным событиям .

    Примечание.

    После настройки ресурсов Pacemaker для агента azure-events при включении и отключении режима обслуживания кластера могут появиться следующие сообщения с предупреждениями:

    ПРЕДУПРЕЖДЕНИЕ: cib-bootstrap-options: неизвестный атрибут "hostName_hostname"
    WARNING: cib-bootstrap-options: unknown attribute 'azure-events_globalPullState'
    WARNING: cib-bootstrap-options: unknown attribute 'hostName_ hostname'
    Эти предупреждения можно игнорировать.

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