How to Migrate a Highly Available SAP System in Azure from Availability Set to Availability Zone

[Goran Condric]

For many SAP customers, high availability (HA) setup is a must-have option, as it reduces unplanned and planned downtime.

Availability set is the first HA concept for SAP systems in Azure, that protect an application against unplanned downtime of physical servers and racks inside ONE data center (DC). It also offers planned maintenance downtime minimization well.

Here is an example of an SAP HA architecture in Azure Availability Set:

An Availability Zone is a high-availability offering that protects your applications and data from datacenter failures. Availability zones are unique physical locations within an Azure region.

Many SAP on Azure customers implemented their SAP HA systems in Availability Sets, due to the unavailability of Azure Zones at the time of deployment.

Here's an example of an SAP HA architecture in Azure Zones:

Now, they're looking for a straightforward way to migrate their productive SAP HA systems from Availability Set construct to Azure Zones to improve their infrastructure SLA from 99.95% to 99.99%.

SAP standard migration requires running a project that lasts at least six months and incurs significant costs. Typically, SAP migrations also result in a full system downtime, which creates business processes disruption.

A set of SAP on Azure PowerShell cmdlets is:

• Automating the whole procedure on Windows and Linux based SAP systems.
• Reducing migration time from months to minutes/hours.
• There's no need for any post configuration activities.
• The whole procedure is also offering a way to avoid full SAP system downtime if desired (rolling approach) and it's minimizing or removing impact on productive SAP systems business processes.  

During the migration process, SAP systems can stay online all the time or most of the time!

Here's high level procedure:

• Prerequisite checks – check if specific region supports zones, identify two zones that are close for good network latency, check if VM types are available in the needed zones etc.
• Check if existing Load Balancers (LB) are Standard type that supports zones. If there are Basic load balancers, convert them to Standard type.
• Create two Proximity Placement Groups (PPG1 and PPG2) for each zone
• Create two new Azure Availability Sets for each zone, for SAP application servers, and configure availability sets to use corresponding PPGs.
• Prepare PowerShell environment and scripts.
• Move DBMS cluster VM1 to zone 1 (and optional PPG1) using PowerShell cmdlet:

  Move-AzVMToAzureZoneAndOrProximityPlacementGroup

• Move DBMS cluster VM2 to zone 2 (and optional PPG2) using PowerShell cmdlet:

   Move-AzVMToAzureZoneAndOrProximityPlacementGroup

• If you have file share cluster (like SUSE Linux with Pacemaker + DRBD, Red Hat GlusterFS):
  • Move file share cluster VM1 to zone 1 (and PPG1) using PowerShell cmdlet:

     Move-AzVMToAzureZoneAndOrProximityPlacementGroup

  • Move file share cluster VM2 to zone 2 (and PPG2) using PowerShell cmdlet:

     Move-AzVMToAzureZoneAndOrProximityPlacementGroup

• Move SAP ASCS/SCS cluster VM1 to zone 1 and PPG1 using PowerShell cmdlet:

  Move-AzVMToAzureZoneAndOrProximityPlacementGroup

• Install new SAP license key using the hardware key from SAP ASCS/SCS cluster VM1
• Move SAP ASCS/SCS cluster VM2 to zone 2 and PPG2 using PowerShell cmdlet:

  Move-AzVMToAzureZoneAndOrProximityPlacementGroup

• Install new SAP license key using the hardware key from SAP ASCS/SCS cluster VM2
• Move set of SAP application server(s) VM(s) to Availability Set 1 (associated with PPG1 and indirectly to zone 1) using PowerShell cmdlet:

   Move-AzVMToAvailabilitySetAndOrProximityPlacementGroup

• Move another set of SAP application server(s) VMs to Availability Set 2 (associated with PPG2 and indirectly to zone 2) using PowerShell cmdlet:

  Move-AzVMToAvailabilitySetAndOrProximityPlacementGroup

IMPORTANT: PowerShell cmdlet Move-AzVMToAzureZoneAndOrProximityPlacementGroup can also be used to move VM from one zone to another zone.

As Azure evolves and innovates, more of the discrete HA components are offered as native cloud services. (For example, a cloud file share).

Such SaaS cloud services are offering:

• Simplification of SAP HA architecture.
• Simplification of operations of highly available SAP systems.
  Cloud services are cloud SaaS service, for example, there's no need to manage it.
• Often, such cloud services can also lead to cheaper solutions compared to classical infrastructure solutions.

The whitepaper recommends the replacement of some older HA components with newer Azure services.  This simplifies the HA setup, minimize operations efforts, and optimize Azure costs and overall total cost of ownership (TCO).

Here you can find all the necessary information:

• High level overview on how to use PowerShell cmdlets is available here.
• White paper How to Migrate a Highly Available SAP System in Azure from Availability Set to Availability Zone , with detail  information on how to plan and execute migration.
• SAPAzurePowerShellModules PowerShell module available on PowerShell gallery repository.