Udostępnij za pośrednictwem

Konfigurowanie programu Pacemaker w systemie Red Hat Enterprise Linux na platformie Azure

  • Artykuł

W tym artykule opisano sposób konfigurowania podstawowego klastra Pacemaker na serwerze Red Hat Enterprise Server (RHEL). Instrukcje obejmują RHEL 7, RHEL 8 i RHEL 9.

Wymagania wstępne

Najpierw zapoznaj się z następującymi uwagami i artykułami SAP:

Omówienie

Ważne

Klastry Pacemaker obejmujące wiele sieci wirtualnych/podsieci nie są objęte standardowymi zasadami pomocy technicznej.

Na platformie Azure są dostępne dwie opcje konfigurowania ogrodzenia w klastrze pacemaker dla systemu RHEL: agent ogrodzenia platformy Azure, który uruchamia ponownie węzeł, który kończy się niepowodzeniem za pośrednictwem interfejsów API platformy Azure lub można użyć urządzenia SBD.

Ważne

Na platformie Azure klaster wysokiej dostępności RHEL z ogrodzeniem opartym na magazynie (fence_sbd) używa emulowanego oprogramowania watchdog. Podczas wybierania usługi SBD jako mechanizmu ogrodzenia ważne jest zapoznanie się ze znanymi ograniczeniami i zasadami pomocy technicznej dla klastrów wysokiej dostępności RHEL — sbd i fence_sbd podczas wybierania usługi SBD.

Korzystanie z urządzenia SBD

Uwaga

Mechanizm ogrodzenia z funkcją SBD jest obsługiwany w systemach RHEL 8.8 i nowszych oraz RHEL 9.0 i nowszych.

Urządzenie SBD można skonfigurować przy użyciu jednej z dwóch opcji:

  • Usługa SBD z serwerem docelowym iSCSI

    Urządzenie SBD wymaga co najmniej jednej dodatkowej maszyny wirtualnej, która działa jako serwer docelowy Internet Small Compute System Interface (iSCSI) i udostępnia urządzenie SBD. Te serwery obiektów docelowych iSCSI mogą być jednak współużytkowane z innymi klastrami pacemaker. Zaletą korzystania z urządzenia SBD jest to, że jeśli korzystasz już z urządzeń SBD lokalnie, nie wymagają one żadnych zmian sposobu działania klastra pacemaker.

    Można użyć maksymalnie trzech urządzeń SBD dla klastra pacemaker, aby umożliwić urządzeniu SBD stanie się niedostępne (na przykład podczas stosowania poprawek systemu operacyjnego serwera docelowego iSCSI). Jeśli chcesz użyć więcej niż jednego urządzenia SBD na moduł rozrusznika, pamiętaj, aby wdrożyć wiele serwerów docelowych iSCSI i połączyć jeden SBD z każdego serwera docelowego iSCSI. Zalecamy użycie jednego lub trzech urządzeń SBD. Program Pacemaker nie może automatycznie ogrodzać węzła klastra, jeśli skonfigurowano tylko dwa urządzenia SBD i jeden z nich jest niedostępny. Jeśli chcesz mieć możliwość ogrodzenia, gdy jeden serwer docelowy iSCSI nie działa, musisz użyć trzech urządzeń SBD i w związku z tym trzech serwerów docelowych iSCSI. Jest to najbardziej odporna konfiguracja podczas korzystania z dysków SSD.

    Diagram rozrusznika z serwerem docelowym iSCSI jako urządzeniem SBD w systemie RHEL

    Ważne

    Podczas planowania wdrażania i konfigurowania węzłów klastra rozrusznika systemu Linux i urządzeń SBD nie zezwalaj na routing między maszynami wirtualnymi i maszynami wirtualnymi hostujących urządzenia SBD do przekazywania wszystkich innych urządzeń, takich jak wirtualne urządzenie sieciowe (WUS).

    Zdarzenia konserwacji i inne problemy z urządzeniem WUS mogą mieć negatywny wpływ na stabilność i niezawodność ogólnej konfiguracji klastra. Aby uzyskać więcej informacji, zobacz Reguły routingu zdefiniowane przez użytkownika.

  • Usługa SBD z dyskiem udostępnionym platformy Azure

    Aby skonfigurować urządzenie SBD, należy dołączyć co najmniej jeden dysk udostępniony platformy Azure do wszystkich maszyn wirtualnych będących częścią klastra pacemaker. Zaletą urządzenia SBD przy użyciu dysku udostępnionego platformy Azure jest to, że nie trzeba wdrażać i konfigurować dodatkowych maszyn wirtualnych.

    Diagram urządzenia SBD dysku udostępnionego platformy Azure dla klastra pacemaker systemu RHEL.

    Poniżej przedstawiono kilka ważnych zagadnień dotyczących urządzeń SBD podczas konfigurowania przy użyciu dysku udostępnionego platformy Azure:

    • Dysk udostępniony platformy Azure z dyskiem SSD w warstwie Premium jest obsługiwany jako urządzenie SBD.
    • Urządzenia SBD korzystające z dysku udostępnionego platformy Azure są obsługiwane w systemie RHEL 8.8 lub nowszym.
    • Urządzenia SBD korzystające z dysku udziału w warstwie Premium platformy Azure są obsługiwane w magazynie lokalnie nadmiarowym (LRS) i magazynie strefowo nadmiarowym (ZRS).
    • W zależności od typu wdrożenia wybierz odpowiedni magazyn nadmiarowy dla dysku udostępnionego platformy Azure jako urządzenie SBD.
    • Urządzenie SBD korzystające z magazynu LRS dla dysku udostępnionego usługi Azure Premium (skuName — Premium_LRS) jest obsługiwane tylko w przypadku wdrożenia regionalnego, takiego jak zestaw dostępności.
    • Urządzenie SBD korzystające z magazynu ZRS dla dysku udostępnionego w warstwie Premium platformy Azure (skuName — Premium_ZRS) jest zalecane w przypadku wdrożenia strefowego, takiego jak strefa dostępności, lub zestaw skalowania z FD=1.
    • Magazyn ZRS dla dysku zarządzanego jest obecnie dostępny w regionach wymienionych w dokumencie dostępności regionalnej.
    • Dysk udostępniony platformy Azure używany na potrzeby urządzeń SBD nie musi być duży. Wartość maxShares określa, ile węzłów klastra może używać dysku udostępnionego. Można na przykład użyć rozmiarów dysków P1 lub P2 dla urządzenia SBD w klastrze z dwoma węzłami, takimi jak SAP ASCS/ERS lub SAP HANA scale-up.
    • W przypadku skalowania w poziomie platformy HANA z replikacją systemu HANA (HSR) i modułem rozrusznika można użyć dysku udostępnionego platformy Azure dla urządzeń SBD w klastrach z maksymalnie pięcioma węzłami na lokację replikacji z powodu bieżącego limitu maxShares.
    • Nie zalecamy dołączania urządzenia SBD dysku udostępnionego platformy Azure w klastrach pacemaker.
    • Jeśli używasz wielu urządzeń SBD dysku udostępnionego platformy Azure, sprawdź limit maksymalnej liczby dysków danych, które można dołączyć do maszyny wirtualnej.
    • Aby uzyskać więcej informacji na temat ograniczeń dotyczących dysków udostępnionych platformy Azure, dokładnie zapoznaj się z sekcją "Ograniczenia" w dokumentacji dysku udostępnionego platformy Azure.

