共用方式為

網路效能疑難排解

  • 發行項

概觀

Azure 提供穩定且快速的方式，將您的內部部署網路連線到 Azure。 各種規模的客戶已成功使用站對站 VPN 和 ExpressRoute 等方法，在 Azure 中執行其業務。 但是，當效能不符合您的預期或先前體驗時，會發生什麼事？ 本文可協助您將測試方式標準化，並為您的特定環境制訂基準。

您將瞭解如何輕鬆且一致地測試兩部主機之間的網路等待時間和頻寬。 您也會收到如何查看 Azure 網路以協助隔離問題點的建議。 討論的 PowerShell 指令碼和工具在網路上 (要測試之連結的任一端) 需要有兩部主機。 一部主機必須是 Windows Server 或桌面，另一部主機可以是 Windows 或 Linux。

網路元件

深入了解疑難排解之前，讓我們先討論一些通用的術語和構成要素。 這個討論可確保我們將考慮端對端鏈結中，可在 Azure 中連線的每個構成要素。

使用 ExpressRoute 或 VPN 在內部部署至 Azure 之間的網路路由網域圖表。

在最高層級有三種主要網路路由網域：

  • Azure 網路 (藍色雲)
  • 網際網路或 WAN (綠色雲)
  • 公司網路 (橙色雲)

從右至左查看圖表，讓我們簡短討論每個元件：

  • 虛擬機器 - 伺服器可能會有多個 NIC。 確保任何靜態路由、預設路由和作業系統設定都會以您認為的方式傳送和接收流量。 此外，每個 VM SKU 都有頻寬限制。 如果您要使用較小的 VM SKU，則您的流量會受到 NIC 可用頻寬的限制。 我們建議使用 DS5v2 進行測試，以確保 VM 有足夠的頻寬。

  • NIC：請確定您知道指派給上述 NIC 的私人 IP。

  • NIC NSG - NIC 層級可能會套用特定的 NSG。 請確定 NSG 規則集適用於您想要通過的流量 例如，確定已開放連接埠 5201 (用於 iPerf)、3389 (用於 RDP) 或 22 (用於 SSH)，以允許通過測試流量。

  • VNet 子網 - NIC 會指派給特定子網。 請確定您知道哪一個與該子網相關聯的規則。

  • 子網 NSG - 就像 NIC 一樣，NSG 也可以套用在子網層級。 請確定 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 或網際網路。 有許多與這些連結相關的躍點、裝置和公司可能會導致難以進行疑難排解。 您必須先排除 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 命令會在新的目錄中 C:\ACTTools 安裝 iPerf 和 PSPing，並開啟 Windows 防火牆埠以允許 ICMP 和埠 5201 （iPerf） 流量。

  3. 執行效能測試

    首先，在遠端主機上，在伺服器模式中安裝並執行 iPerf。 請確定遠端主機是接聽 3389 ( Windows 的 RDP) 還是 22 (Linux 的 SSH)，並在連接埠 5201 上允許 iPerf 的流量。 如果遠端主機是 Windows，請安裝 AzureCT 並執行 Install-LinkPerformance 命令來設定 iPerf 和必要的防火牆規則。

    一旦遠端電腦準備就緒之後，請在本機電腦上開啟 PowerShell 並開始測試：

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10

    此命令會執行一系列的並行負載和延遲測試，以估計網路連結的頻寬容量和延遲。

  4. 檢閱測試輸出

    PowerShell 輸出格式看起來類似於：

    連結效能測試的PowerShell輸出螢幕快照。

    所有 iPerf 和 PSPing 測試的詳細結果都會儲存在 AzureCT C:\ACTTools工具目錄中的個別文本檔中。

疑難排解

如果效能測試結果未如預期般，請遵循系統化方法來找出問題。 假設路徑中的元件數目，逐步程式比隨機測試更有效率。

注意

以下的案例是效能問題，而不是連線問題。 若要隔離與 Azure 網路的連線問題，請遵循 驗證 ExpressRoute 連線 一文。

  1. 挑戰您的假設

    請確定您的期望是合理的。 例如，使用 1 Gbps ExpressRoute 線路和 100 毫秒的延遲，預期完整的 1 Gbps 流量是不切實際的，因為 TCP 在高延遲連結上的效能特性。 如需 效能假設的詳細資訊，請參閱參考一節 。

  2. 從網路邊緣開始

    從路由網域之間的邊緣開始，並嘗試將問題隔離到單一主要路由網域。 避免在路徑中指責「黑匣子」而不進行徹底調查，因為這可能會延遲解決。

  3. 建立圖表

    繪製有關區域的圖表，以有條不紊地處理並隔離問題。 規劃測試點，並在您清除區域或深入挖掘時更新地圖。

  4. 分裂和征服

    分割網路並縮小問題範圍。 識別其運作位置及其不運作位置，並持續移動測試點以隔離違規元件。

  5. 考慮所有 OSI 層

    雖然專注於網路和第 1-3 層（實體、數據和網路層）是常見的，但請記住，問題也可能發生在第 7 層（應用層）。 請保持開放心態，並確認所有假設。

