SAP HANA System Replication Scale-Up - Cost Optimized Scenario #

With the SAPHanaSR resource agent software package, we limit the support to scale-up (single-box to single-box) system replication with the following configurations and parameters:

The SUSE Linux Enterprise Server for SAP Applications versions are:

For the HA/DR provider hook scripts SAPHanaSR.py and susCostOpt.py, the following requirements apply:

Additional considerations for the SAP HANA version are:

Important

Without a valid STONITH method, the complete cluster is unsupported and will not work properly.

If you need to implement a different scenario, we strongly recommend to define a Proof of Concept (PoC) with SUSE. This PoC will focus on testing the existing solution in your scenario. Most of the above mentioned limitations are set because careful testing is needed.

For information on supported hardware and virtualization, refer to the SUSE release notes and hardware compatibility database:

Also, take a look at the SAP HANA product availability matrix, which can for example be found at https://support.sap.com/en/release-upgrade-maintenance.html#section_1969201630.

Additional information for deploying the cost optimized scenario in particular public clouds is available either from the respective cloud provider or from SUSE at https://documentation.suse.com/sbp/sap/.

This document describes how to set up the cluster to control SAP HANA in System Replication scenarios. The document focuses on the steps to integrate an already installed and working SAP HANA with System Replication. In this document SUSE Linux Enterprise Server for SAP Applications 15 SP3 is used. This concept can also be used with SUSE Linux Enterprise Server for SAP Applications 15 SP2 or newer.

The described example setup builds an SAP HANA HA cluster in two data centers in Walldorf (WDF) and in Rot (ROT), installed on two SLES for SAP 15 SP3 systems. In addition, a non-replicated SAP HANA is installed and added to the cluster control.

Figure 8: Cluster with SAP HANA SR - cost optimized #

 

You can either set up the cluster using the YaST wizard, doing it manually or using your own automation.

If you prefer to use the YaST wizard, you can use the shortcut yast sap_ha to start the module. The procedure to set up SAPHanaSR using YaST is described in the product documentation of SUSE Linux Enterprise Server for SAP Applications in section Setting Up an SAP HANA Cluster at https://documentation.suse.com/sles-sap/15-SP3/html/SLES-SAP-guide/cha-cluster.html.

Figure 9: Scenario Selection for SAP HANA in the YaST Module sap_ha #

 

This guide focuses on the manual setup of the cluster to explain the details and to give you the possibility to create your own automation.

The seven main setup steps are:

Planning the installation is essential for a successful SAP HANA cluster setup.

Before you start, you need the following:

4.1 Minimum lab requirements and prerequisites #

 

Note

The minimum lab requirements mentioned here are by no means SAP sizing information. These data are provided only to rebuild the described cluster in a lab for test purposes. The following minimum setup uses the half-size of RAM for the secondary SAP HANA database which has table preload inactive. Even for tests the requirements can increase, depending on your test scenario. For productive systems ask your hardware vendor or use the official SAP sizing tools and services.

Note

Refer to SAP HANA TDI documentation for allowed storage configuration and file systems.

Requirements with 1 SAP system replication instance per site (1 : 1) - without a majority maker (2 node cluster):

• 1 VM with 32GB RAM, 50 GB disk space for the system

• 1 VM with 48GB RAM, 50 GB disk space for the system

• 1 shared disk for SBD with 10 MB disk space

• 2 data disks (one per site) with a capacity of each 96 GB for SAP HANA

• 1 data disk (for the non-replicated database) with a capacity of 96 GB for SAP HANA

• 1 additional IP address for takeover

• 1 additional IP address for non-replicated database

• 1 optional IP address for HAWK Administration GUI

Requirements with 1 SAP system replication instance per site (1 : 1) - with a majority maker (3 node cluster):

• 1 VM with 32 GB RAM, 50 GB disk space for the system

• 1 VM with 48 GB RAM, 50 GB disk space for the system

• 1 VM with 2 GB RAM, 50 GB disk space for the system

• 2 data disks (one per site) with a capacity of each 96 GB for SAP HANA

• 1 data disk (for the non-replicated database) with a capacity of 96 GB for SAP HANA

• 1 additional IP address for takeover

• 1 additional IP address for non-replicated database

• 1 optional IP address for HAWK Administration GUI

This section contains information you should consider during the installation of the operating system.

For the scope of this document, first SUSE Linux Enterprise Server for SAP Applications is installed and configured. Then the SAP HANA database including the system replication is set up. Finally the automation with the cluster is set up and configured.

Even though this document focuses on the integration of an installed SAP HANA with system replication already set up into the Linux cluster, this chapter summarizes the test environment. Always use the official documentation from SAP to install SAP HANA and to set up the system replication.

This guide shows SAP HANA and saphostagent with native systemd integration. An example for legacy SystemV is outlined in the appendix Section 13.5, “Example for checking legacy SystemV integration”.

# systemctl list-unit-files | grep sap
saphostagent.service enabled
sapinit.service generated
saprouter.service disabled
saptune.service enabled

# systemctl list-unit-files | grep SAP
SAPHA1_10.service enabled

# systemd-cgls -u SAP.slice
Unit SAP.slice (/SAP.slice):
├─saphostagent.service
│ ├─2630 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile -systemd
│ ├─2671 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
│ └─3591 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile
└─SAPHA1_10.service
  ├─ 1257 hdbcompileserver
  ├─ 1274 hdbpreprocessor
  ├─ 1353 hdbindexserver -port 31003
  ├─ 1356 hdbxsengine -port 31007
  ├─ 2077 hdbwebdispatcher
  ├─ 2300 hdbrsutil --start --port 31003 --volume 3 --volumesuffix mnt00001/hdb00003.00003 --identifier 1644426276
  ├─28462 /usr/sap/HA1/HDB10/exe/sapstartsrv pf=/usr/sap/HA1/SYS/profile/HA1_HDB10_suse01
  ├─31314 sapstart pf=/usr/sap/HA1/SYS/profile/HA1_HDB10_suse01
  ├─31372 /usr/sap/HA1/HDB10/suse01/trace/hdb.sapHA1_HDB10 -d -nw -f /usr/sap/HA1/HDB10/suse01/daemon.ini pf=/usr/sap/HA1/SYS/profile/HA1_HDB10_suse01
  ├─31479 hdbnameserver
  └─32201 hdbrsutil --start --port 31001 --volume 1 --volumesuffix mnt00001/hdb00001 --identifier 1644426203

