Get started creating an Internet facing load balancer for cloud services

An Azure load balancer is a Layer-4 (TCP, UDP) load balancer. The load balancer provides high availability by distributing incoming traffic among healthy service instances in cloud services or virtual machines in a load balancer set. Azure Load Balancer can also present those services on multiple ports, multiple IP addresses, or both.

You can configure a load balancer to:

  • Load balance incoming Internet traffic to virtual machines (VMs). We refer to a load balancer in this scenario as an Internet-facing load balancer.
  • Load balance traffic between VMs in a virtual network (VNet), between VMs in cloud services, or between on-premises computers and VMs in a cross-premises virtual network. We refer to a load balancer in this scenario as an internal load balancer (ILB).
  • Forward external traffic to a specific VM instance.

Important

Before you work with Azure resources, it's important to understand that Azure currently has two deployment models: Azure Resource Manager and classic. Make sure you understand deployment models and tools before you work with any Azure resource. You can view the documentation for different tools by clicking the tabs at the top of this article. This article covers the classic deployment model. You can also Learn how to create an Internet facing load balancer using Azure Resource Manager.

Cloud services are automatically configured with a load balancer and can be customized via the service model.

Create a load balancer using the service definition file

You can leverage the Azure SDK for .NET 2.5 to update your cloud service. Endpoint settings for cloud services are made in the service definition .csdef file.

The following example shows how a servicedefinition.csdef file for a cloud deployment is configured:

Checking the snippet for the .csdef file generated by a cloud deployment, you can see the external endpoint configured to use ports HTTP on port 10000, 10001, and 10002.

<ServiceDefinition name="Tenant">
    <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" />

            <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" />
        </Endpoints>
    </WorkerRole>
</ServiceDefinition>

Check load balancer health status for cloud services

The following is an example of a health probe:

<LoadBalancerProbes>
    <LoadBalancerProbe name="MyProbe" protocol="http" path="Probe.aspx" intervalInSeconds="5" timeoutInSeconds="100" />
</LoadBalancerProbes>

The load balancer combines the information of the endpoint and the information of the probe to create a URL in the form of http://{DIP of VM}:80/Probe.aspx that can be used to query the health of the service.

The service detects periodic probes from the same IP address. This is the health probe request coming from the host of the node where the virtual machine is running. The service has to respond with a HTTP 200 status code for the load balancer to assume that the service is healthy. Any other HTTP status code (for example 503) directly takes the virtual machine out of rotation.

The probe definition also controls the frequency of the probe. In our case above, the load balancer is probing the endpoint every 5 secs. If no positive answer is received for 10 secs (two probe intervals), the probe is assumed down, and the virtual machine is taken out of rotation. Similarly, if the service is out of rotation and a positive answer is received, the service is put back to rotation right away. If the service is fluctuating between healthy and unhealthy, the load balancer can decide to delay the re-introduction of the service back to rotation until it has been healthy for a number of probes.

Check the service definition schema for the health probe for more information.

Next steps

Get started configuring an internal load balancer

Configure a load balancer distribution mode

Configure idle TCP timeout settings for your load balancer