Implemented enhancements from doc review

Round 1. Fixed typos, wording, grammar, style, punctuation according to
SUSE style guide and policies.

Author: chabowski

adoc/SAP-S4HA10-setup-simplemount-sle16-docinfo.xml

@@ -73,7 +73,7 @@
     <revision>
         <date>2026-08-08</date>
         <revdescription>
-            <para>initial version</para>
+            <para>Initial version</para>
         </revdescription>
     </revision>
 </revhistory>
@@ -85,7 +85,7 @@
                 This document explains how to deploy an S/4HANA
                 Enqueue Replication 2 High Availability Cluster solution.
                 It is based on SUSE Linux Enterprise Server for SAP applications 16.0.
-                The concept however can also be used with
+                The concept, however, can also be used with
                 other minor versions of SUSE Linux Enterprise Server for SAP applications 16.
         </para>
 

adoc/SAP-S4HA10-setup-simplemount-sle16/SAP-S4HA10-setup-simplemount-sle16-about.adoc

@@ -13,9 +13,9 @@ single points of failure can be eliminated.
 and mid-size companies. Many critical business environments require the highest
 possible {sapReg} application availability.
 
-The described cluster solution can be used for {sapReg} {sapS4pl}.
+The described cluster solution can be used for {sapS4pl}.
 
-{sapS4pl} is a common stack of middleware functionality used to support SAP
+{sapS4pl} is a common stack of middleware functionalities used to support SAP
 business applications. The {sapERS} constitutes application
 level redundancy for one of the most crucial components of the {sapS4pl} stack,
 the enqueue service. An optimal effect of the enqueue replication mechanism can
@@ -31,7 +31,7 @@ architecture, implementation and maintenance of a {sleHA} cluster for
 //.Certified by SAP
 //image::SAP_Certi_Integration_SAPS4HANA_R.svg[SVG]
 
