Configurar o Pacemaker no Azure em SUSE Linux Enterprise Server

Este artigo explica como configurar e configurar um cluster básico Pacemaker de dois nós no SUSE Linux Enterprise Server (SLES) no Azure. Estas instruções cobrem SLES for SAP 12 SP5, SLES for SAP 15 SP 4+, e SLES for SAP 16.

Pré-requisitos

Descrição geral

Este guia assume que já implementou o grupo de recursos necessário, a rede virtual Azure, a sub-rede e as máquinas virtuais (VMs).

Clusters executados em Linux requerem um agente de fencing para isolar nós não saudáveis. Para realizar esta tarefa no Azure, utilize um dos seguintes métodos:

  • Morte Baseada em Armazenamento (SBD) com Azure Shared Disk
  • Morte baseada no armazenamento (SBD) com destinos iSCSI
  • Agente de isolamento do Azure

Nota

Os seguintes prefixos são usados neste documento:

  • [A]: Aplicável a todos os nós.
  • [1]: Aplicável apenas ao nó 1.
  • [2]: Aplicável apenas ao nó 2.

Usar SBD com o Azure Shared Disk

Ao usar Azure Shared Disks, pode montar o mesmo disco em todas as máquinas virtuais que fazem parte do cluster. Podes alojar o teu dispositivo SBD nesse disco partilhado sem requisitos adicionais de infraestrutura.

Diagrama de um Disco Partilhado do Azure como dispositivo SBD num cluster do Pacemaker.

Benefits

  • Fornece uma opção nativa de dispositivo de bloco partilhado Azure para SBD sem necessidade de recursos adicionais.
  • As máquinas virtuais anexam diretamente o disco gerido, reduzindo a dependência de considerações adicionais de rede.

Considerações importantes

  • Podes usar um disco partilhado do Azure com o Premium SSD SKU como dispositivo SBD.
  • Consulte a lista de sistemas operativos suportados.
  • Os dispositivos SBD que utilizam um disco partilhado premium Azure suportam armazenamento localmente redundante (LRS) e armazenamento redundante por 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 que utiliza LRS para o disco partilhado Premium do Azure (skuName - Premium_LRS) suporta apenas implementações num conjunto de disponibilidade.
    • Recomenda-se um dispositivo SBD que utilize ZRS para um disco partilhado premium Azure (skuName - Premium_ZRS) para implementações em zonas de disponibilidade.
  • 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, pode usar tamanhos de disco P1 ou P2 para o seu dispositivo SBD num 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 documentado de maxShares para o disco selecionado.
  • Não anexe um dispositivo SBD de disco partilhado do Azure em diferentes clusters do Pacemaker.
  • Se você usar vários dispositivos SBD de disco compartilhado do Azure, verifique o limite para um número máximo de discos de dados que podem ser anexados a uma VM.
  • Para obter mais informações sobre limitações para discos compartilhados do Azure, examine cuidadosamente a seção "Limitações" da documentação de disco compartilhado do Azure.

Utilizar o SBD com destinos iSCSI

Esta solução exige que aloje alvos de Internet Small Computer System Interface (iSCSI) em pelo menos uma máquina virtual adicional (VM).

Diagrama dos servidores iSCSI que alojam alvos iSCSI para dispositivos SBD num Cluster Pacemaker.

Benefits

  • Estes servidores anfitriões iSCSI também podem albergar destinos iSCSI para outros clusters Pacemaker que se encontrem na mesma região.
  • Se já os usas localmente, não exigem alterações na forma como operas o cluster do Pacemaker.

Considerações importantes

  • Deve usar três servidores host iSCSI para ter o mais alto nível de resiliência para o seu cluster.
    • A utilização de apenas um servidor introduz um ponto único de falha que impede o seu cluster de efetuar fencing se esse servidor ficar indisponível.
    • O Pacemaker não permite esgrima se só tiveres dois alvos e um estiver em baixo.
  • Os servidores anfitriões de destino iSCSI devem residir na mesma região dos seus clusters.
  • O roteamento de rede entre os clusters e os servidores anfitrião iSCSI não deve passar por quaisquer dispositivos de rede não redundantes (como um dispositivo virtual de rede).
    • Eventos de manutenção e outros problemas com dispositivos de rede podem afetar negativamente a estabilidade e fiabilidade da configuração global do cluster.

