SAP on Azure: SAP Web Dispatcher Highly Availability setup and virtual hostname/IP configuration with Azure Load balancer


Introduction

The Web Dispatcher component is used as a load balancer for http(s) across the SAP application servers. To achieve high availability of the SAP Web Dispatcher, Azure Internal Load Balancer (ILB) implements either the failover cluster (active/passive) or the parallel (active/active) Web Dispatcher setup. We will describe both scenarios and Azure Internal Load Balancer configuration for them.

For internet facing communications a stand-alone solution in DMZ would be the recommended architecture to satisfy security concerns. Embedded Web Dispatcher on ASCS is a special option, proper sizing due to additional workload on ASCS should be taken into account.

Above reference architecture diagram is for a highly available SAP on Azure deployment across Availability zone which provide VM availability SLA of 99.99%. We are only focusing on deployment SAP web Dispatcher part from this reference diagram. The entire setup can also be deployed using Availability sets.

Standard Load balancer is highly recommended for SAP environment. In case of zonal deployment, only standard Load balancer is supported. We can find more details in the ILB SKU comparison docs.

The Parallel (active/active) HA SAP Web Dispatcher Setup

In The Parallel (active-active setup), both SAP web Dispatchers (WD) should be deployed individually with shared nothing design and different SIDs, running and receiving user connections. To connect to the SAP web Dispatcher, Users will be using the one virtual hostname (FQDN)/IP as defined in the frontend IP of . Virtual IP to hostname/FQDN mapping needs to be performed in AD/DNS. Incoming traffic will be distributed to either of the SAP WD by the Azure Internal Load balancer. No Operating system cluster setup is required in this scenario. This architecture can be deployed in either Linux or Windows operating systems.

In ILB configuration, Session persistence settings will ensure that user’s successive requests always be routed from ILB to same SAP WD as long as its active and ready to receive connections.

Following are the advantages of active-active SAP WD setup.

  • Simpler design no need to set up OS Cluster
  • We have 2 WD instances to handle the requests and distribute the workload.
  • If one of the nodes fail, Load balancer will forward request to another and stop sending requests to failed node. So, it means WD setup is highly available.

ILB settings

Following are the ILB settings for the parallel SAP WD setup.

  • Front-end IP: Define the virtual IP for connecting to the highly available WD pair. Map the virtual IP to hostname (FQDN) in AD/DNS.
  • Backend Pool: Define/include the VM hosts in which individual web dispatchers are running.
  • Health Probe:

In health probe, you can define like following

Protocol: either HTTP OR HTTPS (preferred)

Port: Corresponding Port to connect to the SAP WD.

Path: “/sap/public/icman/ping”

Interval & Unhealthy threshold: Default values.

Icman/ping is a way to ensure that SAP web dispatcher is successfully connected to backend SAP S/4 HANA or SAP ERP based application servers. This check is also part of the basic configuration check of SAP web dispatcher using “sapwebdisp pf=<profile> -checkconfig”.

We are avoiding TCP port-based health probe as it will not ensure that ILB connection will be redirected to WD only when connection between SAP WD and S/4 HANA OR ERP Application is working.

Note : As per SAP Note 2941769, we need to set SAP web dispatcher parameter wdisp/filter_internal_uris=FALSE.  Also need to verify if icman ping URL is working for both the SAP Web dispatchers with their actual hostnames.

  • Load balancing Rule:

Load balancing rules should be set like below screen shot.

    • HA Port is selected,
    • Session Persistence is set to “Client IP and protocol”,
    • Idle timeout is set to maximum
    • TCP reset is disabled
    • Floating IP is disabled

Further details on settings for Load balancing rule.

HA Port: High availability (HA) ports is a type of load balancing rule that provides an easy way to load-balance all flows that arrive on all ports of an internal Standard Load Balancer. The load-balancing decision is made per flow. This action is based on the following five-tuple connection: source IP address, source port, destination IP address, destination port, and protocol. Azure Standard Load Balancer helps you load-balance all protocol flows on all ports simultaneously when you’re using an internal Load Balancer via HA Ports. Please refer to this link for more details.

Idle Timeout and TCP reset:

Load Balancer’s default behavior is to silently drop flows when the idle timeout of a flow is reached. Enabling this TCP reset feature will cause Load Balancer to send bidirectional TCP Resets (TCP RST packet) on idle timeout. This will inform your application endpoints that the connection has timed out and is no longer usable.

By default, Idle timeout is set to 4 minutes. If a period of inactivity is longer than the timeout value, there’s no guarantee that the TCP or HTTP session is maintained between the client and your cloud service. A common practice is to use a TCP keep-alive. This practice keeps the connection active for a longer period. Packets are sent during periods of inactivity on the connection. Keep-alive packets ensure the idle timeout value isn’t reached and the connection is maintained for a long period.

Please refer to this link for more details.

 Floating IP:

When Floating IP is enabled, Azure changes the IP address mapping to the Frontend IP address of the Load Balancer frontend instead of backend instance’s IP.

