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

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more