suse02:~ # su - qasadm
qasadm@suse02:/usr/sap/QAS/HDB20> cdcoc
qasadm@suse02:/usr/sap/QAS/SYS/global/hdb/custom/config> grep -A1 memorymanager \
 global.ini
[memorymanager]
global_allocation_limit = <size_in_mb_for_non_replicated_hana>

# systemctl list-unit-files | grep SAP
SAPHA1_10.service enabled
SAPQAS_20.service enabled

# systemd-cgls -u SAP.slice
Unit SAP.slice (/SAP.slice):
├─saphostagent.service
│ ├─2630 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile -systemd
│ ├─2671 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
│ └─3591 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile
└─SAPHA1_10.service
  ├─ 1257 hdbcompileserver
  ├─ 1274 hdbpreprocessor
  ├─ 1353 hdbindexserver -port 32003
  ├─ 1356 hdbxsengine -port 32007
  ├─ 2077 hdbwebdispatcher
  ├─ 2300 hdbrsutil --start --port 32003 --volume 3 --volumesuffix mnt00001/hdb00003.00003 --identifier 1644426276
  ├─28462 /usr/sap/HA1/HDB10/exe/sapstartsrv pf=/usr/sap/QAS/SYS/profile/QAS_HDB20_suse02
  ├─31314 sapstart pf=/usr/sap/HA1/SYS/profile/QAS_HDB20_suse02
  ├─31372 /usr/sap/QAS/HDB20/suse02/trace/hdb.sapQAS_HDB20 -d -nw -f /usr/sap/QAS/HDB20/suse02/daemon.ini pf=/usr/sap/QAS/SYS/profile/QAS_HDB20_suse02
  ├─31479 hdbnameserver
  └─32201 hdbrsutil --start --port 32001 --volume 1 --volumesuffix mnt00001/hdb00001 --identifier 1644426203

For more information read the section Setting Up System Replication of the SAP HANA Administration Guide.

Procedure

7.1 Backing up the primary database #

 

Back up the primary database as described in the SAP HANA Administration Guide, section SAP HANA Database Backup and Recovery. We provide an example with SQL commands. You need to adapt these backup commands to match your backup infrastructure.

Example 4: Simple backup for the system database and all tenants with one single backup call #

 

As user <sid>adm enter the following command:

~> hdbsql -i 10 -u SYSTEM -d SYSTEMDB \
   "BACKUP DATA FOR FULL SYSTEM USING FILE ('backup')"

You will get a command output similar to the following:

0 rows affected (overall time 7255.049 msec; server time 7253.369 msec)

Example 5: Simple backup for a single container (non MDC) database #

 

Enter the following command as user <sid>adm:

~> hdbsql -i <instanceNumber> -u <dbuser> \
   "BACKUP DATA USING FILE ('backup')"

Important

Without a valid backup, you cannot bring SAP HANA into a system replication configuration.

7.2 Enabling the primary node #

 

As Linux user <sid>adm, enable the system replication at the primary node. You need to define a site name (like WDF). This site name must be unique for all SAP HANA databases which are connected via system replication. This means the secondary must have a different site name. The site names must not be changed later when the cluster has been activated.

Note

Do not use strings like "primary" and "secondary" as site names.

Example 6: Enable the Primary #

 

Enable the primary using the -sr_enable option.

ha1adm@suse01:/usr/sap/HA1/HDB10> hdbnsutil -sr_enable --name=WDF
nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.

Example 7: Check SR Configuration on the Primary #

 

Check the primary using the command hdbnsutil -sr_stateConfiguration.

ha1adm@suse01:/usr/sap/HA1/HDB10> hdbnsutil -sr_stateConfiguration --sapcontrol=1
SAPCONTROL-OK: <begin>
mode=primary
site id=1
site name=WDF
SAPCONTROL-OK: <end>
done.

The mode has changed from “none” to “primary”. The site now has a site name and a site ID.

ha1adm@suse02:/usr/sap/HA1/HDB10> HDB stop

~> cd /usr/sap/<SID>/SYS/global/security/rsecssfs
~> rsync -va {<node1-site A>:,}$PWD/data/SSFS_<SID>.DAT
~> rsync -va {<node1-site A>:,}$PWD/key/SSFS_<SID>.KEY

...
ha1adm@suse02:/usr/sap/HA1/HDB10> hdbnsutil -sr_register --name=ROT \
     --remoteHost=suse01 --remoteInstance=10 \
     --replicationMode=sync --operationMode=logreplay
adding site ...
nameserver suse02:30001 not responding.
collecting information ...
updating local ini files ...
done.

[memorymanager]
global_allocation_limit = <size_in_mb_for_secondary_hana>

[system_replication]
preload_column_tables = false

ha1adm@suse02:/usr/sap/HA1/HDB10> HDB start
...
ha1adm@suse02:/usr/sap/HA1/HDB10> hdbnsutil -sr_stateConfiguration \
     --sapcontrol=1
SAPCONTROL-OK: <begin>
mode=sync
site id=2
site name=ROT
active primary site=1
primary masters=suse01
SAPCONTROL-OK: <end>
done.

ha1adm@suse01:/usr/sap/HA1/HDB10> HDBSettings.sh systemReplicationStatus.py \
     --sapcontrol=1
...
site/2/SITE_NAME=ROT
site/2/SOURCE_SITE_ID=1
site/2/REPLICATION_MODE=SYNC
site/2/REPLICATION_STATUS=ACTIVE
overall_replication_status=ACTIVE
site/1/REPLICATION_MODE=PRIMARY
site/1/SITE_NAME=WDF
local_site_id=1
...

This step is mandatory to inform the cluster immediately if the secondary gets out of sync. The hook is called by SAP HANA using the HA/DR provider interface in point-of-time when the secondary gets out of sync. This is typically the case when the first commit pending is released. The hook is called by SAP HANA again when the system replication is back. This HA/DR provider method is srConnectionChanged(), the related SUSE hook script is SAPHanaSR.py. The hook script SAPHanaSR.py is defacto madatory.

Another hook is called by SAP HANA after an SR takeover has happened. This method can be used to remove the SAP HANA memory limit and enable table preload. This HA/DR provider method is postTakeover(), the related SUSE hook script is susCostOpt.py.

Optionally, a third hook is called by SAP HANA when a service status changes. This method can be used to speed up the takeover in case the indexserver process fails. This HA/DR provider method is srServiceStateChanged(), the related SUSE hook script is susChkSrv.py. For installation details, refer to manual page susChkSrv.py(7).

