Configurar o Pacemaker no Red Hat Enterprise Linux no Azure

Artigo
10/28/2024

Este artigo descreve como configurar um cluster básico do Pacemaker no Red Hat Enterprise Server (RHEL). As instruções abrangem RHEL 7, RHEL 8 e RHEL 9.

Pré-requisitos

Leia primeiro as seguintes notas e artigos do SAP:

Documentação do RHEL High Availability (HA)
- Configuração e gerenciamento de clusters de alta disponibilidade.
- Políticas de suporte para clusters de alta disponibilidade RHEL - sbd e fence_sbd.
- Políticas de suporte para clusters RHEL High Availability - fence_azure_arm.
- Limitações conhecidas do cão de guarda emulado por software.
- Explorando os componentes de alta disponibilidade do RHEL - sbd e fence_sbd.
- Orientação de projeto para clusters de alta disponibilidade RHEL - considerações sobre sbd.
- Considerações na adoção do RHEL 8 - Alta Disponibilidade e Clusters
Documentação RHEL específica do Azure
- Políticas de suporte para clusters de alta disponibilidade RHEL - Máquinas Virtuais do Microsoft Azure como membros do cluster.
- Diretrizes de design para clusters de alta disponibilidade RHEL - Máquinas virtuais do Microsoft Azure como membros do cluster.
Documentação RHEL para ofertas SAP

Descrição geral

Importante

Os clusters de marcapasso que abrangem várias redes virtuais (VNets)/sub-redes não são cobertos por políticas de suporte padrão.

Há duas opções disponíveis no Azure para configurar a cerca em um cluster de marcapasso para RHEL: agente de cerca do Azure, que reinicia um nó com falha por meio das APIs do Azure, ou você pode usar o dispositivo SBD.

Importante

No Azure, o cluster de alta disponibilidade RHEL com vedação baseada em armazenamento (fence_sbd) usa watchdog emulado por software. É importante revisar as limitações conhecidas do cão de guarda emulado por software e as políticas de suporte para clusters de alta disponibilidade RHEL - sbd e fence_sbd ao selecionar o SBD como o mecanismo de cerca.

Usar um dispositivo SBD

Nota

O mecanismo de esgrima com SBD é suportado em RHEL 8.8 e superior, e RHEL 9.0 e superior.

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

SBD com 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 Compute System Interface) e fornece um dispositivo SBD. Esses servidores de destino iSCSI podem, no entanto, ser compartilhados com outros clusters de marcapasso. 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 de marcapasso.

Você pode usar até três dispositivos SBD para um cluster de marcapasso 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 pretender utilizar mais do que um dispositivo SBD por pacemaker, certifique-se de que implementa vários servidores de destino iSCSI e que liga um SBD a partir de cada servidor de destino iSCSI. Recomendamos o uso de um ou três dispositivos SBD. 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

Quando você estiver planejando implantar e configurar nós de cluster de marcapasso Linux 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 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 de marcapasso. A vantagem do dispositivo SBD usando um disco compartilhado do Azure é que você não precisa implantar e configurar máquinas virtuais adicionais.

Aqui estão algumas considerações importantes sobre dispositivos SBD ao configurar usando o 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 são suportados no RHEL 8.8 e posterior.
- Os dispositivos SBD que usam um disco de compartilhamento 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 um disco compartilhado premium do Azure (skuName - Premium_LRS) só é suportado com implantação regional como conjunto de disponibilidade.
- Um dispositivo SBD usando ZRS para um disco compartilhado premium do Azure (skuName - Premium_ZRS) é recomendado com implantação zonal, como zona de disponibilidade, ou dimensionamento definido com FD=1.
- Um ZRS para disco gerenciado está atualmente disponível nas regiões listadas no documento de disponibilidade regional.
- 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 marcapasso, você pode usar um disco compartilhado do Azure para dispositivos SBD em clusters com até cinco 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 de marcapasso.
- 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 ou identidade de sistema gerenciado (MSI) 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 de marcapasso.

Implante máquinas virtuais que são executadas na versão compatível do RHEL OS e conecte-se a elas via SSH. As VMs não precisam ser de tamanho grande. Tamanhos de VM como Standard_E2s_v3 ou Standard_D2s_v3 são suficientes. Certifique-se de usar o armazenamento Premium para o disco do sistema operacional.
Não é necessário usar o RHEL for SAP com HA e Update Services, ou a imagem do RHEL for SAP Apps OS para o servidor de destino iSCSI. Em vez disso, uma imagem padrão do sistema operacional RHEL pode ser usada. No entanto, esteja ciente de que o ciclo de vida do suporte varia entre diferentes versões de produtos do sistema operacional.
Execute os seguintes comandos em todas as máquinas virtuais de destino iSCSI.
1. Atualize o RHEL.
```
sudo yum -y update
```
  Nota
  
  Talvez seja necessário reinicializar o nó depois de atualizar ou atualizar o sistema operacional.
