Internal load balancing
Updated: October 8, 2014
Azure Internal Load Balancing (ILB) provides load balancing between virtual machines that reside inside of a cloud service or a virtual network with a regional scope. For information about the use and configuration of virtual networks with a regional scope, see Regional Virtual Networks in the Azure blog. Existing virtual networks that have been configured for an affinity group cannot use ILB.
ILB enables the following new types of load balancing:
Within a cloud service, from virtual machines to a set of virtual machines that reside within the same cloud service (see Figure 1).
Within a virtual network, from virtual machines in the virtual network to a set of virtual machines that reside within the same cloud service of the virtual network (see Figure 2).
For a cross-premises virtual network, from on-premises computers to a set of virtual machines that reside within the same cloud service of the virtual network (see Figure 3).
In all cases, the set of virtual machines receiving the incoming, load-balanced traffic—known as the internal load-balanced set—must reside within the same cloud service. You cannot create an internal load-balanced set that contains virtual machines from more than one cloud service.
The existing Azure load balancing only provides load balancing between Internet-based computers and virtual machines in a cloud service. ILB enables new capabilities for hosting virtual machines in Azure.
For additional information, see Internal Load Balancing in the Azure blog.
You can use ILB in many new configurations, including the following:
Internet-facing, multi-tier applications in which the back-end tiers are not Internet-facing but require load balancing for traffic from the Internet-facing tier.
Load balancing for line-of-business (LOB) applications hosted in Azure without requiring additional load balancer hardware or software.
Including on-premises servers in the set of computers whose traffic is load balanced.
The following sections describe these configurations in more detail.
Figure 1 shows an example of a multi-tier application using web servers as the front end and database servers as the back end in a cloud service.
Figure 1: ILB for Internet-facing, multi-tier applications in a cloud service
In this example:
The web tier has public-facing endpoints for Internet clients and is part of a load-balanced set. The load balancer randomly distributes incoming traffic from web clients to TCP port 443 (HTTPS) to the servers of the web tier.
The database tier that the web tier uses for storage does not have public-facing endpoints. However, the load of database access and storage must be spread across multiple database servers. To facilitate this, the database tier has endpoints and is part of an internal load-balanced set. The ILB randomly distributes web server requests from the web servers to the servers of the database tier for TCP port 1433 (SQL Server traffic).
Figure 2 shows another example of a multi-tier application, this time as multiple cloud services within a virtual network.
Figure 2: ILB for Internet-facing, multi-tier applications between cloud services in a virtual network
In this example, ILB is providing the same distribution of web requests to the servers of the database tier, except that the virtual machines in the web and database tiers are in different cloud services. This is only possible if both cloud services are in the same virtual network.
SQL Server AlwaysOn Availability Groups can be run with ILB. For more information, see SQL Server AlwaysOn and ILB in the Azure blog.
For intranet LOB applications running on Azure virtual machines in a cross-premises Azure virtual network, ILB can perform load balancing for traffic from intranet clients. Figure 3 shows an example.
Figure 3: LOB applications hosted in Azure
Traffic from clients on the on-premises network get load-balanced across the set of LOB servers running in a cross-premises virtual network, without requiring a separate load balancer in the on-premises network or in the virtual network.
ILB also allows traffic from servers on the on-premises network to be load-balanced across virtual machines running in a cross-premises virtual network. Figure 4 shows an example.
Figure 4: ILB for including on-premises servers
In Figure 4, the private IP address of the web server in the on-premises network sends its requests to the ILB, which distributes them across the servers in the database tier.
|ILB does not support adding an on-premises server to the set of servers to which traffic is being distributed. For example, in Figure 4, you cannot add a database server in the on-premises network to the set of servers in the database tier.|
To configure ILB, you must do the following:
Create an instance of an ILB, which gets assigned a virtual IP (VIP) address from the pool of addresses for the cloud service or virtual network. You can also specify the VIP and subnet when the virtual machines are inside a virtual network.
Add endpoints corresponding to the virtual machines that will receive the load-balanced traffic.
Configure the servers whose traffic will be load-balanced to send their traffic to the VIP of the ILB instance, or to a DNS name that resolves to the VIP of ILB instance.
Steps 1 and 2 must be done with Windows PowerShell commands. For more information, see Configure an internal load-balanced set.
Note that you can convert an existing load-balanced set (for Internet traffic) to an internal load-balanced set and convert an existing internal load-balanced set to a load-balanced set (for Internet traffic).