I have a scenario perfect for a Layer-7 Load Balancer / Reverse Proxy:
- Multiple web server clusters to be routed under one URL hierarchy (one domain name)
- Redirect HTTP traffic to the same URL on HTTPS
- Have reverse proxy performing SSL termination (or SSL offloading), i.e. accepting HTTPS but routing to underlying servers using HTTP
On paper, Azure Application Gateway can do all of those. Let’s fine out in practice.
Azure Application Gateway Concepts
From the documentation:
Application Gateway is a layer-7 load balancer. It provides failover, performance-routing HTTP requests between different servers, whether they are on the cloud or on-premises. Application Gateway provides many Application Delivery Controller (ADC) features including HTTP load balancing, cookie-based session affinity, Secure Sockets Layer (SSL) offload, custom health probes, support for multi-site, and many others.
Before we get into the meat of it, there are a bunch of concepts Application Gateway uses and we need to understand:
- Back-end server pool: The list of IP addresses of the back-end servers. The IP addresses listed should either belong to the virtual network subnet or should be a public IP/VIP.
- Back-end server pool settings: Every pool has settings like port, protocol, and cookie-based affinity. These settings are tied to a pool and are applied to all servers within the pool.
- Front-end port: This port is the public port that is opened on the application gateway. Traffic hits this port, and then gets redirected to one of the back-end servers.
- Listener: The listener has a front-end port, a protocol (Http or Https, these values are case-sensitive), and the SSL certificate name (if configuring SSL offload).
- Rule: The rule binds the listener, the back-end server pool and defines which back-end server pool the traffic should be directed to when it hits a particular listener.
On top of those, we should probably add probes that are associated to a back-end pool to determine its health.
Proof of Concept
As a proof of concept, we’re going to implement the following:
We use Windows Virtual Machine Scale Sets (VMSS) for back-end servers.
In a production setup, we would go for exposing the port 443 on the web, but for a POC, this should be sufficient.
As of this writing, there are no feature to allow automatic redirection from port 80 to port 443. Usually, for public web site, we want to redirect users to HTTPS. This could be achieve by having one of the VM scale set implementing the redirection and routing HTTP traffic to it.
We’ve published the ARM template on GitHub.
First, let’s look at the visualization.
The template is split within 4 files:
- azuredeploy.json, the master ARM template. It simply references the others and passes parameters around.
- network.json, responsible for the virtual network and Network Security Groups
- app-gateway.json, responsible for the Azure Application Gateway and its public IP
- vmss.json, responsible for VM scale set, a public IP and a public load balancer ; this template is invoked 3 times with 3 different set of parameters to create the 3 VM scale sets
We’ve configured the VMSS to have public IPs. It is quite typical to want to connect directly to a back-end servers while testing. We also optionally open the VMSS to RDP traffic ; this is controlled by the ARM template’s parameter RDP Rule (Allow, Deny).
Here are the following ARM template parameters.
|Public DNS Prefix||The DNS suffix for each VMSS public IP.
They are then suffixed by ‘a’, ‘b’ & ‘c’.
|RDP Rule||Switch allowing or not allowing RDP network traffic to reach VMSS from public IPs.|
|Cookie Based Affinity||Switch enabling / disabling cookie based affinity on the Application Gateway.|
|VNET Name||Name of the Virtual Network (default to VNet).|
|VNET IP Prefix||Prefix of the IP range for the VNET (default to 10.0.0).|
|VM Admin Name||Local user account for administrator on all the VMs in all VMSS (default to vmssadmin).|
|VM Admin Password||Password for the VM Admin (same for all VMs of all VMSS).|
|Instance Count||Number of VMs in each VMSS.|
|VM Size||SKU of the VMs for the VMSS (default to Standard DS2-v2).|
An important characteristic of URL-based routing is that requests are routed to back-end servers without alteration.
This is important. It means that /a/ on the Application Gateway is mapped to /a/ on the Web Server. It isn’t mapped to /, which seems more intuitive as that would seem like the root of the ‘a’ web servers. This is because URL-base routing can be more general than just defining suffix.
This proof of concept gives a fully functional example of Azure Application Gateway using URL-based routing.
This is a great showcase for Application Gateway as it can then reverse proxy all traffic while keeping user affinity using cookies.