-For additional information on the simple mount architecture, also read:
+For additional information on the simple mount architecture, read:
 
 - {SUSE} blog article "Simple Mount Structure for SAP Application Platform"
 (https://www.suse.com/c/simple-mount-structure-for-sap-application-platform/).
@@ -48,7 +48,7 @@ are either available on the system or on the Internet. Among them are:
 
 - {SUSE} product documentation at https://documentation.suse.com/
 
-- {SUSE} best practices web page at https://documentation.suse.com/sbp/sap-16/
+- {SUSE} best practices Web page at https://documentation.suse.com/sbp/sap-16/
 
 - Supported high availability solutions by {sles4sap} overview at
 https://documentation.suse.com/sles-sap/sap-ha-support/

adoc/SAP-S4HA10-setup-simplemount-sle16/SAP-S4HA10-setup-simplemount-sle16-appendix.adoc

@@ -1,11 +1,11 @@
 :leveloffset: 0
 == Appendix
 
-=== CRM configuration of the two-node cluster
+=== CRM configuration of a two-node cluster
 
-Find below the complete crm configuration for {sap} system {mySid}. This example
-is for the two node cluster, but without priority fencing.
-In a multi-node cluster you will find additional node entries like *node 3: {my3nd3}*.
+Find below the complete `crm` configuration for {sap} system {mySid}. This example
+is for the two-node cluster, but without priority fencing.
+In a multi-node cluster, you will find additional node entries like *node 3: {my3nd3}*.
 // TODO PRIO1: adapt the below example
 [subs="attributes"]
 ----
@@ -61,9 +61,9 @@ op_defaults op-options: \
 
 === CRM configuration fragments of the two-node cluster with priority fencing
 
-Find below crm configuration fragments for {sap} system {mySid}. This example
-shows the specific items for the two node cluster with priority fencing.
-This configuration is basically the same as above, except the items shown below.
+Find below `crm` configuration fragments for {sap} system {mySid}. This example
+shows the specific items for the two-node cluster with priority fencing.
+This configuration matches the previous one, except for the following items:
 // TODO PRIO1: check the below example
 [subs="attributes"]
 ----
@@ -91,7 +91,7 @@ property cib-bootstrap-options: \
 
 === Corosync configuration of the two-node cluster
 
-Find below the Corosync configuration for one corosync ring. Ideally two rings would be used.
+Find below the Corosync configuration for one corosync ring. Ideally, two rings are used.
 // TODO PRIO1: check the below example
 [subs="specialchars,attributes"]
 ----
@@ -138,7 +138,7 @@ nodelist {
 
 === Corosync configuration of the multi-node cluster
 
-Find below the Corosync configuration for one corosync ring. Ideally two rings would be used.
+Find below the Corosync configuration for one corosync ring. Ideally, two rings aree used.
 // TODO PRIO1: check the below example
 [subs="specialchars,attributes,quotes"]
 ----

adoc/SAP-S4HA10-setup-simplemount-sle16/SAP-S4HA10-setup-simplemount-sle16-multinode.adoc

@@ -1,19 +1,18 @@
 [[multicluster]]
-== Multi-node cluster setups for {sapS4}
+== Setting up multi-node cluster setups for {sapS4}
 
-*Multi-node cluster* setups mean cluster configurations with more than two nodes.
-Depending on the starting point it is possible to extend a two-node cluster setup
+*Multi-node cluster* setups are cluster configurations with more than two nodes.
+Depending on the starting point, you can or extend a two-node cluster setup
 or directly start with more than two nodes for an ASCS / ERS high availability setup.
-The examples below will show the setting up of multi-node cluster and the extension
-of an existing two node cluster pair. The major configuration changes will be shown
-and the basic preparation of the new cluster member node.
-
-The task list to set up the three node cluster is similar to the task list for the
-two-node cluster. However, some details are described different here to get a diskless
-SBD setup. Such a diskless SBD setup is an optional improvement for three nodes, but
-does not work for two nodes. On the other hand, priority fencing is an optional improvement
-for two nodes, but does not work for three nodes. An example priority fencing configuration
-for the two-node cluster is shown in the appendix.
+The following examples show how to set up a multi-node cluster and how to extend
+an existing two-node cluster. They outline major configuration changes and the basic 
+preparation of a new member node.
+The task list for setting up a three-node cluster is similar to the task list for a
+two-node cluster. However, some details differ to allow for a diskless
+SBD setup. A diskless SBD setup is an optional improvement for three nodes, but
+does not work on two nodes. Conversely, priority fencing is an optional improvement
+for two nodes, but does not work on three nodes. An example priority fencing configuration
+for a two-node cluster is available in the appendix.
 See the {sleHA} product documentation for details.
 // TODO PRIO2: fix product links
 // (https://documentation.suse.com/sle-ha/15-SP3/single-html/SLE-HA-administration/#pro-ha-storage-protect-fencing).
@@ -23,18 +22,18 @@ NOTE: When extending a cluster from two to three nodes, make sure to not use pri
 ////
 .Tasks
 
-. OS preparation and install the cluster software
+. Preparing the OS and installing the cluster software
 . Preparing watchdog and SBD parameters for diskless SBD
-. Configure the cluster base including corosync and resource manager with diskless SBD
-. Configure the cluster resources
-. Tune the cluster timing in special for the SBD.
+. Configuring the cluster base including corosync and resource manager with diskless SBD
+. Configuring the cluster resources
+. Tuning the cluster timing in special for the SBD.
 ////
 
 ////
 // BEGIN OF BLOCKED CHAPTERS FOR MULTINODE 2019-06-18
 === Setting up multi-node cluster from the top with diskless SBD
 
-A fencing mechanism is essential for cluster controlled infrastructures. Sometimes there is no possibility
+A fencing mechanism is essential for cluster-controlled infrastructures. Sometimes there is no possibility
 to have a shared block device or an IPMI device. A solution for such environments could be the
 diskless SBD option. SBD can be operated in a diskless mode. In this mode, a watchdog device will be
 used to reset the node in the following cases: if it loses quorum, if any monitored daemon is lost and not
@@ -48,7 +47,7 @@ SBD in diskless mode cannot handle split brain scenarios for two-node clusters.
 ==== Preparing the operating system and installing the cluster software
 
 In general the OS preparation is similar to the procedure described for the two node cluster.
-This includes the setup of NTP as well as installing the software pattern *ha_sles* using *yast2* or *zypper*.
+This includes the setup of NTP as well as installing the software pattern `ha_sles` using `yast2` or `zypper`.
 
 ==== Preparing watchdog and SBD parameters for diskless SBD
 
@@ -219,14 +218,14 @@ for the two node cluster.
 . Patching the existing nodes
 . Preparing the new node's operating system
 . Installing the cluster software on the new node
-. Preparing SAPStartSrv resource agent on the new node
+. Preparing *SAPStartSrv* resource agent on the new node
 . Preparing the SAP installation on the new node
 . Adding the new node to the cluster
 . Testing the new cluster configuration
 
 ==== Backing up the current cluster
 
-To *back up the current cluster*, perform a
+To *back up the current cluster*, perform a 
 ==========
 
 * Backup of your system including
@@ -238,17 +237,17 @@ The system is configured as described in the SUSE Best Practices document
 __SAP S/4 HANA - Enqueue Replication 2 High Availability Cluster With Simple Mount - Setup Guide__.
 
 To *back up the cluster configuration*, go to one of the cluster nodes and save
-the cluster configuration with _crm_ and _crm report_ commands:
+the cluster configuration with the _crm_ and _crm report_ commands:
 
 [subs="attributes"]
 ----
 # crm configure save 2nodes_crm.txt
 # supportconfig
 ----
 
-Back up the existing /etc/corosync/corosync.conf and all other files which may
-be important for a restore. This example is one method for creating a backup.
-The important point is using an external destination.
+Back up the existing _/etc/corosync/corosync.conf_ and all other files required to restore the system.
+The following example is one method for creating a backup. 
+The important step is storing the backup on an external destination.
 
 [subs="specialchars,attributes,quotes"]
 ----
@@ -265,25 +264,25 @@ The important point is using an external destination.
 
 ==== Installing the operating system of the new node
 
-We recommend using automating the installation to ensure that the system setup
-across nodes is identical. Make sure to document any additional steps you take
-beyond the automated setup. In our example, we deploy the machines with Agama
-and use Ansible for the configuration.
+We recommend using automated installation to ensure that the system setup
+across nodes is identical. Document any additional steps taken
+beyond the automated setup. In this example, we deploy machines with Agama
+and use Ansible for configuration.
 
 ==== Patching the existing nodes
 
 If applicable, install the latest updates and patches on your existing nodes.
-Alternatively, if you are using frozen repositories such as those provided by
-Multi Linux Manager, add the new system to the same repositories, so they have
+Alternatively, if you are using frozen repositories, such as those provided by
+SUSE Multi Linux Manager, add the new system to the same repositories to ensure they have
 the same patch level as your existing nodes.
 
-Use `zypper patch` or `zypper update` depending on your company's rules.
+Use `zypper patch` or `zypper update`, depending on your company's rules.
 
 - We recommend installing the latest available patches to guarantee system stability
 and hardening. Bug fixing and security patches help avoid unplanned outages and make
 the system less vulnerable.
 
-There are multiple ways:
+There are multiple ways to do so:
 
 [subs="specialchars,attributes,quotes"]
 ----
@@ -303,7 +302,7 @@ There are multiple ways:
 # ping <hostname>
 ----
 
-- Set up *chrony* (this is best done with *yast2*) and enable it:
+- Set up `chrony` (this is best done with `yast2`) and enable it:
 +
 [subs="specialchars,attributes,quotes"]
 ----
@@ -337,19 +336,19 @@ same patch level and that all required reboots have been performed.
 
 ============
 
-==== Preparing SAPStartSrv resource agent on the new node
+==== Preparing *SAPStartSrv* resource agent on the new node
 
-- Enable the sapping and sappong services.
+- Enable the `sapping` and `sappong` services.
 +
 [subs="specialchars,attributes,quotes"]
 ----
 # systemctl enable sapping
 # systemctl enable sappong
 ----
 
-After installing all necessary packages, compare installed package versions.
+After installing all necessary packages, compare the installed package versions.
 
-.Check that all nodes have the same software packages and versions:
+.Check if all nodes have the same software packages and versions:
 ============
 - On the existing cluster nodes, type:
 +
@@ -373,12 +372,12 @@ After installing all necessary packages, compare installed package versions.
 ----
 ============
 
-NOTE: If there any differences fix them first before you proceed.
+NOTE: If there are any differences, fix them first before you proceed.
 
 .Install and configure the watchdog device on the new machine.
 ============
 
-Instead of deploying the software-based solution, preferably use a hardware-based
+Instead of deploying the software-based solution, use a hardware-based
 watchdog device. The following example uses the software device but can be easily
 adapted to the hardware device.
 
@@ -392,7 +391,7 @@ adapted to the hardware device.
 ============
 
 NOTE: Ensure that the new node is connected to the same SBD disk connected to
-the existing two nodes. Ensure that the new node has the exact same SBD
+the existing two nodes. Ensure that the new node has identic SBD
 configurations as the two existing nodes
 
 [subs="attributes"]
@@ -402,12 +401,12 @@ configurations as the two existing nodes
 
 ==== Preparing the SAP installation on the new node
 
-With SWPM 2.0 (SP4 or later), which is part of the SL Toolset, SAP provides an new
+With SWPM 2.0 (SP4 or later), which is part of the SL Toolset, SAP provides a new
 option which can perform all necessary steps to prepare a fresh install server to
-be able to fit into an existing SAP system. This new option will help us to prepare
-a new host which can later run either the ASCS or ERS in the cluster environment.
+be able to fit into an existing SAP system. This new option helps  to prepare
+a new host which can later run either ASCS or ERS in the cluster environment.
 
-You need to create the directory structure that should run the SAP resource.
+Create the directory structure that should run the SAP resource.
 The instance directory is located on an NFS share for all nodes.
 
 - Create mount points and mount NFS shares on the new added node ({my3nd3}):
@@ -464,10 +463,11 @@ The next step requires the following information:
 # /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/<SID>/SYS/profile/<SID>_ASCS<instanceNumberAscs>_<virtHostNameAscs> -reg
 ----
 +
-NOTE: This must be done for each instance. Call sapstartsrv with parameters *pf=*<profile-of-the-sap-instance> and *-reg*.
+NOTE: This must be done for each instance. 
+Call `sapstartsrv` with parameters *pf=*<profile-of-the-sap-instance> and *-reg*.
 +
 
-- Disable *systemd* services of the ASCS and the ERS {sap} instance:
+- Disable `systemd` services of the ASCS and the ERS {sap} instance:
 +
 [subs="specialchars,attributes"]
 ----
@@ -478,7 +478,7 @@ NOTE: This must be done for each instance. Call sapstartsrv with parameters *pf=
 NOTE: This is mandatory for giving control over the instance to the HA cluster.
 +
 
-- Check the {sap} *systemd* integration:
+- Check the {sap} `systemd` integration:
 +
 [subs="specialchars,attributes"]
 ----
@@ -501,8 +501,8 @@ systemctl --no-ask-password start SAP{mySid}_{myErsIno} # sapstartsrv pf=/usr/sa
 .Adding the New Node to the Cluster
 ==========
 Check if the SBD device is available in case the SBD fencing method is in place
-for the two nodes. If the existing cluster using a different, supported fencing
-mechanism check and verify them too for the new cluster node.
+for the two nodes. If the existing cluster uses a different, supported fencing
+mechanism, check and verify it also for the new cluster node.
 
 [subs="specialchars,attributes,quotes"]
 ----
@@ -527,14 +527,14 @@ the file _/etc/corosync/corosync.conf_.
 # corosync-quorumtool -s
 ----
 
-The values *expected_votes* and *two_node* should now look like this on all nodes:
+The values *expected_votes* and *two_node* should now look like the following on all nodes:
 
 ----
 expected_votes: 3
 two_node: 0
 ----
 
-Modify the cluster configuration and set a new colocation rule with _crm_:
+Modify the cluster configuration and set a new colocation rule with `crm`:
 
 [subs="specialchars,attributes,quotes"]
 ----
@@ -545,21 +545,21 @@ Modify the cluster configuration and set a new colocation rule with _crm_:
 
 ==== Testing the new cluster configuration
 
-It is highly recommended to run certain test to verify that the new configuration
-is working as expected. A list of test can be found in the basic setup for the two
+We recommend running test to verify that the new configuration
+is working as expected. Find a list of tests in the basic setup for the two
 node cluster above.
 
 === Pros and Cons for odd and even numbers of cluster nodes
 
 There are certain use cases and infrastructure requirements which end up in different
-setups. We will cover some advantages and disadvantages of special configuration below:
+setups. Below, find a list of advantages and disadvantages of special configurations:
 
 * The two node cluster and two locations
     - Advantage: symmetric spread of all nodes over all locations
     - Disadvantage: no diskless SBD feature allowed for all two node clusters
 * The two node cluster and more than two locations
-    - Advantage: SBD device can be provided from there (must be HA himself)
-    - Advantage: cluster could operate with three SBD devices from different locations
+    - Advantage: SBD device can be provided from there (must be HA itself)
+    - Advantage: cluster can operate with three SBD devices from different locations
     - Disadvantage: no diskless SBD feature allowed for all two node clusters
 * The three node cluster and two locations
     - Advantage: less complex infrastructure