Without Floating IP, Azure exposes the VM instances’ IP. Enabling Floating IP changes the IP address mapping to the Frontend IP of the load Balancer to allow for additional flexibility.

In addition to the rule configuration, you must also configure your virtual machine’s Guest OS in order to leverage Floating IP.

Please refer to this link for more details.

Failover Testing for the parallel SAP WD setup

Failover testing needs to be performed for the SAP WD environment.

There are mainly 2 kinds of HA testing that need to be performed:

Planned – In case of planned unavailability of the one the node of the pair, this can be tested by stopping one of the SAP WD service or stopping one of the VM and verifying that SAP WD services are available to users.

Unplanned – This can be tested by crashing any one of the VMs and removing the storage from VMs. In Windows environment, VM crashing can be achieved by the tool ‘notmyfault’. SAP WD services should continue to work uninterrupted for the end user which is accessing the SAP WD using virtual hostname/FQDN.

The Failover Cluster (active/passive) based HA SAP Web Dispatcher Setup (for Windows)

In the failover cluster based setup, SAP WD is managed by Operating System based cluster to provide the high availability. In case of unavailability of primary SAP WD, cluster will initiate the failover the SAP WD services to secondary node and it will become new primary. Users will connect to SAP WD URLs using virtual hostname (FQDN)/ IP address as defined in the ILB.

ILB will redirect all the connections to the primary SAP WD and monitor the primary VMs status using health probe. OS cluster needs to be aware of Health probe port and will keep the health probe active only on primary host.

As described in the  SAP Note 2884073 – Installation of SAP Web Dispatcher in Windows Failover Cluster and the installation guide attached to this note, SAP WD need to installed on both the VMs with same SID and common ‘sapmnt’ hosted in fileshare or shared disk. Please follow the installation guide for the SAP WD setup and cluster configuration.

For a clustered Web Dispatcher configuration, you need the following components: –

  • A Windows Failover Cluster with at least 2 cluster nodes, running on Windows 2012 or higher
  • A high availability share “sapmnt” on a Windows or Linux host, or on a NAS storage system
  • A DNS A-record name is used for the clustered Web Dispatcher instance. We need to define the virtual IP in the ILB for DNS A-Record.

ILB Setup

  • Front-end IP: Define the virtual IP for connecting to the highly available WD pair. Map the virtual IP to hostname (FQDN) in AD/DNS.
  • Backend Pool: Define/include the VM hosts in which individual web dispatchers are running.
  • Health Probe:

In health probe, you can define like following

Protocol: TCP

Port: Any unused TCP port. Later we will configure this probe port in the Windows Cluster.

Note: TCP Port numbers range from 0 to 65535, but only port numbers 0 to 1023 are reserved for privileged services and designated as well-known ports.

Interval & Unhealthy threshold: Default values.

  • Load balancing Rules:

Load balancing rules should be set like below screen shot.

    • HA Port is selected,
    • Session Persistence is set to “none”,
    • Idle timeout is set to maximum
    • TCP reset is disabled
    • Floating IP is enabled

Detailed description of these ILB parameters is described above in the parallel SAP WD setup scenario.

Probe port configuration in Windows Cluster

  • Check the current probe port (using PowerShell command) of the cluster resource which will be ‘0’ as its yet to be defined.

Get-ClusterResource “IP Address xx.xx.xx.xx” | Get-ClusterParameter

Note: In the above command we need to specify the IP resource name within the Cluster Role.

  • Run the PowerShell commands to set the probe port

$ClusterNetworkName = “Cluster Network 1″

 $IPResourceName = “IP Address xx.xx.xx.xx”

$ILBIP = “xx.xx.xx.xx”

 Import-Module FailoverClusters

 Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{Address=$ILBIP;ProbePort=<probeport>;SubnetMask=”255.255.255.255″;Network=$ClusterNetworkName;EnableDhcp=0}

 Note: Define the ILB frontend IP (virtual IP) in the parameter “$ILBIP” 

  • Restart the cluster resource.
  • Recheck the current probe port of the cluster resource.
  • Verify the Virtual IP connections are working and ILB ‘insights’ section is showing the success status. 

Failover Cluster Testing

Failover testing needs to be performed for the SAP WD environment.

There are mainly 2 kinds of HA testing that needs to be performed:

Planned – In case of planned unavailability of the one the node of the cluster pair. This can be tested by moving the cluster resources from the primary node to secondary and verifying that SAP services are available to users.

Unplanned – This can be tested by crashing the VMs and removing the storage from VMs. In windows environment, VM crashing can be achieved by the tool ‘notmyfault’. Windows cluster will failover the resources from primary node to secondary and SAP WD services should continue to work uninterrupted.

Disaster Recovery Setup of SAP Web Dispatcher

DR setup needs to be done in another Azure region, for either of the HA setup scenario (the parallel or the cluster setup) in primary region can be achieved by configuring Azure Site recovery of the one of the SAP WD in the primary region.

