There has always been confusion on the usage of the 3 components provided by Azure viz. Azure LB (Load Balancer), App Gateway and Traffic Manager . The notion is these can be used interchangeably which is incorrect. Each of the components are different and are intended to be used for different purpose.
First a recap of the OSI layer format which is as shown below,
Now we will see various Balancing options from Azure.
Traffic Manager : This is ideally kept right at the top and works only as an intelligent DNS routing. This essentially works at DNS level and uses DNS Responses to redirect end user traffic to globally distributed end points.
Usage : If you have resources at different locations and depending the end user’s closest latency you wish to direct the traffic to an end point, you should use Traffic Manager.
Application Gateway : This works at Application Layer ( Layer 7). It acts as a reverse proxy service. This terminates the client connection and forwards request to back endpoints.
Usage : Also called as Application delivery controller, this is ideally used if you want to redirect to a endpoint depending on application. For e.g. The application developer has decided that any URLs that match the pattern /images/* are served from a dedicated pool of VMs that are different from the rest of the web farm. We will see a diagram to help understanding this concept below.
Load Balancing : This works at Transport Layer ( Layer 4). This provides network level distribution but essentially only with the same azure data centre.
There are 2 types of Load balancing :
- Internet facing LB
- Internal LB
Usage :If you have couple of VM’s in the same Data Center and you wish to provide appropriate load balancing between them.
Scenario
source : Azure Balancing options
In this example scenario, we use a simple website that serves two types of content: images and dynamically rendered webpages. The website must be geographically redundant, and it should serve its users from the closest (lowest latency) location to them. The application developer has decided that any URLs that match the pattern /images/* are served from a dedicated pool of VMs that are different from the rest of the web farm.
Additionally, the default VM pool serving the dynamic content needs to talk to a back-end database that is hosted on a high-availability cluster. The entire deployment is set up through Azure Resource Manager.
Using Traffic Manager, Application Gateway, and Load Balancer allows this website to achieve these design goals:
- Multi-geo redundancy: If one region goes down, Traffic Manager routes traffic seamlessly to the closest region without any intervention from the application owner.
- Reduced latency: Because Traffic Manager automatically directs the customer to the closest region, the customer experiences lower latency when requesting the webpage contents.
- Independent scalability: Because the web application workload is separated by type of content, the application owner can scale the request workloads independent of each other. Application Gateway ensures that the traffic is routed to the right pools based on the specified rules and the health of the application.
- Internal load balancing: Because Load Balancer is in front of the high-availability cluster, only the active and healthy endpoint for a database is exposed to the application. Additionally, a database administrator can optimize the workload by distributing active and passive replicas across the cluster independent of the front-end application. Load Balancer delivers connections to the high-availability cluster and ensures that only healthy databases receive connection requests.
The following diagram shows the architecture of this scenario:
The following table summarizes the features offered by each service:
| Service | Azure Load Balancer | Application Gateway | Traffic Manager |
|---|---|---|---|
| Technology | Transport level (Layer 4) | Application level (Layer 7) | DNS level |
| Application protocols supported | Any | HTTP and HTTPS | Any (An HTTP endpoint is required for endpoint monitoring) |
| Endpoints | Azure VMs and Cloud Services role instances | Any Azure Internal IP address or public internet IP address | Azure VMs, Cloud Services, Azure Web Apps, and external endpoints |
| Vnet support | Can be used for both Internet facing and internal (Vnet) applications | Can be used for both Internet facing and internal (Vnet) applications | Only supports Internet-facing applications |
| Endpoint Monitoring | Supported via probes | Supported via probes | Supported via HTTP/HTTPS GET |
Source : Application Gateway
Xamlized 