Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure

Artigo
04/08/2024

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

Descrição geral

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

Usar um dispositivo SBD

Você pode configurar o dispositivo SBD usando uma das duas opções:

SBD com um servidor de destino iSCSI:

O dispositivo SBD requer pelo menos uma máquina virtual (VM) adicional que atua como um servidor de destino iSCSI (Internet Small Computer System Interface) e fornece um dispositivo SBD. No entanto, esses servidores de destino iSCSI podem ser compartilhados com outros clusters Pacemaker. A vantagem de usar um dispositivo SBD é que, se você já estiver usando dispositivos SBD localmente, eles não exigirão nenhuma alteração na forma como você opera o cluster Pacemaker.

Você pode usar até três dispositivos SBD para um cluster Pacemaker para permitir que um dispositivo SBD fique indisponível (por exemplo, durante a aplicação de patches do sistema operacional do servidor de destino iSCSI). Se você quiser usar mais de um dispositivo SBD por marcapasso, certifique-se de implantar vários servidores de destino iSCSI e conectar um SBD de cada servidor de destino iSCSI. Recomendamos o uso de um dispositivo SBD ou três. O Pacemaker não pode cercar automaticamente um nó de cluster se apenas dois dispositivos SBD estiverem configurados e um deles não estiver disponível. Se você quiser ser capaz de cercar quando um servidor de destino iSCSI está inativo, você tem que 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

Ao planejar e implantar nós clusterizados Linux Pacemaker e dispositivos SBD, não permita que o roteamento entre suas máquinas virtuais e as VMs que hospedam os dispositivos SBD passe por quaisquer outros dispositivos, como um dispositivo virtual de rede (NVA).

Eventos de manutenção e outros problemas com o NVA podem ter um impacto negativo na estabilidade e confiabilidade da configuração geral do cluster. Para obter mais informações, consulte 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 Pacemaker. A vantagem do dispositivo SBD usando um disco compartilhado do Azure é que você não precisa implantar máquinas virtuais adicionais.

Aqui estão algumas considerações importantes sobre dispositivos SBD quando você estiver usando um disco compartilhado do Azure:
- Um disco compartilhado do Azure com SSD Premium é suportado como um dispositivo SBD.
- Os dispositivos SBD que usam um disco compartilhado do Azure têm suporte no SLES High Availability 15 SP01 e posterior.
- Os dispositivos SBD que usam um disco compartilhado premium do Azure têm suporte no armazenamento com redundância local (LRS) e no armazenamento com redundância de zona (ZRS).
- Dependendo do tipo de sua implantação, escolha o armazenamento redundante apropriado para um disco compartilhado do Azure como seu dispositivo SBD.
- Um dispositivo SBD usando LRS para disco compartilhado premium do Azure (skuName - Premium_LRS) só é suportado com a implantação no conjunto de disponibilidade.
- Um dispositivo SBD usando ZRS para um disco compartilhado premium do Azure (skuName - Premium_ZRS) é recomendado com implantação em zonas de disponibilidade.
- Um ZRS para disco gerenciado está atualmente indisponível em todas as regiões com zonas de disponibilidade. Para obter mais informações, consulte a seção "Limitações" do ZRS em Opções de redundância para discos gerenciados.
- O disco compartilhado do Azure que você usa para 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 seu dispositivo SBD em cluster de dois nós, como SAP ASCS/ERS ou SAP HANA scale-up.
- Para expansão do HANA com replicação do sistema HANA (HSR) e Pacemaker, você pode usar um disco compartilhado do Azure para dispositivos SBD em clusters com até quatro nós por local de replicação devido ao limite atual de maxShares.
- Não recomendamos anexar um dispositivo SBD de disco compartilhado do Azure em clusters Pacemaker.
- Se você usar vários dispositivos SBD de disco compartilhado do Azure, verifique o limite para um número máximo de discos de dados que podem ser anexados a uma VM.
- Para obter mais informações sobre limitações para discos compartilhados do Azure, examine cuidadosamente a seção "Limitações" da documentação de disco compartilhado do Azure.

