Configurazione di Pacemaker su SUSE Linux Enterprise Server in Azure

  • Articolo

Questo articolo descrive come configurare Pacemaker su SUSE Linux Enterprise Server (SLES) in Azure.

Panoramica

In Azure sono disponibili due opzioni per configurare l'isolamento nel cluster Pacemaker per SLES. È possibile usare un agente di isolamento di Azure, che riavvia un nodo in errore tramite le API di Azure oppure è possibile usare il dispositivo SBD.

Usare un dispositivo SBD

Per configurare il dispositivo SBD, è possibile usare una delle due opzioni seguenti:

  • SBD con un server di destinazione iSCSI:

    Il dispositivo SBD richiede almeno una macchina virtuale (VM) aggiunta che funga da server di destinazione iSCSI (Internet Small Computer System Interface) e fornisce un dispositivo SBD. Questi server di destinazione iSCSI, tuttavia, possono essere condivisi con altri cluster Pacemaker. Il vantaggio dell'uso di un dispositivo SBD consiste nel fatto che se già si usano dispositivi SBD in locale, tali dispositivi non richiedono alcuna modifica alla modalità di utilizzo del cluster Pacemaker.

    È possibile usare fino a tre dispositivi SBD per un cluster Pacemaker per consentire a un dispositivo SBD di diventare non disponibile, ad esempio durante l'applicazione di patch del sistema operativo del server di destinazione iSCSI. Se si desidera usare più di un dispositivo SBD per Pacemaker, assicurarsi di distribuire più server di destinazione iSCSI e connettere un solo SBD da ogni server di destinazione iSCSI. È consigliabile usare uno o tre dispositivi SBD. Pacemaker non può isolare automaticamente un nodo del cluster se sono configurati solo due dispositivi SBD e uno dei quali non è disponibile. Per porre un limite quando un server di destinazione iSCSI è inattivo, è necessario usare tre dispositivi SBD e pertanto tre server di destinazione iSCSI. Questa è la configurazione più resiliente quando si usano SBD.

    Diagramma di panoramica di Pacemaker su SLES

    Importante

    Quando si prevede di distribuire e configurare nodi del cluster Linux Pacemaker e dispositivi SBD, non consentire al routing tra le proprie macchine virtuali e quelle che ospitano i dispositivi SBD di passare da altri dispositivi, ad esempio un'appliance virtuale di rete (NVA).

    Eventi di manutenzione e altri problemi con le appliance virtuali di rete possono avere un impatto negativo sulla stabilità e l'affidabilità della configurazione di tutto il cluster. Per altre informazioni, vedere Regole di routing definite dall'utente.

  • SBD con un disco condiviso di Azure:

    Per configurare un dispositivo SBD, è necessario collegare almeno un disco condiviso di Azure a tutte le macchine virtuali che fanno parte del cluster Pacemaker. Il vantaggio di un dispositivo SBD che usa un disco condiviso di Azure consiste nel fatto che non richiede la distribuzione di macchine virtuali aggiuntive.

    Diagramma del dispositivo SBD con disco condiviso di Azure per il cluster Pacemaker SLES.

    Di seguito sono riportate alcune considerazioni importanti sui dispositivi SBD quando si usa un disco condiviso di Azure:

    • Un disco condiviso di Azure con SSD Premium è supportato come dispositivo SBD.
    • I dispositivi SBD che usano un disco condiviso di Azure sono supportati in SLES High Availability 15 SP01 e versioni successive.
    • I dispositivi SBD che usano un disco condiviso Premium di Azure sono supportati nell'archiviazione con ridondanza locale (LRS) e nell'archiviazione con ridondanza della zona (ZRS).
    • A seconda del tipo di distribuzione, scegliere l'archiviazione ridondante appropriata per un disco condiviso di Azure come dispositivo SBD.
    • Un dispositivo SBD che usa LRS per un disco condiviso Premium di Azure (skuName - Premium_LRS) è supportato solo con la distribuzione nel set di disponibilità.
    • Un dispositivo SBD che usa ZRS per un disco condiviso Premium di Azure (skuName - Premium_ZRS) è consigliato con la distribuzione in zone di disponibilità.
    • Un'archiviazione con ridondanza della zona (ZRS) per il disco gestito attualmente non è disponibile in tutte le aree geografiche con zone di disponibilità. Per altre informazioni, esaminare la sezione "Limitazioni" dell'archiviazione con ridondanza della zona (ZRS) in Opzioni di ridondanza per i dischi gestiti.
    • Il disco condiviso di Azure usato per i dispositivi SBD non deve essere di grandi dimensioni. Il valore maxShares determina il numero di nodi del cluster che possono usare il disco condiviso. Ad esempio, è possibile usare le dimensioni di disco P1 o P2 per il dispositivo SBD in un cluster a due nodi, come la scalabilità verticale SAP ASCS/ERS o SAP HANA.
    • Per lo scale-out HANA con replica di sistema HANA (HSR) e Pacemaker, è possibile usare un disco condiviso di Azure per i dispositivi SBD in cluster con un numero massimo di quattro nodi per sito di replica, a causa del limite corrente di maxShares.
    • Non è consigliabile collegare un dispositivo SBD con disco condiviso di Azure tra cluster Pacemaker.
    • Se si usano più dispositivi SBD con disco condiviso di Azure,verificare il limite massimo di dischi dati che è possibile collegare a una macchina virtuale.
    • Per altre informazioni sulle limitazioni per i dischi condivisi di Azure, rivedere attentamente la sezione "Limitazioni" della documentazione relativa ai dischi condivisi di Azure.

