Install SAP NetWeaver HA on a Windows failover cluster and shared disk for an SAP ASCS/SCS instance in Azure
This article describes how to install and configure a high-availability SAP system in Azure by using a Windows Server failover cluster and cluster shared disk for clustering an SAP ASCS/SCS instance. As described in Architecture guide: Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a cluster shared disk, there are two alternatives for cluster shared disk:
- Azure shared disks
- Using SIOS DataKeeper Cluster Edition to create mirrored storage, that will simulate clustered shared disk
Prerequisites
Before you begin the installation, review these documents:
We don't describe the DBMS setup in this article because setups vary depending on the DBMS system you use. We assume that high-availability concerns with the DBMS are addressed with the functionalities that different DBMS vendors support for Azure. Examples are Always On or database mirroring for SQL Server and Oracle Data Guard for Oracle databases. The high availability scenarios for the DBMS are not covered in this article.
There are no special considerations when different DBMS services interact with a clustered SAP ASCS or SCS configuration in Azure.
Note
The installation procedures of SAP NetWeaver ABAP systems, Java systems, and ABAP+Java systems are almost identical. The most significant difference is that an SAP ABAP system has one ASCS instance. The SAP Java system has one SCS instance. The SAP ABAP+Java system has one ASCS instance and one SCS instance running in the same Microsoft failover cluster group. Any installation differences for each SAP NetWeaver installation stack are explicitly mentioned. You can assume that the rest of the steps are the same.
Install SAP with a high-availability ASCS/SCS instance
Important
If you use SIOS to present shared disk, don't place your page file on the SIOS DataKeeper mirrored volumes. You can leave your page file on the temporary drive D of an Azure virtual machine, which is the default. If it's not already there, move the Windows page file to drive D of your Azure virtual machine.
Installing SAP with a high-availability ASCS/SCS instance involves these tasks:
- Create a virtual host name for the clustered SAP ASCS/SCS instance.
- Install SAP on the first cluster node.
- Modify the SAP profile of the ASCS/SCS instance.
- Add a probe port.
- Open the Windows firewall probe port.
Create a virtual host name for the clustered SAP ASCS/SCS instance
In the Windows DNS manager, create a DNS entry for the virtual host name of the ASCS/SCS instance.
Important
The IP address that you assign to the virtual host name of the ASCS/SCS instance must be the same as the IP address that you assigned to Azure Load Balancer.
Define the DNS entry for the SAP ASCS/SCS cluster virtual name and TCP/IP address
If are using the new SAP Enqueue Replication Server 2, which is also clustered instance, then you need to reserve in DNS a virtual host name for ERS2 as well.
Important
The IP address that you assign to the virtual host name of the ERS2 instance must be the second the IP address that you assigned to Azure Load Balancer.
Define the DNS entry for the SAP ERS2 cluster virtual name and TCP/IP address
To define the IP address that's assigned to the virtual host name, select DNS Manager > Domain.
New virtual name and TCP/IP address for SAP ASCS/SCS cluster configuration
Install the SAP first cluster node
Execute the first cluster node option on cluster node A. Select:
- ABAP system: ASCS instance number 00
- Java system: SCS instance number 01
- ABAP+Java system: ASCS instance number 00 and SCS instance number 01
Important
Keep in mind that the configuration in the Azure internal load balancer load balancing rules(if using Basic SKU) and the selected SAP instance numbers must match.
Follow the SAP described installation procedure. Make sure in the start installation option “First Cluster Node”, to choose “Cluster Shared Disk” as configuration option.
Tip
The SAP installation documentation describes how to install the first ASCS/SCS cluster node.
Modify the SAP profile of the ASCS/SCS instance
If you have Enqueue Replication Server 1, add SAP profile parameter enque/encni/set_so_keepalive as described below. The profile parameter prevents connections between SAP work processes and the enqueue server from closing when they are idle for too long. The SAP parameter is not required for ERS2.
Add this profile parameter to the SAP ASCS/SCS instance profile, if using ERS1.
enque/encni/set_so_keepalive = trueFor both ERS1 and ERS2, make sure that the
keepaliveOS parameters are set as described in SAP note 1410736.To apply the SAP profile parameter changes, restart the SAP ASCS/SCS instance.
Add a probe port
Use the internal load balancer's probe functionality to make the entire cluster configuration work with Azure Load Balancer. The Azure internal load balancer usually distributes the incoming workload equally between participating virtual machines.
However, this won't work in some cluster configurations because only one instance is active. The other instance is passive and can’t accept any of the workload. A probe functionality helps when the Azure internal load balancer detect which instance is active, and only target the active instance.
Important
In this example configuration, the ProbePort is set to 620Nr. For SAP ASCS instance with number 00 it is 62000. You will need to adjust the configuration to match your SAP instance numbers and your SAP SID.
To add a probe port run this PowerShell Module on one of the cluster VMs:
In the case of SAP ASC/SCS Instance
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID SID -ProbePort 62000If using ERS2, which is clustered. There is no need to configure probe port for ERS1, as it is not clustered.
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID SID -ProbePort 62001 -IsSAPERSClusteredInstance $True
The code for function Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource would look like:
function Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource {
<#
.SYNOPSIS
Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer Health Probe Port on 'SAP $SAPSID IP' cluster resource.
.DESCRIPTION
Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer Health Probe Port on 'SAP $SAPSID IP' cluster resource.
It will also restart SAP Cluster group (default behavior), to activate the changes.
You need to run it on one of the SAP ASCS/SCS Windows cluster nodes.
Expectation is that SAP group is installed with official SWPM installation tool, which will set default expected naming convention for:
- SAP Cluster Group: 'SAP $SAPSID'
- SAP Cluster IP Address Resource: 'SAP $SAPSID IP'
.PARAMETER SAPSID
SAP SID - 3 characters staring with letter.
.PARAMETER ProbePort
Azure Load Balancer Health Check Probe Port.
.PARAMETER RestartSAPClusterGroup
Optional parameter. Default value is '$True', so SAP cluster group will be restarted to activate the changes.
.PARAMETER IsSAPERSClusteredInstance
Optional parameter.Default value is '$False'.
If set to $True , then handle clsutered new SAP ERS2 instance.
.EXAMPLE
# Set probe port to 62000, on SAP cluster resource 'SAP AB1 IP', and restart the SAP cluster group 'SAP AB1', to activate the changes.
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000
.EXAMPLE
# Set probe port to 62000, on SAP cluster resource 'SAP AB1 IP'. SAP cluster group 'SAP AB1' IS NOT restarted, therefore changes are NOT active.
# To activate the changes you need to manualy restart 'SAP AB1' cluster group.
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 -RestartSAPClusterGroup $False
.EXAMPLE
# Set probe port to 62001, on SAP cluster resource 'SAP AB1 ERS IP'. SAP cluster group 'SAP AB1 ERS' IS restarted, to activate the changes.
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 -IsSAPERSClusteredInstance $True
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$True)]
[ValidateNotNullOrEmpty()]
[ValidateLength(3,3)]
[string]$SAPSID,
[Parameter(Mandatory=$True)]
[ValidateNotNullOrEmpty()]
[int] $ProbePort,
[Parameter(Mandatory=$False)]
[bool] $RestartSAPClusterGroup = $True,
[Parameter(Mandatory=$False)]
[bool] $IsSAPERSClusteredInstance = $False
)
BEGIN{}
PROCESS{
try{
if($IsSAPERSClusteredInstance){
#Handle clustered SAP ERS Instance
$SAPClusterRoleName = "SAP $SAPSID ERS"
$SAPIPresourceName = "SAP $SAPSID ERS IP"
}else{
#Handle clustered SAP ASCS/SCS Instance
$SAPClusterRoleName = "SAP $SAPSID"
$SAPIPresourceName = "SAP $SAPSID IP"
}
$SAPIPResourceClusterParameters = Get-ClusterResource $SAPIPresourceName | Get-ClusterParameter
$IPAddress = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Address" }).Value
$NetworkName = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Network" }).Value
$SubnetMask = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "SubnetMask" }).Value
$OverrideAddressMatch = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "OverrideAddressMatch" }).Value
$EnableDhcp = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "EnableDhcp" }).Value
$OldProbePort = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "ProbePort" }).Value
$var = Get-ClusterResource | Where-Object { $_.name -eq $SAPIPresourceName }
Write-Output "Current configuration parameters for SAP IP cluster resource '$SAPIPresourceName' are:"
Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
Write-Output " "
Write-Output "Current probe port property of the SAP cluster resource '$SAPIPresourceName' is '$OldProbePort'."
Write-Output " "
Write-Output "Setting the new probe port property of the SAP cluster resource '$SAPIPresourceName' to '$ProbePort' ..."
Write-Output " "
$var | Set-ClusterParameter -Multiple @{"Address"=$IPAddress;"ProbePort"=$ProbePort;"Subnetmask"=$SubnetMask;"Network"=$NetworkName;"OverrideAddressMatch"=$OverrideAddressMatch;"EnableDhcp"=$EnableDhcp}
Write-Output " "
if($RestartSAPClusterGroup){
Write-Output ""
Write-Output "Activating changes..."
Write-Output " "
Write-Output "Taking SAP cluster IP resource '$SAPIPresourceName' offline ..."
Stop-ClusterResource -Name $SAPIPresourceName
sleep 5
Write-Output "Starting SAP cluster role '$SAPClusterRoleName' ..."
Start-ClusterGroup -Name $SAPClusterRoleName
Write-Output "New ProbePort parameter is active."
Write-Output " "
Write-Output "New configuration parameters for SAP IP cluster resource '$SAPIPresourceName':"
Write-Output " "
Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
}else
{
Write-Output "SAP cluster role '$SAPClusterRoleName' is not restarted, therefore changes are not activated."
}
}
catch{
Write-Error $_.Exception.Message
}
}
END {}
}
Open the Windows firewall probe port
Open a Windows firewall probe port on both cluster nodes. Use the following script to open a Windows firewall probe port. Update the PowerShell variables for your environment.
If using ERS2, you will also need to open the firewall port for the ERS2 probe port.
$ProbePort = 62000 # ProbePort of the Azure internal load balancer
New-NetFirewallRule -Name AzureProbePort -DisplayName "Rule for Azure Probe Port" -Direction Inbound -Action Allow -Protocol TCP -LocalPort $ProbePort
Install the database instance
To install the database instance, follow the process that's described in the SAP installation documentation.
Install the second cluster node
To install the second cluster, follow the steps that are described in the SAP installation guide.
Install the SAP Primary Application Server
Install the Primary Application Server (PAS) instance <SID>-di-0 on the virtual machine that you've designated to host the PAS. There are no dependencies on Azure. If using SIOS, there are no DataKeeper-specific settings.
Install the SAP Additional Application Server
Install an SAP Additional Application Server (AAS) on all the virtual machines that you've designated to host an SAP Application Server instance.
Test the SAP ASCS/SCS instance failover
For the outlined failover tests, we assume that SAP ASCS is active on node A.
Verify that the SAP system can successfully failover from node A to node B Choose one of these options to initiate a failover of the SAP <SID> cluster group from cluster node A to cluster node B:
- Failover Cluster Manager
- Failover Cluster PowerShell
$SAPSID = "PR1" # SAP <SID> $SAPClusterGroup = "SAP $SAPSID" Move-ClusterGroup -Name $SAPClusterGroupRestart cluster node A within the Windows guest operating system. This initiates an automatic failover of the SAP <SID> cluster group from node A to node B.
Restart cluster node A from the Azure portal. This initiates an automatic failover of the SAP <SID> cluster group from node A to node B.
Restart cluster node A by using Azure PowerShell. This initiates an automatic failover of the SAP <SID> cluster group from node A to node B.
Verification
After failover, verify that the SAP <SID> cluster group is running on cluster node B.
In Failover Cluster Manager, the SAP <SID> cluster group is running on cluster node B
After failover, verify shared disk is now mounted on cluster node B.
After failover, if using SIOS, verify that SIOS DataKeeper is replicating data from source volume drive S on cluster node B to target volume drive S on cluster node A.
SIOS DataKeeper replicates the local volume from cluster node B to cluster node A
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for