Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure

Este artigo descreve como configurar o Pacemaker no SLES (SUSE Linux Enterprise Server) no Azure.

Visão geral

No Azure, você tem duas opções para configurar o isolamento no cluster do Pacemaker para SLES. Você pode usar um agente de isolamento do Azure, que reinicia um nó com falha por meio das APIs do Azure, ou pode usar um dispositivo SBD.

Usar um dispositivo SBD

Configure o dispositivo SBD usando uma de duas opções:

SBD com um servidor de destino iSCSI:

O dispositivo SBD requer pelo menos uma VM (máquina virtual) adicional que atue como um iSCSI e forneça um dispositivo SBD. Esses servidores de destino iSCSI podem, entretanto, ser compartilhados com outros clusters do Pacemaker. A vantagem de usar um dispositivo SBD é que, se você já estiver usando dispositivos SBD no local, não será necessário alterar como você opera o cluster do Pacemaker.

Você pode usar até três dispositivos SBD para um cluster do Pacemaker para permitir que um dispositivo SBD fique indisponível (por exemplo, durante uma aplicação de patch do sistema operacional do servidor de destino iSCSI). Se quiser usar mais de um dispositivo SBD por Pacemaker, implante vários servidores de destino iSCSI e conecte um SBD de cada servidor de destino iSCSI. É recomendável usar um dispositivo SBD ou três. O Pacemaker não poderá limitar automaticamente um nó de cluster se apenas dois dispositivos SBD estiverem configurados e um deles estiver indisponível. Se você quiser garantir que o isolamento seja possível mesmo se um servidor de destino iSCSI falhar, você precisará usar três dispositivos SBD, o que significa implantar três servidores de destino iSCSI. Essa configuração fornece o alto nível de resiliência ao usar dispositivos SBD.

Importante

Quando estiver planejando e implantando nós clusterizados do Linux Pacemaker e dispositivos SBD, não permita que o roteamento entre suas máquinas virtuais e as VMs que hospedam os dispositivos SBD passem por outros dispositivos, como um NVA (dispositivo virtual de rede).

Eventos de manutenção e outros problemas com a NVA podem ter um efeito negativo sobre a estabilidade e a confiabilidade da configuração geral do cluster. Para obter mais informações, confira Regras de roteamento definidas pelo usuário.
SBD com um disco compartilhado do Azure:

Para configurar um dispositivo de SBD, você precisa anexar pelo menos um disco compartilhado do Azure a todas as máquinas virtuais que fazem parte do cluster do Pacemaker. A vantagem de o dispositivo SBD usar um disco compartilhado do Azure é que você não precisa implantar máquinas virtuais adicionais.

Veja algumas considerações importantes sobre os dispositivos SBD quando você está usando um disco compartilhado do Azure:
- Um disco compartilhado do Azure com SSD Premium tem suporte como um dispositivo SBD.
- Os dispositivos SBD que usam um disco compartilhado do Azure têm suporte no SLES de Alta Disponibilidade 15 SP01 e posteriores.
- Dispositivos SBD que usam um disco compartilhado Premium do Azure têm suporte no LRS (armazenamento com redundância local) e no ZRS (armazenamento com redundância de zona).
- Dependendo do tipo da sua implantação, escolha o armazenamento redundante apropriado de um disco compartilhado do Azure como seu dispositivo SBD.
- Um dispositivo SBD que usa LRS para o disco compartilhado Premium do Azure (skuName - Premium_LRS) só tem suporte com a implantação no conjunto de disponibilidade.
- Um dispositivo SBD que usa ZRS para um disco compartilhado Premium do Azure (skuName - Premium_ZRS) é recomendado com a implantação em zonas de disponibilidade.
- Um ZRS para disco gerenciado não está disponível em todas as regiões com zonas de disponibilidade. Para saber mais, confira a seção "Limitações" do ZRS em Opções de redundância para discos gerenciados.
- O disco compartilhado do Azure que você usa nos dispositivos SBD não precisa ser grande. O valor maxShares determina quantos nós de cluster podem usar o disco compartilhado. Por exemplo, você pode usar tamanhos de disco P1 ou P2 para o dispositivo SBD em um cluster de dois nós como o SAP ASCS/ERS ou o SAP HANA com escalonamento vertical.
- Para a expansão do HANA com HSR (replicação do sistema HANA) e Pacemaker, você pode usar um disco compartilhado do Azure para dispositivos SBD em clusters com até quatro nós por site de replicação, devido ao limite atual de maxShares.
- Não recomendamos anexar um dispositivo de SBD com disco compartilhado do Azure nos clusters do Pacemaker.
- Se você usa vários dispositivos SBD de disco compartilhado do Azure, verifique o limite para o número máximo de discos de dados que podem ser anexados a uma VM.
- Para obter mais informações sobre as limitações dos discos compartilhados do Azure, examine com atenção a seção "Limitações" da Documentação do disco compartilhado do Azure.

