Load balancing refers to efficiently distributing incoming network traffic across a group of backend servers or resources.
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.
Balancing multi-tier applications by using both public and internal Load Balancer
Note :- Azure provides a suite of fully managed load-balancing solutions for your scenarios.
If you are looking to do DNS based global routing and do not have requirements for Transport Layer Security (TLS) protocol termination (“SSL offload”), per-HTTP/HTTPS request or application-layer processing, review Traffic Manager.
If you want to load balance between your servers in a region at the application layer, review Application Gateway.
If you need to optimize global routing of your web traffic and optimize top-tier end-user performance and reliability through quick global failover, see Front Door.
Your end-to-end scenarios may benefit from combining these solutions as needed. For an Azure load-balancing options comparison, see Overview of load-balancing options in Azure.
Key scenarios that you can accomplish using Azure Standard Load Balancer include:
Load balance internal and external traffic to Azure virtual machines.
Increase availability by distributing resources within and across zones.
Configure outbound connectivity for Azure virtual machines.
Use health probes to monitor load-balanced resources.
Employ port forwarding to access virtual machines in a virtual network by public IP address and port.
Enable support for load-balancing of IPv6.
Standard load balancer provides multi-dimensional metrics through Azure Monitor. These metrics can be filtered, grouped, and broken out for a given dimension. They provide current and historic insights into performance and health of your service. Insights for Azure Load Balancer offers a preconfigured dashboard with useful visualizations for these metrics. Resource Health is also supported. Review Standard load balancer diagnostics for more details.
Load balance services on multiple ports, multiple IP addresses, or both.
Move internal and external load balancer resources across Azure regions.
Load balance TCP and UDP flow on all ports simultaneously using HA ports.
Chain Standard Load Balancer and Gateway Load Balancer.
Virtual networks and availability zones
Virtual networks and subnets span all availability zones in a region. You don’t need to divide them by availability zones to accommodate zonal resources. For example, if you configure a zonal VM, you don’t have to take into consideration the virtual network when selecting the availability zone for the VM. The same is true for other zonal resources.
What is an availability set?
Availability sets are logical groupings of VMs that reduce the chance of correlated failures bringing down related VMs at the same time. Availability sets place VMs in different fault domains for better reliability, especially beneficial if a region doesn’t support availability zones. When using availability sets, create two or more VMs within an availability set. Using two or more VMs in an availability set helps highly available applications and meets the 99.95% Azure SLA. There’s no extra cost for using availability sets, you only pay for each VM instance you create.
Availability sets offer improved VM to VM latencies compared to availability zones, since VMs in an availability set are allocated in closer proximity. Availability sets have fault isolation for many possible failures, minimizing single points of failure, and offering high availability. Availability sets are still susceptible to certain shared infrastructure failures, like datacenter network failures, which can affect multiple fault domains.
For more reliability than availability sets offer, use availability zones. Availability zones offer the highest reliability since each VM is deployed in multiple datacenters, protecting you from loss of either power, networking, or cooling in an individual datacenter. If your highest priority is the best reliability for your workload, replicate your VMs across multiple availability zones.
How do availability sets work?
Each virtual machine in your availability set is assigned an update domain and a fault domain by the underlying Azure platform. Each availability set can be configured with up to 3 fault domains and 20 update domains. These configurations can’t be changed once the availability set has been created. Update domains indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. When more than five virtual machines are configured within a single availability set with five update domains, the sixth virtual machine is placed into the same update domain as the first virtual machine, the seventh in the same update domain as the second virtual machine, and so on. The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time. A rebooted update domain is given 30 minutes to recover before maintenance is initiated on a different update domain.
Fault domains define the group of virtual machines that share a common power source and network switch. By default, the virtual machines configured within your availability set are separated across up to three fault domains. While placing your virtual machines into an availability set doesn’t protect your application from operating system or application-specific failures, it does limit the impact of potential physical hardware failures, network outages, or power interruptions.
What are Azure Fault and Update Domains?
Azure Fault and Update Domains are logical groupings of Azure resources that are designed to help you distribute your workloads across different physical hardware and software components, thereby reducing the risk of downtime due to hardware or software failures or updates.
A fault domain is a logical grouping of resources that share a common physical hardware platform, such as a rack, server, or power source. In other words, all resources in a fault domain share the same failure domain. Azure ensures that no two resources in the same fault domain are running on the same physical hardware platform. This means that if one physical hardware platform fails, only the resources in that fault domain are affected, and the rest of your resources continue to function normally. (Eg: RACKS)
An update domain, on the other hand, is a logical grouping of resources that share a common software update policy. Azure ensures that no two resources in the same update domain are updated at the same time. This means that if an update causes a problem, only the resources in that update domain are affected, and the rest of your resources continue to function normally. (Eg: Servers)
What are availability zones?
Many Azure regions provide availability zones, which are separated groups of datacenters within a region. Availability zones are close enough to have low-latency connections to other availability zones. They’re connected by a high-performance network with a round-trip latency of less than 2ms. However, availability zones are far enough apart to reduce the likelihood that more than one will be affected by local outages or weather. Availability zones have independent power, cooling, and networking infrastructure. They’re designed so that if one zone experiences an outage, then regional services, capacity, and high availability are supported by the remaining zones. They help your data stay synchronized and accessible when things go wrong.
Datacenter locations are selected by using rigorous vulnerability risk assessment criteria. This process identifies all significant datacenter-specific risks and considers shared risks between availability zones.
The following diagram shows several example Azure regions. Regions 1 and 2 support availability zones.
What is Azure Virtual Network? (Vnet)
Azure Virtual Network is a service that provides the fundamental building block for your private network in Azure. An instance of the service (a virtual network) enables many types of Azure resources to securely communicate with each other, the internet, and on-premises networks. These Azure resources include virtual machines (VMs).
A virtual network is similar to a traditional network that you’d operate in your own datacenter. But it brings extra benefits of the Azure infrastructure, such as scale, availability, and isolation.
Why use an Azure virtual network?
Key scenarios that you can accomplish with a virtual network include:
Communication of Azure resources with the internet.
Communication between Azure resources.
Communication with on-premises resources.
Filtering of network traffic.
Routing of network traffic.
Integration with Azure services.
Azure resources communicate securely with each other in one of the following ways:
Virtual network: You can deploy VMs and other types of Azure resources in a virtual network. Examples of resources include App Service Environments, Azure Kubernetes Service (AKS), and Azure Virtual Machine Scale Sets. To view a complete list of Azure resources that you can deploy in a virtual network, see Deploy dedicated Azure services into virtual networks.
Virtual network service endpoint: You can extend your virtual network’s private address space and the identity of your virtual network to Azure service resources over a direct connection. Examples of resources include Azure Storage accounts and Azure SQL Database. Service endpoints allow you to secure your critical Azure service resources to only a virtual network. To learn more, see Virtual network service endpoints.
Virtual network peering: You can connect virtual networks to each other by using virtual peering. The resources in either virtual network can then communicate with each other. The virtual networks that you connect can be in the same, or different, Azure regions. To learn more, see Virtual network peering.
Communicate with on-premises resources
You can connect your on-premises computers and networks to a virtual network by using any of the following options:
Point-to-site virtual private network (VPN): Established between a virtual network and a single computer in your network. Each computer that wants to establish connectivity with a virtual network must configure its connection. This connection type is useful if you’re just getting started with Azure, or for developers, because it requires few or no changes to an existing network. The communication between your computer and a virtual network is sent through an encrypted tunnel over the internet. To learn more, see About point-to-site VPN.
Site-to-site VPN: Established between your on-premises VPN device and an Azure VPN gateway that’s deployed in a virtual network. This connection type enables any on-premises resource that you authorize to access a virtual network. The communication between your on-premises VPN device and an Azure VPN gateway is sent through an encrypted tunnel over the internet. To learn more, see Site-to-site VPN.
Azure ExpressRoute: Established between your network and Azure, through an ExpressRoute partner. This connection is private. Traffic doesn’t go over the internet. To learn more, see What is Azure ExpressRoute?.
Filter network traffic
You can filter network traffic between subnets by using either or both of the following options:
Network security groups: Network security groups and application security groups can contain multiple inbound and outbound security rules. These rules enable you to filter traffic to and from resources by source and destination IP address, port, and protocol. To learn more, see Network security groups and Application security groups.
Network virtual appliances: A network virtual appliance is a VM that performs a network function, such as a firewall or WAN optimization. To view a list of available network virtual appliances that you can deploy in a virtual network, go to Azure Marketplace.
Route network traffic
Azure routes traffic between subnets, connected virtual networks, on-premises networks, and the internet, by default. You can implement either or both of the following options to override the default routes that Azure creates:
Route tables: You can create custom route tables that control where traffic is routed to for each subnet.
Border gateway protocol (BGP) routes: If you connect your virtual network to your on-premises network by using an Azure VPN gateway or an ExpressRoute connection, you can propagate your on-premises BGP routes to your virtual networks.
How to configure Load Balancer
Prerequisites
- Resource group
- Vnet
- Availability set
- VMs
- Load Balancer.
Creating Resource Groups
Login to https://Portal.azure.com
Create Virtual Network (VNet)
Create Availability Set (You can create AS while creating VMs as well-Better, sometimes availability set shows greyed out when creating VMs)
A proximity placement group is a logical grouping used to make sure that Azure compute resources are physically located close to each other. Proximity placement groups are useful for workloads where low latency is a requirement.
Next
Create VMs
Since we have 2 VMs for testing Keeping 2 update Domains and 2 fault Domains (Max Fault domains -3 and Max update domain 20)-
Create an Another VM with same RG/VNet/Availability (Pro-NewAS1)set called Pro-App2
Capacity reservations
Capacity reservations allow you to reserve capacity for your virtual machine needs. You get the same SLA as normal virtual machines with the security of reserving the capacity ahead of time.
Host
Azure Dedicated Hosts allow you to provision and manage a physical server within our data centers that are dedicated to your Azure subscription. A dedicated host gives you assurance that only VMs from your subscription are on the host, flexibility to choose VMs from your subscription that will be provisioned on the host, and the control of platform maintenance at the level of the host.
Proximity placement group
Proximity placement groups allow you to group Azure resources physically closer together in the same region.
Now finished Creating Second VM with Same RG/VNet/ AS (Pro-NewAS1) called Pro-App2
Pls Note the Public IPs of VMs.
Now Create Load Balancer
Choose Standard Load Balancer network load balancing when extreme performance is required coupled with low latency. Choose Gateway Load Balancer to deploy, scale, and run third party appliances in Azure with ease
You can use internal load balancers to balance traffic from private IP addresses. Public load balancers can balance traffic originating from public IP addresses.
Now Create a Health Probe
Protocol- TCP/Https /Http (Choose as per requirements)
Port– The destination port for the health signal
Path -The URI used for requesting health status from the backend endpoint.
Interval— The amount of time between probe attempts. (The value must be between 5 and 2147483646, inclusive.)
Create Load Balancer Rules
Backend Port – You can choose to route traffic to the virtual machines in the backend pool using a different port than the one clients use to communicate with the load balancer.
Session Persistence – 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. “Client IP” specifies that successive requests from the same client IP address will be handled by the same virtual machine. “Client IP and protocol” specifies that successive requests from the same client IP address and protocol combination will be handled by the same virtual machine.
Idle Time out (Mnts) – Keep a TCP or HTTP connection open without relying on clients to send keep-alive messages.Floating IP, Azure exposes a traditional load balancing IP address mapping scheme for ease of use (the VM instances’ IP). Enabling Floating IP changes the IP address mapping to the Frontend IP of the load balancer to allow for additional flexibility.
Go to Load Balancer and you could see all configurations.
Now Load Balancer is configured.
Now Install IIS on both the VMs and make changes on IIS web Page on both web servers. Now you can switch off one VM and access website by using Load Balancer Front end IP, Load Balancer would divert its traffic to the available VM. That means Load Balancing is working well even though one server is not available.
Thanks Ranjith.
