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.

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 AlwaysOn or database mirroring for SQL Server and Oracle Data Guard for Oracle databases. In the scenario we use in this article, we don't add more protection to the DBMS.

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 all other parts are the same.

Install SAP with a high-availability ASCS/SCS instance

Important

Be sure not to place your page file on SIOS DataKeeper mirrored volumes. DataKeeper does not support 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 the SAP 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

  1. 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 (<SID>-lb-ascs).

    The IP address of the virtual SAP ASCS/SCS host name (pr1-ascs-sap) is the same as the IP address of Azure Load Balancer (pr1-lb-ascs).

    Figure 1: Define the DNS entry for the SAP ASCS/SCS cluster virtual name and TCP/IP address

    Figure 1: Define the DNS entry for the SAP ASCS/SCS cluster virtual name and TCP/IP address

  2. To define the IP address that's assigned to the virtual host name, select DNS Manager > Domain.

    Figure 2: New virtual name and TCP/IP address for SAP ASCS/SCS cluster configuration

    Figure 2: New virtual name and TCP/IP address for SAP ASCS/SCS cluster configuration

Install the SAP first cluster node

  1. Execute the first cluster node option on cluster node A. For example, on the pr1-ascs-0*host.

  2. To keep the default ports for the Azure internal load balancer, 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

    To use instance numbers other than 00 for the ABAP ASCS instance and 01 for the Java SCS instance, first, change the Azure internal load balancer default load balancing rules. For more information, see Change the ASCS/SCS default load balancing rules for the Azure internal load balancer.

The next few tasks aren't described in the standard SAP installation documentation.

Note

The SAP installation documentation describes how to install the first ASCS/SCS cluster node.

Modify the SAP profile of the ASCS/SCS instance

First, add a new profile parameter. The profile parameter prevents connections between SAP work processes and the enqueue server from closing when they are idle for too long. We mention the problem scenario in Add registry entries on both cluster nodes of the SAP ASCS/SCS instance. In that section, we also introduce two changes to some basic TCP/IP connection parameters. In a second step, you need to set the enqueue server to send a keep_alive signal so that the connections don't hit the Azure internal load balancer's idle threshold.

To modify the SAP profile of the ASCS/SCS instance:

  1. Add this profile parameter to the SAP ASCS/SCS instance profile:

    enque/encni/set_so_keepalive = true
    

    In our example, the path is:

    <ShareDisk>:\usr\sap\PR1\SYS\profile\PR1_ASCS00_pr1-ascs-sap

    For example, to the SAP SCS instance profile and corresponding path:

    <ShareDisk>:\usr\sap\PR1\SYS\profile\PR1_SCS01_pr1-ascs-sap

  2. To apply the 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 assigns work only to an active instance. With the probe functionality, the internal load balancer can detect which instances are active, and then target only the instance with the workload.

