Compartilhar via

Configurar o Pacemaker no Red Hat Enterprise Linux no Azure

  • Artigo

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

Pré-requisitos

Primeiro, leia os seguintes artigos e Notas do SAP:

Visão geral

Importante

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

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

Importante

No Azure, o cluster de alta disponibilidade do RHEL com isolamento baseado em armazenamento (fence_sbd) usa um watchdog emulado por software. É importante ler os artigos Limitações Conhecidas do Watchdog Emulado por Software e Políticas de Suporte para Clusters de Alta Disponibilidade do RHEL: sbd e fence_sbd ao selecionar o SBD como um mecanismo de isolamento.

Usar um dispositivo SBD

Observação

O mecanismo de isolamento com SBD é compatível com o RHEL 8.8 e superior e com o RHEL 9.0 e superior.

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

  • SBD com servidor de destino iSCSI

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

    Você pode usar até três dispositivos de SBD para que um cluster do Pacemaker permita que um dispositivo de SBD se torne indisponível (por exemplo, durante a aplicação de patch do sistema operacional do servidor de destino iSCSI). Se quiser usar mais de um dispositivo de SBD por Pacemaker, certifique-se de implantar vários servidores de destino iSCSI e conecte um SBD de cada servidor de destino iSCSI. Recomendamos usar um ou três dispositivos de SBD. O Pacemaker não poderá isolar um nó de cluster automaticamente se apenas dois dispositivos de SBD estiverem configurados e um deles estiver indisponível. Se quiser ser capaz de limitar quando um servidor de destino iSCSI estiver inativo, você precisará usar três dispositivos SBD e, portanto, três servidores de destino iSCSI. Essa é a configuração mais resiliente quando você está usando SBDs.

    Diagrama do Pacemaker com o servidor de destino iSCSI atuando como dispositivo de SBD no RHEL

    Importante

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

    Eventos de manutenção e outros problemas com a NVA poderão ter impacto negativo na estabilidade e confiabilidade da configuração geral do cluster. Para obter mais informações, confira regras de roteamento definidas pelo usuário.

  • SBD com um disco compartilhado do Azure

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

    Diagrama do dispositivo de SBD com disco compartilhado do Azure para um cluster do Pacemaker no RHEL.

    Confira algumas considerações importantes sobre dispositivos de SBD ao configurá-los com o uso de um disco compartilhado do Azure:

    • Um disco compartilhado do Azure com SSD Premium tem suporte como um dispositivo SBD.
    • Dispositivos SBD que usam um disco compartilhado do Azure são compatíveis com o RHEL 8.8 e posterior.
    • Os dispositivos de SBD que usam um disco compartilhado premium do Azure são compatíveis com o armazenamento com redundância local (LRS) e com o armazenamento com redundância de zona (ZRS).
    • Dependendo do tipo da sua implantação, escolha o armazenamento redundante apropriado de um disco compartilhado do Azure como seu dispositivo SBD.
    • Um dispositivo de SBD que usa LRS para um disco compartilhado Premium do Azure (skuName Premium_LRS) só terá suporte se o conjunto de disponibilidade tiver implantação regional.
    • Um dispositivo de SBD usando ZRS para um disco compartilhado Premium do Azure (skuName Premium_ZRS) é recomendado com um conjunto de disponibilidade com implantação zonal ou um conjunto de dimensionamento com FD=1.
    • Uma ZRS para disco gerenciado está disponível atualmente nas regiões listadas no documento de disponibilidade regional.
    • O disco compartilhado do Azure que você usa nos dispositivos SBD não precisa ser grande. O valor maxShares determina quantos nós de cluster podem usar o disco compartilhado. Por exemplo, você pode usar tamanhos de disco P1 ou P2 para o dispositivo SBD em um cluster de dois nós como o SAP ASCS/ERS ou o SAP HANA com escalonamento vertical.
    • Para a expansão do HANA com replicação do sistema HANA (HSR) e Pacemaker, você pode usar um disco compartilhado do Azure para dispositivos de SBD em clusters com até cinco nós por site de replicação, devido ao limite atual de maxShares.
    • Não recomendamos anexar um dispositivo de SBD com disco compartilhado do Azure nos clusters do Pacemaker.
    • Se você usa vários dispositivos SBD de disco compartilhado do Azure, verifique o limite para o número máximo de discos de dados que podem ser anexados a uma VM.
    • Para obter mais informações sobre as limitações dos discos compartilhados do Azure, examine com atenção a seção "Limitações" da Documentação do disco compartilhado do Azure.