Usare un agente di isolamento di Azure

È possibile configurare l'isolamento tramite un agente di isolamento di Azure. L'agente di isolamento di Azure richiede identità gestite per le VM del cluster o un'entità servizio che gestisce il riavvio di nodi in errore tramite le API di Azure. L'agente di isolamento di Azure non richiede la distribuzione di macchine virtuali aggiuntive.

SBD con un server di destinazione iSCSI

Per usare un dispositivo SBD che si serve di un server di destinazione iSCSI per l'isolamento, seguire le istruzioni nelle sezioni successive.

Configurare il server di destinazione iSCSI

Prima di tutto è necessario creare le macchine virtuali per la destinazione iSCSI. È possibile condividere i server di destinazione iSCSI con più cluster Pacemaker.

  1. Distribuire nuove macchine virtuali SLES 12 SP3 o versione successiva e connettersi a tali VM tramite SSH. La macchina non dovrà essere di grandi dimensioni. Le dimensioni della macchina virtuale Standard_E2s_v3 o Standard_D2s_v3 sono sufficienti. Assicurarsi di usare l'archiviazione Premium sul disco del sistema operativo.

  2. Usare i comandi seguenti in tutte le macchine virtuali di destinazione iSCSI:

    a. Aggiornare SLES.

    sudo zypper update

    Nota

    Dopo l'upgrade o l'aggiornamento potrebbe essere necessario riavviare il sistema operativo.

    b. Rimuovere i pacchetti.

    Per evitare un problema noto con targetcli e SLES 12 SP3, disinstallare i pacchetti seguenti. È possibile ignorare gli errori relativi ai pacchetti non trovati.

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

    c. Installare i pacchetti di destinazione iSCSI.

    sudo zypper install targetcli-fb dbus-1-python

    d. Abilitare il servizio di destinazione iSCSI.

    sudo systemctl enable targetcli
sudo systemctl start targetcli

Creare un dispositivo iSCSI nel server di destinazione iSCSI

Per creare i dischi iSCSI per i cluster che devono essere usati dai sistemi SAP, usare i comandi seguenti su tutte le macchine virtuali di destinazione iSCSI. Nell'esempio vengono creati dispositivi SBD per più cluster. Viene illustrato come usare un solo server di destinazione iSCSI per più cluster. I dispositivi SBD vengono posizionati nel disco del sistema operativo. Assicurarsi di avere spazio sufficiente.

  • nfs: identifica il cluster NFS.
  • ascsnw1: identifica il cluster ASCS di NW1.
  • dbnw1: identifica il cluster di database di NW1.
  • nfs-0 e nfs-1: i nomi host dei nodi del cluster NFS.
  • nw1-xscs-0 e nw1-xscs-1: i nomi host dei nodi del cluster ASCS NW1.
  • nw1-db-0 e nw1-db-1: i nomi host dei nodi del cluster di database.