Usar um agente de limitação do Azure

Você pode configurar o isolamento usando um agente de isolamento do Azure. O agente de limitação do Azure requer identidades gerenciadas para as VMs do cluster ou uma entidade de serviço, que gerencia a reinicialização dos nós com falha pelas APIs do Azure. O agente de limitação do Azure não exige a implantação de máquinas virtuais adicionais.

SBD com um servidor de destino iSCSI

Para usar um dispositivo SBD que usa um servidor de destino iSCSI para limitação, siga as instruções nas próximas seções.

Configurar o servidor de destino iSCSI

Primeiro, você precisa criar as máquinas virtuais de destino iSCSI. Você pode compartilhar servidores de destino iSCSI com vários clusters do Pacemaker.

Implante novas máquinas virtuais SLES 12 SP3 ou superiores e conecte-se a eles por SSH. As máquinas não precisam ser grandes. Tamanhos de máquina virtual Standard_E2s_v3 ou Standard_D2s_v3 são suficientes. Use o armazenamento Premium para o disco do SO.
Nas máquinas virtuais de destino iSCSI, execute os seguintes comandos:

a. Atualizar o SLES.
```
sudo zypper update
```
Observação

Talvez seja necessário reinicializar o sistema operacional depois de fazer upgrade ou atualizar o sistema operacional.

b. Remover pacotes.

Para evitar um problema conhecido com targetcli e SLES 12 SP3, desinstale os pacotes a seguir. Você pode ignorar erros sobre pacotes que não podem ser encontrados.
```
sudo zypper remove lio-utils python-rtslib python-configshell targetcli
```
c. Instalar os pacotes de destino do iSCSI.
```
sudo zypper install targetcli-fb dbus-1-python
```
d. Habilitar o serviço de destino do iSCSI.
```
sudo systemctl enable targetcli
sudo systemctl start targetcli
```

Criar um dispositivo iSCSI no servidor de destino do iSCSI

Para criar os discos iSCSI para os clusters a serem usados por seu sistema SAP, execute os comandos a seguir em todas as máquinas virtuais de destino do iSCSI. No exemplo, são criados dispositivos SBD para vários clusters. Ele mostra como você usaria um servidor de destino do iSCSI para vários clusters. Os dispositivos SBD são colocados no disco do SO. Certifique-se de que você tenha espaço suficiente.

nfs: identifica o cluster NFS.
ascsnw1: identifica o cluster ASCS do NW1.
dbnw1: identifica o cluster de banco de dados do NW1.
nfs-0 e nfs-1: os nomes de host dos nós do cluster NFS.
nw1-xscs-0 e nw1-xscs-1: os nomes de host dos nós do cluster ASCS do NW1.
nw1-db-0 e nw1-db-1: os nomes de host dos nós de cluster do banco de dados.

Nas instruções a seguir, atualize os nomes de host dos nós de cluster e o SID do sistema SAP.

Crie a pasta raiz para todos os dispositivos SBD.
```
sudo mkdir /sbd
```

Crie o dispositivo SBD para o servidor 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

Crie o dispositivo SBD para o servidor ASCS do 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

Crie o dispositivo SBD para o cluster de banco de dados do 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

Salve as alterações de targetcli.
```
sudo targetcli saveconfig
```

Verifique se tudo foi configurado corretamente.

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]

Configurar o dispositivo SBD do servidor de destino iSCSI

Conecte-se ao dispositivo iSCSI criado na última etapa do cluster. Execute os comandos a seuir nos nós do novo cluster que você deseja criar.

Observação

[A]: aplica-se a todos os nós.
[1]: aplica-se somente ao nó 1.
[2]: aplica-se somente ao nó 2.

