Edit

Set up Pacemaker on SUSE Linux Enterprise Server in Azure

This article explains how to set up and configure a basic two node Pacemaker cluster on SUSE Linux Enterprise Server (SLES) in Azure. These instructions cover SLES for SAP 12 SP5, SLES for SAP 15 SP 4+, and SLES for SAP 16.

Prerequisites

Overview

This guide assumes you already deployed the required resource group, Azure virtual network, subnet, and virtual machines (VMs).

Clusters running on Linux require a fencing agent to fence unhealthy nodes. To accomplish this task on Azure, use one of the following methods:

  • Storage Based Death (SBD) with Azure Shared Disk
  • Storage Based Death (SBD) with iSCSI targets
  • Azure Fencing Agent

Note

The following prefixes are used in this document:

  • [A]: Applicable to all nodes.
  • [1]: Applicable to only node 1.
  • [2]: Applicable to only node 2.

Using SBD with Azure Shared Disk

By using Azure Shared Disks, you can mount the same disk across all virtual machines that are part of the cluster. You can host your SBD device on that shared disk without extra infrastructure requirements.

Diagram of an Azure Shared Disk as an SBD device in a Pacemaker Cluster.

Benefits

  • Provides a native Azure shared block device option for SBD without requiring additional resources.
  • Virtual machines attach the managed disk directly, reducing dependency on additional network considerations.

Important considerations

  • You can use an Azure shared disk with the Premium SSD SKU as an SBD device.
  • Review the List of Supported Operating Systems.
  • SBD devices that use an Azure premium shared disk support locally redundant storage (LRS) and zone-redundant storage (ZRS).
  • Depending on the type of your deployment, choose the appropriate redundant storage for an Azure shared disk as your SBD device.
    • An SBD device that uses LRS for Azure premium shared disk (skuName - Premium_LRS) supports only deployments in an availability set.
    • An SBD device that uses ZRS for an Azure premium shared disk (skuName - Premium_ZRS) is recommended for deployments in availability zones.
  • The Azure shared disk that you use for SBD devices doesn't need to be large. The maxShares value determines how many cluster nodes can use the shared disk. For example, you can use P1 or P2 disk sizes for your SBD device on a two-node cluster such as SAP ASCS/ERS or SAP HANA scale-up.
    • For clusters with more than two nodes, refer to the documented maxShares for your selected disk.
  • Don't attach an Azure shared disk SBD device across different Pacemaker clusters.
  • If you use multiple Azure shared disk SBD devices, check on the limit for a maximum number of data disks that can be attached to a VM.
  • For more information about limitations for Azure shared disks, carefully review the "Limitations" section of Azure shared disk documentation.

Using SBD with iSCSI targets

This solution requires you to host Internet Small Computer System Interface (iSCSI) targets on at least one additional virtual machine (VM).

Diagram of iSCSI servers hosting iSCSI targets for SBD devices in a Pacemaker Cluster.

Benefits

  • These iSCSI host servers can host iSCSI targets for other Pacemaker clusters in the same region as well.
  • If you're already using them on-premises, they don't require any changes to how you operate the Pacemaker cluster.

Important considerations

  • You must use three iSCSI host servers to have the highest level of resiliency for your cluster.
    • Using only one server introduces a single point of failure that prevents your cluster from fencing if it's down.
    • Pacemaker doesn't allow fencing if you only have two targets and one is down.
  • iSCSI target host servers must reside in the same region as your clusters.
  • Network routing between your clusters and iSCSI host servers must not traverse any non-redundant network devices (like a Network Virtual Appliance).
    • Maintenance events and other issues with network devices can negatively affect the stability and reliability of the overall cluster configuration.

Using the Azure Fence Agent

By using the Azure Fence Agent, your cluster can fence nodes by directly calling the Azure APIs to restart failed nodes.

Diagram of Azure Fence Agent in a Pacemaker Cluster.

Benefits

  • No extra resources needed.
  • Managed Identities remove any credential maintenance.

Important considerations

  • Use Managed Identities for authentication. If you're currently using a service principal, Update the Azure Fence Agent from SPN to MSI.
  • The Azure fence agent requires outbound connectivity to public Azure endpoints. For more information along with possible solutions, see Public endpoint connectivity for VMs using standard ILB.
  • The monitoring and fencing operations are deserialized. As a result, if there's a longer running monitoring operation and simultaneous fencing event, there's no delay to the cluster failover because the monitoring operation is already running.

Deploy an Azure Shared Disk for SBD

To create and attach an Azure shared disk by using PowerShell, run the following commands. If you want to deploy resources by using the Azure CLI or the Azure portal, see Deploy a ZRS disk.

$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
}

Use iSCSI targets