Usar um agente de cerca do Azure

Você pode configurar a cerca usando um agente de cerca do Azure. O agente de cerca do Azure requer identidades gerenciadas para as VMs de cluster ou uma entidade de serviço que gerencia a reinicialização de nós com falha por meio de APIs do Azure. O agente de cerca do Azure não requer 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 cerca, 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 Pacemaker.

Implante novas máquinas virtuais SLES 12 SP3 ou superior e conecte-se a elas via SSH. As máquinas não precisam ser grandes. Os tamanhos Standard_E2s_v3 ou Standard_D2s_v3 das máquinas virtuais são suficientes. Certifique-se de usar o armazenamento Premium para o disco do sistema operacional.
Em máquinas virtuais de destino iSCSI, execute os seguintes comandos:

a. Atualize o SLES.
```
sudo zypper update
```
Nota

Talvez seja necessário reiniciar o sistema operacional depois de atualizá-lo.

b. Remova os pacotes.

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

Criar um dispositivo iSCSI no servidor de destino iSCSI

Para criar os discos iSCSI para os clusters a serem usados pelos sistemas SAP, execute os seguintes comandos em todas as máquinas virtuais de destino iSCSI. No exemplo, dispositivos SBD para vários clusters são criados. Ele mostra como você usaria um servidor de destino iSCSI para vários clusters. Os dispositivos SBD são colocados no disco do sistema operacional. Certifique-se de que tem 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 de cluster NFS.
nw1-xscs-0 e nw1-xscs-1: Os nomes de host dos nós de cluster NW1 ASCS.
nw1-db-0 e nw1-db-1: Os nomes de host dos nós do cluster de banco de dados.

Nas instruções a seguir, substitua ajustar os nomes de host dos nós do 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 SAP System NW1.

sudo targetcli backstores/fileio create sbdascsnw1 /sbd/sbdascsnw1 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.ascsnw1.local:ascsnw1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/luns/ create /backstores/fileio/sbdascsnw1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-0.local:nw1-xscs-0
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-1.local:nw1-xscs-1

Crie o dispositivo SBD para o cluster de banco de dados do SAP System NW1.

sudo targetcli backstores/fileio create sbddbnw1 /sbd/sbddbnw1 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.dbnw1.local:dbnw1
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/luns/ create /backstores/fileio/sbddbnw1
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/acls/ create iqn.2006-04.nw1-db-0.local:nw1-db-0
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/acls/ create iqn.2006-04.nw1-db-1.local:nw1-db-1

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 que você criou na última etapa do cluster. Execute os seguintes comandos nos nós do novo cluster que você deseja criar.

Nota

[R]: Aplica-se a todos os nós.
[1]: Aplica-se apenas ao nó 1.
[2]: Aplica-se apenas ao nó 2.

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

[A] Conecte-se aos dispositivos iSCSI. Primeiro, habilite os serviços iSCSI e 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 ficheiro para corresponder às listas de controlo de acesso (ACLs) que utilizou quando criou o dispositivo iSCSI no servidor de destino 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 ficheiro para corresponder às ACLs que utilizou quando criou o dispositivo iSCSI no servidor de destino iSCSI.
```
InitiatorName=iqn.2006-04.nfs-1.local:nfs-1
```

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

sudo systemctl restart iscsid
sudo systemctl restart iscsi

[A] Ligue os dispositivos iSCSI. No exemplo a seguir, 10.0.0.17 é o endereço IP do servidor de destino iSCSI e 3260 é a porta padrão. iqn.2006-04.nfs.local:nfs é um dos nomes de destino listados 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 pretender utilizar vários dispositivos SBD, ligue-se também ao segundo servidor de destino 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 pretender utilizar vários dispositivos SBD, ligue-se também ao terceiro servidor de destino 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 estão 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 os 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. Recomendamos o uso do ID que começa com scsi-3. No exemplo anterior, os 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 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] Adaptar 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 SBD.
```
[...]
SBD_DEVICE="/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]
```
Nota

