Azure Application Gateway

Introduction

Azure Application Gateway provides application-level routing and load balancing services which let you build a scalable and highly-available web front end in Azure. You control the size of the gateway and can scale your deployment based on your needs.
Application Gateway currently supports layer-7 application delivery for the following:

  • HTTP load balancing
  • Cookie-based session affinity
  • Secure Sockets Layer (SSL) offload

022116_1111_AzureApplic1.png

Demonstration Scenario

022116_1111_AzureApplic2.png
Here, in order to demonstrate the session affinity of the Azure Application Gateway load balancer without the VM scaling option. We need to setup the infrastructure in following architecture.
Here, We have two VM configure in different Cloud Services. We have chosen two cloud services to demonstrate that App Gateway load balancer is different from implicit load balancer which each cloud service has. Each cloud service have just one VM inside it. Both the VM’s are configured in the same azure virtual network, so they can talk to each other and share the same IP convention as specified in the subnet.
Then, we create Application Gateway in the same virtual network and configured to load balance between this two VM with cookie affinity.
Azure appliaction gateway will get the request from the internet of configured DNS address or public IP and would route the request to each VM in the round robin fashion. It monitors the health of the VM by probing configured port (which you specify in BackendHttpSettings section) very 30 second. If the response from these endpoint doesn’t like in 200-390 range, the endpoint is taken out from the pool this next probes happen.

Configure Azure Application Gateway

In order to configure azure application gateway for mention architecture, following are the steps

  1. Create Virtual Network in which VM needs to be placed
  2. Create two identical VM and configure it to be place in same virtual network created above
  3. Configure each VM to host ASP.NET web application and deploy the sample application on them
  4. Create Application Gateway loadbalancer and configure it to load balance the VMs
  5. Validate the application and check if the connection is persists for entire session to same machine

Steps 1

Create Virtual Network in Classic

022116_1111_AzureApplic3.png

Give a logical name,

Create Address Space : 192.168.0.0/16
Create Two Subnets :

  • 1st Subnet : 192.168.10.0/8
  • 2nd Subnet: 192.168.11.0/8

Steps 2

Create two VM’s with the Name as sbag1vm1 and sbag1vm2

022116_1111_AzureApplic4.png
During the creation of these VM,

VM were put in Virtual Network “Shabs-VirNet” which we had configured earlier

Subnet was of 192.168.0.0/24 address space which we configure while creating the Shabs-VirNet

022116_1111_AzureApplic5.png

Step 3

Each VM needs to be configure as Web server which need to host sample ASP.NET web application on it. Here, we had deployed the sample ASP.NET web application to demonstrate the use of session affinity. ASP.NET application generate session cookie everytime new request hits the server and maintains it through the lifetime of the user session on the server.

Sample app will save a counter in the session state in memory (metal love) and respond to your page refreshes with updated session data.

022116_1111_AzureApplic6.png

Step 4

Create the new Application Gateway with following powershell script.

I won’t go in details of explaining each of command in this entire powershell script, but on the whole it creates the Application Gateway with name ‘noscaleapplicationgateway’ and configure it for load balance across two VM’s

$checkGateway = Get-AzureApplicationGateway noscaleapplicationgateway
if($checkGateway -eq $null)
{
   New-AzureApplicationGateway -Name noscaleapplicationgateway -VnetName applicationgatewaynetwork -Subnets("Subnet-1")
}
Get-AzureApplicationGateway noscaleapplicationgateway
#Set Application Gateway Configuration
Set-AzureApplicationGatewayConfig -Name noscaleapplicationgateway -ConfigFile $GatewayconfigurationFilePath
#Start Gateway
Start-AzureApplicationGateway noscaleapplicationgateway
#Verify that gateway is running
Get-AzureApplicationGateway noscaleapplicationgateway

Once the Gateway starts (at which point billing also starts), the Get-AzureApplicationGateway command will return a result that looks like the following. Note the DnsName field which contains the URL which users can access to interface with the Application Gateway.

022116_1111_AzureApplic7.png

Step 5

Verify the application,  Try accessing the Application Gateway URL from different browsers to hopefully hit the different VMs that you deployed (you can keep closing and reopening browsers until you succeed). Your screen .should look similar to the following. Note that I am accessing the Application Gateway URL here.

022116_1111_AzureApplic8.png

If you view the cookies now, you would find the secret sauce that is making the Application Gateway tick.

022116_1111_AzureApplic9.png

ARRAffinity cookie contains data that helps Azure Application Gateway determine the endpoint to which it should route the request (yes it is ARR under the hood). ASP.NET_Sessionid cookie is a standard session cookie that contains session identifier.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s