Korzystanie z agenta ogrodzenia platformy Azure

Ogrodzenie można skonfigurować przy użyciu agenta ogrodzenia platformy Azure. Agent ogrodzenia platformy Azure wymaga tożsamości zarządzanych dla maszyn wirtualnych klastra lub jednostki usługi lub tożsamości zarządzanego systemu (MSI), która zarządza ponownym uruchomieniem węzłów, które zakończyły się niepowodzeniem za pośrednictwem interfejsów API platformy Azure. Agent ogrodzenia platformy Azure nie wymaga wdrożenia dodatkowych maszyn wirtualnych.

Usługa SBD z serwerem docelowym iSCSI

Aby użyć urządzenia SBD, które używa serwera docelowego iSCSI do ogrodzenia, postępuj zgodnie z instrukcjami w następnych sekcjach.

Konfigurowanie serwera docelowego iSCSI

Najpierw należy utworzyć maszyny wirtualne obiektów docelowych iSCSI. Serwery docelowe iSCSI można udostępniać z wieloma klastrami pacemaker.

  1. Wdróż maszyny wirtualne działające w obsługiwanej wersji systemu operacyjnego RHEL i nawiąż z nimi połączenie za pośrednictwem protokołu SSH. Maszyny wirtualne nie muszą mieć dużego rozmiaru. Rozmiary maszyn wirtualnych, takie jak Standard_E2s_v3 lub Standard_D2s_v3, są wystarczające. Pamiętaj, aby używać magazynu w warstwie Premium dla dysku systemu operacyjnego.

  2. Nie jest konieczne używanie systemu RHEL dla oprogramowania SAP z wysoką dostępnością i usługami aktualizacji ani obrazu systemu operacyjnego RHEL dla systemu operacyjnego SAP Apps dla serwera docelowego iSCSI. Zamiast tego można użyć standardowego obrazu systemu operacyjnego RHEL. Należy jednak pamiętać, że cykl życia pomocy technicznej różni się między różnymi wersjami produktów systemu operacyjnego.

  3. Uruchom następujące polecenia na wszystkich maszynach wirtualnych docelowych iSCSI.

    1. Zaktualizuj RHEL.

      sudo yum -y update

      Uwaga

      Po uaktualnieniu lub zaktualizowaniu systemu operacyjnego może być konieczne ponowne uruchomienie węzła.

    2. Zainstaluj pakiet docelowy iSCSI.

      sudo yum install targetcli

    3. Uruchom i skonfiguruj element docelowy do uruchomienia w czasie rozruchu.

      sudo systemctl start target
sudo systemctl enable target

    4. Otwieranie portu 3260 w zaporze

      sudo firewall-cmd --add-port=3260/tcp --permanent
sudo firewall-cmd --add-port=3260/tcp

Tworzenie urządzenia iSCSI na serwerze docelowym iSCSI

Aby utworzyć dyski iSCSI dla klastrów systemowych SAP, wykonaj następujące polecenia na każdej docelowej maszynie wirtualnej iSCSI. W przykładzie pokazano tworzenie urządzeń SBD dla kilku klastrów, pokazując użycie jednego serwera docelowego iSCSI dla wielu klastrów. Urządzenie SBD jest skonfigurowane na dysku systemu operacyjnego, więc upewnij się, że jest wystarczająca ilość miejsca.

  • ascsnw1: reprezentuje klaster ASCS/ERS NW1.
  • dbhn1: reprezentuje klaster bazy danych HN1.
  • sap-cl1 i sap-cl2: nazwy hostów węzłów klastra NW1 ASCS/ERS.
  • hn1-db-0 i hn1-db-1: nazwy hostów węzłów klastra bazy danych.

W poniższych instrukcjach zmodyfikuj polecenie przy użyciu określonych nazw hostów i identyfikatorów SID zgodnie z potrzebami.

  1. Utwórz folder główny dla wszystkich urządzeń SBD.

    sudo mkdir /sbd

  2. Utwórz urządzenie SBD dla serwerów ASCS/ERS systemu 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.sap-cl1.local:sap-cl1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl2.local:sap-cl2

  3. Utwórz urządzenie SBD dla klastra bazy danych systemu HN1.

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

  4. Zapisz konfigurację targetcli.

    sudo targetcli saveconfig

  5. Sprawdź, czy wszystko zostało poprawnie skonfigurowane

    sudo targetcli ls

