As some of you may already be aware, the Microsoft Azure cloud platform provides a service called Traffic Manager. Traffic Manager is a DNS-based load balancing service, and helps to ensure application high availability, by offering three profiles types (also known as “load balancing methods”):
- Performance – points DNS clients to the lowest-latency cloud resource endpoint
- Round Robin – responds to DNS clients with a rotating list of configured cloud resource endpoints
- Failover – responds to DNS clients with a primary cloud resource endpoint, but will failover to alternate endpoints if primary is unavailable
Tweet this article!!
— Trevor Sullivan (@pcgeek86) February 26, 2015
Traffic Manager Architecture
The basic architecture of Traffic Manager looks like the following diagram. A Traffic Manager Profile is the top-level object that is created in an Azure subscription. Each Traffic Manager Profile contains references to one or more Endpoints. Each of the Endpoints points to a DNS name, such as an Azure Website, Azure Cloud Service, or external, custom DNS record. The Traffic Manager Profile can be configured as any one of the three aforementioned profile types.
Let’s say that you want to ensure the highest level of performance for your users globally, for your website. Your website is already being hosted in two Azure or non-Azure locations: West US and East Asia. You would perform the following steps:
- Create a Traffic Manager Profile (eg. trevor.trafficmanager.net)
- Configure the Profile for the Performance profile type (load balancing method)
- Add two Endpoints to the Traffic Manager Profile
- Create a custom DNS CNAME record that points to your Traffic Manager DNS name (eg. trevorsullivan.net –> trevor.trafficmanager.net)
Once you’ve completed these steps, you would be able to point all of your global clients to trevorsullivan.net and they would automatically be pointed to their nearest website location. The Performance load balancing method automatically ensures that clients request the endpoint with the best performance.
But what happens if one of your Traffic Manager Endpoints goes offline, and is changed to the Degraded state? Well, we know from the documentation for Traffic Manager, that the monitoring service is querying each Endpoint for a HTTP status code of 200, with a timeout of 10 seconds. Therefore, we need to test our degraded Endpoint to see why it’s returning a HTTP status other than 200.
Testing Your Traffic Manager Endpoints
You might be inclined to use PowerShell to test your Traffic Manager Endpoints to ensure that they are available. This can be especially useful if one of your Azure Traffic Manager Endpoints falls into a Degraded state. There are a variety of methods to perform HTTP requests using PowerShell, but the two that I will review are:
- Use the System.Net.HttpWebRequest .NET class in the Base Class Library (BCL)
- Use the Invoke-WebRequest command in PowerShell 3.0 and later
Using the HttpWebRequest Class
If you want to make a request to your website or web service using the System.Net.HttpWebRequest .NET class, you can use the following PowerShell code as an example.
### Create a HttpWebRequest object $HttpWebRequest = [System.Net.HttpWebRequest]::CreateHttp('http://trevorsullivan.net'); ### Submit the HTTP request and get the HTTP response $HttpWebResponse = $HttpWebRequest.GetResponse();
Examine the HTTP status code that was returned
It’s important to take note of the following detail. The StatusCode property on the HttpWebResponse .NET class is actually a reference to a .NET Enumeration called System.Net.HttpStatusCode. To get the underlying integer value that the “friendly” status code maps to, we need to reference the value__ property of the enumeration.
Using the Invoke-WebRequest Command
You can also use the Invoke-WebRequest command, available in PowerShell version 3.0 and later, to test your website or web service endpoint.
Invoke-WebRequest -Uri http://westus.trevorsullivan.net -UseBasicParsing;
By default, Invoke-WebRequest will show the HTTP status code in the PowerShell console. You would normally expect to see a HTTP 200 OK response code returned. The -UseBasicParsing switch parameter can be used to speed up the parsing of the webpage, if you don’t need advanced parsing via the Internet Explorer engine, but can be omitted if you so choose.
Gotcha! Save Yourself a Headache
If the Traffic Manager Endpoint is responding normally, then you will typically receive a HTTP 200 “OK” in response. However, if your Traffic Manager Endpoint is in a degraded state, then you will likely get back a different HTTP status code. There’s a specific gotcha that snagged me, however, and hopefully this will save you some headache! If your website performs a redirect, you will receive a HTTP 301 Redirect followed by a HTTP 200 OK. In this case, by default during your manual testing, you will not see the HTTP 301 and think that your Traffic Manager Endpoint is functioning normally, even though Traffic Manager disagrees with you. The cause for this is that the HttpWebRequest and Invoke-WebRequest PowerShell tests are both following the redirect.
To fix this, we need to explicitly instruct both commands to not follow HTTP redirects.
Fixing the HttpWebRequest Method
To “fix” our PowerShell call using the .NET Base Class Library (BCL) HTTP objects, we need to change the AllowAutoRedirect boolean property on the HttpWebRequest class to $false before we submit the HTTP request.
### Create a HttpWebRequest object $HttpWebRequest = [System.Net.HttpWebRequest]::CreateHttp('http://trevorsullivan.net'); ### Disable automatic HTTP redirections $HttpWebRequest.AllowAutoRedirect = $false; ### Submit the HTTP request and get the HTTP response $HttpWebResponse = $HttpWebRequest.GetResponse(); ### Examine the HTTP status code that was returned $HttpWebResponse.StatusCode;
Fixing the Invoke-WebRequest Command
To “fix” the call to Invoke-WebRequest, we need to specify the -MaximumRedirection parameter, which accepts an integer value representing the maximum number of redirects that the command will follow, before returning a HTTP response. Once you specify this parameter, your test should return the HTTP 301 instead of a HTTP 200.
Invoke-WebRequest -Uri http://westus.trevorsullivan.net -MaximumRedirection 0;
In this article, we discussed Microsoft Azure Traffic Manager Profiles and Endpoints. We also took a look at two different methods of using PowerShell to test your Azure Traffic Manager Endpoints, to assist with troubleshooting Endpoints when they change into a degraded state. Thanks for joining me, and I hope you’ll tune in for the next article!
Please follow me on Twitter @pcgeek86!