Skip to Content
Technical Articles

Use SLES 15.2 To Automate SAP HANA High Availability

4 years ago, I wrote a blog explaining how to manually setup and configure SLES 12.2 with SAP HANA to run an automated HA solution from performance-optimized to resource optimized “SAP Hana TDI setup – SAP Hana HSR 3 Tiers with SAPHanaSR
As a strategic partner of SAP, in its latest revision “15.2”, now SLES provides a fully integrated process to accelerate the deployment of SAP HANA in a highly available environment. Awesome right!!!

In this first article of a series of four, I will talk to you about how SLES HA Automation process and integration work with SAP HANA to facilitate the management of these systems, but also how to get the best of this marriage by leveraging enhanced native SLES tools specifically for SAP platform.

 

Some references

Before starting, it is important to make sure that you have the right information in regard to the technology, tools, and components used to achieve and realize some of the scenarios that I will cover. Here is a collection of guides, references, and SAP Notes to be reviewed.

SAP Notes

  • 2235581 – SAP HANA: Supported Operating Systems
  • 2684254 – SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Application 15
  • 1999880 – FAQ: SAP HANA System Replication
  • 2407186 – How-To Guides & Whitepapers for SAP HANA High Availability

Guides

  • SUSE Linux Enterprise Server for SAP Applications 15 SP2
  • SAP Hana Administration Guide 2.0 SP5
  • SAP HANA System Replication
  • FreeNAS® 11.3-U5 User Guide

 

What and how to articulate it?

I know you want to go straight to the config part of the solution 😉, but I have to be diligent with you and at least show some updates from the components used in my previous blog since those updates/upgrades are the essences for the rest of the documentation.

VMware Platform

vSphere 6.0 to 6.7 – vSphere 6.7 contains major improvements which provide such as 2x better performance, 3x reduction in memory usage as well as 3x faster operation relating to VDRS.

FreeNAS Platform

FreeNAS 9.0 to 11.3-U5 – Not just a virtual appliance, the latest version of FreeNAS offer the ability to add virtual machines, Docker, and cloud synchronization support, it includes a mobile-friendly Angular web interface, improved iocage plugin system, real-time APIv2, and synchronization with many more cloud storage providers.

Now that I have talked about the 2 main pieces, let’s dive into SLES For SAP 15 SP2, as I mentioned earlier this revision of SLES provides an embedded mechanism to set up and configure SAP HANA to run in HA mode with auto-failover (scale-up).
I will not cover how to install SLES for SAP step by step neither how to install SAP HANA, but will cover the detail to realize the setup.

Operating System Core Install

By design, SLES 15.2 media gives you the ability to install your OS according to a specific product in order to install the necessary extension and module

The Basesystem Module and Server Application Module are selected de facto, make sure to select SAP Application Module which will auto-select the SLES HA Extension

Your System Role is an important point; however, you can choose only one role.

A very important point, that people don’t think about often, is the NTP server. You need to make sure to sync your server time.

 

Get your system ready for HA

Because the environment needs to be configured as a cluster, to guaranty the consistency of the following an SBD device needs to be attached on both server parts of the cluster.

This is where I use FreeNAS to create and share an iSCSI bloc to be attached

Now in order to leverage the SLES feature for SAP HANA, specifics package needs to be deployed since they don’t come natively in the core install if you don’t explicitly select them. The yast2-sap-ha for the cluster setup, and the yast2-hana-update to maintain your SAP system within the cluster.

 

Ready to run the procedure

My DNS is updated with the virtual ip and hostname given for my cluster

Both SAP Hana is installed according to the recommendation, my primary system is backed up
On my primary Hana I have created a key for backup

The PKI SSF data and file has been copied from the primary to the secondary node

  • scp -p /usr/sap/HB0/SYS/global/security/rsecssfs/data/SSFS_HB0.DAT hb0adm@hanadb03:/usr/sap/HB0/SYS/global/security/rsecssfs/data/
  • scp -p /usr/sap/HB0/SYS/global/security/rsecssfs/key/SSFS_HB0.KEY hb0adm@hanadb03:/usr/sap/HB0/SYS/global/security/rsecssfs/key/

Now from the primary, as root, I invoke “yast2” and select “HA Setup for SAP Products”

Select the “Scale UP: Performance-optimized”

On the communication layer, provide the ip range from the nic card to be used.

Edit both server ips and hostname and also make sure to select “Append to /etc/hosts”, because of the root key exchange between server, the password will be asked

The NTP server configured earlier should appear

It the following screen, I need to add the SBD device attached to the server

How to check the iSCSI? run the command “fdisk -l”

For the Watchdog, I will choose “softdog”

In this last step, I provide the system information such, SID, instance number, VIP, the site name and the behavior for taking over and auto registration

Review the config and hit Install

During the process, some package will be required to be installed

One completed a review of the log to make sure no error encored and click finish

Validate the cluster and SAP HANA replication, to do so I will open the HAWK interface but using the virtual hostname of my cluster on port 7630

At the OS level if I run the “crm status” the status of the resources will show green

Finally, I will register my cluster in my Hana Cockpit

I can see that my hanadb02 node the primary used as per the Cockpit

 

Test the failover

I now test the failover process by killing the hb0adm process on the hanadb02 (node1) and check the takeover on Hana Cockpit and the OS level (because HAWK is only deployed on node1)
I my primary node (hanadb02) I run my killer command 😉 “pkill -9 HB0”

 

On the logical order, after the pkill command is invoked, I run the “crm status” command and I can see that hanadb02 resources are stopped

On the Hana Cockpit, I can see that the replication is broken on Site1

After a few second the takeover is completed and we can see the hanadb03 acting as the master now

And finally, the Hana Cockpit shows the hanadb03 as well the master after refreshing without changing anything

 

Conclusion

The new embedded process provided by SLES is very good to automate build and task for SAP HANA, very straight forward and efficient if you are not a Linux savvy person to deal with multiple file manipulation and OS command.
In the next portion of this of articles, I will talk about the maintenance part of this process for SAP HANA, Cost Optimized configuration (QA/PRD), and the Chained setup (3 tiers).

Series

Part 1: Current
Part 2: Use SLES 15.2 To Automate SAP HANA HA Maintenance

7 Comments
You must be Logged on to comment or reply to a post.
  • If you are not separating the iscsi device on a separate physical channel. the whole setup doesnt make sense. Separating the fencing device channel is very important for your high availability cluster. Having sbd  as the fencing device  especially for HANA instances (Since they mostly will not be carrying a FC card) only to complete the architecture you are looking for is a bad idea.

    • Hello Phani,

      Thanks for your input, if you pay attention to my current setup i used only one channel to simplify the process only.

      I talk about the feature provided by SLES and about the component to be used, the focus was not the design here 😉

      As you know the SLES HA support FC or Iscsi SAN, so your comment is valid from network segregation point of view.

      However, i appreciate all the comment as long as they can help others in their reflection.

      Thank you.

      • Iam just pointing out the issue. After seeing the same blunders being done in production setups.  Cloud providers are suggesting to use this mechanism without understanding the repercussions of the same.

        I have at least 3-4 customers who have used this approach of using the iscsi devices on the same channel as data for the fencing devices. Whenever i have discussions with them on the reason for using the iscsi devices as fencing devices, they point me to Cloud Provider Documents / such blogs .