o- / ......................................................................................................................... [...]
  o- backstores .............................................................................................................. [...]
  | o- block .................................................................................................. [Storage Objects: 0]
  | o- fileio ................................................................................................. [Storage Objects: 2]
  | | o- sbdascsnw1 ............................................................... [/sbd/sbdascsnw1 (50.0MiB) write-thru activated]
  | | | o- alua ................................................................................................... [ALUA Groups: 1]
  | | |   o- default_tg_pt_gp ....................................................................... [ALUA state: Active/optimized]
  | | o- sbddbhn1 ................................................................... [/sbd/sbddbhn1 (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: 2]
  | o- iqn.2006-04.dbhn1.local:dbhn1 ..................................................................................... [TPGs: 1]
  | | o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
  | |   o- acls .......................................................................................................... [ACLs: 2]
  | |   | o- iqn.2006-04.hn1-db-0.local:hn1-db-0 .................................................................. [Mapped LUNs: 1]
  | |   | | o- mapped_lun0 ............................................................................... [lun0 fileio/sbdhdb (rw)]
  | |   | o- iqn.2006-04.hn1-db-1.local:hn1-db-1 .................................................................. [Mapped LUNs: 1]
  | |   |   o- mapped_lun0 ............................................................................... [lun0 fileio/sbdhdb (rw)]
  | |   o- luns .......................................................................................................... [LUNs: 1]
  | |   | o- lun0 ............................................................. [fileio/sbddbhn1 (/sbd/sbddbhn1) (default_tg_pt_gp)]
  | |   o- portals .................................................................................................... [Portals: 1]
  | |     o- 0.0.0.0:3260 ..................................................................................................... [OK]
  | o- iqn.2006-04.ascsnw1.local:ascsnw1 ................................................................................. [TPGs: 1]
  |   o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
  |     o- acls .......................................................................................................... [ACLs: 2]
  |     | o- iqn.2006-04.sap-cl1.local:sap-cl1 .................................................................... [Mapped LUNs: 1]
  |     | | o- mapped_lun0 ........................................................................... [lun0 fileio/sbdascsers (rw)]
  |     | o- iqn.2006-04.sap-cl2.local:sap-cl2 .................................................................... [Mapped LUNs: 1]
  |     |   o- mapped_lun0 ........................................................................... [lun0 fileio/sbdascsers (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- loopback ......................................................................................................... [Targets: 0]

Konfigurowanie urządzenia SBD serwera docelowego iSCSI

[A]: Dotyczy wszystkich węzłów. [1]: Dotyczy tylko węzła 1. [2]: Dotyczy tylko węzła 2.

W węzłach klastra nawiąż połączenie i odnajdywanie urządzenia iSCSI utworzonego we wcześniejszej sekcji. Uruchom następujące polecenia w węzłach nowego klastra, który chcesz utworzyć.

  1. [A] Zainstaluj lub zaktualizuj narzędzia inicjatora iSCSI na wszystkich węzłach klastra.

    sudo yum install -y iscsi-initiator-utils

  2. [A] Zainstaluj pakiety klastra i SBD na wszystkich węzłach klastra.

    sudo yum install -y pcs pacemaker sbd fence-agents-sbd

  3. [A] Włącz usługę iSCSI.

    sudo systemctl enable iscsid iscsi

  4. [1] Zmień nazwę inicjatora w pierwszym węźle klastra.

    sudo vi /etc/iscsi/initiatorname.iscsi

# Change the content of the file to match the access control ists (ACLs) you used when you created the iSCSI device on the iSCSI target server (for example, for the ASCS/ERS servers)
InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1

  5. [2] Zmień nazwę inicjatora w drugim węźle klastra.

    sudo vi /etc/iscsi/initiatorname.iscsi

# Change the content of the file to match the access control ists (ACLs) you used when you created the iSCSI device on the iSCSI target server (for example, for the ASCS/ERS servers)
InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2

  6. [A] Uruchom ponownie usługę iSCSI, aby zastosować zmiany.

    sudo systemctl restart iscsid 
sudo systemctl restart iscsi

  7. [A] Łączenie urządzeń iSCSI. W poniższym przykładzie 10.0.0.17 jest adresem IP serwera docelowego iSCSI, a 3260 jest portem domyślnym. Nazwa iqn.2006-04.ascsnw1.local:ascsnw1 docelowa zostanie wyświetlona podczas uruchamiania pierwszego polecenia iscsiadm -m discovery.

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

  8. [A] Jeśli używasz wielu urządzeń SBD, połącz się również z drugim serwerem docelowym iSCSI.

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

  9. [A] Jeśli używasz wielu urządzeń SBD, połącz się również z trzecim serwerem docelowym iSCSI.

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

  10. [A] Upewnij się, że urządzenia iSCSI są dostępne i zanotuj nazwę urządzenia. W poniższym przykładzie trzy urządzenia iSCSI są odnajdywane przez połączenie węzła z trzema serwerami docelowymi iSCSI.

    lsscsi

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

  11. [A] Pobieranie identyfikatorów urządzeń iSCSI.

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:85d254ed-78e2-4ec4-8b0d-ecac2843e086 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_85d254ed-78e2-4ec4-8b0d-ecac2843e086 -> ../../sdf

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:87122bfc-8a0b-4006-b538-d0a6d6821f04 -> ../../sdh
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d -> ../../sdh
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_87122bfc-8a0b-4006-b538-d0a6d6821f04 -> ../../sdh

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:d2ddc548-060c-49e7-bb79-2bb653f0f34a -> ../../sdg
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 -> ../../sdg
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_d2ddc548-060c-49e7-bb79-2bb653f0f34a -> ../../sdg

    Polecenie wyświetla listę trzech identyfikatorów urządzeń dla każdego urządzenia SBD. Zalecamy użycie identyfikatora rozpoczynającego się od scsi-3. W poprzednim przykładzie identyfikatory to:

    • /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2
    • /dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d
    • /dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65

  12. [1] Tworzenie urządzenia SBD.

    1. Użyj identyfikatora urządzenia urządzeń iSCSI, aby utworzyć nowe urządzenia SBD w pierwszym węźle klastra.

      sudo sbd -d /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2 -1 60 -4 120 create

    2. Utwórz również drugie i trzecie urządzenia SBD, jeśli chcesz użyć więcej niż jednego.

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

  13. [A] Dostosowywanie konfiguracji SBD

    1. Otwórz plik konfiguracji SBD.

      sudo vi /etc/sysconfig/sbd

    2. Zmień właściwość urządzenia SBD, włącz integrację modułu pacemaker i zmień tryb uruchamiania usługi SBD.

      [...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2;/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d;/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65"
[...]
SBD_PACEMAKER=yes
[...]
SBD_STARTMODE=always
[...]
SBD_DELAY_START=yes
[...]

  14. [A] Uruchom następujące polecenie, aby załadować softdog moduł.

    modprobe softdog

  15. [A] Uruchom następujące polecenie, aby upewnić się, że softdog jest automatycznie ładowane po ponownym uruchomieniu węzła.

    echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load

  16. [A] Wartość limitu czasu usługi SBD jest domyślnie ustawiona na 90 s. Jeśli jednak wartość jest ustawiona SBD_DELAY_START na yes, usługa SBD opóźni uruchomienie do momentu przekroczenia limitu msgwait czasu. W związku z tym wartość limitu czasu usługi SBD powinna przekraczać msgwait limit czasu, gdy SBD_DELAY_START jest włączony.

    sudo mkdir /etc/systemd/system/sbd.service.d
echo -e "[Service]\nTimeoutSec=144" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
sudo systemctl daemon-reload

systemctl show sbd | grep -i timeout
# TimeoutStartUSec=2min 24s
# TimeoutStopUSec=2min 24s

Usługa SBD z dyskiem udostępnionym platformy Azure

Ta sekcja ma zastosowanie tylko wtedy, gdy chcesz użyć urządzenia SBD z dyskiem udostępnionym platformy Azure.

Konfigurowanie udostępnionego dysku platformy Azure przy użyciu programu PowerShell

Aby utworzyć i dołączyć dysk udostępniony platformy Azure za pomocą programu PowerShell, wykonaj następujące instrukcje. Jeśli chcesz wdrożyć zasoby przy użyciu interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal, możesz również zapoznać się z artykułem Wdrażanie dysku ZRS.

$ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"
$DiskSizeInGB = 4
$DiskName = "SBD-disk1"
$ShareNodes = 2
$LRSSkuName = "Premium_LRS"
$ZRSSkuName = "Premium_ZRS"  
$vmNames = @("prod-cl1-0", "prod-cl1-1")  # VMs to attach the disk

# ZRS Azure shared disk: Configure an Azure shared disk with ZRS for a premium shared disk
$zrsDiskConfig = New-AzDiskConfig -Location $Location -SkuName $ZRSSkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$zrsDataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $zrsDiskConfig

# Attach ZRS disk to cluster VMs
foreach ($vmName in $vmNames) {
  $vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
  Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Attach -ManagedDiskId $zrsDataDisk.Id -Lun 0
  Update-AzVM -VM $vm -ResourceGroupName $resourceGroup -Verbose
}

# LRS Azure shared disk: Configure an Azure shared disk with LRS for a premium shared disk
$lrsDiskConfig = New-AzDiskConfig -Location $Location -SkuName $LRSSkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$lrsDataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $lrsDiskConfig

# Attach LRS disk to cluster VMs
foreach ($vmName in $vmNames) {
  $vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
  Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Attach -ManagedDiskId $lrsDataDisk.Id -Lun 0
  Update-AzVM -VM $vm -ResourceGroupName $resourceGroup -Verbose
}

Konfigurowanie urządzenia SBD dysku udostępnionego platformy Azure

  1. [A] Zainstaluj pakiety klastra i SBD na wszystkich węzłach klastra.

    sudo yum install -y pcs pacemaker sbd fence-agents-sbd

  2. [A] Upewnij się, że dołączony dysk jest dostępny.

    lsblk

# NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
# sda                 8:0    0    4G  0 disk
# sdb                 8:16   0   64G  0 disk
# ├─sdb1              8:17   0  500M  0 part /boot
# ├─sdb2              8:18   0   63G  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  /
# ├─sdb14             8:30   0    4M  0 part
# └─sdb15             8:31   0  495M  0 part /boot/efi
# sr0                11:0    1 1024M  0 rom

lsscsi

# [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
# [0:0:0:2]    cd/dvd  Msft     Virtual DVD-ROM  1.0   /dev/sr0
# [1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
# [1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdc

  3. [A] Pobierz identyfikator urządzenia dołączonego dysku udostępnionego.

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

# lrwxrwxrwx 1 root root  9 Jul 15 22:24 /dev/disk/by-id/scsi-14d534654202020200792c2f5cc7ef14b8a7355cb3cef0107 -> ../../sda
# lrwxrwxrwx 1 root root  9 Jul 15 22:24 /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107 -> ../../sda

    Identyfikator urządzenia dołączonego dysku udostępnionego zawiera listę poleceń. Zalecamy użycie identyfikatora rozpoczynającego się od scsi-3. W tym przykładzie identyfikator to /dev/disk/by-id/scsi-3600224800792c2f5cc7e5cb3cef0107.

  4. [1] Tworzenie urządzenia SBD

    # Use the device ID from step 3 to create the new SBD device on the first cluster node
sudo sbd -d /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107 -1 60 -4 120 create

  5. [A] Dostosowywanie konfiguracji SBD

    1. Otwórz plik konfiguracji SBD.

      sudo vi /etc/sysconfig/sbd

    2. Zmienianie właściwości urządzenia SBD, włączanie integracji modułu pacemaker i zmienianie trybu uruchamiania usługi SBD

      [...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107"
[...]
SBD_PACEMAKER=yes
[...]
SBD_STARTMODE=always
[...]
SBD_DELAY_START=yes
[...]

  6. [A] Uruchom następujące polecenie, aby załadować softdog moduł.

    modprobe softdog

  7. [A] Uruchom następujące polecenie, aby upewnić się, że softdog jest automatycznie ładowane po ponownym uruchomieniu węzła.

    echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load

  8. [A] Wartość limitu czasu usługi SBD jest domyślnie ustawiona na 90 sekund. Jeśli jednak wartość jest ustawiona SBD_DELAY_START na yes, usługa SBD opóźni uruchomienie do momentu przekroczenia limitu msgwait czasu. W związku z tym wartość limitu czasu usługi SBD powinna przekraczać msgwait limit czasu, gdy SBD_DELAY_START jest włączony.

    sudo mkdir /etc/systemd/system/sbd.service.d
echo -e "[Service]\nTimeoutSec=144" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
sudo systemctl daemon-reload

systemctl show sbd | grep -i timeout
# TimeoutStartUSec=2min 24s
# TimeoutStopUSec=2min 24s

Konfiguracja agenta ogrodzenia platformy Azure

Urządzenie ogrodzenia używa tożsamości zarządzanej dla zasobu platformy Azure lub jednostki usługi do autoryzacji na platformie Azure. W zależności od metody zarządzania tożsamościami postępuj zgodnie z odpowiednimi procedurami —

  1. Konfigurowanie zarządzania tożsamościami

    Użyj tożsamości zarządzanej lub jednostki usługi.

    Aby utworzyć tożsamość zarządzaną (MSI), utwórz tożsamość zarządzaną przypisaną przez system dla każdej maszyny wirtualnej w klastrze. Jeśli tożsamość zarządzana przypisana przez system już istnieje, zostanie użyta. Nie używaj obecnie tożsamości zarządzanych przypisanych przez użytkownika z programem Pacemaker. Urządzenie ogrodzenia oparte na tożsamości zarządzanej jest obsługiwane w systemach RHEL 7.9 i RHEL 8.x/RHEL 9.x.

  2. Tworzenie roli niestandardowej dla agenta ogrodzenia

    Zarówno tożsamość zarządzana, jak i jednostka usługi nie mają domyślnie uprawnień dostępu do zasobów platformy Azure. Musisz przyznać tożsamości zarządzanej lub jednostce usługi uprawnienia do uruchamiania i zatrzymywania (wyłączania) wszystkich maszyn wirtualnych klastra. Jeśli rola niestandardowa nie została jeszcze utworzona, możesz ją utworzyć przy użyciu programu PowerShell lub interfejsu wiersza polecenia platformy Azure.

    Użyj następującej zawartości dla pliku wejściowego. Musisz dostosować zawartość do subskrypcji, czyli zastąpić xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx identyfikatory subskrypcji i yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy identyfikatorami subskrypcji. Jeśli masz tylko jedną subskrypcję, usuń drugi wpis w pliku 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": []
}

  3. Przypisywanie roli niestandardowej

    Użyj tożsamości zarządzanej lub jednostki usługi.

    Przypisz rolę Linux Fence Agent Role niestandardową utworzoną w ostatniej sekcji do każdej tożsamości zarządzanej maszyn wirtualnych klastra. Każda tożsamość zarządzana przypisana przez system maszyny wirtualnej wymaga roli przypisanej dla każdego zasobu maszyny wirtualnej klastra. Aby uzyskać więcej informacji, zobacz Przypisywanie dostępu tożsamości zarządzanej do zasobu przy użyciu witryny Azure Portal. Sprawdź, czy przypisanie roli tożsamości zarządzanej każdej maszyny wirtualnej zawiera wszystkie maszyny wirtualne klastra.

    Ważne

    Należy pamiętać, że przypisanie i usunięcie autoryzacji z tożsamościami zarządzanymi może być opóźnione do momentu wprowadzenia w życie.

Instalacja klastra

Różnice w poleceniach lub konfiguracji między RHEL 7 i RHEL 8/RHEL 9 są oznaczone w dokumencie.

  1. [A] Zainstaluj dodatek RHEL HA.

    sudo yum install -y pcs pacemaker nmap-ncat

  2. [A] W systemie RHEL 9.x zainstaluj agentów zasobów na potrzeby wdrażania w chmurze.

    sudo yum install -y resource-agents-cloud

  3. [A] Zainstaluj pakiet ogrodzenia agentów, jeśli używasz urządzenia ogrodzenia opartego na agencie ogrodzenia platformy Azure.

    sudo yum install -y fence-agents-azure-arm

    Ważne

    Zalecamy następujące wersje agenta ogrodzenia platformy Azure (lub nowszego) dla klientów, którzy chcą używać tożsamości zarządzanych dla zasobów platformy Azure zamiast nazw głównych usług dla agenta ogrodzenia:

    • RHEL 8.4: ogrodzenie-agenci-4.2.1-54.el8.
    • RHEL 8.2: ogrodzenie-agenci-4.2.1-41.el8_2.4
    • RHEL 8.1: ogrodzenie agentów-4.2.1-30.el8_1.4
    • RHEL 7.9: ogrodzenie-agenci-4.2.1-41.el7_9.4.

    Ważne

    W systemie RHEL 9 zalecamy wykonanie następujących wersji pakietów (lub nowszych), aby uniknąć problemów z agentem ogrodzenia platformy Azure:

    • ogrodzenia agenci-4.10.0-20.el9_0.7
    • ogrodzenia agenci-common-4.10.0-20.el9_0.6
    • ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm

    Sprawdź wersję agenta ogrodzenia platformy Azure. W razie potrzeby zaktualizuj ją do minimalnej wymaganej wersji lub nowszej.

    # Check the version of the Azure Fence Agent
sudo yum info fence-agents-azure-arm

    Ważne

    Jeśli musisz zaktualizować agenta ogrodzenia platformy Azure, a jeśli używasz roli niestandardowej, pamiętaj o zaktualizowaniu roli niestandardowej w celu uwzględnienia akcji powerOff. Aby uzyskać więcej informacji, zobacz Tworzenie roli niestandardowej dla agenta ogrodzenia.

  4. [A] Skonfiguruj rozpoznawanie nazw hostów.

    Możesz użyć serwera DNS lub zmodyfikować /etc/hosts plik na wszystkich węzłach. W tym przykładzie /etc/hosts pokazano, jak używać pliku. Zastąp adres IP i nazwę hosta w następujących poleceniach.

    Ważne

    Jeśli używasz nazw hostów w konfiguracji klastra, ważne jest, aby mieć niezawodne rozpoznawanie nazw hostów. Komunikacja z klastrem kończy się niepowodzeniem, jeśli nazwy nie są dostępne, co może prowadzić do opóźnień trybu failover klastra.

    Zaletą użycia /etc/hosts jest to, że klaster staje się niezależny od systemu DNS, co może być również pojedynczym punktem awarii.

    sudo vi /etc/hosts

    Wstaw następujące wiersze do /etc/hosts. Zmień adres IP i nazwę hosta, aby pasować do twojego środowiska.

    # 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

  5. [A] Zmień hacluster hasło na to samo hasło.

    sudo passwd hacluster

  6. [A] Dodaj reguły zapory dla programu Pacemaker.

    Dodaj następujące reguły zapory do całej komunikacji klastra między węzłami klastra.

    sudo firewall-cmd --add-service=high-availability --permanent
sudo firewall-cmd --add-service=high-availability

  7. [A] Włącz podstawowe usługi klastra.

    Uruchom następujące polecenia, aby włączyć usługę Pacemaker i uruchomić ją.

    sudo systemctl start pcsd.service
sudo systemctl enable pcsd.service

  8. [1] Tworzenie klastra Pacemaker.

    Uruchom następujące polecenia, aby uwierzytelnić węzły i utworzyć klaster. Ustaw token na 30000, aby umożliwić konserwację pamięci. Aby uzyskać więcej informacji, zobacz ten artykuł dla systemu Linux.

    Jeśli tworzysz klaster w systemie RHEL 7.x, użyj następujących poleceń:

    sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000
sudo pcs cluster start --all

    Jeśli tworzysz klaster w systemie RHEL 8.x/RHEL 9.x, użyj następujących poleceń:

    sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000
sudo pcs cluster start --all

    Sprawdź stan klastra, uruchamiając następujące polecenie:

    # Run the following command until the status of both nodes is online
sudo pcs status

# Cluster name: nw1-azr
# WARNING: no stonith devices and stonith-enabled is not false
# Stack: corosync
# Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
# Last updated: Fri Aug 17 09:18:24 2018
# Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1
#
# 2 nodes configured
# 0 resources configured
#
# Online: [ prod-cl1-0 prod-cl1-1 ]
#
# No resources
#
# Daemon Status:
#   corosync: active/disabled
#   pacemaker: active/disabled
#   pcsd: active/enabled

  9. [A] Ustaw oczekiwane głosy.

    # Check the quorum votes 
pcs quorum status

# If the quorum votes are not set to 2, execute the next command
sudo pcs quorum expected-votes 2

    Napiwek

    Jeśli tworzysz klaster wielowęzłowy, czyli klaster z więcej niż dwoma węzłami, nie ustawiaj głosów na 2.

  10. [1] Zezwalaj na współbieżne akcje ogrodzenia.

    sudo pcs property set concurrent-fencing=true

Tworzenie urządzenia ogrodzenia w klastrze Pacemaker

Napiwek

  • Aby uniknąć wyścigów ogrodzenia w klastrze rozrusznika z dwoma węzłami, możesz skonfigurować właściwość klastra priority-fencing-delay . Ta właściwość wprowadza dodatkowe opóźnienie w ogrodzeniu węzła, który ma wyższy całkowity priorytet zasobów, gdy wystąpi scenariusz podziału mózgu. Aby uzyskać więcej informacji, zobacz Czy program Pacemaker ogrodzy węzeł klastra z najmniej uruchomionymi zasobami?.
  • Właściwość priority-fencing-delay ma zastosowanie do programu Pacemaker w wersji 2.0.4-6.el8 lub nowszej i w klastrze z dwoma węzłami. Jeśli skonfigurujesz właściwość klastra priority-fencing-delay , nie musisz ustawiać pcmk_delay_max właściwości. Jeśli jednak wersja pacemaker jest mniejsza niż 2.0.4-6.el8, należy ustawić pcmk_delay_max właściwość .
  • Aby uzyskać instrukcje dotyczące sposobu ustawiania właściwości klastra priority-fencing-delay , zobacz odpowiednie dokumenty SAP ASCS/ERS i SAP HANA scale-up HA.

Na podstawie wybranego mechanizmu ogrodzenia wykonaj tylko jedną sekcję, aby uzyskać odpowiednie instrukcje: SBD jako urządzenie ogrodzeniowe lub agent ogrodzenia platformy Azure jako urządzenie ogrodzenia.

SBD jako urządzenie ogrodzeniowe

  1. [A] Włączanie usługi SBD

    sudo systemctl enable sbd

  2. [1] W przypadku urządzenia SBD skonfigurowanego przy użyciu serwerów docelowych iSCSI lub dysku udostępnionego platformy Azure uruchom następujące polecenia.

    sudo pcs property set stonith-timeout=144
sudo pcs property set stonith-enabled=true

# Replace the device IDs with your device ID. 
pcs stonith create sbd fence_sbd \
devices=/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2,/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d,/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 \
op monitor interval=600 timeout=15

  3. [1] Uruchom ponownie klaster

    sudo pcs cluster stop --all

# It would take time to start the cluster as "SBD_DELAY_START" is set to "yes"
sudo pcs cluster start --all

    Uwaga

    Jeśli wystąpi następujący błąd podczas uruchamiania klastra pacemaker, możesz zignorować komunikat. Alternatywnie możesz uruchomić klaster przy użyciu polecenia pcs cluster start --all --request-timeout 140.

    Błąd: nie można uruchomić wszystkich węzłów node1/node2: Nie można nawiązać połączenia z węzłem1/node2, sprawdź, czy pcsd jest tam uruchomiony, lub spróbuj ustawić wyższy limit czasu z opcją --request-timeout (upłynął limit czasu operacji po 60000 milisekundach z odebranymi 0 bajtami)

Agent ogrodzenia platformy Azure jako urządzenie ogrodzenia

  1. [1] Po przypisaniu ról do obu węzłów klastra można skonfigurować urządzenia ogrodzeniowe w klastrze.

    sudo pcs property set stonith-timeout=900
sudo pcs property set stonith-enabled=true

  2. [1] Uruchom odpowiednie polecenie w zależności od tego, czy używasz tożsamości zarządzanej, czy jednostki usługi dla agenta ogrodzenia platformy Azure.

    Uwaga

    W przypadku korzystania z chmury Azure Government należy określić cloud= opcję podczas konfigurowania agenta ogrodzenia. Na przykład cloud=usgov dla chmury platformy Azure dla instytucji rządowych USA. Aby uzyskać szczegółowe informacje na temat obsługi oprogramowania RedHat w chmurze dla instytucji rządowych platformy Azure, zobacz Zasady pomocy technicznej dla klastrów wysokiej dostępności RHEL — Microsoft Azure Virtual Machines jako elementy członkowskie klastra.

    Napiwek

    Opcja pcmk_host_map jest wymagana tylko w poleceniu, jeśli nazwy hostów RHEL i nazwy maszyn wirtualnych platformy Azure nie są identyczne. Określ mapowanie w formacie nazwa hosta:vm-name. Aby uzyskać więcej informacji, zobacz Jaki format należy używać do określania mapowań węzłów na urządzeniach ogrodzeniowych w pcmk_host_map?.

    W przypadku systemu RHEL 7.x użyj następującego polecenia, aby skonfigurować urządzenie ogrodzenia:

    sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \ 
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

    W przypadku systemu RHEL 8.x/9.x użyj następującego polecenia, aby skonfigurować urządzenie ogrodzenia:

    # Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

Jeśli używasz urządzenia ogrodzenia opartego na konfiguracji jednostki usługi, przeczytaj artykuł Change from SPN to MSI for Pacemaker clusters using Azure fencing (Zmiana nazwy SPN na msi dla klastrów Pacemaker przy użyciu ogrodzenia platformy Azure) i dowiedz się, jak konwertować na konfigurację tożsamości zarządzanej.

Operacje monitorowania i ogrodzenia są deserializowane. W związku z tym, jeśli istnieje już uruchomiona operacja monitorowania i jednoczesne zdarzenie ogrodzenia, nie ma opóźnienia w trybie failover klastra, ponieważ operacja monitorowania jest już uruchomiona.

Napiwek

Agent ogrodzenia platformy Azure wymaga łączności wychodzącej z publicznymi punktami końcowymi. Aby uzyskać więcej informacji wraz z możliwymi rozwiązaniami, zobacz Łączność z publicznym punktem końcowym dla maszyn wirtualnych korzystających ze standardowego modułu równoważenia obciążenia.

Konfigurowanie programu Pacemaker dla zaplanowanych zdarzeń platformy Azure

Platforma Azure oferuje zaplanowane zdarzenia. Zaplanowane zdarzenia są wysyłane za pośrednictwem usługi metadanych i umożliwiają aplikacji przygotowanie się do takich zdarzeń.

Agent azure-events-az zasobów Pacemaker monitoruje zaplanowane zdarzenia platformy Azure. Jeśli wykryto zdarzenia, a agent zasobów ustali, że dostępny jest inny węzeł klastra, ustawia atrybut kondycji klastra.

Gdy atrybut kondycji klastra jest ustawiony dla węzła, ograniczenie lokalizacji wyzwala i wszystkie zasoby o nazwach, które nie zaczynają się od health- , są migrowane z dala od węzła z zaplanowanym zdarzeniem. Po uwolnieniu węzła klastra od uruchamiania zasobów klastra zaplanowane zdarzenie zostanie potwierdzone i może wykonać jego akcję, taką jak ponowne uruchomienie.

  1. [A] Upewnij się, że pakiet agenta azure-events-az jest już zainstalowany i aktualny.

    RHEL 8.x: sudo dnf info resource-agents
RHEL 9.x: sudo dnf info resource-agents-cloud

    Minimalne wymagania dotyczące wersji:

    • RHEL 8.4: resource-agents-4.1.1-90.13
    • RHEL 8.6: resource-agents-4.9.0-16.9
    • RHEL 8.8: resource-agents-4.9.0-40.1
    • RHEL 9.0: resource-agents-cloud-4.10.0-9.6
    • RHEL 9.2 i nowsze: resource-agents-cloud-4.10.0-34.1

  2. [1] Konfigurowanie zasobów w narzędziu Pacemaker.

    #Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true

  3. [1] Ustaw strategię i ograniczenie węzła kondycji klastra Pacemaker.

    sudo pcs property set node-health-strategy=custom

sudo pcs constraint location 'regexp%!health-.*' \
rule score-attribute='#health-azure' \
defined '#uname'

    Ważne

    Nie należy definiować żadnych innych zasobów w klastrze, zaczynając od health- innych zasobów opisanych w następnych krokach.

  4. [1] Ustaw początkową wartość atrybutów klastra. Uruchom polecenie dla każdego węzła klastra i dla środowisk skalowalnego w poziomie, w tym maszyny wirtualnej twórcy większości.

    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] Konfigurowanie zasobów w narzędziu Pacemaker. Upewnij się, że zasoby zaczynają się od health-azure.

    sudo pcs resource create health-azure-events \
ocf:heartbeat:azure-events-az \
op monitor interval=10s timeout=240s \
op start timeout=10s start-delay=90s

sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true failure-timeout=120s

  6. Wyjmij klaster Pacemaker z trybu konserwacji.

    sudo pcs property set maintenance-mode=false

  7. Wyczyść wszelkie błędy podczas włączania i sprawdź, health-azure-events czy zasoby zostały pomyślnie uruchomione we wszystkich węzłach klastra.

    sudo pcs resource cleanup

    Wykonywanie zapytania po raz pierwszy dla zaplanowanych zdarzeń może potrwać do dwóch minut. Testy pacemaker z zaplanowanymi zdarzeniami mogą używać akcji ponownego uruchamiania lub ponownego wdrażania dla maszyn wirtualnych klastra. Aby uzyskać więcej informacji, zobacz Zaplanowane zdarzenia.

Opcjonalna konfiguracja ogrodzenia

Napiwek

Ta sekcja ma zastosowanie tylko wtedy, gdy chcesz skonfigurować specjalne urządzenie fence_kdumpogrodzeniowe .

Jeśli musisz zebrać informacje diagnostyczne w ramach maszyny wirtualnej, może być przydatne skonfigurowanie innego urządzenia ogrodzenia na podstawie agenta fence_kdumpogrodzenia . fence_kdump Agent może wykryć, że węzeł wszedł do odzyskiwania awaryjnego kdump i może umożliwić ukończenie usługi odzyskiwania awaryjnego przed wywołaniem innych metod ogrodzenia. Pamiętaj, że fence_kdump nie jest to zamiennik tradycyjnych mechanizmów ogrodzenia, takich jak SBD lub agent ogrodzenia platformy Azure, gdy używasz maszyn wirtualnych platformy Azure.

Ważne

Należy pamiętać, że jeśli fence_kdump jest skonfigurowany jako urządzenie ogrodzeniowe pierwszego poziomu, wprowadza opóźnienia w operacjach ogrodzenia i, odpowiednio, opóźnienia w trybie failover zasobów aplikacji.

Jeśli zrzut awaryjny zostanie pomyślnie wykryty, ogrodzenie zostanie opóźnione do momentu zakończenia usługi odzyskiwania po awarii. Jeśli węzeł, który zakończył się niepowodzeniem, jest nieosiągalny lub nie odpowiada, ogrodzenie jest opóźnione o określony czas, skonfigurowaną liczbę iteracji i fence_kdump limit czasu. Aby uzyskać więcej informacji, zobacz Jak mogę skonfigurować fence_kdump w klastrze Red Hat Pacemaker?.

Może być konieczne dostosowanie proponowanego fence_kdump limitu czasu do określonego środowiska.

Zalecamy skonfigurowanie ogrodzenia tylko wtedy, gdy jest to konieczne, aby zebrać fence_kdump diagnostykę na maszynie wirtualnej i zawsze w połączeniu z tradycyjnymi metodami ogrodzenia, takimi jak SBD lub agent ogrodzenia platformy Azure.

Następujące artykuły z bazy wiedzy red hat zawierają ważne informacje dotyczące konfigurowania fence_kdump ogrodzenia:

Uruchom następujące opcjonalne kroki, aby dodać fence_kdump jako konfigurację ogrodzenia pierwszego poziomu oprócz konfiguracji agenta ogrodzenia platformy Azure.

  1. [A] Sprawdź, czy kdump jest aktywny i skonfigurowany.

    systemctl is-active kdump
# Expected result
# active

  2. [A] Zainstaluj agenta ogrodzenia fence_kdump .

    yum install fence-agents-kdump

  3. [1] Utwórz fence_kdump urządzenie ogrodzeniowe w klastrze.

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30

  4. [1] Skonfiguruj poziomy ogrodzenia, fence_kdump aby najpierw zaangażował się mechanizm ogrodzenia.

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1"
pcs stonith level add 1 prod-cl1-0 rsc_st_kdump
pcs stonith level add 1 prod-cl1-1 rsc_st_kdump
# Replace <stonith-resource-name> to the resource name of the STONITH resource configured in your pacemaker cluster (example based on above configuration - sbd or rsc_st_azure)
pcs stonith level add 2 prod-cl1-0 <stonith-resource-name>
pcs stonith level add 2 prod-cl1-1 <stonith-resource-name>

# Check the fencing level configuration 
pcs stonith level
# Example output
# Target: prod-cl1-0
# Level 1 - rsc_st_kdump
# Level 2 - <stonith-resource-name>
# Target: prod-cl1-1
# Level 1 - rsc_st_kdump
# Level 2 - <stonith-resource-name>

  5. [A] Zezwalaj na wymagane porty przez fence_kdump zaporę.

    firewall-cmd --add-port=7410/udp
firewall-cmd --add-port=7410/udp --permanent

  6. [A] Wykonaj konfigurację fence_kdump_nodes , /etc/kdump.conf aby uniknąć fence_kdump niepowodzenia z przekroczeniem limitu czasu dla niektórych kexec-tools wersji. Aby uzyskać więcej informacji, zobacz fence_kdump przekroczenie limitu czasu, gdy fence_kdump_nodes nie jest określony z narzędzi kexec-tools w wersji 2.0.15 lub nowszej , a fence_kdump kończy się niepowodzeniem z "przekroczeniem limitu czasu po X sekundach" w klastrze RHEL 6 lub 7 High Availability z wersjami narzędzi kexec-tools starszymi niż 2.0.14. W tym miejscu przedstawiono przykładową konfigurację klastra z dwoma węzłami. Po wprowadzeniu zmiany w /etc/kdump.confpliku należy ponownie wygenerować obraz kdump. Aby ponownie wygenerować, uruchom ponownie usługę kdump .

    vi /etc/kdump.conf
# On node prod-cl1-0 make sure the following line is added
fence_kdump_nodes  prod-cl1-1
# On node prod-cl1-1 make sure the following line is added
fence_kdump_nodes  prod-cl1-0

# Restart the service on each node
systemctl restart kdump

  7. [A] Upewnij się, że initramfs plik obrazu zawiera fence_kdump pliki i hosts . Aby uzyskać więcej informacji, zobacz Jak mogę skonfigurować fence_kdump w klastrze Red Hat Pacemaker?.

    lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts"
# Example output 
# -rw-r--r--   1 root     root          208 Jun  7 21:42 etc/hosts
# -rwxr-xr-x   1 root     root        15560 Jun 17 14:59 usr/libexec/fence_kdump_send

  8. Przetestuj konfigurację, rozbijając węzeł. Aby uzyskać więcej informacji, zobacz Jak mogę skonfigurować fence_kdump w klastrze Red Hat Pacemaker?.

    Ważne

    Jeśli klaster jest już wydajnie używany, należy odpowiednio zaplanować test, ponieważ awaria węzła ma wpływ na aplikację.

    echo c > /proc/sysrq-trigger

Następne kroki