Adaptive Server Enterprise (ASE) HADR – Extended Edition

Some days ago the colleagues from the Alibaba Cloud team in the SAP LinuxLab approached us and ask if we would like to participate in a project together with the SAP ASE team and the Alibaba cloud team. The goal was to show an ASE HADR concept between Alibaba Cloud and an on-premise data center. Quite quickly, the idea was born to extend the setup with the implementation of the SAP central services and application server.

The setup was clear and the presentation was done at DSAG 2020. After this we created a best practice guide for the HA part of this setup.

The picture below illustrate one possible setup.

This new guide will help you to setup a SAP NetWeaver 7.50 system with the HA implementation for the central services, ASCS and ERS. On top of this we have described the methods how you could implement the ASE Fault Manager (FM) in our cluster setup. This means the Fault Manager must run outside of the database nodes but is not high available itself. By placing them in the existing cluster for ASCS & ERS we could take care of this service as well, without requiring an additional server.

Let me explain it a bit more in detail:

The Fault Manager can run in two different ways. Once as additional service together with the ASCS or as independent SAP instance.

The first option is illustrated below. It was already proofed but the second option is new and not yet documented as an example. We worked together with the SAP ASE team and Alibaba Cloud team to make this happen.

With the second option the Fault Manager (FM) is separate from the ASCS. The FM is a standalone instance shown below.

What is the benefit for the second option for ASE?

If you are already familiar with the ASCS / ERS pacemaker solution you may could imaging what are the key facts here.

When FM is running as independent instance and independent cluster resource there is no dependency between the ASCS and the FM (as there is with option 1). If something happens to the ASCS or ERS, the resources must move from one host to another, but the FM could continue running without change. If you have to do some database maintenance you could set the FM cluster resource to maintenance mode separately without any impacting the ASCS / ERS resources.

With the first option the FM is also affected, if the ASCS must be restarted or moved to a different node due to a failure. Vice versa, an issue with the FM instance has an impact on the ASCS instance as well. If you want to stop your FM service you have to set the ASCS resource in maintenance mode to avoid a cluster reaction.

Regarding the SAP enqueue replication version there are no restrictions. You can use this regardless if you plan to use ENSA1 or ENSA2. You could also decide to plan three nodes in the cluster, or run multiple SAP systems in one cluster. We have documented some examples and rules here:

https://documentation.suse.com/sbp/all → SAP S/4HANA and SAP NetWeaver Multi-SID Cluster Guide

BTW: Our HA setup for NetWeaver was proofed again and we got certified for NW-HA-CLU_750.

Summary

This example shows again how flexible our Pacemaker solutions can be to help making life easier. This solution delivers a very high database protection and – in conjunction with our ASCS / ERS cluster – simplifies the whole infrastructure setup.

This and many more documentation is available at https://documentation.suse.com/sbp/all

A big thank you to the teams of Alibaba Cloud, SAP ASE team and SUSE to make this happen.