我们有一个高可用性网站，我们正在尝试将其迁移到 Azure。我们基本上有一个 Azure 标准负载均衡器，具有公共 IP 和后端池中的 2 个虚拟机。
我们注意到，如果其中一台虚拟机出现故障（主机出现故障或应用程序池等出现故障），标准负载均衡器会检测到主机不健康，但会继续向主机发送现有连接。
这意味着已经在运行不正常的后端 VM 上进行过会话的最终用户将继续被发送到那里，并且通常只会收到一般的 HTTP 错误。以新连接形式进入的用户将成功发送到后端池中的运行正常的主机。
我们的负载均衡器设置为不保持状态，因此理论上新的连接将随机分布在下面的主机之间，并且会话超时为 4 分钟（Azure 允许的最低值）。
我们在这里是否遗漏了什么，或者这只是 Azure 负载均衡器的预期行为？
答案1
这是预期的行为。探测行为如下：
新的 TCP 连接将成功到达健康且具有能够接受新流的客户操作系统和应用程序的后端实例。
如果后端实例的运行状况探测失败，则与该后端实例建立的 TCP 连接将继续。
如果后端池中所有实例的所有探测均失败，则不会向后端池发送任何新流。标准负载均衡器将允许已建立的 TCP 流继续。基本负载均衡器将终止流向后端池的所有现有 TCP 流。
由于流程始终在客户端和虚拟机的客户操作系统之间进行，因此所有探测器都关闭的池将导致前端不响应 TCP 连接打开尝试，因为没有健康的后端实例来接收流程。
参考：负载均衡器运行状况探测