Merge pull request #303737 from dennispadia/dp-slescontraintchange

Update constraint in SLES

Author: prmerger-automator[bot]

articles/sap/workloads/high-availability-guide-rhel-pacemaker.md

@@ -8,7 +8,7 @@ ms.service: sap-on-azure
 ms.topic: article
 ms.tgt_pltfrm: vm-linux
 ms.custom: linux-related-content
-ms.date: 10/28/2024
+ms.date: 08/01/2025
 ms.author: radeltch
 # Customer intent: "As a system administrator managing RHEL clusters on Azure, I want to configure a high availability cluster using Pacemaker, so that I can ensure redundancy and fault tolerance for my applications."
 ---
@@ -377,7 +377,7 @@ On the cluster nodes, connect and discover iSCSI device that was created in the
        SBD_STARTMODE=always
        [...]
        # # In some cases, a longer delay than the default "msgwait" seconds is needed. So, set a specific delay value, in seconds. See, `man sbd` for more information. 
-       SBD_DELAY_START=216
+       SBD_DELAY_START=186
        [...]
        ```
 
@@ -394,17 +394,17 @@ On the cluster nodes, connect and discover iSCSI device that was created in the
     systemctl restart systemd-modules-load
     ```
 
-16. **[A]** The SBD service timeout value is set to 90 s by default. However, if the `SBD_DELAY_START` value is set to `yes`, the SBD service will delay its start until after the `msgwait` timeout. Therefore, the SBD service timeout value should exceed the `msgwait` timeout when `SBD_DELAY_START` is enabled.
+16. **[A]** The SBD service timeout value is set to 90 seconds by default. However, if the `SBD_DELAY_START` value is set to `yes`, the SBD service will delay its start until after the `msgwait` timeout. Therefore, the SBD service timeout value should exceed the `msgwait` timeout when `SBD_DELAY_START` is enabled.
 
     ```bash
     sudo mkdir /etc/systemd/system/sbd.service.d
-    echo -e "[Service]\nTimeoutSec=259" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
+    echo -e "[Service]\nTimeoutSec=223" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
     sudo systemctl daemon-reload
     
     systemctl show sbd | grep -i timeout
-    # TimeoutStartUSec=4min 19s
-    # TimeoutStopUSec=4min 19s
-    # TimeoutAbortUSec=4min 19s
+    # TimeoutStartUSec=3min 43s
+    # TimeoutStopUSec=3min 43s
+    # TimeoutAbortUSec=3min 43s
     ```
 
 ## SBD with an Azure shared disk
