Condividi tramite

Configurare Pacemaker su SUSE Linux Enterprise Server in Azure

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. Se si vuole assicurarsi che l'isolamento sia possibile anche in caso di errore di un server di destinazione iSCSI, è necessario usare tre dispositivi SBD, che implica la distribuzione di tre server di destinazione iSCSI. Questa configurazione offre un elevato livello di resilienza quando si usano dispositivi SBD.

    Diagramma di panoramica di Pacemaker su SLES

    Importante

    Quando pianifichi e distribuisci nodi cluster di Linux Pacemaker e dispositivi SBD, assicurati che il routing tra le tue macchine virtuali e quelle che ospitano i dispositivi SBD non passi attraverso altri dispositivi, come ad esempio un'appliance virtuale di rete.

    Gli eventi di manutenzione e altri problemi con NVA possono avere un effetto 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 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 del 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 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 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

    Note

    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,aggiornare 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.

Note

  • [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. Inoltre, regolare il valore SBD_DELAY_START, se necessario

    [...]
SBD_DEVICE="/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf"
[...]
# In some cases, a longer delay than the default "msgwait" seconds is needed. So, set a specific delay value, in seconds. See, `man sbd` for more information. 
SBD_DELAY_START=216
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]

    Note

    Se il valore della proprietà SBD_DELAY_START è impostato su "no" o "sì", aggiornarlo con un valore di ritardo specifico, in secondi. Per altre informazioni, vedere la sezione Configuration via environment nel manuale di man sbd.

    c. Assicurarsi che il valore TimeoutStartSec nel file del servizio SBD sia maggiore del valore di SBD_DELAY_START. Per informazioni dettagliate, vedere la documentazione sulla configurazione dei file SBD.

    sudo systemctl show sbd | grep -i Timeout
# TimeoutStartUSec=4min 19s
# TimeoutStopUSec=4min 19s
# TimeoutAbortUSec=4min 19s

    Se il valore è predefinito (90 secondi) o è impostato minore di SBD_DELAY_START, seguire i passaggi per regolare il valore.

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

    Note

    Nella nuova compilazione del cluster, i valori SBD_DELAY_START e TimeoutStartSec vengono impostati automaticamente.

    Nella configurazione del cluster esistente, il valore di SBD_DELAY_START potrebbe essere impostato su "no" o "sì" e TimeoutStartSec sarebbe diverso. L'aggiornamento della versione SLES non aggiorna il valore, quindi è necessario regolare queste impostazioni manualmente.

  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

Per creare e collegare un disco condiviso di Azure a PowerShell, attenersi alle istruzioni seguenti. Per distribuire risorse tramite l'interfaccia della riga di comando di Azure o il portale di Azure, è anche possibile consultareDistribuire un disco ZRS.

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

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

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

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

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

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 SBD. Inoltre, regolare il valore SBD_DELAY_START, se necessario

    [...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19"
[...]
# # In some cases, a longer delay than the default "msgwait" seconds is needed. So, set a specific delay value, in seconds. See, `man sbd` for more information. 
SBD_DELAY_START=216
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]

    Note

    Se il valore della proprietà SBD_DELAY_START è impostato su "no" o "sì", aggiornarlo in base a un valore di ritardo specifico, in secondi. Per altre informazioni, vedere la sezione Configuration via environment nel manuale di man sbd.

    c. Assicurarsi che il valore TimeoutStartSec nel file del servizio SBD sia maggiore del valore di SBD_DELAY_START. Per informazioni dettagliate, vedere la documentazione sulla configurazione dei file SBD.

    sudo systemctl show sbd | grep -i Timeout
# TimeoutStartUSec=4min 19s
# TimeoutStopUSec=4min 19s
# TimeoutAbortUSec=4min 19s

    Se il valore è predefinito (90 secondi) o è impostato minore di SBD_DELAY_START, seguire i passaggi per regolare il valore.

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

    Note

    Nella nuova compilazione del cluster, i valori SBD_DELAY_START e TimeoutStartSec vengono impostati automaticamente.

    Nella configurazione del cluster esistente, il valore di SBD_DELAY_START potrebbe essere impostato su "no" o "sì" e TimeoutStartSec sarebbe diverso. L'aggiornamento della versione SLES non aggiorna il valore, quindi è necessario regolare manualmente queste impostazioni.

  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 l'agente di isolamento di Azure come dispositivo di isolamento. L'agente di isolamento di Azure usa un'identità gestita o un'entità servizio per l'autorizzazione Microsoft Azure.

Per creare un'identità gestita (MSI), creare un'identità gestita assegnata dal sistema per ogni macchina virtuale nel cluster. Se un'identità gestita assegnata dal sistema è già abilitata, verrà usata. 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

Note

  • [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

    Note

    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'agente di isolamento di Azure potrebbe non essere avviato in un cluster Pacemaker, visualizzando il messaggio di errore "Azure Resource Manager Python SDK 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 "Azure Resource Manager Python SDK non trovato o non accessibile" apparirà 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

    Note

    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 funzionano 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 la versione 4.9.0+git.1624456340.8d746be9-3.41.3 o versione successiva e per SLES 15 SP4 e versioni successive, è necessario installare il fence-agents-azure-arm pacchetto. Questo pacchetto include 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 fence-agents versione è inferiore a 4.9.0+git.1624456340.8d746be9-3.41.3e 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 your python-azure-mgmt-compute o python3-azure-mgmt-compute è 17.0.0-6.7.1, seguire le istruzioni in SUSE KBA per aggiornare la versione degli agenti di isolamento e installare la libreria client Azure Identity per il modulo Python, se manca.

  12. [A] Configurare la risoluzione del nome 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 ha esito negativo se i nomi non sono disponibili e questo può causare ritardi di 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 altre informazioni, vedere la Guida all'amministrazione delle estensioni a disponibilità elevata su SUSE Linux Enterprise Server.
  • La proprietà priority-fencing-delay è applicabile solo per il cluster a due nodi. 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).
  • Quando si configura un cluster per lo scale-out di HANA, non impostare la proprietà pcmk_delay_max nella risorsa SBD Stonith.

  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=210
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

    Note

    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" \
meta failure-timeout=120s \
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, imposta un attributo #health-azure di integrità a livello di nodo su -1000000.

Quando questo speciale attributo di integrità del cluster è impostato per un nodo, il nodo viene considerato non integro dal cluster e tutte le risorse vengono migrate dal nodo interessato. Il vincolo di localizzazione garantisce che le risorse il cui nome inizia con "health-" vengano escluse, poiché l'agente deve essere eseguito in questo stato di errore. Quando il nodo del cluster interessato è libero di eseguire risorse cluster, l'evento pianificato può eseguire l'azione, ad esempio il riavvio, senza rischi per l'esecuzione delle risorse.

L'#heath-azureattributo viene ripristinato su 0 all'avvio di pacemaker, una volta elaborati tutti gli eventi, contrassegnando nuovamente il nodo come sano.

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 failure-timeout=120s \
op start start-delay=60s \
op monitor interval=10s

sudo crm configure clone health-azure-events-cln health-azure-events \
meta allow-unhealthy-nodes=true

    Note

    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.

    Note

    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

  • Last updated on