SAP DR on Azure – Introduction

Abstract

This document would like to be a simple guide to give DR on Azure of a SAP environment. Due to the nature and importance of the workload described, this guide is intended as a high level reference that must be integrated with more specific documentation if interested in realize SAP DR solution on Azure.

---

Navigation Pane

This guide is splitted in several parts, to give readers ability to navigate an choose what’s more interested in:

---

Why a Disaster Recovery for SAP

SAP workload are usually mission critical systems that provide core business functions to the companies. Having a business continuity plan is a key factor to ensure that the business will continue to run as expected still during a disaster event. When planning for a Disaster Recovery solution, companies must define and establish a recovery time objective (RTO) and a recovery point objective (RPO) for every single point of failure in the SAP application Stack.

RTO is the acceptable amount of time in which SAP application data must be restored while RPO is the acceptable amount of data loss measured in time.

Not implementing a D/R solution for mission critical systems exposes the customer to unexpected events that could cause huge lost in terms of business continuity. There are some studies that report that 1 hour downtime may cause between 100.000 to 1M$ lost for the company.

With the Cloud advent, there are now many great opportunities to implement an effective disaster recovery solution that allows to satisfy the required RTO and RPO leveraging the new Cloud capacitlities and flexibility.

Microsoft Azure is the “to go” platform for SAP workload and allows to implement many D/R scenarios like On-premises to Azure or Azure to Azure.

---

Points to consider

In realizing a DR solution for SAP workload some points must to be considered in order to design a good solution. Some of them are:

• The components to put in DR:
  • x DB Server SAP HANA
  • x Application Server SAP
  • x Application Server SAP ASCS
  • x Application Server SAP Router / Web Dispatcher
• If those components should be normally offline and startable on demand or always running[1]
• If the DR activation must be performed starting from an HANA backup or from continuous sync[2]
• The desired RPO and RTO
• If a Test environment should be provided to do regular (i.e. quarterly DR Tests)
• The formalization of a Recovery Plan describing all operations to be performed in case of DR activation

[1] Depends on the RTO desired: sometimes Customer wants systems in DR up and ready to start immediately.

[2] Depends on the RPO desired: Closer RPO needs something different, e.g. continuous DB Replica.

---

Typical on-prem SAP Environment

The following picture depicts a typical SAP environment installed on Customer DataCenter:

The components of a SAP environment similar to this are:

• DB Servers SAP HANA, generally based on Linux
  • Normally there are two HANA servers configured in synchronous replication
    • 1 HANA Srv configured as primary;
    • 1 HANA Srv configured as secondary
• At least 1 SAP Application Server ASCS, based on Linux or Windows Server;
• At least 1 SAP Router / Web Dispatcher, based on Linux or Windows Server;
• A number of SAP Application Servers, based on Linux or Windows Server
  • The number depends on the number of clients using the system.

As pointed in the picture, sometimes ASCS and Web Dispatcher are deployed as single box, while sometimes the role are putted in a kind of crossed active/passive cluster with two nodes in this way:

• Node 1: Active ASCS Role, Passive Web Dispatcher Role;
• Node 2: Active Web Dispatcher Role, Passive ASCS Role.

The typical HW configuration of the servers in a SAP environment are similar to the following:

• HANA Server
  • xx CPU depending on the load of system. Is common to find HANA with 50 or 128 CPUs;
  • xxx GB RAM depending on the DB size;
  • xx GB OS disk (xx GB OS + xx GB Swap);
• at least 4 data volumes
  • SAP_Shared volume xxx GB;
  • HANA_Data volume xx TB;
  • HANA_Log volume xxx GB;
  • sap Volume xxx GB.

As noted, the HANA servers are typically High-End machines and is common to have it as physical machines.

Other servers are generally virtualized and the HW configuration of VMs could be something similar to the following:

• Application Servers
  • 16 vcpu
  • 32 GB Ram
  • 3 volumes
    • OS – xx GB
    • SWAP – xx GB
    • Data – xx GB
• ASCS / Web Dispatcher
  • 16 vcpu
  • 32 GB Ram
  • 3 volumes
    • OS – xx GB
    • SWAP – xx GB
    • Data – xx GB

---

So, now lets describe the possible solutions identified to address Customer needs:

SAP DR on Azure Part 2 – Possible Solution # 1

SAP DR on Azure Part 3 – Possible Solution # 2

---