Nelle istruzioni seguenti, sostituire i nomi host dei nodi del cluster e il SID del sistema SAP.

  1. Creare la cartella radice per tutti i dispositivi SBD.

    sudo mkdir /sbd

  2. Creare il dispositivo SBD per il server 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. Creare il dispositivo SBD per i server ASCS del sistema 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. Creare il dispositivo SBD per il cluster di database del sistema 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. Salvare le modifiche di targetcli.

    sudo targetcli saveconfig

  6. Assicurarsi che tutto sia stato configurato correttamente.

    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]

Configurare il dispositivo SBD del server di destinazione iSCSI

Connettersi al dispositivo iSCSI creato nell'ultimo passaggio dal cluster. Eseguire i comandi seguenti nei nodi del nuovo cluster che si intende creare.

Nota

  • [A]: si applica a tutti i nodi.
  • [1]: si applica solo al nodo 1.
  • [2]: si applica solo al nodo 2.

  1. [A] Installare il pacchetto iSCSI.

    sudo zypper install open-iscsi

  2. [A] Connettersi ai dispositivi iSCSI. Abilitare prima i servizi iSCSI e SBD.

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

  3. [1] Modificare il nome dell'iniziatore sul primo nodo.

    sudo vi /etc/iscsi/initiatorname.iscsi

  4. [1] Modificare il contenuto del file in modo che corrisponda agli ACL usati durante la creazione del dispositivo iSCSI nel server di destinazione iSCSI, ad esempio per il server NFS.

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

  5. [2] Modificare il nome dell'iniziatore sul secondo nodo.

    sudo vi /etc/iscsi/initiatorname.iscsi

  6. [2] Modificare il contenuto del file in modo che corrisponda agli ACL usati durante la creazione del dispositivo iSCSI nel server di destinazione iSCSI.

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

  7. [A] Riavviare il servizio iSCSI per applicare le modifiche.

    sudo systemctl restart iscsid
sudo systemctl restart iscsi

  8. [A] Connettersi ai dispositivi iSCSI. Nell'esempio seguente, 10.0.0.17 è l'indirizzo IP del server di destinazione iSCSI e 3260 è la porta predefinita. iqn.2006 04.nfs.local:nfs è uno dei nomi di destinazione elencati quando si esegue il primo comando, 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] Se si desidera usare più dispositivi SBD, connettersi anche al secondo server di destinazione 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] Se si desidera usare più dispositivi SBD, connettersi anche al terzo server di destinazione 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] Assicurarsi che i dispositivi iSCSI siano disponibili e annotare il nome dei dispositivi (nell'esempio seguente /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] Recuperare gli ID dei dispositivi 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

    Vengono elencati tre ID dispositivo per ogni dispositivo SBD. È consigliabile usare l'ID che inizia con scsi-3. Nell'esempio precedente, gli ID sono:

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

  13. [1] Creare il dispositivo SBD.

    a. Usare l'ID del dispositivo iSCSI per creare un nuovo dispositivo SBD nel primo nodo del cluster.

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

    b. Creare anche il secondo e il terzo dispositivo SBD se si intende usarne più di uno.

    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] Adattare la configurazione SBD.

    a. Aprire il file di configurazione SBD.

    sudo vi /etc/sysconfig/sbd

    b. Modificare la proprietà del dispositivo SBD, abilitare l'integrazione di Pacemaker e modificare la modalità di avvio 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"
[...]

    Nota

    Se il valore della proprietà SBD_DELAY_START è impostato su "no", modificare il valore in "sì". Controllare anche il file del servizio SBD per assicurarsi che il valore di TimeoutStartSec sia maggiore del valore di SBD_DELAY_START. Per altre informazioni, vedere la configurazione del file SBD

  15. [A] Creare il file di configurazione softdog.

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

  16. [A] Caricare il modulo.

    sudo modprobe -v softdog