Utilizar o agente de vedação do Azure

Ao utilizar o Azure Fence Agent, o seu cluster pode isolar nós chamando diretamente as APIs do Azure para reiniciar nós com falha.

Diagrama do Azure Fence Agent num cluster do Pacemaker.

Benefits

  • Não são necessários recursos extra.
  • As Identidades Geridas removem qualquer manutenção de credenciais.

Considerações importantes

  • Utilize Identidades Geridas para autenticação. Se estiver a usar atualmente um principal de serviço, atualize o Azure Fence Agent do SPN para o MSI.
  • O fence agent do Azure requer conectividade de saída para os pontos finais públicos do Azure. Para obter mais informações e possíveis soluções, consulte Conectividade de ponto de extremidade público para VMs usando o ILB padrão.
  • 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.

Implementar um disco partilhado do Azure para SBD

Para criar e anexar um disco partilhado no Azure usando o PowerShell, execute os seguintes comandos. Se quiser implementar recursos utilizando a CLI do Azure ou o portal do Azure, veja Implementar 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
}

Utilizar destinos iSCSI

Construir servidores host de destino iSCSI

  1. Implemente três máquinas virtuais que corram numa versão suportada do SLES OS. As VMs não precisam de ser grandes. Tamanhos de VM como Standard_E2s ou Standard_D2s são suficientes.

    Nota

    Não precisas de usar o SLES para a imagem do sistema operativo de aplicações SAP para o servidor alvo iSCSI. Podes usar uma imagem padrão do SLES OS em vez disso. No entanto, o ciclo de vida do suporte varia entre diferentes versões de produtos do sistema operacional.

  2. Instala as atualizações mais recentes e reinicia se for necessário.

    sudo zypper -n update
    
  3. Instale o pacote de destino iSCSI.

    sudo zypper -n install targetcli-fb
    
  4. Ative e inicie o serviço iSCSI.

    sudo systemctl start targetcli
    sudo systemctl enable targetcli
    

Criar alvos iSCSI

Para cada cluster, é necessário provisionar um disco iSCSI em cada servidor anfitrião iSCSI e depois conceder acesso a cada nó do cluster a esse disco. Neste exemplo, crias discos para dois clusters diferentes:

  • ascsnw1: O agrupamento ASCS/ERS de NW1
  • hdbnw1: O cluster de bases 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
  1. Crie a pasta raiz para todos os dispositivos SBD.
    sudo mkdir /sbd
    
  2. 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
    
  3. 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
    
  4. Salve a configuração.
    sudo targetcli saveconfig
    
  5. Verifica 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]
    

Configure Azure Fence Agent

  1. Criar identidade

    Para criar uma identidade gerida (MSI), crie uma identidade gerida atribuída pelo sistema para cada VM no cluster. Identidades geridas atribuídas pelos utilizadores não são suportadas neste momento.

  2. Crie um papel personalizado.

    A sua identidade precisa de permissões atribuídas através do Azure RBAC para realizar operações de isolamento nas suas VMs. Para cumprir o Modelo de Segurança de Acesso Mínimo Privilegiado (LPA), crie um papel RBAC personalizado.

    Utilize a definição seguinte para a sua função, substituindo o(s) ID(s) da subscrição conforme 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": []
    }
    
  3. Atribui o papel personalizado às tuas identidades.

    Para cada VM no seu cluster, atribua a sua identidade gerida ao papel personalizado "Linux Fence Agent" para cada VM do cluster, incluindo ela própria. Para obter etapas detalhadas, consulte Atribuir um acesso de identidade gerenciado a um recurso usando o portal do Azure.

    Importante

    Esteja ciente de que a atribuição e remoção da autorização com identidades geridas pode ser adiada até entrar em vigor.