[A] Instalar o pacote iSCSI.
```
sudo zypper install open-iscsi
```

[A] Conecte-se aos dispositivos iSCSI. Primeiro, habilite o iSCSI e os serviços SBD.

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

[1] Altere o nome do iniciador no primeiro nó.
```
sudo vi /etc/iscsi/initiatorname.iscsi
```
[1] Altere o conteúdo do arquivo para corresponder às ACLs (listas de controle de acesso) que você usou ao criar o dispositivo iSCSI no servidor de destino do iSCSI (por exemplo, para o servidor NFS).
```
InitiatorName=iqn.2006-04.nfs-0.local:nfs-0
```
[2] Altere o nome do iniciador no segundo nó.
```
sudo vi /etc/iscsi/initiatorname.iscsi
```
[2] Altere o conteúdo do arquivo para corresponder às ACLs que você usou ao criar o dispositivo iSCSI no servidor de destino do iSCSI.
```
InitiatorName=iqn.2006-04.nfs-1.local:nfs-1
```

[A] Reinicie o serviço do iSCSI para aplicar a alteração.

sudo systemctl restart iscsid
sudo systemctl restart iscsi

[A] Conecte os dispositivos iSCSI. No exemplo a seguir, 10.0.0.17 é o endereço IP do servidor de destino do iSCSI e 3260 é a porta padrão. iqn.2006-04.nfs.local:nfs é um dos nomes de destino listado quando você executa o primeiro 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

[A] Se quiser usar vários dispositivos SBD, conecte-se também ao segundo servidor de destino do 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

[A] Se quiser usar vários dispositivos SBD, conecte-se também ao terceiro servidor de destino do 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

[A] Certifique-se de que os dispositivos iSCSI estejam disponíveis e anote o nome do dispositivo (/dev/sde no exemplo a seguir).

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

[A] Recupere as IDs dos dispositivos 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

O comando lista três IDs de dispositivo para cada dispositivo SBD. É recomendável usar a ID que começa com scsi-3. No exemplo anterior, as IDs são:

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

[1] Crie o dispositivo SBD.

a. Use a ID do dispositivo dos dispositivos iSCSI para criar os novos dispositivos SBD no primeiro nó do cluster.

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

b. Crie também o segundo e o terceiro dispositivos SBD se quiser usar mais de um.

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

[A] Adapte a configuração do SBD.

a. Abra o arquivo de configuração do SBD.
```
sudo vi /etc/sysconfig/sbd
```
b. Altere a propriedade do dispositivo SBD, habilite a integração do Pacemaker e altere o modo de início de SBD. Além disso, ajuste o valor SBD_DELAY_START, se necessário
```
[...]
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"
[...]
```
Observação

Se o valor da propriedade SBD_DELAY_START for definido como "no" ou "yes", atualize-o para um valor de atraso específico, em segundos. Para obter mais informações, consulte a seção Configuration via environment no manual man sbd.

c. Verifique se o valor TimeoutStartSec no arquivo de serviço SBD é maior que o valor de SBD_DELAY_START. Consulte a documentação de configuração de arquivo SBD para obter detalhes.
```
sudo systemctl show sbd | grep -i Timeout
# TimeoutStartUSec=4min 19s
# TimeoutStopUSec=4min 19s
# TimeoutAbortUSec=4min 19s
```
Se o valor for padrão (90 segundos) ou for definido menos de SBD_DELAY_START, siga as etapas para ajustar o valor.
```
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
```
Observação

No novo build do cluster, os valores SBD_DELAY_START e TimeoutStartSec são definidos automaticamente.

Na configuração de cluster existente, o valor de SBD_DELAY_START pode ser definido como "no" ou "yes" e TimeoutStartSec seria diferente. A atualização da versão do SLES não atualiza o valor, portanto, você precisará ajustar essas configurações manualmente.

[A] Crie o arquivo de configuração softdog.

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

[A] Carregue o módulo.
```
sudo modprobe -v softdog
```

SBD com um disco compartilhado do Azure

Esta seção se aplica somente quando você quer usar um dispositivo SBD com um disco compartilhado do Azure.

Criar e anexar um disco compartilhado do Azure com o PowerShell

