通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

网络性能故障排除

  • 项目

概述

Azure 提供了一种稳定、快速地将本地网络连接到 Azure 的方法。 站点到站点 VPN 和 ExpressRoute 等方法被各种规模的客户成功用于在 Azure 中运行业务。 但是，若性能不满足期望或先前经验，会发生什么呢？ 本文可帮助对测试特定环境和为其设置基线时使用的方法进行规范。

你将了解如何采用一致的方法轻松测试两台主机之间的网络延迟和带宽。 本文还就如何查看 Azure 网络以帮助隔离问题点提供了一些建议。 所讨论的 PowerShell 脚本和工具需要网络上有两台主机（在所测试链接的任一端）。 一台主机必须是 Windows Server 或 Desktop，而另一台可以是 Windows 或 Linux。

网络要素

深入了解故障排除之前，先来讨论一些常用术语和要素。 这可确保我们思考 Azure 中支持连接的端到端链中的每个要素。

使用 ExpressRoute 或 VPN 在本地与 Azure 之间建立的网络路由域的示意图。

在最高级别，有三个主要的网络路由域：

  • Azure 网络（蓝色云）
  • Internet 或 WAN（绿色云）
  • 企业网络（橙色云）

从右到左查看关系图，我们来简要讨论一下每个要素：

  • 虚拟机 - 服务器可以有多个 NIC。 请确保任何静态路由、默认路由和操作系统设置都按照预想的方式发送和接收流量。 此外，每个 VM SKU 具有带宽限制。 如果使用较小的 VM SKU，流量会受到 NIC 可用带宽的限制。 建议使用 DS5v2 进行测试，以确保 VM 上有足够的带宽。

  • NIC - 确保你知道分配给问题 NIC 的专用 IP。

  • NIC NSG - 可能在 NIC 级别应用特定的 NSG。 确保 NSG 规则集适合于正尝试传递的流量。 例如，确保已打开 iPerf 的 5201 端口、RDP 的 3389 或 SSH 22，可让测试流量通过。

  • VNet 子网 - 将 NIC 分配给特定子网。 确保你已了解与该子网关联的规则和规则。

  • 子网 NSG - NSG 与 NIC 一样可应用于子网级别。 确保 NSG 规则集适合于正尝试传递的流量。 对于 NIC 的入站流量，将首先应用子网 NSG，然后应用 NIC NSG。 当流量从 VM 出站时，首先应用 NIC NSG，然后应用子网 NSG。

  • 子网 UDR - 用户定义的路由可将流量定向到中间跃点（如防火墙或负载均衡器）。 确保你知道是否存在 UDR 可用于你的流量。 如果存在，请了解它指向何处，以及下一跃点将如何影响你的流量。 例如，防火墙可在两台相同主机之间传递一些流量，并拒绝其他一些流量。

  • 网关子网/NSG/UDR - 网关子网与 VM 子网一样可具有 NSG 和 UDR。 确保你知道是否存在这两者，以及它们对流量的影响。

  • VNet 网关 (ExpressRoute) - 启用对等互连 (ExpressRoute) 或 VPN 后，不会有许多设置会影响到流量路由方式及是否进行流量路由。 如果你有一个连接到多个 ExpressRoute 线路或 VPN 隧道的虚拟网络网关，则应注意连接权重设置。 连接权重会影响连接首选项，并确定流量所采用的路径。

  • 路由筛选器（未显示）- 在通过 ExpressRoute 使用 Microsoft 对等互连时，需要使用路由筛选器。 如果未收到任何路由，请检查路由筛选器是否已正确配置且已正确应用到线路。

此时，你处于链接的 WAN 部分。 此路由域可以是服务提供商、公司 WAN 或 Internet。 这些链路涉及很多跃点、设备和公司，这可能会使故障排除变得很困难。 你需要首先排除 Azure 和公司网络，然后才能调查这两者之间的跃点。

上图中，最左侧是公司网络。 根据公司大小，此路由域可以是你和 WAN 之间的一些网络设备，或是校园/企业网络中的多层设备。