@@ -520,7 +520,7 @@ foreach ($vmName in $vmNames) {
       SBD_STARTMODE=always
       [...]
       # In some cases, a longer delay than the default "msgwait" seconds is needed. So, set a specific delay value, in seconds. See, `man sbd` for more information. 
-      SBD_DELAY_START=216
+      SBD_DELAY_START=186
       [...]
       ```
 
@@ -541,13 +541,13 @@ foreach ($vmName in $vmNames) {
 
    ```bash
    sudo mkdir /etc/systemd/system/sbd.service.d
-   echo -e "[Service]\nTimeoutSec=259" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
+   echo -e "[Service]\nTimeoutSec=223" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
    sudo systemctl daemon-reload
    
    systemctl show sbd | grep -i timeout
-   # TimeoutStartUSec=4min 19s
-   # TimeoutStopUSec=4min 19s
-   # TimeoutAbortUSec=4min 19s
+   # TimeoutStartUSec=3min 43s
+   # TimeoutStopUSec=3min 43s
+   # TimeoutAbortUSec=3min 43s
    ```
 
 ## Azure fence agent configuration
@@ -578,7 +578,7 @@ The fencing device uses either a managed identity for Azure resource or a servic
    1. Make a note of the **Value**. It's used as the **password** for the service principal.
    1. Select **Overview**. Make a note of the **Application ID**. It's used as the username (**login ID** in the following steps) of the service principal.
 
-   ---
+    ---
 
 2. Create a custom role for the fence agent
 
@@ -622,7 +622,7 @@ The fencing device uses either a managed identity for Azure resource or a servic
 
    Make sure to assign the role for both cluster nodes.
 
-   ---
+    ---
 
 ## Cluster installation
 

articles/sap/workloads/high-availability-guide-suse-pacemaker.md

@@ -8,7 +8,7 @@ ms.service: sap-on-azure
 ms.subservice: sap-vm-workloads
 ms.topic: article
 ms.custom: devx-track-azurepowershell, linux-related-content
-ms.date: 07/31/2025
+ms.date: 08/01/2025
 ms.author: radeltch
 # Customer intent: "As a system administrator, I want to set up Pacemaker with fencing on SUSE Linux Enterprise Server in Azure, so that I can ensure high availability and reliability for my applications running in the cloud."
 ---
@@ -962,7 +962,8 @@ Make sure to assign the custom role to the service principal at all VM (cluster
 > [!TIP]
 >
 > - To avoid fence races within a two-node pacemaker cluster, you can configure additional "priority-fencing-delay" cluster property. This property introduces additional delay in fencing a node that has higher total resource priority when a split-brain scenario occurs. For more information, see [SUSE Linux Enterprise Server high availability extension administration guide](https://documentation.suse.com/sle-ha/15-SP3/single-html/SLE-HA-administration/#pro-ha-storage-protect-fencing).
-> - The instruction on setting "priority-fencing-delay" cluster property can be found in respective SAP ASCS/ERS (applicable only on ENSA2) and SAP HANA scale-up high availability document.
+> - The property `priority-fencing-delay` is only applicable for two-node cluster. The instruction on setting "priority-fencing-delay" cluster property can be found in respective SAP ASCS/ERS (applicable only on ENSA2) and SAP HANA scale-up high availability document.
+> - When configuring a cluster for HANA scale-out, do not set the `pcmk_delay_max` property in the SBD Stonith resource.
 
 1. **[1]** If you're using an SBD device (iSCSI target server or Azure shared disk) as a fencing device, run the following commands. Enable the use of a fencing device, and set the fence delay.
 

articles/sap/workloads/sap-hana-high-availability-netapp-files-suse.md

@@ -266,10 +266,10 @@ When VMs without public IP addresses are placed in the back-end pool of internal
    ```bash
    #Check nfs4_disable_idmapping
    sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
-
+   
    #If you need to set nfs4_disable_idmapping to Y
    sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
-
+   
    #Make the configuration permanent
    sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
    ```
@@ -329,6 +329,7 @@ When VMs without public IP addresses are placed in the back-end pool of internal
    ```
 
    > [!TIP]
+   >
    > Avoid setting `net.ipv4.ip_local_port_range` and `net.ipv4.ip_local_reserved_ports` explicitly in the sysctl configuration files to allow the SAP Host Agent to manage the port ranges. For more information, see SAP Note [2382421](https://launchpad.support.sap.com/#/notes/2382421).
 
 1. **[A]** Adjust the `sunrpc` settings, as recommended in SAP Note [3024346 - Linux Kernel Settings for NetApp NFS](https://launchpad.support.sap.com/#/notes/3024346).
@@ -480,18 +481,18 @@ Create a dummy file system cluster resource. It monitors and reports failures if
 
    ```bash
    sudo crm status
-
+   
    # Cluster Summary:
    # Stack: corosync
    # Current DC: hanadb1 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
    # Last updated: Tue Nov  2 17:57:39 2021
    # Last change:  Tue Nov  2 17:57:38 2021 by root via crm_attribute on hanadb1
    # 2 nodes configured
    # 11 resource instances configured
-
+   
    # Node List:
    # Online: [ hanadb1 hanadb2 ]
-
+   
    # Full List of Resources:
    # Clone Set: cln_azure-events [rsc_azure-events]:
    #  Started: [ hanadb1 hanadb2 ]
@@ -649,18 +650,18 @@ This section describes how you can test your setup.
 
    ```bash
    sudo crm  status
-
+   
    #Cluster Summary:
     # Stack: corosync
     # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
     # Last updated: Mon Nov  8 23:01:27 2021
     # Last change:  Mon Nov  8 23:00:46 2021 by root via crm_attribute on hanadb1
     # 2 nodes configured
     # 11 resource instances configured
-
+   
     #Node List:
     # Online: [ hanadb1 hanadb2 ]
-
+   
     #Full List of Resources:
     # Clone Set: cln_azure-events [rsc_azure-events]:
       # Started: [ hanadb1 hanadb2 ]
@@ -687,18 +688,18 @@ This section describes how you can test your setup.
 
    ```bash
    sudo crm status
-
+   
    #Cluster Summary:
     # Stack: corosync
     # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
     # Last updated: Wed Nov 10 22:00:27 2021
     # Last change:  Wed Nov 10 21:59:47 2021 by root via crm_attribute on hanadb2
     # 2 nodes configured
     # 11 resource instances configured
-
+   
     #Node List:
     # Online: [ hanadb1 hanadb2 ]
-
+   
     #Full List of Resources:
     # Clone Set: cln_azure-events [rsc_azure-events]:
       # Started: [ hanadb1 hanadb2 ]

articles/sap/workloads/sap-hana-high-availability.md

@@ -34,8 +34,6 @@ ms.author: radeltch
 [sles-for-sap-bp12]:https://documentation.suse.com/sbp/sap-12/
 [sles-for-sap-bp15]:https://documentation.suse.com/sbp/sap-15/
 
-[sap-swcenter]:https://launchpad.support.sap.com/#/softwarecenter
-
 To establish high availability in an on-premises SAP HANA deployment, you can use either SAP HANA system replication or shared storage.
 
 Currently on Azure virtual machines (VMs), SAP HANA system replication on Azure is the only supported high availability function.
@@ -376,10 +374,10 @@ sapcontrol -nr <instance number> -function StopSystem
 
    #### [SAPHanaSR-angi](#tab/saphanasr-angi)
 
-   1. **[A]** Adjust *global.ini* on each cluster node. 
+   1. **[A]** Adjust *global.ini* on each cluster node.
 
       If you choose not to use the recommended susChkSrv hook, remove the entire `[ha_dr_provider_suschksrv]` block from the following parameters. You can adjust the behavior of `susChkSrv` by using the `action_on_lost` parameter. Valid values are [ `ignore` | `stop` | `kill` | `fence` ].
-  
+
       ```bash
       [ha_dr_provider_sushanasr]
       provider = susHanaSR
@@ -391,12 +389,12 @@ sapcontrol -nr <instance number> -function StopSystem
       path = /usr/share/SAPHanaSR-angi
       execution_order = 3
       action_on_lost = fence
-  
+      
       [trace]
       ha_dr_sushanasr = info
       ha_dr_suschksrv = info
       ```
-  
+   
       If you point parameter path to the default `/usr/share/SAPHanaSR-angi` location, the Python hook code updates automatically through OS updates or package updates. HANA uses the hook code updates when it next restarts. With an optional own path like `/hana/shared/myHooks`, you can decouple OS updates from the hook version that you use.
 
    1. **[A]** The cluster requires *sudoers* configuration on each cluster node for \<sap-sid\>adm. In this example, that's achieved by creating a new file.
@@ -463,7 +461,7 @@ sapcontrol -nr <instance number> -function StopSystem
   
      For details about implementing the SAP HANA system replication hook, see [Set up HANA HA/DR providers](https://documentation.suse.com/sbp/sap-15/html/SLES4SAP-hana-sr-guide-PerfOpt-15/index.html#cha.s4s.hana-hook).
 
----
+    ---
 
 3. **[A]** Start SAP HANA on both nodes.
    Run the following command as \<sap-sid\>adm:
@@ -495,7 +493,7 @@ sapcontrol -nr <instance number> -function StopSystem
    # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOK
    ```
 
----
+    ---
 
 5. **[1]** Verify the susChkSrv hook installation.
    Run the following command as \<sap-sid\>adm on HANA VMs:
@@ -673,8 +671,13 @@ sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb por
 
 sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>
 
+# Run the following command if the cluster nodes are running on SLES 12 SP05.
+sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
+  msl_SAPHana_<HANA SID>_HDB<instance number>:Master
+  
+# Run the following command if the cluster nodes are running on SLES 15 SP03 or later.
 sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
-  msl_SAPHana_<HANA SID>_HDB<instance number>:Master  
+  msl_SAPHana_<HANA SID>_HDB<instance number>:Promoted
 
 sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
   msl_SAPHana_<HANA SID>_HDB<instance number>
@@ -804,8 +807,13 @@ crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=
 
 crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>
 
+# Run the following command if the cluster nodes are running on SLES 12 SP05.
+crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
+ msl_SAPHana_<HANA SID>_HDB<instance number>:Slave
+ 
+# Run the following command if the cluster nodes are running on SLES 15 SP03 or later.
 crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
- msl_SAPHana_<HANA SID>_HDB<instance number>:Slave 
+ msl_SAPHana_<HANA SID>_HDB<instance number>:Unpromoted
 
 crm configure property maintenance-mode=false
 ```