Merge pull request #245819 from dennispadia/depadia-sleshanaupdate

Update priority-fencing-delay parameter in SLES HANA document

Author: prmerger-automator[bot]

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

@@ -989,7 +989,7 @@ The following tests are a copy of the test cases in the best practices guides of
         rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started nw1-cl-0
    ```
 
-   Execute firewall rule to drop communication on one of the nodes
+   Execute firewall rule to block the communication on one of the nodes.
 
    ```bash
    # Execute iptable rule on nw1-cl-0 (10.0.0.5) to block the incoming and outgoing traffic to nw1-cl-1 (10.0.0.6)
@@ -1000,7 +1000,14 @@ The following tests are a copy of the test cases in the best practices guides of
 
    When configuring a fencing device, it's recommended to configure [`pcmk_delay_max`](https://www.suse.com/support/kb/doc/?id=000019110) property. So, in the event of split-brain scenario, the cluster introduces a random delay up to the `pcmk_delay_max` value, to the fencing action on each node. The node with the shortest delay will be selected for fencing.
 
-   Additionally, in ENSA 2 configuration, to prioritize the node hosting the ASCS resource over the other node during a split brain scenario, it's recommended to configure [`priority-fencing-delay`](https://documentation.suse.com/sle-ha/15-SP3/single-html/SLE-HA-administration/#pro-ha-storage-protect-fencing) property in the cluster. Enabling priority-fencing-delay property allows the cluster to introduce an extra delay in the fencing action specifically on the node hosting the ASCS resource, allowing the ASCS node to win the fence race.
+   Additionally, in ENSA 2 configuration, to prioritize the node hosting the ASCS resource over the other node during a split brain scenario, it's recommended to configure [`priority-fencing-delay`](https://documentation.suse.com/sle-ha/15-SP3/single-html/SLE-HA-administration/#pro-ha-storage-protect-fencing) property in the cluster. Enabling priority-fencing-delay property allows the cluster to introduce an additional delay in the fencing action specifically on the node hosting the ASCS resource, allowing the ASCS node to win the fence race.
+
+   Execute below command to delete the firewall rule.
+
+   ```bash
+   # If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
+   iptables -D INPUT -s 10.0.0.6 -j DROP; iptables -D OUTPUT -d 10.0.0.6 -j DROP
+   ```
 
 1. Test manual restart of ASCS instance
 

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

@@ -207,7 +207,7 @@ Replace `<placeholders>` with the values for your SAP HANA installation.
       sudo mkfs.xfs /dev/vg_hana_log_<HANA SID>/hana_log
       sudo mkfs.xfs /dev/vg_hana_shared_<HANA SID>/hana_shared
       ```
-  
+    
    1. Create the mount directories and copy the universally unique identifier (UUID) of all the logical volumes:
 
       ```bash
@@ -481,13 +481,13 @@ With susChkSrv implemented, an immediate and configurable action is executed. Th
       provider = SAPHanaSR
       path = /usr/share/SAPHanaSR
       execution_order = 1
-    
+       
       [ha_dr_provider_suschksrv]
       provider = susChkSrv
       path = /usr/share/SAPHanaSR
       execution_order = 3
       action_on_lost = fence
-
+   
       [trace]
       ha_dr_saphanasr = info
       ```
@@ -599,6 +599,8 @@ sudo crm configure ms msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<H
   meta notify="true" clone-max="2" clone-node-max="1" \
   target-role="Started" interleave="true"
 
+sudo crm resource meta msl_SAPHana_<HANA SID>_HDB<instance number> set priority 100
+
 sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
   meta target-role="Started" \
   operations \$id="rsc_ip_<HANA SID>_HDB<instance number>-operations" \
@@ -620,6 +622,8 @@ sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: c
 # Clean up the HANA resources. The HANA resources might have failed because of a known issue.
 sudo crm resource cleanup rsc_SAPHana_<HANA SID>_HDB<instance number>
 
+sudo crm configure property priority-fencing-delay=30
+
 sudo crm configure property maintenance-mode=false
 sudo crm configure rsc_defaults resource-stickiness=1000
 sudo crm configure rsc_defaults migration-threshold=5000
@@ -848,31 +852,44 @@ stonith-sbd     (stonith:external/sbd): Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
 ```
 
-### Test the Azure fencing agent
+### Blocking network communication
 
-You can test the setup of the Azure fencing agent (not the *SBD*) by disabling the network interface on the `hn1-db-0` node:
+Resource state before starting the test:
 
-```bash
-sudo ifdown eth0
-```
+   ```bash
+   Online: [ hn1-db-0 hn1-db-1 ]
+   
+   Full list of resources:
+   stonith-sbd     (stonith:external/sbd): Started hn1-db-1
+    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
+        Started: [ hn1-db-0 hn1-db-1 ]
+    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
+        Masters: [ hn1-db-1 ]
+        Slaves: [ hn1-db-0 ]
+    Resource Group: g_ip_HN1_HDB03
+        rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
+        rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
+   ```
 
-The VM now restarts or stops, depending on your cluster configuration.
+Execute firewall rule to block the communication on one of the nodes.
 
-If you set the `stonith-action` setting to `off`, the VM is stopped and the resources are migrated to the running VM.
+   ```bash
+   # Execute iptable rule on hn1-db-1 (10.0.0.6) to block the incoming and outgoing traffic to hn1-db-0 (10.0.0.5)
+   iptables -A INPUT -s 10.0.0.5 -j DROP; iptables -A OUTPUT -d 10.0.0.5 -j DROP
+   ```
 
-After you start the VM again, the SAP HANA resource fails to start as secondary if you set `AUTOMATED_REGISTER="false"`. In this case, configure the HANA instance as secondary by running this command:
+When cluster nodes can't communicate to each other, there's a risk of a split-brain scenario. In such situations, cluster nodes will try to simultaneously fence each other, resulting in fence race.
 
-```bash
-su - <hana sid>adm
+When configuring a fencing device, it's recommended to configure [`pcmk_delay_max`](https://www.suse.com/support/kb/doc/?id=000019110) property. So, in the event of split-brain scenario, the cluster introduces a random delay up to the `pcmk_delay_max` value, to the fencing action on each node. The node with the shortest delay will be selected for fencing. 
 
-# Stop the HANA instance, just in case it is running
-sapcontrol -nr <instance number> -function StopWait 600 10
-hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
+Additionally, to ensure that the node running the HANA master takes priority and wins the fence race in a split brain scenario, it's recommended to set  [`priority-fencing-delay`](https://documentation.suse.com/sle-ha/15-SP3/single-html/SLE-HA-administration/#pro-ha-storage-protect-fencing) property in the cluster configuration. By enabling priority-fencing-delay property, the cluster can introduce an additional delay in the fencing action specifically on the node hosting HANA master resource, allowing the node to win the fence race.
 
-# Switch back to root and clean up the failed state
-exit
-crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
-```
+Execute below command to delete the firewall rule.
+
+   ```bash
+   # If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
+   iptables -D INPUT -s 10.0.0.5 -j DROP; iptables -D OUTPUT -d 10.0.0.5 -j DROP
+   ```
 
 ### Test SBD fencing