Criar e configurar o cluster

  1. [A] Atualize o sistema operativo e reinicie se necessário.

    sudo zypper -n update
    
  2. [A] Instalar pacotes de cluster necessários.

    sudo zypper -n install socat pacemaker resource-agents 
    
  3. [A] Instalar os pacotes de vedação necessários.

    sudo zypper -n install sbd
    
    sudo zypper -n install sbd open-iscsi
    
    sudo zypper -n install fence-agents-azure-arm
    
  4. [A] Configurar o DNS.

    Pode usar um servidor DNS ou modificar /etc/hosts em cada um dos nós. Este exemplo mostra como usar o /etc/hosts arquivo.

    Atualize as entradas para corresponderem 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-cl2
    
    sudo 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
    
  5. [A] Troque as chaves SSH de root entre os nós.

    sudo ssh-keygen -t ed25519 -N "" -f /root/.ssh/id_ed25519
    sudo cat /root/.ssh/id_ed25519.pub
    sudo vi /root/.ssh/authorized_keys
    [...]
    <Contents from cat command on other server>
    
  6. [A] Configure o sistema operacional.

    1. Ajusta a cache suja para clientes NFS em sistemas de alta memória. Consulte este artigo para mais informações.
      sudoedit /etc/sysctl.d/30-nfs.conf && sudo sysctl --system
      
      vm.dirty_bytes = 629145600
      vm.dirty_background_bytes = 314572800
      
    2. Certifica-te de que vm.swappiness está definido para 10 para reduzir a utilização da swap e privilegiar a memória.
      sudoedit /etc/sysctl.d/31-memswap.conf && sudo sysctl --system
      
      vm.swappiness = 10
      
    3. Apenas SLES 12 SP 5: O Pacemaker cria ocasionalmente muitos processos, o que pode esgotar o número permitido. Quando isso acontece, uma pulsação entre os nós do cluster pode falhar e levar a um failover de seus recursos. Aumente o número máximo de processos permitidos definindo o seguinte parâmetro:
      # Edit the configuration file
      sudo vi /etc/systemd/system.conf
      [...]
      DefaultTasksMax=4096
      [...]
      
      # Activate this setting
      sudo systemctl daemon-reload
      
      # Test to ensure that the change was successful
      sudo systemctl --no-pager show | grep DefaultTasksMax
      
  7. [1] Cria o cluster.

    sudo crm cluster init --yes --name ascsnw1 --node sap-cl1 --node sap-cl2
    
  8. [1] Configurar as definições do cluster.

    sudo crm corosync set totem.token 30000
    sudo csync2 -xv
    sudo crm cluster run "corosync-cfgtool -R"
    
  9. Configura um atraso de arranque para o Pacemaker.

    Iniciar o Pacemaker imediatamente após o arranque pode potencialmente permitir que um nó volte a juntar-se ao cluster antes da conclusão do failover, prevenindo o failover ou atrasando a recuperação. Para resolver este problema, use um serviço de temporizador para atrasar o arranque do pacemaker ao reiniciar.

    1. [A] Configurar o serviço do temporizador.
      sudo vi /etc/systemd/system/pacemaker.timer   
      
      [Unit]
      Description=Delay start of pacemaker.service after boot
      [Timer]
      OnBootSec=216
      Unit=pacemaker.service
      [Install]
      WantedBy=timers.target
      
    2. [A] Ativar serviço de temporizador.
      sudo systemctl daemon-reload
      sudo systemctl enable pacemaker.timer
      
    3. [1] Desativar os serviços do Pacemaker.
      sudo crm cluster disable --all
      
  10. Valida o cluster.

    1. [1] Validar o cluster do marcapasso.
      sudo crm status
      
      Cluster Summary:
        * Stack: corosync (Pacemaker is running)
        * Current DC: sap-cl1 (version 2.1.7+20231219.0f7f88312-150600.6.15.1-2.1.7+20231219.0f7f88312) - partition with quorum
        * Last updated: Tue Aug  4 17:50:24 2026 on sap-cl1
        * Last change:  Thu Jul 30 19:02:56 2026 by hacluster via hacluster on sap-cl1
        * 2 nodes configured
        * 0 resource instances configured
      
      Node List:
        * Online: [ sap-cl1 sap-cl2 ]
      
      Full List of Resources:
      
    2. [A] Validar serviços.
      systemctl list-unit-files pacemaker.timer pacemaker.service corosync.service
      
      UNIT FILE         STATE    PRESET
      corosync.service  disabled disabled
      pacemaker.service disabled disabled
      pacemaker.timer   enabled  disabled
      

