通过

排查资源运行状况和入站可用性问题

  • 项目

本文介绍了如何调查影响负载均衡器前端 IP 和后端资源的可用性的问题。

负载均衡器的资源运行状况检查 (RHC) 用于确定负载均衡器的运行状况。 它在 2 分钟间隔内分析数据路径可用性指标，以确定负载均衡终结点、前端 IP 和具有负载均衡规则的前端端口组合是否可用。

注意：基本 SKU 负载均衡器不支持 RHC

下表描述了用于确定负载均衡器的运行状况状态的 RHC 逻辑。

资源运行状况 说明
可用 标准负载均衡器资源正常且可用。
已降级 标准负载均衡器具有平台或用户启动的影响性能的事件。 “数据路径可用性”指标至少有两分钟报告了低于 90% 但高于 25% 的运行状况。 你会遇到中等到严重程度的性能降低。
不可用 标准负载均衡器资源不正常。 “数据路径可用性”指标至少有两分钟报告了低于 25% 的正常运行。 你遇到严重的性能降低，或者入站连接不可用。 可能存在导致不可用的用户或平台事件。
未知 标准负载均衡器资源的资源运行状况尚未更新，或者最近 10 分钟内未收到数据路径可用性信息。 此状态是暂时性的，系统在收到数据后会立即反映正确的状态。

关于我们使用的指标

要使用的两个指标是“数据路径可用性”和“运行状况探测状态”，必须了解其含义才能得出正确的见解。

数据路径可用性

在配置了负载均衡和入站 NAT 规则的所有前端端口上，TCP ping 每隔 25 秒就会生成数据路径可用性指标。 然后，此 TCP ping 会路由到任何正常的（探测结果为正常运行的）后端实例。 如果服务收到对 ping 的响应，则这是一个成功的响应，并且指标的总和将迭代一次。 如果没有响应，则不会发生迭代。 此指标的计数为每个采样期间的 TCP ping 的总数的 1/100。 因此，我们希望考虑平均值，这是该时间段内的总和/计数的平均值。 因此，按平均值聚合的数据路径可用性指标为每个负载均衡规则和入站 NAT 规则提供了针对前端 IP:端口的 TCP ping 的成功率百分比。

运行状况探测状态

运行状况探测状态指标是由运行状况探测中定义的协议的 ping 生成的。 此 ping 将发送到后端池中的每个实例，以及运行状况探测中定义的端口上。 对于 HTTP 和 HTTPS 探测，成功的 ping 要求获得 HTTP 200 OK 响应，而对于 TCP 探测，任何响应都会被视为成功。 可以根据每个探测的连续成功或失败状态确定后端实例的运行状况，以及分配的后端池是否能够接收流量。 与数据路径可用性类似，我们使用平均聚合，它告诉我们在采样间隔期间的平均成功/总计 ping 数。 此运行状况探测状态值通过探测后端实例而不通过前端来发送流量，指示与负载均衡器隔离的后端运行状况。

重要

运行状况探测状态每分钟采样一次。 这可能会导致本应稳定的值出现轻微波动。 例如，如果有两个后端实例，一个的探测结果为正常运行，另一个的探测结果为关闭，则运行状况探测服务可以为正常的实例捕获 7 个样本，为不正常的实例捕获 6 个样本。 这将导致以前的稳定值 50 在一分钟时间间隔内显示为 46.15。

诊断降级的和不可用的负载均衡器

如资源运行状况一文中所述，性能下降的负载均衡器显示了 25% 到 90% 的数据路径可用性。 不可用的负载均衡器是指在两分钟内数据路径可用性低于 25% 的负载均衡器。 可以采取这些相同的步骤来调查在你配置的任何运行状况探测状态或数据路径可用性警报中看到的失败。 我们将探讨一个案例。在该案例中，我们在检查了资源运行状况后发现，如果数据路径可用性为 0%，则我们的负载均衡器不可用 - 我们的服务已关闭。

首先，我们在 Azure 门户中转到负载均衡器见解页的详细指标视图。 从负载均衡器资源页或资源运行状况消息中的链接访问视图。 接下来，我们导航到前端和后端可用性选项卡，查看一个出现降级或不可用状态的三十分钟时段窗口。 如果我们发现数据路径可用性为 0%，则表明有一个问题阻碍了所有负载均衡和入站 NAT 规则的流量，我们可以看到此问题的持续时间。

接下来，我们需要检查运行状况探测状态指标，以便确定数据路径不可用是不是因为我们没有正常的后端实例来提供流量。 如果我们的所有负载均衡和入站规则都有至少一个正常的后端实例，则表明不是我们的配置导致数据路径不可用。 这种情况表示存在 Azure 平台问题。 虽然平台问题非常少见，但如果出现，系统会向我们的团队发送自动警报，以便快速解决所有平台问题。

诊断运行状况探测失败

假设我们检查运行状况探测状态后发现所有实例都显示为不正常。 此检查结果说明了为何数据路径不可用，其表现为流量无处可去。 接下来，我们应按以下清单进行检查，以排除常见的配置错误：

  • 检查资源的 CPU 利用率，以确定资源负载是否过高。
  • 如果使用了 HTTP 或 HTTPS 探测，请检查应用程序是否正常运行且可做出响应。
    • 通过专用 IP 地址或与后端实例关联的实例级公共 IP 地址直接访问应用程序，以验证应用程序是否正常运行。
  • 查看应用于后端资源的网络安全组。 确保不存在优先级高于 AllowAzureLoadBalancerInBound 的规则，这种规则会阻止运行状况探测。
    • 为此，可访问后端 VM 或虚拟机规模集的“网络”设置。
    • 如果你发现存在此 NSG 问题，请移动现有的 Allow 规则，或创建一个新的高优先级规则以允许 AzureLoadBalancer 流量。
  • 检查 OS。 确保 VM 侦听的是探测端口并检查其 OS 防火墙规则，以确保它们不会阻止来自 IP 地址 168.63.129.16 的探测流量。
    • 可以通过从 Windows 命令提示符运行 netstat -a 或从 Linux 终端运行 netstat -l 来检查侦听端口。
  • 确保使用正确的协议。 例如，如果一个探测使用 HTTP 来探测非 HTTP 应用程序的端口侦听情况，则会失败。
  • 不应将 Azure 防火墙放置在负载均衡器的后端池中。 请参阅将 Azure 防火墙与 Azure 标准负载均衡器集成，以将 Azure 防火墙与负载均衡器正确集成。

如果已按此清单检查完毕，但仍然发现运行状况探测失败，则可能存在影响实例的探测服务的罕见平台问题。 在这种情况下，Azure 会为你提供支持。系统会向我们的团队发送自动警报，因此可以快速解决所有平台问题。

后续步骤