進階 ExpressRoute 疑難排解

如果您不確定雲端的邊緣在哪裡，隔離 Azure 元件可能會很困難。 使用 ExpressRoute 時，邊緣是稱為 Microsoft Enterprise Edge （MSEE） 的網路元件。 MSEE 是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 位置時觀察到的延遲和頻寬，以及估計的距離。

測試設定：

  • 使用連線到 ExpressRoute 線路的 10 Gbps NIC 執行 Windows Server 2016 的實體伺服器。

  • 已啟用私人對等互連的 10 Gbps Premium ExpressRoute 線路。

  • 在指定的區域中，具有 UltraPerformance 閘道的 Azure 虛擬網路。

  • 在虛擬網路上執行 Windows Server 2016 的 DS5v2 VM，使用已安裝 AzureCT 的預設 Azure 映像。

  • 所有測試都會使用 AzureCT Get-LinkPerformance 命令，並針對六個測試回合的每一個執行執行 5 分鐘負載測試。 例如：

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300

  • 每個測試的數據流都是從內部部署伺服器（西雅圖的 iPerf 用戶端）到 Azure VM（列出的 Azure 區域中的 iPerf 伺服器）。

  • [延遲] 資料行會顯示無負載測試的數據（沒有執行 iPerf 的 TCP 延遲測試）。

  • [最大带寬] 數據行會顯示 16 個 TCP 流量負載測試的數據，其大小為 1 Mb。

安裝 AzureCT 的測試環境圖表。

延遲/頻寬結果

重要

這些數字僅供一般參考。 許多因素會影響延遲，雖然這些值通常會隨著時間而保持一致，但 Azure 或服務提供者網路內的條件可能會變更，因而影響延遲和頻寬。 一般而言，這些變更不會產生顯著的差異。

ExpressRoute 位置 Azure 區域 估計距離（公里） 延遲 1 會話頻寬 最大頻寬
西雅圖 美國西部 2 191 公里 5 毫秒 262.0 Mbits/秒 3.74 Gbits/秒
西雅圖 美國西部 1,094 公里 18 毫秒 82.3 Mbits/秒 3.70 Gbits/秒
西雅圖 美國中部 2,357 公里 40 毫秒 38.8 Mbits/秒 2.55 Gbits/秒
西雅圖 美國中南部 2,877 公里 51 毫秒 30.6 Mbits/秒 2.49 Gbits/秒
西雅圖 美國中北部 2,792 公里 55 毫秒 27.7 Mbits/秒 2.19 Gbits/秒
西雅圖 美國東部 2 3,769 公里 73 毫秒 21.3 Mbits/秒 1.79 Gbits/秒
西雅圖 美國東部 3,699 公里 74 毫秒 21.1 Mbits/秒 1.78 Gbits/秒
西雅圖 日本東部 7,705 公里 106 毫秒 14.6 Mbits/秒 1.22 Gbits/秒
西雅圖 英國南部 7,708 公里 146 毫秒 10.6 Mbits/秒 896 Mbits/秒
西雅圖 西歐 7,834 公里 153 毫秒 10.2 Mbits/秒 761 Mbits/秒
西雅圖 澳大利亞東部 12,484 公里 165 毫秒 9.4 Mbits/秒 794 Mbits/秒
西雅圖 東南亞 12,989 公里 170 毫秒 9.2 Mbits/秒 756 Mbits/秒
西雅圖 巴西南部 * 10,930 公里 189 毫秒 8.2 Mbits/秒 699 Mbits/秒
西雅圖 印度南部 12,918 公里 202 毫秒 7.7 Mbits/秒 634 Mbits/秒

* 巴西的延遲是光纖運行距離與直線距離明顯不同的範例。 預期的延遲大約為 160 毫秒，但由於光纖路由較長，實際上為 189 毫秒。

注意

這些數位是透過PowerShell使用以Windows中的iPerf為基礎的 AzureCT 進行測試。 iPerf 不接受縮放比例的預設 Windows TCP 選項，並且針對 TCP 視窗大小使用較低的 Shift Count。 藉由使用 -w 參數調整 iPerf 命令和較大的 TCP 視窗大小，即可達到更好的輸送量。 從多部機器以多線程模式執行 iPerf，也有助於達到最大連結效能。 若要在 Windows 上取得最佳的 iPerf 結果，請使用 “Set-NetTCPSetting -AutoTuningLevelLocal Experimental”。 進行任何變更之前，請先檢查您的組織原則。

下一步