Creating an Azure Traffic Manager – CloudShell

In a previous post, we talked about about Load Balancers, how they can be useful to load balance traffic between a set of virtual machines, but they are not useful when we are talking about multiple regions. Azure Traffic Manager helps you to have high availability when you have 2 or more regions. Let’s see what is Azure Traffic Manager, how it works and how to deploy it in this post.

1 – What is Traffic Manager?

Azure Traffic Manager is a DNS-based load balancer, it enables you to distribute traffic optimally to services across global Azure regions, the endpoints need to be internet-facing hosted either inside or outside of Azure.
The DNS is used to direct traffic to the endpoints based on the traffic-routing method and the endpoints health.

2 – How it Works?

As we said before, traffic manager uses DNS to direct the traffic to the endpoints, however, it does not see the traffic passing between the client and the service because traffic manager is not a proxy or gateway.
To choose the best endpoint to direct the traffic, traffic manager will validate a few things:

• The configured state of each endpoint, where the disabled endpoints won’t be returned;
• The endpoints health validated by the traffic manager health checks;
• The chosen routing traffic methods;

Traffic manager only redirects the users to the correct endpoint using DNS and the rules above. In the example below, you see that we have a traffic manager that has 4 endpoints attached to it, it will redirect the user traffic to the correct endpoint based on the routing method that was previously configured.

Let’s get to know the existing routing methods in the next section.

3 – Routing Methods

The traffic-routing method determines which endpoint is returned in the DNS response. You can apply changes within one minute and there’s no downtime.

3.1 – Performance – This method is used when you want traffic manager to redirect the user to the closest endpoint in terms of low latency;

In the example above, the Brazilians users are redirected to the EastUS because the latency is lower than the WestEurope; The same happens with Italian users, but for them the latency is lower in WestEurope;

3.2 – Weighted – This method is used when you want to distribute traffic to your endpoint based on the weight that you define for them;

In this example, the weight is 8 for the WestEurope WebApp, 80% of the users will be redirected to that region, while it’s 2 in the EastUS and 20% of the users will be redirected to that webapp. A good example of use case could be a new website interface and you want to have a small percentage of users testing it, if nobody complains about your new site performance, you can slightly increase the weight to the new website and finally redirect 100% of the users to the new site.

3.3 – Geographical – This method is based on the geographic location where the DNS query was originated from.

On figure 4, each query coming from Europe will be redirected to the WestEurope webapp, while everything else will be redirected to the EastUS endpoint.

3.4 – Priority – It is useful when you want to designate the traffic to an endpoint and provide a backup to it, you can redirect the traffic to another endpoint in case of the primary is unavailable for instance. The higher priority is always the lowest number, for instance, the priority 1 is higher than the priority 100;

The priority on Figure 5 is to use the WestEurope web app while it’s healthy, but if something bad happens with it, the users will be redirected to the EastUS webApp;

3.5 – Multivalue – this method returns all healthy endpoints in a single DNS query, if an endpoint is unhealthy, the client has more options to retry without making another DNS call;

3.6 – Subnet – This method is used to map a set of end users IP addresses to a specific endpoint as an example, you could show different content if users are connecting to a website from your corporate HQ;

4 – Deploying the Traffic Manager

In this demo, we are going to create the Figure 2 diagram, which is the performance routing method, so let’s get started with the basic infrastructure:

Resource Group:

Go to the search bar and search for Resource Group. Then, click add to create a new one:

Choose the subscription, add a name to the resource group and select the region:

You can also use Powershell to do so. If you don’t know how to connect your Powershell session to your Azure tenant, I’ve written this post that may help you.

Powershell Equivalent:

#To connnect Your Session to Azure
Connect-AzAccount

#To create the Resouce Group
New-AzResourceGroup -Name "Test-TrafficManagerRG" -Location "EastUS"

Web Apps

To create 2 web apps, you can either follow the 2.2 section of this post or use the following Powershell code:

$ResourceGroup = "Test-trafficManager"
$AppServicePlan = "CloudShellSP"
$location1 = "EastUS"
$location2 = "WestEurope"

$locations = ($location1, $location2)

#To create the WebApps and the App Service Plans
foreach($Location in $locations){

    $ASPService = "$AppServicePlan-$location"

    #To create the App Service Plan
    New-AzAppServicePlan -Name $ASPService -Location $Location -ResourceGroupName $ResourceGroup -Tier "Standard" -NumberofWorkers 2 -WorkerSize "Small"

    #To create the WebApp
    New-AzWebApp -Name "$location-site" -ResourceGroupName $ResourceGroup -Location $Location -AppServicePlan $ASPService
}

This code is going to create two app service plans with a web app on top of them, in the EastUS and another one in WestEurope;

Don’t forget that only Web Apps at the ‘Standard‘ SKU or above are eligible for use with Traffic Manager. Attempts to add a Web App of a lower SKU will fail.

Traffic Manager

Using the Console

Go to search bar and search for “traffic manager profiles” and click “Add”:

Here you have to set some configs:

• Name – Traffic manager name;
• Routing Method – We talked about them on section 3 of this post. We’ll use “Performance” for this demo;
• Subscription – Subscription where you’ll deploy your resource;
• Resource Group – The resource group that you created before;
• Resource Group Location – Although the traffic manager is not bound to a specific region, it’s necessary to select a region to store its metadata, in our case, we leave the same region as our resource group;

Adding endpoints:

Go to the traffic manager page, select Endpoints and add one:

Let’s configure our first endpoint:

