Microsoft Azure Traffic Manager allows users to manage the user traffic distribution of various service endpoints that are located in data centres around the world.
The service endpoints, which are supported by the Azure Traffic Manager, incorporate cloud services, Web Apps, and Azure VMs.
Users can use the Azure Traffic Manager, as well as the non-Azure external endpoints as well.
Azure Traffic Manager utilizes the DNS (Domain Name System) in order to direct the client requests through the most suitable endpoint by applying the traffic-routing method.
The Traffic Manager offers several endpoint monitoring alternatives and traffic-routing methodologies to suit unique application requirements with auto-failover models.
Azure Traffic Manager is robust and resilient to failures, which also includes the failures of the whole Azure region.
1. Improves the accessibility of crucial applications.
2. Delivers exceptionally high availability of applications through endpoint monitoring and automatic failover, just in case any endpoint is down.
3. Enhances responsiveness for applications that need high-performance.
MS Azure Traffic Manager offers users to run websites or cloud services in data centers stationed across the globe. The Traffic Manager increases the responsiveness of applications by routing the traffic to an endpoint which has the lowest latency.
Users can perform pre-planned maintenance services on applications without having to face downtimes. Azure Traffic Manager, during the maintenance, routes the traffic to an alternate endpoint, ensuring complete service availability.
Azure Traffic Manager can support non-Azure, external endpoints, enabling its convergence with on-premises and hybrid cloud deployments. This includes, "migrate-to-cloud," "failover-to-cloud", and the "burst-to-cloud," environments.
By applying nested Traffic Manager Profiles, the traffic-routing methods can be blended together to create more flexible as well as sophisticated rules which support the requirements of the complex and the large deployments.
Azure's Traffic Manager allows users to control traffic distribution across various application endpoints. An endpoint can be referred to as an Internet-facing service, placed outside or inside the Azure.
1. The Traffic Manager distributes the traffic using the best traffic-routing methodology applicable to the scenario.
2. Constant monitoring of the endpoint health
3. Automatic failover in case the endpoints fail
The most significant point that needs to be understood is that Azure Traffic Manager functions at the DNS level. It uses the DNS to route clients to precise service endpoints, according to the traffic-routing rules and methods. Clients can connect directly to the chosen endpoint.
The Azure Traffic Manager, however, isn't a gateway, and neither a proxy. It cannot help the users to view the traffic between the service and the client.
Related Page: Azure SQL Data Warehouse
Example of Azure Traffic Manager
For instance, a company has newly launched a partner portal -
To enhance global performance, and to optimize its availability, the company uses the Azure Traffic Manager for the distribution of traffic to an available endpoint.
The application, for example, is being hosted in 3 regions of this forum. To accomplish this particular configuration, the company performs the steps listed below -
1. Deploys three cases for the service. DNS names for the service deployments are - 'contoso-us.cloudapp.net', 'contoso-asia.cloudapp.net', and the 'contoso-eu.cloudapp.net'.
2. It creates an Azure Traffic Manager profile, titled as 'contoso.trafficmanager.net', and then it configures the same to use Azure's Performance traffic-routing across all the three endpoints.
3. It configures 'partners.contoso.com'- a vanity domain name to point it to 'contoso.trafficmanager.net', by applying the DNS CNAME record.
Extending the previous discussion, when the client requests for the https://partners.contoso.com/login.aspx page, - they execute the below-mentioned actions to resolve DNS name in order to set up the connection -
1. The client forwards a DNS query to the designated recursive DNS service in order to resolve the name 'partners.contoso.com'. The Recursive DNS service, also known as the Local DNS service. This does not directly host the DNS domains. Instead, the client sheds the major workload of contacting different authoritative DNS services over the Internet required to resolve the DNS name.
2. To resolve a DNS name, the Local DNS service finds the name servers for 'contoso.com' domain. Subsequently, it contacts the name servers for DNS record of 'partners.contoso.com. As a result, the contoso.com DNS servers send back the CNAME record which further points to the contoso.trafficmanager.net.
3. Next, recursive DNS service finds name servers for 'trafficmanager.net' domain, given by Azure Traffic Manager service. The Traffic Manager then forwards a request for 'contoso.trafficmanager.net' DNS record to the DNS servers.
The ATM (Azure Traffic Manager) servers get the request, and consequently, the name servers select an endpoint on the basis of -
1. The state of every configured endpoint (endpoints that are disabled aren't returned)
2. The present health of every endpoint, according to the health checks performed by the Azure Traffic Manager.
3. The selected traffic-routing method. (Please refer to Traffic Manager Routing Methods to know more).
The selected endpoint is then returned as the DNS CNAME record. For this particular case, let's assume contoso-us.cloudapp.net has been returned.
1. Accordingly, Local DNS service finds the name servers for 'cloudapp.net' domain. This service contacts the name servers to ask for the 'contoso-us.cloudapp.net' DNS record. A DNS 'A' record comprising the IP address of service endpoint based in the United States is returned.
2. The Local DNS service merges with all the results, and after that, it returns a consolidated DNS response to the client.
3. The client correspondingly receives the consolidated DNS results, with which they connect to the provided IP address. The client directly connects the application service endpoint, without going through the ATM.
This being an HTTPS endpoint, the client does the required SSL/TLS handshake, following which they make an HTTP GET request for their '/login.aspx' page.
The Local DNS service caches all the DNS responses received by it. The DNS resolver located on the client's device caches the received result as well.
Caching enables DNS queries to be responded more speedily by utilizing the cache data, instead of performing queries for various name servers. The time duration of cache is typically determined by the 'time-to-live' (TTL) attribute of every DNS record.
Shorter values lead to the quicker expiry of cache, and hence, more return trips to the Azure Traffic Manager name servers.
Longer values essentially mean, it might need a longer time for directing the traffic elsewhere from an endpoint that has failed.
Azure Traffic Manager allows users to configure the 'time-to-live' used in Traffic Manager DNS feedbacks. It is typically 0 seconds on the lower side, and 2,147,483,647 seconds in the upper limit, compliant with the RFC-1035 maximum range.
This enables the users to determine the ideal value that is suitable to meet the requirements of their applications.
|Microsoft Azure Infrastructure Solutions 70-533||Microsoft Azure Solutions 70-532|
|Azure Solutions Architect||Microsoft Azure Certification|
Free Demo for Corporate & Online Trainings.