SBD con un disco condiviso di Azure

Questa sezione si applica solo se si desidera usare un dispositivo SBD con un disco condiviso di Azure.

Creare e collegare un disco condiviso di Azure con PowerShell

  1. Modificare i valori per il gruppo di risorse, l'area di Azure, le macchine virtuali, i numeri di unità logica (LUN) e così via.

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

  2. Definire le dimensioni del disco in base alle dimensioni del disco disponibili per le unità SSD Premium. In questo esempio viene menzionata la dimensione del disco P1 4G.

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

  3. Con il parametro -MaxSharesCount, definire il numero massimo di nodi del cluster per collegare il disco condiviso per il dispositivo SBD.

    $ShareNodes = 2

  4. Per un dispositivo SBD che usa l'archiviazione con ridondanza locale (LRS) per un disco condiviso Premium di Azure, usare lo SkuName di archiviazione seguente:

    $SkuName = "Premium_LRS"

  5. Per un dispositivo SBD che usa l'archiviazione con ridondanza della zona (ZRS) per un disco condiviso Premium di Azure, usare lo SkuName di archiviazione seguente:

    $SkuName = "Premium_ZRS"

  6. Configurare un disco condiviso di Azure.

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

  7. Collegare il disco alle VM del cluster.

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

    a. Aggiungere il disco condiviso di Azure al nodo del cluster 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. Aggiungere il disco condiviso di Azure al nodo del cluster 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

Per distribuire risorse tramite l'interfaccia della riga di comando di Azure o il portale di Azure, è anche possibile consultareDistribuire un disco ZRS.

Configurare un dispositivo SBD con disco condiviso di Azure

  1. [A] Abilitare i servizi SBD.

    sudo systemctl enable sbd

  2. [A] Assicurarsi che il disco collegato sia disponibile.

    # 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] Recuperare gli ID dei dischi collegati.

    # 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

    I comandi elencano gli ID dispositivo per il dispositivo SBD. È consigliabile usare l'ID che inizia con scsi-3. Nell'esempio precedente l'ID è /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19.

  4. [1] Creare il dispositivo SBD.

    Usare l'ID dispositivo dal passaggio 2 per creare i nuovi dispositivi SBD nel primo nodo del cluster.

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

  5. [A] Adattare la configurazione SBD.

    a. Aprire il file di configurazione SBD.

    sudo vi /etc/sysconfig/sbd

    b. Modificare la proprietà del dispositivo SBD, abilitare l'integrazione di Pacemaker e modificare la modalità di avvio del dispositivo SBD.

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

    Nota

    Se il valore della proprietà SBD_DELAY_START è impostato su "no", modificare il valore in "sì". Controllare anche il file del servizio SBD per assicurarsi che il valore di TimeoutStartSec sia maggiore del valore di SBD_DELAY_START. Per altre informazioni, vedere la configurazione del file SBD

  6. Creazione del file di configurazione softdog.

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

  7. Caricare il modulo.

    sudo modprobe -v softdog

Usare un agente di isolamento di Azure

Questa sezione si applica solo se si desidera usare un dispositivo di isolamento con un agente di isolamento di Azure.

Usare un dispositivo dell'agente di isolamento di Azure

Questa sezione si applica solo se si usa un dispositivo di isolamento basato su un agente di isolamento di Azure. Il dispositivo di isolamento usa un'identità gestita o un'entità servizio per l'autorizzazione in Microsoft Azure.

Per creare un'identità gestita (MSI), creare un'identità gestita assegnata dal sistema per ogni macchina virtuale nel cluster. Se esiste già un'identità gestita assegnata dal sistema, viene usata tale identità. Al momento, non usare identità gestite assegnate dall'utente con Pacemaker. L'agente di isolamento di Azure, basato sull'identità gestita, è supportato per SLES 12 SP5 e SLES 15 SP1 e versioni successive.

