Load balance non-HTTP(S) traffic in Azure Flashcards
Load Balancing options for Azure
Azure Load Balancer - High-performance, ultra-low-latency Layer 4 load-balancing service (inbound and outbound) for all UDP and TCP protocols. The load balancer can handle millions of requests per second ensuring your solution is highly available. Azure Load Balancer is zone-redundant, ensuring high availability across Availability Zones.
Traffic Manager - DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions, while providing high availability and responsiveness. Because Traffic Manager is a DNS-based load-balancing service, it load-balances only at the domain level. For that reason, it can’t fail over as quickly as Front Door, because of common challenges around DNS caching and systems not honoring DNS time-to-live values (TTLs).
Azure Application Gateway - Provides application delivery controller (ADC) as a service, offering various Layer 7 load-balancing capabilities. Use it to optimize web farm productivity by offloading CPU-intensive SSL termination to the gateway.
Azure Front Door - Application delivery network that provides global load balancing and site acceleration service for web applications. It offers Layer 7 capabilities for your application like SSL offload, path-based routing, fast failover, caching, etc. to improve performance and high-availability of your applications.
Categorizing load balancing services
Load balancing services can be categorized in two ways: global versus regional, and HTTP(S) versus non-HTTP(S).
Global versus regional
* Global load-balancing services distribute traffic across regional backends, clouds, or hybrid on-premises services. These services route end-user traffic to the closest available backend. They also react to changes in service reliability or performance, in order to maximize availability and performance.
- In contrast, Regional load-balancing services distribute traffic within virtual networks across virtual machines (VMs) or zonal and zone-redundant service endpoints within a region.
HTTP(S) versus non-HTTP(S)
* HTTP(S) load-balancing services are Layer 7 load balancers that only accept HTTP(S) traffic. They’re intended for web applications or other HTTP(S) endpoints. They include features such as SSL offload, web application firewall, path-based load balancing, and session affinity.
- In contrast, non-HTTP(S) load-balancing services can handle non-HTTP(S) traffic and are recommended for nonweb workloads.
Choosing a load balancing option for Azure
- Type of traffic - is it for a web application? Is it a public-facing or private application?
- Scope - do you need to load balance virtual machines and containers within a virtual network, or load balance across regions, or both?
- Availability - what is the Service Level Agreement (SLA) for the service?
- Cost - In addition to the cost of the actual service itself, consider the operational cost to manage and maintain a solution built on that service.
Azure Load Balancer - Type / Availability Zones
Choosing a load balancer type
* 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.
* An internal load balancer is used where private IPs are needed at the frontend only. Internal load balancers are used to load balance traffic from internal Azure resources to other Azure resources inside a virtual network.
Availability Zones
A Load Balancer can either be zone redundant, zonal, or nonzonal.
- Zone redundant - A single frontend IP address survives zone failure. One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy.
- Zonal - Frontend guaranteed to a single zone. he data path is unaffected by failures in zones other than where it was guaranteed. You can use zonal frontends to expose an IP address per Availability Zone.
Selecting an Azure Load Balancer SKU
Two SKUs are available when you create a load balancer in Azure: Basic load balancers and Standard load balancers. These SKUs differ in terms of their scenario scope and scale, features, and cost. Any scenario that is possible with the Basic load balancer can also be created with the Standard load balancer.
Microsoft recommends Standard load balancer. Standalone VMs, availability sets, and virtual machine scale sets can be connected to only one SKU, never both. Load balancer and the public IP address SKU must match when you use them with public IP addresses.
SKUs aren’t mutable; therefore, you cannot change the SKU of an existing resource.
Creating and configuring an Azure Load Balancer
On the Create load balancer page, you must supply the following required information:
- Subscription
- Resource group
- Name
- Region
- Type - Select whether your load balancer is going to be Internal (private) or Public (external)
- SKU - SKU - Select either the Standard SKU or the Basic SKU.
- Tier- Select whether your load balancer is balancing within a region (Regional) or across regions (Global) - If you select the Basic SKU, this setting is greyed out.
- Public IP Address - Specify whether to create a new public IP address for your public-facing front-end, or use an existing one
Backend Pools & Health Probes
Backend Pools
* Is a collection of resources—such as virtual machines, VM scale sets, or instances—that can receive incoming network traffic.
* When you define a load balancing rule, you specify which backend pool it should apply to, ensuring that traffic is routed only to the intended set of resources.
Health Probes
* Are periodic checks performed by the Azure Load Balancer on each resource in a backend pool.
* These probes determine the health and responsiveness of each instance by sending requests (using protocols like TCP, HTTP, or HTTPS).
* If an instance fails to respond correctly to a health probe, the load balancer marks it as unhealthy and stops directing traffic to it until it recovers.
Azure 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 the 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.
Key features
* Increase application availability
* Improve application performance
* Service maintenance without downtime
* Combine hybrid applications
* Distribute traffic for complex deployments
How Traffic Manager works
Azure Traffic Manager enables you to control the distribution of traffic across your application endpoints. An endpoint is any Internet-facing service hosted inside or outside of Azure.
Traffic Manager provides two key benefits:
- Distribution of traffic according to one of several traffic-routing methods
- Continuous monitoring of endpoint health and automatic failover when endpoints fail
When a client attempts to connect to a service, it must first resolve the DNS name of the service to an IP address. The client then connects to that IP address to access the service.
Traffic Manager works at the DNS level which is at the Application layer (Layer-7)
Traffic Manager - Example Deployment
Contoso Corp has 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.
Traffic Manager - Example Client Usage
- The client sends a DNS query to its configured recursive DNS service to resolve the name ‘partners.contoso.com’.
- 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 which 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 aren’t returned)
* The current health of each endpoint, as determined by the Traffic Manager health checks.
* The chosen traffic-routing method. - 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.
Traffic routing methods
Azure Traffic Manager supports six traffic-routing methods to determine how to route network traffic to the various service endpoints.
1. Priority - This routing method for a primary service endpoint for all traffic. You can provide multiple backup endpoints in case the primary or one of the backup endpoints is unavailable.
2. Weighted - When you want to distribute traffic across a set of endpoints based on their weight. Set the weight the same to distribute evenly across all endpoints.
3- Performance - When endpoints are in different geographic locations. Users should use the “closest” endpoint for the lowest network latency.
4. Geographic - Direct users to specific endpoints (Azure, External, or Nested) based on where their DNS queries originate from geographically. With this routing method, it enables you to be compliant with scenarios such as data sovereignty mandates, localization of content & user experience
5. MultiValue - This routing method for Traffic Manager profiles with only one IPv4/IPv6 address endpoint. When a query is received for this profile, all healthy endpoints are returned.
6. Subnet - This routing method to map sets of end-user IP address ranges to a specific endpoint. When a request is received, the endpoint is the one mapped for that request’s source IP address.
Traffic Manager profiles
Traffic Manager profiles
Within a Traffic Manager profile, you can only configure one traffic routing method at a time. You can select a different traffic routing method for your profile at any time. Your changes are applied within a minute without any downtime.
- All Traffic Manager profiles include health monitoring and automatic failover of endpoints.
Nested Traffic Manager profiles
Azure Traffic Manager allows only one traffic-routing method per profile. Nested profiles enable combining different traffic-routing strategies in Azure Traffic Manager.
Traffic Manager Endpoints
Azure Traffic Manager controls how network traffic is distributed across application deployments in different datacenters. Each deployment is configured as an endpoint, and Traffic Manager selects an available endpoint based on its status and the traffic-routing method.
Types of Traffic Manager Endpoints
* Azure Endpoints – Used for load balancing traffic to cloud services, web apps, or public IPs within the same Azure subscription.
* External Endpoints – Used for load balancing traffic to IPv4/IPv6 addresses, FQDNs, or services hosted outside Azure (on-premises or with other providers).
* Nested Endpoints – Used to combine Traffic Manager profiles for more complex traffic-routing needs. A child profile is added as an endpoint to a parent profile, and both can contain any other endpoint types.
Traffic Manager Endpoint Monitoring
Azure Traffic Manager includes built-in endpoint monitoring and automatic endpoint failover. This feature helps you deliver high-availability applications that are resilient to endpoint failure, including Azure region failures.
To configure endpoint monitoring, you open the Configuration page for the Traffic Manager profile. Then, under the Endpoint monitor settings section.
How endpoint monitoring works
Azure Traffic Manager monitors endpoint health using HTTP, HTTPS, or TCP protocols.
1. HTTP/HTTPS Monitoring:
* Traffic Manager sends a GET request to the endpoint.
* If the response is 200-OK (or a configured expected status code), the endpoint is considered healthy.
* If the response is incorrect or missing, Traffic Manager retries based on the Tolerated Number of Failures setting.
2. TCP Monitoring:
* Traffic Manager attempts to establish a TCP connection using the specified port.
* If the connection succeeds, the endpoint is healthy; otherwise, it retries based on failure settings.
3. General Monitoring Behavior:
* Traffic Manager probes from multiple locations for better reliability.
* If failures exceed the tolerated threshold, the endpoint is marked unhealthy.
* Health probes occur more frequently than the configured Probing Interval setting.
