I lost a good portion of last week fighting dropping traffic / intermittent connection issues in a basic tier azure load balancer. The project this was working on had been up and running for 6 months without configuration changes and had not been restarted in 100 days. Restarting it did not help, so clearly something had changed about the environment. It also started happening in multiple deployments in different azure subscriptions, implying that it was not an isolated issue or server/etc related.
After doing a crazy amount of tests and eventually escalating to Azure support, who reviewed the problem for over 12 hours, Azure support pointed out this:
“Do not translate or proxy a health probe through the instance that receives the health probe to another instance in your VNet as this configuration can lead to cascading failures in your scenario. Consider the following scenario: a set of third-party appliances is deployed in the backend pool of a Load Balancer resource to provide scale and redundancy for the appliances and the health probe is configured to probe a port that the third-party appliance proxies or translates to other virtual machines behind the appliance. If you probe the same port you are using to translate or proxy requests to the other virtual machines behind the appliance, any probe response from a single virtual machine behind the appliance will mark the appliance itself dead. This configuration can lead to a cascading failure of the entire application scenario as a result of a single backend instance behind the appliance. The trigger can be an intermittent probe failure that will cause Load Balancer to mark down the original destination (the appliance instance) and in turn can disable your entire application scenario. Probe the health of the appliance itself instead.”
I was using a load balancer over a scale set, and the load balancer pointed at HaProxy, which was designed to route traffic to the “primary” server. So, I wanted Azure’s load balancer to consider every server up as long as it could route to the “primary” server, even if other things on this server specifically were down.
But having the health probe check HAProxy meant that the health probe was routed to the “primary” server and triggered this error.
This seems like an Azure quirk to me… but they have it documented. Once I switched the health probe to target something not routed by HaProxy the LB stabilized and everything was ok.