SAP on Azure: Load Balancing Web Application Servers for SAP BOBI using Azure Application Gateway

[dennispadia]

Purpose

In SAP BOBI multi-instance deployment, Web Application Servers (web tier) are running on two or more hosts. To distribute user load evenly across web servers, you need a load balancer to distribute traffic between end users and web servers. In Azure, you can either use Azure Load Balancer or Azure Application Gateway to manage traffic to your web application servers.

Azure Application Gateway has some advantage (like SSL offloading, Centralize SSL management to reduce encryption and decryption overhead on server etc.) over Azure Load Balancer, which makes it suitable for load balancing traffic across web servers of SAP BI Platform.

In this blog, we will discuss on how to configure Azure Application Gateway to load balance the traffic on SAP BOBI web servers.

Overview

Azure Application Gateway (AGW) provide Application Delivery Controller (ADC) as a service which is used to help application to direct user traffic to one or more web application servers. It offer various layer 7 load balancing capabilities like TLS/SSL Offloading, Web Application Firewall (WAF), Cookie-based session affinity and others for your application(s).

In SAP BI Platform, application gateway directs application web traffic to the specified resources in a back-end pool. You assign a listeners to ports, create rules and add resources to a back-end pool.

Load balancing traffic using Azure Application Gateway

In above figure, Azure Application Gateway with private front-end IP address (10.31.3.20) act as entry point for the users, handles incoming TLS/SSL (HTTPS - TCP/443) connections, decrypt the TLS/SSL and passing on the un-encrypted request (HTTP - TCP/8080) to the servers in the back-end pool. With in-built TLS/SSL termination (a.k.a TLS/SSL Offload) feature, we just need to maintain one SSL certificate on application gateway which simplifies operations.

What is TLS/SSL Termination (a.k.a. TLS/SSL Offloading)?

SSL Termination is a process by which SSL-encrypted data traffic is decrypted (or offloaded). An SSL connection sends encrypted data between end-user’s computer and web server(s) by using a certificate for authentication. SSL termination or SSL offloading decrypts and verifies data on Azure Application Gateway instead of web server. Putting the decryption burden on the Azure Application Gateway enables the server to spend processing power on application tasks, which helps improve performance. It also simplifies the management of SSL certificates, as you just need to maintain one SSL Certificate on Azure Application Gateway, without the need to enable SSL on web servers in back-end pool.

Prerequisites

1. Separate subnet is required in your virtual network, which contain only application gateway. See more details, here.


2. If you are configuring Application Gateway to use TLS/SSL Termination, you will need certificate.NOTE: In this illustration, self-signed certificate is used. Client browsers do not trust these certificates and will warn the user that the virtual service’s certificate is not part of a trust chain. Self-signed certificates are good for testing or environments where administrators control the clients and can safely bypass the browser’s security alerts. Business workloads should never use self-signed certificates.

Configuration Steps

Create Self-Signed Certificate

On your local computer, open a Windows PowerShell window as an administrator. Run the following command to create the certificate:

New-SelfSignedCertificate `

  -certstorelocation cert:\localmachine\my `

  -dnsname azure.bobi.com

Note the thumbprint and replace it in below command

$pwd = ConvertTo-SecureString -String <your password> -Force -AsPlainText

