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!
Showing results for 
Search instead for 
Did you mean: 

As SAP customers around the world prepare for the arrival of S/4HANA to their enterprises, one element common to many of their current system infrastructures that had been so fretted about, painstakingly researched, carefully implemented, frequently tested and dutifully maintained is now subject to lots of new scrutiny. That element is high availability.

Arguably, over the past three years, SAP HANA technology has been allowed into many enterprises without satisfying this need.  After all, for most early adopters the first HANA deployments have been accompanied by a “let’s see what this baby can do” mentality.  If it worked and produced a useful result, great.  If it didn’t, well, we’ll put the technology back in the oven and check on it in a year or two.  No great harm done.

But now that expectations are high and key SAP business applications will morph over time to S/4HANA, the notion of resilient, highly-available, failover-capable and disaster-ready systems no longer constitutes a set of nice-to-have features.  Rather, they are guarded gates that IT systems must pass through on their way to supplanting today’s installed solutions.  Since many currently-deployed R/3 infrastructures count on established “HA/DR” (e.g. Oracle Solaris Cluster, HP Serviceguard, IBM Tivoli or Symantec Veritas), it’s no surprise that SAP’s customer base will have high expectations for HA/DR for their S/4HANA deployments.  Virtually no one will accept any less capability in this regard than they possess today; indeed many will demand quite a lot more. 

The research firm Forrester reports that an hour of downtime for a critical business application will likely result in financial losses stemming from employee productivity losses, customer flight (to competitors), and direct revenue losses in the form of orders that will not be made up once the service is back online.  Depending on the nature, size and scope of the business, these losses can range from nuisance level to pretty damaging. Bottom line: avoid this experience as much as is practical, given your particular cost constraints.

SUSE has traditionally offered High Availability Extensions to SUSE Linux Enterprise as a for-fee option, but for SAP environments, SUSE includes these extensions as part of the bundle called SUSE Linux Enterprise Server for SAP Applications.  The SUSE Linux Enterprise HA Extensions include six standard HA/DR methods:

  • Simple Stack
  • Enqueue Replication
  • DRBD Data Synchronization
  • SAN-based Mirror
  • SAP & NFS in one cluster
  • HA in virtual environments

This range of topologies ensures one that will work for virtually every enterprise.  For smaller outfits with some ability to tolerate unplanned downtime, perhaps an active/passive (a.k.a. “cost optimized”) arrangement will suffice, and maybe the database redundancy could be entrusted to a hosting provider.  For more demanding environments, active/active setups utilizing Geo-clustering might be the way to go, despite the higher associated costs.

SUSE continues to work closely with SAP to set the de facto standard for SAP HANA high availability methods. The many in-service deployments now taking advantage of HANA System Replication technology indeed benefit from SUSE leadership and our extensive collaboration with SAP in this space.  There are a variety of posts on this site and on the SUSE site detailing what’s available along with valuable “how-to” info.  Refer to Fabian Herschel’s in-depth article here on SCN:

…and to the summary titled “Automate your SAP HANA System Replication Failover” on the SUSE site.

And more enhancements are coming.  Take live-patching in SLES 12, for example. It may well represent the holy grail of application uptime – software updates that can help improve performance, tighten up security and even system resilience, without requiring even a brief planned downtime for a system restart. 

Labels in this area