Build iSCSI target host servers

  1. Deploy three virtual machines that run on a supported SLES OS version. The VMs don't need to be large. VM sizes such as Standard_E2s or Standard_D2s are sufficient.

    Note

    You don't need to use SLES for SAP Applications OS image for the iSCSI target server. You can use a standard SLES OS image instead. However, the support life cycle varies between different OS product releases.

  2. Install the latest updates, and reboot if required.

    sudo zypper -n update
    
  3. Install the iSCSI target package.

    sudo zypper -n install targetcli-fb
    
  4. Enable and start the iSCSI service.

    sudo systemctl start targetcli
    sudo systemctl enable targetcli
    

Create iSCSI targets

For each cluster, you need to provision an iSCSI disk on each iSCSI host server, and then grant every cluster node access to that disk. In this example, you create disks for two different clusters:

  • ascsnw1: The ASCS/ERS cluster for NW1
  • hdbnw1: The HANA Database cluster for NW1
  • sap-cl1 and sap-cl2: Hostnames for the NW1 ASCS/ERS cluster nodes
  • sap-db1 and sap-db2: Hostnames for the NW1 HANA cluster nodes
  1. Create the root folder for all SBD devices.
    sudo mkdir /sbd
    
  2. Create the SBD device for the first 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. Create the SBD device for the second 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. Save the configuration.
    sudo targetcli saveconfig
    
  5. Verify the setup.
    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. Create Identity

    To create a managed identity (MSI), create a system-assigned managed identity for each VM in the cluster. User assigned managed identities aren't supported at this time.

  2. Create a custom role.

    Your identity needs permissions through Azure RBAC to perform fencing actions against your VMs. To comply with the Least Privileged Access (LPA) Security Model, create a custom RBAC role.

    Use the following definition for your role, replacing your Subscription ID(s) where needed:

    {
          "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. Assign the custom role to your identities.

    For each VM in your cluster, assign its managed identity to the custom "Linux Fence Agent" role for every VM in the cluster, including itself. For detailed steps, see Assign a managed identity access to a resource by using the Azure portal.

    Important

    Be aware that the assignment and removal of authorization with managed identities can be delayed until effective.

Create and configure cluster

  1. [A] Update the OS and reboot if required.

    sudo zypper -n update
    
  2. [A] Install required cluster packages.

    sudo zypper -n install socat pacemaker resource-agents 
    
  3. [A] Install required fencing packages.

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

    You can either use a DNS server or modify /etc/hosts on all nodes. This example shows how to use the /etc/hosts file.

    Update the entries to match your IPs and hostnames.

    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] Exchange SSH root keys between the nodes.

    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 the operating system.

    1. Adjust the dirty cache for NFS clients on high memory systems. See this article for more information.
      sudoedit /etc/sysctl.d/30-nfs.conf && sudo sysctl --system
      
      vm.dirty_bytes = 629145600
      vm.dirty_background_bytes = 314572800
      
    2. Make sure vm.swappiness is set to 10 to reduce swap usage and favor memory.
      sudoedit /etc/sysctl.d/31-memswap.conf && sudo sysctl --system
      
      vm.swappiness = 10
      
    3. SLES 12 SP 5 Only: Pacemaker occasionally creates many processes, which can exhaust the allowed number. When this happens, a heartbeat between the cluster nodes might fail and lead to a failover of your resources. Increase the maximum number of allowed processes by setting the following parameter:
      # 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] Create the cluster.

    sudo crm cluster init --yes --name ascsnw1 --node sap-cl1 --node sap-cl2
    
  8. [1] Configure cluster settings.

    sudo crm corosync set totem.token 30000
    sudo csync2 -xv
    sudo crm cluster run "corosync-cfgtool -R"
    
  9. Configure a startup delay for Pacemaker.

    Starting Pacemaker immediately after boot can potentially let a node rejoin the cluster before failover completes, preventing failover or delaying recovery. To solve this problem use a timer service to delay pacemaker startup on reboot.

    1. [A] Configure timer service.
      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] Enable timer service.
      sudo systemctl daemon-reload
      sudo systemctl enable pacemaker.timer
      
    3. [1] Disable Pacemaker services.
      sudo crm cluster disable --all
      
  10. Validate the cluster.

    1. [1] Validate Pacemaker cluster.
      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] Validate services.
      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
      