Para criar e anexar um disco compartilhado do Azure com o PowerShell, execute as instruções a seguir. Se quiser implantar recursos usando a CLI do Azure ou o portal do Azure, consulte Implantar um 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
}

Configurar um dispositivo SBD de disco compartilhado do Azure

[A] Habilitar os serviços SBD.
```
sudo systemctl enable sbd
```

[A] Certifique-se de que o disco anexado esteja disponível.

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

[A] Recupere as IDs dos discos anexados.

# 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

Os comandos listam as IDs do dispositivo SBD. É recomendável usar a ID que começa com scsi-3. No exemplo anterior, a ID é /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19.

[1] Crie o dispositivo SBD.

Use a ID do dispositivo da etapa 2 para criar os novos dispositivos SBD no primeiro nó do cluster.
```
# sudo sbd -d /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 -1 60 -4 120 create
```
[A] Adapte a configuração do SBD.

a. Abra o arquivo de configuração do SBD.
```
sudo vi /etc/sysconfig/sbd
```
b. Altere a propriedade do dispositivo SBD, habilite a integração do Pacemaker e altere o modo de início de SBD. Além disso, ajuste o valor SBD_DELAY_START, se necessário
```
[...]
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"
[...]
```
Observação

Se o valor da propriedade SBD_DELAY_START estiver definido como "no" ou "yes", atualize-o para um valor de atraso específico, em segundos. Para obter mais informações, consulte a seção Configuration via environment no manual man sbd.

c. Verifique se o valor TimeoutStartSec no arquivo de serviço SBD é maior que o valor de SBD_DELAY_START. Consulte a documentação de configuração de arquivo SBD para obter detalhes.
```
sudo systemctl show sbd | grep -i Timeout
# TimeoutStartUSec=4min 19s
# TimeoutStopUSec=4min 19s
# TimeoutAbortUSec=4min 19s
```
Se o valor for padrão (90 segundos) ou for definido menos de SBD_DELAY_START, siga as etapas para ajustar o valor.
```
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
```
Observação

No novo build do cluster, os valores SBD_DELAY_START e TimeoutStartSec são definidos automaticamente.

Na configuração de cluster existente, o valor de SBD_DELAY_START pode ser definido como "no" ou "yes" e TimeoutStartSec seria diferente. A atualização da versão do SLES não atualiza o valor, portanto, você precisa ajustar essas configurações manualmente.

Crie o arquivo de configuração softdog.

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

Carregue o módulo.
```
sudo modprobe -v softdog
```

Usar um agente de limitação do Azure

Esta seção se aplica somente quando você quer usar um dispositivo de isolamento com um agente de isolamento do Azure.

Criar um dispositivo do agente de isolamento do Azure

Esta seção se aplicará somente se você estiver usando o agente de isolamento do Azure como um dispositivo de isolamento. O agente de isolamento do Azure usa uma identidade gerenciada ou uma entidade de serviço para autorização no Microsoft Azure.

Identidade gerenciada
Entidade de serviço

Para criar uma MSI (identidade gerenciada), crie uma identidade gerenciada atribuída pelo sistema para cada VM no cluster. Se uma identidade gerenciada atribuída pelo sistema já estiver habilitada, ela será usada. As identidades gerenciadas atribuídas pelo usuário não devem ser usadas com o Pacemaker no momento. O agente de isolamento do Azure, com base na identidade gerenciada, tem suporte para SLES 12 SP5 e SLES 15 SP1 e superiores.

Para criar uma entidade de serviço, faça o seguinte:

No portal do Azure, selecione Propriedades>Microsoft Entra ID, e anote a ID do Diretório. Essa é a ID de locatário.
Selecione Registros do Aplicativo.
Selecione Novo registro.
Insira um nome de registro e selecione Contas apenas neste diretório de organização.
Quanto ao Tipo de aplicativo, selecione Web, insira uma URL de logon (por exemplo, http://localhost) e selecione Adicionar.
A URL de logon não é usada e pode ser qualquer URL válida.
Selecione Certificados e segredos e Novo segredo do cliente.
Insira uma descrição para uma nova chave, selecione Dois anos e selecione Adicionar.
Anote o valor, que você usará como a senha da entidade de serviço.
Selecione Visão geral e anote a ID do aplicativo, que você usará como nome de usuário da entidade de serviço.

[1] Criar uma função personalizada para o agente de isolamento

Por padrão, nem a identidade gerenciada nem a entidade de serviço têm permissões para acessarem seus recursos do Azure. Você precisa fornecer as permissões da identidade gerenciada ou da entidade de serviço para iniciar e parar (desalocar) todas as máquinas virtuais do cluster. Se você ainda não criou a função personalizada, pode criá-la usando o PowerShell ou CLI do Azure.

Use o seguinte conteúdo para o arquivo de entrada. Você precisa adaptar o conteúdo às suas assinaturas. Isto é, substitua xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx e yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy com suas próprias IDs de assinatura. Se tiver apenas uma assinatura, remova a segunda entrada em 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] Atribuir a função personalizada

