One of the most challenging aspects of creating a disaster recovery environment was having a quick failover to a website that exists in another datacenter.  These failover instances usually contained stale code, the hardware for the environment was expensive and  rarely, if ever utilized and when we tried to failover to the DR it rarely worked.  There was a lot of false hope placed on these expensive DR solutions that, IMO were not worth the investment.  Maybe things have gotten better over time, but this was my experience.  With the introduction of Traffic Manager into Microsoft Azure Web Sites (MAWS) you can now have web sites in different Regions used as a failover instance or as a way to manage additional load, if the scaling capabilities of an existing MAWS is too low to meet your needs.

There are numerous redundancies built in to the Microsoft Azure Web Site (MAWS) platform.  Too many to mention and many I shouldn’t mention because it’s intellectual property.  One which I do believe to be public is the concept of Regions and Stamps.  Regions,
for example West Europe, North Europe, EastUS, etc… contain stamps which you can find embedded into the FTP address on the DASHBOARD page for the given MAWS.  For example, WAWS-PROD-CH1-001. WAWS-PROD-BLU-003, etc…  The existence of
the stamp helps isolate issues that happen within a stamp and keep them from impacting other stamps in the same Region, there are multiple stamps in a region/datacenter.  But what happens if there is a problem in a datacenter or on the stamp where your MAWS is hosted?  At the moment you cannot choose which stamp your MAWS is created on, you can’t move your MAWS to another stamp, nor can you load balance between multiple stamps in the same region.

The remainder of this article discusses how I implemented Traffic Manager on some of my test Standard mode MAWS.  Traffic Manager is only available with Standard mode MAWS.

First, click on the Traffic Manager item from within the Microsoft Azure management console as shown in Figure 1.  Notice that it lists the name, status, load balancing method, subscription and the DNS name, which is used for accessing the traffic manager.  During my testing I experienced 4 different status types, as shown in Table 1.

Figure 1, Microsoft Azure Traffic Manager with Web Sites

If you ever see Degraded as the status, you might want to check out this link for some troubleshooting tips. 

Status types

Description

Disabled

The traffic manager is created but   not configured with any endpoints

Degraded

One or more of the endpoints configured in the traffic manager is not responding as expected

Online

The traffic manager is enabled and the endpoints are responding as expected

Inactive

The traffic manager is enabled but there are no endpoints configured

Table 1, Traffic Manager status types

To create a new traffic manager, click on the NEW button on the bottom left of the window and the wizard is opened shown in Figure 2.  Enter in a traffic manager name and select the load balancing method described in Table 2.

Load Balancing Method

Description

Performance

When the performance is bad in one of the endpoints, the traffic manager will stop directing traffic to it.  The constraints are not known at this moment.

Round Robin

Balance the requests evenly across the configured endpoints

Failover

Requests are redirected from an non-functional endpoint to a working instance

 Table 2, Traffic Manager load balancing methods

Figure 2, Create a traffic manager for Microsoft Azure Web Sites

Once created, click on the ENDPOINTS page as shown in Figure 3 and add an endpoint.

Figure 3, Configuring traffic manager for Microsoft Azure Web Sites

Once you click on the ADD ENDPOINTS link or the ADD button at the bottom middle, the window shown in Figure 4 is rendered.  Notice that you can select either Cloud Service or Web Site.  As this article is about Microsoft Azure Web Sites, select the Web Site value from the drop-down.  It is also important to state that only web sites running in Standard mode can be added as an endpoint.

Figure 4, Adding endpoints to traffic manager for Microsoft Azure Web Sites

Notice that I have multiple Web Sites running in Standard mode.  The point and what I am after here is load balancing and failover capabilities for my web site.  Therefore, I’d expect the SELECTED ENDPOINTS to have the same code/same web site and that the web sites are located in different regions like East US, North Central US, North Europe, West Europe, etc…  Configuring a traffic manager to balance load across different web sites or same web sites in the same region, would not be a recommended usage of traffic manager, IMO.  Select the check mark to save the endpoints to the traffic manager.  Once selected you are returned to the ENDPOINT page where the endpoints get verified, as shown in Figure 5.

Figure 5, validating traffic manager endpoints on Microsoft Azure Web Sites

Once the endpoints validate correctly, the status is updated accordingly as shown via Figure 6.

Figure 6, traffic manager status on the Microsoft Azure Web Site console

Notice that when the validation was completed I had one MAWS in Stopped status and another in Degraded.  For the MAWS in Stopped, I checked the web site and saw it was indeed running, I recycled it and then disabled and re-enabled it which triggered another validation process which returned again as unsuccessful.  What happened was that I had that MAWS in Standard mode when I added it, as this is the only MAWS mode which can be added, but then later scaled down to Basic.  I scaled back to Standard and that got the traffic manager endpoint for that MAWS running again.  As for the MAWS with a Degraded status, that one took a minute to figure out.  It turned out that I had placed a URL Rewrite rule on the web site the forced all traffic to it to be HTTPS.  Turns out the ENDPOINT didn’t like that.

To resolve the issue I navigated to the CONFIGURE page and changed the PROTOCOL from HTTP to HTTPS as illustrated in Figure 7.

Figure 7, change traffic manager protocol with Microsoft Azure Web Sites

One point I’d like to make is the RELATIVE PATH AND FILE NAME text box.  AFAIK a basic traffic manager endpoint configuration does something like a ping, just to see if the web site responds which might not be everything you need.  What this textbox provides is the ability for you to write a page that checks, for example database connections, services responsiveness, transaction validation, ext…  So write a page that performs those activities and place the file into the textbox.  Then you can direct traffic when your web site is running nicely versus just being up.

And once I solved all the small issues, the traffic manager is running and everything shows green and is working, as illustrated in Figure 8.

Figure 8, traffic manager configuration in Microsoft Azure Web Sites

When a MAWS is added to a traffic manager, a URL is mapped to the MAWS which can be seen on the CONFIGURE tab for the traffic manager endpoint, as shown in Figure 9.

Figure 9, traffic manager domain name added to Microsoft Azure Web Sites

NOTE: It is possible to map your custom domain to the traffic manager domain, but that is outside the scope of this article. Perhaps I will write about that at some point later.