During the DR activation, we can create the standard ILB in the DR region as its created in the primary region with similar settings and adjust the DNS to map the SAP WD virtual hostname/FQDN to the new front-end IP of the ILB.  ILB backend pool will contain the single SAP WD running in the DR region.

In case of the cluster setup, windows cluster role configuration needs to be updated with new virtual IP defined the ILB and then cluster role can be started successfully.

Scalability, throughput, Security, performance objective

  • SAP Web Dispatcher can be protected from Denial of Service (DoS) attacks by limiting the number of connections from a single IP address. For every network connection that is established, the number of existing connections per client IP address is checked.

Profile parameter icm/client_ip_connection_limit and icm/max_conn should be carefully configured to protect the SAP Web Dispatcher from DoS attacks. Please refer to this link for more details.

  • Fending Off Slowloris Attacks – Slowloris are a special type of Denial of Service (DoS) attacks used for blocking the availability of a Web server/application server. With a slowloris attack a large number of requests are sent in parallel with a very low data transfer rate to the application server.

The three sub parameters should be implemented in parameter icm/server_port. You can use them to link specific conditions to the data rate of a request. Please refer to this link for more details.

  • HTTP/2 Support: HTTP/1.0 and HTTP/1.1 do have some disadvantages for modern applications, in particular with respect to performance in wide-area networks. To improve these problems, their successor RFC 7540 HTTP/2 has been implemented. As of kernel version 7.49, SAP Web Dispatcher and Internet Communication Manager support the HTTP/2 protocol as the protocol converter.

For SAP Web Dispatcher connection, HTTP/2 support can be activated or deactivated with parameter icm/HTTP/support_http2. We can configure the communication between SAP Web Dispatcher and the back end with parameter wdisp/support_http2_to_backend. Please refer to this link for more details.

  • With reference to the maximum data throughput that can be achieved via an Azure Load Balancer, we need to know that Azure LB is a pass-through network load balancer, throughput limitations are dictated by the type of virtual machine used in the backend pool. Please refer to this FAQ link for ILB.

System Monitoring and Alert Management

It is critical to monitor the Azure Load balancer, SAP WD VMs and all the related Azure resources for their availability, performance, and operation.

  • Monitoring and alert configuration of Standard Load Balancer are described in this link. We can find the details of the metrics which must be monitored using Azure Monitor and Resource Health to ensure that we can detect any faults.

Azure Load Balancer provides multi-dimensional metrics via the Azure Metrics in the Azure portal, and it helps you get real-time diagnostic insights into your load balancer resources.

The various load balancer configurations provide the following metrics:

Data path availability: A standard load balancer continuously uses the data path from within a region to the load balancer frontend, to the network that supports your VM.

Health probe status: This metric provides an aggregate or per-endpoint filtered view of each instance endpoint in the load balancer pool. You can see how load balancer views the health of your application, as indicated by your health probe configuration.

Byte count: A standard load balancer reports the data processed per front end.

Packet count: A standard load balancer reports the packets processed per front end.

  • From the Insights blade of your Load Balancer, you can select More Detailed Metrics to view a pre-configured Azure Monitor Workbook containing metrics visuals relevant to specific aspects of your Load Balancer.

The dashboard tabs currently available are:

    • Overview
    • Frontend and Backend Availability
    • Data Throughput
    • Flow Distribution
    • Connection Monitors
    • Metric Definitions
  • We also need to prepare monitoring strategy and scope for Subscription, VMs, storage, network, backup and other resources deployed in Azure for SAP environment including SAP Web Dispatcher. Recommend to start the design using the following link.

 References

Run SAP NetWeaver in Windows on Azure – Azure Architecture Center | Microsoft Docs

High Availability of the SAP Web Dispatcher – SAP Help Portal

SAP Note 2884073 – Installation of SAP Web Dispatcher in Windows Failover Cluster

SAP Note 2941769 – Web Dispatcher: external access to /sap/public/icman/ping returns 403 Forbidden

SAP Note 908097 – SAP Web Dispatcher: Release, Installation, Patches, Documentation

ASCS Instance with Integrated SAP Web Dispatcher – SAP Help Portal

Running the Configuration Check (sap.com)

Azure Load Balancer components | Microsoft Docs

Configure Azure Load Balancer distribution mode – Azure Load Balancer | Microsoft Docs

High availability ports overview in Azure – Azure Load Balancer | Microsoft Docs

Manage rules for Azure Load Balancer – Azure portal | Microsoft Docs

Azure Load Balancer Floating IP configuration | Microsoft Docs

Azure Load Balancer SKUs | Microsoft Docs

Frequently asked questions – Azure Load Balancer | Microsoft Docs

Azure subscription limits and quotas – Azure Resource Manager | Microsoft Docs

Insights for Azure Load Balancer | Microsoft Docs

Diagnostics with metrics, alerts, and resource health – Azure Load Balancer | Microsoft Docs

SAP Web Dispatcher/ICM: Limit Connections per Client IP – SAP Help Portal

Fending Off Slowloris Attacks – SAP Help Portal

HTTP/2 Support – SAP Help Portal