考虑到这三种不同高层级网络环境的复杂性，从边缘处开始，试着显示性能好的地方及性能降低的地方，通常来说是最佳的方式。 此方法可帮助识别这三种环境的问题路由域。 然后，可将故障排除重点放在该特定环境上。

工具

可使用 ping 和 traceroute 等基本工具对大多数网络问题进行分析及隔离。 基本上不需要像使用 Wireshark 等工具进行数据包分析那样深入。

为了帮助进行故障排除，开发了 Azure 连接工具包 (AzureCT) 将这些工具中的一部分放入简单的包中。 对于性能测试，iPerf 和 PSPing 之类的工具可为你提供网络相关信息。 iPerf 是用于基本性能测试的常用工具，使用起来很方便。 PSPing 是由 SysInternals 开发的 ping 工具。 PSPing 可执行 ICMP 和 TCP ping 来连接到远程主机。 这两个工具都是轻量级的，只需将文件复制到主机的目录便可轻松“安装”。

这些工具和方法已打包到一个 PowerShell 模块 (AzureCT) 中，可供你安装和使用。

AzureCT - Azure 连接工具包

AzureCT PowerShell 模块包含两个组成部分 - 可用性测试和性能测试。 本文档重点介绍性能测试，特别是此 PowerShell 模块中的两个链接性能命令。

