A WISE MAN once said “the true test of a great software product is what it does when nobody is watching”; enter SAP’s Always-On HADR. SAP is breathing new life into its HADR solution via much anticipated mods to Adaptive Server Enterprise and Replication Server. I recently performed some real world testing of Always-On.
The recent introduction of SAP’s Always-On HADR solution, (licensed) feature of Adaptive Server Enterprise, will have former Sybase clients thinking, “why did we ever toss Sybase in favor of brand X?” After all, Wall Street was built upon on the speed and reliability of Sybase software. No other product came close to its dataserver, replication server, and client/server ground-breaking technology.
ASE and Replication Servers still play an integral part in our data services, especially with regard to speed, data integrity, and heterogeneous capability. I’ve been working with these two products for over 20 years from Replication Server 11.0.2 (when I used to pull my hair out) to the most recent 15.7.1 SP305. Now, in the post-Sybase era, the ASE/RS tag team has been given a fresh tank of oxygen and continues to thrive in the marketplace.
Through the introduction of practical, user-desired features incorporated by SAP, Always-On HADR continues to be a cost-effective, reliable, robust solution for many clients planning or upgrading an OLTP, HA, or DR environment.SAP ASE Always-On HADR option Dobler Consulting has performed extensive evaluation and testing on the SAP Always-On HADR feature.
SAP ASE Always-On HADR Option
Dobler Consulting has performed extensive evaluation and testing on the SAP Always-On HADR feature. We have written a detailed technical paper with our findings so that you can gain a better understanding of the feature and how it works.
In the paper, you’ll learn about all the various testing we carried out and the results they yielded. Our team of experts has worked diligently to put together all of the technical details needed to enable you to implement the HADR feature.
We want you to know what’s in our paper before you download it. Here is a high-level summary of what it contains. You can download the SAP ASE Always-On White Paper.
Please note: The information contained in the technical document pertains only to the High Availability configuration, operation, and administration of SAP’s Always-On HADR feature.
Overview of SAP ASE Always-On Feature
Think of the Always-On feature as a high-availability and disaster recovery (HADR) solution that, currently, consists of two SAP ASE servers, two SAP Replication Servers (RS), two SAP Host Agents, and a Fault Manager (FM) to monitor and control component failure switching.
Two SAP ASE Servers and Replication Servers
- Primary ASE Server – The primary server is where all transaction processing takes place.
- Companion ASE Server – The primary server has a companion server (referred to as a “standby server” in DR mode, and as a “companion” in HA mode), and contains copies of designated databases from the primary server.
- Primary RS – The primary RS operates from the companion host site.
- Companion RS – The companion RS remains up, available, and unused until replication between the primary and companion sites is switched.
Two SAP Host Agents
- One Host Agent runs on the primary site host and another at the companion site host. These agents facilitate inter-host communication for multiple components.
One SAP Fault Manager
- The FM is installed and runs from a host machine completely separate from the primary and companion components. Its function is to monitor components availability and invoke a switch of the primary and companion sites.
The RS Process
- The system takes user specified data and replicates it through an RS from the primary server to the companion server.
- If the Fault Manager (FM) detects that a primary server has failed, a companion server is promoted to the role of
- The system takes user specified data and replicates it through an RS from the primary server to the companion server. • If the Fault Manager (FM) detects that a primary server has failed, a companion server is promoted to the role of primary server either manually or automatically.
- Once the promotion is complete, clients can reconnect to the new primary server and see all committed data including data that was committed on the previous primary server.
- The environment uses cluster configurations. Cluster configurations normally imply shared resources; however, there are no shared resources here. Each node maintains its own resources and shares nothing.
The HA option is made possible through the use of synchronous replication.
Zero Data Loss is even possible?
The answer is, YES. I recently downloaded, installed, and conducted a series of comprehensive tests to help me understand Always-On. You may think, “synchronous replication; no way, my users will be sitting around waiting for the keyboard to unlock!.” However, you may be surprised. Through the use of a robust network combined with fast disk devices synchronous replication works well and it guarantees zero data loss (ZDL).
In a properly configured HA environment, users will not experience a degradation of throughput.
The tested Always-On bundle consisted of the following products:
|SAP Adaptive Server Enterprise (ASE)||(re-energized and still lightening fast)|
|SAP Replication Server (RS)||(new commands/functionality, enhanced automation)|
|SAP Host Agent||(os/database monitoring, instance provisioning)|
|Replication Management Agent (RMA)||(…more than your father’s Replication Server Manager)|
|SAP ASE Cockpit||(…more than your father’s Sybase Central) (not discussed in this document)|
|Fault Manager (FM)||(…more than your father’s OpenSwitch)|
The basis for the design is a cluster configuration. The cluster we configured for our testing consisted of two sites:
- Site1 (Primary) – In the normal configuration, site1 ran the primary ASE and a standby RS.
- Site2 (Companion) – In the normal configuration, site2 ran the companion ASE and primary RS.
The process flow was from the primary ASE (site1) to the primary RS (site2) then into the companion ASE (site2). We did not use the RS (site1) in this scenario. Upon automatic or manual failover, replication changed direction to flow from the new primary ASE (site2) to the new primary RS (site1), then into the new ASE companion (site1). The RS (site2) was not used in this scenario.
Here is a good depiction of the architecture courtesy of SAP’s “HADR Users Guide – Administration Guide – SAP ASE 16.0 SP02 – December 20, 2016”
The normal path is in green and the failover flow in dotted red.
The installation is a straight forward 3-step process.
- Install the worksheet template – Fill out the worksheet and feed it into the setup executable. In our test, we created a copy of the template to use. We entered all of the details properly; however, setup still invoked the GUI for answers to some details already specified in the template.
- Install the companion template – At the end of the first install, all of the products had been configured for the primary site and were up and running. The output of this install created a companion template which should be reviewed then fed, once again, into setup to create and configure the companion side of HA.
- Install Fault Manager template – After completion of steps 1 and 2, the final install is for the Fault Manager which also comes with a supplied template for use. Remember, the purpose of the FM is to monitor the servers and conduct failover in the event of a component failure so, be sure to install the FM on a third host or a host that does not run any primary or companion HA components.
Based on initial testing, it seems as though SAP put some manpower behing the QA of this product. The performance was a nice added bonus because it eliminated our team from having to do a lot of QA on our end, like we’ve experienced in the past.
For the most part, I can say that everything worked as advertised and most of the problems encountered were caused by being unfamiliar with new command syntax and the use of these commands. Failover, manual and automatic, was swift and clean.
For my minimal testing environment, component failover completed in 5-7 seconds. The FM, working in conjunction with the Host Agent and RMA, successfully detected primary ASE failures and performed failover/failback as it should. I am hoping, however, that a future release of the FM, which is basically a reworked OpenSwitch (HA product marketed by Sybase in the past), supports some sort of a “Coordination Module” interface to allow clients to introduce their own criteria and tasks to be performed during pre and post failover.
The AO software version described in this document was ASE 16.0 SP02 PL05 HF1. The RS software within this bundle was at 15.7.1 SP305.
Selected content for this document has been obtained from the “HADR Users Guide – Administration Guide – SAP ASE 16.0 SP02 – December 20, 2016”.
ALWAYS-ON. The product is aptly named and will not disappoint.
ALWAYS-ON is not your father’s SAP Replication Server HADR solution!