We have a highly available website which we are trying to migrate to Azure. We basically have an Azure Standard Load Balancer with a public IP and 2 VMs in the backend pool.

We have noticed that if 1 of the VMs fails (Either the host fails or something like the App Pool fails) the standard load balancer detects that the host is unhealthy but continues to send existing connections to the host.

This means end users who already have a session on the unhealthy backend VM continue to be sent there and often just get a generic HTTP error. Users who are coming in as new connections are succesfully sent to the healthy host in the backend pool.

Our load balancer is setup to not hold state so in theory new connections will be randomly distributed between the hosts underneath and with a session timeout of 4 minutes (The lowest Azure lets us go).

Is there something we have missed here or is this just the expected behaviour of Azure's load balancers?


It's the expected behavior. The probes down behavior are as bellows:

New TCP connections will succeed to backend instance which is healthy and has a guest OS and application able to accept a new flow.

If a backend instance's health probe fails, established TCP connections to this backend instance continue.

If all probes for all instances in a backend pool fail, no new flows will be sent to the backend pool. Standard Load Balancer will permit established TCP flows to continue. Basic Load Balancer will terminate all existing TCP flows to the backend pool.

Because the flow is always between the client and the VM's guest OS, a pool with all probes down will cause a frontend to not respond to TCP connection open attempts as there is no healthy backend instance to receive the flow.

References: Load Balancer health probes

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.