[1] Creare un ruolo personalizzato per l'agente di isolamento

Per impostazione predefinita, né l'identità gestita né l'entità servizio dispongono delle autorizzazioni per accedere alle risorse di Azure. È necessario concedere all'identità gestita o all'entità servizio le autorizzazioni per avviare e arrestare (deallocare) tutte le macchine virtuali nel cluster. Se il ruolo personalizzato non è stato ancora creato, è possibile crearlo tramite PowerShell o l'interfaccia della riga di comando di Azure.

Per il file di input usare il contenuto seguente. È necessario adattare il contenuto alle sottoscrizioni. Vale a dire che occorre sostituire xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx e yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy con gli ID sottoscrizione. Se si ha una sola sottoscrizione, rimuovere la seconda voce in 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": []
}

[A] Assegnare il ruolo personalizzato

Usare l'identità gestita o l'entità servizio.

Assegnare il ruolo personalizzato "Linux Fence Agent Role" creato nell'ultimo capitolo per ogni identità gestita delle VM del cluster. Ogni identità gestita assegnata dal sistema della macchina virtuale richiede il ruolo assegnato per ogni risorsa della macchina virtuale del cluster. Per i passaggi dettagliati, vedere Assegnare a un'identità gestita l'accesso a una risorsa tramite il portale di Azure. Assicurarsi che l'assegnazione di ruolo dell'identità gestita di ogni VM contenga tutte le VM del cluster.

Importante

Tenere presente che l'assegnazione e la rimozione dell'autorizzazione con identità gestite possono subire un ritardo fino a quando non vengono applicate.

Installare il cluster

