Azure Load Balancer
Intro
My notes on Azure’s Load Balancer service
Â
Documentation
Understand Azure Load Balancing - Read here to determine which Azure load balancer makes sense
Quickstart: Create a public load balancer to load balance VMs using the Azure portal
Tips And Tidbits
Â
Azure Load Balancer operates at layer 4 of the Open Systems Interconnection (OSI) model.
With Azure Load Balancer, you can spread user requests across multiple virtual machines or other services.Â
Load balancers aren't physical instances.
Load balancer objects are used to express how Azure configures its infrastructure to meet your requirements.
 Load balancers use a hash-based distribution algorithm.
By default, a five-tuple hash is used to map traffic to available servers.
The hash is made from the following elements:
Source IP: The IP address of the requesting client.
Source port: The port of the requesting client.
Destination IP: The destination IP of the request.
Destination port: The destination port of the request.
Protocol type: The specified protocol type, TCP or UDP.
Because the source port is included in the hash and the source port changes for each session, clients might be directed to a different virtual machine for each session.
To mequests from a specific client to the same virtual machine, select Session persistence when configuring the LB.
Azure Load Balancer is zone-redundant, ensuring high availability across Availability Zones.
To achieve high availability with Load Balancer:
Configuration | Service level agreement (SLA) | Information |
Availability set | 99.95% | Protection from hardware failures within datacenters |
Availability zone | 99.99% | Protection from entire datacenter failure
|
Â
At least one backend and a health probe must exist before you can create a load balancing rule.
Outbound rules allow instances to use SNAT (source network address translation) to communicate with the internet.
This is only available in the Standard SKU (not the basic one).
Each public IP assigned as a frontend IP of your load balancer is given 64,000 SNAT ports for its backend pool members.
Ports can't be shared with backend pool members.
A range of SNAT ports can only be used by a single backend instance to ensure return packets are routed correctly.
It's recommended you use an explicit outbound rule to configure SNAT port allocation. This rule will maximize the number of SNAT ports each backend instance has available for outbound connections.
Using Source Network Address Translation (SNAT) for outbound connections
Outbound rules enable you to explicitly define SNAT (source network address translation) for a Standard Public Load Balancer.
This configuration allows you to use the public IP or IPs of your load balancer for outbound connectivity of the backend instances.
SNAT prevents outside sources from having a direct address to the backend instances.
Â
Explore load balancing
The table below summarizes these categorizations for each Azure load balancing service.
Service | Global/regional | Recommended traffic |
---|---|---|
Azure Front Door | Global | HTTP(S) |
Traffic Manager | Global | non-HTTP(S) |
Application Gateway | Regional | HTTP(S) |
Azure Load Balancer | Regional | non-HTTP(S) |
Â
HTTP(S) load-balancing services are Layer 7 load balancers that only accept HTTP(S) traffic.
They are intended for web applications or other HTTP(S) endpoints
Â
Load Balancer Types
Two products are available when you create a load balancer in Azure: basic load balancers and standard load balancers.
Basic load balancers allow:
Port forwarding
Automatic reconfiguration
Health probes
Outbound connections through source network address translation (SNAT)
Diagnostics through Azure Log Analytics for public-facing load balancers
Basic load balancers can be used only with Virtual machines in a single availability set or a virtual machine scale set.
Basic load balancer is offered at no charge
Standard load balancers support all of the basic features. They also allow:
HTTPS health probes
Availability zones
Diagnostics through Azure Monitor, for multidimensional metrics
High availability (HA) ports
Outbound rules
A guaranteed SLA (99.99% for two or more virtual machines)
Â
Health Probes
Â
A very detailed description on how to setup probes for TCP and HTTP: Load Balancer health probes
When using load-balancing rules with Azure Load Balancer, you need to specify health probes to allow Load Balancer to detect the backend endpoint status.
The configuration of the health probe and probe responses determine which backend pool instances will receive new flows.
You can use health probes to detect the failure of an application on a backend endpoint.
You can also generate a custom response to a health probe and use the health probe for flow control to manage load or planned downtime.
When a health probe fails, Load Balancer will stop sending new flows to the respective unhealthy instance.
Outbound connectivity is not impacted, only inbound connectivity is impacted.
Probe types: TCP, HTTP (Basic SKU) and TCP, HTTP, HTTPS (Standard SKU).
Load Balancer health probes originate from the IP address 168.63.129.16Â
HTTP(S) Load Balancer health probes will automatically probe down an instance if the server returns any status code that is not HTTP 200 OK or if the connection is terminated via TCP reset.
Health probe configuration consists of the following elements:
Duration of the interval between individual probes
Protocol of the probe
Port of the probe
HTTP path to use for HTTP GET when using HTTP(S) probes
Pricing and SLA
Â
See: Pricing and SLA
Â
Internal and external load balancers
Â
Â
An external load balancer operates by distributing client traffic across multiple virtual machines.
Permits traffic from the internet.
An internal load balancer distributes a load from internal Azure resources to other Azure resources.
No traffic is allowed from internet sources.
Â
Session Persistence
Â
To programmatically set the LB to use session persistence. This is done through the LoadDistribution property being set to sourceIp
$lb = Get-AzLoadBalancer -Name MyLb -ResourceGroupName MyResourceGroup
$lb.LoadBalancingRules[0].LoadDistribution = 'sourceIp'
Set-AzLoadBalancer -LoadBalancer $lb
Â
Â
Load Balancing
Â
Understand Azure load balancing - Pay attention to the global vs regional use and the type of traffic.
The following table summarizes the Azure load balancing services by these categories:
Service | Global/regional | Recommended traffic |
---|---|---|
Azure Front Door | Global | HTTP(S) |
Traffic Manager | Global | non-HTTP(S) |
Application Gateway | Regional | HTTP(S) |
Azure Load Balancer | Regional + Global | non-HTTP(S) |
Â
Â
Creating a LB from Portal
Â
See Quickstart: Create a public load balancer to load balance VMs using the Azure portal
Â
Â
Front-end load balancer. You also need to create a public IP
Â
Create a backend pool
A backend address pool contains the IP addresses of the virtual (NICs) connected to the load balancer.
Â
Â
Create a health probe
The load balancer monitors the status of your app with a health probe.
The health probe adds or removes VMs from the load balancer based on their response to health checks.
Â
Create a load balancer rule
A load balancer rule is used to define how traffic is distributed to the VMs. You define the frontend IP configuration for the incoming traffic and the backend IP pool to receive the traffic. The source and destination port are defined in the rule.
Â
Create the virtual network
Â
Create the VNET and its full address space.
Add subnet range
Â
Add a Bastion
Design and implement Azure load balancer using the Azure portal
Â
Design and implement Azure load balancer using the Azure portal
Azure Load Balancer distributes inbound flows that arrive at the load balancer's front end to backend pool instances.
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.
External load balancers are used to distribute client traffic from the internet across your VMs.
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.
Azure load balancer and availability zones
A Load Balancer can either be zone redundant, zonal, or non-zonal
In a region with Availability Zones, a Standard Load Balancer can be zone-redundant.
This traffic is served by a single IP address.
The frontend's IP address is served simultaneously by multiple independent infrastructure deployments in multiple availability zones.
Â
You can choose to have a frontend guaranteed to a single zone, which is known as a zonal.
This scenario means any inbound or outbound flow is served by a single zone in a region.
Your frontend shares fate with the health of the zone.
You can use zonal frontends to expose an IP address per Availability Zone.
Â
Â
Creating and configuring an Azure load balancer
Â
Add load balancing rule
Session persistence specifies that traffic from a client should be handled by the same virtual machine in the backend pool for the duration of a session.
None specifies that successive requests from the same client may be handled by any virtual machine.
Idle timeout(minutes): Specify the time to keep a TCP or HTTP connection open without relying on clients to send keep-alive messages.
The default idle timeout is 4 minutes, which is also the minimum setting. The maximum setting is 30 minutes.
Floating IP: Choose between Disabled or Enabled. With Floating IP set to Disabled, Azure exposes a traditional load balancing IP address mapping scheme for ease of use (the VM instances' IP).
With Floating IP set to Enabled, it changes the IP address mapping to the Frontend IP of the load balancer to allow for additional flexibility.
Â