SLES4SAP-hana-angi-perfopt-15.adoc SLES4SAP-hana-angi-scaleout-perfop…

…t-15.adoc: Abstract. Misc. details, alert-fencing

adoc/SLES4SAP-hana-angi-perfopt-15.adoc

@@ -75,25 +75,31 @@ Ask your public cloud provider or your SUSE contact for more information.
 
 See <<cha.hana-sr.scenario>> for details.
 
+NOTE: In this guide the software package SAPHanaSR-angi is used. This package replaces
+the two packages SAPHanaSR and SAPHanaSR-ScaleOut. Thus new deployment should be
+done with SAPHanaSR-angi only. For upgrading existing clusters to SAPHanaSR-angi,
+please read the blog article
+https://www.suse.com/c/how-to-upgrade-to-saphanasr-angi/ .
+
 ==== Scale-up versus scale-out
 
 // TODO PRIO2: add stonith resource to the graphic
 
-The first set of scenarios includes the architecture and development of _scale-up_ solutions.
+The first set of scenarios includes the topology of _scale-up_ solutions.
 
 .{HANA} System Replication Scale-Up in the Cluster
 image::hana_sr_in_cluster.svg[scaledwidth=70.0%]
 
-For these scenarios, {SUSE} has developed the scale-up
-resource agent package `{SAPHanaSR}`. System replication helps to
-replicate the database data from one computer to another computer to compensate for database failures (single-box replication).
+These scenarios are covered by the package SAPHanaSR-angi. System replication
+helps to replicate the database data from one computer to another computer to
+compensate for database failures (single-box replication).
 
 //.{HANA} System Replication Scale-Up in the Cluster
 //image::hana_sr_in_cluster.svg[scaledwidth=100.0%]
 
-The second set of scenarios includes the architecture and development of
-_scale-out_ solutions (multi-box replication). For these scenarios, {SUSE}
-has developed the scale-out resource agent package `{SAPHanaSR}-ScaleOut`.
+The second set of scenarios includes the toplogy of _scale-out_ solutions
+(multi-box replication). These scenarios are also covered by the package
+SAPHanaSR-angi.
 
 .{HANA} System Replication Scale-Out in the Cluster
 image::SAPHanaSR-ScaleOut-Cluster.svg[scaledwidth=70.0%]
@@ -1859,9 +1865,8 @@ clone cln_SAPHanaTop_{sapsid}_HDB{sapino} rsc_SAPHanaTop_{sapsid}_HDB{sapino} \
     meta clone-node-max=1 interleave=true
 ----
 
-Additional information about all parameters can be found with the command:
-
-`man ocf_suse_SAPHanaTopology`
+Additional information about all parameters can be found in manual page
+ocf_suse_SAPHanaTopology(7).
 
 Again, add the configuration to the cluster.
 
@@ -1893,14 +1898,13 @@ primitive rsc_SAPHanaFil_{sapsid}_HDB{sapino} ocf:suse:SAPHanaFilesystem \
     op start interval=0 timeout=10 \
     op stop interval=0 timeout=20 \
     op monitor interval=12 timeout=120 \
-    params SID={sapsid} InstanceNumber={sapino} ACTION_ON_FAIL="fence"
+    params SID={sapsid} InstanceNumber={sapino} ON_FAIL_ACTION="fence"
 clone cln_SAPHanaFil_{sapsid}_HDB{sapino} rsc_SAPHanaFil_{sapsid}_HDB{sapino} \
     meta clone-node-max=1 interleave=true
 ----
 
-Additional information about all parameters can be found with the command:
-
-`man ocf_suse_SAPHanaFilesystem`
+Additional information about all parameters can be found in manual page
+ocf_suse_SAPHanaFilesystem(7).
 
 Again, add the configuration to the cluster.
 
@@ -1910,7 +1914,7 @@ Again, add the configuration to the cluster.
 ----
 
 The most important parameters here are SID and InstanceNumber, which are
-quite self explaining in the SAP context. ACTION_ON_FAIL defines how the RA
+quite self explaining in the SAP context. ON_FAIL_ACTION defines how the RA
 should react on monitor failures. Beside these parameters, typical
 tuneables are the timeout values or the operations (start, monitor, stop).
 
@@ -1960,12 +1964,19 @@ primary will be registered after the time difference is passed. If
 "only" the SAP HANA RDBMS has crashed, the former primary will be
 registered immediately. After this registration to the new primary, all
 data will be overwritten by the system replication.
+
+|ON_FAIL_ACTION
+| Defines how the  RA escalates monitor failures on an HANA primary node.
+If srHook=SOK, in case of monitor failure an node fencing could be triggered.
+For srHook=SFAIL, the restart will be proceeded as usual. ON_FAIL_ACTION=*fence*
+may speed up takeover, depending on how long HANA needs for stopping.
+See also SAPHanaSR-alert-fencing(8). This option currently is *unsupported*.
 |=======================================================================
 
-Additional information about all parameters of the SAPHanaController RA can be
-found with the following command:
+// TODO PRIO1: change above, once it is supported
 
-`man ocf_suse_SAPHanaController`
+Additional information about all parameters of the SAPHanaController RA can be
+found in manual page ocf_suse_SAPHanaController(7).
 
 [subs="attributes,quotes"]
 ----
@@ -3340,7 +3351,7 @@ primitive rsc_SAPHanaTop_{sapsid}_HDB{sapino} ocf:suse:SAPHanaTopology \
 primitive rsc_SAPHanaFil_{sapsid}_HDB{sapino} ocf:suse:SAPHanaFilesystem \
     op start interval=0 timeout=10 \
     op stop interval=0 timeout=20 \
-    op monitor interval=120 timeout=120 ACTION_ON_FAIL="fence" \
+    op monitor interval=120 timeout=120 ON_FAIL_ACTION="fence" \
     params SID={sapsid} InstanceNumber={sapino}
 
 primitive rsc_SAPHanaCon_{sapsid}_HDB{sapino} ocf:suse:SAPHana \