Nota

  • [A]: si applica a tutti i nodi.
  • [1]: si applica solo al nodo 1.
  • [2]: si applica solo al nodo 2.

  1. [A] Aggiornare SLES.

    sudo zypper update

    Nota

    Per SLES 15 SP4, verificare le versioni dei pacchetti crmsh e pacemaker per assicurarsi che soddisfino i requisiti minimi della versione:

    • crmsh-4.4.0+20221028.3e41444-150400.3.9.1 o versioni successive
    • pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 o versioni successive

    Importante

    • SLES 12 SP5: se è installato python-azure-core-1.23.1-2.12.8, l'avvio dell'agente di isolamento di Azure potrebbe non riuscire in un cluster Pacemaker, visualizzando il messaggio di errore "SDK Python di Azure Resource Manager non trovato o non accessibile" in /var/log/messages. Seguire le istruzioni in SUSE KBA 21532 per altri dettagli.
    • SLES 15 SP4+: dopo l'aggiornamento del sistema operativo, le librerie di Azure per Python potrebbero usare l'interprete Python 3.11, causando l'errore di avvio dell'agente di isolamento di Azure in un cluster Pacemaker. Il messaggio di errore "SDK Python di Azure Resource Manager non trovato o non accessibile" verrà visualizzato in /var/log/messages. Per altri dettagli, seguire le istruzioni in SUSE KBA 21504.

  2. [A] Installare il componente necessario per le risorse del cluster.

    sudo zypper in socat

  3. [A] Installare il componente azure-lb, necessario per le risorse del cluster.

    sudo zypper in resource-agents

    Nota

    Controllare la versione del pacchetto resource-agents e assicurarsi che i requisiti minimi della versione siano soddisfatti:

    • SLES 12 SP4/SP5: la versione deve essere resource-agents-4.3.018.a7fb5035-3.30.1 o una versione successiva.
    • SLES 15/15 SP1: la versione deve essere resource-agents-4.3.0184.6ee15eb2-4.13.1 o una versione successiva.

  4. [A] Configurare il sistema operativo.

    a. Pacemaker crea occasionalmente molti processi che possono esaurire il numero consentito. In tal caso, un heartbeat tra i nodi del cluster potrebbe avere esito negativo e richiedere il failover delle risorse. È consigliabile aumentare il numero massimo di processi consentiti impostando il parametro seguente:

    # 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. Ridurre le dimensioni della cache dirty. Per altre informazioni, vedere Prestazioni di scrittura ridotte sui server SLES 11 12 con RAM di grandi dimensioni.

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

    c. Assicurarsi che vm.swappiness sia impostato su 10 per ridurre l'utilizzo dello swapping e favorire la memoria.

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

  5. [A] Controllare la versione del pacchetto cloud-netconfig-azure.

    Controllare la versione installata del pacchetto cloud-netconfig-azure eseguendo zypper info cloud-netconfig-azure. Se la versione è precedente alla 1.3, si consiglia di aggiornare il pacchetto cloud-netconfig-azure all'ultima versione disponibile.

    Suggerimento

    Se la versione nell'ambiente è 1.3 o una successiva, non è più necessario disattivare la gestione delle interfacce di rete da parte del plug-in della rete cloud.

    Solo se la versione di cloud-netconfig-azure è precedente alla 1.3, modificare il file di configurazione per l'interfaccia di rete come mostrato nel codice seguente per evitare che il plug-in della rete cloud rimuova l'indirizzo IP virtuale (Pacemaker deve controllare l'assegnazione). Per altre informazioni, vedere l'articolo della Knowledge Base SUSE 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] Abilitare l'accesso 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] Abilitare l'accesso 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] Abilitare l'accesso 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] Installare il pacchetto fence-agents se si usa un dispositivo di isolamento basato sull'agente di isolamento di Azure.

    sudo zypper install fence-agents

    Importante

    La versione installata del pacchetto fence-agents deve essere 4.4.0 o una versione successiva per sfruttare i tempi di failover più rapidi con l'agente di isolamento di Azure, quando un nodo del cluster è isolato. Se si esegue una versione precedente, è consigliabile aggiornare il pacchetto.

    Importante

    Se si usa l'identità gestita, la versione installata del pacchetto fence-agents deve essere

    • SLES 12 SP5: fence-agents 4.9.0+git.1624456340.8d746be9-3.35.2 o versione successiva
    • SLES 15 SP1 e versioni successive: fence-agents 4.5.2+git.1592573838.1eee0863 o versione successiva.

    Le versioni precedenti non funzioneranno correttamente con una configurazione dell'identità gestita.

  10. [A] Installare il pacchetto fence-agents-azure-arm.

    Per SLES 12 SP5, se si usa fence-agents versione 4.9.0+git.1624456340.8d746be9-3.41.3 o successiva e per SLES 15 SP4 e versioni successive è necessario installare il pacchetto fence-agents-azure-arm. Questo pacchetto includerà tutte le dipendenze necessarie.

    # On SLES 12 SP5 with fence-agents version 4.9.0+git.1624456340.8d746be9-3.41.3 or higher. You might need to activate the public cloud extension first
SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper install fence-agents-azure-arm

# On SLES 15 SP4 and later. You might need to activate the public cloud extension first. In this example, the SUSEConnect 
SUSEConnect -p sle-module-public-cloud/15.4/x86_64
sudo zypper install fence-agents-azure-arm

  11. [A] Installare l'SDK Python di Azure e il modulo e Identity Python di Azure.

    Per SLES 12 SP5, se la versione fence-agents è anteriore a 4.9.0+git.1624456340.8d746be9-3.41.3 e per SLES 15 SP3 e versioni precedenti è necessario installare i pacchetti aggiuntivi seguenti.

    # 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