Procedure

This will implement two SAP HANA HA/DR provider hook scripts. The hook script SAPHanaSR.py needs no config parameters. The configuration for susCostOpt.py needs to be adapted to your specific system size and user keystore.

Note

All hook scripts should be used directly from the SAPHanaSR package. If the scripts are moved or copied, regular SUSE package updates will not work.

SAP HANA must be stopped to change the global.ini and allow SAP HANA to integrate the HA/DR hook scripts during start. Alternatively, SAPHanaSR-manageProvider might be used for adapting the global.ini. See manual page SAPHanaSR-manageProvider(8) for details.

~> sapcontrol -nr <instanceNumber> -function StopSystem

[ha_dr_provider_saphanasr]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/
execution_order = 1

[trace]
ha_dr_saphanasr = info

ha1adm@suse02:/usr/sap/HA1/HDB10> sapcontrol -nr <instanceNumber> -function StopSystem

[memorymanager]
global_allocation_limit = <size_in_mb_for_secondary_hana>

[system_replication]
preload_column_tables = false
...

[ha_dr_provider_suscostopt]
provider = susCostOpt
path = /usr/share/SAPHanaSR/
userkey = sus_<SID>_costopt
execution_order = 2

[trace]
ha_dr_suscostopt = info
...

[system_replication]
operation_mode = logreplay

# SAPHanaSR-ScaleUp entries for writing srHook cluster attribute
<sid>adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_*

# SAPHanaSR-ScaleUp entries for writing srHook cluster attribute
Cmnd_Alias SOK_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
Cmnd_Alias SFAIL_SITEA  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias SOK_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
Cmnd_Alias SFAIL_SITEB  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
<sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB

8.5 Create a database user key in <sid>adm´s keystore #

 

The user keystore needs to be created for the <sid>adm of the replicating database. The keystore needs to be created on node 2, where the replication secondary database is running. In this example we use the SAP HANA database user SYSTEM for changing the values for memory limit and column pre-load.

Example 21: Creating a database user key #

 

The example port and password need to be adapted.

# su - <sid>adm
~> hdbuserstore SET sus_<SID>_costopt localhost:31013 SYSTEM SuSE1234
~> hdbuserstore LIST sus_<SID>_costopt

Important

For security reasons on production systems always a dedicated database user with restricted permission needs to be created. The database user SYSTEM must never be used.

Refer to SAP HANA documentation for further information on database users, permissions and the user keystore.

~> sapcontrol -nr <instanceNumber> -function StartSystem

<sid>adm@suse02:/usr/sap/<SID>/HDB<instanceNumber>> cdtrace
<sid>adm@suse02:/usr/sap/<SID>/HDB<instanceNumber>> grep HADR.*load.*SAPHanaS nameserver_*.3*.trc

# grep "sudo.*crm_attribute.*srHook" /var/log/messages

<sid>adm@suse02:/usr/sap/<SID>/HDB<instanceNumber>> cdtrace
<sid>adm@suse02:/usr/sap/<SID>/HDB<instanceNumber>> grep HADR.*load.*susCostOpt nameserver_*.trc
<sid>adm@suse02:/usr/sap/<SID>/HDB<instanceNumber>> grep susCostOpt.init nameserver_*.3*.trc

This chapter describes the configuration of the cluster software SUSE Linux Enterprise High Availability Extension, which is part of SUSE Linux Enterprise Server for SAP Applications, and the SAP HANA database integration.

9.1 Configuring the basic cluster #

 

The first step is to set up the basic cluster framework. For convenience, use YaST or the ha-cluster-init script. It is strongly recommended to add a second corosync ring, change it to UCAST communication and adjust the timeout values to fit your environment.

9.1.1 Setting up watchdog for "Storage-Based Fencing" #

 

If you use the storage-based fencing (SBD) mechanism (diskless or disk-based), you must also configure a watchdog. The watchdog is needed to reset a node if the system cannot longer access the SBD (diskless or disk-based). It is mandatory to configure the Linux system for loading a watchdog driver. It is strongly recommended to use a watchdog with hardware assistance (as is available on most modern systems), such as hpwdt, iTCO_wdt, or others. As fallback, you can use the softdog module.

Example 22: Setup for Watchdog #

 

Important

Access to the watchdog timer: No other software must access the watchdog timer; it can only be accessed by one process at any time. Some hardware vendors ship systems management software that use the watchdog for system resets (for example HP ASR daemon). Such software must be disabled if the watchdog is to be used by SBD.

Determine the right watchdog module. Alternatively, you can find a list of installed drivers with your kernel version.

# ls -l /lib/modules/$(uname -r)/kernel/drivers/watchdog

Check if any watchdog module is already loaded.

# lsmod | egrep "(wd|dog|i6|iT|ibm)"

If you get a result, the system has already a loaded watchdog. If the watchdog does not match your watchdog device, you need to unload the module.

To safely unload the module, check first if an application is using the watchdog device.

# lsof /dev/watchdog
# rmmod <wrong_module>

Enable your watchdog module and make it persistent. For the example below, softdog has been used. However, softdog has some restrictions and should not be used as first option.

# echo softdog > /etc/modules-load.d/watchdog.conf
# systemctl restart systemd-modules-load

Check if the watchdog module is loaded correctly.

# lsmod | grep dog
# ls -l /dev/watchdog

Testing the watchdog can be done with a simple action. Ensure to switch of your SAP HANA first because the watchdog will force an unclean reset or shutdown of your system.

In case a hardware watchdog is used, a desired action is predefined after the timeout 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 commands will force your system to be reset/switched off.

In case the softdog module is used, the following action can be performed:

# sync; cat /dev/watchdog & while date; do sleep 10; done

After your test was successful, you must implement the watchdog on all cluster members.

9.1.2 Setting up the initial cluster using ha-cluster-init #

 

For more detailed information about setting up a cluster, refer to the sections Setting Up the First Node and Adding the Second Node of the Installation and Setup Quick Start for SUSE Linux Enterprise High Availability Extension 15 SP3 at https://documentation.suse.com/sle-ha/15-SP3/single-html/SLE-HA-install-quick/index.html.

This setup uses unicast (UCAST) for corosync communication (-u option). Refer to the https://documentation.suse.com/sle-ha/15-SP3/single-html/SLE-HA-guide/ on detailed explanations of the terms unicast/multicast.

Create an initial setup, using the ha-cluster-init command, and follow the dialogs. Do this only on the first cluster node. Answer "no" to "Do you wish to configure a virtual IP address" and "Do you want to configure QDevice".