Use a identidade gerenciada ou a entidade de serviço.

Identidade gerenciada
Entidade de serviço

Atribua a função personalizada “Função do Agente de Limitação Linux" que foi criada no último capítulo para cada identidade gerenciada das VMs do cluster. Cada identidade gerenciada atribuída pelo sistema da VM precisa da função atribuída para o recurso de cada VM de cluster. Para obter etapas detalhadas, confira Atribuir o acesso de uma identidade gerenciada a um recurso usando o portal do Azure. Verifique se a atribuição de função de identidade gerenciada de cada VM contém todas as VMs do cluster.

Importante

Lembre-se de que a atribuição e a remoção da autorização com identidades gerenciadas podem ser adiadas até que elas entrem em vigor.

Instalar o cluster

Observação

[A]: aplica-se a todos os nós.
[1]: aplica-se somente ao nó 1.
[2]: aplica-se somente ao nó 2.

[A] Atualize o SLES.
```
sudo zypper update
```
Observação

Para o SLES 15 SP4, verifique as versões dos pacotes do crmsh e do pacemaker para garantir que atendam aos requisitos mínimos de versão:
- crmsh-4.4.0+20221028.3e41444-150400.3.9.1 ou posterior
- pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 ou posterior
Importante
- SLES 12 SP5: se o python-azure-core-1.23.1-2.12.8 estiver instalado, o agente de isolamento do Azure poderá falhar ao ser iniciado em um cluster do Pacemaker, exibindo a mensagem de erro "SDK do Python do Azure Resource Manager não encontrado ou não acessível" em /var/log/messages. Siga as instruções do SUSE KBA 21532 para obter mais detalhes.
- SLES 15 SP4+: após uma atualização do sistema operacional, as bibliotecas do Azure para Python talvez usem o interpretador do Python 3.11, fazendo com que o agente de isolamento do Azure falhe ao ser iniciado em um cluster do Pacemaker. A mensagem de erro "SDK do Python do Azure Resource Manager não encontrado ou não acessível" irá aparecer em /var/log/messages. Siga as instruções do SUSE KBA 21504 para obter mais detalhes.
[A] Instale o componente que você precisa para os recursos do cluster.
```
sudo zypper in socat
```
[A] Instale o componente azure-lb que você precisa para os recursos do cluster.
```
sudo zypper in resource-agents
```
Observação

Verifique a versão do pacote resource-agents e verifique se os requisitos mínimos de versão foram atendidos:
- SLES 12 SP4/SP5: a versão deve ser resource-agents-4.3.018.a7fb5035-3.30.1 ou posterior.
- SLES 15/15 SP1: a versão deve ser resource-agents-4.3.0184.6ee15eb2-4.13.1 ou posterior.
[A] Configure o sistema operacional.

