Azure VM High Availability & Disaster Recovery (part 2)

By Ashwin Venugopal -

 



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


High-availability of SAP application servers

High-availability can be simply achieved by redundancy through installing individual application servers on separate Azure VMs with at least two SAP application instances installed in two instances of Azure VMs. An Azure availability set can ensure that:
  • Each Azure belongs to a different upgrade domain ensuring that Hyper-V hosts hosting these VMs aren't updated at the same time during planned maintenance events that needs a temporary downtime.
  • Each Azure VM belongs to a different fault domain ensuring that VMs are deployed such that a localized rack-level failure does not affect the availability of all Azure VMs. 

High-availability of SAP ASCS-SCS instance

Additional provisions are needed by Azure VMs to implement the operating system-dependent clustering capabilities:
  • High-availability architecture for SAP ASCS/SCS instance on Windows (single-SID configuration)- Windows Server Failover Clustering (WSFC) solution can be used to protect the SAP ASCS/SCS instance which has following two variants- 

  1. Cluster the SAP ASCS/SCS instance by using clustered shared disks that can be implemented by using third-party solutions like SIOS Datakeeper.
  2. Cluster the SAP ASCS/SCS instance by using file share in which a highly available UNC/sapmnt share can be implemented by using WSFC with Scale Out File Server (SOFS) and the Storage Spaces Direct (S2D) feature in Windows Server 2016. 

  • High-availability architecture for SAP ASCS/SCS instance on Linux (single-SID configuration)- which needs the use of Linux clustering (Pacemaker with STONITH) and  a highly available NFS share, that can be provisioned by using Azure VMs in a separate cluster, Azure NetApp Files, or Red Hat GlusterFS.

  • High-availability architecture for SAP ASCS/SCS instance on Windows (multi-SID configuration)- It is supported only with WSFC by using file share and shared disk. 

High-availability for DBMS instance

The DBMS consists of a single point of failure in SAP system which can also be protected by using high-availability solution by deploying a DBMS layer in an active/passive mode along with a failover clustering solution to protect from infrastructure or software failures. 

The DBMS-specific failover framework generally integrates with the operating system-level clustering functionality and take advantage of the Azure platform support. For example, SQL Server Always On high-availability solution in Azure always integrates with Windows Server Failover Clustering and uses an Azure Load Balancer with an availability set. It also replicates DBMS data  and log files by using its own DBMS replication which eliminates the requirement for any shared storage.   

High-availability capabilities of Azure infrastructure

The following principles are used to maximize the high availability of SAP NetWeaver system in Azure:
  • The complete system is deployed on Azure.
  • The complete system runs within one Azure subscription.
  • The complete system runs within one Azure Virtual Network.
  • Each layer must use a dedicated Availability Set.
  • All VMs running DBMS instances of one SAP system are in one Availability Set.
  • All VMs use managed disks.
  • DBMS data and log files are replicated using DBMS high availability functions that synchronize the data.
  • (A)SCS instance files and SAP Global folder are either stored on a highly available file share or synchronously replicated between disks of two Azure VMs that are part of the same availability set.



To read part 1 please click here 
To read part 3 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