使用此工具包进行性能测试有以下三个基本步骤：

  1. 安装 PowerShell 模块

    (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression

    此命令用于下载 PowerShell 模块，并将其安装在本地。

  2. 安装支持性应用程序

    Install-LinkPerformance

    此 AzureCT 命令将 iPerf 和 PSPing 安装在新目录“C:\ACTTools”中，还会打开 Windows 防火墙端口以允许 ICMP 和端口 5201 (iPerf) 流量。

  3. 运行性能测试

    首先，iPerf 需在远程主机上安装，在服务器模式下运行。 确保远程主机在 3389 (RDP for Windows) 或 22 (SSH for Linux) 上进行侦听，并在 iPerf 端口 5201 上允许流量。 如果远程主机是 Windows，请安装 AzureCT 并运行 Install-LinkPerformance 命令来设置 iPerf 和必要的防火墙规则。

    远程计算机准备就绪后，在本地计算机上打开 PowerShell 并启动测试：

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10

    此命令运行一系列的并发负荷和延迟测试，以估计带宽容量和网络链接延迟。

  4. 查看测试输出

    PowerShell 输出格式看起来类似于：

    链接性能测试的 PowerShell 输出的屏幕截图。

    所有 iPerf 和 PSPing 测试的详细结果都保存于“C:\ACTTools”上 AzureCT 工具目录中的单个文本文件中。

故障排除

如果性能测试结果不符合预期，请按照系统方法确定问题。 考虑到路径中的组件数，分步过程会比随机测试更有效。

注意

此处的情况是出现了性能问题而非连接问题。 若要隔离与 Azure 网络的连接问题，请按照“验证 ExpressRoute 连接”一文进行操作。

  1. 怀疑假设

    确保预期合理。 例如，对于 1 Gbps ExpressRoute 线路和 100 毫秒的延迟，由于 TCP 在高延迟链路上的性能特征，希望获得完整的 1 Gbps 流量是不切实际的。 有关更多性能假设信息，请参阅引用部分。

  2. 从网络边缘开始

    从路由域之间的边缘开始，试着将问题隔离到一个主要的路由域。 避免将问题归咎于路径中的“黑匣子”而不进行彻底调查，因为这样会导致延迟执行解决方案。

  3. 创建关系图

    绘制相关区域的图示，以有条不紊地处理和隔离问题。 规划测试点，在清除区域或深入挖掘时更新地图。

  4. 分治法

    细分网络并缩小问题范围。 确定运行正常和不正常的位置，并不断移动测试点以隔离有问题的组件。

  5. 考虑所有 OSI 层

    虽然专注于网络和第 1-3 层（物理层、数据和网络层）是常见做法，但请记住，第 7 层（应用程序层）也可能出现问题。 保持开放的心态，验证所有假设。

高级 ExpressRoute 故障排除

如果不确定云边缘在哪里，隔离 Azure 组件可能会很困难。 使用 ExpressRoute 时，边缘是名为 Microsoft 企业边缘 (MSEE) 的网络要素。 MSEE 是进入 Microsoft 网络的第一个接触点，也是离开 Microsoft 网络时的最后一个跃点。 在虚拟网络网关和 ExpressRoute 线路之间创建连接时，会连接到 MSEE。 将 MSEE 识别为第一个或最后一个跃点对于隔离 Azure 网络问题至关重要。 了解流量方向有助于确定问题是否在 Azure 中或 WAN 或企业网络中的更下游。

连接到 ExpressRoute 线路的多个虚拟网络的示意图。

注意

MSEE 不在 Azure 云中。 ExpressRoute 位于 Microsoft 网络边缘，而不是在 Azure 中。 通过 ExpressRoute 连接到 MSEE 后，你就连接到了 Microsoft 网络，然后便可访问云服务，例如 Microsoft 365（使用 Microsoft 对等互连）或 Azure（使用专有和/或 Microsoft 对等互连）。

如果两个 Vnet 连接到同一个 ExpressRoute 线路，你可执行相关测试来隔离 Azure 中的问题。

测试计划

  1. 在 VM1 和 VM2 之间运行 Get-LinkPerformance 测试。 此测试提供有关问题是否为本地问题的见解。 如果此测试造成的延迟和带宽结果是可接受的，则可将本地虚拟网络标记为良好。

  2. 如果本地虚拟网络流量状态良好，则在 VM1 和 VM3 之间运行 Get-LinkPerformance 测试。 此测试通过 Microsoft 网络实现连接到 MSEE ，然后再连回 Azure。 如果此测试造成的延迟和带宽结果是可接受的，则可将 Azure 网络标记为良好。

  3. 如果排除了 Azure，请在公司网络上执行类似的测试。 如果这些测试的结果同样良好，请与服务提供商或 ISP 合作来诊断 WAN 连接。 例如，在两个分支机构之间运行此测试，或在桌面和数据中心服务器之间进行测试。 找到可实现你正在测试路径的终结点（例如服务器和客户端电脑）。

重要

对于每个测试，请标记一天中的时间，并将结果记录在常用位置。 每个测试运行都应具有相同的输出，以便实现一致的数据比较。 使用 AzureCT 进行故障排除主要是因为可实现多个测试间的一致性。 密钥每次都会获得一致的测试和数据输出。 如果问题偶尔出现，记录时间并获得一致的数据特别有用。 要勤于提前采集数据，这样可避免重复测试相同的方案。

隔离了问题，然后呢？

你越使问题孤立，就能越快找到解决方案。 有时，你会遇到一个无法进一步进行故障排除的点。 例如，你可能会看到服务提供商中的链接采用通过欧洲的跃点，但你预期路径会在亚洲。 此时，请根据隔离问题的路由域与某人联系以获取帮助。 将该问题缩小范围到特定组件会更好。

对于公司网络问题，内部 IT 部门或服务提供商可帮助进行设备配置或硬件修复。

对于 WAN 问题，请与服务提供商或 ISP 共享测试结果，以帮助他们完成工作并避免出现冗余任务。 他们可能希望根据信任但需要验证原则来验证结果。

对于 Azure 问题，在尽可能详细地隔离问题后，请查看 Azure 网络文档，并根据需要打开支持票证。

参考

延迟/带宽预期

提示

终结点之间的地理距离是延迟的最大因素。 虽然设备延迟（物理和虚拟组件、跃点数等）也起着作用，但光纤运行距离（而非直线距离）是主要起作用的因素。 此距离难以准确测量，因此我们经常使用城市距离计算器进行粗略估计。

例如，我们在美国华盛顿州西雅图设置了 ExpressRoute。 下表显示了在测试各种 Azure 位置时观察到的延迟和带宽，以及估计的距离。

测试设置：

  • 运行 Windows Server 2016 的物理服务器，其 NIC 为 10 Gbps 且连接到 ExpressRoute 线路。

  • 已启用具备专用对等互连的 10 Gbps Premium ExpressRoute 线路。

  • 指定的区域中具有 UltraPerformance 网关的 Azure 虚拟网络。

  • 在虚拟网络上运行 Windows Server 2016 的 DS5v2 VM，使用安装了 AzureCT 的默认 Azure 映像。

  • 所有测试都使用了 AzureCT Get-LinkPerformance 命令，而且 6 个测试运行都有 5 分钟的负载测试。 例如：

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300

  • 每个测试的数据流都从本地服务器（西雅图的 iPerf 客户端）流向 Azure VM（所列 Azure 区域中的 iPerf 服务器）。

  • “延迟”列显示的数据来自无负载测试（iPerf 未运行情况下的 TCP 延迟测试）。

  • “最大带宽”列显示的数据来自窗口大小为 1 Mb 的 16 TCP 流负载测试。

安装了 AzureCT 的测试环境的示意图。

延迟/带宽结果

重要

这些数字仅供一般参考。 许多因素会影响延迟，尽管这些值在一段时间内通常一致，但 Azure 或服务提供商网络中的条件可能会改变，从而影响延迟和带宽。 通常，这些改变造成的影响不会带来显著差异。

ExpressRoute 位置 Azure 区域 估计距离 (km) 延迟 1 会话带宽 最大带宽
西雅图 美国西部 2 191 km 5 ms 262.0 Mbits/sec 3.74 Gbits/sec
西雅图 美国西部 1,094 km 18 ms 82.3 Mbits/sec 3.70 Gbits/sec
西雅图 美国中部 2,357 km 40 ms 38.8 Mbits/sec 2.55 Gbits/sec
西雅图 美国中南部 2,877 km 51 ms 30.6 Mbits/sec 2.49 Gbits/sec
西雅图 美国中北部 2,792 km 55 ms 27.7 Mbits/sec 2.19 Gbits/sec
西雅图 美国东部 2 3,769 km 73 ms 21.3 Mbits/sec 1.79 Gbits/sec
西雅图 美国东部 3,699 km 74 ms 21.1 Mbits/sec 1.78 Gbits/sec
西雅图 日本东部 7,705 km 106 ms 14.6 Mbits/sec 1.22 Gbits/sec
西雅图 英国南部 7,708 km 146 ms 10.6 Mbits/sec 896 Mbits/sec
西雅图 西欧 7,834 km 153 ms 10.2 Mbits/sec 761 Mbits/sec
西雅图 澳大利亚东部 12,484 km 165 ms 9.4 Mbits/sec 794 Mbits/sec
西雅图 东南亚 12,989 km 170 ms 9.2 Mbits/sec 756 Mbits/sec
西雅图 巴西南部* 10,930 km 189 ms 8.2 Mbits/sec 699 Mbits/sec
西雅图 印度南部 12,918 km 202 ms 7.7 Mbits/sec 634 Mbits/sec

* 巴西的延迟便是一个例子，其中的光纤运行距离明显不同于直线距离。 预期延迟约为 160 毫秒，但由于光纤路由较长，实际延迟为 189 毫秒。

注意

这些数字是通过 PowerShell 在 Windows 中使用基于 iPerf 的 AzureCT 测试而得出。 iPerf 不遵循缩放因子的默认 Windows TCP 选项，并且对 TCP 窗口大小使用较低的移位计数。 通过使用 -w 交换机和更大的 TCP 窗口大小来优化 iPerf 命令，可以实现更好的吞吐量。 从多台计算机在多线程模式下运行 iPerf 也有助于达到最大链接性能。 若要在 Windows 上获得最佳 iPerf 结果，请使用“Set-NetTCPSetting -AutoTuningLevelLocal Experimental”。 在做出任何更改之前，都需检查组织策略。

后续步骤