The document outlines the importance of high availability and automation for SAP on Azure, emphasizing the need for a platform-agnostic approach to cloud solutions. It details the configuration of Azure Internal Load Balancers and Web Dispatchers to ensure effective load balancing and fault protection, while highlighting best practices for maintaining server health and security. Future assurance and the avoidance of bleeding-edge technologies are recommended for long-term operational success and interoperability between cloud providers.

1. SAP on Azure Web Dispatcher High Availability

2. Automation Core
• Technology improvements mean computing tasks previously requiring interaction with people, can be fully automated.
• Automation brings repeatability, reduced error rates, easy scalability of service provision.
Platform Agnostic
• Future interoperability and open standards will mean businesses can swap easily between cloud providers.
• It is key that solutions are designed to operate in such a platform agnostic manner outside the bounds of normal technical
architecture design (i.e. no fixed O/S choices or fixed DB platforms).
Established Technological Principals
• Solutions today, should be built using already established technological principals.
• Using bleeding edge rarely produces the perceived benefits in places such as core business systems, without significant
buy-in from business leaders.
• Pre-empting standards not already widely adopted, could produce a “Beta-Max” scenario.
Future Assurance
• Technology solutions should deliver for a minimum timeframe within the context of the lifecycle of the related business system.
• Example: Re-writing scripts during any platform migration should not just use the coolest scripting language, they should use a commonly known
language widely used and understood.
Drivers

3. • Acts as a reverse proxy for HTTP to/from SAP/non-SAP systems.
• Required when HA setup of a Web Server is implemented (i.e. multi-node
active/active setup).
• Required when load balancing HTTP traffic to back-end SAP systems.
• Supports 3 different load balancing methods.
• Supports request rewriting through modification handlers.
• Supports serving static content.
• Supports SSL termination and end-to-end SSL pass-through.
• Can also route non-HTTP traffic in RAW mode.
About the Web Dispatcher

4. • Primarily you need to protect against Azure underlying physical host failures.
They DO happen!
• Secondarily, provision for server downtime during Microsoft physical host
patching/maintenance. There is no magic that moves your VM to another Azure
physical host (not like vMotion).
• To protect your system:
*You* must provision duplicate services into Azure Availability Sets.
For the SAP Web Dispatcher, this means you need at least two virtual machines
in one Azure Availability Set with the Web Dispatcher running on both servers
in active/active (parallel) mode.
About High Availability on Azure

5. • A logical grouping of your virtual machines.
• Servers within a group are bound not to be running on the same underlying
physical host at the same time (like anti-affinity rules).
• Availability Sets are assigned at Virtual Machine creation only.
Azure Subscription(s)
Web Dispatcher
Server Primary
Web Dispatcher
Server Secondary
Azure Availability Set #1
Azure Hyper-V
Host #1
Azure Hyper-V
Host #2
About Azure Availability Sets

6. • A software defined load balancer with port routing in SKU basic or standard.
• The ILB SKU must match the SKU of back-end pool member VMs & IP resources.
• Uses probes (like a ping) to test and route network traffic to available back-end
members.
• You are billed for an ILB once you’ve created one
• An ILB has an initial cost, plus potentially a cost for each of the ports you assign to it.
• You can map to any IP address on a NIC of a back-end member.
• You define an IP address for the ILB.
• You define the front-end (listen) ports.
• You define the back-end pools of virtual machines.
• You define a probe port and protocol for testing availability of back-end members.
• You define flow rules that map front-end ports to back-end pools and destination
ports.
• Back-end pool members cannot talk to themselves via the ILB (ILB is invisible to
them)!
About Azure Internal Load Balancers

7. Azure Subscription(s)
Azure
Internal
Load Balancer
Web Dispatcher
Primary
ILB IP: 10.0.0.1 (Web Dispatcher IP)
Web Dispatcher Ports: 80, 443 etc
IP: 10.0.0.3
IP: 10.0.0.4
Web Dispatcher
Secondary
Front-End IP & “listen” Ports
Back-End Pool Probe Ports
NIC
NIC
Flow Rules
(port mappings)
Probes determine
health status for
routing to back-end
pool members.
A back-end member cannot talk to itself via the ILB !
There are 2x SKUs:
STANDARD or BASIC.
For STANDARD SKU IP addresses
you must have STANDARD ILB.
About Azure Internal Load Balancers

8. Azure Subscription(s)
WDisp
Primary
Azure ILB:
http://mycorp.int.net:80
https://mycorp.int.net:443
WDisp
Secondary
http://host1.int.net:8090
http://host1.int.net:44390
http://host2.int.net:8090
https://host2.int.net:44390
HA NFS
sapmnt PSE
Backend SAP
System ASCS
(HA)
ICM
Table: HTTPURLLOC
https 443 mycorp.int.net
Param:
wdisp/handle_webdisp_ap_header
Sample Web Dispatcher Architecture

9. • DNS is key.
• ILB fronts the Web Dispatchers in active/active setup with a single PSE
containing the SSL cert(s).
• ILB has front-end ports listening on tcp/80 and tcp/443 (well known and
probably firewall friendly).
• ILB routes to backend Web Dispatcher VMs on port 80## and 443##.
• Administrative access to Web Dispatcher is via host:443## and not via ILB (more
secure).
• In NetWeaver ABAP AS the HTTPURLLOC table should be configured to ensure
all URLs generated in the ABAP AS are prefixed with the ILB hostname and IP.
• In Web Dispatcher the parameter “wdisp/handle_webdisp_ap_header” needs
configuring to ensure correct ports are advertised in HTTP headers sent to
backend SAP system.
Sample Web Dispatcher Architecture

10. • Since Web Dispatcher is not listening on ports <1024 no external bind is required
(better security).
• Co-hosting of the Web Dispatcher on the SAP ASCS/SCS is possible but will require
some additional service IP addresses adding to the ILB to enable tcp routing to the
message server (can’t go via the ILB from a back-end pool member!).
• Co-hosting of the Web Dispatcher using 1 single ILB but different back-end VMs is
not ideal due to mixing application architectural layers (and security in-depth).
• NetWeaver table HTTPURLLOC is truncated emptied in the target client of a SAP
local client copy!
• Secure the Web Dispatcher admin URL behind specific IP addresses and ensure it is
only reachable via HTTPS. It could be on a different HTTPS port not reached via the
ILB.
Points to Note

11. • Protection of the SAP Web Dispatcher from faults is critical.
Provisioning for Azure physical host maintenance is critical.
• Apart from a few specific areas, HA of the SAP Web Dispatcher in Azure is
almost the same as on-premise, but with an Azure twist (the ILB).
• Correct use of the ILB and emphasizing the architectural layout is important for
security and correct operation of the Wdisp within the realms of HTTP (AP
access ports is an example).
Conclusion

12. Microsoft Docs:
• Azure virtual machine high availability for SAP NetWeaver:
https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/sap-
high-availability-guide
• Azure Load Balancer Overview: https://docs.microsoft.com/en-us/azure/load-
balancer/load-balancer-overview
• Reference architecture: https://docs.microsoft.com/en-
us/azure/architecture/reference-architectures/sap/sap-netweaver
SAP Docs/Notes:
• SAP Web Dispatcher 7.5
• SAP Web Dispatcher Parameters
References

13. Thank You