What is Azure Load Balancer?
Load balancing refers to evenly distributing load (incoming network traffic) across a group of backend resources or servers.
Azure Load Balancer operates at layer 4 of the Open Systems Interconnection (OSI) model. It's the single point of contact for clients.
Load balancer distributes inbound flows that arrive at the load balancer's front end to backend pool instances. These flows are according to configured load-balancing rules and health probes. The backend pool instances can be Azure Virtual Machines or instances in a Virtual Machine Scale Set.
A public load balancer can provide outbound connections for virtual machines (VMs) inside your virtual network. These connections are accomplished by translating their private IP addresses to public IP addresses. Public Load Balancers are used to load balance internet traffic to your VMs.
An internal (or private) load balancer is used where private IPs are needed at the frontend only. Internal load balancers are used to load balance traffic inside a virtual network. A load balancer frontend can be accessed from an on-premises network in a hybrid scenario.
Figure: Balancing multi-tier applications by using both public and internal Load Balancer
What is Azure Application Gateway?
Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that's optimized for videos.
This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway can do URL-based routing and more.
What is Traffic Manager?
Azure Traffic Manager is a DNS-based traffic load balancer. This service allows you to distribute traffic to your public facing applications across the global Azure regions. Traffic Manager also provides your public endpoints with high availability and quick responsiveness.
Traffic Manager uses DNS to direct client requests to the appropriate service endpoint based on a traffic-routing method.
Traffic manager also provides health monitoring for every endpoint. The endpoint can be any Internet-facing service hosted inside or outside of Azure.
Traffic Manager provides a range of traffic-routing methods and endpoint monitoring options to suit different application needs and automatic failover models. Traffic Manager is resilient to failure, including the failure of an entire Azure region.
Traffic Manager continuously monitors the web application. If the primary site is unavailable, it provides automatic failover to the backup site.
How Traffic Manager Works
Traffic Manager example
Contoso Corp have developed a new partner portal. The URL for this portal is https://partners.contoso.com/login.aspx. The application is hosted in three regions of Azure. To improve availability and maximize global performance, they use Traffic Manager to distribute client traffic to the closest available endpoint.
To achieve this configuration, they complete the following steps:
- Deploy three instances of their service. The DNS names of these deployments are 'contoso-us.cloudapp.net', 'contoso-eu.cloudapp.net', and 'contoso-asia.cloudapp.net'.
- Create a Traffic Manager profile, named 'contoso.trafficmanager.net', and configure it to use the 'Performance' traffic-routing method across the three endpoints.
- Configure their vanity domain name, 'partners.contoso.com', to point to 'contoso.trafficmanager.net', using a DNS CNAME record.
How clients connect using Traffic Manager
Continuing from the previous example, when a client requests the page https://partners.contoso.com/login.aspx, the client performs the following steps to resolve the DNS name and establish a connection:
The client sends a DNS query to its configured recursive DNS service to resolve the name 'partners.contoso.com'. A recursive DNS service, sometimes called a 'local DNS' service, does not host DNS domains directly. Rather, the client off-loads the work of contacting the various authoritative DNS services across the Internet needed to resolve a DNS name.
To resolve the DNS name, the recursive DNS service finds the name servers for the 'contoso.com' domain. It then contacts those name servers to request the 'partners.contoso.com' DNS record. The contoso.com DNS servers return the CNAME record that points to contoso.trafficmanager.net.
Next, the recursive DNS service finds the name servers for the 'trafficmanager.net' domain, which are provided by the Azure Traffic Manager service. It then sends a request for the 'contoso.trafficmanager.net' DNS record to those DNS servers.
The Traffic Manager name servers receive the request. They choose an endpoint based on:
- The configured state of each endpoint (disabled endpoints are not returned)
- The current health of each endpoint, as determined by the Traffic Manager health checks. For more information, see Traffic Manager Endpoint Monitoring.
The chosen endpoint is returned as another DNS CNAME record. In this case, let us suppose contoso-eu.cloudapp.net is returned.
Next, the recursive DNS service finds the name servers for the 'cloudapp.net' domain. It contacts those name servers to request the 'contoso-eu.cloudapp.net' DNS record. A DNS 'A' record containing the IP address of the EU-based service endpoint is returned.
The recursive DNS service consolidates the results and returns a single DNS response to the client.
The client receives the DNS results and connects to the given IP address. The client connects to the application service endpoint directly, not through Traffic Manager. Since it is an HTTPS endpoint, the client performs the necessary SSL/TLS handshake, and then makes an HTTP GET request for the '/login.aspx' page.
What is Azure Front Door?
Whether you’re delivering content and files or building global apps and APIs, Azure Front Door can help you deliver higher availability, lower latency, greater scale, and more secure experiences to your users wherever they are.
Azure Front Door is Microsoft’s modern cloud Content Delivery Network (CDN) that provides fast, reliable, and secure access between your users and your applications’ static and dynamic web content across the globe.
Azure Front Door delivers your content using the Microsoft’s global edge network with hundreds of global and local points of presence (PoPs) distributed around the world close to both your enterprise and consumer end users.
Why use Azure Front Door?
Azure Front Door enables internet-facing application to:
Build and operate modern internet-first architectures that have dynamic, high-quality digital experiences with highly automated, secure, and reliable platforms.
Accelerate and deliver your app and content globally at scale to your users wherever they're creating opportunities for you to compete, weather change, and quickly adapt to new demand and markets.
Intelligently secure your digital estate against known and new threats with intelligent security that embrace a Zero Trust framework.
Key Benefits
Global delivery scale using Microsoft’s network
Scale out and improve performance of your applications and content using Microsoft’s global Cloud CDN and WAN.
Leverage over 118 edge locations across 100 metro cities connected to Azure using a private enterprise-grade WAN and improve latency for apps by up to 3 times.
Accelerate application performance by using Front Door’s anycast network and split TCP connections.
Terminate SSL offload at the edge and use integrated certificate management.
Natively support end-to-end IPv6 connectivity and the HTTP/2 protocol.
Deliver modern apps and architectures
Modernize your internet first applications on Azure with Cloud Native experiences
Integrate with DevOps friendly command line tools across SDKs of different languages, Bicep, ARM templates, CLI and PowerShell.
Define your own custom domain with flexible domain validation.
Load balance and route traffic across origins and use intelligent health probe monitoring across apps or content hosted in Azure or anywhere.
Integrate with other Azure services such as DNS, Web Apps, Storage and many more for domain and origin management.
Move your routing business logic to the edge with enhanced rules engine capabilities including regular expressions and server variables.
Analyze built-in reports with an all-in-one dashboard for both Front Door and security patterns.
Monitoring your Front Door traffic in real time, and configure alerts that integrate with Azure Monitor.
Log each Front Door request and failed health probes.
What are difference between Azure Load Balancer vs Application Gateway vs Traffic Manager vs Front Door?
Load Balancer | Application Gateway | Traffic Manager | Front Door | |
Service | Network load balancer. | Web traffic load balancer. | DNS-based traffic load balancer. | Global application delivery |
Network Protocols | Layer 4 (TCP or UDP) | Layer 7 (HTTP/HTTPS) | Layer 7 (DNS) | Layer 7 (HTTP/HTTPS) |
Type | Internal and Public | Standard and WAF | – | Standard and Premium |
Routing | Hash-based, | Path-based | Performance, Weighted, Priority, Geographic, MultiValue, Subnet | Latency, Priority, Weighted, Session Affinity |
Global/Regional Service | Global | Regional | Global | Global |
Recommended Traffic | Non-HTTP(S) | HTTP(S) | Non-HTTP(S) | HTTP(S) |
Endpoints | NIC (VM/VMSS), IP address | IP address/FQDN, Virtual machine/VMSS, App services | Cloud service, App service/slot, Public IP address | App service, Cloud service, Storage, Application Gateway, API Management, Public IP address, Traffic Manager, Custom Host |
Endpoint Monitoring | Health probes | Health probes | HTTP/HTTPS GET requests | Health probes |
Redundancy | Zone redundant and Zonal | Zone redundant | Resilient to regional failures | Resilient to regional failures |
SSL/TLS Termination | – | Supported | – | Supported |
Web Application Firewall | – | Supported | – | Supported |
Sticky Sessions | Supported | Supported | – | Supported |
VNet Peering | Supported | Supported | – | – |
SKU | Basic and Standard | Standard and WAF (v1 & v2) | – | Standard and Premium |
Pricing | Standard Load Balancer – charged based on the number of rules and processed data. | Charged based on Application Gateway type, processed data, outbound data transfers, and SKU. | Charged per DNS queries, health checks, measurements, and processed data points. | Charged based on outbound/inbound data transfers, and incoming requests from client to Front Door POPs. |
No comments:
Post a Comment