通过

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

  • 项目

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

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

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

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

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

监视负载均衡器可用性

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

数据路径可用性

在配置了负载均衡规则的所有前端端口上，TCP ping 每隔 25 秒就会生成数据路径可用性指标。 然后，此 TCP ping 会路由到任何正常的（探测结果为正常运行的）后端实例。 该指标是在样本时间段内，每个负载均衡规则的每个前端 IP:port 组合上 TCP ping 成功率的汇总百分比。

运行状况探测状态

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

重要

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

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

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

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

接下来，我们需要检查运行状况探测状态指标，以便确定数据路径不可用是不是因为我们没有正常的后端实例来提供流量。 如果我们的所有负载均衡和入站规则都有至少一个正常的后端实例，则表明不是我们的配置导致数据路径不可用。 这种情况表示存在 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 防火墙与负载均衡器正确集成。

后续步骤