Configurar a vedação

  1. [A] Ativar o serviço SBD.
    sudo systemctl enable sbd
    
  2. [A] Ativar o sistema de vigilância de software.
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [A] Descubra o ID do dispositivo iSCSI.
    1. Determinar 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
      
    2. Obtenha o ID do dispositivo iSCSI do ponto de 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
      
  4. [1] Crie o dispositivo SBD.
    sudo sbd -d /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -1 60 -4 120 create
    
  1. [1] Adicionar o dispositivo SBD ao cluster.
    sudo crm cluster init --yes sbd -s /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617
    
  2. [1] Alterar as definições de configuração do SBD.
    sudo crm configure property stonith-timeout=210
    sudo crm configure property stonith-enabled=true
    # For the below command, 600 is the interval, and 120 is the timeout
    sudo crm configure monitor stonith-sbd 600:120
    sudo crm configure set stonith-sbd.pcmk_delay_max 15
    
  3. [A] Validar ficheiro de configuração SBD.
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [A] Permitir os serviços necessários.
    sudo systemctl enable sbd iscsi iscsid
    
  2. [A] Ativar o sistema de vigilância de software.
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [1] Atualize o nó InitiatorName 1.
    sudo vi /etc/iscsi/initiatorname.iscsi
    [...]
    InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1
    
  4. [2] Atualize o InitiatorName do nó 2.
    # Node 2
    sudo vi /etc/iscsi/initiatorname.iscsi
    [...]
    InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2
    
  5. [A] Reiniciar os serviços iSCSI.
    sudo systemctl restart iscsi iscsid
    
  6. [A] Monte os destinos iSCSI de todos os servidores anfitrião 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
    
  7. [A] Descobre os IDs dos dispositivos iSCSI.
    1. Determina 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
      
    2. 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
      
  8. [1] Criar 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. [1] Adicionar os dispositivos SBD ao cluster.
    sudo crm cluster init --yes sbd \
       -s /dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528 \
       -s /dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff \
       -s /dev/disk/by-id/scsi-360014059f135275c24647d49268123e5
    
  2. [1] Alterar as definições de configuração do SBD.
    sudo crm configure property stonith-timeout=210
    sudo crm configure property stonith-enabled=true
    # For the below command, 600 is the interval, and 120 is the timeout
    sudo crm configure monitor stonith-sbd 600:120
    sudo crm configure set stonith-sbd.pcmk_delay_max 15
    
  3. [A] Validar ficheiro de configuração SBD.
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [1] Configure o agente de vedação do Azure.

    Nota

    Ao usar o Azure Government Cloud, deve especificar essa cloud= opção ao configurar o Azure Fence Agent. Por exemplo, cloud=usgov para a Azure cloud do governo dos EUA.

    sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm params 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
    
  2. [1] Configurar o cluster para o Azure Fence Agent.

    sudo crm configure property stonith-enabled=true
    sudo crm configure property stonith-timeout=900
    

Construir um cluster Pacemaker com mais de dois nós

Se está a construir um cluster maior, tenha estas considerações em mente:

  1. [1] Ajustar a configuração do cluster.

    Os quorum.two_node valores e quorum.expected_votes atualizam-se automaticamente quando adicionas um terceiro ou mais nós. Valida que quorum.two_node é 0 e quorum.expected_votes é igual ao número de nós no teu cluster.

    sudo crm corosync get quorum.two_node
    sudo crm corosync get quorum.expected_votes
    
  2. Ajusta a configuração da vedação.

    sudo crm resource param stonith-sbd delete pcmk_delay_max
    sudo crm resource param stonith-sbd set pcmk_action_limit -1
    
    sudo 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 à sua aplicação para se preparar para a manutenção da VM. Fornece informações sobre eventos de manutenção futuros, como um reinício, para que a sua aplicação possa preparar-se para eles e limitar as interrupções.

