Overview
In Azure, SAP workload deployment can either be regional or zonal depending on the availability and resiliency requirements of the SAP applications. For regional deployment, the availability sets are used to deploy SAP workloads within a single zone or datacenter in a region. Whereas for zonal deployment, availability zones are used to deploy SAP workloads across zones within a region and in some case in combination with Availability Set for SAP application server layer.
Recently, Microsoft announced support for a new availability option for SAP workload called Virtual Machine Scale Set with Flexible Orchestration.
Flexible Orchestration in Virtual Machine Scale Sets provides a way to attain optimal availability for SAP workloads, like other deployment frameworks as availability sets and availability zones. When deploying a flexible scale set with a platformFaultDomainCount=1, you have the option to either create the scale set within a region or expand it across multiple availability zones. Before proceeding further, it is important to refer to the deployment guide for virtual machine scale sets for SAP workloads to ensure that all important considerations and supported options are evaluated.
For new SAP deployments, you have the option to directly deploy SAP VMs in a flexible scale set with platformFaultDomainCount=1 (FD=1). But for existing SAP systems that are not currently deployed using the flexible scale set framework, you have the option to migrate the SAP VMs to a flexible scale set with FD=1.
This blog post outlines the details on the process of migrating existing SAP workloads that are deployed in an availability set or availability zone to a flexible scale set with FD=1 deployment option.
Benefits of flexibility scale set availability options
- For cross zonal SAP deployment, flexible scale set distribute VMs across specified zone and would also distribute VMs across different fault domains within the zone on best effort basis. This eliminates the requirement of anchoring VMs using a proximity placement group with availability set in a specific zone for distributing application tier VMs across different fault domains within the zone.
- The deployment of the entire SAP system can be incorporated into a single scale set, allowing for the inclusion of different virtual machine (VM) SKU families within the same scale set. For instance, a combination of general purpose VM SKUs and M-Series VM SKUs can be included in a single scale set with FD=1. This results in simplified architecture, compared to using multiple availability sets for different layers of a single SAP system.
- Deployment of SAP system in a scale set with FD=1 is scoped at zonal level, which means VMs in scale set can span across different compute clusters/data centers belonging to the same zone. This offers increased flexibility in resizing the VMs and reduces the risk of failure due to capacity limitations.
INFORMATION
Now with the different availability options on Azure for SAP workload, such as virtual machine scale set, availability zone, and availability set, we have compiled a comparison of different deployment types. This comparison shows how these options can be applied across different Azure regions, including across zones, within a single zone, or in a region without zones, to configure a highly available SAP workload. As a result, we have updated our high availability architecture and scenarios for SAP NetWeaver document, encompassing this discussion.
Migration of existing SAP system VMs to Flexible Scale Set
To migrate VMs of an existing SAP system to VMSS Flex, a new PowerShell cmdlet Move-AzSAPVMToVMSSFlex is developed. It is advised to refer to Important consideration of Flexible virtual machine scale sets for SAP workload document before you use cmdlet.
It is important to note that open-source PowerShell cmdlet is designed ONLY for flexible scale set with SAP workload scenarios. Prior to executing the migration and scripts on the productive SAP system, it is crucial to conduct thorough testing on the test VMs. Ideally, the test VMs should also have an SAP system installed. It is important to ensure that the test VMs are configured identically to the productive VMs. This includes having the same VM SKU, disk types, disk numbers and sizes, number of NIC cards, subscription, load balancers, and other relevant factors. If possible, it is recommended to place the test VMs within the same subnet and resource groups as the productive VMs. Additionally, it is essential to have a well-implemented and tested backup/restore procedure in place.
The cmdlet Move-AzSAPVMToVMSSFlex will perform necessary prechecks to ensure that the SAP VM migration is possible, and that final configuration is supported by Microsoft. The Azure region, resource group, disk names, NIC card(s), and load balancer configuration of SAP VM(s) will remain unchanged even after migration using the cmdlet.
DISCLAIMER: THE SCRIPT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING ANY IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR NON-INFRINGEMENT.
SAP system migration to Flexible Scale Set - Possible Options
Depending on the deployment of your current SAP workload (whether it uses availability sets or availability zones), you have the option to migrate to a flexible scale set with FD=1. The following matrix provides details on the various migration options available for transitioning to a flexible scale set.
|
System type |
Source VM |
Target VM (flexible scale set with FD=1) |
Azure Region |
Azure storage |
Disk migration method |
|
Scenario 1: HA SAP systems |
Regional VM* (deployed in availability set) |
Zonal VM in flexible scale set, span across zones |
Applicable in region with zones |
Managed disk v1 |
Create zonal disk from snapshot. |
|
Scenario 2: HA SAP systems |
Zonal VM (deployed in Availability zone) |
Zonal VM in flexible scale set, span across zones |
Applicable in region with zones |
Managed disk v1 & v2 |
Create zonal disk from snapshot. In the case that VM stays in the same zone, zonal disks are reattached.
|
|
Scenario 3: non-HA SAP systems |
Regional VM* (deployed in availability set) |
Zonal VM in scale set in one zone |
Applicable in region with zones |
Managed disk v1 |
Create zonal disk from snapshot. |
|
Scenario 4: non-HA SAP systems |
Zonal VM (deployed in availability zone) |
Zonal VM in scale set in one zone |
Applicable in region with zones |
Managed disk v1 & v2 |
Create zonal disk from snapshot. In the case that VM stays in the same zone, zonal disks are reattached.
|
|
Scenario 5: |
Regional VM* (Deployed in availability set) |
Regional VM* in scale set |
Applicable in region with no zones |
Managed disk v1 |
Attach existing regional disks. |
IMPORTANT NOTES:
- With PowerShell cmdlet, you can migrate existing deployment to flexible scale set with FD=1 within the same region. Migration of deployment across region is not supported.
- A * Regional VM is a virtual machine deployed in a specific region, and the associated managed disk is usually provisioned as a regional disk. However, it's crucial to understand that regional disks cannot be attached to zonal VMs. So, if you decide to convert your regional VM to a zonal VM, the disks connected to the VM must also be converted to zonal disks.
- When performing a migration of an existing SAP VM to flexible scale set with FD=1 in an Azure region with zones, the migrated VM will always be a zonal VM. Target VM couldn’t be a regional VM.
- New: Current version of cmdlet works with Premium v2 managed disk.
- The current version of cmdlet does not support migration of Ultra disks.
- New: Azure NetApp Files is network storage and is configured/mounted inside of the operating system. During the migration to Scale Set, all operating system configuration is preserved.
For more information on how to manage Azure NetApp Files volumes during the VM migration to Scale Set, please check this blog: Configuring Azure NetApp Files (ANF) Application Volume Group (AVG) for zonal SAP HANA deployment.
Scenario 1: The source SAP system, which is highly available, is initially deployed regionally using an availability set. It is then migrated to a scale set with FD=1, spanning across availability zones. It's important to note that this entire migration process takes place within the same region, with managed disk v1 being attached to the system. Here are few considerations for deploying across availability zones.
Scenario 2: The source SAP system, which is highly available, is initially deployed zonally using availability zone. It is then migrated to scale set with FD=1, spanning across availability zones. It’s important to note that this entire migration process takes place within the same region, with managed disk v1 being attached to the system.
Scenario 3: The source SAP system, which is non-HA or non-production, is initially deployed regionally using availability set. It is then migrated to scale set with FD=1 in a single zone of a region. It’s important to note that this entire migration process takes place within the same region, with managed disk v1 being attached to the system.
Scenario 5: The source SAP system, which is non-HA or non-production, is initially deployed regionally using availability set. It is then migrated to scale set with FD=1 in a region with no zones. It’s important to note that this entire migration process takes place within the same region, with managed disk v1 being attached to the system.
High level execution steps: Move-AzSAPVMToVMSSFlex cmdlet
Following action is performed on executing Move-AzSAPVMToVMSSFlex command:
- Verify the existence of the specified VM.
- Verify the existence of the specified flexible scale set.
- Check if the scale set orchestration mode is set to flexible.
- Ensure that the flexible scale set has a platformFaultDomainCount of 1.
- Determine whether the Azure region has availability zones.
- For Azure regions with availability zones, confirm if the flexible scale set is configured as zonal.
- Automatically detect if the VM is configured with an Azure Load Balancer and validate that the Load Balancer type is Standard.
- In Azure regions with availability zones, check if the required VM SKU is available in the desired zone.
- Stop the VM.
- For Azure regions with availability zones:
- Create snapshots of the OS and data disks.
- Create copies of the original disks from the snapshots, following the naming convention: <OriginalDiskName>-orig<x>.
- These copied disks can be used to restore the original disks if needed.
- Set the properties of all disks and NICs to "Detach" to prevent automatic deletion when the VM is deleted.
- Delete the virtual machines (not the disks and NICs).
- For Azure regions with availability zones:
-
If source VM is zonal VM , and VM stays in the same zone, zonal disks are reattached.
- Otherwise, delete the original disks and create new zonal disks from disk snapshots using the original disk names.
- Recreate the VM and place it in the flexible scale set.
- Attach the new zonal disks or reattach existing zonal disks (VM stays in the same zone).
-
- For Azure regions without availability zones, reattach the existing disks.
- Existing NIC cards will be reattached.
- If the Azure Load Balancer is configured, preserve all settings as the existing NIC cards are reattached.
INFORMATION: You can check Move-AzSAPVMToVMSSFlex cmdlet code in PowerShell module SAPAzurePowerShellModules located in PowerShell Gallery.
Prepare PowerShell Environment and Scripts
Install Latest PowerShell Environment (7.3 or newer)
- You need to install latest PowerShell runtime environment - 7.3, or newer.
- You can check PowerShell version by running this command:
$PSVersionTable.PSVersion Major Minor Patch PreReleaseLabel BuildLabel ----- ----- ----- --------------- ---------- 7 3 4
Install Latest Az PowerShell Modules
Install the latest version of Az PowerShell modules, by running command:
Install-Module -Name Az -Repository PSGallery -Force
This is described in the official guide Install the Azure Az PowerShell module.
Install Latest SAPAZurePowerShellModules Modules
You will use PowerShell cmdlet Move-AzSAPVMToVMSSFlex to move VMs to the flexible scale set. This cmdlet is part of the SAPAZurePowerShellModules module. You can install SAPAZurePowerShellModules module from PowerShell Gallery by running this PowerShell command:
Install-Module SAPAZurePowerShellModules -Repository PSGallery -Force -Verbose
Set the Execution Policy to unrestricted.
Set-ExecutionPolicy Unrestricted
Connect to the correct subscription (see here for details)
Select-AzSubscription -SubscriptionName 'your-subscription-name'
Or
Select-AzSubscription -SubscriptionId 'your-subscription-id'
Create flexible scale set with FD=1
It's not possible to create flexible virtual machine scale set without a scaling profile through the Azure Portal. However, you can use an alternative client to create a scale set without a scaling profile.
Create a flexible scale set with FD=1 for cross zonal deployments
To create a zonal flexible scale set with a PlatformFaultDomainCount of 1, and zones 1, 2, and 3 in PowerShell, you can use the following command:
$ResourceGroupName = "sap-ab1"
$VMSSName = "sap-flex-zones-ab1"
$Location = "westeurope"
# Create flexible scale set for cross zonal deployment of SAP workload in a region.
$vmssConfig = New-AzVmssConfig -Location $Location -PlatformFaultDomainCount 1 -Zone @(1,2,3)
New-AzVmss -ResourceGroupName $ResourceGroupName -Name $VMSSName -VirtualMachineScaleSet $vmssConfig
Create a flexible scale set with FD=1 for single zone deployments
To create a zonal flexible scale set with a PlatformFaultDomainCount of 1, and zones 1 in PowerShell, you can use the following command:
$ResourceGroupName = "sap-ab1"
$VMSSName = "sap-flex-zones-ab1"
$Location = "westeurope"
# Create flexible scale set for single zone deployment of SAP workload in a region.
$vmssConfig = New-AzVmssConfig -Location $Location -PlatformFaultDomainCount 1 -Zone @(1)
New-AzVmss -ResourceGroupName $ResourceGroupName -Name $VMSSName -VirtualMachineScaleSet $vmssConfig
Create a flexible scale set with FD=1 for deployment in a region with no zones
To create a regional flexible scale set with a PlatformFaultDomainCount of 1 in a region without any zones using PowerShell, you can use the following command:
$ResourceGroupName = "sap-ab1"
$VMSSName = "sap-flex-region-ab1"
$Location = "switzerlandwest"
# Create flexible scale set for deployment of SAP workload in a region with no zones.
$vmssConfig = New-AzVmssConfig -Location $Location -PlatformFaultDomainCount 1
New-AzVmss -ResourceGroupName $ResourceGroupName -Name $VMSSName -VirtualMachineScaleSet $vmssConfig
Execute Move-AzSAPVMToVMSSFlex cmdlet to migrate VM
Command to migrate VM to a particular zone within a region
To perform a VM migration to a flexible scale set with zones, you can follow the command below:
$ResourceGroupName = "sap-ab1"
$VMName = "ab1-ascs"
$VMSSName = "sap-flex-zones-ab1"
$Location = "westeurope"
# Move VM to VMSS Flex and Zone 2
Move-AzSAPVMToVMSSFlex -VMResourceGroupName $ResourceGroupName -VirtualMachineName $VMName -VMSSGResourceGroupName $ResourceGroupName -VMSSName $VMSSName -AzureZone 2
Command to migrate VM to a regional scale set with no zones
To perform a VM migration to a flexible scale set without zones (within a regional context), you can follow the steps provided below:
$ResourceGroupName = "sap-ab1"
$VMSSName = "sap-flex-region-ab1"
$Location = "switzerlandwest"
$VMName = "ab1-ascs"
# Move VM to non-zonal VMSS Flex
Move-AzSAPVMToVMSSFlex -VMResourceGroupName $ResourceGroupName -VirtualMachineName $VMName -VMSSGResourceGroupName $ResourceGroupName -VMSSName $VMSSName
TIP: To get the help information on PowerShell cmdlet Move-AzSAPVMToVMSSFlex, you can execute following PS command:
help Move-AzSAPVMToVMSSFlex -Full
Post configuration tasks
SAP license key
The PS cmdlet Move-AzSAPVMToVMSSFlex does not modify the Azure region, VM name, NIC card names and configurations, disk names, load balancer configuration, region, or Azure resource group.
When moving VM(s) with SAP message server processes, such as SAP ASCS/SCS instances or DVEBMGS<Nr> instances, it is necessary to install a new SAP license.
The SAP license key is tied to the host where the SAP message server is running. In the case of clustered SAP ASCS/SCS/DVEBMGS<Nr>, two licenses are installed, one for each cluster host/VM. In Azure, SAP utilizes a Unique VM ID to calculate the license key. As the VM is newly re-created, it will receive a NEW unique VM ID, rendering the old license invalid. For each recreated SAP ASCS/SCS/DVEBMGS<Nr> node, a new hardware key needs to be obtained, a new license generated, and it must be installed.
INFO: For more details on SAP licensing in Azure check this blog SAP NetWeaver Licensing Mechanism in Microsoft Azure Cloud - Part 1.
Azure fence agent
The current version of the script does not include the functionality to enable managed-system identities or service principal settings required for the Azure fencing agent. It also does not assign IAM role, which is required to configure Azure fence agent. If you are utilizing system-managed identities for the cluster VMs or a service principal for the Azure fencing agent on SLES or RHEL, please ensure that you manually reapply the previous settings.