Azure VM High Availability & Disaster Recovery (part 1)

 


To read part 2 please click here
To read part 3 please click here
To read part 4 please click here

 



High Availability of SAP Workloads

High availability of SAP workloads on azure VMs can be analyzed by two different ways:

High availability of SAP workloads consists of-
  • SAP application servers
  • SAP ASCS/SCS instance
  • DBMS server 

High availability capabilities of Azure infrastructure includes-

  • Azure VM restart capability (significantly important in single-VM scenarios).
  • High availability of compute (VMs), network, and storage, based on availability sets and zones.

Note- As these two context compliments each other, then you should design by combining the benefits of both of them. 

Failover Clustering

A failover cluster is known as a group of independent servers that works together to increase the availability of applications as well as services, and if a node failure occurs, it can perform node arbitration which will transfer the workload to one of the remaining nodes depending on the outcome.

It is a service which offers high availability in Windows Server while also relying on the quorum construct to avoid the split-brain scenarios. The cluster resource manager called Pacemaker facilitates high availability on Linux servers and relies on external STONITH i.e. Shoot The Other Node in the Head component to regulate the node arbitration while also leveraging Corosync to facilitate inter-node communication.

To setup the STONITH component in Azure you can either use a fencing agent or an SBD device. An SBD (storage Based Death) device needs minimum one additional VM that can act as an iSCSI target server and guarantees faster failover time but, if you don't want to deploy additional Azure VMs you can also go for the option of Azure Fence Agent. However, the main disadvantage is that the failover can take up to 10 to 15 minutes if a resource fails or the cluster nodes cannot communicate between themselves.

Deployment Scenarios

Single-SID deployment with two clusters 
  • One dedicated cluster is used for the SAP ASCS/SCS instance.
  • One dedicated cluster is used for the DBMS instance.
  • SAP Application Server instances are deployed in their own dedicated VMs.
Single-SID deployment with a single cluster
  • One dedicated cluster is used for both the SAP ASCS/SCS instance as well as the DBMS.
  • SAP Application Server instances are deployed in own dedicated VMs.

Multi-SID deployment

  • One dedicated cluster is used for both the SAP ASCS/SCS SID1 instance and the SAP ASCS/SCS SID2 instance (one cluster).
  • One dedicated cluster is used for DBMS SID1, another one is used for DBMS SID2 (two clusters).
  • SAP Application Server instances for the SAP system SID1 and SID2 have their own dedicated VMs. 


To read part 2 please click here
To read part 3 please click here
To read part 4 please click here

 






Comments

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

Planning for Implementing SAP Solutions on Azure (Part 2 of 5)

Work with String Data Using KQL Statements