# 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

    Importante

    A seconda della versione e del tipo di immagine, per poter installare l'SDK Python di Azure potrebbe essere necessario prima attivare l'estensione cloud pubblico per la release del sistema operativo. È possibile controllare l'estensione eseguendo SUSEConnect ---list-extensions. Per ottenere tempi di failover più rapidi con l'agente di isolamento di Azure:

    • In SLES 12 SP5, installare la versione 4.6.2 o successiva del pacchetto python-azure-mgmt-compute.
    • Se la versione del pacchetto python-azure-mgmt-compute or python3-azure-mgmt-compute è 17.0.0-6.7.1, seguire le istruzioni riportate in SUSE KBA per aggiornare la versione degli agenti di isolamento e installare il modulo libreria client Identity di Azure per Python, se manca.

  12. [A] Configurare la risoluzione dei nomi host.

    È possibile usare un server DNS o modificare il file /etc/hosts in tutti i nodi. Questo esempio mostra come usare il file /etc/hosts.

    Sostituire l'indirizzo IP e il nome host nei comandi seguenti.

    Importante

    Se si usano nomi host nella configurazione del cluster, è fondamentale avere una risoluzione affidabile dei nomi host. La comunicazione del cluster non riuscirà se i nomi non sono disponibili, il che può causare ritardi del failover del cluster.

    Il vantaggio di usare /etc/hosts consiste nel fatto che il cluster diventa indipendente dal DNS, che potrebbe essere un singolo punto di guasto.

    sudo vi /etc/hosts

    Inserire le righe seguenti in /etc/hosts. Modificare l'indirizzo IP e il nome host in base all'ambiente.

    # 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

  13. [1] Installare il cluster.

    • Se si usano dispositivi SBD per l'isolamento (per il server di destinazione iSCSI o il disco condiviso di 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

    • Se non si usano di dispositivi SBD per l'isolamento:

      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

  14. [2] Aggiungere un nodo al cluster.

    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

  15. [A] Cambiare la password hacluster in modo da usare la stessa password.

    sudo passwd hacluster

  16. [A] Modificare le impostazioni di corosync.

    sudo vi /etc/corosync/corosync.conf

    a. Controllare la sezione seguente nel file e apportare modifiche se i valori non sono presenti o sono diversi. Assicurarsi di modificare il token su 30000 per consentire la manutenzione con mantenimento della memoria. Per altre informazioni, vedere l'articolo "Manutenzione per le macchine virtuali in Azure" per Linux o 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. Riavviare il servizio corosync.

    sudo service corosync restart

Creare un dispositivo di isolamento nel cluster Pacemaker

Suggerimento

  • Per evitare race condition dell'isolamento all'interno di un cluster Pacemaker a due nodi, è possibile configurare la proprietà aggiuntiva del cluster "priority-fencing-delay". Questa proprietà introduce un ulteriore ritardo nell'isolamento di un nodo con priorità totale più elevata quando si verifica uno scenario split-brain. Per altri dettagli, vedere Guida all'amministrazione dell'estensione per la disponibilità elevata di SUSE Linux Enterprise Server.
  • Le istruzioni sull'impostazione della proprietà del cluster "priority-fencing-delay" sono disponibili nel rispettivo documenti sulla disponibilità elevata con aumento SAP HANA e SAP ASCS/ERS (applicabile solo su ENSA2).

  1. [1] Se si usa un dispositivo SBD (server di destinazione iSCSI o disco condiviso di Azure) come dispositivo di isolamento, usare i comandi seguenti. Abilitare l'uso di un dispositivo di isolamento impostare il ritardo di isolamento.

    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] Se si usa un agente di isolamento di Azure per l'isolamento, usare i comandi seguenti. Dopo aver assegnato i ruoli a entrambi i nodi del cluster, è possibile configurare i dispositivi di isolamento nel cluster.

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

    Nota

    L'opzione "pcmk_host_map" è necessaria nel comando solo se i nomi host RHEL e i nomi delle VM di Azure non sono identici. Specificare il mapping nel formato nome host:vm-name.

# 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

Se si usa un dispositivo di isolamento basato sulla configurazione dell'entità servizio, leggere Passare da SPN a MSI per cluster Pacemaker usando l'isolamento di Azure per informazioni su come eseguire la conversione alla configurazione dell'identità gestita.

Importante

Le operazioni di monitoraggio e isolamento vengono deserializzate. Di conseguenza, se si verifica un'operazione di monitoraggio più lunga e un evento di isolamento simultaneo, non si verifica alcun ritardo per il failover del cluster perché l'operazione di monitoraggio è già in esecuzione.

Suggerimento

L'agente di isolamento di Azure richiede la connettività in uscita verso gli endpoint pubblici, come documentato, con l'aggiunta di possibili soluzioni, in Connettività di endpoint pubblici per VM con ILB standard.

