Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
gorbenkoteh
Active Participant

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


The scenario for SLES:






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/


Links:


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








Conclusion.


One of the many possible approaches to HA is described.

Labels in this area