a. Ocasionalmente, o Pacemaker cria muitos processos, o que pode esgotar o número permitido. Quando isso acontece, uma pulsação entre os nós de cluster pode falhar e levar a um failover de seus recursos. Recomendamos aumentar o máximo de processos permitidos definindo o seguinte parâmetro:
```
# 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. Reduza o tamanho do cache sujo. Para obter mais informações, consulte Baixo desempenho de gravação em servidores SLES 11/12 com RAM grande.
```
sudo vi /etc/sysctl.conf
# Change/set the following settings
vm.dirty_bytes = 629145600
vm.dirty_background_bytes = 314572800
```
c. Verifique se vm.swapiness está definido como 10 para reduzir o uso de troca e favorecer a memória.
```
sudo vi /etc/sysctl.conf
# Change/set the following setting
vm.swappiness = 10
```
[A] Verifique a versão do pacote cloud-netconfig-azure.

Verifique a versão instalada do pacote cloud-netconfig-azure executando zypper info cloud-netconfig-azure. Se a versão for inferior à 1.3, recomendamos que você atualize o pacote cloud-netconfig-azure para a versão mais recente disponível.

Dica

Se a versão em seu ambiente for 1.3 ou superior, não será mais necessário suprimir o gerenciamento de adaptadores de rede pelo plug-in de rede de nuvem.

Somente se a versão do cloud-netconfig-azure for inferior a 1,3, altere o arquivo de configuração para o adaptador de rede, conforme mostrado no código a seguir, para impedir que o plug-in de rede de nuvem remova o endereço de IP virtual (o Pacemaker deve controlar a atribuição). Para obter mais informações, confira SUSE KB 7023633.
```
# Edit the configuration file
sudo vi /etc/sysconfig/network/ifcfg-eth0 

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

[1] Habilite o acesso 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

[2] Habilite o acesso 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

[1] Habilite o acesso 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

[A] Instale o pacote fence-agents se estiver usando um dispositivo de isolamento com base no agente de isolamento do Azure.
```
sudo zypper install fence-agents
```
Importante

A versão instalada do pacote fence-agents deve ser pelo menos a 4.4.0 para beneficiar-se dos tempos de failover mais rápidos com o agente de limitação do Azure quando um nó de cluster precisa ser isolado. Se estiver executando uma versão anterior, recomendamos que você atualize o pacote.
Importante

Se estiver usando a identidade gerenciada, a versão instalada do pacote fence-agent deverá ser -
- SLES 12 SP5: fence-agents 4.9.0+git.1624456340.8d746be9-3.35.2 ou posterior
- SLES 15 SP1 e superior: fence-agents 4.5.2+git.1592573838.1eee0863 ou posterior.
As versões anteriores não funcionam corretamente com uma configuração de identidade gerenciada.

[A] Instalar o pacote fence-agents-azure-arm.

Para o SLES 12 SP5, se você estiver usando fence-agents a versão 4.9.0+git.1624456340.8d746be9-3.41.3 ou posterior e para o SLES 15 SP4 e mais recente, será necessário instalar o fence-agents-azure-arm pacote. Esse pacote inclui todas as dependências necessárias.

# 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

[A] Instale o SDK do Python do Azure e o módulo Python do Azure Identity.

Para SLES 12 SP5, se sua fence-agents versão for menor que 4.9.0+git.1624456340.8d746be9-3.41.3, e para SLES 15 SP3 ou inferior, você precisará instalar os pacotes adicionais abaixo.
```
# 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

Dependendo de sua versão e tipo de imagem, talvez seja necessário ativar a extensão de nuvem pública para sua versão do sistema operacional antes de instalar o SDK do Python do Azure. Você pode verificar a extensão executando SUSEConnect ---list-extensions. Para atingir tempos de failover mais rápidos com o agente de limitação do Azure:
- No SLES 12 SP5, instale a versão 4.6.2 ou posterior do pacote python-azure-mgmt-compute.
- Se sua versão do pacote python-azure-mgmt-compute ou python3-azure-mgmt-compute for 17.0.0-6.7.1, siga as instruções no SUSE KBA para atualizar a versão dos agentes de limitação e instalar a biblioteca de clientes de Identidade do Azure para o módulo do Python se ela estiver ausente.
[A] Configurar a resolução do nome do host.

É possível usar um servidor DNS ou modificar o arquivo /etc/hosts em todos os nós. Este exemplo mostra como usar o arquivo /etc/hosts.

Substitua o endereço IP e o nome do host nos comandos a seguir.

Importante

Se você está usando nomes de host na configuração do cluster, é essencial ter uma resolução de nome de host confiável. A comunicação do cluster falhará se os nomes não estiverem disponíveis e isso poderá levar a atrasos de failover de cluster.

A vantagem de usar /etc/hosts é que o cluster se torna independente do DNS, o que também pode ser um ponto único de falha.
```
sudo vi /etc/hosts
```
Insira as linhas a seguir no arquivo /etc/hosts. Altere o endereço IP e o nome do host para corresponder ao seu 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
```

[1] Instale o cluster.