Configure fencing

  1. [A] Enable the SBD service.
    sudo systemctl enable sbd
    
  2. [A] Enable software watchdog.
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [A] Discover the iSCSI device ID.
    1. Determine mount point based on LUN number
      ls -l /dev/disk/azure/scsi1/lun1
      lrwxrwxrwx. 1 root root 12 Apr 16 20:22 /dev/disk/azure/scsi1/lun1 -> ../../../sdb
      
    2. Get the iSCSI device ID from mount.
      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] Create the SBD device.
    sudo sbd -d /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -1 60 -4 120 create
    
  1. [1] Add the SBD device to the cluster.
    sudo crm cluster init --yes sbd -s /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617
    
  2. [1] Change SBD configuration settings.
    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] Validate SBD config file.
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [A] Enable the required services.
    sudo systemctl enable sbd iscsi iscsid
    
  2. [A] Enable software watchdog.
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [1] Update the InitiatorName for node 1.
    sudo vi /etc/iscsi/initiatorname.iscsi
    [...]
    InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1
    
  4. [2] Update the InitiatorName for node 2.
    # Node 2
    sudo vi /etc/iscsi/initiatorname.iscsi
    [...]
    InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2
    
  5. [A] Restart the iSCSI services.
    sudo systemctl restart iscsi iscsid
    
  6. [A] Mount the iSCSI targets from all the iSCSI host servers.
    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] Discover the iSCSI device IDs.
    1. Determine the iSCSI mount points.
      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. Get the iSCSI device IDs.
      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] Create the SBD devices.
    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] Add the SBD devices to the 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] Change SBD configuration settings.
    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] Validate SBD config file.
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [1] Configure Azure Fence Agent.

    Note

    When using Azure government cloud, you must specify the cloud= option when configuring the Azure Fence Agent. For example, cloud=usgov for the Azure US government cloud.

    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 the cluster for Azure Fence Agent.

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

Building a Pacemaker cluster with more than two nodes

If you're building a larger cluster, keep these considerations in mind:

  1. [1] Adjust cluster configuration.

    The quorum.two_node and quorum.expected_votes values automatically update when you add a third or more nodes. Validate the quorum.two_node is 0 and quorum.expected_votes equals the number of nodes in your cluster.

    sudo crm corosync get quorum.two_node
    sudo crm corosync get quorum.expected_votes
    
  2. Adjust fencing configuration.

    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
    

Configure Pacemaker for Azure scheduled events

Scheduled Events is an Azure Metadata Service that gives your application time to prepare for VM maintenance. It provides information about upcoming maintenance events, such as a reboot, so that your application can prepare for them and limit disruption.

The azure-events-az resource agent monitors this metadata service. When the agent detects events and determines that another cluster node is available, it sets a node-level health attribute #health-azure to -1000000. This value causes the cluster to consider the node unhealthy and migrates resources away from the affected node. The location constraint ensures resources starting with health- are excluded, as the azure-events-az agent still needs to run on both nodes. Once the affected cluster node is free of running cluster resources, the agent notifies the metadata service and the scheduled event can continue. When all events complete, the resource agent sets the #health-azure attribute back to 0, marking the node as healthy again.

Important

Previously, this document described the use of resource agent azure-events. New resource agent azure-events-az fully supports Azure environments deployed in different availability zones. Use the newer azure-events-az agent for all SAP highly available systems with Pacemaker.

  1. SLES 12 SP5 Only Check your version of the resource-agents package and update if required. SLES 15 and higher include it by default in their installed versions.

    zypper info resource-agents
    

    The minimum version is resource-agents-4.3.018.a7fb5035-3.98.1.

  2. [1] Place the cluster in maintenance mode.

    sudo crm configure property maintenance-mode=true
    
  3. [1] Set the pacemaker cluster health node strategy and constraint.

    Important

    Don't define any other resources in the cluster starting with health-, besides the resources described in the next steps.

    sudo crm configure property node-health-strategy=custom
    sudo crm configure location loc_azure_health \
       /'!health-.*'/ rule '#health-azure': defined '#uname'
    
  4. [1] Set initial value of the cluster attributes.

    Run a command for each cluster node. For scale-out environments include the majority maker VM.

    # 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 the resources in Pacemaker. The resources must start with 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
    

    Note

    When you configure the health-azure-events resource, you can ignore the following warning message.

    WARNING: health-azure-events: unknown attribute 'allow-unhealthy-nodes'.

  6. Take the Pacemaker cluster out of maintenance mode and clear any errors.

    sudo crm configure property maintenance-mode=false
    sudo crm resource cleanup
    
  7. Verify that health-azure-events starts successfully on all nodes.

    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 ]
    

    The first time query execution for scheduled events can take up to 2 minutes. Pacemaker testing with scheduled events can use reboot or redeploy actions for the cluster VMs. For more information, see scheduled events.

    Note

    After you configure the Pacemaker resources for the azure-events agent, if you place the cluster in or out of maintenance mode, you might get warning messages such as:

    WARNING: cib-bootstrap-options: unknown attribute 'hostName_hostname'
    WARNING: cib-bootstrap-options: unknown attribute 'azure-events_globalPullState'
    WARNING: cib-bootstrap-options: unknown attribute 'hostName_ hostname'
    You can ignore these warning messages.

Next steps