Before I get started with Azure Load balance, let me show you the topics that I am going to cover in this blog, which will help you to Know Azure Traffic Manager, Internal load balancer and Azure load balancer. In this blog, I have written Multiple Important Topics which will help for your carrier.
Formerly known as Windows Azure, Microsoft Azure is Microsoft’s public cloud computing platform and it offers a range of cloud services including those for analytics, computer, networking, and storage.
The user can pick and select from these services to run existing applications or build and scale new applications in the public cloud. In Azure, load balancing offers a higher level of scale and availability by extending incoming requests covering multiple VMs(virtual machines). The Azure portal can be used for the creation of a load balancer.
In simple words, an Azure Load Balancer can be defined as a cloud-based system that allows a set of machines to perform as one single machine to serve the request of a user.
The job of a load balancer, put simply, is to take on client requests, determine which machines in the set can manage such requests, and finally, forwarding those requests to the relevant machines.
There are several load balancers and numerous algorithms that process requests at various layers in the TCP/IP stack.
* A public load balancer will load-balance the incoming internet traffic to your virtual machines. Load balance the traffic across virtual machines inside a virtual network.
* From an on-premises network in a hybrid scenario, you can also get to a load balancer front end. A configuration known as the Internal Load Balancer is utilized in both scenarios.
* You can also port forward traffic to a particular port on particular virtual machines with inbound NAT(network address translation) rules.
* Azure load balancer enables you to offer outbound connectivity for virtual machines inside your virtual network by utilizing a public load balancer.
Load balancer resources are the objects within which you can express how Azure must program its multi-tenant infrastructure to attain the scenario that you wish to create. There doesn’t exist any direct relationship between the actual infrastructure and load balancer resources. An instance is not created by creating a load balancer and capacity is always available.
The resources of a load balancer either as internal load balancers or public load balancers. The functions of load balancer resources are expressed as a front end, a health probe, a rule, and a backend pool definition. By specifying the backend pool from the virtual machine, you place virtual machines into the backend pool.
For UDP and TCP applications, load balancer offers the following capabilities.
You can create a load-balancing rule with Azure Load Balancer for distributing traffic that approaches to backend from frontend pool instances. Load balancer utilizes a hash-based algorithm for rewriting the headers of flows to backend pool and distribution of inbound flows. When a health probe notifies a healthy backend endpoint, a server is available to receive new flows.
The load balancer, by default, utilizes a 5-tuple hash containing source port, source IP address, destination port, destination IP address, and IP protocol number to map flows to available servers. You can choose to develop an affinity to a particular source IP address by choosing a 2- or 3-tuple hash for the given rule. All packets of the identical packet flow arrive on the same instance at the back of the load-balanced front end. The source port gets changed when the client institutes a new flow from the same source IP. As a result, the 5-tuple might cause the traffic to go to a different backend endpoint.
Load Balancer doesn’t directly interact with UDP or the application layer or TCP, and any UDP or TCP application scenario can be supported. The load balancer doesn’t originate or terminate flows, provides no application layer gateway function, interact with the payload of the flow, and every time, the protocol handshakes directly happen between the backend pool instance and the client. A response from a virtual machine is always a response to an inbound flow. The original source IP address is also preserved when the flow arrives on the virtual machine.
The load balancer uses the health probes that you define in order to determine the health of instances in the backend pool. When a probe fails to respond, the load balancer ends the act of directing new connections to the unhealthy instances. The current connections aren’t affected, and they will continue until the application obstructs the flow, the virtual machine is shut down or an idle timeout occurs. Load balancer offers different health probe types for HTTPS, HTTP, and TCP endpoints.
Load balancer reconfigures itself instantly when you scale instances up or down. When appending or withdrawing virtual machines from the backend pool is done, the load balancer gets reconfigured without any additional operations on the load balancer resource.
All the outbound flows to public IP addresses on the internet from private IP addresses in the virtual network can be translated to the front-end IP address of the load balancer. When the public front end is attached to a backend virtual machine as a form of a load balancing rule, the outbound connections will be translated automatically to the public frontend IP address as programmed by Azure. For more information on this, you can see outbound connections.
Load balancing offers a higher level of scale and availability by extending incoming requests over multiple virtual machines. In this section, we will develop a public load balancer that helps in the load balancing of virtual machines. The standard load balancer supports only a standard public IP address. When you create a standard load balancer, you should also create a new standard public IP address that is configured as the frontend for the standard load balancer. For information on the creation of an Azure load balancer, creation of virtual machines and installing IIS server, creating load balancer resources, viewing a load balancer in action, and adding and removing VMs from a load balancer.
The usage for a standard load balancer is charged depending on the amount of processed outbound and inbound data and the number of configured load-balancing rules. You can see the load balancer pricing page for standard load balancer pricing information.
You can check the load balancer SLA page for more information about the standard load balancer SLA.
A load balancer is a UDP or TCP product for port forwarding and load balancing for these specific IP protocols. Inbound NAT rules and load balancing rules are supported for UDP and TCP and not supported for other IP protocols including ICMP. The load balancer doesn’t interact, respond, or terminate with the payload of a TCP or UDP flow and it is not a proxy.
Unlike public load balancers which offer outbound connections when transitioning to public IP addresses from private IP addresses inside the virtual network, outbound originated connections are not translated by internal load balancers to the internal load balancer frontend as both these are in private IP address space. When the translation isn’t required, this eliminates the possibility of SNAT port exhaustion in the isolated internal IP address space.
The side effect here is that, in the backend pool, if the outbound flow from a virtual machine tries a flow to internal Load Balancer front-end in which pool it stays and is mapped back to itself, both legs of the flow don't match and the flow will fail. Suppose the flow didn’t map back to the same virtual machine in the backend pool(which created the flow to the frontend), the flow will succeed. When the flow maps itself back, the outbound flow seems like it begins from the virtual machine to the frontend and the corresponding inbound flow emerges to kick-off from the virtual machine to itself.
Microsoft's Azure Load Balancer supports load balancing for cloud services and virtual machines to scale applications and provide safety against failure of a single system, which could lead to unwanted downtime and disruption of the service availability.
There are essentially three types of load balancers in Microsoft Azure. They are - Azure Load Balancer, Internal Load Balancer (ILB), and Traffic Manager.
The Azure Load Balancer is considered as a TCP/IP layer 4 load balancer, which uses the hash function on the source IP, source port, destination IP, destination port, and the protocol type to proportionately balance the internet traffic load across distributed virtual machines.
While the Azure Load Balancer utilizes the hash function to allocate the load, the traffic, however, for the source IP, source port, destination IP, destination port, and the protocol type goes to the same endpoint in the course of a session.
If a user closes the session and begins a new session, the traffic generating from the new session might be guided to a separate endpoint than that of the previous session, but all of the traffic coming from the new session will be led to the same endpoint.
The hash function distribution in the Azure Load Balancer leads to an arbitrary endpoint selection, which over the time creates an even distribution of the traffic flow for both UDP and TCP protocol sessions.
The Internal Load Balancer is an Azure Load Balancer that has only an internal-facing Virtual IP. This essentially means users cannot apply an Internal Load Balancer to balance a traffic load coming from the Internet to internal input endpoints.
The Internal Load Balancer implements load balancing only for virtual machines connected to an internal Azure cloud service or a virtual network.
If the Internal Load Balancer is deployed within the Azure cloud service, then all the nodes that have been load balanced need to be a part of the cloud service.
In case the Internal Load Balancer is used inside a virtual network, then all the nodes that have been load balanced must be connected to the same virtual network.
The Traffic Manager load balancer can be described as an Internet-facing solution to balance the traffic load between many endpoints.
The Traffic Manager makes use of a policy engine and a set of DNS queries to steer the traffic to Internet resources. The Internet resource can be settled in one data centre, or multiple data centres spread across the globe.
Traffic Manager is only associated with the determination of the initial endpoint. It is not involved in processing the redirection of each and every packet, and hence, it cannot be viewed as a standard load balancing engine.
The Traffic Manager integrates three categories of load balancing algorithms.
1. Performance Algorithm – Directs the user to the nearest load-balanced node depending on latency.
2. Failover Algorithm – Typically directs the user to the principal node, except if the principal node is down, it redirects the client to a backup node.
3. Round Robin Algorithm – Implements a distributed approach to direct users to a node, using the weights attributed to such nodes.
The Traffic Manager deploys the Azure load balancer algorithm defined by a set of 'intelligent' policies, where every Traffic Manager URL resource is connected to the same set of intelligent policies.
The Traffic Manager also incorporates the functionality to disable or enable endpoints in its policy engine without taking down the endpoint. This provides the capacity to add or eliminate endpoint positions as and when required, or to manage the maintenance of the endpoints easily.
Users requiring multi-tier applications that need global accessibility and scalability can leverage the power of Traffic Manager 'performance' load-balancing algorithm to redirect the clients to the nearest endpoint. This endpoint can be an Azure Load Balancer VIP, which is a load balancing user interface-tier across aggregated nodes.
Every user interface-tier node can put to use an Internal Load Balancer that balances the load of a middleware-tier across various nodes. Every middleware-tier should be connected to an 'SQL Always On Availability Group' data tier, which deploys a 3rd Party Appliance for implementing the SQL listener.
Whatever your load balancing needs might be - whether it's a single-tier or a multi-tier virtual machine or cloud service - Microsoft Azure Load Balancer can offer you flexible tailor-made solutions specifically designed for your deployment environments.
Free Demo for Corporate & Online Trainings.