Se o valor da propriedade SBD_DELAY_START estiver 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 é maior do que o valor de SBD_DELAY_START. Para obter mais informações, consulte Configuração de arquivo SBD

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

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 se você quiser usar um dispositivo SBD com um disco compartilhado do Azure.

Criar e anexar um disco compartilhado do Azure com o PowerShell

Ajuste os valores para seu grupo de recursos, região do Azure, máquinas virtuais, números de unidade lógica (LUNs) e assim por diante.
```
$ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"
```
Defina o tamanho do disco com base no tamanho do disco disponível para SSDs Premium. Neste exemplo, o tamanho do disco P1 do 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 o 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 de 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, você também pode consultar Implantar um disco ZRS.

Configurar um dispositivo SBD de disco compartilhado do Azure

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

[A] Certifique-se de que o disco ligado está 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 os 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 IDs de dispositivo para o dispositivo SBD. Recomendamos o uso do ID que começa com scsi-3. No exemplo anterior, o ID é /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19.

[1] Crie o dispositivo SBD.

Use o 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] Adaptar 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"
[...]
```
Nota

Se o valor da propriedade SBD_DELAY_START estiver 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 é maior do que o valor de SBD_DELAY_START. Para obter mais informações, consulte Configuração de arquivo SBD

Crie o arquivo de softdog configuração.

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

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

Usar um agente de cerca do Azure

Esta seção se aplica somente se você quiser usar um dispositivo de esgrima com um agente de cerca do Azure.

Criar um dispositivo de agente de cerca do Azure

Esta seção se aplica somente se você estiver usando um dispositivo de esgrima baseado em um agente de cerca do Azure. O dispositivo de esgrima usa uma identidade gerenciada ou uma entidade de serviço para autorizar contra o Microsoft Azure.

Identidade gerida
Principal de serviço

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

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

No portal do Azure, selecione Propriedades da ID>do Microsoft Entra e anote a ID do Diretório. Este é o ID do inquilino.
Selecione Registos de aplicações.
Selecione Novo registo.
Introduza um nome para o registo e, em seguida, selecione Contas apenas neste diretório da organização.
Em Tipo de aplicativo, selecione Web, insira uma URL de logon (por exemplo, http://localhost) e selecione Adicionar.
O URL de início de sessão não é utilizado e pode ser qualquer URL válido.
Selecione Certificados e segredos e, em seguida, selecione Novo segredo do cliente.
Introduza uma descrição para uma nova chave, selecione Dois anos e, em seguida, selecione Adicionar.
Anote o valor, que você usará como senha para a entidade de serviço.
Selecione Visão geral e anote a ID do aplicativo, que você usará como o nome de usuário da entidade de serviço.

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

Por padrão, nem a identidade gerenciada nem a entidade de serviço têm permissões para acessar seus recursos do Azure. Você precisa conceder à identidade gerenciada ou permissões de entidade de serviço para iniciar e parar (deslocalizar) todas as máquinas virtuais no cluster. Se você ainda não criou a função personalizada, pode fazê-lo usando o PowerShell ou a CLI do Azure.

Use o seguinte conteúdo para o arquivo de entrada. Precisa de adaptar o conteúdo às suas subscrições. Ou seja, substitua xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx e yyyy-yyyy-yyyy-yyyy-yyy pelos seus próprios IDs de subscrição. Se você 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 identidade gerenciada ou entidade de serviço.

Identidade gerida
Principal de serviço

Atribua a função personalizada "Linux Fence Agent Role" que foi criada no último capítulo a cada identidade gerenciada das VMs de cluster. Cada identidade gerenciada atribuída ao sistema VM precisa da função atribuída para cada recurso de VM de cluster. Para obter etapas detalhadas, consulte Atribuir um acesso de identidade gerenciado 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 de cluster.

Importante

Esteja ciente de que a atribuição e a remoção de autorização com identidades gerenciadas podem ser adiadas até serem efetivas.

Instalar o cluster

Nota

[R]: Aplica-se a todos os nós.
[1]: Aplica-se apenas ao nó 1.
[2]: Aplica-se apenas ao nó 2.

[A] Atualizar o SLES.
```
sudo zypper update
```
Nota

No SLES 15 SP4, verifique a versão do crmsh e do pacote de marcapasso e certifique-se de que os requisitos da versão mínima são 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 necessário para os recursos do cluster.
```
sudo zypper in socat
```
[A] Instale o componente azure-lb, que você precisa para os recursos de cluster.
```
sudo zypper in resource-agents
```
Nota

Verifique a versão do pacote de agentes de recursos e certifique-se de que os requisitos mínimos de versão sejam 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. Pacemaker ocasionalmente cria muitos processos, que podem esgotar o número permitido. Quando isso acontece, uma pulsação entre os nós do cluster pode falhar e levar a um failover de seus recursos. Recomendamos aumentar o número 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. Certifique-se de que vm.swappiness está definido como 10 para reduzir o uso de swap 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 anterior à 1.3, recomendamos que você atualize o pacote cloud-netconfig-azure para a versão mais recente disponível.

Gorjeta

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

Somente se a versão do cloud-netconfig-azure for inferior a 1.3, altere o arquivo de configuração para a interface de rede, conforme mostrado no código a seguir, para evitar que o plug-in de rede em nuvem remova o endereço IP virtual (o Pacemaker deve controlar a atribuição). Para obter mais informações, consulte 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 a utilizar um dispositivo de esgrima, com base no agente de vedação do Azure.
```
sudo zypper install fence-agents
```
Importante

A versão instalada do pacote fence-agents deve ser 4.4.0 ou posterior para se beneficiar dos tempos de failover mais rápidos com o agente de cerca do Azure, quando um nó de cluster é cercado. Se você estiver executando uma versão anterior, recomendamos que atualize o pacote.
Importante

Se estiver usando a identidade gerenciada, a versão instalada do pacote fence-agents deve ser -
- SLES 12 SP5: agentes de vedação 4.9.0+git.1624456340.8d746be9-3.35.2 ou posterior
- SLES 15 SP1 e superior: agentes de vedação 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 Azure Python 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 Azure Python 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 da sua versão e do 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 Azure Python. Você pode verificar a extensão executando SUSEConnect ---list-extensions. Para obter os tempos de failover mais rápidos com o agente de cerca do Azure:
- No SLES 12 SP4 ou SLES 12 SP5, instale a versão 4.6.2 ou posterior do pacote python-azure-mgmt-compute .
- Se a 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 fence-agents e instalar a biblioteca de cliente do Azure Identity para o módulo Python se ela estiver ausente.
[A] Configure a resolução de nome de host.

Você pode 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ê estiver usando nomes de host na configuração do cluster, é essencial ter uma resolução de nome de host confiável. A comunicação de cluster falhará se os nomes não estiverem disponíveis e isso pode levar a atrasos de failover de cluster.

O benefício de usar /etc/hosts é que seu cluster se torna independente do DNS, que também pode ser um único ponto de falha.
```
sudo vi /etc/hosts
```
Insira as seguintes linhas no /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 você estiver usando dispositivos SBD para vedação (para o servidor de destino iSCSI ou 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 você não estiver usando dispositivos SBD para cerca:

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 hacluster para a mesma senha.
```
sudo passwd hacluster
```

[A] Ajuste as configurações 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. Certifique-se de alterar o token para 30000 para permitir a manutenção da preservação da memória. Para obter mais informações, consulte 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 vedação no cluster do Pacemaker

Gorjeta

Para evitar corridas de cerca dentro de um cluster de marcapasso de dois nós, você pode configurar a propriedade adicional do cluster "priority-fencing-delay". Esta propriedade introduz um atraso adicional na vedação de um nó que tem maior prioridade total de recursos quando ocorre um cenário de cérebro dividido. Para obter detalhes adicionais, consulte o guia de administração da 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 no respetivo documento de alta disponibilidade SAP ASCS/ERS (aplicável somente em ENSA2) e SAP HANA scale-up.

[1] Se estiver a utilizar um dispositivo SBD (servidor de destino iSCSI ou disco partilhado do Azure) como dispositivo de esgrima, execute os seguintes comandos. Habilite o uso de um dispositivo de vedação e defina o atraso da cerca.

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 a utilizar um agente de vedação do Azure para esgrima, execute os seguintes comandos. Depois de atribuir funções a ambos os nós do cluster, você pode configurar os dispositivos de vedação no cluster.
```
sudo crm configure property stonith-enabled=true
sudo crm configure property concurrent-fencing=true
```
Nota

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

Identidade gerida
Principal 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 um dispositivo de esgrima, com base na configuração da entidade de serviço, leia Alterar de SPN para MSI para clusters de Pacemaker usando a cerca do Azure e saiba como converter para configuração de identidade gerenciada.

Importante

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

Gorjeta

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

Configurar o Pacemaker para eventos agendados do Azure

O Azure oferece eventos agendados. Os eventos agendados são fornecidos através do serviço de metadados e dão tempo para que a aplicação se prepare para tais eventos. O agente de recursos azure-events-az monitora eventos agendados do Azure. Se os eventos forem detetados 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 é acionada e todos os recursos, cujo nome não começa com "health-", são migrados para fora do nó com evento agendado. Quando o nó de cluster afetado estiver livre de 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 suporta totalmente ambientes do Azure implantados em diferentes zonas de disponibilidade. Recomenda-se utilizar o agente azure-events-az mais recente para todos os sistemas SAP altamente disponíveis com Pacemaker.

[A] Certifique-se de que o pacote para o agente azure-events já está instalado e atualizado.
```
sudo zypper info resource-agents
```
Requisitos mínimos de 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 de marcapasso
```
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 nenhum outro recurso no cluster começando com "health-", além dos recursos descritos nas próximas etapas da documentação.
[1] Defina o valor inicial dos atributos do cluster. Executar para cada nó de cluster. Para ambientes de expansão, incluindo VM de fabricante majoritário.
```
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
```
Nota

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

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

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

