Configurazione di Pacemaker su SUSE Linux Enterprise Server in Azure

  • Articolo

Questo articolo illustra come configurare Pacemaker in SU edizione Standard 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 non riuscito tramite le API di Azure oppure è possibile usare il dispositivo SBD.

Usare un dispositivo SBD

È possibile configurare il dispositivo SBD usando una delle due opzioni seguenti:

  • SBD con un server di destinazione iSCSI:

    Il dispositivo SBD richiede almeno una macchina virtuale aggiuntiva che funge da server di destinazione iSCSI (Internet Small Computer System Interface) e fornisce un dispositivo SBD. Questi server di destinazione iSCSI possono tuttavia essere condivisi con altri cluster Pacemaker. Il vantaggio dell'uso di un dispositivo SBD è che, se si usano già dispositivi SBD in locale, non sono necessarie modifiche al funzionamento 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 vuole usare più di un dispositivo SBD per Pacemaker, assicurarsi di distribuire più server di destinazione iSCSI e connettere un SBD da ogni server di destinazione iSCSI. È consigliabile usare uno o tre dispositivi SBD. Pacemaker non è in grado di delimitare automaticamente un nodo del cluster se sono configurati solo due dispositivi SBD e uno di essi non è disponibile. Se si vuole essere in grado di recinto quando un server di destinazione iSCSI è inattivo, è necessario usare tre dispositivi SBD e, di conseguenza, tre server di destinazione iSCSI. Questa è la configurazione più resiliente quando si usano gli SBD.

    Diagramma della panoramica di Pacemaker su SLES.

    Importante

    Quando si pianifica e si distribuiscono nodi cluster Linux Pacemaker e dispositivi SBD, non consentire il routing tra le macchine virtuali e le macchine virtuali che ospitano i dispositivi SBD per passare attraverso altri dispositivi, ad esempio un'appliance virtuale di rete.

    Gli eventi di manutenzione e altri problemi relativi all'appliance virtuale di rete possono avere un impatto negativo sulla stabilità e sull'affidabilità della configurazione complessiva del 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 del dispositivo SBD che usa un disco condiviso di Azure è che non è necessario distribuire macchine virtuali aggiuntive.

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

    Ecco 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 e nell'archiviazione con ridondanza della zona.
    • 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 l'archiviazione con ridondanza locale per il disco condiviso Premium di Azure (skuName - Premium_LRS) è supportato solo con la distribuzione nel set di disponibilità.
    • Un dispositivo SBD che usa l'archiviazione con ridondanza della zona per un disco condiviso Premium di Azure (skuName - Premium_ZRS) è consigliato con la distribuzione nelle zone di disponibilità.
    • Un'archiviazione con ridondanza della zona per il disco gestito non è attualmente disponibile in tutte le aree con zone di disponibilità. Per altre informazioni, vedere la sezione "Limitazioni" dell'archiviazione con ridondanza della zona 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 del disco P1 o P2 per il dispositivo SBD in un cluster a due nodi, ad esempio SAP ASCS/ERS o SAP HANA.
    • Per la scalabilità orizzontale di HANA con la replica di sistema HANA (HSR) e Pacemaker, è possibile usare un disco condiviso di Azure per i dispositivi SBD nei cluster con un massimo di quattro nodi per sito di replica a causa del limite corrente di maxShares.
    • Non è consigliabile collegare un dispositivo SBD su disco condiviso di Azure tra cluster Pacemaker.
    • Se si usano più dispositivi SBD del disco condiviso di Azure, controllare il limite per un numero massimo di dischi dati che possono essere collegati a una macchina virtuale.
    • Per altre informazioni sulle limitazioni per i dischi condivisi di Azure, vedere attentamente la sezione "Limitazioni" della documentazione del disco condiviso di Azure.

Usare un agente di isolamento di Azure

È possibile configurare l'isolamento usando un agente di isolamento di Azure. L'agente di isolamento di Azure richiede identità gestite per le macchine virtuali del cluster o un'entità servizio che gestisce il riavvio dei nodi non riusciti 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 usa 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 successive e connetterle tramite SSH. La macchina non dovrà essere di grandi dimensioni. Le dimensioni delle macchine virtuali Standard_E2s_v3 o Standard_D2s_v3 sono sufficienti. Assicurarsi di usare l'archiviazione Premium per il disco del sistema operativo.

  2. Nelle macchine virtuali di destinazione iSCSI eseguire i comandi seguenti:

    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 che non sono stati 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 da usare dai sistemi SAP, eseguire i comandi seguenti in tutte le macchine virtuali di destinazione iSCSI. Nell'esempio vengono creati dispositivi SBD per più cluster. Illustra come usare un 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 NW1.
  • nfs-0 e nfs-1: nomi host dei nodi del cluster NFS.
  • nw1-xscs-0 e nw1-xscs-1: nomi host dei nodi del cluster ASCS NW1.
  • nw1-db-0 e nw1-db-1: nomi host dei nodi del cluster di database.