2. Instale o pacote de destino iSCSI.
```
sudo yum install targetcli
```
3. Inicie e configure o destino para iniciar no momento da inicialização.
```
sudo systemctl start target
sudo systemctl enable target
```
4. Abrir porta 3260 no firewall
```
sudo firewall-cmd --add-port=3260/tcp --permanent
sudo firewall-cmd --add-port=3260/tcp
```

Criar um dispositivo iSCSI no servidor de destino iSCSI

Para criar os discos iSCSI para seus clusters de sistema SAP, execute os seguintes comandos em cada máquina virtual de destino iSCSI. O exemplo ilustra a criação de dispositivos SBD para vários clusters, demonstrando o uso de um único servidor de destino iSCSI para vários clusters. O dispositivo SBD está configurado no disco do SO, por isso certifique-se de que há espaço suficiente.

ascsnw1: Representa o cluster ASCS/ERS do NW1.
dbhn1: Representa o cluster de banco de dados de HN1.
sap-cl1 e sap-cl2: nomes de host dos nós de cluster ASCS/ERS NW1.
hn1-db-0 e hn1-db-1: nomes de host dos nós do cluster de banco de dados.

Nas instruções a seguir, modifique o comando com seus nomes de host e SIDs específicos, conforme necessário.

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

Crie o dispositivo SBD para os servidores ASCS/ERS do sistema 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.sap-cl1.local:sap-cl1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl2.local:sap-cl2

Crie o dispositivo SBD para o cluster de banco de dados do sistema HN1.

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