O agente de recursos azure-events-az monitoriza este serviço de metadados. Quando o agente deteta eventos e determina que outro nó do cluster está disponível, define o atributo de estado de funcionamento ao nível do nó #health-azure como -1000000. Este valor faz com que o cluster considere o nó doente e migra recursos para longe do nó afetado. A restrição de localização garante que os recursos que começam por health- são excluídos, pois o agente azure-events-az ainda precisa de correr em ambos os nós. Uma vez que o nó afetado do cluster esteja livre dos recursos do cluster em execução, o agente notifica o serviço de metadados e o evento agendado pode continuar. Quando todos os eventos são concluídos, o agente de recursos define novamente o atributo #health-azure como 0, marcando o nó como saudável novamente.

Importante

Anteriormente, este documento descrevia o uso do agente de recursos azure-events. O novo agente de recursos azure-events-az suporta totalmente ambientes do Azure implantados em diferentes zonas de disponibilidade. Utilize o agente azure-events-az mais recente para todos os sistemas SAP de alta disponibilidade com Pacemaker.

  1. Apenas SLES 12 SP5 Verifique a sua versão do resource-agents pacote e atualize se necessário. O SLES 15 e versões posteriores incluem-no por predefinição na instalação.

    zypper info resource-agents
    

    A versão mínima é resource-agents-4.3.018.a7fb5035-3.98.1.

  2. [1] Coloque o cluster em modo de manutenção.

    sudo crm configure property maintenance-mode=true
    
  3. [1] Configure a estratégia e a restrição do nó de integridade do cluster do Pacemaker.

    Importante

    Não defina quaisquer outros recursos no cluster que comecem por health-, além dos recursos descritos nos próximos passos.

    sudo crm configure property node-health-strategy=custom
    sudo crm configure location loc_azure_health \
       /'!health-.*'/ rule '#health-azure': defined '#uname'
    
  4. [1] Defina o valor inicial dos atributos do cluster.

    Executa um comando para cada nó do cluster. Para ambientes de expansão horizontal, inclua a VM Majority Maker.

    # 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
    
  5. [1] Configure os recursos no Pacemaker. Os recursos devem começar por health-azure.

    sudo crm configure primitive health-azure-events ocf:heartbeat:azure-events-az \
       meta failure-timeout=120s \
       op start start-delay=60s \
       op monitor interval=10s
    
    sudo crm configure clone health-azure-events-cln health-azure-events \
       meta allow-unhealthy-nodes=true
    

    Nota

    Quando configura o health-azure-events recurso, pode ignorar a seguinte mensagem de aviso.

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

  6. Retire o cluster Pacemaker do modo de manutenção e limpe quaisquer erros.

    sudo crm configure property maintenance-mode=false
    sudo crm resource cleanup
    
  7. Verifique que health-azure-events é iniciado com êxito em todos os nós.

    crm status
    
    Cluster Summary:
      * Stack: corosync (Pacemaker is running)
      * Current DC: sap-cl1 (version 3.0.0+20250218.64cd85422c-160000.4.1-3.0.0+20250218.64cd85422c) - partition with quorum
      * Last updated: Thu Jul 30 19:07:49 2026 on sap-cl1
      * Last change:  Thu Jul 30 19:06:01 2026 by root via root on sap-cl1
      * 2 nodes configured
      * 3 resource instances configured
    
    Node List:
      * Online: [ z04ascs3 z04ascs4 ]
    
    Full List of Resources:
      * stonith-sbd (stonith:fence_sbd):     Started sap-cl1
      * Clone Set: health-azure-events-cln [health-azure-events]:
        * Started: [ sap-cl1 sap-cl2 ]
    

    A execução da primeira consulta para eventos agendados pode demorar até 2 minutos. O teste de marcapasso com eventos agendados pode usar ações de reinicialização ou redistribuição para as VMs da infraestrutura de cluster. Para mais informações, consulte os eventos programados.

    Nota

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

    AVISO: cib-bootstrap-options: atributo desconhecido 'hostName_hostname'
    AVISO: cib-bootstrap-options: atributo desconhecido 'azure-events_globalPullState'
    AVISO: cib-bootstrap-options: atributo desconhecido 'hostName_ hostname'
    Pode ignorar estas mensagens de aviso.

Próximos passos