sudo crm configure property maintenance-mode=false

Limpe todos os erros durante a ativação e verifique se os recursos health-azure-events foram iniciados com êxito em todos os nós do cluster.
```
sudo crm resource cleanup
```
A execução da primeira consulta para eventos agendados pode levar até 2 minutos. O teste de marcapasso com eventos agendados pode usar ações de reinicialização ou reimplantação para as VMs de cluster. Para obter mais informações, consulte a documentação de eventos agendados.

Nota

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

AVISO: cib-bootstrap-options: atributo desconhecido 'hostName_hostname'
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óximos passos

Planejamento e implementação de Máquinas Virtuais do Azure para SAP
Implantação de Máquinas Virtuais do Azure para SAP
Implantação de DBMS de Máquinas Virtuais do Azure para SAP
Alta disponibilidade para NFS em VMs do Azure no SUSE Linux Enterprise Server
Elevada disponibilidade do SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server para aplicações SAP
Para saber como estabelecer alta disponibilidade e planejar a recuperação de desastres 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

Descrição geral

Usar um dispositivo SBD

Usar um agente de cerca do Azure

SBD com um servidor de destino iSCSI

Configurar o servidor de destino iSCSI

Criar um dispositivo iSCSI no servidor de destino 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 cerca do Azure

Criar um dispositivo de agente de cerca do Azure

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

[A] Atribuir a função personalizada

Instalar o cluster

Criar um dispositivo de vedação no cluster do Pacemaker

Configurar o Pacemaker para eventos agendados do Azure

Próximos passos

Recursos adicionais