To use two corosync rings make sure you have two interfaces configured and run:

suse01:~ # ha-cluster-init -u -M -s /dev/disk/by-id/SBDA -s /dev/disk/by-id/SBDB

To use only one corosync ring leave out the -M option (not recommended):

suse01:~ # ha-cluster-init -u -s /dev/disk/by-id/SBDA -s /dev/disk/by-id/SBDB

This command configures the basic cluster framework including:

• SSH keys

• csync2 to transfer configuration files

• SBD (at least one device, in this guide two)

• corosync (at least one ring, better two rings)

• HAWK Web interface

Important

As requested by ha-cluster-init, change the password of the user hacluster.

9.1.3 Checking and adapting the corosync and SBD configuration #

 

9.1.3.1 Checking the corosync configuration #

 

Check the following blocks in the file /etc/corosync/corosync.conf. The important parts are udpu and the correct ring/IP configuration.

See also the example at the end of this document and refer to the manual pages corosync.conf(5), votequorum(5) and corosync_overview(8) for details on parameters and features.

totem {
    ...

    interface {
        ringnumber: 0
        mcastport: 5405
        ttl: 1
    }

    interface {
        ringnumber: 1
        mcastport: 5407
        ttl: 1
    }

    rrp_mode: passive
    transport: udpu

    ...

}

    ...

nodelist {
    node {
            ring0_addr: 192.168.1.11
            ring1_addr: 192.168.2.11
            nodeid: 1
    }

    node {
            ring0_addr: 192.168.1.12
            ring1_addr: 192.168.2.12
            nodeid: 2
    }
}
    ...

9.1.3.2 Adapting the SBD configuration #

 

You can skip this section if you do not have any SBD devices, but be sure to implement another supported fencing mechanism.

See the manual pages sbd(8) and stonith_sbd(7) for details.

Table 3: SBD Options in File /etc/sysconfig/SBD #

 

Parameter	Description
SBD_WATCHDOG_DEV	Define the watchdog device. It is mandatory to use a watchdog. SBD does not work reliable without watchdog. Refer to the SLES manual and SUSE TIDs 7016880 for setting up a watchdog.
SBD_WATCHDOG_TIMEOUT	This parameter is used with diskless SBD. It defines the timeout, in seconds, the watchdog will wait before panicking the node if noone tickles it. If you set CIB parameter stonith-watchdog-timeout to a negative value, Pacemaker will automatically calculate this timeout and set it to twice the value of SBD_WATCHDOG_TIMEOUT starting with SUSE Linux Enterprise High Availability Extension 15.
SBD_STARTMODE	Start mode. If set to "clean", sbd will only start if the node was previously shut down cleanly or if the slot is empty.
SBD_PACEMAKER	Check Pacemaker quorum and node health.

# egrep -v "(^#|^$)"/etc/sysconfig/sbd
SBD_PACEMAKER="yes"
SBD_STARTMODE="clean"
SBD_DELAY_START="no"
SBD_WATCHDOG_DEV="/dev/watchdog"
SBD_WATCHDOG_TIMEOUT="5"
SBD_TIMEOUT_ACTION="flush,reboot"
SBD_MOVE_TO_ROOT_CGROUP="auto"
SBD_OPTS=""
SBD_DEVICE="/dev/disk/by-id/SBDA;/dev/disk/by-id/SBDB"

On your specific system, the file might have additional parameters not discussed here.

9.1.3.3 Verifying the SBD device #

 

You can skip this section if you do not have any SBD devices, but make sure to implement a supported fencing mechanism.

It is a good practice to check if the SBD device can be accessed from both nodes and does contain valid records. Check this for all devices configured in /etc/sysconfig/sbd. You can do so, for example, by calling cs_show_sbd_devices.

suse01:~ # sbd -d /dev/disk/by-id/SBDA -d /dev/disk/by-id/SBDB dump
==Dumping header on disk /dev/disk/by-id/SBDA
Header version     : 2.1
UUID               : 1fdc54e8-e2f0-4f02-9e6a-51acbe5656cf
Number of slots    : 255
Sector size        : 512
Timeout (watchdog) : 20
Timeout (allocate) : 2
Timeout (loop)     : 1
Timeout (msgwait)  : 40
==Header on disk /dev/disk/by-id/SBDA is dumped
==Dumping header on disk /dev/disk/by-id/SBDB
Header version     : 2.1
UUID               : 23c423df-575d-4937-a48b-5eb869fe0bb7
Number of slots    : 255
Sector size        : 512
Timeout (watchdog) : 20
Timeout (allocate) : 2
Timeout (loop)     : 1
Timeout (msgwait)  : 40
==Header on disk /dev/disk/by-id/SBDB is dumped

Important

The timeout values in our example are only start values. It is a requirement that they are tuned to your environment. Refer to the TIDs 7011346 and 7023689 for more information.

To check the current SBD entries for the various cluster nodes, you can use sbd list. If all entries are clear, no fencing task is marked in the SBD device.

suse01:~ # sbd -d /dev/disk/by-id/SBDA -d /dev/disk/by-id/SBDB list
0     suse01      clear
0     suse01      clear

For more information on SBD configuration parameters, read the section Using SBD as Fencing Mechanism of the Installation and Setup Quick Start for SUSE Linux Enterprise High Availability Extension 15, and the TIDs 7016880 and 7008216.

9.1.4 Configuring the cluster on the second node #

 

The second node of the two nodes cluster can be integrated by starting the command ha-cluster-join. This command asks for the IP address or name of the first cluster node. With this command, all needed configuration files are copied over. As a result, the cluster is started on both nodes.

# ha-cluster-join -c <host1>

Press RETURN to acknowledge the IP address.

9.1.5 Checking the cluster for the first time #

 

Now it is time to check and optionally start the cluster for the first time on both nodes.

suse01:~ # systemctl status pacemaker
suse01:~ # systemctl status sbd
suse02:~ # systemctl status pacemaker
suse02:~ # systemctl status sbd
suse01:~ # crm cluster start
suse02:~ # crm cluster start

Check the cluster status. First, check if all nodes have used the SBD devices. To check the current SBD entries for the various cluster nodes, you can use sbd list. If all entries are clear , no fencing task is marked in the SBD device.

suse01:~ # sbd -d /dev/disk/by-id/SBDA -d /dev/disk/by-id/SBDB list
0     suse01      clear
1     suse02      clear
0     suse01      clear
1     suse02      clear

