
PaaS / IaaS support
Load balancing services in Microsoft Azure work with all the tenant types (IaaS or PaaS) and all OS flavors (Windows or any Linux based OS supported). PaaS tenants are configured via the service model. IaaS tenants are configured either via the Management Portal or via PowerShell.Layer-4 Load Balancer, Hash based distribution
Microsoft Azure Load Balancer is a Layer-4 type load balancer. Microsoft Azure load balancer distributes load among a set of available servers (virtual machines) by computing a hash function on the traffic received on a given input endpoint. The hash function is computed such that all the packets from the same connection (TCP or UDP) end up on the same server. The Microsoft Azure Load Balancer uses a 5 tuple (source IP, source port, destination IP, destination port, protocol type) to calculate the hash that is used to map traffic to the available servers. The hash function is chosen such that the distribution of connections to servers is fairly random. However, depending on traffic pattern, it is possible for different connections to get mapped to the same server. (Note that the distribution of connections to servers is NOT round robin, neither there is any queuing of requests, as has been mistakenly mentioned in some articles and some blogs). The basic premise of the hash function is given a lot of requests coming from a lot of different clients, you will get a nice distribution of requests across the servers.Multiple Protocol Support
Load balancing services in Microsoft Azure supports TCP and UDP protocols. Customers can specify protocol in the specification of input endpoint in their service model, via PowerShell or the Management Portal.Multiple Endpoint Support
A hosted service can specify multiple input endpoints and they will automatically get configured on the load balancing service. Currently, multiple endpoints with the same port AND protocol are not supported. There is also a limit of the maximum number of endpoints a hosted service can have which is currently set to 150.Internal Endpoint Support
Every service can specify up to 25 internal endpoints that are not exposed to the load balancer and are used for communicating between the service roles.Direct Port Endpoint Support (Instance Input Endpoint)
A hosted service can specify that a given endpoint should not be load balanced and get direct access to the virtual machine hosting the service. This allows an application to control a possible redirect of a client directly to a given instance of the application (VM) without having each request load balanced (and as a result potentially land to a different instance).Automatic reconfiguration on scale out/down, service healing and updates
The load balancing service works in conjunction with Microsoft Azure Compute Service to ensure that if the number of servers instances specified for an input endpoint scales up or down (either due to increasing the instance count for web/worker role or due to putting additional persistent VMs under the same load balancing group), the load balancing service automatically reconfigures itself to load balance to the increased or decreased instances. The load balancing service also transparently reconfigures itself in response to service healing actions by the Microsoft Azure fabric controller or service updates by the customer.Service Monitoring
The load balancing service offers the capability to probe for health of the various server instances and to take unhealthy server instances out of rotation. There are three types of probes supported: Guest Agent probe (on PaaS VMs), HTTP custom probes and TCP custom probes. In the case of Guest Agent, load balancing service queries the Guest Agent in the VM to learn about the status of the service. In the case of HTTP, load balancing service relies on fetching a specified URL to determine the health of an instance. For TCP, it relies on successful TCP session establishment to a defined probe port.Source NAT (SNAT)
All outbound traffic originating from a service is Source NATed (SNAT) using the same VIP address as for incoming traffic. We will dive into how SNAT works in a future post.Intra Data Center Traffic Optimization
Microsoft Azure Load Balancer optimizes traffic between Microsoft Azure datacenters in the same region, such that traffic between Azure tenants that talk over the VIP and are within the same region, after TCP/IP connection is initiated, they bypass Microsoft Azure Load Balancer altogether.VIP Swap
Microsoft Azure Load Balancer allows the swapping of the VIP of two tenants, allowing the move of a tenant that is in “stage” to “production” and vice versa. The VIP Swap operation allows the client to be using the same VIP to talk to the service, while a new version of the service is deployed. The new version of the service can be deployed and tested without interfering with the production traffic, in a staging environment. Once the new version passes any tests needed, it can be promoted to production, by swapping with the existing production service. Existing connections to the “old” production continue un-altered. New connections are directed to the “new” production environment.Example: Load Balanced Service
Next we will see how most of the above features offered by the load balancing service can be used in a sample cloud service. The PaaS tenant we want to model is shown in the diagram below:
<ServiceDefinition name="ProbeTenant">
<LoadBalancerProbes>
<LoadBalancerProbe name="MyProbe" protocol="http" path="Probe.aspx" intervalInSeconds="5" timeoutInSeconds="100" />
</LoadBalancerProbes>
<WorkerRole name="BERole" vmsize="Small">
<Endpoints>
<InternalEndpoint name="BE_InternalEP_Tcp" protocol="tcp" />
<InternalEndpoint name="BE_InternalEP_Udp" protocol="udp" />
<InternalEndpoint name="BE_InternalEP_Http" protocol="http" port="80" />
<InstanceInputEndpoint name="InstanceEP_BE" protocol="tcp" localPort="80">
<AllocatePublicPortFrom>
<FixedPortRange min="10210" max="10220" />
</AllocatePublicPortFrom>
</InstanceInputEndpoint>
</Endpoints>
</WorkerRole>
<WorkerRole name="FERole" vmsize="Small">
<Endpoints>
<InputEndpoint name="FE_External_Http" protocol="http" port="10000" />
<InputEndpoint name="FE_External_Tcp" protocol="tcp" port="10001" />
<InputEndpoint name="FE_External_Udp" protocol="udp" port="10002" />
<InputEndpointname="HTTP_Probe" protocol="http" port="80" loadBalancerProbe="MyProbe" />
<InstanceInputEndpoint name="InstanceEP" protocol="tcp" localPort="80">
<AllocatePublicPortFrom>
<FixedPortRange min="10110" max="10120" />
</AllocatePublicPortFrom>
</InstanceInputEndpoint>
<InternalEndpoint name="FE_InternalEP_Tcp" protocol="tcp" />
</Endpoints>
</WorkerRole>
</ServiceDefinition>
<LoadBalancerProbes>
<LoadBalancerProbe name="MyProbe" protocol="http" path="Probe.aspx" intervalInSeconds="5" timeoutInSeconds="100" />
</LoadBalancerProbes>
<InputEndpoint name="FE_External_Http" protocol="http" port="10000" />
<InputEndpoint name="FE_External_Tcp" protocol="tcp" port="10001" />
<InputEndpoint name="FE_External_Udp" protocol="udp" port="10002" />
<InputEndpoint name="HTTP_Probe" protocol="http" port="80" loadBalancerProbe="MyProbe" />
<InstanceInputEndpoint name="InstanceEP" protocol="tcp" localPort="80">
<AllocatePublicPortFrom>
<FixedPortRange min="10110" max="10120" />
</AllocatePublicPortFrom>
</InstanceInputEndpoint>
<InternalEndpoint name="FE_InternalEP_Tcp" protocol="tcp" />
<InternalEndpoint name="BE_InternalEP_Tcp" protocol="tcp" />
<InternalEndpoint name="BE_InternalEP_Udp" protocol="udp" />
<InternalEndpoint name="BE_InternalEP_Http" protocol="http" port="80" />
<InstanceInputEndpoint name="InstanceEP_BE" protocol="tcp" localPort="80">
<AllocatePublicPortFrom>
<FixedPortRange min="10210" max="10220" />
</AllocatePublicPortFrom>
</InstanceInputEndpoint>