HANA scale-out w HSR on RHEL - HANA shared on Azure Files

Author: rdeltcheva

articles/sap/workloads/sap-hana-high-availability-scale-out-hsr-rhel.md

@@ -903,11 +903,11 @@ You chose to deploy /hana/shared' on [NFS share on Azure Files](../../storage/fi
     pcs resource clone fs_hana_shared_s2 meta clone-node-max=1 interleave=true
     ```
 
-   The `OCF_CHECK_LEVEL=20` attribute is added to the monitor operation, so that monitor operations perform a read/write test on the file system. Without this attribute, the monitor operation only verifies that the file system is mounted. This can be a problem because when connectivity is lost, the file system might remain mounted, despite being inaccessible.  
+The `OCF_CHECK_LEVEL=20` attribute is added to the monitor operation, so that monitor operations perform a read/write test on the file system. Without this attribute, the monitor operation only verifies that the file system is mounted. This can be a problem because when connectivity is lost, the file system might remain mounted, despite being inaccessible.  
 
-   The `on-fail=fence` attribute is also added to the monitor operation. With this option, if the monitor operation fails on a node, that node is immediately fenced. Without this option, the default behavior is to stop all resources that depend on the failed resource, then restart the failed resource, and then start all the resources that depend on the failed resource. Not only can this behavior take a long time when an SAP HANA resource depends on the failed resource, but it also can fail altogether. The SAP HANA resource can't stop successfully, if the NFS share holding the HANA binaries is inaccessible.
+The `on-fail=fence` attribute is also added to the monitor operation. With this option, if the monitor operation fails on a node, that node is immediately fenced. Without this option, the default behavior is to stop all resources that depend on the failed resource, then restart the failed resource, and then start all the resources that depend on the failed resource. Not only can this behavior take a long time when an SAP HANA resource depends on the failed resource, but it also can fail altogether. The SAP HANA resource can't stop successfully, if the NFS share holding the HANA binaries is inaccessible.
 
-   The timeouts in the above configurations may need to be adapted to the specific SAP setup.
+The timeouts in the above configurations may need to be adapted to the specific SAP setup.  
   
 
 1. **[1]** Configure and verify the node attributes. All SAP HANA DB nodes on replication site 1 are assigned attribute `S1`, and all SAP HANA DB nodes on replication site 2 are assigned attribute `S2`.  
@@ -938,6 +938,7 @@ You chose to deploy /hana/shared' on [NFS share on Azure Files](../../storage/fi
    When you enable the file system resources, the cluster will mount the `/hana/shared` file systems.  
  
 1. **[AH]** Verify that the Azure NetApp Files volumes are mounted under `/hana/shared`, on all HANA DB VMs on both sites.
+
 - Example, if using Azure NetApp Files:
     ```bash
     sudo nfsstat -m