Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure

Artigo
04/08/2024

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 quiser ser capaz de limitar quando um servidor de destino iSCSI estiver inativo, você precisará usar três dispositivos SBD e, portanto, três servidores de destino iSCSI. Essa é a configuração mais resiliente quando você está usando SBDs.

Importante

Quando estiver planejando e implantando nós clusterizados do Pacemaker o e dispositivos SBD no Linux, não permita o roteamento entre suas máquinas virtuais e as VMs que estão hospedando os dispositivos SBD passe por outros dispositivos, como uma NVA (solução de virtualização de rede).

Eventos de manutenção e outros problemas com a NVA poderão ter impacto negativo na estabilidade e 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 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 SBD de disco compartilhado do Azure entre 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, substitua ajustar 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.
```
[...]
SBD_DEVICE="/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]
```
Observação

Se o valor da propriedade SBD_DELAY_START for definido como "não", altere o valor para "sim". Você também deve verificar o arquivo de serviço SBD para garantir que o valor de TimeoutStartSec seja maior que o valor de SBD_DELAY_START. Para obter mais informações, consulte Configuração do arquivo SBD

[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

Ajuste os valores de seu grupo de recursos, região do Azure, máquinas virtuais, LUNs (números de unidade lógica) e assim por diante.
```
$ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"
```
Defina o tamanho do disco com base no tamanho de disco disponível para SSDs Premium. Neste exemplo, o tamanho de disco P1 de 4G é mencionado.
```
$DiskSizeInGB = 4
$DiskName = "SBD-disk1"
```
Com o parâmetro -MaxSharesCount, defina o número máximo de nós de cluster para anexar o disco compartilhado para o dispositivo SBD.
```
$ShareNodes = 2
```
Para um dispositivo SBD que usa LRS para um disco compartilhado Premium do Azure, use o seguinte SkuName de armazenamento:
```
$SkuName = "Premium_LRS"
```
Para um dispositivo SBD que usa ZRS para um disco compartilhado Premium do Azure, use o seguinte SkuName de armazenamento:
```
$SkuName = "Premium_ZRS"
```

Configure um disco compartilhado do Azure.

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

Anexe o disco às VMs do cluster.

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

a. Adicione o disco compartilhado do Azure ao nó de cluster 1.

$vm = Get-AzVM -ResourceGroupName $ResourceGroup -Name $VM1
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroup -Verbose

b. Adicione o disco compartilhado do Azure ao nó de cluster 2.

$vm = Get-AzVM -ResourceGroupName $ResourceGroup -Name $VM2
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroup -Verbose

Se quiser implantar recursos usando a CLI do Azure ou o portal do Azure, consulte Implantar um disco ZRS.

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 do dispositivo SBD.
```
[...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]
```
Observação

Se o valor da propriedade SBD_DELAY_START for definido como "não", altere o valor para "sim". Você também deve verificar o arquivo de serviço SBD para garantir que o valor de TimeoutStartSec seja maior que o valor de SBD_DELAY_START. Para obter mais informações, consulte Configuração do arquivo SBD

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 aplica somente quando você está usando um dispositivo baseado em um agente de isolamento do Azure. O dispositivo de isolamento 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á existir, 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

No SLES 15 SP4, verifique a versão do pacote crmsh e pacemaker, e certifique-se que os requisitos mínimos da versão sejam atendidos:
- crmsh-4.4.0+20221028.3e41444-150400.3.9.1 ou posterior
- pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 ou posterior
[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 funcionarão corretamente com uma configuração de identidade gerenciada.
[A] Instale o SDK do Python do Azure e o módulo Python do Azure Identity.

Instale o SDK do Python do Azure no SLES 12 SP4 ou SLES 12 SP5:
```
# You might need to activate the public cloud extension first
SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper install python-azure-mgmt-compute
sudo zypper install python-azure-identity
```
Instale o SDK do Python do Azure no SLES 15 ou posterior:
```
# 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 SP4 ou no SLES 12 SP5, instale a versão 4.6.2 ou superior do pacote python-azure-mgmt-compute.
- Se sua versão do 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 do de Identidade do Azure para o módulo do Python se ela estiver ausente.
[A] Configure 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 pode 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 uma prioridade total de recursos mais alta quando ocorre um cenário de split-brain. Para obter mais detalhes, consulte Guia de administração de extensão de alta disponibilidade do SUSE Linux Enterprise Server.
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.

[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=144
sudo crm configure property stonith-enabled=true

# List the resources to find the name of the SBD device
sudo crm resource list
sudo crm resource stop stonith-sbd
sudo crm configure delete stonith-sbd
sudo crm configure primitive stonith-sbd stonith:external/sbd \
   params pcmk_delay_max="15" \
   op monitor interval="600" timeout="15"

[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" \
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" \
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 do cluster. Quando o atributo de integridade do cluster é definido para um nó, a restrição de local dispara e todos os recursos, cujo nome não começa com "health-", são migrados para longe do nó com o evento agendado. Depois que o nó de cluster afetado estiver livre dos recursos de cluster em execução, o evento agendado será reconhecido e poderá executar sua ação, como reiniciar.

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 allow-unhealthy-nodes=true failure-timeout=120s \ 
op start start-delay=90s \ 
op monitor interval=10s

sudo crm configure clone health-azure-events-cln health-azure-events
```
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 do 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

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

Recursos adicionais