To add a probe port:

  1. Check the current ProbePort value by running the following PowerShell command:

    $SAPSID = "PR1"     # SAP <SID>
    
    $SAPNetworkIPClusterName = "SAP $SAPSID IP"
    Get-ClusterResource $SAPNetworkIPClusterName | Get-ClusterParameter
    

    Execute the command from within one of the virtual machines in the cluster configuration.

  2. Define a probe port. The default probe port number is 0. In our example, we use probe port 62000.

    Figure 3: The cluster configuration probe port is 0 by default

    Figure 3: The default cluster configuration probe port is 0

    The port number is defined in SAP Azure Resource Manager templates. You can assign the port number in PowerShell.

    To set a new ProbePort value for the SAP <SID> IP cluster resource, run the following PowerShell script to update the PowerShell variables for your environment:

    $SAPSID = "PR1"      # SAP <SID>
    $ProbePort = 62000   # ProbePort of the Azure internal load balancer
    
    Clear-Host
    $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-Host "Current configuration parameters for SAP IP cluster resource '$SAPIPresourceName' are:" -ForegroundColor Cyan
    Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
    
    Write-Host
    Write-Host "Current probe port property of the SAP cluster resource '$SAPIPresourceName' is '$OldProbePort'." -ForegroundColor Cyan
    Write-Host
    Write-Host "Setting the new probe port property of the SAP cluster resource '$SAPIPresourceName' to '$ProbePort' ..." -ForegroundColor Cyan
    Write-Host
    
    $var | Set-ClusterParameter -Multiple @{"Address"=$IPAddress;"ProbePort"=$ProbePort;"Subnetmask"=$SubnetMask;"Network"=$NetworkName;"OverrideAddressMatch"=$OverrideAddressMatch;"EnableDhcp"=$EnableDhcp}
    
    Write-Host
    
    $ActivateChanges = Read-Host "Do you want to take restart SAP cluster role '$SAPClusterRoleName', to activate the changes (yes/no)?"
    
    if($ActivateChanges -eq "yes"){
    Write-Host
    Write-Host "Activating changes..." -ForegroundColor Cyan
    
    Write-Host
    write-host "Taking SAP cluster IP resource '$SAPIPresourceName' offline ..." -ForegroundColor Cyan
    Stop-ClusterResource -Name $SAPIPresourceName
    sleep 5
    
    Write-Host "Starting SAP cluster role '$SAPClusterRoleName' ..." -ForegroundColor Cyan
    Start-ClusterGroup -Name $SAPClusterRoleName
    
    Write-Host "New ProbePort parameter is active." -ForegroundColor Green
    Write-Host
    
    Write-Host "New configuration parameters for SAP IP cluster resource '$SAPIPresourceName':" -ForegroundColor Cyan
    Write-Host
    Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
    }else
    {
    Write-Host "Changes are not activated."
    }
    

    After you bring the SAP <SID> cluster role online, verify that ProbePort is set to the new value.

    $SAPSID = "PR1"     # SAP <SID>
    
    $SAPNetworkIPClusterName = "SAP $SAPSID IP"
    Get-ClusterResource $SAPNetworkIPClusterName | Get-ClusterParameter
    
    

    After the script runs, you are prompted to restart the SAP cluster group to activate the changes.

    Figure 4: Probe the cluster port after you set the new value

    Figure 4: Probe the cluster port after you set the new value

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.

$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

ProbePort is set to 62000. Now, you can access the file share \\ascsha-clsap\sapmnt from other hosts, such as from ascsha-dbas.

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.

Change the start type of the SAP ERS Windows service instance

Change the start type of the SAP ERS Windows service to Automatic (Delayed Start) on both cluster nodes.

Figure 5: Change the service type for the SAP ERS instance to delayed automatic

Figure 5: Change the service type for the SAP ERS instance to delayed automatic

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. 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. For example, on <SID>-di-1 to <SID>-di-<n>.

Note

This finishes the installation of a high-availability SAP NetWeaver system. Next, proceed with failover testing.

Test the SAP ASCS/SCS instance failover and SIOS replication

It's easy to test and monitor an SAP ASCS/SCS instance failover and SIOS disk replication by using Failover Cluster Manager and the SIOS DataKeeper Management and Configuration tool.

SAP ASCS/SCS instance is running on cluster node A

The SAP PR1 cluster group is running on cluster node A. For example, on pr1-ascs-0. Assign the shared disk drive S, which is part of the SAP PR1 cluster group, to cluster node A. The ASCS/SCS instance also uses disk drive S.

Figure 6: Failover Cluster Manager: The SAP <SID> cluster group is running on cluster node A

Figure 6: Failover Cluster Manager: The SAP <SID> cluster group is running on cluster node A

In the SIOS DataKeeper Management and Configuration tool, you can see that the shared disk data is synchronously replicated from the source volume drive S on cluster node A to the target volume drive S on cluster node B. For example, it's replicated from pr1-ascs-0 [10.0.0.40] to pr1-ascs-1 [10.0.0.41].

Figure 7: In SIOS DataKeeper, replicate the local volume from cluster node A to cluster node B

Figure 7: In SIOS DataKeeper, replicate the local volume from cluster node A to cluster node B

Failover from node A to node B

  1. 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 $SAPClusterGroup
    
    
  2. Restart 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.

  3. 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.

  4. 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.

    After failover, the SAP <SID> cluster group is running on cluster node B. For example, it's running on pr1-ascs-1.

    Figure 8: In Failover Cluster Manager, the SAP <SID> cluster group is running on cluster node B

    Figure 8: In Failover Cluster Manager, the SAP <SID> cluster group is running on cluster node B

    The shared disk is now mounted on cluster node B. SIOS DataKeeper is replicating data from source volume drive S on cluster node B to target volume drive S on cluster node A. For example, it's replicating from pr1-ascs-1 [10.0.0.41] to pr1-ascs-0 [10.0.0.40].

    Figure 9: SIOS DataKeeper replicates the local volume from cluster node B to cluster node A

    Figure 9: SIOS DataKeeper replicates the local volume from cluster node B to cluster node A