Nelle istruzioni seguenti sostituire modificare 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 il server ASCS di SAP System 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 di SAP System 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 dell'elenco di destinazione.

    sudo targetcli saveconfig

  6. Verificare 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

Connessione al dispositivo iSCSI creato nell'ultimo passaggio dal cluster. Eseguire i comandi seguenti nei nodi del nuovo cluster che si vuole 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] Connessione 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 nel primo nodo.

    sudo vi /etc/iscsi/initiatorname.iscsi

  4. [1] Modificare il contenuto del file in modo che corrisponda agli elenchi di controllo di accesso (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 nel 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 la modifica.

    sudo systemctl restart iscsid
sudo systemctl restart iscsi

  8. [A] Connessione i 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 vogliono 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 vogliono 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 prendere nota del nome del dispositivo (/dev/sde, nell'esempio seguente).

    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

    Il comando elenca 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 vuole usare 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 di 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ì". È inoltre necessario controllare il file del servizio SBD per assicurarsi che il valore di TimeoutStartSec sia maggiore del valore di SBD_DELAY_START. Per altre informazioni, vedere Configurazione file SBD

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

    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 vuole 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 per un disco condiviso Premium di Azure, usare il valore SkuName di archiviazione seguente:

    $SkuName = "Premium_LRS"

  5. Per un dispositivo SBD che usa l'archiviazione con ridondanza della zona per un disco condiviso Premium di Azure, usare il codice 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 macchine virtuali del cluster.

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

    a. Aggiungere il disco condiviso di Azure al nodo 1 del cluster.

    $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 2 del cluster.

    $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 le risorse usando l'interfaccia della riga di comando di Azure o il portale di Azure, è anche possibile fare riferimento a Distribuire un disco ZRS.

Configurare un dispositivo SBD su 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 del 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ì". È inoltre necessario controllare il file del servizio SBD per assicurarsi che il valore di TimeoutStartSec sia maggiore del valore di SBD_DELAY_START. Per altre informazioni, vedere Configurazione file SBD

  6. Creare il softdog file di configurazione.

    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 vuole usare un dispositivo di isolamento con un agente di isolamento di Azure.

Creare un dispositivo 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 autorizzare microsoft Azure.

Per creare un'identità gestita , creare un'identità gestita assegnata dal sistema per ogni macchina virtuale nel cluster. Se esiste già un'identità gestita assegnata dal sistema, verrà usata. Le identità gestite assegnate dall'utente non devono essere usate con Pacemaker in questo momento. 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 hanno le 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 non è già stato creato il ruolo personalizzato, è possibile farlo usando 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. Ovvero sostituire xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ey-y-y-y con i propri ID sottoscrizione. Se si dispone di 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 "Ruolo agente di isolamento Linux" creato nell'ultimo capitolo a ogni identità gestita delle macchine virtuali 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 un accesso all'identità gestita a una risorsa usando il portale di Azure. Verificare che l'assegnazione di ruolo dell'identità gestita di ogni macchina virtuale contenga tutte le macchine virtuali del cluster.

Importante

Tenere presente l'assegnazione e la rimozione dell'autorizzazione con identità gestite può essere ritardata fino a quando non è effettiva.

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

    In SLES 15 SP4 controllare la versione del pacchetto crmsh e pacemaker e assicurarsi che siano soddisfatti i requisiti di versione miniumum:

    • crmsh-4.4.0+20221028.3e41444-150400.3.9.1 o versione successiva
    • pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 o versione successiva

  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 siano soddisfatti i requisiti minimi per la versione:

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

  4. [A] Configurare il sistema operativo.

    a. Pacemaker crea occasionalmente molti processi, che possono esaurire il numero consentito. In questo caso, un heartbeat tra i nodi del cluster potrebbe non riuscire e causare un 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 scambio 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, è consigliabile aggiornare il pacchetto cloud-netconfig-azure alla versione più recente disponibile.

    Suggerimento

    Se la versione nell'ambiente è 1.3 o successiva, non è più necessario eliminare la gestione delle interfacce di rete dal plug-in di rete cloud.

    Solo se la versione di cloud-netconfig-azure è inferiore alla 1.3, modificare il file di configurazione per l'interfaccia di rete come illustrato nel codice seguente per impedire al plug-in di rete cloud di rimuovere 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, in base all'agente di isolamento di Azure.

    sudo zypper install fence-agents

    Importante

    La versione installata del pacchetto fence-agents deve essere 4.4.0 o successiva per trarre vantaggio dai tempi di failover più rapidi con l'agente di isolamento di Azure, quando un nodo del cluster è delimitato. 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.1e0863 o versione successiva.

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

  10. [A] Installare il modulo Azure Python SDK e Azure Identity Python.

    Installare Azure Python SDK in SLES 12 SP4 o SLES 12 SP5:

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

    Installare Azure Python SDK in SLES 15 o versione successiva:

    # 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, potrebbe essere necessario attivare l'estensione cloud pubblico per la versione del sistema operativo prima di poter installare Azure Python SDK. È 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 SP4 o 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 o python3-azure-mgmt-compute è 17.0.0-6.7.1, seguire le istruzioni in SU edizione Standard KBA per aggiornare la versione di fence-agents e installare la libreria client di Azure Identity per python, se mancante.

  11. [A] Configurare la risoluzione del nome host.

    È possibile usare un server DNS o modificare il file /etc/hosts in tutti i nodi. In questo esempio viene illustrato 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, è essenziale avere una risoluzione affidabile del nome host. La comunicazione del cluster avrà esito negativo se i nomi non sono disponibili e ciò può causare ritardi di failover del cluster.

    Il vantaggio dell'uso di /etc/hosts è che il cluster diventa indipendente dal DNS, che potrebbe essere anche un singolo punto di errore.

    sudo vi /etc/hosts

    Inserire le righe seguenti in /etc/hosts. Modificare l'indirizzo IP e il nome host in modo che corrispondano 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

  12. [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 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

  13. [2] Aggiungere il 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

  14. [A] Modificare la password hacluster con la stessa password.

    sudo passwd hacluster

  15. [A] Regolare le impostazioni corosync.

    sudo vi /etc/corosync/corosync.conf

    a. Controllare la sezione seguente nel file e regolare, se i valori non sono presenti o sono diversi. Assicurarsi di modificare il token impostandolo 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 corse di isolamento all'interno di un cluster pacemaker a due nodi, è possibile configurare una proprietà del cluster "priority-fencing-delay" aggiuntiva. 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 SU edizione Standard Guida all'amministrazione delle estensioni per la disponibilità elevata di Linux Enterprise Server.
  • Le istruzioni sull'impostazione della proprietà del cluster "priority-fencing-delay" sono disponibili nei rispettivi documenti sap ASCS/ERS (applicabili solo su ENSA2) e nel documento di disponibilità elevata di SAP HANA.

  1. [1] Se si usa un dispositivo SBD (server di destinazione iSCSI o disco condiviso di Azure) come dispositivo di isolamento, eseguire i comandi seguenti. Abilitare l'uso di un dispositivo di isolamento e 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, eseguire 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 e i nomi delle macchine virtuali 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, in base alla configurazione dell'entità servizio, vedere Passare da SPN a MSI per cluster Pacemaker usando l'isolamento di Azure e informazioni su come eseguire la conversione in configurazione dell'identità gestita.

Importante

Le operazioni di monitoraggio e isolamento vengono deserializzate. Di conseguenza, se è presente un'operazione di monitoraggio con esecuzione più lunga e un evento di isolamento simultaneo, non è previsto 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 agli endpoint pubblici, come documentato, insieme alle possibili soluzioni, nella connettività degli endpoint pubblici per le macchine virtuali che usano il bilanciamento del carico interno standard.

Configurare Pacemaker per gli eventi pianificati di Azure

Azure offre eventi pianificati. Gli eventi pianificati vengono forniti tramite il servizio metadati e consentono all'applicazione di prepararsi per tali eventi. Azure-events-az monitora l'agente di risorse per gli eventi di Azure pianificati. Se vengono rilevati eventi e l'agente risorse determina che è disponibile un altro nodo del cluster, imposta un attributo di integrità del cluster. Quando l'attributo di integrità del cluster è impostato per un nodo, il vincolo di posizione attiva e tutte le risorse, il cui nome non inizia con "health-" viene migrato 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ò eseguirne l'azione, ad esempio il riavvio.

Importante

In precedenza, questo documento descriveva l'uso di azure-events dell'agente di risorse. Il nuovo agente di risorse azure-events-az supporta completamente gli 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 a partire da "health-", oltre alle risorse descritte nei passaggi successivi della documentazione.

  4. [1] Impostare il valore iniziale degli attributi del cluster. Eseguire per ogni nodo del cluster. Per gli ambienti con scalabilità orizzontale, inclusa la macchina virtuale 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=90s \ 
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 sconosciuto 'allow-unhealthy-nodes'.

  6. Disconnettere il cluster Pacemaker dalla modalità di 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

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

    Nota

    Dopo aver configurato le risorse pacemaker per l'agente azure-events, se si posiziona il cluster in modalità di manutenzione o fuori dalla modalità di manutenzione, è possibile che vengano visualizzati messaggi di avviso come:

    AVVISO: cib-bootstrap-options: attributo sconosciuto 'hostName_hostname'
    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