Azure Traffic Manager is happy to announce support for nested Traffic Manager profiles. This feature enables you to create more flexible and powerful load-balancing and failover schemes to support the needs of larger, more complex deployments.

This feature is supported now through our REST API and PowerShell cmdlets.

Introduction

Traffic Manager allows you to load balance incoming traffic across multiple Azure deployments. Key scenarios enabled by Traffic Manager include improving application performance by directing end users to the closest deployment, and enabling high availability by monitoring your services and providing automatic failover when a service goes down. We also recently announced support for weighted traffic distribution and endpoints external to Azure, which enables a range of additional scenarios such as failover-to-cloud, burst-to-cloud and on-premises to cloud migration.

Today, we’re happy to announce another new feature: nested Traffic Manager profiles. This feature enables you to create more flexible and powerful load-balancing and failover schemes to support the needs of larger, more complex deployments.

Nested profiles can only be created via our REST API and PowerShell cmdlets (here’s how to get started with Azure PowerShell—note you’ll need version 0.8.8 or later.) They cannot be created via the Azure management portal.

The remainder of this blog post will explain the power of this feature and how to use it, using some examples.

Example 1: Trialing new deployments with Performance load-balancing

Suppose your application is deployed in multiple Azure regions—East US, West US, Europe North, Europe West, East Asia and SouthEast Asia. You use Traffic Manager’s ‘Performance’ load-balancing method to distribute traffic to the region closest to the user.

Now, suppose you wish to trial an update to your service with a small number of users before rolling it out more widely. For this, you’d like to use the ‘weighted round robin’ load-balancing method, which can direct a small percentage of traffic to your trial deployment. Previously, you were unable to combine this with Performance load-balancing. Now, with Nested Profiles, you can do both.

Here’s how: suppose you want to trial the new deployment in Europe North. You set up the trial deployment alongside the existing deployment, and you create a Traffic Manager profile using just these two endpoints and the weighted round-robin load-balancing method. You then add this ‘child’ profile as an endpoint to the ‘parent’ profile, which uses the Performance load-balancing method.

The following diagram and PowerShell snippet illustrate this example:

# Create child profile

$child = New-AzureTrafficManagerProfile -Name "eunorth-child" -DomainName "eunorth.trafficmanager.net" -LoadBalancingMethod "RoundRobin" -Ttl 30 -MonitorProtocol "Http" -MonitorPort 80 -MonitorRelativePath "/"

$child = Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $child -DomainName "eunorth.cloudapp.net" -Status "Enabled" -Type "CloudService" -Weight 99

$child = Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $child -DomainName "eunorth-new.cloudapp.net" -Status "Enabled" -Type "CloudService" -Weight 1

Set-AzureTrafficManagerProfile –TrafficManagerProfile $child

# Create parent profile

$parent = New-AzureTrafficManagerProfile -Name "parent" -DomainName "myapp.trafficmanager.net" -LoadBalancingMethod "Performance" -Ttl 30 -MonitorProtocol "Http" -MonitorPort 80 -MonitorRelativePath "/"

$parent = Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $parent -DomainName "eunorth.trafficmanager.net" -Status "Enabled" -Type "TrafficManager" -Location "North Europe"

$parent = Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $parent -DomainName "euwest.cloudapp.net" -Status "Enabled" -Type "CloudService"

# Repeat above line for other endpoints

Set-AzureTrafficManagerProfile –TrafficManagerProfile $parent

With this arrangement, traffic directed via the parent profile will be distributed across regions as normal. Within Europe North, traffic will be directed between your existing and trial deployments according to the weights you assigned.

Note that when assigning a child profile to a parent that uses the Performance load-balancing method, we specified the Location of the child profile (in exactly the same way as specifying the location for external endpoints, using type = ‘Any’, see earlier blog post).

Endpoint Monitoring in Nested Profiles

Traffic Manager actively monitors the health of each service endpoint (here’s how). If an endpoint is determined to be unhealthy, Traffic Manager will direct users to alternative endpoints instead, thereby preserving the overall availability of your service. This endpoint monitoring and failover behavior is available for all load-balancing methods (not just the ‘failover’ method).

For nested profiles, endpoint monitoring works a little differently. Where a parent profile is configured with a child profile as a nested endpoint, the parent doesn’t probe the child directly. Instead, the health of the child profile’s endpoints is used to calculate the overall health of the child profile, and this determines whether the parent profile will direct traffic to the child.

