Azure VM High Availability & Disaster Recovery (part 3)

By Ashwin Venugopal -

 


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



Availability Zones

The following should be accounted while considering availability zones:
  • There is no guarantee with respect to the distances between various Availability Zones within an Azure region.
  • Availability Zones are not an ideal DR solution as natural disasters can cause widespread damage in world regions including heavy damage to power infrastructures. 
  • The network latency across Availability Zones is not the same in all Azure regions as in some cases the SAP application layer can be deployed and run across different zones because the network latency from one zone to the active DBMS VM is acceptable.
  • Network latency plays an important role in two areas i.e.-

  1. Latency between the two DBMS instances that need to have synchronous replication. The higher the network latency, the more likely it will affect the scalability of your workload.
  2. As the difference in network latency between a VM running a SAP dialog instance in-zone with the active DBMS instance and similar VM in another zone increases, the influence on the running time of business processes and batch jobs also increases, dependent on whether they run-in zone with the DBMS or in a different zone. 

While making such decisions you should also consider SAP's network latency recommendations. The network latency across Availability Zones in Azure regions can't be generalized.

Deployment Scenarios

Active/Active deployment

It is so called because you can deploy your active SAP application servers across two or three zones and it is also required to find two Availability Zones in your region that can offer cross-zone network latency while considering this configuration that's acceptable for your workload as well as your synchronous DBMS replication. The following considerations apply for this configuration:
  • You treat the Azure Availability Zones as fault and update domains for all the VMs because availability sets can't be deployed in Azure Availability Zones.
  • You should use the Standard SKU Azure Load Balancer for the load balancers of the failover clusters of SAP Central Services and the DBMS layer. 
  • The Azure virtual network that you deployed to host the SAP system, together with its subnets, is stretched across zones. 
  • For all VMs you deploy, you should use Azure Managed Disks as Unmanaged ones are not supported for zonal deployments.
  • Azure Premium Storage and Ultra SSD storage don't support any type of storage replication across zones.
  • At present, the solution that uses Microsoft Scale-Out File Server is not supported across zones.
  • The third zone is used to host the SBD device in case you build a SUSE Linux Pacemaker cluster or additional application instances.
  • You can also try to direct certain batch jobs and users to certain application instances to achieve run-time consistency for critical business processes that are in-zone with the active DBMS instance by using SAP batch server groups, logon groups, or RFC groups.
  • To enable an immediate return to the former resource capacity you can also deploy dormant dialog instances in each of the zones if a zone is used by a part of your application instances is out of service.

Active/Passive deployment

An architecture that has an active/passive character from the SAP application layer point of view can be deployed if you can't find a proper delta between the network latency within one zone and the latency of cross-zone network traffic. The following considerations apply for this configuration:
  • Availability sets can't be deployed in Azure Availability Zones, hence, you will have only one update and fault domain for your application layer as it is deployed in only one zone. 
  • While using this architecture, you should monitor the status closely and try to keep the active DBMS as well as SAP Central Services instances in the same zone as your deployed application layer.
  • It is required to use the standard SKU Azure Load Balancer for the load balancers of the failover clusters of SAP Central Services and the DBMS layer. 
  • The Azure Virtual network deployed to host the SAP system, with all its subnets, is stretched across the zones.
  • You should use Azure Managed Disks for all the VMs you deploy, as the unmanaged ones are not supported for zonal deployments.
  • Azure Premium and Ultra SSD storages doesn.t support any type of storage replication across zones.
  • You should invest in automation that allows you, in case of zone failure, to automatically start the SAP application in second zone.

Combined high availability and disaster recovery configuration

Some customers uses zones for combined HA and DR configurations that ensures a Recovery Point Objective (RPO) of zero. This configuration is recommended only in certain circumstances. The following considerations apply for this configuration:
  • You can't deploy availability sets in Azure Availability Zones, hence, you have one update and fault domain for your application layer as it's deployed in one zone.
  • You should monitor the status closely while you use this architecture and try to keep the active DBMS as well as SAP Central Services instances in the same zone as your deployed application layer.
  • You should have production application instances pre-installed in VMs that run the active QA application instances.
  • the third zone is used to host the SBD device in case you build the SUSE Linux Pacemaker cluster or additional application instances.
  • At present, the solution that uses Microsoft Scale-Out File Server is not supported across zones.






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














































Comments

Post a Comment

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

By Ashwin Venugopal -
Image
  Azure Sentinel Workbooks Several ready for use templates are provided by the Azure Sentinel that can be used to create your own workbook and then modify them as needed for Contoso. Most of the data connectors it uses to ingest data come with their own workbooks, but better insight can be obtained by simply looking into the data that is being ingested by using tables and visualizations, including bar and pie charts. You can also make your own workbook easily by using this data from the beginning instead of using the predefined templates. Workbook Page You can easily access the workbook page from the Azure Sentinel from the navigation pane which consists of the: Workbook header- You can add a new workbook and review the saved workbooks as well as templates that are available on the workbook page. Templates section- You can access existing workbook templates on the Templates tab. You can save some of the workbooks for quick access and they will appear on the My Workbooks tab.  From the
Read more

Work with String Data Using KQL Statements

By Ashwin Venugopal -
Image
  Extract Data from Unstructured String Fields Unstructured string fields often contains the Security log data and requires parsing to extract data. There are multiple ways of pulling information from string fields in KQL and the two primary operators used are extract and parse.  Extract It gets a match for a regular expression from a text string. You can convert the extracted substring to the indicated type.  Arguments regex- A regular expression. captureGroup- A positive int constant indicating the capture group to extract. 0 stands for the entire match, 1 for the value matched by the first '('parenthesis')' in the regular expression, 2 or more for subsequent parenthesis.  text- A string to search. typeLiteral- An optional type literal. If provided, the extracted substring is converted to this type.  Returns If regex finds a match in text- the substring matched against the indicated capture group captureGroup, optionally converted to typeLiteral. If there's no mat
Read more

Threat Hunting in Microsoft Sentinel (part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Introducing the Microsoft Sentinel Hunting Page Threat hunting is a series activities performed while investigating and as there are no guidelines to perform it, the available tools on the Microsoft Sentinel can be introduced to perform better in your investigations. Firstly, you have to choose the Hunting link in the Microsoft Sentinel navigation menu to get to the Hunting page which is divided into the following sections: The header bar- It is located at the top of the page as usual and contains Refresh as well as timespan drop down menu. The New Query button can help you with creating a new query and the Run all queries button can run all the hunting queries in the background while also updating the hunting query list section with the number of results found.  The summary bar- Here, you can view the total number of queries available to run, the total number of bookmarks, the number of results from running live
Read more