Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure

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

Pré-requisitos

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.

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.

Diagrama de um Azure Shared Disk como dispositivo SBD em um cluster do Pacemaker.

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 SSD SKU 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 da sua implantação, escolha o armazenamento redundante apropriado de um disco compartilhado do 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 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 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ê 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.

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.

Diagrama dos servidores iSCSI hospedando alvos iSCSI para dispositivos SBD em um Cluster Pacemaker.

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.

Diagrama do agente de cercamento do Azure em um cluster do Pacemaker.

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

Criar servidores host de destino iSCSI

  1. Implante três máquinas virtuais que rodem em uma versão suportada do SLES 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 SLES para a imagem do sistema operacional de aplicações SAP para o servidor alvo iSCSI. Você pode usar uma imagem padrão do SLES OS em vez disso. No entanto, o ciclo de vida de suporte varia entre diferentes versões de produtos do sistema operacional.

  2. Instale as atualizações mais recentes e reinicie se 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, 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
  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. 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 Azure Fence Agent

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

  2. 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": []
    }
    
  3. 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 da autorização com identidades gerenciadas podem levar algum tempo até entrarem em vigor.

Criar e configurar o cluster

  1. [A] Atualize o sistema operacional 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] Instalação dos pacotes de cercas 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 DNS.

    Você pode usar um servidor DNS ou modificar /etc/hosts em 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-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 da raiz 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. Ajuste o cache sujo para clientes NFS em sistemas de alta memória. Veja 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. Certifique-se de que vm.swappiness esteja definido como 10 para reduzir o uso da área de swap e priorizar a memória.
      sudoedit /etc/sysctl.d/31-memswap.conf && sudo sysctl --system
      
      vm.swappiness = 10
      
    3. Apenas SLES 12 SP 5: ocasionalmente, o Pacemaker cria muitos processos, o que pode esgotar o número permitido. Quando isso acontece, uma pulsação entre os nós de 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] Crie o agrupamento.

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

    sudo crm corosync set totem.token 30000
    sudo csync2 -xv
    sudo crm cluster run "corosync-cfgtool -R"
    
  9. Configure 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.

    1. [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=216
      Unit=pacemaker.service
      [Install]
      WantedBy=timers.target
      
    2. [A] Ativar o serviço de temporizador.
      sudo systemctl daemon-reload
      sudo systemctl enable pacemaker.timer
      
    3. [1] Desative os serviços do Pacemaker.
      sudo crm cluster disable --all
      
  10. Valide o agrupamento.

    1. [1] Validar o cluster do Pacemaker.
      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 o isolamento

  1. [A] Ativem o serviço SBD.
    sudo systemctl enable sbd
    
  2. [A] Ativar o watchdog de software.
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [A] Descubra o ID do dispositivo iSCSI.
    1. 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
      
    2. 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
      
  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 configurações 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 o arquivo de configuração SBD.
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [A] Habilitar os serviços necessários.
    sudo systemctl enable sbd iscsi iscsid
    
  2. [A] Ativar o watchdog de software.
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [1] Atualize o InitiatorName do nó 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] Reinicie os serviços iSCSI.
    sudo systemctl restart iscsi iscsid
    
  6. [A] Monte os alvos iSCSI de todos os servidores host 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] Descubra os IDs dos dispositivos iSCSI.
    1. 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
      
    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] 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. [1] Adicione 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 configurações 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 o arquivo de configuração SBD.
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [1] Configure Azure Fence Agent.

    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=usgov para a nuvem Azure 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] Configure o cluster para o Azure Fence Agent.

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

Configurando um cluster do Pacemaker com mais de dois nós

Se você está construindo um cluster maior, tenha em mente estas considerações:

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

    Os quorum.two_node valores e quorum.expected_votes se atualizam automaticamente quando você adiciona um terceiro ou mais nós. Valide se o quorum.two_node é 0 e se quorum.expected_votes é igual ao número de nós em seu cluster.

    sudo crm corosync get quorum.two_node
    sudo crm corosync get quorum.expected_votes
    
  2. 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 -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 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. Assim que o nó de cluster afetado não tiver mais recursos do cluster em execução, 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 para todos os sistemas SAP de alta disponibilidade com Pacemaker.

  1. Apenas SLES 12 SP5 Verifique sua versão do resource-agents pacote e atualize se necessário. O SLES 15 e versões superiores o incluem por padrão nas versões instaladas.

    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] Definir a estratégia e a restrição do nó de integridade do cluster do Pacemaker.

    Importante

    Não defina nenhum outro recurso no cluster começando com 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] Definir 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
    
  5. [1] Configure os recursos no Pacemaker. Os recursos devem começar com 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
    

    Observação

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

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

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

    sudo crm configure property maintenance-mode=false
    sudo crm resource cleanup
    
  7. Verifique se health-azure-events inicia com sucesso 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 primeira execução da consulta para eventos agendados pode levar 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 mais informações, veja eventos programados.

    Observação

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

    AVISO: cib-bootstrap-options: atributo 'hostName_ hostname' desconhecido
    AVISO: cib-bootstrap-options: atributo desconhecido 'azure-events_globalPullState'
    AVISO: cib-bootstrap-options: atributo desconhecido 'hostName_ hostname'
    Você pode ignorar essas mensagens de alerta.

Próximas etapas