Returning to our earlier example: Suppose the existing deployment in Europe North fails. By default, the ‘child’ profile will direct all traffic to the trial deployment. If that also fails, the parent profile will determine that since all child endpoints are unhealthy, the child profile should not receive traffic and it will failover all Europe North traffic to the other regions.

You might be happy with this arrangement, or you might be concerned that the Trial deployment shouldn’t be used as a failover for all Europe North traffic—you’d rather failover to the other regions if the existing deployment in Europe North fails, regardless of the health of the Trial deployment. This is also possible: when configuring the child profile as an endpoint in the parent profile, you can specify the ‘MinChildEndpoints’ parameter, which determines the minimum number of endpoints that must be available in the child profile. Below this threshold (which defaults to 1), the parent profile will consider the entire child profile as unavailable, and direct traffic to the other parent profile endpoints instead.

The example below illustrates: with MinChildEndpoints set to 2, if either deployment in Europe North fails, the parent profile will determine that the child profile should not receive traffic and users will be directed to the other regions.

Note that when the child profile uses the ‘Failover’ load-balancing method, all traffic to that child is received by a single endpoint. Thus there is little value in a MinChildEndpoints setting other than ‘1’ in this case.

Example 2: In-Geo failover

In the original example (first picture), if an endpoint (e.g. Europe North) fails, all traffic that would have been directed to that endpoint is instead distributed across the other endpoints, across all regions (this is the default behaviour for the Traffic Manager Performance load-balancing method, designed to avoid over-loading the ‘next nearest’ endpoint):

However, suppose you prefer the Europe North traffic fail over to Europe West by preference, and only direct elsewhere if both of those endpoints are unavailable. You can do this by creating a child profile which uses the Failover load-balancing method, as shown:

You can repeat this pattern for all regions—replacing all 6 endpoints in the parent profile with 6 child profiles, each providing in-region failover.

Example 3: Per-Endpoint Monitoring Settings

Suppose you are using Traffic Manager to smoothly migrate traffic between a legacy on-premises web site and a new Cloud-based version hosted on Azure.  For the legacy site, you want to use the home page (path ‘/’) to monitor site health, but for the new Cloud-based version you are implementing a custom monitoring page that includes additional checks (path ‘/monitor.aspx’).

The monitoring settings in a Traffic Manager profile apply to all endpoints within the profile, which means you’d previously have had to use the same path on both sites.  With the release of nested Traffic Manager profiles, you can now use a child profile per site to define different monitoring settings per site:

FAQ

Can I use Nested profiles via the Azure Management Portal?

Nested Traffic Manager profiles can currently only be configured via our REST API and PowerShell cmdlets. They cannot be created via the Azure management portal.

However, you can continue to use the Azure management portal to view the status of profiles using nested profiles, and even to manage other settings on those profiles, such as enabling and disabling endpoints or configuring monitoring settings.

How many layers of nesting does Traffic Manger support?

You can nest profiles up to 10 levels deep (although we can’t imagine why you would!) ‘Loops’ are not permitted.

Can I mix other endpoint types (Cloud Services, Websites and External Endpoints) with nested ‘child’ profiles, in the same Traffic Manager profile?

Yes. There are no restrictions on how you combine endpoints of different types within a profile.

How does the billing model apply for Nested profiles?

Traffic Manager billing has two components, per monitored endpoints and per million DNS queries (for full details, see our pricing page.) Here’s how this applies to Nested profiles:

• Per monitored endpoint: There is no charge for a child profile when configured as an endpoint in a parent profile. Endpoints in the child profile that are monitoring the underlying services are billed in the usual way.
• Per million DNS queries: each query is only counted once. A query against a parent profile that returns an endpoint from a child profile is billed against the parent profile only.

Where can I get more information on Azure Traffic Manager?

The Azure portal contains an overview of the Traffic Manager service and scenarios. It also contains pricing and SLA details.

MSDN contains a more detailed overview, including descriptions of Traffic Manager’s load-balancing methods and endpoint monitoring and configuration.  MSDN also hosts our reference documentation for the Traffic Manager REST API, .NET Management Library and PowerShell cmdlets.

This earlier blog post explains how to get started with PowerShell for Azure Traffic Manager, including configuration of external endpoints and weighted profiles.

In addition to Azure’s paid-for support plans, our MSDN forum can be used to ask questions on any aspect of Azure relating to DNS or Traffic Manager. Feature suggestions should be posted to our feedback site, where you can also vote for existing suggestions.