Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo explica como configurar e configurar um cluster básico de dois nós Pacemaker no Red Hat Enterprise Linux (RHEL). As instruções cobrem RHEL 8.6+, RHEL 9.x, e RHEL 10.x.
Pré-requisitos
Documentação de Alta Disponibilidade (HA) do RHEL
- Como configurar e gerenciar Clusters de Alta Disponibilidade.
- Políticas de Suporte para Clusters de Alta Disponibilidade do RHEL: sbd e fence_sbd.
- Políticas de Suporte para Clusters de Alta Disponibilidade do RHEL: fence_azure_arm.
- Limitações Conhecidas do Watchdog Emulado por Software.
- Explorando os Componentes de Alta Disponibilidade do RHEL: sbd e fence_sbd.
- Diretrizes de design para Clusters de Alta Disponibilidade do RHEL: considerações sobre sbd.
- Considerações sobre a adoção do RHEL 8: Alta Disponibilidade e Clusters
documentação do RHEL específica para o Azure
Documentação do RHEL para ofertas do SAP
Visão geral
Este guia assume que você já implantou o grupo de recursos necessário, a rede virtual do Azure, a sub-rede e as máquinas virtuais (VMs).
Clusters em execução no Linux requerem um agente de isolamento para isolar nós não íntegros. Para realizar essa tarefa no Azure, use um dos seguintes métodos:
- Storage Based Death (SBD) com Disco Compartilhado do Azure
- Morte Baseada em Armazenamento (SBD) com alvos iSCSI
- Agente de Isolamento do Azure
Observação
Os seguintes prefixos são usados neste documento:
- [A]: Aplicável a todos os nós.
- [1]: aplicável somente ao nó 1.
- [2]: aplicável somente ao nó 2.
Importante
No Azure, clusters RHEL de alta disponibilidade com isolamento baseado em armazenamento (fence_sbd) utilizam um watchdog emulado por software. Revise a documentação a seguir ao usar o SBD.
Usando SBD com o Azure Shared Disk
Ao usar Azure Shared Disks, você pode montar o mesmo disco em todas as máquinas virtuais que fazem parte do cluster. Você pode hospedar seu dispositivo SBD nesse disco compartilhado sem exigências adicionais de infraestrutura.
Benefícios
- Oferece uma opção nativa de dispositivo de bloco compartilhado do Azure para SBD sem exigir recursos adicionais.
- Máquinas virtuais conectam o disco gerenciado diretamente, reduzindo a dependência de considerações adicionais da rede.
Considerações importantes
- Você pode usar um disco compartilhado do Azure com o
Premium SSDSKU como um dispositivo SBD. - Revise a lista de sistemas operacionais suportados.
- Dispositivos SBD que utilizam disco compartilhado premium Azure suportam armazenamento redundante local (LRS) e armazenamento redundante por zona (ZRS).
- Dependendo do tipo de sua implantação, escolha o armazenamento redundante apropriado para um disco compartilhado Azure como seu dispositivo SBD.
- Um dispositivo SBD que usa LRS para o disco compartilhado Premium do Azure (skuName - Premium_LRS) só tem suporte com a implantação no conjunto de disponibilidade.
- Um dispositivo SBD que usa ZRS para um disco compartilhado premium Azure (skuName - Premium_ZRS) é recomendado para implantações em zonas de disponibilidade.
- O Azure disco compartilhado 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 um cluster de dois nós, como SAP ASCS/ERS ou SAP HANA scale-up.
- Para clusters com mais de dois nós, consulte o valor de maxShares documentado para o disco selecionado.
- Não anexe um dispositivo SBD de disco compartilhado do Azure entre clusters diferentes do Pacemaker.
- Se você usar vários dispositivos SBD de disco compartilhado Azure, verifique o limite de 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 Azure discos compartilhados, examine cuidadosamente a seção "Limitações" da documentação Azure disco compartilhado.
Usando SBD com alvos iSCSI
Essa solução exige que você hospede alvos de Internet Small Computer System Interface (iSCSI) em pelo menos uma máquina virtual (VM) adicional.
Benefícios
- Esses servidores host iSCSI também podem hospedar alvos iSCSI para outros clusters Pacemaker na mesma região.
- Se você já está usando eles no local, eles não exigem mudanças na forma como você opera o cluster Pacemaker.
Considerações importantes
- Você deve usar três servidores host iSCSI para ter o mais alto nível de resiliência para seu cluster.
- Usar apenas um servidor cria um único ponto de falha que impede o isolamento do seu cluster se esse servidor ficar fora do ar.
- O Pacemaker não permite isolamento se você tiver apenas dois destinos e um deles estiver indisponível.
- Os servidores host iSCSI de destino devem residir na mesma região dos seus clusters.
- O roteamento de rede entre seus clusters e servidores host iSCSI não deve atravessar nenhum dispositivo de rede não redundante (como um Appliance Virtual de Rede).
- Eventos de manutenção e outros problemas com dispositivos de rede podem afetar negativamente a estabilidade e confiabilidade da configuração geral do cluster.
Usando o Fence Agent do Azure
Usando o Agente de isolamento do Azure, seu cluster pode isolar nós chamando diretamente as APIs do Azure para reiniciar nós com falha.
Benefícios
- Não são necessários recursos extras.
- Identidades gerenciadas removem qualquer manutenção de credencial.
Considerações importantes
- Use Identidades Gerenciadas para autenticação. Se você está usando um principal de serviço atualmente, atualize o Azure Fence Agent do SPN para o MSI.
- O fence agent do Azure requer conectividade de saída com os endpoints públicos do Azure. 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.
- 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.
Implante um disco compartilhado do Azure para SBD
Para criar e anexar um disco compartilhado no Azure usando o PowerShell, execute os seguintes comandos. Se você quiser implantar recursos usando a CLI do Azure ou o portal Azure, veja Implantar um disco ZRS.
$ResourceGroup = "<ResourceGroupName>"
$DiskSizeInGB = 4
$DiskName = "<SBDDiskName>"
# Must be Equal to or greater than the Number of Nodes in the Cluster
$ShareNodes = 2
# Options are "Premium_LRS" or "Premium_ZRS"
$SKUName = "<DiskSKU>"
# VMs to attach the disk to
$vmNames = @("sap-cl1", "sap-cl2")
# Lun to attach the disk to. You should use the same lun on all servers in the cluster.
$lunNumber = <lunNumber>
$diskConfig = New-AzDiskConfig -Location $Location -SkuName $SkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $diskConfig
# Attach SBD disk to cluster VMs
foreach ($vmName in $vmNames)
{
$vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $lunNumber
Update-AzVM -VM $vm -ResourceGroupName $resourceGroup -Verbose
}
Uso de alvos iSCSI
Configurar servidores host de destino iSCSI
Implante três máquinas virtuais que rodem em uma versão suportada do RHEL OS. As VMs não precisam ser grandes. Tamanhos de VM como Standard_E2s ou Standard_D2s são suficientes.
Observação
Você não precisa usar o RHEL for SAP com HA e Update Services nem a imagem de sistema operacional do RHEL for SAP Apps para o servidor de destino iSCSI. Você pode usar uma imagem padrão do RHEL OS em vez disso. No entanto, o ciclo de vida de suporte varia entre diferentes versões de produtos do sistema operacional.
Instale as atualizações mais recentes e reinicie se necessário.
sudo dnf -y updateInstale o pacote de destino iSCSI.
sudo dnf install -y targetcliAtive e inicie o serviço iSCSI.
sudo systemctl start target sudo systemctl enable targetAbra a porta do firewall.
sudo firewall-cmd --add-port=3260/tcp --permanent sudo firewall-cmd --reload
Criar alvos iSCSI
Para cada cluster, você precisa provisionar um disco iSCSI em cada servidor host iSCSI e então conceder acesso a cada nó do cluster a esse disco. Neste exemplo, você cria discos para dois clusters diferentes:
- ascsnw1: O cluster ASCS/ERS para NW1
- hdbnw1: O cluster de banco de dados HANA para NW1
- sap-cl1 e sap-cl2: Nomes de host para os nós do cluster ASCS/ERS do NW1
- sap-db1 e sap-db2: Nomes de host para os nós do cluster HANA do NW1
- Crie a pasta raiz para todos os dispositivos SBD.
sudo mkdir /sbd - Crie o dispositivo SBD para o primeiro cluster (ascsnw1).
# Create Storage Object sudo targetcli backstores/fileio create sbdascsnw1 /sbd/sbdascsnw1 50M write_back=false # Create iSCSI Target sudo targetcli iscsi/ create iqn.2006-04.ascsnw1.local:ascsnw1 # Creates the LUN and attaches it to the iSCSI Target sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/luns/ create /backstores/fileio/sbdascsnw1 # Grant Cluster Node 1 (sap-cl1) access to the iSCSI Target sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl1.local:sap-cl1 # Grant Cluster Node 2 (sap-cl2) access to the iSCSI Target 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 segundo cluster (hdbnw1).
# Create Storage Object sudo targetcli backstores/fileio create sbdhdbnw1 /sbd/sbdhdbnw1 50M write_back=false # Create iSCSI Target sudo targetcli iscsi/ create iqn.2006-04.hdbnw1.local:hdbnw1 # Creates the LUN and attaches it to the iSCSI Target sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/luns/ create /backstores/fileio/sbdhdbnw1 # Grant Cluster Node 1 (sap-db1) access to the iSCSI Target sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/acls/ create iqn.2006-04.sap-db1.local:sap-db1 # Grant Cluster Node 2 (sap-db2) access to the iSCSI Target sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/acls/ create iqn.2006-04.sap-db2.local:sap-db2 - Salve a configuração.
sudo targetcli saveconfig - Verifique a configuração.
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- sbdhdbnw1 ....................................... [/sbd/sbdhdbnw1 (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.hdbnw1.local:hdbnw1 ......................................................... [TPGs: 1] | | o- tpg1 ..................................................................... [no-gen-acls, no-auth] | | o- acls ................................................................................ [ACLs: 2] | | | o- iqn.2006-04.sap-db1.local:sap-db1 .......................................... [Mapped LUNs: 1] | | | | o- mapped_lun0 ..................................................... [lun0 fileio/sbdhdb (rw)] | | | o- iqn.2006-04.sap-db2.local:sap-db2 .......................................... [Mapped LUNs: 1] | | | o- mapped_lun0 ..................................................... [lun0 fileio/sbdhdb (rw)] | | o- luns ................................................................................ [LUNs: 1] | | | o- lun0 ................................. [fileio/sbdhdbnw1 (/sbd/sbdhdbnw1) (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/sbdascsnw1 (rw)] | | o- iqn.2006-04.sap-cl2.local:sap-cl2 .......................................... [Mapped LUNs: 1] | | o- mapped_lun0 ................................................. [lun0 fileio/sbdascsnw1 (rw)] | o- luns ................................................................................ [LUNs: 1] | | o- lun0 ............................... [fileio/sbdascsnw1 (/sbd/sbdascsnw1) (default_tg_pt_gp)] | o- portals .......................................................................... [Portals: 1] | o- 0.0.0.0:3260 ........................................................................... [OK] o- loopback ............................................................................... [Targets: 0]
Configurar o agente de isolamento do Azure
Criar identidade
Para criar uma identidade gerenciada (MSI), crie uma identidade gerenciada atribuída pelo sistema para cada VM no cluster. Identidades gerenciadas atribuídas por usuários não são suportadas no momento.
Criar uma função personalizada.
Sua identidade precisa de permissões por meio do Azure RBAC para executar ações de isolamento em relação às suas VMs. Para cumprir o Modelo de Segurança de Acesso Mínimo Privilegiado (LPA), crie um papel RBAC personalizado.
Use a seguinte definição para seu cargo, substituindo seu(s) ID(s) de assinatura quando necessário:
{ "Name": "Linux Fence Agent", "description": "Allowed to power-off and start virtual machines", "assignableScopes": [ "/subscriptions/<Subscription 1 ID (GUID)>", "/subscriptions/<Subscription N ID (GUID)>" ], "actions": [ "Microsoft.Compute/*/read", "Microsoft.Compute/virtualMachines/powerOff/action", "Microsoft.Compute/virtualMachines/start/action" ], "notActions": [], "dataActions": [], "notDataActions": [] }Atribua o papel personalizado às suas identidades.
Para cada VM do seu cluster, atribua sua identidade gerenciada ao papel personalizado "Linux Fence Agent" para cada VM do cluster, incluindo ela mesma. Para obter etapas detalhadas, confira Atribuir o acesso de uma identidade gerenciada a um recurso usando o portal do Azure.
Importante
Esteja ciente de que a atribuição e a remoção de autorização com identidades gerenciadas podem sofrer atraso até entrarem em vigor.
Criar e configurar o cluster
[A] Atualize o sistema operacional e reinicie se necessário.
sudo dnf -y update[A] Instalar pacotes de cluster necessários.
sudo dnf install -y nmap-ncat pcs pacemaker resource-agents resource-agents-cloud[A] Instalação dos pacotes de cercas necessários.
sudo dnf install -y sbd fence-agents-sbdsudo dnf install -y sbd fence-agents-sbd iscsi-initiator-utilssudo dnf install -y fence-agents-azure-arm[A] Configurar DNS.
Você pode usar um servidor DNS ou modificar
/etc/hostsem todos os nós. Este exemplo mostra como usar o arquivo/etc/hosts.Atualize as entradas para corresponder aos seus IPs e nomes de host.
sudo vi /etc/hosts [...] # IP address of cluster node 1 10.27.0.6 sap-cl1 # IP address of cluster node 2 10.27.0.7 sap-cl2sudo vi /etc/hosts [...] # IP address of cluster node 1 10.0.0.6 sap-cl1 # IP address of cluster node 2 10.0.0.7 sap-cl2 # IP address of iSCSI Target Host Server 1 10.0.0.17 sbd-iscsi1 # IP address of iSCSI Target Host Server 1 10.0.0.18 sbd-iscsi2 # IP address of iSCSI Target Host Server 1 10.0.0.19 sbd-iscsi3[A] Atualize a senha
haclusterpara que seja a mesma em todos os nós.sudo passwd hacluster[A] Atualize o firewall.
sudo firewall-cmd --add-service=high-availability --permanent sudo firewall-cmd --reload[A] Habilitar os serviços do Pacemaker.
sudo systemctl start pcsd.service sudo systemctl enable pcsd.service[1] Crie o agrupamento.
sudo pcs host auth sap-cl1 sap-cl2 -u hacluster sudo pcs cluster setup ascsnw1 sap-cl1 sap-cl2 totem token=30000 sudo pcs cluster start --allConfigure um atraso de inicialização para o Pacemaker.
Iniciar o Pacemaker imediatamente após a inicialização pode permitir que o nó retorne ao cluster antes que o failover seja concluído, o que impede o failover ou atrasa a recuperação. Para resolver esse problema, use um serviço de temporizador para atrasar a inicialização do marcapasso na reinicialização.
-
[A] Configurar o serviço de temporizador.
sudo vi /etc/systemd/system/pacemaker.timer[Unit] Description=Delay start of pacemaker.service after boot [Timer] OnBootSec=186 Unit=pacemaker.service [Install] WantedBy=timers.target -
[A] Ativar o serviço de temporizador.
sudo systemctl daemon-reload sudo systemctl enable pacemaker.timer -
[1] Desative os serviços do Pacemaker.
sudo pcs cluster disable --all
-
[A] Configurar o serviço de temporizador.
Valide o agrupamento.
-
[1] Validar o cluster do Pacemaker.
sudo pcs status Cluster name: ascsnw1 Cluster Summary: * Stack: corosync (Pacemaker is running) * Current DC: sap-cl1 (version 3.0.0-5.1.el10_0-8818a21) - partition with quorum * Last updated: Tue May 19 22:15:08 2026 on sap-cl1 * Last change: Tue Apr 21 23:11:34 2026 by root via root on sap-cl1 * 2 nodes configured * 0 resource instances configured Node List: * Online: [ sap-cl1 sap-cl2 ] Full List of Resources: Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled -
[A] Validar serviços.
systemctl list-unit-files pacemaker.timer pacemaker.service corosync.service pcsd.serviceUNIT FILE STATE PRESET corosync.service disabled disabled pacemaker.service disabled disabled pacemaker.timer enabled disabled pcsd.service enabled disabled
-
[1] Validar o cluster do Pacemaker.
Configurar o isolamento
-
[A] Ativem o serviço SBD.
sudo systemctl enable sbd -
[A] Ativar o watchdog de software.
echo softdog | sudo tee /etc/modules-load.d/softdog.conf sudo modprobe softdog -
[A] Descubra o ID do dispositivo iSCSI.
- Determine o ponto de montagem com base no número LUN
ls -l /dev/disk/azure/scsi1/lun1 lrwxrwxrwx. 1 root root 12 Apr 16 20:22 /dev/disk/azure/scsi1/lun1 -> ../../../sdb - Obtenha o ID do dispositivo iSCSI a partir da montagem.
ls -l /dev/disk/by-id/scsi-3* | grep -i sdb lrwxrwxrwx. 1 root root 9 Apr 16 20:22 /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -> ../../sdb
- Determine o ponto de montagem com base no número LUN
-
[1] Crie o dispositivo SBD.
sudo sbd -d /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -1 60 -4 120 create
-
[1] Adicionar o dispositivo SBD ao cluster.
sudo pcs stonith create sbd fence_sbd devices=/dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 op monitor interval=600 timeout=15 -
[1] Alterar as configurações do SBD.
sudo pcs property set stonith-timeout=210 sudo pcs property set stonith-enabled=true -
[A] Validar o arquivo de configuração SBD.
sudo vi /etc/sysconfig/sbd[...] SBD_DELAY_START=no [...] SBD_PACEMAKER=yes [...] SBD_STARTMODE=always [...]
-
[A] Habilitar os serviços necessários.
sudo systemctl enable sbd iscsi iscsid -
[A] Ativar o watchdog de software.
echo softdog | sudo tee /etc/modules-load.d/softdog.conf sudo modprobe softdog -
[1] Atualize o
InitiatorNamedo nó 1.sudo vi /etc/iscsi/initiatorname.iscsi [...] InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1 -
[2] Atualize o
InitiatorNamedo nó 2.# Node 2 sudo vi /etc/iscsi/initiatorname.iscsi [...] InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2 -
[A] Reinicie os serviços iSCSI.
sudo systemctl restart iscsi iscsid -
[A] Monte os destinos iSCSI de todos os servidores host de iSCSI.
for hostServer in sbd-iscsi1 sbd-iscsi2 sbd-iscsi3; do iscsiadm -m discovery --type=st --portal=${hostServer}:3260 iscsiadm -m node -T iqn.2006-04.ascsnw1.local:ascsnw1 --login --portal=${hostServer}:3260 iscsiadm -m node --portal=${hostServer}:3260 -T iqn.2006-04.ascsnw1.local:ascsnw1 --op=update --name=node.startup --value=automatic done -
[A] Descubra os IDs dos dispositivos iSCSI.
- Determine os pontos de montagem do iSCSI.
lsscsi [0:0:0:0] disk Msft Virtual Disk 1.0 /dev/sda [1:0:0:1] disk Msft Virtual Disk 1.0 /dev/sdb [2:0:0:0] disk LIO-ORG sbdascsnw1 4.0 /dev/sdc [3:0:0:0] disk LIO-ORG sbdascsnw1 4.0 /dev/sdd [4:0:0:0] disk LIO-ORG sbdascsnw1 4.0 /dev/sde - Obtenha os IDs dos dispositivos iSCSI.
ls -l /dev/disk/by-id/scsi-3* | grep sd[c,d,e] lrwxrwxrwx 1 root root 9 Jul 21 18:02 /dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528 -> ../../sdd lrwxrwxrwx 1 root root 9 Jul 21 17:50 /dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff -> ../../sdc lrwxrwxrwx 1 root root 9 Jul 21 18:04 /dev/disk/by-id/scsi-360014059f135275c24647d49268123e5 -> ../../sde
- Determine os pontos de montagem do iSCSI.
-
[1] Crie os dispositivos SBD.
sudo sbd -d /dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528 -1 60 -4 120 create sudo sbd -d /dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff -1 60 -4 120 create sudo sbd -d /dev/disk/by-id/scsi-360014059f135275c24647d49268123e5 -1 60 -4 120 create
-
[1] Adicione os dispositivos SBD ao cluster.
sudo pcs stonith create sbd fence_sbd \ devices=/dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528,/dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff,/dev/disk/by-id/scsi-360014059f135275c24647d49268123e5 \ op monitor interval=600 timeout=120 -
[1] Alterar as configurações do SBD.
sudo pcs property set stonith-timeout=210 sudo pcs property set stonith-enabled=true -
[A] Validar o arquivo de configuração SBD.
sudo vi /etc/sysconfig/sbd[...] SBD_DELAY_START=no [...] SBD_PACEMAKER=yes [...] SBD_STARTMODE=always [...]
[1] Configurar o agente de isolamento do Azure.
Observação
Ao usar a nuvem governamental do Azure, você deve especificar essa
cloud=opção ao configurar o Azure Fence Agent. Por exemplo,cloud=usgovpara a nuvem Azure do governo dos EUA.sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true \ resourceGroup="<ResourceGroupName>" subscriptionId="<SubscriptionID>" \ pcmk_host_map="sap-cl1:<AzureVMNameCL1>;sap-cl2:<AzureVMNameCL2>" \ power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 \ pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \ meta failure-timeout=120s op monitor interval=3600 timeout=120[1] Configure o cluster para o Azure Fence Agent.
sudo pcs property set stonith-enabled=true sudo pcs property set stonith-timeout=900
Construindo um cluster com Pacemaker com mais de dois nós
Se você está construindo um cluster maior, tenha em mente estas considerações:
[1] Ajuste a configuração do cluster.
Os
Votequorum - Expected votesvalores eVotequorum - Flags - 2Nodese atualizam automaticamente quando você adiciona um terceiro ou mais nós. Valide que a2Nodeflag está ausente eVotequorum - Expected votesé igual ao número de nós no seu cluster.sudo pcs quorum status Quorum information ------------------ [...] Votequorum information ---------------------- Expected votes: 3 Highest expected: 3 Total votes: 3 Quorum: 2 Flags: Quorate WaitForAll Membership information ---------------------- [...]Ajuste a configuração da cerca.
sudo crm resource param stonith-sbd delete pcmk_delay_max sudo crm resource param stonith-sbd set pcmk_action_limit -1sudo crm resource param rsc_st_azure delete pcmk_delay_max sudo crm resource param rsc_st_azure pcmk_action_limit -1
Configurar o Pacemaker para eventos agendados do Azure
Eventos Programados é um Serviço de Metadados do Azure que dá tempo para sua aplicação se preparar para a manutenção da VM. Ele fornece informações sobre eventos de manutenção futuros, como reiniciações, para que sua aplicação possa se preparar para eles e limitar interrupções.
O agente de recursos azure-events-az monitora esse serviço de metadados. Quando o agente detectar eventos e determinar que outro nó do cluster está disponível, ele define o atributo de integridade em nível de nó #health-azure como -1000000. Esse valor faz com que o cluster considere o nó como insalubre e migra recursos para longe do nó afetado. A restrição de localização garante que recursos iniciados por health- são excluídos, já que o agente azure-events-az ainda precisa rodar em ambos os nós. Quando não houver mais recursos de cluster em execução no nó de cluster afetado, o agente notificará o serviço de metadados, e o evento programado poderá continuar. Quando todos os eventos terminam, o agente de recursos define o atributo #health-azure de volta como 0, marcando o nó como íntegro novamente.
Importante
Anteriormente, este documento descrevia o uso do agente de recursos azure-events. O novo agente de recursos azure-events-az oferece suporte total aos ambientes do Azure implantados em diferentes zonas de disponibilidade. Use o agente azure-events-az mais recente em todos os sistemas SAP de alta disponibilidade com Pacemaker.
Instale e atualize o
resource-agentspacote.sudo dnf install -y resource-agents[1] Coloque o cluster em modo de manutenção.
sudo pcs property set maintenance-mode=true[1] Definir a estratégia e a restrição do nó de integridade do cluster do Pacemaker.
Importante
Não defina outros recursos no cluster que começam com
health-, além dos recursos descritos nas próximas etapas.sudo pcs property set node-health-strategy=custom sudo pcs constraint location 'regexp%!health-.*' \ rule score-attribute='#health-azure' \ "defined #uname"[1] Defina o valor inicial dos atributos do cluster.
Execute um comando para cada nó do cluster. Para ambientes com expansão horizontal, inclua a VM do fabricante principal.
# Node 1 sudo crm_attribute --node sap-cl1 --name '#health-azure' --update 0 # Node 2 sudo crm_attribute --node sap-cl2 --name '#health-azure' --update 0 # Node N sudo crm_attribute --node sap-clN --name '#health-azure' --update 0[1] Configure os recursos no Pacemaker. Os recursos devem começar com
health-azure.sudo pcs resource create health-azure-events \ ocf:heartbeat:azure-events-az \ meta failure-timeout=120s \ op monitor interval=10s timeout=240s \ op start timeout=10s start-delay=90ssudo pcs resource clone health-azure-events meta allow-unhealthy-nodes=trueRetire o cluster do Pacemaker do modo de manutenção e limpe todos os erros
sudo pcs property set maintenance-mode=false sudo pcs resource cleanupVerifique se
health-azure-eventsinicia com sucesso em todos os nós.sudo pcs status Cluster name: ascsnw1 Cluster Summary: * Stack: corosync (Pacemaker is running) * Current DC: sap-cl1 (version 3.0.0-5.1.el10_0-8818a21) - partition with quorum * Last updated: Tue May 19 22:15:08 2026 on sap-cl1 * Last change: Tue Apr 21 23:11:34 2026 by root via root on sap-cl1 * 2 nodes configured * 3 resource instances configured Node List: * Online: [ sap-cl1 sap-cl2 ] Full List of Resources: * sbd (stonith:fence_sbd): Started sap-cl1 * Clone Set: health-azure-events-clone [health-azure-events]: * Started: [ sap-cl1 sap-cl2 ] Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled sbd: active/enabledA 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 fence_kdump não é uma substituição para mecanismos de fencing tradicionais, como o SBD ou agente de fence do Azure, quando você está usando as VMs 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.
O tempo limite proposto fence_kdump pode precisar ser adaptado ao ambiente específico.
Recomendamos que você configure fence_kdump fencing somente quando necessário para coletar diagnósticos dentro da VM e sempre em combinação com métodos de cerca tradicionais, como SBD ou agente de cerca 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:
- Veja como configurar fence_kdump em um cluster do Red Hat Pacemaker?
- Confira Como configurar/gerenciar níveis de isolamento em um cluster do RHEL com o Pacemaker.
- Para obter informações sobre como alterar o tempo limite padrão, confira Como configurar o kdump para uso com o complemento RHEL 6, 7, 8 HA?
- Para obter informações sobre como reduzir o atraso no failover ao usar
fence_kdump, veja Posso reduzir o atraso esperado do failover ao incluir a configuração 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 limite do Azure.
[A] Verifique se o
kdumpestá ativo e configurado.systemctl is-active kdump # Expected result # active[A] Instale o agente de isolamento
fence_kdump.sudo dnf install -y fence-agents-kdump[1] Crie um dispositivo de isolamento
fence_kdumpno cluster.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="sap-cl1 sap-cl2" timeout=30[1] Configure níveis de isolamento para que o mecanismo de isolamento
fence_kdumpseja ativado primeiro.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="sap-cl1 sap-cl2" pcs stonith level add 1 sap-cl1 rsc_st_kdump pcs stonith level add 1 sap-cl2 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 sap-cl1 <stonith-resource-name> pcs stonith level add 2 sap-cl2 <stonith-resource-name> # Check the fencing level configuration pcs stonith level # Example output # Target: sap-cl1 # Level 1 - rsc_st_kdump # Level 2 - <stonith-resource-name> # Target: sap-cl2 # Level 1 - rsc_st_kdump # Level 2 - <stonith-resource-name>[A] Permita as portas necessárias para
fence_kdumpno firewall.firewall-cmd --add-port=7410/udp --permanent firewall-cmd --reload[A] Execute a configuração de
fence_kdump_nodesem/etc/kdump.confpara evitar uma falha defence_kdumpcom um tempo limite para algumas versões dokexec-tools. Para ter mais informações, consulte fence_kdump expira quando fence_kdump_nodes não é especificado com a versão 2.0.15 ou posterior do kexec-tools. 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çokdump.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] Verifique se o arquivo de imagem
initramfscontém os arquivosfence_kdumpehosts.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_sendTeste a configuração causando falha em um nó.
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
- Planejamento e implementação de Máquinas Virtuais do Azure para o SAP.
- Implantação de Máquinas Virtuais do Azure para SAP.
- Implantação do DBMS de Máquinas Virtuais do Azure para SAP.
- Alta disponibilidade para NFS Simple Mount em VMs Azure no Red Hat Enterprise Linux.
- Para saber como estabelecer a alta disponibilidade e o plano de recuperação de desastre do SAP HANA em VMs do Azure, consulte Alta disponibilidade do SAP HANA em Máquinas Virtuais do Azure.