Share via

How to use Microsoft Azure Traffic Manager for Web portals hosted in multiple on-premises datacenters

  • Article

Introduction

Microsoft Azure has an ATM (Azure Traffic Manager) feature that is capable to manage traffic Load Balancing and Failovering for Endpoints within Microsoft Azure Regions. Combining this feature and IIS Reverse-Proxy allows implementing an intelligent management and caching of traffic for Web portals hosted in multiple on-premise datacenters. This Wiki shares the way to achieve that.

Scenario

CONTOSO is a company that has a Business Critical Web application hosted in one of their Datacenters. The Web application is accessible from internet and CONTOSO would like to increase its availability by making it available from a second Datacenter. When one of the Datacenters is not available, the traffic should be redirected to the other one for the continuity of the service. Multiple Web servers will be hosted within each Datacenter and two on-premise load balancers will be managing the load locally for each Datacenter. CONTOSO would like then to have a Global Load Balancer that is capable to load balance the traffic between the two Datacenters and initiate a failover of traffic when one of them is not available. The Global Load Balancer should redirect the clients to the “closest” datacenter. CONTOSO would like also to implement frontal caching servers for Web caching of the Web application.

CONTOSO have implemented the required Web servers in both Datacenters and called a Microsoft Partner to achieve the global load balancing requirements.

Below is a figure for the current setup of the Web servers within the two Datacenters:

Solution

The solution would combine the use of two features:

  • ATM (Azure Traffic Manager)
  • IIS Reverse-Proxy

This could be achieved if the following is done:

  • The Web Application is published in both on-premise Datacenters with different DNS names: In our case, it will be appdc1.contoso.com for North Europe Datacenter and appdc2.contoso.com for East Asia Datacenter
  • (At least) two Windows Server VMs running IIS are provisioned in Microsoft Azure. The VMs should be hosted in different Azure Regions: In our case, a VM was provisioned in Azure North Europe Region and another one was provisioned in Azure East Asia Region
  • The VM hosted in Azure North Europe Datacenters will work as a Reverse-Proxy for appdc1.contoso.com while the VM hosted in Azure East Asia Datacenters will work as a Reverse-Proxy for appdc2.contoso.com
  • The Azure VMs will be configured for Web caching
  • WATM will be configured for Load Balancing between Azure VMs using performance method (Clients will connect to the “closest” Reverse Proxy)

Below is a figure representing the target setup:

Implementation

In our case, we have provisioned two Azure VMs running Windows Server 2012 R2 with IIS 8.5. Below are the VM details:

Server

Location

Public IP address

Contosovm001.cloudapp.net

North Europe

23.100.63.57

Contosovm002.cloudapp.net

East Asia

23.100.92.85

Once done, we have configured WATM load balancing to use the following parameters:

  • contosolb01.trafficmanager.net is the DNS name of the traffic manager

  • Contosovm001.cloudapp.net and Contosovm002.cloudapp.net were configured as Endpoints

  • Performance was used as load balancing method

We have also installed IIS ARR (Application Request Routing) on the provisioned Azure VMs and then we have configured them as Reverse Proxies using the following method:

  • Select the IIS Website to use and then click on URL Rewrite

  • Click on Add Rule(s)

  • Select Reverse Proxy and then click on OK

  • Configure the Inbound Rules and the Outbound Rules then click on OK. In our case, we have configured the following as the server name where HTTP requests will be forwarded:
    • On Contosovm001.cloudapp.net: appdc1.contoso.com
    • On Contosovm002.cloudapp.net: appdc2.contoso.com

We have also configured IIS Application Request Routing Cache to have Web caching enabled. The IIS servers will then act as Frontal Web Caching servers.

Testing of the Implementation

To test the implementation and make sure that it works properly, we have tested the following scenarios:

Scenario 1: The Web Portal is available from all CONTOSO Datacenters

Expected behavior: The clients will be redirected to the “closest” CONTOSO datacenter.

Results of testing: WATM was redirecting the clients to “closest” IIS VM in Azure. The “closest” IIS VM will then redirect the traffic to the “closest” CONTOSO datacenter. The clients are then redirected to the “closest” CONTOSO datacenter.

The redirection of clients to the “closest” IIS VM in Azure was confirmed by using https://www.whatsmydns.net Website. Below is the screen capture for the DNS resolution received from WATM in different locations within the globe:

Scenario 2: The Web portal is available only from CONTOSO North Europe Datacenter

Expected behavior: The clients will be redirected to CONTOSO North Europe datacenter.

Results of testing: WATM was redirecting the clients to IIS VM in Azure North Europe. The VM will then redirect the traffic to CONTOSO North Europe datacenter. The clients are then redirected CONTOSO datacenter North Europe datacenter.

The redirection of clients to the IIS VM in Azure North Europe was confirmed by using https://www.whatsmydns.net Website. Below is the screen capture for the DNS resolution received from WATM in different locations within the globe:

Scenario 3: The Web portal is available only from CONTOSO East Asia Datacenter

Expected behavior: The clients will be redirected to CONTOSO East Asia datacenter.

Results of testing: WATM was redirecting the clients to IIS VM in Azure East Asia. The VM will then redirect the traffic to CONTOSO East Asia datacenter. The clients are then redirected CONTOSO datacenter East Asia datacenter.

The redirection of clients to the IIS VM in Azure East Asia was confirmed by using https://www.whatsmydns.net Website. Below is the screen capture for the DNS resolution received from WATM in different locations within the globe:

In all three scenarios, we have seen that the cache gets created on the IIS servers when the clients were accessing the Web Portal.

Conclusion

This Wiki article shared a way to implement a global load balancer with Web caching for on-premise Web portals hosted in multiple regions using Microsoft Azure. It actually combines the advantages of ATM and IIS Reverse-Proxying and Caching.