Se estiver usando dispositivos SBD para limitação (para o servidor de destino do iSCSI ou o disco compartilhado do 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 não estiver usando dispositivos SBD para limitação:

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

[2] Adicione o nó ao 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

[A] Altere a senha de hacluster para a mesma senha.
```
sudo passwd hacluster
```

[A] Ajuste as configurações de corosync.

sudo vi /etc/corosync/corosync.conf

a. Verifique a seção a seguir no arquivo e ajuste se os valores não estiverem lá ou forem diferentes. Altere o token para 30000 para permitir a manutenção com preservação da memória. Para obter mais informações, confira o artigo "Manutenção para máquinas virtuais no Azure" para Linux ou 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. Reinicie o serviço corosync.

sudo service corosync restart

Criar um dispositivo de isolamento no cluster do Pacemaker

Dica

Para evitar corridas de cerca dentro de um cluster de pacemaker de dois nós, você pode configurar a propriedade de cluster "priority-fencing-delay" adicional. Essa propriedade introduz um atraso adicional no isolamento de um nó que tem maior prioridade total de recursos quando ocorre um cenário de partição de rede. Para obter mais informações, confira o guia de administração de extensão de alta disponibilidade do SUSE Linux Enterprise Server.
A propriedade priority-fencing-delay só é aplicável ao cluster de dois nós. A instrução sobre como definir a propriedade de cluster "priority-fencing-delay" pode ser encontrada nos respectivos SAP ASCS/ERS (aplicável somente no ENSA2) e no documento de alta disponibilidade do SAP HANA.
Ao configurar um cluster para expansão do HANA, não defina a propriedade pcmk_delay_max no recurso Stonith do SBD.

[1] Se você estiver usando um dispositivo SBD (servidor de destino iSCSI ou disco compartilhado do Azure) como um dispositivo de isolamento, execute os comandos a seguir. Permita o uso de um dispositivo de isolamento e defina o atraso de 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"

[1] Se estiver usando um agente de isolamento do Azure para isolamento, execute os comandos a seguir. Depois de atribuir funções aos nós de cluster, você pode configurar os dispositivos de isolamento no cluster.
```
sudo crm configure property stonith-enabled=true
sudo crm configure property concurrent-fencing=true
```
Observação

A opção 'pcmk_host_map' é necessária no comando somente quando os nomes do host e os nomes da VM do Azure não são idênticos. Especifique o mapeamento no formato nome do host: vm-name.

Identidade gerenciada
Entidade de serviço

# 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

# Adjust the command with your subscription ID, resource group of the VM, tenant ID, service principal application ID and password

sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm \
params subscriptionId="subscription ID" resourceGroup="resource group" tenantId="tenant ID" login="application ID" passwd="password" \
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 você estiver usando o dispositivo de isolamento, com base na configuração da entidade de serviço, leia Alterar de SPN para MSI para clusters do Pacemaker usando o isolamento do Azure e saiba como converter em configuração de identidade gerenciada.

Importante

As operações de monitoramento e limitação são desserializadas. Como resultado, se houver uma operação de monitoramento de execução longa e um evento de limitação simultâneo, não haverá atraso no failover do cluster, porque a operação de monitoramento já estará em execução.

Dica

O agente de limitação do Azure requer conectividade de saída para pontos de extremidade públicos, conforme documentado, juntamente com soluções possíveis, em Conectividade de ponto de extremidade pública para VMs usando o ILB padrão.

Configurar o Pacemaker para eventos agendados do Azure

O Azure oferece eventos agendados. Os eventos agendados são fornecidos pelo serviço de metadados e permitem tempo para o aplicativo se preparar para esses eventos.

O agente de recursos dos monitores azure-events-az para eventos agendados do Azure. Se os eventos forem detectados e o agente de recursos determinar que outro nó de cluster está disponível, ele definirá um atributo de integridade #health-azure no nível do nó como -1000000.

Quando esse atributo de integridade de cluster especial é definido para um nó, o nó é considerado não íntegro pelo cluster e todos os recursos são migrados para longe do nó afetado. A restrição de local garante que recursos com o nome começando com "health-" sejam excluídos, pois o agente precisa ser executado nesse estado não íntegro. Depois que o nó de cluster afetado estiver livre da execução de recursos de cluster, o evento agendado poderá executar a sua ação, como reiniciar, sem risco para os recursos em execução.

O atributo #heath-azure é definido novamente como 0 na inicialização do pacemaker depois que todos os eventos são processados, marcando o nó como íntegro novamente.

Importante

Anteriormente, este documento descrevia o uso do agente de recursos azure-events. O novo agente de recursos azure-events-az oferece suporte total aos ambientes do Azure implantados em diferentes zonas de disponibilidade. É recomendável usar o agente azure-events-az mais recente em todos os sistemas SAP altamente disponíveis com o Pacemaker.

[A] Verifique se o pacote do agente azure-events já está instalado e atualizado.
```
sudo zypper info resource-agents
```
Requisitos mínimos da versão:
- 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 mais recente: resource-agents-4.10.0+git40.0f4de473-150400.3.19.1

[1] Configure os recursos no Pacemaker.

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

[1] Definir a estratégia e a restrição do nó de integridade do cluster do pacemaker
```
sudo crm configure property node-health-strategy=custom
sudo crm configure location loc_azure_health \
/'!health-.*'/ rule '#health-azure': defined '#uname'
```
Importante

Não defina outros recursos no cluster começando com "health-", além dos recursos descritos nas próximas etapas da documentação.
[1] Definir o valor inicial dos atributos do cluster. Execute para cada nó do cluster. Para os ambientes de expansão, incluindo a VM da maioria dos fabricantes.
```
sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0
sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0
```
[1] Configure os recursos no Pacemaker. Importante: os recursos devem começar com '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
```
Observação

Ao configurar o recurso "health-azure-events", a mensagem de aviso a seguir pode ser ignorada.

AVISO: health-azure-events: atributo 'allow-unhealthy-nodes' desconhecido.

Tirar o cluster do Pacemaker do modo de manutenção

sudo crm configure property maintenance-mode=false

Limpe os erros durante a habilitação e verifique se os recursos de eventos de integridade do azure foram iniciados com êxito em todos os nós do cluster.
```
sudo crm resource cleanup
```
A primeira execução de consulta para eventos programados pode levar até 2 minutos. Os testes do Pacemaker com eventos agendados podem usar ações de reinicialização ou reimplantação nas VMs do cluster. Para obter mais informações, consulte a documentaçãoeventos agendados.

Observação

Depois de ter configurado os recursos do Pacemaker para o agente azure-events, se você colocar ou tirar o cluster do modo de manutenção, poderá receber mensagens de aviso como:

AVISO: cib-bootstrap-options: atributo 'hostName_ hostname' desconhecido
AVISO: cib-bootstrap-options: atributo desconhecido 'azure-events_globalPullState'
AVISO: cib-bootstrap-options: atributo desconhecido 'hostName_ hostname'
Essas mensagens de aviso podem ser ignoradas.

Próximas etapas

Planejamento e implementação de Máquinas Virtuais do Azure para o SAP.
Implantação de Máquinas Virtuais do Azure para SAP.
Implantação do DBMS de Máquinas Virtuais do Azure para SAP.
Alta disponibilidade para NFS em VMs do Azure no SUSE Linux Enterprise Server.
Alta disponibilidade do SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server para aplicativos SAP.
Para saber como estabelecer a alta disponibilidade e o plano de recuperação de desastre do SAP HANA em VMs do Azure, consulte Alta disponibilidade do SAP HANA em Máquinas Virtuais do Azure.

Comentários

Esta página foi útil?

Last updated on 2026-01-07

Compartilhar via

Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure

Visão geral

Usar um dispositivo SBD

Usar um agente de limitação do Azure

SBD com um servidor de destino iSCSI

Configurar o servidor de destino iSCSI

Criar um dispositivo iSCSI no servidor de destino do iSCSI

Configurar o dispositivo SBD do servidor de destino iSCSI

SBD com um disco compartilhado do Azure

Criar e anexar um disco compartilhado do Azure com o PowerShell

Configurar um dispositivo SBD de disco compartilhado do Azure

Usar um agente de limitação do Azure

Criar um dispositivo do agente de isolamento do Azure

[1] Criar uma função personalizada para o agente de isolamento

[A] Atribuir a função personalizada

Instalar o cluster

Criar um dispositivo de isolamento no cluster do Pacemaker

Configurar o Pacemaker para eventos agendados do Azure

Próximas etapas

Comentários

Recursos adicionais