Configurare Pacemaker per gli eventi pianificati di Azure

Azure offre eventi pianificati. Gli eventi pianificati vengono inviati tramite il servizio metadati e lasciano all'applicazione il tempo di prepararsi per tali eventi. L'agente di risorse azure-events-az monitora gli eventi di Azure pianificati. Se vengono rilevati eventi e l'agente di risorse determina che è disponibile un altro nodo del cluster, viene impostato un attributo di integrità del cluster. Quando l'attributo di integrità del cluster è impostato per un nodo, il vincolo di posizione si attiva e tutte le risorse i cui nomi non iniziano con "health-" vengono migrate dal nodo con l'evento pianificato. Una volta che il nodo del cluster interessato è libero di eseguire risorse del cluster, l'evento pianificato viene riconosciuto e può eseguire la relativa azione, ad esempio un riavvio.

Importante

In precedenza, questo documento descriveva l'uso dell'agente di risorse azure-events. Il nuovo agente di risorse azure-events-az supporta completamente ambienti di Azure distribuiti in zone di disponibilità diverse. È consigliabile usare l'agente azure-events-az più recente per tutti i sistemi SAP a disponibilità elevata con Pacemaker.

  1. [A] Assicurarsi che il pacchetto per l'agente azure-events sia già installato e aggiornato.

    sudo zypper info resource-agents

    Requisiti minimi per la versione:

    • SLES 12 SP5: resource-agents-4.3.018.a7fb5035-3.98.1
    • SLES 15 SP1: resource-agents-4.3.0184.6ee15eb2-150100.4.72.1
    • SLES 15 SP2: resource-agents-4.4.0+git57.70549516-150200.3.56.1
    • SLES 15 SP3: resource-agents-4.8.0+git30.d0077df0-150300.8.31.1
    • SLES 15 SP4 e versioni successive: resource-agents-4.10.0+git40.0f4de473-150400.3.19.1

  2. [1] Configurare le risorse in Pacemaker.

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

  3. [1] Impostare la strategia e il vincolo del nodo di integrità del cluster Pacemaker

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

    Importante

    Non definire altre risorse nel cluster che iniziano con "health-" oltre alle risorse descritte nei passaggi successivi della documentazione.

  4. [1] Impostare il valore iniziale degli attributi del cluster. Eseguire ogni nodo del cluster. Per ambienti scale-out inclusa la VM di maggioranza.

    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] Configurare le risorse in Pacemaker. Importante: le risorse devono iniziare con "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=60s \
op monitor interval=10s

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

    Nota

    Durante la configurazione della risorsa "health-azure-events", è possibile ignorare il messaggio di avviso seguente.

    AVVISO: health-azure-events: attributo "allow-unhealthy-nodes" sconosciuto.

  6. Rimuovere il cluster Pacemaker dalla modalità manutenzione

    sudo crm configure property maintenance-mode=false

  7. Cancellare eventuali errori durante l'abilitazione e verificare che le risorse health-azure-events siano state avviate correttamente in tutti i nodi del cluster.

    sudo crm resource cleanup

    La prima esecuzione della query per gli eventi pianificati può richiedere fino a 2 minuti. I test pacemaker con eventi pianificati possono usare azioni di riavvio o ridistribuzione per le macchine virtuali del cluster. Per altre informazioni, vedere la documentazione sugli eventi pianificati.

    Nota

    Dopo aver configurato le risorse di Pacemaker per l'agente azure-events, se si attiva o disattiva la modalità manutenzione del cluster, potrebbero essere visualizzati messaggi di avviso come i seguenti:

    AVVISO: cib-bootstrap-options: attributo "hostName_ hostname" sconosciuto
    AVVISO: cib-bootstrap-options: attributo sconosciuto 'azure-events_globalPullState'
    AVVISO: cib-bootstrap-options: attributo sconosciuto 'hostName_ hostname'
    Questi messaggi di avviso possono essere ignorati.

Passaggi successivi