Usar um agente de limitação do Azure

Você pode configurar o isolamento usando um agente de isolamento do Azure. O agente de isolamento do Azure requer identidades gerenciadas para as VMs de cluster ou uma entidade de serviço ou identidade de sistema gerenciada (MSI) que gerencie a reinicialização de nós com falha por meio de APIs do Azure. O agente de limitação do Azure não exige a implantação de máquinas virtuais adicionais.

SBD com um servidor de destino iSCSI

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

Configurar o servidor de destino iSCSI

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

  1. Implante máquinas virtuais que são executadas na versão do sistema operacional do RHEL com suporte e conecte-se a elas por meio de SSH. As VMs não precisam ser grandes. Tamanhos de VM como o Standard_E2s_v3 ou Standard_D2s_v3 são suficientes. Use o armazenamento Premium para o disco do SO.

  2. Não é necessário usar o RHEL para SAP com HA e serviços de atualização, ou a imagem do sistema operacional do RHEL para Aplicativos SAP para o servidor de destino iSCSI. Em vez disso, poder ser usada uma imagem padrão do sistema operacional do RHEL. No entanto, lembre-se de que o ciclo de vida de suporte varia entre diferentes versões de produto do sistema operacional.

  3. Execute os seguintes comandos em todas as máquinas virtuais de destino iSCSI.

    1. Atualize o RHEL.

      sudo yum -y update

      Observação

      Talvez você precise reinicializar o nó após atualizar ou fazer um upgrade do sistema operacional.

    2. Instale os pacotes 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. Abra uma 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 do iSCSI

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

  • ascsnw1: representa o cluster ASCS/ERS do NW1.
  • dbhn1: representa o cluster de banco de dados do HN1.
  • sap-cl1 e sap-cl2: nomes de host dos nós de cluster ASCS/ERS do 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.

  1. Crie a pasta raiz para todos os dispositivos SBD.

    sudo mkdir /sbd

  2. Crie o dispositivo de 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

  3. Crie o dispositivo de 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

  4. Salve a configuração targetcli.

    sudo targetcli saveconfig

  5. Verifique para se certificar de que 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 somente ao nó 1. [2]: aplica-se somente ao nó 2.

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

  1. [A] Instale ou atualize os utilitários do iniciador iSCSI em todos os nós do cluster.

    sudo yum install -y iscsi-initiator-utils

  2. [A] Instale os pacotes de cluster e SBD em todos os nós do cluster.

    sudo yum install -y pcs pacemaker sbd fence-agents-sbd

  3. [A] Habilite o serviço de iSCSI.

    sudo systemctl enable iscsid iscsi

  4. [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

  5. [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

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

    sudo systemctl restart iscsid 
sudo systemctl restart iscsi

  7. [A] Conecte os dispositivos iSCSI. No exemplo a seguir, 10.0.0.17 é o endereço IP do servidor de destino do iSCSI e 3260 é a porta padrão. O nome do destino iqn.2006-04.ascsnw1.local:ascsnw1 é 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

  8. [A] Se estiver usando vários dispositivos de SBD, conecte-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

  9. [A] Se estiver usando vários dispositivos de 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

  10. [A]Certifique-se de que os dispositivos de iSCSI estejam disponíveis e anote o nome do dispositivo. No exemplo a seguir, três dispositivos de 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

  11. [A] Recupere as 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. É recomendável usar a ID que começa com scsi-3. No exemplo anterior, as IDs são:

    • /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2
    • /dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d
    • /dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65

  12. [1] Crie o dispositivo SBD.

    1. 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

    2. Crie também o segundo e o 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

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

    1. Abra o arquivo de configuração do SBD.

      sudo vi /etc/sysconfig/sbd

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

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

  14. [A] Execute o comando a seguir para carregar o módulo softdog.

    modprobe softdog

  15. [A] Execute o comando a seguir para garantir que o softdog seja carregado automaticamente após uma reinicialização de nó.

    echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load

  16. [A] O valor do tempo limite do serviço de SBD é definido como 90s por padrão. No entanto, se o valor SBD_DELAY_START for definido como yes, o serviço de SBD atrasará seu início até depois do tempo limite de msgwait. Portanto, o valor do tempo limite do serviço de SBD deve exceder o tempo limite de msgwait 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 quando você quiser usar um dispositivo de 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, consulte Implantar um disco ZRS.

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

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

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

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

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

Configurar um dispositivo SBD de disco compartilhado do Azure

  1. [A] Instale os pacotes de cluster e SBD em todos os nós do cluster.

    sudo yum install -y pcs pacemaker sbd fence-agents-sbd

  2. [A] Certifique-se de que o disco anexado 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

  3. [A] Recupere a ID do dispositivo do disco compartilhado anexado.

    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

    A ID do dispositivo de lista de comandos para o disco compartilhado anexado. É recomendável usar a ID que começa com scsi-3. Nesse exemplo, a ID é /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107.

  4. [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

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

    1. Abra o arquivo de configuração do SBD.

      sudo vi /etc/sysconfig/sbd

    2. Altere a propriedade do dispositivo de SBD, habilite a integração do Pacemaker e altere o modo inicial do SBD.

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

  6. [A] Execute o comando a seguir para carregar o módulo softdog.

    modprobe softdog

  7. [A] Execute o comando a seguir para garantir que o softdog seja carregado automaticamente após uma reinicialização de nó.

    echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load

  8. [A] O valor do tempo limite do serviço de SBD é definido como 90 segundos por padrão. No entanto, se o valor SBD_DELAY_START for definido como yes, o serviço de SBD atrasará seu início até depois do tempo limite de msgwait. Portanto, o valor do tempo limite do serviço de SBD deve exceder o tempo limite de msgwait 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 isolamento do Azure

O dispositivo de isolamento usa uma identidade gerenciada para recursos do Azure ou uma entidade de serviço para autorização no Azure. Dependendo do método de gerenciamento de identidade, siga os procedimentos apropriados:

  1. Configurar o gerenciamento de identidades

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

    Para criar uma MSI (identidade gerenciada), crie uma identidade gerenciada atribuída pelo sistema para cada VM no cluster. Se já existir, uma identidade gerenciada atribuída pelo sistema será usada. Não use identidades gerenciadas atribuídas pelo usuário com o Pacemaker no momento. Há suporte para um dispositivo de isolamento, baseado na identidade gerenciada, no RHEL 7.9 e no RHEL 8.x/RHEL 9.x.

  2. Criar uma função personalizada para o agente de limite

    Por padrão, a identidade gerenciada e a entidade de serviço não têm permissões para acessar seus recursos do Azure. Você precisa fornecer permissões à identidade gerenciada ou à entidade de serviço para iniciar e parar (desligar) todas as VMs do cluster. Se você ainda não criou a função personalizada, poderá 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 pelas IDs da sua assinatura. 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": []
}

  3. Atribuir a função personalizada

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

    Atribua a função personalizada Linux Fence Agent Role que foi criada na última seção a cada identidade gerenciada das VMs do cluster. Cada identidade gerenciada atribuída pelo sistema da VM precisa da função atribuída para o recurso de cada VM de cluster. Para obter mais informações, confira Atribuir o acesso de uma identidade gerenciada a um recurso usando o portal do Azure. Verifique se a atribuição de função da identidade gerenciada de cada VM contém todas as VMs do cluster.

    Importante

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

Instalação do Cluster

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

  1. [A] Instale o complemento de HA do RHEL.

    sudo yum install -y pcs pacemaker nmap-ncat

  2. [A] No RHEL 9.x, instale os agentes de recursos para implantação na nuvem.

    sudo yum install -y resource-agents-cloud

  3. [A] Instale o pacote de agentes de isolamento se estiver usando um dispositivo de isolamento baseado no agente de isolamento do Azure.

    sudo yum install -y fence-agents-azure-arm

    Importante

    Recomendamos as versões a seguir (ou posterior) do agente de isolamento do Azure para clientes que desejam usar as identidades gerenciadas para recursos do Azure em vez de nomes de entidade de serviço para o agente de isolamento:

    • RHEL 8.4: fence-agents-4.2.1-54.el8.
    • RHEL 8.2: fence-agents-4.2.1-41.el8_2.4
    • RHEL 8.1: fence-agents-4.2.1-30.el8_1.4
    • RHEL 7.9: fence-agents-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 isolamento do Azure:

    • fence-agents-4.10.0-20.el9_0.7
    • fence-agents-common-4.10.0-20.el9_0.6
    • ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm

    Verifique a versão do agente de isolamento do Azure. Se necessário, atualize-o para a versão mínima necessária ou posterior.

    # Check the version of the Azure Fence Agent
sudo yum info fence-agents-azure-arm

    Importante

    Se precisar atualizar o agente de isolamento do Azure e estiver usando uma função personalizada, atualize-a para incluir a ação powerOff. Para obter mais informações, confira Criar uma função personalizada para o agente de isolamento.

  4. [A] Configurar a resolução de nome do 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ê está usando nomes de host na configuração do cluster, é essencial ter uma resolução de nome de host confiável. A comunicação do cluster falhará se os nomes não estiverem disponíveis, o que pode resultar em atrasos de failover de cluster.

    A vantagem de usar /etc/hosts é que o cluster se torna independente do DNS, o que também pode ser um ponto único de falhas.

    sudo vi /etc/hosts

    Insira as seguintes linhas até /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

  5. [A] Altere a senha de hacluster para a mesma senha.

    sudo passwd hacluster

  6. [A] Adicione regras de firewall ao Pacemaker.

    Adicione as seguintes regras de firewall para todas as comunicações de cluster entre os nós do cluster.

    sudo firewall-cmd --add-service=high-availability --permanent
sudo firewall-cmd --add-service=high-availability

  7. [A] Habilite serviços básicos de cluster.

    Execute os seguintes comandos para habilitar o serviço Pacemaker e iniciá-lo.

    sudo systemctl start pcsd.service
sudo systemctl enable pcsd.service

  8. [1] Crie um cluster do 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 memória. Para obter mais informações, confira 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

  9. [A] Defina 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

    Dica

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

  10. [1] Permita ações simultâneas de isolamento.

    sudo pcs property set concurrent-fencing=true

Criar um dispositivo de isolamento no cluster do Pacemaker

Dica

  • Para evitar corridas de isolamento dentro de um cluster do Pacemaker de dois nós, você pode configurar a propriedade do cluster priority-fencing-delay. Essa propriedade introduz um atraso adicional no isolamento de um nó que tem uma prioridade total de recursos mais alta quando ocorre um cenário de split-brain. Para obter mais informações, confira O Pacemaker pode isolar o nó de cluster com o menor número de recursos em execução?.
  • A propriedade priority-fencing-delay é aplicável ao Pacemaker versão 2.0.4-6.el8 ou superior e a um cluster de dois nós. Se você configurar a propriedade do cluster priority-fencing-delay, não precisará definir a propriedade pcmk_delay_max. No entanto, se a versão do Pacemaker for menor que 2.0.4-6.el8, você precisará definir a propriedade pcmk_delay_max.
  • Para obter instruções sobre como definir a propriedade do cluster priority-fencing-delay, confira os respectivos documentos de HA de expansão do SAP ASCS/ERS e do SAP HANA.

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

SBD como dispositivo de isolamento

  1. [A] Habilite o serviço de SBD.

    sudo systemctl enable sbd

  2. [1] Para o dispositivo de SBD configurado usando servidores de destino iSCSI ou discos compartilhados do Azure, execute os comandos a seguir.

    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

  3. [1] Reinicie 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

    Observação

    Caso se depare com o seguinte erro ao iniciar o cluster do Pacemaker, você poderá desconsiderar a mensagem. Alternativamente, você pode iniciar o cluster usando o comando pcs cluster start --all --request-timeout 140.

    Erro: não foi possível iniciar todos os nós node1/node2; não foi possível se conectar ao nó1/node2, verifique se o pcsd está em execução no nó em questão ou tente definir um tempo limite mais alto com a opção --request-timeout (a operação atingiu o tempo limite após 60.000 milissegundos com 0 bytes recebidos)

Agente de isolamento do Azure como dispositivo de isolamento

  1. [1] Após atribuir funções aos dois nós de cluster, você poderá configurar os dispositivos de isolamento no cluster.

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

  2. [1] Execute o comando apropriado, dependendo de você estar usando uma identidade gerenciada ou uma entidade de serviço para o agente de isolamento do Azure.

    Observação

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

    Consulte a seção em negrito no comando. Para obter mais informações, confira Qual formato devo usar para especificar os mapeamentos de nó para os dispositivos de isolamento em pcmk_host_map?.

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

    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 o RHEL 8.x/9.x, use o seguinte comando para configurar o dispositivo de isolamento:

    # 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

Se você estiver usando um dispositivo de isolamento, baseado na configuração da entidade de serviço, leia Alterar de SPN para MSI para clusters do Pacemaker usando o isolamento do Azure e saiba como fazer a conversão para a configuração da identidade gerenciada.

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

Dica

O agente de isolamento do Azure exige a conectividade de saída com pontos de extremidade públicos. Para obter mais informações, além das possíveis soluções, confira Conectividade de ponto de extremidade público para VMs usando o ILB padrão.

Configurar o Pacemaker para eventos agendados do Azure

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

O agente de recursos azure-events-az do Pacemaker monitora os eventos agendados do Azure. Se os eventos forem detectados e o agente de recursos determinar que outro nó de cluster está disponível, ele definirá um atributo de integridade do cluster.

Quando o atributo de integridade do cluster é definido para um nó, a restrição de local dispara e todos os recursos com nomes que não começam com health- são migrados para longe do nó com o evento agendado. Depois que o nó de cluster afetado estiver livre dos recursos de cluster em execução, o evento agendado será reconhecido e poderá executar a respectiva ação, como reinicialização.

  1. [A] Verifique se o pacote do agente azure-events-az 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 da 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

  2. [1] Configure os recursos no Pacemaker.

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

  3. [1] Defina a estratégia e a restrição do nó de integridade do cluster do 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 outros recursos no cluster que começam com health-, além dos recursos descritos nas próximas etapas.

  4. [1] Defina o valor inicial dos atributos do cluster. Execute-o para cada nó de cluster e para ambientes de expansão, incluindo a VM do criador da maioria.

    sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0
sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0

  5. [1] Configure os recursos no Pacemaker. Verifique se os recursos começam 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

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

    sudo pcs property set maintenance-mode=false

  7. Limpe os erros durante a habilitação e verifique se os recursos health-azure-events foram iniciados com êxito em todos os nós do cluster.

    sudo pcs resource cleanup

    A primeira execução de consulta para eventos agendados pode demorar até 2 minutos. Os testes do Pacemaker com eventos agendados podem usar ações de reinicialização ou reimplantação nas VMs do cluster. Para saber mais, confira Eventos agendados.

Configuração opcional de isolamento

Dica

Esta seção só será aplicável se você quiser configurar o dispositivo de isolamento especial fence_kdump.

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

Importante

Lembre-se de que, quando fence_kdump estiver configurado como um dispositivo de isolamento de primeiro nível, ele apresentará atrasos nas operações de isolamento e, respectivamente, atrasos no failover de recursos do aplicativo.

Se um despejo de memória for detectado com êxito, o isolamento será atrasado até que o serviço de recuperação de pane seja concluído. Se o nó com falha estiver inacessível ou não responder, o isolamento será atrasado por tempo determinado pelo número configurado de iterações e o tempo limite de fence_kdump. Para obter mais informações, confira Como fazer para configurar o fence_kdump em um cluster do Red Hat Pacemaker?.

O tempo limite proposto fence_kdump pode precisar ser adaptado ao ambiente específico.

Recomendamos que você configure o isolamento por fence_kdump somente quando for preciso coletar diagnósticos dentro da VM e sempre em combinação com métodos de isolamento tradicionais, como o SBD ou o agente de isolamento do Azure.

Os seguintes artigos da base de dados de conhecimento da Red Hat contêm informações importantes sobre a configuração do isolamento de fence_kdump:

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

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

    systemctl is-active kdump
# Expected result
# active

  2. [A] Instale o agente de isolamento fence_kdump.

    yum install fence-agents-kdump

  3. [1] Crie um dispositivo de isolamento fence_kdump 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

  4. [1] Configure níveis de isolamento para que o mecanismo de isolamento fence_kdump seja ativado 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>

  5. [A] Permita as portas necessárias para fence_kdump no firewall.

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

  6. [A] Execute a configuração de fence_kdump_nodes em /etc/kdump.conf para evitar uma falha de fence_kdump com um tempo limite para algumas versões do kexec-tools. Para obter mais informações, confira o fence_kdump atinge o tempo limite quando o fence_kdump_nodes não é especificado com kexec-tools versão 2.0.15 ou posterior e o fence_kdump falha com “tempo limite atingido após X segundos” em clusters de Alta Disponibilidade do RHEL 6 ou 7 com kexec-tools de versões anteriores à 2.0.14. A configuração de exemplo para um cluster de dois nós é apresentada aqui. Depois que você faz uma alteração em /etc/kdump.conf, a imagem do kdump precisa ser regenerada. Para regenerá-la, reinicie o serviço kdump.

    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

  7. [A] Verifique se o arquivo de imagem initramfs contém os arquivos fence_kdump e hosts. Para obter mais informações, confira Como fazer para configurar o fence_kdump em um cluster do 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

  8. Teste a configuração causando falha em um nó. Para obter mais informações, confira Como fazer para configurar o fence_kdump em um cluster do Red Hat Pacemaker?.

    Importante

    Se o cluster já estiver em uso produtivo, planeje o teste de acordo, pois a falha de um nó tem um impacto sobre o aplicativo.

    echo c > /proc/sysrq-trigger

Próximas etapas