You can also call cs_show_sbd_devices again.

Next, check if all nodes have joined the cluster. To do so, call crm_mon. Use the options "-r1" to also see the resources that are configured but stopped.

# crm_mon -r1

The command will show the "empty" cluster and will print something similar to the screen output below. The most interesting pieces of information for now are that there are two nodes in the status "online", the message "partition with quorum", and a running SBD resource.

Cluster Summary:
  * Stack: corosync
  * Current DC: suse01 (version 2.0.5+20201202.ba59be712-150300.4.16.1-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Thu Jun 10 08:32:58 2022
  * Last change:  Thu Jun 10 08:29:41 2022 by hacluster via crmd on suse01
  * 2 nodes configured
  * 1 resource instance configured

Node List:
  * Online: [ suse01 suse02  ]

Full List of Resources:
  * stonith-sbd	(stonith:external/sbd):	 Started suse01

suse01:~ # vi crm-fileXX
suse01:~ # crm configure load update crm-fileXX

suse01:~ # vi crm-bs.txt
# enter the following to crm-bs.txt
property cib-bootstrap-options: \
    have-watchdog="true" \
	stonith-enabled="true" \
    stonith-action="reboot" \
    stonith-timeout="150s"
rsc_defaults rsc-options: \
    resource-stickiness="1000" \
    migration-threshold="3"
op_defaults op-options: \
    timeout=600 \
    record-pending=true

suse01:~ # crm configure load update crm-bs.txt

# vi crm-saphanatop.txt
# enter the following to crm-saphanatop.txt
primitive rsc_SAPHanaTopology_HA1_HDB10 ocf:suse:SAPHanaTopology \
    op monitor interval="10" timeout="600" \
    op start interval="0" timeout="600" \
    op stop interval="0" timeout="300" \
    params SID="HA1" InstanceNumber="10"
clone cln_SAPHanaTop_HA1_HDB10 rsc_SAPHanaTop_HA1_HDB10 \
    meta clone-node-max="1" interleave="true"

suse01:~ # crm configure load update crm-saphanatop.txt

# vi crm-saphana.txt
# enter the following to crm-saphana.txt
primitive rsc_SAPHana_HA1_HDB10 ocf:suse:SAPHana \
    op start interval="0" timeout="3600" \
    op stop interval="0" timeout="3600" \
    op promote interval="0" timeout="3600" \
    op monitor interval="60" role="Master" timeout="700" \
    op monitor interval="61" role="Slave" timeout="700" \
    params SID="HA1" InstanceNumber="10" PREFER_SITE_TAKEOVER="false" \
        DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
    meta priority="100"
ms msl_SAPHana_HA1_HDB10 rsc_SAPHana_HA1_HDB10 \
    meta clone-max="2" clone-node-max="1" interleave="true"

suse01:~ # crm configure load update crm-saphana.txt

# vi crm-vip.txt
# enter the following to crm-vip.txt

primitive rsc_ip_HA1_HDB10 ocf:heartbeat:IPaddr2 \
    op monitor interval="10s" timeout="20s" \
    params ip="192.168.1.20"

suse01:~ # crm configure load update crm-vip.txt

# vi crm-cs.txt
# enter the following to crm-cs.txt
colocation col_saphana_ip_HA1_HDB10 3000: rsc_ip_HA1_HDB10:Started \
    msl_SAPHana_HA1_HDB10:Master
order ord_SAPHana_HA1_HDB10 Optional: cln_SAPHanaTop_HA1_HDB10 \
    msl_SAPHana_HA1_HDB10

suse01:~ # crm configure load update crm-cs.txt

# vi crm-si.txt
# enter the following to crm-si.txt
primitive rsc_SAP_QAS_HDB20 ocf:heartbeat:SAPInstance \
  params InstanceName="QAS_HDB20_suse02" \
        MONITOR_SERVICES="hdbindexserver|hdbnameserver" \
        START_PROFILE="/usr/sap/QAS/SYS/profile/QAS_HDB20_suse02" \
  op start interval="0" timeout="600" \
  op monitor interval="120" timeout="700" \
  op stop interval="0" timeout="300"

suse01:~ # crm configure load update crm-si.txt

# vi crm-con.txt
# enter the following to crm-con.txt
location loc_QAS_never_on_suse01 rsc_SAP_QAS_HDB20 -inf: suse01
colocation col_QAS_never_with_HA1ip -inf: rsc_SAP_QAS_HDB20:Started \
  rsc_ip_HA1_HDB10
order ord_QASstop_before_HA1-promote mandatory: rsc_SAP_QAS_HDB20:stop \
  msl_SAPHana_HA1_HDB10:promote

suse01:~ # crm configure load update crm-con.txt

The lists of tests will be further enhanced in one of the next updates of this document.

For any cluster setup testing is crucial. Make sure that all test cases derived from your organizations or from customer expectations are fully implemented and successfully passed. Otherwise the project is likely to fail in production.

If not described differently, the test prerequisite is always that both nodes are booted, normal members of the cluster and that the HANA RDBMS is running. There are no left-over migration constraints or resource failures contained in the cluster information base (CIB). The system replication is in sync (SOK) and the cluster is not performing any action, this means it is in the state S_IDLE.

This can be checked, for example, with the following command sequence:

# crm_mon -1r
# crm configure show | grep cli-
# SAPHanaSR-showAttr
# cs_clusterstate -i

See also the manual pages SAPHanaSR-showAttr(8), crm_mon(8), crm(8), cs_clusterstate(8), SAPHanaSR_maintenance_examples(7).

10.1 Test cases for semi-automation #

 

For the following test descriptions we assume these following parameter values: * PREFER_SITE_TAKEOVER="false" * AUTOMATED_REGISTER="false".

Note

The following tests are designed to run in a sequence. Each test depends on the exit state of the preceding tests.

10.1.1 Tests for primary database or node #

 

10.1.1.1 Test: Stop primary database on site A (node 1) #

 

Example 23: Test STOP_PRIMARY_DB_SITE_A_SEMI #

 

Component: #

 

• Primary Database

Description: #

 

• Stop Primary on site A (node 1)

Test Procedure: #

 

1. Stop the SAP HANA database as user <sid>adm

   suse01:~ # su - ha1adm
   ha1adm@suse01:/usr/sap/HA1/HDB10> HDB stop

Expected: #

 

• Primary restarts on site A (PREFER_SITE_TAKEOVER=false) until failcount >= migration-threshold

• If takeover occurs:

  • non-replicated database is stopped on node 2 (site B)

  • Secondary database is promoted as primary

Recovery Procedure: #

 

• No recovery needed, if no takeover did occur

• Recovery after takeover:

  1. Register site A to site B

  2. Resource cleanup for site A

10.1.1.2 Test: Stop primary database on site B (node 2) #

 

Example 24: Test STOP_PRIMARY_DB_SITE_B_SEMI #

 

Component: #

 

• Primary Database

Description: #

 

• Stop Primary on site B (node 2)

Test Procedure: #

 

1. Stop the SAP HANA database as user <sid>adm

   ha1adm@suse02:/usr/sap/HA1/HDB10> HDB stop

Expected: #

 

• Primary restarts on site B (PREFER_SITE_TAKEOVER=false) until failcount >= migration-threshold

• Non-replicated database still stopped on node 2 (site B)

• If takeover occurs:

  • Secondary database is promoted as primary

  • non-replicated database is started on node 2 (site B)

Recovery Procedure: #

 

• No recovery needed if no takeover did occur

• Recovery after takeover:

  1. Register site B to site A

  2. Resource cleanup for site B

10.1.1.3 Test: Crash primary database on site A (node 1) #

 

Example 25: Test CRASH_PRIMARY_DB_SITE_A_SEMI #

 

Component: #

 

• Primary Database

Description: #

 

• Kill Primary on site A (node 1)

Test Procedure: #

 

1. Kill (send signal to) the SAP HANA database as user <sid>adm

   ha1adm@suse01:/usr/sap/HA1/HDB10> HDB kill-9

Expected: #

 

• Primary restarts on site A (PREFER_SITE_TAKEOVER=false) until failcount >= migration-threshold

• If takeover occurs:

  • Non-replicated database is stopped on node 2 (site B)

  • Secondary database is promoted as primary

Recovery Procedure: #

 

• No recovery needed if no takeover did occur

• Recovery after takeover:

  1. Register site A to site B

  2. Resource cleanup for site A

10.1.1.4 Test: Crash primary database on site B (node 2) #

 

Example 26: Test CRASH_PRIMARY_DB_SITE_B_SEMI #

 

Component: #

 

• Primary Database

Description: #

 

• Kill Primary on site B (node 2)

Test Procedure: #

 

1. Kill Primary on site B (node 2) as user <sid>adm

   ha1adm@suse02:/usr/sap/HA1/HDB10> HDB kill-9

Expected: #

 

• Primary restarts on site B (PREFER_SITE_TAKEOVER=false) until failcount >= migration-threshold

• Non-replicated database still stopped on node 2 (site B)

Recovery Procedure: #

 

• No recovery needed if no takeover did occur

• Recovery after takeover:

  1. Register site B to site A

  2. Resource cleanup for site B

10.1.1.5 Test: Crash primary node on site A (node 1) #

 

Example 27: Test CRASH_PRIMARY_NODE_SITE_A_SEMI #

 

Component: #

 

• Cluster Node

Description: #

 

• Crash node 1 (site A)

Test Procedure: #

 

1. Crash the node by proc-sysrq-trigger as user root

   suse01:~ # sync; echo b > /proc/sysrq-trigger

Expected: #

 

• Non-replicated SAP HANA stopped on node 2

• Cluster takeover to site B

• Non-replicated database is stopped on node 2 (site B)

• Secondary database is promoted as primary

Recovery Procedure: #

 

• Recovery after takeover:

  1. Optionally clean up sbd slot for node 1

  2. Register site A to site B

  3. Start cluster framework on node 1

  4. Wait until node 1 joins the cluster

10.1.1.6 Test: Crash primary node on site B (node 2) #

 

Example 28: Test CRASH_PRIMARY_NODE_SITE_B_SEMI #

 

Component: #

 

• Cluster Node

Description: #

 

• Crash node 2 (site B)

Test Procedure: #

 

1. Crash the node by proc-sysrq-trigger as user root

   suse02:~ # sync; echo b > /proc/sysrq-trigger

Expected: #

 

• Cluster takeover to site A

• Non-replicated database not available (no takeover to site A)

Recovery Procedure: #

 

• Recovery after takeover:

  1. Optionally clean up sbd slot for node 2

  2. Register site B to site A

  3. Start cluster framework on node 2

  4. Wait until node 2 joins the cluster

10.1.2 Tests for secondary database or node #

 

10.1.2.1 Test: Stop the secondary database on site B (node 2) #

 

Example 29: Test STOP_SECONDARY_DB_SITE_B_SEMI #

 

Component: #

 

• Secondary Database

Description: #

 

• Stop secondary database on node 2 (site B)

Test Procedure: #

 

1. Stop the secondary SAP HANA database as user <sid>adm

   ha1adm@suse02:/usr/sap/HA1/HDB10> HDB stop

Expected: #

 

• Cluster restarts Secondary on node 2 (site B)

• non-replicated database not affected on node 2 (site B)

Recovery Procedure: #

 

1. Wait and see

2. Resource cleanup for site B

10.1.2.2 Test: Crash the secondary database on site B (node 2) #

 

Example 30: Test CRASH_SECONDARY_DB_SITE_B_SEMI #

 

Component: #

 

• Secondary Database

Description: #

 

• Crash secondary database on node 2 (site B)

Test Procedure: #

 

1. Kill (send signal to) the secondary SAP HANA database as user <sid>adm

   ha1adm@suse02:/usr/sap/HA1/HDB10> HDB kill-9

Expected: #

 

• Cluster restarts Secondary on node 2 (site B)

• Non-replicated database not affected on node 2 (site B)

Recovery Procedure: #

 

1. Wait and see

2. Resource cleanup for site B

10.1.2.3 Test: Crash the secondary node on site B (node2) #

 

Example 31: Test CRASH_SECONDARY_NODE_SITE_B_SEMI #

 

Component: #

 

• Cluster Node

Description: #

 

• Crash node 2 (site B)

Test Procedure: #

 

1. Crash the node by proc-sysrq-trigger as user root

   suse02:~ # sync; echo b > /proc/sysrq-trigger

Expected: #

 

• No takeover of node 2 resources to site A

• Non-replicated database not available (no takeover to site A)

Recovery Procedure: #

 

• Recovery after node 2 is back:

  1. Optionally clean up sbd slot for node 2

  2. Start cluster framework on node 2

  3. Wait until node 2 joins the cluster

10.1.3 Tests for non-replicated database #

 

10.1.3.1 Test: Stop non-replicated database on site B (node 2) #

 

Example 32: Test STOP_NONSR_DB_SITE_B_SEMI #

 

Component: #

 

• Non-Replicated Database

Description: #

 

• Stop non-replicated database node 2 (site B)

Test Procedure: #

 

1. Kill (send signal to) the non-replicated SAP HANA database as user <sid>adm

   qasadm@suse02:/usr/sap/QAS/HDB20> HDB stop

Expected: #

 

• Cluster restarts non-replicated database on node 2 (site B)

• Secondary database is not affected

Recovery Procedure: #

 

1. Clean up non-replicated database resource

10.1.3.2 Test: Crash non-replicated database on site B (node 2) #

 

Example 33: Test CRASH_NONSR_DB_SITE_B_SEMI #

 

Component: #

 

• Non-Replicated Database

Description: #

 

• Crash non-replicated database on node 2 (site B)

Test Procedure: #

 

1. Kill (send signal to) the non-replicated SAP HANA database as user <sid>adm

   qasadm@suse02:/usr/sap/QAS/HDB20> HDB kill-9

Expected: #

 

• Cluster restarts non-replicated database on node 2 (site B)

• Secondary database is not affected

Recovery Procedure: #

 

1. Clean up non-replicated database resource

10.1.4 Tests for other components #

 

10.1.4.1 Test: Failure of dedicated replication LAN #

 

Example 34: Test FAIL_NETWORK_SR_SEMI #

 

Component: #

 

• Replication Network

Description: #

 

• Pull LAN port down or block network packets for system replication. Corosync network still available.

Expected: #

 

• System replication status fall down to status SFAIL

• Primary stays on node 1 (site A)

• No cluster takeover

• Non-replicated database not affected on node 2 (site B)

Recovery Procedure: #

 

1. Re-establish network connection

2. Wait until System replication status is SOK again

10.1.5 Test maintenance procedures #

 

Also test the maintenance procedures mentioned in section Section 11.3, “Maintenance”.

10.2 Test cases for full automation #

 

For the following test descriptions, we assume the following parameter values: * PREFER_SITE_TAKEOVER="false" * AUTOMATED_REGISTER="true".

Note

The following tests are designed to run in a sequence. Each test depends on the exit state of the preceding tests.

10.2.1 Tests for primary database or node #

 

10.2.1.1 Test: Stop primary database on site A (node 1) #

 

Example 35: Test STOP_PRIMARY_DB_SITE_A_FULL #

 

Component: #

 

• Primary Database

Description: #

 

• Stop primary database on site A (node 1)

Test Procedure: #

 

1. Stop the SAP HANA database as user <sid>adm

   ha1adm@suse01:/usr/sap/HA1/HDB10>  HDB stop

Expected: #

 

• Primary restarts on site A (PREFER_SITE_TAKEOVER=false) until failcount >= migration-threshold

• If takeover occurs:

  • Non-replicated database is stopped on node 2 (site B)

  • Secondary database is promoted as primary

  • SiteA is automatically registered to SiteB

Recovery Procedure: #

 

• No recovery needed, if no takeover did occur

• Recovery after takeover:

  1. Resource cleanup for site A

10.2.1.2 Test: Stop primary database on site B (node 2) #

 

Example 36: Test STOP_PRIMARY_DB_SITE_B_FULL #

 

Component: #

 

• Primary Database

Description: #

 

• Stop primary database on site B (node 2)

Test Procedure: #

 

1. Stop the SAP HANA database as user <sid>adm

   ha1adm@suse02:/usr/sap/HA1/HDB10>  HDB stop

Expected: #

 

• Primary restarts on site B (PREFER_SITE_TAKEOVER=false) until failcount >= migration-threshold

• Non-replicated database still stopped on node 2 (site B)

• If takeover occurs:

  • Secondary database is promoted as primary

  • non-replicated database is started on node 2 (site B)

  • SiteB is automatically registered to SiteA

Recovery Procedure: #

 

• No recovery needed if no takeover did occur

• Recovery after takeover:

  1. Resource cleanup for site B

10.2.1.3 Test: Crash primary database on site A (node 1) #

 

Example 37: Test CRASH_PRIMARY_DB_SITE_A_FULL #

 

Component: #

 

• Primary Database

Description: #

 

• Kill primary database on site A (node 1)

Test Procedure: #

 

1. Kill (send signal to) the SAP HANA database as user <sid>adm

   ha1adm@suse01:/usr/sap/HA1/HDB10>  HDB kill-9

Expected: #

 

• Primary restarts on site A (PREFER_SITE_TAKEOVER=false) until failcount >= migration-threshold

• If takeover occurs:

  • Non-replicated database is stopped on node 2 (site B)

  • Secondary database is promoted as primary

  • SiteA is registered to SiteB

Recovery Procedure: #

 

• No recovery needed if no takeover did occur

• Recovery after takeover:

  1. Resource cleanup for site A

10.2.1.4 Test: Crash primary database on site B (node 2) #

 

Example 38: Test CRASH_PRIMARY_DB_SITE_B_FULL #

 

Component: #

 

• Primary Database

Description: #

 

• Kill primary database on site B (node 2)

Test Procedure: #

 

1. Kill primary database on site B (node 2) as user <sid>adm

   ha1adm@suse02:/usr/sap/HA1/HDB10>  HDB kill-9

Expected: #

 

• Primary restarts on site B (PREFER_SITE_TAKEOVER=false) until failcount >= migration-threshold

• Non-replicated database still stopped on node 2 (site B)

• If takeover occurs:

  • Secondary database is promoted as primary

  • Non-replicated database is started on node 2 (site B)

  • SiteB is automatically registered to SiteA

Recovery Procedure: #

 

• No recovery needed if no takeover did occur

• Recovery after takeover:

  1. Resource cleanup for site B

10.2.1.5 Test: Crash primary node on site A (node 1) #

 

Example 39: Test CRASH_PRIMARY_NODE_SITE_A_FULL #

 

Component: #

 

• Cluster Node

Description: #

 

• Crash node 1 (site A)

Test Procedure: #

 

1. Crash the node by proc-sysrq-trigger as user root

   suse01:~ # sync; echo b > /proc/sysrq-trigger

Expected: #

 

• Non-replicated SAP HANA stopped on node 2

• Cluster takeover to site B

• Non-replicated database is stopped on node 2 (site B)

• Secondary database is promoted as primary

• Later, when node 1 joins the cluster again:

  • SiteA is registered to SiteB

Recovery Procedure: #

 

• Recovery after takeover:

  1. Optionally clean up sbd slot for node 1

  2. Start cluster framework on node 1

  3. Wait until node 1 joins the cluster

10.2.1.6 Test: Crash primary node on site B (node 2) #

 

Example 40: Test CRASH_PRIMARY_NODE_SITE_B_FULL #

 

Component: #

 

• Cluster Node

Description: #

 

• Crash node 2 (site B) as user root

Test Procedure: #

 

1. Crash the node by proc-sysrq-trigger

   suse02:~ # sync; echo b > /proc/sysrq-trigger

Expected: #

 

• Cluster takeover to site A

• Non-replicated database not available (no takeover to site A)

• Later, when node 2 joins the cluster again:

  • SiteB is registered to SiteA

  • Non-replicated database will be started

Recovery Procedure: #

 

• Recovery after takeover:

  1. Optionally clean up sbd slot for node 2

  2. Start cluster framework on node 2

  3. Wait until node 2 joins the cluster

10.2.2 Tests for secondary database or node #

 

10.2.2.1 Test: Stop the secondary database on site B (node 2) #

 

Example 41: Test STOP_SECONDARY_DB_SITE_B_FULL #

 

Component: #

 

• Secondary Database

Description: #

 

• Stop secondary database on node 2 (site B)

Test Procedure: #

 

1. Stop the secondary SAP HANA database as user <sid>adm

   ha1adm@suse02:/usr/sap/HA1/HDB10> HDB stop

Expected: #

 

• Cluster restarts Secondary on node 2 (site B)

• Non-replicated database not affected on node 2 (site B)

Recovery Procedure: #

 

1. Wait and see

2. Resource cleanup for site B

10.2.2.2 Test: Crash the secondary database on site B (node 2) #

 

Example 42: Test CRASH_SECONDARY_DB_SITE_B_FULL #

 

Component: #

 

• Secondary Database

Description: #

 

• Crash secondary database on node 2 (site B)

Test Procedure: #

 

1. Kill (send signal to) the secondary SAP HANA database as user <sid>adm

   ha1adm@suse02:/usr/sap/HA1/HDB10> HDB kill-9

Expected: #

 

• Cluster restarts Secondary on node 2 (site B)

• Non-replicated database not affected on node 2 (site B)

Recovery Procedure: #

 

1. Wait and see

2. Resource cleanup for site B

10.2.2.3 Test: Crash the secondary node on Site B (node 2) #

 

Example 43: Test CRASH_SECONDARY_NODE_SITE_B_FULL #

 

Component: #

 

• Cluster Node

Description: #

 

• Crash node 2 (site B)

Test Procedure: #

 

1. Crash the node by proc-sysrq-trigger as user root

   suse02:~ # sync; echo b > /proc/sysrq-trigger

Expected: #

 

• No takeover of node 2 resources to site A

• Non-replicated database not available (no takeover to site A)

Recovery Procedure: #

 

• Recovery after node 2 is back:

  1. Optionally clean up sbd slot for node 2

  2. Start cluster framework on node 2

  3. Wait until node 2 joins the cluster

10.2.3 Tests for non-replicated database #

 

10.2.3.1 Test: Stop non-replicated database on site B (node 2) #

 

Example 44: Test STOP_NONSR_DB_SITE_B_FULL #

 

Component: #

 

• Non-Replicated Database

Description: #

 

• Stop non-replicated database node 2 (site B)

Test Procedure: #

 

1. Kill (send signal to) the non-replicated SAP HANA database as user <sid>adm

   qasadm@suse02:/usr/sap/QAS/HDB20> HDB stop

Expected: #

 

• Cluster restarts non-replicated database on node 2 (site B)

• Secondary database is not affected

Recovery Procedure: #

 

1. Clean up non-replicated database resource

10.2.3.2 Test: Crash non-replicated database on site B (node 2) #

 

Example 45: Test CRASH_NONSR_DB_SITE_B_FULL #

 

Component: #

 

• Non-Replicated Database

Description: #

 

• Crash non-replicated database on node 2 (site B)

Test Procedure: #

 

1. Kill (send signal to) the non-replicated SAP HANA database as user <sid>adm

   qasadm@suse02:/usr/sap/QAS/HDB20> HDB kill-9

Expected: #

 

• Cluster restarts non-replicated database on node 2 (site B)

• Secondary database is not affected

Recovery Procedure: #

 

1. Clean up non-replicated database resource

10.2.4 Tests for other components #

 

10.2.4.1 Test: Failure of dedicated replication LAN #

 

Example 46: Test FAIL_NETWORK_SR_FULL #

 

Component: #

 

• Replication Network

Description: #

 

• Pull LAN port down or block network packets for system replication, Corosync network still available.

Expected: #

 

• System replication status fall down to status SFAIL

• Primary stays on node 1 (site A)

• No cluster takeover

• Non-replicated database not affected on node 2 (site B)

Recovery Procedure: #

 

1. Re-establish network connection

2. Wait until system replication status is SOK again

10.2.5 Test maintenance procedures #

 

Also, test the maintenance procedures mentioned in section Section 11.3, “Maintenance”.

For more detailed information, have a look at the documents listed below.

Copyright © 2006–2024 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled "GNU Free Documentation License".

SUSE, the SUSE logo and YaST are registered trademarks of SUSE LLC in the United States and other countries. For SUSE trademarks, see https://www.suse.com/company/legal/.

Linux is a registered trademark of Linus Torvalds. All other names or trademarks mentioned in this document may be trademarks or registered trademarks of their respective owners.

Documents published as part of the SUSE Best Practices series have been contributed voluntarily by SUSE employees and third parties. They are meant to serve as examples of how particular actions can be performed. They have been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. SUSE cannot verify that actions described in these documents do what is claimed or whether actions described have unintended consequences. SUSE LLC, its affiliates, the authors, and the translators may not be held liable for possible errors or the consequences thereof.

Below we draw your attention to the license under which the articles are published.

Copyright © 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties—​for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

Copyright (c) YEAR YOUR NAME.
   Permission is granted to copy, distribute and/or modify this document
   under the terms of the GNU Free Documentation License, Version 1.2
   or any later version published by the Free Software Foundation;
   with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
   A copy of the license is included in the section entitled “GNU
   Free Documentation License”.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “ with…​Texts.” line with this:

with the Invariant Sections being LIST THEIR TITLES, with the
   Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.