• Type – here we have three options:
  • Azure Endpoint – For services hosted in Azure;
  • External Endpoints – For services outside Azure, you have to point to their FQDNs or IPv4/6 addresses;
  • Nested Endpoints – You can use it to combine traffic manager profiles and create more flexible traffic routing schemes, to support complex scenarios;
• Name – Endpoint name;
• Target Resource Type – Currently 4 types are supported:
  • Cloud Service
  • App Service
  • Web App Slots
  • PublicIP Address
• Target Resource – The resource that you want to be an endpoint for this traffic manager, in our case, we have 2 web apps;
• Custom Header Settings – You can add up to 8 pairs of headers, it will override the Custom Header Settings in the profile configuration;
• Add as Disabled – To add the endpoint but not start it yet;

Repeat the same process to add the second endpoint.

When I test the traffic manager URL, I got one of the websites:

Using Powershell:

#To create the Traffic Manager Profile
$TFName = "performancetf"
New-AzTrafficManagerProfile -Name $TFName -ResourceGroupName $ResourceGroup -RelativeDnsName $TFName -TrafficRoutingMethod Performance -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"

#To create the Endpoints using the Web Apps that were previously created
foreach($Location in $locations){

    $siteID = (Get-AzWebApp -ResourceGroupName $ResourceGroup -Name "$location-site").Id
    
    New-AzTrafficManagerEndpoint -EndpointStatus Enabled `
                             -Name "$location-endpoint" `
                             -ProfileName $TFName `
                             -ResourceGroupName $ResourceGroup `
                             -Type AzureEndpoints  `
                             -TargetResourceId $siteID
}

Let’s make more tests to see if the “Performance” routing method is working well.

5 – Testing the Traffic Manager

To upload a test page to your web apps, you can simply follow my previous post or use the following Powershell code to upload the zip files to each web app:

$EastUSfiles =  "C:\Temp\Sites\TechSite"
$Europefiles =  "C:\Temp\Sites\TechSite2"

#Open the index.html, search for "on featured" and change it to "EastUS Region" and then run the following
Compress-Archive -Path "$EastUSfiles\*" -DestinationPath "C:\Temp\$location1.zip" -Update

#Open the index.html, search for "on featured" and change it to "WestEurope Region" and then run the following
Compress-Archive -Path "$Europefiles\*" -DestinationPath "C:\Temp\$location2.zip" -Update

#To publish the zip files you've created before
Publish-AzWebapp -ResourceGroupName $ResourceGroup -Name "$location1-site" -ArchivePath "C:\Temp\$location1.zip" -Force

Publish-AzWebapp -ResourceGroupName $ResourceGroup -Name "$location2-site" -ArchivePath "C:\Temp\$location2.zip" -Force

You can find the test website on my github page.

This will create two web pages containing the following information:

Let’s first measure the latency of both websites to see which site I’ll be redirected by the traffic manager. I’ve created a simple script to measure the latency of the websites:

$EastUSurl = "https://$location1-site.azurewebsites.net"
$WestEuropeurl = "https://$location2-site.azurewebsites.net"

$URLs = ($EastUSurl, $WestEuropeurl)


foreach ($url in $URLs){
    # track execution time:
    $i= 0
    While ($i -lt 10){

        $timeTaken = Measure-Command -Expression {
        Invoke-WebRequest -Uri $url
        }
        $milliseconds = $timeTaken.TotalMilliseconds

        $milliseconds = [Math]::Round($milliseconds, 1)

        write-host "This took $milliseconds ms to execute against $url" -ForegroundColor Green
        $i++
    }
}

Running this command returns the following output:

As you can see on the figure 15, there’s a small difference between them, but EastUS is the best choice for me in this case, that’s why when I browse the traffic manager URL, I get the following result:

And with that, we confirmed that the Performance method is working well. I challenge you to test another routing methods by yourself.

In this post, you’ve learned how to deploy the traffic manager. You can find the full code to deploy this environment here:

Powershell:

$ResourceGroup = "Test-trafficManager"
$AppServicePlan = "CloudShellSP"
$location1 = "EastUS"
$location2 = "WestEurope"

Connect-AzAccount

New-AzResourceGroup -Name $ResourceGroup -Location $location1

$locations = ($location1, $location2)

#To create the WebApp using the App Service Plan
foreach($Location in $locations){

    $ASPService = "$AppServicePlan-$location"

    #To create the App Service Plan
    New-AzAppServicePlan -Name $ASPService -Location $Location -ResourceGroupName $ResourceGroup -Tier "Standard" -NumberofWorkers 2 -WorkerSize "Small"

    New-AzWebApp -Name "$location-site" -ResourceGroupName $ResourceGroup -Location $Location -AppServicePlan $ASPService
}

#To create the Traffic Manager Profile
$TFName = "performancetf"
New-AzTrafficManagerProfile -Name $TFName -ResourceGroupName $ResourceGroup -RelativeDnsName $TFName -TrafficRoutingMethod Performance -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"

#To create the Endpoints using the Web Apps that were previously created
foreach($Location in $locations){

    $siteID = (Get-AzWebApp -ResourceGroupName $ResourceGroup -Name "$location-site").Id
    
    New-AzTrafficManagerEndpoint -EndpointStatus Enabled `
                             -Name "$location-endpoint" `
                             -ProfileName $TFName `
                             -ResourceGroupName $ResourceGroup `
                             -Type AzureEndpoints  `
                             -TargetResourceId $siteID
}

Don’t forget to find me on GitHub.