From 49287b072f677ce22a5a1529605f5a99cd547e5f Mon Sep 17 00:00:00 2001 From: lpinne Date: Mon, 27 May 2024 12:37:08 +0200 Subject: [PATCH] SAPNotes_HANA20_angi_15.adoc SLES4SAP-hana-angi-scaleout-perfopt-15.adoc Var_SLES4SAP-hana-angi-scaleout-perfopt-15.txt: first adaption --- adoc/SAPNotes_HANA20_angi_15.adoc | 8 +- ...LES4SAP-hana-angi-scaleout-perfopt-15.adoc | 285 ++++++++++-------- ...SLES4SAP-hana-angi-scaleout-perfopt-15.txt | 2 +- 3 files changed, 167 insertions(+), 128 deletions(-) diff --git a/adoc/SAPNotes_HANA20_angi_15.adoc b/adoc/SAPNotes_HANA20_angi_15.adoc index 8fe303fd7..7f5bc54ad 100644 --- a/adoc/SAPNotes_HANA20_angi_15.adoc +++ b/adoc/SAPNotes_HANA20_angi_15.adoc @@ -10,7 +10,7 @@ SUSE product manuals and documentation:: Release notes:: https://www.suse.com/releasenotes/ Online documentation of {sles4sapa}:: - https://documentation.suse.com/sles-sap/15-SP6/ + https://documentation.suse.com/sles-sap/15-SP4/ Online documentation of {sleha}:: {haAdminGuide15} Deployment guide for {sls}:: @@ -320,8 +320,6 @@ Fail-Safe Operation of {SAPHANA}: {SUSE} Extends Its High-Availability Solution: // -// REVISION 1.0 2022/02 -// - copied from SAPNotes_s4_1809.adoc -// REVISION 1.1 2022/03 -// - include SAPHanaSR-ScaleOut 15, CostOpt 15 +// REVISION 1.0 (2024-05-27) +// - copied from scale-out multi-target // diff --git a/adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc b/adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc index b2de751b3..7ee015b6c 100644 --- a/adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc +++ b/adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc @@ -6,7 +6,7 @@ include::Var_SLES4SAP-hana-scaleOut-multiTarget-PerfOpt-15-param.txt[] // Start of the document // -= {saphana} System Replication Scale-Out - Multi-Target Performance-Optimized Scenario += {saphana} System Replication Scale-Out - Performance-Optimized Scenario: with SAPHanaSR-angi // TODO PRIO3: use variables like {usecase}, as in scale-up @@ -105,7 +105,7 @@ This document describes how to set up {saphana} scale-out multi-target system replication with a cluster installed on two sites (and a third site which acts as majority maker) based on {sles4sap} {pn15} SP4. Furthermore, it describes how to add an additional non-cluster site for a multi-target architecture. This concept can -also be used with {sles4sap} {pn15} SP1 or newer. +also be used with {sles4sap} {pn15} SP4 or newer. For a better understanding and overview, the installation and setup is subdivided into seven steps. @@ -130,7 +130,7 @@ set up a third site which is outside the {sleha} cluster but acts as additional .Cluster with {SAPHana} Multi-Target SR - performance optimized image::SAPHanaSR-ScaleOut-MultiTarget-Concept.svg[scaledwidth="100%"] -With SAPHanaSR-ScaleOut, various {saphana} scale-out configurations are supported. +With SAPHanaSR-angi, various {saphana} scale-out configurations are supported. Details on requirements and supported scenarios are given below. // TODO PRIO3: internal link to requirements section @@ -141,8 +141,8 @@ The scenario where {saphana} is configured for host auto-failover is explained a https://documentation.suse.com/sbp/all/html/SLES4SAP-hana-scaleOut-PerfOpt-15/index.html . NOTE: For upgrading an existing {saphana} scale-out system replication cluster from -SAPHanaSR-ScaleOut version 0.160, consult manual page SAPHanaSR-manageAttr(8) and -the blog article https://www.suse.com/c/sap-hana-scale-out-multi-target-upgrade/ . +classical SAPHanaSR-ScaleOut, consult manual page SAPHanaSR_upgrade_to_angi(8). + == Planning the installation @@ -281,6 +281,9 @@ of a {sle} High Availability Extension {pn15} cluster. It gathers information about the statuses and configurations of the {saphana} system replication. It is designed as a normal (stateless) clone resource. +The third resourrce agent is *SAPHanaFilesystem*. This RA +// TODO PRIO1: outline SAPHanaFilesystem RA + With the current version of resource agents, {saphana} system replication for scale-out is supported in the following scenarios or use cases: @@ -324,11 +327,11 @@ A site is noticed as "down" or "on error", if the *LandscapeHostConfiguration status* reflects this (return code 1). This happens when worker nodes are going down without any {saphana} standby nodes left. ERP-style {saphana} scale-out database will have no standby nodes by design. -Find more details on concept and implementation in manual page -SAPHanaSR-ScaleOut(7). +Find more details on concept and implementation in manual pages +SAPHanaSR-angi(7) and SAPHanaSR-ScaleOut(7). To achieve an automation of this resource handling process, use the -{saphana} resource agents included in the _SAPHanaSR-ScaleOut_ RPM package +{saphana} resource agents included in the _SAPHanaSR-angi_ RPM package delivered with {sles4sap}. You can configure the level of automation by setting the parameter @@ -339,7 +342,7 @@ Find configuration details in manual page ocf_suse_SAPHanaController(7). The resource agent for HANA in a Linux cluster does not trigger a takeover to the secondary site when a software failure causes one or more HANA processes to be restarted. The same is valid when a hardware error causes the index server to restart locally. -Therefor the SAPHanaSR-ScaleOut package contains the HA/DR provider hook script +Therefor the SAPHanaSR-angi package contains the HA/DR provider hook script susChkSrv.py. For details see manual page susChkSrv.py(7). Site 3 is connected as an additional system replication target to either {saphana} @@ -351,7 +354,7 @@ re-registering the 3rd site in case of takeover. Read the SAP Notes and papers first. -The _SAPHanaSR-ScaleOut_ resource agent software package +The _SAPHanaSR-angi_ resource agent software package supports scale-out (multiple-box to multiple-box) system replication with the following configurations and parameters: // TODO PRIO2: align prerequisites section with scale-up guide and man pages @@ -372,12 +375,12 @@ following configurations and parameters: * The {saphana} scale-out system must have only *one* active master name server per site. There are no configured master name server. * For {saphana} databases without additional master name server candidate, - the package SAPHanaSR-ScaleOut version 0.180 or newer is needed. + the package SAPHanaSR-angi version 1.2 or newer is needed. * The {saphana} scale-out system must have only *one* failover group. * There is maximum one additional {saphana} system replication connected from outside the Linux cluster. Thus two sites are managed by the Linux cluster, one site outside is recognized. For {saphana} multi-tier and multi-target - system replication, the package SAPHanaSR-ScaleOut version 0.180 or newer is needed. + system replication, the package SAPHanaSR-angi version 1.2 or newer is needed. * Only one {saphana} SID is installed. Thus the performance optimized setup is supported. The cost optimized and MCOS scenarios are currently not supported. * The _{sapHostAgent}_ must be running. _{sapHostAgent}_ is needed to translate @@ -385,7 +388,7 @@ following configurations and parameters: of {saphana}. ** For SystemV style, the sapinit script needs to be active. ** For systemd style, the services saphostagent and SAP_ can stay enabled. -The systemd enabled saphostagent and instance´s sapstartsrv is supported from SAPHanaSR-ScaleOut 0.181 onwards. +The systemd enabled saphostagent and instance´s sapstartsrv is supported from SAPHanaSR-angi 1.2 onwards. Refer to the OS documentation for the systemd version. {HANA} comes with native systemd integration as default starting with version 2.0 SPS07. Refer to {sap} documentation for the {sap} HANA version. @@ -397,14 +400,14 @@ However, all nodes in one Linux cluster have to use the same style. *off*. * The replication mode should be either 'sync' or 'syncmem'. 'async' is supported outside the Linux cluster. -* {HANA} 2.0 SPS05 rev.059 and later provides Python 3 as well as the HA/DR provider hook - method srConnectionChanged() with needed parameters for SAPHanaSrMultiTarget.py. +* {HANA} 2.0 SPS05 rev.059.04 and later provides Python 3 as well as the HA/DR provider hook + method srConnectionChanged() with needed parameters for susHanaSR.py. * {HANA} 2.0 SPS05 or later provides the HA/DR provider hook method srServiceStateChanged() with needed parameters for susChkSrv.py. * {HANA} 2.0 SPS06 or later provides the HA/DR provider hook method preTakeover() with multi-target aware parameters and separate return code for Linux HA clusters. * No other HA/DR provider hook script should be configured for the above mentioned methods. - Hook scripts for other methods, provided in SAPHanaSR-ScaleOut, can be used in parallel, + Hook scripts for other methods, provided in SAPHanaSR-angi, can be used in parallel, if not documented contradictingly. * The Linux cluster needs to be up and running to allow HA/DR provider events being written into CIB attributes. The current HANA SR status might differ from CIB srHook attribute @@ -427,20 +430,20 @@ The two {saphana} sites inside the Linux cluster can be configured to re-registe the outer {saphana} in case of takeover. For this a configuration item 'register_secondaries_on_takeover=true' needs to be added in the system_replication block of the global.ini file. -See also manual page SAPHanaSrMultiTarget.py(7). +See also manual page susHanaSR.py(7). ==== -* You need at least SAPHanaSR-ScaleOut version 0.184, {sles4sap} {pn15} SP1 and - {saphana} 2.0 SPS 05 for all mentioned setups. +* You need at least SAPHanaSR-angi version 1.2, {sles4sap} {pn15} SP4 and + {saphana} 2.0 SPS 05 rev.59.04 for all mentioned setups. * The Linux cluster can be either freshly installed as described in this guide, or it can be upgraded as described in respective documentation. Not allowed is mixing old and new cluster attributes or hook scripts within one cluster. Find more details in the REQUIREMENTS section of manual pages -SAPHanaSR-ScaleOut(7), ocf_suse_SAPHanaController(7), -SAPHanaSrMultiTarget.py(7), SAPHanaSR-manageAttr(8), susChkSrv.py(7) and susTkOver.py(7). +SAPHanaSR-ScaleOut(7), ocf_suse_SAPHanaController(7), ocf_suse_SAPHanaFilesystem(7), +susHanaSR.py(7), SAPHanaSR-manageAttr(8), susChkSrv.py(7) and susTkOver.py(7). IMPORTANT: You must implement a valid STONITH method. Without a valid STONITH method, the complete cluster is unsupported and will not work properly. @@ -459,6 +462,7 @@ the existing solution in your scenario. The limitation of most of the above items is mostly because of testing limits. + == Setting up the operating system .<> OsSetup <> <> <> <> <> <> @@ -504,7 +508,7 @@ The pattern _High Availability_ summarizes all tools recommended to be installed _majority maker_. * remove package: patterns-sap-hana, {sapHanaSR}, yast2-sap-ha -* install package: {sapHanaSR}-ScaleOut, {sapHanaSR}-ScaleOut-doc, ClusterTools2, saptune +* install package: SAPHanaSR-angi, ClusterTools2, saptune * install pattern: ha_sles To do so, for example, use Zypper: @@ -541,37 +545,34 @@ Continue? [y/n/...? shows all options] (y): y ---- ==== -.Installation of the {sapHanaSR} agent for scale-out +.Installation of the SAPHanaSR-angi agent for scale-out ==== As user root, type: ---- -# zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc +# zypper in SAPHanaSR-angi ---- If the package is not installed yet, you should get an output like the below: ---- Refreshing service 'Advanced_Systems_Management_Module_15_x86_64'. -Refreshing service 'SUSE_Linux_Enterprise_Server_for_SAP_Applications_15_SP3_x86_64'. +Refreshing service 'SUSE_Linux_Enterprise_Server_for_SAP_Applications_15_SP4_x86_64'. Loading repository data... Reading installed packages... Resolving package dependencies... -The following 2 NEW packages are going to be installed: - SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc +The following 1 NEW packages are going to be installed: + SAPHanaSR-angi 2 new packages to install. Overall download size: 539.1 KiB. Already cached: 0 B. After the operation, additional 763.1 KiB will be used. Continue? [y/n/...? shows all options] (y): y -Retrieving package SAPHanaSR-ScaleOut-0.180.1-1.1.noarch (1/2), 48.7 KiB (211.8 KiB unpacked) -Retrieving: SAPHanaSR-ScaleOut-0.180.1-1.1.noarch.rpm ....................................[done] -Retrieving package SAPHanaSR-ScaleOut-doc-0.180.1-1.1.noarch (2/2), 490.4 KiB (551.3 KiB unpacked) -Retrieving: SAPHanaSR-ScaleOut-doc-0.180.1-1.1.noarch.rpm ................................[done (48.0 KiB/s)] +Retrieving package SAPHanaSR-angi-1.2.5-150400-1.1.noarch (1/1), 48.7 KiB (211.8 KiB unpacked) +Retrieving: SAPHanaSR-angi-1.2.5-150400-1.1.noarch.rpm ....................................[done] Checking for file conflicts: .............................................................[done] -(1/2) Installing: SAPHanaSR-ScaleOut-0.180.1-1.1.noarch ..................................[done] -(2/2) Installing: SAPHanaSR-ScaleOut-doc-0.180.1-1.1.noarch ..............................[done] +(1/1) Installing: SAPHanaSR-angi-1.2.5-150400-1.1.noarch ..................................[done] ---- Install the tools for High Availability on all nodes. @@ -579,6 +580,7 @@ Install the tools for High Availability on all nodes. [subs="quotes,attributes"] ---- # zypper in --type pattern ha_sles +# zypper in ClusterTools2 ---- ==== @@ -610,8 +612,6 @@ As user root, type: ---- ==== -NOTE: The new srHook script "SAPHanaSrMultiTarget.py" necessary for multi-target setup is not available in the installation ISO media and only available from update channels of SUSE Linux Enterprise Server for SAP Applications 15 SP3 or earlier. Thus, for a correctly working multi-target setup, a full system patching is mandatory. From SUSE Linux Enterprise Server for SAP Applications 15 SP4 onwards the "SAPHanaSrMultiTarget.py" will be included in the ISO. - === Configuring {sles4sap} to run {saphana} ==== Tuning or modifying the operating system @@ -1390,14 +1390,14 @@ ERP style scale-out multi-target scenario. . Stop {saphana} . Configure system replication operation mode . Adapt {saphana} nameserver configuration -. Implement {haDrMultiTargetPy} for srConnectionChanged +. Implement susHanaSR.py for srConnectionChanged . Implement susChkSrv.py for srServiceStateChanged . Implement susTkOver.py for preTakeover . Allow {refsidadm} to access the cluster . Start {saphana} . Test the HA/DR provider hook script integration -NOTE: All hook scripts should be used directly from the SAPHanaSR-ScaleOut +NOTE: All hook scripts should be used directly from the SAPHanaSR-angi package. If the scripts are moved or copied, regular {SUSE} package updates will not work. @@ -1487,40 +1487,33 @@ Refer to {saphana} documentation for details. // TODO PRIO2: detailled command example for above change -=== Implementing {haDrMultiTargetPy} for srConnectionChanged +=== Implementing susHanaSR.py for srConnectionChanged -// TODO PRIO3: explain new default SAPHanaSrMultiTarget.py, even for non-multi-target +// TODO PRIO3: explain new default susHanaSR.py, even for non-multi-target This step must be done on both sites that will be part of the cluster. Use the {saphana} tools for changing global.ini and integrating the hook script. -In global.ini, the section `[ha_dr_provider_saphanasrmultitarget]` needs to be +In global.ini, the section `[ha_dr_provider_sushanasr]` needs to be created. The section `[trace]` might be adapted. -The ready-to-use HA/DR hook script is shipped with the SAPHanaSR-ScaleOut -package in directory /usr/share/SAPHanaSR-ScaleOut/. +The ready-to-use HA/DR hook script is shipped with the SAPHanaSR-angi +package in directory /usr/share/SAPHanaSR-angi/. The hook script must be available on all cluster nodes, including the majority -maker. Find more details in manual pages SAPHanaSrMultiTarget.py(7) and +maker. Find more details in manual pages susHanaSR.py(7) and SAPHanaSR-manageProvider(8). -.Adding {haDrMultiTargetPy} via global.ini +.Adding susHanaSR.py via global.ini =================================== ---- -[ha_dr_provider_saphanasrmultitarget] -provider = SAPHanaSrMultiTarget -path = /usr/share/SAPHanaSR-ScaleOut/ +[ha_dr_provider_sushanasr] +provider = susHanaSR +path = /usr/share/SAPHanaSR-angi/ execution_order = 1 [trace] -ha_dr_saphanasrmultitarget = info +ha_dr_sushanasr = info ---- =================================== -It is again reminded that the srHook script "{haDrMultiTargetPy}" necessary -for multi-target setup is not available in the installation ISO media. It is -only available in update channels of {sles4sap} 15 SP3 or earlier. So, for a -correctly working multi-target setup a full system patching is mandatory after -registering the system to SCC, RMT or SUSE Manager. From {sles4sap} 15 SP4 -onwards the "{haDrMultiTargetPy}" is included in the ISO. - === Implementing susChkSrv.py for srServiceStateChanged @@ -1590,8 +1583,9 @@ From {sles4sap} 15 SP5 onwards the "susTkOver.py" will be included in the ISO. === Allowing {refsidadm} to access the cluster -// TODO PRIO2: align with manual page SAPHanaSrMultiTarget.py(7), also gsh -The current version of the {haDrMultiTargetPy} python hook uses the command +// TODO PRIO2: align with manual page susHanaSr.py(7) +// TODO PRIO1: remove old attributes, gsh etc. +The current version of the susHanaSR.py python hook uses the command _sudo_ to allow the {refsidadm} user to access the cluster attributes. In Linux you can use _visudo_ to start the vi editor for the Linux system */etc/sudoers*. We recommend to use a specific file */etc/sudoers.d/SAPHanaSR* instead. That @@ -1601,7 +1595,7 @@ The user {refsidadm} must be able to set the cluster attributes hana_{refsidLC}_site_srHook_* and hana_{refsidLC}_gsh. The {saphana} system replication hook needs password free access. The following example limits the sudo access to exactly setting the needed attribute. -See manual pages sudoers(5), SAPHanaSrMultiTarget.py(7) and susChkSrv.py(7) for +See manual pages sudoers(5), susHanaSR.py(7) and susChkSrv.py(7) for details. .Entry in sudo permissions /etc/sudoers.d/SAPHanaSR file @@ -1613,26 +1607,10 @@ the uppercase SAP system ID. [subs="specialchars,attributes"] ---- # SAPHanaSR-ScaleOut needs for HA/DR hook scripts -{refsidadm} ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_{refsidLC}_site_srHook_* -{refsidadm} ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_{refsidLC}_gsh * -{refsidadm} ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_{refsidLC}_glob_mts * +{refsidadm} ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_{refsidLC}_* {refsidadm} ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid={refsid} * ---- -// TODO PRIO3: align with manual page SAPHanaSrMultiTarget.py(7) -//// -More specific parameters option to meet a high security level. -[subs="specialchars,attributes"] ----- -# SAPHanaSR-ScaleOut needs for srHook -Cmnd_Alias SOK = /usr/sbin/crm_attribute -n hana_{refsidLC}_glob_srHook -v SOK -t crm_config -s SAPHanaSR -Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_{refsidLC}_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR -Cmnd_Alias GSH = /usr/sbin/crm_attribute -n hana_{refsidLC}_glob_srHook -v * -l reboot -t crm_config -s SAPHanaSR -{refsidadm} ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid={refsid} --case=checkTakeover -{refsidadm} ALL=(ALL) NOPASSWD: SOK, SFAIL, GSH ----- -//// - Example for looking up the sudo permissions for the hook scripts. [subs="specialchars,attributes"] @@ -1681,19 +1659,25 @@ hook scripts have been loaded correctly. A useful verification is to check the {saphana} trace files as {refsidadm}. More complete checks wil be done later, when the Linux cluster is up and running. -==== Checking for SAPHanaSrMultiTarget.py +==== Checking for susHanaSR.py -Check if {saphana} has initialized the SAPHanaSrMultiTarget.py hook script for +Check if {saphana} has initialized the susHanaSR.py hook script for the srConnectionChanged events. Check the HANA name server trace files and the specific hook script trace file. Do this on both sites' master name server. -See also manual page SAPHanaSrMultiTarget.py(7). +See also manual page susHanaSR.py(7). + ---- ~> cdtrace -~> grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3 -~> grep SAPHanaSr.*init nameserver_*.trc | tail -3 -~> grep -A5 "init.called" nameserver_saphanasr_multitarget_hook.trc +~> grep HADR.*load.*susHanaSR nameserver_*.trc | tail -3 +~> grep susHanaSR.*init nameserver_*.trc | tail -3 ---- + // TODO PRIO2: output example +//// +// TODO PRIO2: correct filename? +~> grep -A5 "init.called" nameserver_saphanasr_multitarget_hook.trc +---- +//// // TODO PRIO2: what makes sense right after first init? should we move this example to general testing? //// @@ -1709,10 +1693,11 @@ nameserver. See also manual page SAPHanaSrMultiTarget.py(7). 2022-11-11 11:53:06.316973 ha_dr_SAPHanaS...SOK ---- // TODO PRIO2: some content here + ---- ~> cdtrace -~> grep SAPHanaSr.*srConnection.*CRM nameserver_*.trc -~> grep SAPHanaSr.*srConnection.*fallback nameserver_*.trc +~> grep susHanaSR.*srConnection.*CRM nameserver_*.trc +~> grep susHanaSR.*srConnection.*fallback nameserver_*.trc ---- //// @@ -1722,6 +1707,7 @@ Check if {saphana} has initialized the susChkSrv.py hook script for the srServiceStateChanged events. Check the HANA name server trace files and the specific hook script trace file. Do this on all nodes. See also manual page susChkSrv.py(7). + ---- ~> cdtrace ~> grep HADR.*load.*susChkSrv nameserver_*.trc | tail -3 @@ -1745,6 +1731,7 @@ See also manual page susChkSrv.py(7). Check if {saphana} has initialized the susTkOver.py hook script for the preTakeover events. Check the HANA name server trace. Do this on all nodes. See also manual page susTkOver.py(7). + ---- ~> cdtrace ~> grep HADR.*load.*susTkOver nameserver_*.trc | tail -3 @@ -1760,7 +1747,7 @@ image::SAPHanaSR-ScaleOut-MultiTarget-Plan-Phase6.svg[scaledwidth="100%"] This chapter describes the configuration of the {sleha} cluster. The {sleha} is part of {sles4sap}. Further, the integration of {saphana} System Replication with the {sleha} cluster is explained. The integration is done by using the -SAPHanaSR-ScaleOut package which is also part of {sles4sap}. +SAPHanaSR-angi package which is also part of {sles4sap}. .Procedure @@ -1775,18 +1762,21 @@ SAPHanaSR-ScaleOut package which is also part of {sles4sap}. If not already done, install the pattern _High Availability_ on *all* nodes. To do so, use zypper. + ---- # zypper in -t pattern ha_sles ---- -Now the Resource Agents for controlling the {saphana} system replication need +Now the resource agents for controlling the {saphana} system replication need to be installed at *all* cluster nodes, including the majority maker. + ---- # zypper in SAPHanaSR-ScaleOut ---- If you have the packages installed before, make sure to get the newest updates on *all* nodes + ---- # zypper patch ---- @@ -1866,7 +1856,8 @@ Testing the watchdog can be done with a simple action. Ensure to switch of your system. In case of a hardware watchdog a desired action is predefined after the timeout -of the watchdog has reached. If your watchdog module is loaded and not controlledby any other application, do the following: +of the watchdog has reached. If your watchdog module is loaded and not controlled +by any other application, do the following: IMPORTANT: Triggering the watchdog without continuously updating the watchdog resets/switches off the system. This is the intended mechanism. The following @@ -1899,7 +1890,7 @@ done ==== Basic cluster configuration using _ha-cluster-init_ For more detailed information about ha-cluster-* tools, see section _Overview of the Bootstrap Scripts_ of the Installation and Setup Quick Start Guide -for SUSE Linux Enterprise High Availability Extension at https://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-install-quick/#sec-ha-inst-quick-bootstrap. +for SUSE Linux Enterprise High Availability Extension at https://documentation.suse.com/sle-ha/15-SP4/single-html/SLE-HA-install-quick/#sec-ha-inst-quick-bootstrap. Create an initial setup by using the _ha-cluster-init_ command. Follow the dialog steps. @@ -1943,6 +1934,7 @@ module matching your systems. In the example at hand the _softdog_ kernel module Now it is time to check and optionally start the cluster for the first time on all nodes. + ---- # crm cluster run "crm cluster start" ---- @@ -1952,6 +1944,7 @@ NOTE: All nodes should be started in parallel. Otherwise unseen nodes might get Check whether all cluster nodes have registered at the SBD device(s). See manual page cs_show_sbd_devices(8) for details. + ---- # cs_show_sbd_devices ---- @@ -1959,6 +1952,7 @@ page cs_show_sbd_devices(8) for details. Check the cluster status with `crm_mon`. Use the option `-r` to also see resources which are configured but stopped. + ---- # crm_mon -r ---- @@ -1974,7 +1968,7 @@ Current DC: hanamm (version 1.1.16-4.8-77ea74d) - partition with quorum Last updated: Mon July 25 16:55:04 2022 Last change: Mon July 25 16:53:58 2022 by root via crm_attribute on hanaso2 -7 nodes configured +5 nodes configured 1 resource configured Online: [ hanamm hanaso0 hanaso1 hanaso2 hanaso3 ] @@ -1989,7 +1983,7 @@ stonith-sbd (stonith:external/sbd): Started hanamm This section describes how to configure bootstrap, STONITH, resources, and constraints using the _crm_ configure shell command as described in section _Configuring and Managing Cluster Resources (Command Line)_ of the -{sleha} Administration Guide (see https://documentation.suse.com/sle-ha/15-SP1/html/SLE-HA-all/cha-ha-manual-config.html). +{sleha} Administration Guide (see https://documentation.suse.com/sle-ha/15-SP4/html/SLE-HA-all/cha-ha-manual-config.html). Use the command _crm_ to add the objects to the Cluster Resource Management (CRM). Copy the following examples to a local file and then load the @@ -2126,7 +2120,7 @@ Enter the following to _crm-saphanatop.txt_: [subs="attributes,quotes"] ---- primitive rsc_SAPHanaTop_{refSID}_HDB{refInst} ocf:suse:SAPHanaTopology \ - op monitor interval="10" timeout="600" \ + op monitor interval="50" timeout="600" \ op start interval="0" timeout="600" \ op stop interval="0" timeout="300" \ params SID="**{refSID}**" InstanceNumber="**{refInst}**" @@ -2141,7 +2135,7 @@ clone cln_SAPHanaTop_{refSID}_HDB{refInst} rsc_SAPHanaTop_{refSID}_HDB{refInst} [subs="attributes,specialchars,quotes"] ---- primitive rsc_SAPHanaTop\_**{SID}**_HDB**{Inst}** ocf:suse:SAPHanaTopology \ - op monitor interval="10" timeout="600" \ + op monitor interval="50" timeout="600" \ op start interval="0" timeout="600" \ op stop interval="0" timeout="300" \ params SID="**{SID}**" InstanceNumber="**{Inst}**" @@ -2187,18 +2181,18 @@ Enter the following to crm-saphanacon.txt primitive rsc_SAPHanaCon_{refSID}_HDB{refInst} ocf:suse:SAPHanaController \ op start interval="0" timeout="3600" \ op stop interval="0" timeout="3600" \ - op promote interval="0" timeout="3600" \ + op promote interval="0" timeout="900" \ op demote interval="0" timeout="320" \ - op monitor interval="60" role="Master" timeout="700" \ - op monitor interval="61" role="Slave" timeout="700" \ + op monitor interval="60" role="Promoted" timeout="700" \ + op monitor interval="61" role="Unpromoted" timeout="700" \ params SID="{refSID}" InstanceNumber="{refInst}" \ PREFER_SITE_TAKEOVER="true" \ DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \ HANA_CALL_TIMEOUT="120" -ms msl_SAPHanaCon_{refSID}_HDB{refInst} \ +clone mst_SAPHanaCon_{refSID}_HDB{refInst} \ rsc_SAPHanaCon_{refSID}_HDB{refInst} \ - meta master-node-max="1" master-max="1" clone-node-max="1" interleave="true" \ + meta clone-node-max="1" promotable="true" interleave="true" \ maintenance="true" ---- @@ -2206,11 +2200,11 @@ The most important parameters here are {refSID} ({SID}) and {refInst} ({Inst}), which are in the SAP context quite self explaining. Beside these parameters, the timeout values or the operations (start, monitor, stop) are typical tuneables. -Find more details in manual page ocf_suse_SAPHanaTopology(7). +Find more details in manual page ocf_suse_SAPHanaController(7). // !! The example title MUST NOT include a line break in the ADOC source !! //.In our setup we replace {refSID} by {mySID} and {refInst} by {Inst} -//=========================== + [subs="specialchars,attributes,quotes"] ---- primitive rsc_SAPHanaCon_**{SID}**_HDB**{Inst}** ocf:suse:SAPHanaController \ @@ -2218,17 +2212,16 @@ primitive rsc_SAPHanaCon_**{SID}**_HDB**{Inst}** ocf:suse:SAPHanaController \ op stop interval="0" timeout="3600" \ op promote interval="0" timeout="900" \ op demote interval="0" timeout="320" \ - op monitor interval="60" role="Master" timeout="700" \ - op monitor interval="61" role="Slave" timeout="700" \ + op monitor interval="60" role="Promoted" timeout="700" \ + op monitor interval="61" role="Unpromoted" timeout="700" \ params SID="**{SID}**" InstanceNumber="**{Inst}**" PREFER_SITE_TAKEOVER="true" \ DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \ HANA_CALL_TIMEOUT="120" -ms msl_SAPHanaCon_{SID}_HDB{Inst} rsc_SAPHanaCon_{SID}_HDB{Inst} \ - meta master-node-max="1" master-max="1" clone-node-max="1" interleave="true" \ +clone msl_SAPHanaCon_{SID}_HDB{Inst} rsc_SAPHanaCon_{SID}_HDB{Inst} \ + meta clone-node-max="1" promotable="true" interleave="true" \ maintenance="true" ---- -//=========================== Add the configuration to the cluster. @@ -2238,6 +2231,54 @@ Add the configuration to the cluster. ---- ========== +//// +// TODO PRIO1: SAPHanaFilesystem RA + + +.Configure SAPHanaFilesystem +========== +Enter the following to crm-saphanafil.txt + +[subs="specialchars,attributes"] +---- +primitive rsc_SAPHanaCon_{refSID}_HDB{refInst} ocf:suse:SAPHanaFilesystem \ + op start interval="0" timeout="120" \ + op stop interval="0" timeout="120" \ + op monitor interval="120" timeout="700" \ + params SID="{refSID}" InstanceNumber="{refInst}" + +clone cln_SAPHanaFil_{refSID}_HDB{refInst} \ + rsc_SAPHanaFil_{refSID}_HDB{refInst} \ + meta clone-node-max="1" interleave="true" +---- + +The most important parameters here are {refSID} ({SID}) and {refInst} +({Inst}), which are in the SAP context quite self explaining. +Beside these parameters, the timeout values or the operations (start, monitor, +stop) are typical tuneables. +Find more details in manual page ocf_suse_SAPHanaFilesystem(7). + +[subs="specialchars,attributes,quotes"] +---- +primitive rsc_SAPHanaFil_**{SID}**_HDB**{Inst}** ocf:suse:SAPHanaFilesystem \ + op start interval="0" timeout="120" \ + op stop interval="0" timeout="120" \ + op monitor interval="120" timeout="120" \ + params SID="**{SID}**" InstanceNumber="**{Inst}**" + +clone cln_SAPHanaFil_{SID}_HDB{Inst} rsc_SAPHanaFil_{SID}_HDB{Inst} \ + meta clone-node-max="1" interleave="true" +---- + +Add the configuration to the cluster. + +[subs="specialchars,attributes"] +---- +# crm configure load update crm-saphanafil.txt +---- +========== +//// + // [cols="1,2", options="header"] [width="100%",cols="40%,60%",options="header"] .Table Description of important Resource Agent parameter @@ -2336,15 +2377,17 @@ Enter the following to _crm-cs.txt_: [subs="specialchars,attributes"] ---- colocation col_saphana_ip_{refSID}_HDB{refInst} 2000: rsc_ip_{refSID}_HDB{refInst}:Started \ - msl_SAPHanaCon_{refSID}_HDB{refInst}:Master + mst_SAPHanaCon_{refSID}_HDB{refInst}:Promoted order ord_SAPHana_{refSID}_HDB{refInst} Optional: cln_SAPHanaTop_{refSID}_HDB{refInst} \ - msl_SAPHanaCon_{refSID}_HDB{refInst} + mst_SAPHanaCon_{refSID}_HDB{refInst} -location SAPHanaCon_not_on_majority_maker msl_SAPHanaCon_{refSID}_HDB{refInst} \ +location SAPHanaCon_not_on_majority_maker mst_SAPHanaCon_{refSID}_HDB{refInst} \ -inf: {refHostmj} location SAPHanaTop_not_on_majority_maker cln_SAPHanaTop_{refSID}_HDB{refInst} \ -inf: {refHostmj} +location SAPHanaFil_not_on_majority_maker cln_SAPHanaFil_{refSID}_HDB{refInst} \ + -inf: {refHostmj} ---- // !! The example title MUST NOT include a line break in the ADOC source !! @@ -2352,13 +2395,14 @@ location SAPHanaTop_not_on_majority_maker cln_SAPHanaTop_{refSID}_HDB{refInst} \ [subs="attributes,quotes"] ---- colocation col_saphana_ip_**{SID}**\_HDB**{Inst}** 2000: rsc_ip_**{SID}**\_HDB**{Inst}**:Started \ - msl_SAPHanaCon_**{SID}**\_HDB**{Inst}**:Master + mst_SAPHanaCon_**{SID}**\_HDB**{Inst}**:Master order ord_SAPHana_**{SID}**\_HDB**{Inst}** Optional: cln_SAPHanaTop_**{SID}**\_HDB**{Inst}** \ - msl_SAPHanaCon_**{SID}**\_HDB**{Inst}** + mst_SAPHanaCon_**{SID}**\_HDB**{Inst}** location SAPHanaCon_not_on_majority_maker msl_SAPHanaCon_**{SID}**\_HDB**{Inst}** -inf: **{hanamm}** -location SAPHanaTop_not_on_majority_maker cln_SAPHanaTop_**{SID}**_HDB**{Inst}** -inf: **{hanamm}** +location SAPHanaTop_not_on_majority_maker cln_SAPHanaTop_**{SID}**\_HDB**{Inst}** -inf: **{hanamm}** +location SAPHanaFil_not_on_majority_maker cln_SAPHanaFil_**{SID}**\_HDB**{Inst}** -inf: **{hanamm}** ---- Load the file to the cluster. @@ -2397,7 +2441,7 @@ primitive rsc_ip_ro_{refSID}_HDB{refInst} ocf:heartbeat:IPaddr2 \ params ip="" colocation col_ip_ro_with_secondary_{refSID}_HDB{refInst} \ 2000: rsc_ip_ro_{refSID}_HDB{refInst}:Started \ - msl_SAPHanaCon_{refSID}_HDB{refInst}:Slave + mst_SAPHanaCon_{refSID}_HDB{refInst}:Unpromoted location loc_ip_ro_not_master_{refSID}_HDB{refInst} \ rsc_ip_ro_{refSID}_HDB{refInst} \ rule -inf: hana_{refSIDLC}_roles ne master1:master:worker:master @@ -2412,7 +2456,7 @@ primitive rsc\_ip_ro_**{SID}**\_HDB**{Inst}** ocf:heartbeat:IPaddr2 \ params ip="*{myVipADSec}*" colocation col_ip_ro_with_secondary_**{SID}**\_HDB**{Inst}** \ 2000: rsc_ip_ro_**{SID}**\_HDB**{Inst}**:Started \ - msl_SAPHanaCon_**{SID}**\_HDB**{Inst}**:Slave + mst_SAPHanaCon_**{SID}**\_HDB**{Inst}**:Unpromoted location loc_ip_ro_not_master_**{SID}**\_HDB**{Inst}** \ rsc_ip_ro_**{SID}**\_HDB**{Inst}** \ rule -inf: hana_**{SIDLC}**_roles ne master1:master:worker:master @@ -2439,6 +2483,8 @@ See also manual page SAPHanaSR-ScaleOut_basic_cluster(7). Now check if the HA/DR provider could set the appropriate cluster attribute hana_{refsidLC}_glob_srHook: +//// +// TODO PRIO1: correct attribute name? .Query the srHook cluster attribute ========== [subs="specialchars,attributes"] @@ -2453,7 +2499,7 @@ You should get an output similar to the following: scope=crm_config name=hana_{refsidLC}_glob_srHook value=SFAIL ---- ========== - +//// In this case the HA/DR provider sets the attribute to SFAIL to inform the cluster about a broken system replication. @@ -2485,9 +2531,9 @@ detect the {HANA} status and set the SAPHanaController resource out of maintenan ---- # crm maintenance off # cs_wait_for_idle -s 5 -# crm resource refresh msl_SAPHanaCon_{SID}_HDB{Inst} +# crm resource refresh mst_SAPHanaCon_{SID}_HDB{Inst} # cs_wait_for_idle -s 5 -# crm resource maintenance msl_SAPHanaCon_{SID}_HDB{Inst} off +# crm resource maintenance mst_SAPHanaCon_{SID}_HDB{Inst} off ---- ========== @@ -2496,6 +2542,7 @@ For more details, see manual pages cs_wait_for_idle(8), crm(8), SAPHanaSR_maintenance_examples(7). + == Setup of a scale-out multi-target architecture .<> <> <> <> <> <> MultiTarget <> @@ -3115,12 +3162,6 @@ subs attribute accepts any of the following (in a list): include::common_gfdl1.2_i.adoc[] // -// REVISION 0.1 (2021-09-06) -// - copied from 12 and replaced version strings, URLs, SAP notes, TIDs -// REVISION 0.2 (2022-03-08) -// - prepared for systemd, established includes -// REVISION 0.3 (2023-04-03) -// - SAP native systemd support is default for HANA 2.0 SPS07 -// REVISION 0.3a (2024-02-14) -// - HANA 2.0 SPS05 rev.059 Python 3 needed +// REVISION 0.1 (2024-05-27) +// - copied from classic scale-out multi-target // diff --git a/adoc/Var_SLES4SAP-hana-angi-scaleout-perfopt-15.txt b/adoc/Var_SLES4SAP-hana-angi-scaleout-perfopt-15.txt index 7d03e366f..0d76be07d 100644 --- a/adoc/Var_SLES4SAP-hana-angi-scaleout-perfopt-15.txt +++ b/adoc/Var_SLES4SAP-hana-angi-scaleout-perfopt-15.txt @@ -215,7 +215,7 @@ :docCostOpt: Setting up a SAP HANA SR Cost Optimized Infrastructure :docPerfOpt: SAP HANA System Replication Scale-Up - Performance Optimized Scenario :dochaquickstart: Installation and Setup Quick Start -:sapHanaSrMinVers: 0.184 +:sapHanaSrMinVers: 1.2 :haDrCostOptMem: srCostOptMemConfig :haDrCostOptMemPy: {haDrCostOptMem}.py :haDrMultiTargetPy: SAPHanaSrMultiTarget.py