High Availability on Physical layer
Physical layer basically beyond the BASIS regular tasks but we need to consider this topic at least briefly
Some examples of High Availability on the physical layer
SAP HANA DB PHYSICAL SERVER with two convergent network cards, each network card have two physical ports (for example Ethernet and Fiber)
(POF – Network card failure, Cable failure)
Preparing for a potential Point of Failure (POF): Fault-tolerant network infrastructure
Switch 0 and Switch 1
(POF – Switch failure)
Preparing for a potential Point of Failure (POF): Fault-tolerant network infrastructure
Data Storage
(POF – Disk(s) failure)
Preparing for a potential Point of Failure (POF): Fault-tolerant disk storage
High Availability on SAP Application layer
Consider typical configuration SAP configuration for High Availability
PAS – AAS – ASCS – ERS – SAP HANA DB (Primary) – SAP HANA DB (Secondary)
Step 1:
Preparing for a potential Point of Failure (POF): AAS/PAS failure
Preparation:
1. Create SAP Logon group
2. Preparation from frontend side
Step 1.1. Create SAP Logon group
Transaction – SMLG
On this example Instances 33, 34 – PAS/AAS binding in Logon Group
“Common_group”
Instance 33 – Available (status green)
Instance 34 – Unavailable but SAP system is available for connecting users
Entry point – Message Server
Transaction – SMMS
Troubleshooting
Problems that may occur at this step:
Error: service ‘sapmsSID’ unknown on Front-End
Add new entry to file
C:\Windows\System32\drivers\etc\services
on Front-End side (SAP Logon / MS Windows OS)
Attention – last string in the file must be empty
Step 1.2. Preparation from frontend side
SAPUILandscape.xml (Configuaration file for SAP Logon 7.5 and Higher):
<Service type=”SAPGUI” uuid=”Any guid” name=”Your name here” systemid=”Your SID here”
server=”Common_group” sncop=”-1″ sapcpg=”1100″ dcpg=”2″ msid=”Any guid”/>
<Messageservers><Messageserver uuid=”Any guid” name=”Your SID” host=”ASCS FQDN”/></Messageservers></Landscape>
Step 2:
Preparing for a potential POF: ASCS/ERS failure
The scenario for RHEL:
Configure SAP S/4HANA ASCS/ERS with Standalone Enqueue Server 2
https://access.redhat.com/articles/3974941
The scenario for SLES:
https://www.suse.com/media/white-paper/sap_netweaver_availability_cluster_740_setup_guide.pdf
High Availability on DB layer
Step 3:
Preparing for a potential POF: SAP HANA DB failure
SAP HANA system replication provides the possibility to copy and continuously synchronize a SAP HANA database to a secondary location in the same or another data center
Prerequisites.
1. SAP HANA DB (Secondary) must have the same system number and SID as SAP HANA DB (Primary)
2. SAP HANA DB (Primary) and SAP HANA DB (Secondary) must have the same version number and the same set of Add-ons
3. SAP HANA Cockpit
4. SAP HANA Studio
5. X11Forwarding for configtool
Step 3.1. Preparation for replication. SSFS keys
Copy system PKI ssfs key and dat file from the primary site to the secondary site.
The files can be found at the following locations:
/usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT
/usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY
We can use rsync utility for this purpose
rsync -arv /usr/sap/<SID>/SYS/global/security/rsecssfs/*
root@secondary_hostname:/usr/sap/<SID>/SYS/global/security/rsecssfs/
2369981 – Required configuration steps for authentication with HANA System Replication
Step 3.2. System replication in Hana Studio
From SystemDB side
Configuration and Monitoring > Configure System Replication -> Enable system replication
Step 3.3. Setting for ABAP and JAVA systems
All ABAP/JAVA systems in Landscape must be known about SAP HANA DB (Primary) and SAP HANA DB (Secondary)
For ABAP systems:
For this purpose log-on as a <sid>adm os-user and add a new a key to hdbuserstore:
hdbuserstore -i Set DEFAULT hostname_primary:3<instance>13; hostname_secondary:3<instance>13@<SID> SAPABAP1 <password for SAPABAP1, usually master password>
log-on as a <sid>adm and check hdbuserstore:
hdbuserstore LIST DEFAULT
For JAVA systems:
Launch configtool
/usr/sap/<SID>/JC##/j2ee/configtool/configtool.sh
## – Instance ID
Secure store
Connection Pools
Url – jdbc:sap//hostname_primary:3<instance>13; hostname_secondary:3<instance>13?databaseName = <SID of Java system>
User: SAPJAVA1
Step 3.4. Takeover in Hana Studio.
SAP HANA DB (Secondary) – SystemDB
Configuration and Monitoring > Configure System Replication > Perform takeover
Shutdown SAP HANA DB (Primary)
N.B. Scenario with two primary instances unacceptable. After takeover ex-primary instance must be shutdown
Step 3.5. Takeover in Hana Cockpit.
SAP HANA DB (Secondary)
System Replication Overview
Take Over
Shutdown SAP HANA DB (Primary)
N.B. Scenario with two primary instances unacceptable. After takeover ex-primary instance must be shutdown
Step 3.5. Replication monitoring from Hana Cockpit and CLI
CLI:
su -<sid>adm
hdbnsutil -sr_state
(Cluster state – at glance)
python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py
(Cluster state – in details)
Hana Cockpit:
From SystemDB side
System Replication Overview
Step 3.6. Some facts about the Secondary System.
Password for SYSTEM/ SAPABAP1 for SYSTEMDB – Master password which was provided during installation.
Password for SYSTEM/ SAPABAP1 for Tenant – Password from a tenant on a primary database.
After replication Secondary system accessible only with <sid>adm user
You can register Secondary system in HANA Cockpit with sidadm OS-user credentials
No comments:
Post a Comment