BACK-END CONFIGURATION
The back-end pool defines the back-end servers over which the load balancer will distribute incoming traffic.
When using a Basic-tier load balancer, this back-end pool must comprise either a single vir- tual machine, virtual machines in the same availability set, or a VM scale set. If using a VM scale set, traffic will be distributed to all virtual machines in the VM scale set. You cannot distribute traffic to multiple virtual machines unless they are members of the same availability set or VM scale set.
With a Standard-tier load balancer, these restrictions are lifted. Back-end pools can com- prise a combination of virtual machines across availability sets and VM scale sets.
HEALTH PROBES
Azure Load Balancer supports continual health probing of back-end pool instances to deter- mine which instances are healthy and able to receive traffic. The load balancer will stop send- ing traffic flows to any back-end pool instance that is determined to be unhealthy. Unhealthy instances continue to receive health probes, so the load balancer can resume sending traffic to that instance once it returns to a healthy state.
Azure Load Balancer supports three types of health probes:
- TCP Probes attempt to initiate a connection by completing a three-way TCP handshake (SYN, SYN-ACK, ACK). If successful, the connection is then closed with a four-way handshake (FIN, ACK, FIN, and ACK).
- HTTP Probes issue an HTTP GET with a specified path.
- HTTPS Probes are similar to HTTP probes, except that a TLS/SSL wrapper is used. HTTPS probes are only supported on the Standard-tier load balancer.
All three probe types must also specify the probe port or the interval. The minimum probe interval is five seconds in length, and the minimum consecutive probe failure threshold is two seconds. For HTTP and HTTPs probes, the probe path must also be given.
An endpoint is marked as unhealthy if
- For HTTP or HTTPS probes only, the endpoint returns an HTTP status code other than 200 OK.
- The probe endpoint closes the connection using a TCP reset.
- The probe endpoint fails to respond to a consecutive number of requests during the timeout period. The number of failed requests required to mark the endpoint unhealthy is configurable.
Configuring a dedicated health check page, such as /healthcheck.php, enables each back- end server to implement custom application logic to determine whether it is healthy. Checking the availability of a back-end database is an example of this.
When configuring network security groups (NSGs) for back-end servers, it is important to allow both inbound traffic and probe traffic. Azure Load Balancer does not modify the source IP address of inbound traffic, so inbound traffic rules should be configured as if the load balancer were not in use. To whitelist inbound probe traffic, allow traffic originating from the AzureLoadBalancer service tag.