Export-PfxCertificate `

  -cert cert:\localMachine\my\8A3C48B3D393295D3037BF5DCFB9A38039F7C8AF `

  -FilePath c:\appgwcert.pfx `

  -Password $pwd

The certificate appgwcert.pfx will be available in c:\ drive

Create Application Gateway

Azure Portal > Create a Resource > Search "Application Gateway"



Select appropriate tier for your Application Gateway. For more detail, refer this documentation.

NOTE: "appgateway-subnet" is a separate subnet for Application Gateway created in virtual network dp-bobi-vnet. You cannot deploy any other thing in application gateway subnet (Check for more details, here).

Usually SAP System are accessed inside company network, so keeping that in mind we will used Frontend IP address type as private. You can use pubic if you want your BI application to be accessed via Internet.

Click on "Add a backend pool".

Add all the web server of SAP BOBI Platform to which you want user traffic to be distributed. You can also add the virtual machine later as well.

Click "Next" and now we will add routing rules

Click on "Add a routing rules".

Application gateway will listen to HTTPS (TCP/443) protocol. Upload the certificate file which you have generated. Password will be the one which I have provided while creating self-signed certificate.

NOTE: Certificate is mandatory if you are configuring listener on HTTPS protocol.

Click on the "Backend targets" tab where we will insert back end information

Backend target: Select the backend target pool which we had generated in above step

HTTP settings: Add new. 

In "Add a HTTP setting", we will select backend protocol and port.

As mentioned earlier in this blog, application gateway support SSL termination which means we can HTTP protocol for our web servers in backend pool even when incoming request is listened on HTTPS protocol. Application gateway will perform all the encryption/decryption of user request. This simplifies maintenance work for operation team, as they need to maintain only one certificate i.e. on application gateway.

Cookie-based affinity: Enable

Once listener and backend targets are defined, click on "Add".

Cross verify the details and click on "Create"

It takes around 20-25 minutes to provision application gateway.

Validation

Once the Azure Application Gateway is deployed, you can check CMC and BI Launch Pad application using new URL

https://10.31.3.20/BOE/CMC

https://10.31.3.20/BOE/BI

To accept the security warning if you used a self-signed certificate, select Details (or Advanced on Chrome) and then go on to the webpage:

NOTE: As mentioned earlier browsers do not trust self signed certificates and will warn the user that the virtual service’s certificate is not part of a trust chain. Self-signed certificates are good for testing or environments where administrators control the clients and can safely bypass the browser’s security alerts. Business workloads should never use self-signed certificates.

Now check BI Launch Pad: https://10.31.3.20/BOE/BI

On placing web server behind any load balancer, you will get below error when you login to BI Launchpad

Error: "Logon failed for RESTful Web Services. Contact system administrator."

Follow SAP Note: 2576124 - Error "Logon failed for RESTful Web Services. Contact system administrator." while logging... for resolution

Application Gateway provides high availability at host level which means if one of the host from backend pool in application gateway goes down, traffic will be routed to other host(s) that are part of backend pool. Existing user session will be disconnected from the host that goes down and user need to login again in order to establish session.

So to address this issue, you can set Tomcat clustering which replicate session across all the hosts that are part of cluster. So if one of your web server goes down, application gateway route traffic to other host and tomcat cluster make sure that the user session of the failed host remain intact. You can configure tomcat clustering in Azure by following this article: SAP on Azure: Tomcat Clustering using Static Membership for SAP BusinessObjects BI Platform

You can have seamless user experience if you have tomcat clustering setup behind any load balancer (Azure Load Balancer or Application Gateway)

Testing Application Gateway

IMPORTANT: In distributed landscape, where you have separate web servers you need to perform test cases on web server hosts that are part of backend pool in application gateway, not BI application. 

To simplify the test case we will first stop server azusbosl2 and make sure that our connection to CMC application happens through web server running on azusbosl1.

In this illustration, tomcat and BI applications are running on both hosts (azusbosl1 and azusbosl2). Application Gateway load balance traffic across web server not BI application. But as tomcat and BI application running on same host, so if one of the server goes down, tomcat and BI application will use other host.

As we shutdown azusbosl2, user session is established using tomcat and CMS service running on azusbosl1. During application gateway configuration we have enabled Cookie-based affinity which means application gateway direct traffic to the same server where user session is established.

Now we will start tomcat and BI application on azusbosl2. 

Once tomcat and BI application is started on azusbosl2, we will stop azusbosl1 host

Now my request is routed to azusbosl1.

NOTE: If you don't have tomcat cluster setup, you might need to login again as user session is ended along with host crash. So it is important that you configure tomcat clustering to keep user session in case of host failure.

References

• Tutorial: Configure an application gateway with TLS termination using the Azure portal


• 2576124 - Error "Logon failed for RESTful Web Services. Contact system administrator." while logging...

Regards,

Dennis Padia