Salve a configuração 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: 2]
  | | o- sbdascsnw1 ............................................................... [/sbd/sbdascsnw1 (50.0MiB) write-thru activated]
  | | | o- alua ................................................................................................... [ALUA Groups: 1]
  | | |   o- default_tg_pt_gp ....................................................................... [ALUA state: Active/optimized]
  | | o- sbddbhn1 ................................................................... [/sbd/sbddbhn1 (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: 2]
  | o- iqn.2006-04.dbhn1.local:dbhn1 ..................................................................................... [TPGs: 1]
  | | o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
  | |   o- acls .......................................................................................................... [ACLs: 2]
  | |   | o- iqn.2006-04.hn1-db-0.local:hn1-db-0 .................................................................. [Mapped LUNs: 1]
  | |   | | o- mapped_lun0 ............................................................................... [lun0 fileio/sbdhdb (rw)]
  | |   | o- iqn.2006-04.hn1-db-1.local:hn1-db-1 .................................................................. [Mapped LUNs: 1]
  | |   |   o- mapped_lun0 ............................................................................... [lun0 fileio/sbdhdb (rw)]
  | |   o- luns .......................................................................................................... [LUNs: 1]
  | |   | o- lun0 ............................................................. [fileio/sbddbhn1 (/sbd/sbddbhn1) (default_tg_pt_gp)]
  | |   o- portals .................................................................................................... [Portals: 1]
  | |     o- 0.0.0.0:3260 ..................................................................................................... [OK]
  | o- iqn.2006-04.ascsnw1.local:ascsnw1 ................................................................................. [TPGs: 1]
  |   o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
  |     o- acls .......................................................................................................... [ACLs: 2]
  |     | o- iqn.2006-04.sap-cl1.local:sap-cl1 .................................................................... [Mapped LUNs: 1]
  |     | | o- mapped_lun0 ........................................................................... [lun0 fileio/sbdascsers (rw)]
  |     | o- iqn.2006-04.sap-cl2.local:sap-cl2 .................................................................... [Mapped LUNs: 1]
  |     |   o- mapped_lun0 ........................................................................... [lun0 fileio/sbdascsers (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- loopback ......................................................................................................... [Targets: 0]

Configurar o dispositivo SBD do servidor de destino iSCSI

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

Nos nós do cluster, conecte-se e descubra o dispositivo iSCSI criado na seção anterior. Execute os seguintes comandos nos nós do novo cluster que você deseja criar.

[A] Instale ou atualize os utilitários do iniciador iSCSI em todos os nós do cluster.
```
sudo yum install -y iscsi-initiator-utils
```
[A] Instale pacotes de cluster e SBD em todos os nós de cluster.
```
sudo yum install -y pcs pacemaker sbd fence-agents-sbd
```
[A] Habilite o serviço iSCSI.
```
sudo systemctl enable iscsid iscsi
```

[1] Altere o nome do iniciador no primeiro nó do cluster.

sudo vi /etc/iscsi/initiatorname.iscsi

# Change the content of the file to match the access control ists (ACLs) you used when you created the iSCSI device on the iSCSI target server (for example, for the ASCS/ERS servers)
InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1

[2] Altere o nome do iniciador no segundo nó do cluster.

sudo vi /etc/iscsi/initiatorname.iscsi

# Change the content of the file to match the access control ists (ACLs) you used when you created the iSCSI device on the iSCSI target server (for example, for the ASCS/ERS servers)
InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2

[A] Reinicie o serviço iSCSI para aplicar as alterações.

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. O nome iqn.2006-04.ascsnw1.local:ascsnw1 do 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.ascsnw1.local:ascsnw1 --login --portal=10.0.0.17:3260
sudo iscsiadm -m node -p 10.0.0.17:3260 -T iqn.2006-04.ascsnw1.local:ascsnw1 --op=update --name=node.startup --value=automatic

[R] Se estiver a 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.ascsnw1.local:ascsnw1 --login --portal=10.0.0.18:3260
sudo iscsiadm -m node -p 10.0.0.18:3260 -T iqn.2006-04.ascsnw1.local:ascsnw1 --op=update --name=node.startup --value=automatic

[A] Se você estiver usando vários dispositivos SBD, conecte-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.ascsnw1.local:ascsnw1 --login --portal=10.0.0.19:3260
sudo iscsiadm -m node -p 10.0.0.19:3260 -T iqn.2006-04.ascsnw1.local:ascsnw1 --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. No exemplo a seguir, três dispositivos iSCSI são descobertos conectando o nó a três servidores de destino iSCSI.

lsscsi

[0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sde
[1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[1:0:0:2]    disk    Msft     Virtual Disk     1.0   /dev/sdc
[1:0:0:3]    disk    Msft     Virtual Disk     1.0   /dev/sdd
[2:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdf
[3:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdh
[4:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdg

[A] Recupere os IDs dos dispositivos iSCSI.

ls -l /dev/disk/by-id/scsi-* | grep -i sdf

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:85d254ed-78e2-4ec4-8b0d-ecac2843e086 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_85d254ed-78e2-4ec4-8b0d-ecac2843e086 -> ../../sdf

ls -l /dev/disk/by-id/scsi-* | grep -i sdh

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:87122bfc-8a0b-4006-b538-d0a6d6821f04 -> ../../sdh
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d -> ../../sdh
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_87122bfc-8a0b-4006-b538-d0a6d6821f04 -> ../../sdh

ls -l /dev/disk/by-id/scsi-* | grep -i sdg

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:d2ddc548-060c-49e7-bb79-2bb653f0f34a -> ../../sdg
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 -> ../../sdg
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_d2ddc548-060c-49e7-bb79-2bb653f0f34a -> ../../sdg

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-3600140585d254ed78e24ec48b0decac2
/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d
/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65

[1] Crie o dispositivo SBD.

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-3600140585d254ed78e24ec48b0decac2 -1 60 -4 120 create
```

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

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

[A] Adaptar a configuração do SBD

Abra o arquivo de configuração do SBD.
```
sudo vi /etc/sysconfig/sbd
```

Altere a propriedade do dispositivo SBD, habilite a integração do marca-passo e altere o modo de início do SBD.

[...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2;/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d;/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65"
[...]
SBD_PACEMAKER=yes
[...]
SBD_STARTMODE=always
[...]
SBD_DELAY_START=yes
[...]

[A] Execute o seguinte comando para carregar o softdog módulo.
```
modprobe softdog
```
[A] Execute o seguinte comando para garantir que softdog seja carregado automaticamente após a reinicialização de um nó.
```
echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load
```
[A] O valor de tempo limite do serviço SBD é definido como 90 s por padrão. No entanto, se o SBD_DELAY_START valor estiver definido como yes, o serviço SBD atrasará o seu início para depois do msgwait tempo limite. Portanto, o valor de tempo limite do serviço SBD deve exceder o msgwait tempo limite quando SBD_DELAY_START estiver habilitado.
```
sudo mkdir /etc/systemd/system/sbd.service.d
echo -e "[Service]\nTimeoutSec=144" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
sudo systemctl daemon-reload

systemctl show sbd | grep -i timeout
# TimeoutStartUSec=2min 24s
# TimeoutStopUSec=2min 24s
```

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.

Configurar o disco compartilhado do Azure com o PowerShell

Para criar e anexar um disco compartilhado do Azure com o PowerShell, execute as instruções a seguir. Se quiser implantar recursos usando a CLI do Azure ou o portal do Azure, você também pode consultar Implantar um disco ZRS.

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

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

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

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

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

Configurar um dispositivo SBD de disco compartilhado do Azure

[A] Instale pacotes de cluster e SBD em todos os nós de cluster.
```
sudo yum install -y pcs pacemaker sbd fence-agents-sbd
```

[A] Certifique-se de que o disco ligado está disponível.

lsblk

# NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
# sda                 8:0    0    4G  0 disk
# sdb                 8:16   0   64G  0 disk
# ├─sdb1              8:17   0  500M  0 part /boot
# ├─sdb2              8:18   0   63G  0 part
# │ ├─rootvg-tmplv  253:0    0    2G  0 lvm  /tmp
# │ ├─rootvg-usrlv  253:1    0   10G  0 lvm  /usr
# │ ├─rootvg-homelv 253:2    0    1G  0 lvm  /home
# │ ├─rootvg-varlv  253:3    0    8G  0 lvm  /var
# │ └─rootvg-rootlv 253:4    0    2G  0 lvm  /
# ├─sdb14             8:30   0    4M  0 part
# └─sdb15             8:31   0  495M  0 part /boot/efi
# sr0                11:0    1 1024M  0 rom

lsscsi

# [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
# [0:0:0:2]    cd/dvd  Msft     Virtual DVD-ROM  1.0   /dev/sr0
# [1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
# [1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdc

[A] Recupere o ID do dispositivo do disco compartilhado conectado.

ls -l /dev/disk/by-id/scsi-* | grep -i sda

# lrwxrwxrwx 1 root root  9 Jul 15 22:24 /dev/disk/by-id/scsi-14d534654202020200792c2f5cc7ef14b8a7355cb3cef0107 -> ../../sda
# lrwxrwxrwx 1 root root  9 Jul 15 22:24 /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107 -> ../../sda

O ID do dispositivo da lista de comandos para o disco compartilhado anexado. Recomendamos o uso do ID que começa com scsi-3. Neste exemplo, o ID é /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107.

[1] Criar o dispositivo SBD

# Use the device ID from step 3 to create the new SBD device on the first cluster node
sudo sbd -d /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107 -1 60 -4 120 create

[A] Adaptar a configuração do SBD

Abra o arquivo de configuração do SBD.
```
sudo vi /etc/sysconfig/sbd
```

Altere a propriedade do dispositivo SBD, habilite a integração do marcapasso e altere o modo de início do SBD

[...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107"
[...]
SBD_PACEMAKER=yes
[...]
SBD_STARTMODE=always
[...]
SBD_DELAY_START=yes
[...]

[A] Execute o seguinte comando para carregar o softdog módulo.
```
modprobe softdog
```
[A] Execute o seguinte comando para garantir que softdog seja carregado automaticamente após a reinicialização de um nó.
```
echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load
```
[R] O valor de tempo limite do serviço SBD é definido como 90 segundos por padrão. No entanto, se o SBD_DELAY_START valor estiver definido como yes, o serviço SBD atrasará o seu início para depois do msgwait tempo limite. Portanto, o valor de tempo limite do serviço SBD deve exceder o msgwait tempo limite quando SBD_DELAY_START estiver habilitado.
```
sudo mkdir /etc/systemd/system/sbd.service.d
echo -e "[Service]\nTimeoutSec=144" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
sudo systemctl daemon-reload

systemctl show sbd | grep -i timeout
# TimeoutStartUSec=2min 24s
# TimeoutStopUSec=2min 24s
```

Configuração do agente de cerca do Azure

O dispositivo de esgrima usa uma identidade gerenciada para o recurso do Azure ou uma entidade de serviço para autorizar contra o Azure. Dependendo do método de gerenciamento de identidade, siga os procedimentos apropriados -

Configurar o gerenciamento de identidades

Use identidade gerenciada ou entidade de serviço.
- 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. Se já existir uma identidade gerenciada atribuída ao sistema, ela será usada. Não use identidades gerenciadas atribuídas pelo usuário com o Pacemaker no momento. Um dispositivo de cerca, baseado em identidade gerenciada, é suportado no RHEL 7.9 e RHEL 8.x/RHEL 9.x.
Siga estas etapas para criar uma entidade de serviço, se você não estiver usando a identidade gerenciada.
1. Aceda ao portal do Azure.
2. Abra o painel ID do Microsoft Entra.
3. Vá para Propriedades e anote a ID do diretório. Este é o ID do inquilino.
4. Selecione Registos de aplicações.
5. Selecione Novo Registo.
6. Insira um Nome e selecione Contas somente neste diretório da organização.
7. Selecione Tipo de Aplicativo como 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.
8. Selecione Certificados e Segredos e, em seguida, selecione Novo segredo do cliente.
9. Insira uma descrição para uma nova chave, selecione Dois anos e selecione Adicionar.
10. Anote o Valor. Ele é usado como a senha para a entidade de serviço.
11. Selecione Descrição geral. Anote a ID do aplicativo. Ele é usado como o nome de usuário (ID de login nas etapas a seguir) da entidade de serviço.
Criar uma função personalizada para o agente de cerca

Tanto a identidade gerenciada quanto a entidade de serviço não têm permissões para acessar seus recursos do Azure por padrão. Você precisa conceder à identidade gerenciada ou permissões de entidade de serviço para iniciar e parar (desligar) todas as VMs do cluster. Se você ainda não criou a função personalizada, pode criá-la usando o PowerShell ou a CLI do Azure.

Use o seguinte conteúdo para o arquivo de entrada. Você precisa adaptar o conteúdo às suas assinaturas, ou seja, substituir xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx e yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy com os IDs da sua assinatura. Se tiver apenas uma subscrição, remova a segunda entrada no 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": []
}
```
Atribuir a função personalizada

Use identidade gerenciada ou entidade de serviço.
- Identidade gerida
- Principal de serviço
Atribua a função Linux Fence Agent Role personalizada criada na última seção 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 mais informações, 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

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

Atribua a função Linux Fence Agent Role personalizada criada na última seção à entidade de serviço. Não use mais a função Proprietário. Para obter mais informações, consulte Atribuir funções do Azure usando o portal do Azure.

Certifique-se de atribuir a função para ambos os nós de cluster.

Instalação de cluster

As diferenças nos comandos ou na configuração entre RHEL 7 e RHEL 8/RHEL 9 são marcadas no documento.

[A] Instale o complemento RHEL HA.

sudo yum install -y pcs pacemaker nmap-ncat

[A] No RHEL 9.x, instale os agentes de recursos para implantação na nuvem.
```
sudo yum install -y resource-agents-cloud
```
[A] Instale o pacote fence-agents se estiver a utilizar um dispositivo de vedação baseado no agente de vedação do Azure.
```
sudo yum install -y fence-agents-azure-arm 
```
Importante

Recomendamos as seguintes versões do agente de cerca do Azure (ou posterior) para clientes que desejam usar identidades gerenciadas para recursos do Azure em vez de nomes de entidade de serviço para o agente de cerca:
- RHEL 8.4: agentes de vedação-4.2.1-54.el8.
- RHEL 8.2: agentes de vedação-4.2.1-41.el8_2.4
- RHEL 8.1: agentes de vedação-4.2.1-30.el8_1.4
- RHEL 7.9: agentes de vedação-4.2.1-41.el7_9.4.
Importante

No RHEL 9, recomendamos as seguintes versões de pacote (ou posteriores) para evitar problemas com o agente de cerca do Azure:
- agentes de vedação-4.10.0-20.el9_0.7
- agentes de vedação-comuns-4.10.0-20.el9_0.6
- ha-nuvem-suporte-4.10.0-20.el9_0.6.x86_64.rpm
Verifique a versão do agente de cerca do Azure. Se necessário, atualize-o para a versão mínima exigida ou posterior.
```
# Check the version of the Azure Fence Agent
sudo yum info fence-agents-azure-arm
```
Importante

Se você precisar atualizar o agente de cerca do Azure e se estiver usando uma função personalizada, certifique-se de atualizar a função personalizada para incluir a ação powerOff. Para obter mais informações, consulte Criar uma função personalizada para o agente de cerca.
[A] Configure a resolução de nome de host.

Você pode usar um servidor DNS ou modificar o /etc/hosts arquivo em todos os nós. Este exemplo mostra como usar o /etc/hosts arquivo. 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, é vital ter uma resolução de nome de host confiável. A comunicação de cluster falhará se os nomes não estiverem disponíveis, o que 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 falhas.
```
sudo vi /etc/hosts
```
Insira as seguintes linhas em /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
```
[A] Altere a hacluster palavra-passe para a mesma palavra-passe.
```
sudo passwd hacluster
```
[A] Adicione regras de firewall para o Pacemaker.

Adicione as seguintes regras de firewall a toda a comunicação de cluster entre os nós de cluster.
```
sudo firewall-cmd --add-service=high-availability --permanent
sudo firewall-cmd --add-service=high-availability
```
[A] Habilite serviços básicos de cluster.

Execute os seguintes comandos para ativar o serviço Pacemaker e iniciá-lo.
```
sudo systemctl start pcsd.service
sudo systemctl enable pcsd.service
```

[1] Criar um cluster de pacemaker.

Execute os seguintes comandos para autenticar os nós e criar o cluster. Defina o token como 30000 para permitir a manutenção da preservação da memória. Para obter mais informações, consulte este artigo para Linux.

Se você estiver criando um cluster no RHEL 7.x, use os seguintes comandos:

sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000
sudo pcs cluster start --all

Se você estiver criando um cluster no RHEL 8.x/RHEL 9.x, use os seguintes comandos:

sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000
sudo pcs cluster start --all

Verifique o status do cluster executando o seguinte comando:

# Run the following command until the status of both nodes is online
sudo pcs status

# Cluster name: nw1-azr
# WARNING: no stonith devices and stonith-enabled is not false
# Stack: corosync
# Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
# Last updated: Fri Aug 17 09:18:24 2018
# Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1
#
# 2 nodes configured
# 0 resources configured
#
# Online: [ prod-cl1-0 prod-cl1-1 ]
#
# No resources
#
# Daemon Status:
#   corosync: active/disabled
#   pacemaker: active/disabled
#   pcsd: active/enabled

[A] Definir os votos esperados.
```
# Check the quorum votes 
pcs quorum status

# If the quorum votes are not set to 2, execute the next command
sudo pcs quorum expected-votes 2
```
Gorjeta

Se você estiver criando um cluster de vários nós, ou seja, um cluster com mais de dois nós, não defina os votos como 2.

[1] Permitir ações de vedação simultâneas.

sudo pcs property set concurrent-fencing=true

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 priority-fencing-delay propriedade cluster. 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 mais informações, consulte O Pacemaker pode cercar o nó do cluster com o menor número de recursos em execução?.
A propriedade priority-fencing-delay é aplicável para Pacemaker versão 2.0.4-6.el8 ou superior e em um cluster de dois nós. Se você configurar a priority-fencing-delay propriedade de cluster, não precisará definir a pcmk_delay_max propriedade. Mas se a versão do Pacemaker for inferior a 2.0.4-6.el8, você precisa definir a pcmk_delay_max propriedade.
Para obter instruções sobre como definir a priority-fencing-delay propriedade do cluster, consulte os respetivos documentos SAP ASCS/ERS e SAP HANA scale-up HA.

Com base no mecanismo de vedação selecionado, siga apenas uma seção para obter instruções relevantes: SBD como dispositivo de vedação ou agente de cerca do Azure como dispositivo de cerca.

SBD como dispositivo de vedação

[A] Ativar serviço SBD
```
sudo systemctl enable sbd
```

[1] Para o dispositivo SBD configurado utilizando servidores de destino iSCSI ou disco partilhado do Azure, execute os seguintes comandos.

sudo pcs property set stonith-timeout=144
sudo pcs property set stonith-enabled=true

# Replace the device IDs with your device ID. 
pcs stonith create sbd fence_sbd \
devices=/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2,/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d,/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 \
op monitor interval=600 timeout=15

[1] Reiniciar o cluster
```
sudo pcs cluster stop --all

# It would take time to start the cluster as "SBD_DELAY_START" is set to "yes"
sudo pcs cluster start --all
```
Nota

Se você encontrar o seguinte erro ao iniciar o cluster de marcapasso, você pode ignorar a mensagem. Como alternativa, você pode iniciar o cluster usando o comando pcs cluster start --all --request-timeout 140.

Erro: não é possível iniciar todos os nós node1/node2: Não é possível conectar-se ao node1/node2, verifique se o pcsd está sendo executado lá ou tente definir um tempo limite mais alto com --request-timeout a opção (Operação expirou após 60000 milissegundos com 0 bytes recebidos)

Agente de vedação do Azure como dispositivo de vedação

[1] Depois de atribuir funções a ambos os nós do cluster, pode configurar os dispositivos de vedação no cluster.
```
sudo pcs property set stonith-timeout=900
sudo pcs property set stonith-enabled=true
```

[1] Execute o comando apropriado dependendo se você estiver usando uma identidade gerenciada ou uma entidade de serviço para o agente de cerca do Azure.

Nota

Ao usar a nuvem governamental do Azure, você deve especificar cloud= a opção ao configurar o agente de cerca. Por exemplo, cloud=usgov para a nuvem do governo dos EUA do Azure. Para obter detalhes sobre o suporte RedHat na nuvem governamental do Azure, consulte Políticas de suporte para clusters de alta disponibilidade RHEL - Máquinas virtuais do Microsoft Azure como membros do cluster.

Gorjeta

A opção pcmk_host_map só será necessária no comando se os nomes de host RHEL e os nomes de VM do Azure não forem idênticos. Especifique o mapeamento no formato hostname:vm-name. Para obter mais informações, consulte Qual formato devo usar para especificar mapeamentos de nó para dispositivos de vedação no pcmk_host_map?.

Identidade gerida
Principal de serviço

Para RHEL 7.x, use o seguinte comando para configurar o dispositivo de cerca:

sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \ 
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

Para RHEL 8.x/9.x, use o seguinte comando para configurar o dispositivo de cerca:

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

Para RHEL 7.x, use o seguinte comando para configurar o dispositivo de cerca:

sudo pcs stonith create rsc_st_azure fence_azure_arm login="login ID" passwd="password" \
resourceGroup="resource group" tenantId="tenant ID" subscriptionId="subscription id" \
pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

Para RHEL 8.x/9.x, use o seguinte comando para configurar o dispositivo de cerca:

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm username="login ID" password="password" \
resourceGroup="resource group" tenantId="tenant ID" subscriptionId="subscription id" \
pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm username="login ID" password="password" \
resourceGroup="resource group" tenantId="tenant ID" subscriptionId="subscription id" \
pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

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 do Pacemaker usando a cerca do Azure e saiba como converter para configuração de identidade gerenciada.

As operações de monitoramento e vedação são desserializadas. Como resultado, se houver uma operação de monitoramento em 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 pontos de extremidade públicos. Para obter mais informações, juntamente com possíveis soluções, consulte 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 enviados através do serviço de metadados e dão tempo para que a aplicação se prepare para tais eventos.

O agente azure-events-az de recursos do Pacemaker 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 com nomes que não começam são health- migrados para fora do nó com o evento agendado. Depois que 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 uma reinicialização.

[A] Certifique-se de que o pacote para o azure-events-az agente já está instalado e atualizado.
```
RHEL 8.x: sudo dnf info resource-agents
RHEL 9.x: sudo dnf info resource-agents-cloud
```
Requisitos mínimos de versão:
- RHEL 8.4: resource-agents-4.1.1-90.13
- RHEL 8.6: resource-agents-4.9.0-16.9
- RHEL 8,8: resource-agents-4.9.0-40.1
- RHEL 9.0: resource-agents-cloud-4.10.0-9.6
- RHEL 9.2 e mais recente: resource-agents-cloud-4.10.0-34.1

[1] Configure os recursos no Pacemaker.

#Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true

[1] Defina a estratégia e a restrição do nó de integridade do cluster Pacemaker.
```
sudo pcs property set node-health-strategy=custom

sudo pcs constraint location 'regexp%!health-.*' \
rule score-attribute='#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.
[1] Defina o valor inicial dos atributos do cluster. Execute para cada nó de cluster e 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. Certifique-se de que os recursos comecem com health-azure.

sudo pcs resource create health-azure-events \
ocf:heartbeat:azure-events-az \
op monitor interval=10s timeout=240s \
op start timeout=10s start-delay=90s

sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true failure-timeout=120s

Retire o cluster do Pacemaker do modo de manutenção.
```
sudo pcs property set maintenance-mode=false
```
Limpe todos os erros durante a ativação e verifique se os health-azure-events recursos foram iniciados com êxito em todos os nós do cluster.
```
sudo pcs resource cleanup
```
A execução da primeira consulta para eventos agendados pode levar até dois 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 Eventos agendados.

Configuração opcional de vedação

Gorjeta

Esta seção só é aplicável se você quiser configurar o dispositivo fence_kdumpde vedação especial.

Se você precisar coletar informações de diagnóstico na VM, pode ser útil configurar outro dispositivo de vedação com base no agente fence_kdumpde cerca. O fence_kdump agente pode detetar que um nó entrou na recuperação de falha do kdump e pode permitir que o serviço de recuperação de falhas seja concluído antes que outros métodos de esgrima sejam invocados. Observe que fence_kdump isso não substitui os mecanismos de cerca tradicionais, como o SBD ou o agente de cerca do Azure, quando você estiver usando VMs do Azure.

Importante

Lembre-se de que, quando fence_kdump configurado como um dispositivo de vedação de primeiro nível, ele introduz atrasos nas operações de vedação e, respectivamente, atrasos no failover de recursos do aplicativo.

Se um despejo de memória for detetado com êxito, a vedação será adiada até que o serviço de recuperação de falhas seja concluído. Se o nó com falha estiver inacessível ou não responder, a vedação será atrasada pelo tempo determinado, pelo número configurado de iterações e pelo fence_kdump tempo limite. Para obter mais informações, consulte Como configurar fence_kdump em um cluster Red Hat Pacemaker?.

O tempo limite proposto fence_kdump poderá ter de ser adaptado ao ambiente específico.

Recomendamos que você configure fence_kdump a vedação somente quando necessário para coletar diagnósticos na VM e sempre em combinação com métodos tradicionais de cerca, como SBD ou agente de cerca do Azure.

Os seguintes artigos da Base de Dados de Conhecimento Red Hat contêm informações importantes sobre como configurar fence_kdump a esgrima:

Consulte Como faço para configurar fence_kdump em um cluster Red Hat Pacemaker?.
Consulte Como configurar/gerenciar níveis de esgrima em um cluster RHEL com o Pacemaker.
Consulte fence_kdump falha com "tempo limite após X segundos" em um cluster RHEL 6 ou 7 HA com kexec-tools mais antigo que 2.0.14.
Para obter informações sobre como alterar o tempo limite padrão, consulte Como configurar o kdump para uso com o complemento RHEL 6, 7, 8 HA?.
Para obter informações sobre como reduzir o atraso de failover ao usar fence_kdumpo , consulte Posso reduzir o atraso esperado de failover ao adicionar fence_kdump configuração?.

Execute as seguintes etapas opcionais para adicionar fence_kdump como uma configuração de vedação de primeiro nível, além da configuração do agente de cerca do Azure.

[A] Verifique se kdump está ativo e configurado.

systemctl is-active kdump
# Expected result
# active

[A] Instale o agente de fence_kdump cerca.
```
yum install fence-agents-kdump
```

[1] Crie um fence_kdump dispositivo de vedação no cluster.

pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30

[1] Configure os níveis de vedação para que o mecanismo de fence_kdump vedação seja acionado primeiro.

pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1"
pcs stonith level add 1 prod-cl1-0 rsc_st_kdump
pcs stonith level add 1 prod-cl1-1 rsc_st_kdump
# Replace <stonith-resource-name> to the resource name of the STONITH resource configured in your pacemaker cluster (example based on above configuration - sbd or rsc_st_azure)
pcs stonith level add 2 prod-cl1-0 <stonith-resource-name>
pcs stonith level add 2 prod-cl1-1 <stonith-resource-name>

# Check the fencing level configuration 
pcs stonith level
# Example output
# Target: prod-cl1-0
# Level 1 - rsc_st_kdump
# Level 2 - <stonith-resource-name>
# Target: prod-cl1-1
# Level 1 - rsc_st_kdump
# Level 2 - <stonith-resource-name>

[A] Permita as portas necessárias para fence_kdump através do firewall.

firewall-cmd --add-port=7410/udp
firewall-cmd --add-port=7410/udp --permanent

[A] Execute a fence_kdump_nodes configuração para /etc/kdump.conf evitar fence_kdump falhas com um tempo limite para algumas kexec-tools versões. Para obter mais informações, consulte fence_kdump tempo limite quando fence_kdump_nodes não é especificado com o kexec-tools versão 2.0.15 ou posterior e fence_kdump falha com "tempo limite após X segundos" em um cluster de alta disponibilidade RHEL 6 ou 7 com versões kexec-tools anteriores à 2.0.14. O exemplo de configuração para um cluster de dois nós é apresentado aqui. Depois de fazer uma alteração no /etc/kdump.conf, a imagem kdump deve ser regenerada. Para regenerar, reinicie o kdump serviço.
```
vi /etc/kdump.conf
# On node prod-cl1-0 make sure the following line is added
fence_kdump_nodes  prod-cl1-1
# On node prod-cl1-1 make sure the following line is added
fence_kdump_nodes  prod-cl1-0

# Restart the service on each node
systemctl restart kdump
```

[A] Certifique-se de que o initramfs ficheiro de imagem contém os fence_kdump ficheiros e hosts . Para obter mais informações, consulte Como configurar fence_kdump em um cluster Red Hat Pacemaker?.

lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts"
# Example output 
# -rw-r--r--   1 root     root          208 Jun  7 21:42 etc/hosts
# -rwxr-xr-x   1 root     root        15560 Jun 17 14:59 usr/libexec/fence_kdump_send

Teste a configuração travando um nó. Para obter mais informações, consulte Como configurar fence_kdump em um cluster Red Hat Pacemaker?.

Importante

Se o cluster já estiver em uso produtivo, planeje o teste de acordo porque a falha de um nó tem um impacto no aplicativo.
```
echo c > /proc/sysrq-trigger
```

Próximos passos

Consulte Planejamento e implementação de Máquinas Virtuais do Azure para SAP.
Consulte Implantação de Máquinas Virtuais do Azure para SAP.
Consulte Implantação de DBMS de Máquinas Virtuais do Azure para SAP.
Para saber como estabelecer HA 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.

Partilhar via

Configurar o Pacemaker no Red Hat Enterprise Linux no Azure

Pré-requisitos

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

Configurar o disco compartilhado do Azure com o PowerShell

Configurar um dispositivo SBD de disco compartilhado do Azure

Configuração do agente de cerca do Azure

Instalação de cluster

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

SBD como dispositivo de vedação

Agente de vedação do Azure como dispositivo de vedação

Configurar o Pacemaker para eventos agendados do Azure

Configuração opcional de vedação

Próximos passos

Comentários

Recursos adicionais