排除網路效能問題

總結

Azure 提供一種穩定且快速的方式，讓你的本地網路連接到 Azure。 各種規模的客戶都使用像是 Site-to-Site VPN 和 ExpressRoute 等方法在 Azure 中經營業務。 但如果表現不符合你的期望或過去經驗，會怎麼辦？ 本文協助你標準化測試方式，並設定特定環境的基準。

你會學會如何輕鬆且一致地測試兩台主機之間的網路延遲與頻寬。 你也會獲得關於如何檢視 Azure 網路以協助找出問題點的建議。 上述 PowerShell 腳本和工具需要在網路上安裝兩個主機（分別位於被測試連結的兩端）。 一台主機必須是 Windows Server 或桌機，另一台則可以是 Windows 或 Linux。

網路元件

在深入故障排除之前，讓我們先討論一些常見的術語和元件。 這項討論可確保您會思考 Azure 中支援連線的端對端鏈結中的每個元件。

在最高層級，有三大主要的網路路由領域：

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

從右到左看圖，讓我們簡要討論每個元件：

• 虛擬機 ——伺服器可能有多個網卡。 確保任何靜態路由、預設路由和作業系統設定都能如你預期的方式發送和接收流量。 另外，每個虛擬機 SKU 都有頻寬限制。 如果你使用的是較小的虛擬機 SKU，流量會受到網卡可用頻寬的限制。 使用 DS5v2 進行測試，以確保虛擬機的頻寬足夠。

• 網卡 - 確保你知道該網卡所指派的私有 IP。

• NIC NSG -可能在 NIC 層級會套用特定的 NSG。 確保 NSG 規則集適合你想通過的流量。 例如，請確保 iPerf 埠 5201、RDP 埠 3389 或 SSH 埠 22 開啟，以允許測試流量通過。

• VNet 子網 - 網卡會被指派到特定的子網。 確保你知道是哪一個子網以及該子網的相關規則。

• 子網 NSG ——就像 NIC 一樣，你也可以在子網層級套用 NSG。 請確認 NSG 規則集適用於您要允許通過的流量。 對於進入 NIC 的流量，先適用子網 NSG，接著是 NIC NSG。 當流量從虛擬機輸出時，會先套用 NIC NSG，然後才套用子網路 NSG。

• 子網 UDR - User-Defined 路由可將流量導向中間跳點，如防火牆或負載平衡器。 確保你知道你的網路流量是否有 UDR 設定。 如果是，請了解它流向何處，以及下一跳對流量的影響。 例如，防火牆可能會讓部分流量通過，並拒絕同一兩台主機之間的其他流量。

• 閘道子網 / NSG / UDR ——就像 VM 子網一樣，閘道子網也可以有 NSG 和 UDR。 務必知道它們是否存在，以及它們對流量的影響。

• VNet 閘道器（ExpressRoute） -一旦啟用對等連接（ExpressRoute）或 VPN，就沒有太多設定會影響流量路由方式或是否會被路由。 如果你有一個虛擬網路閘道連接多個 ExpressRoute 迴路或 VPN 隧道，請注意連線權重設定。 連線權重會影響連線偏好，並決定流量的路徑。

• 路由篩選器（未顯示）－透過 ExpressRoute 使用 Microsoft 對等互連時，需要路由篩選器。 如果你沒有收到任何路由，請檢查路由過濾器是否已正確設定並套用到電路上。

此時，你已經在 WAN 網路段。 這個路由網域可以是你的服務提供商、企業廣域網，或是網際網路。 這些連線牽涉到許多中繼節點、裝置和公司，因此難以進行疑難排解。 你必須先排除 Azure 和你的企業網路，才能調查中間的跳數。

在前圖中，最左邊是你的企業網路。 根據公司規模，這個路由域可能是你與 WAN 之間的幾個網路裝置，或是校園或企業網路中的多層裝置。

鑑於這三種不同高階網路環境的複雜性，最佳的做法通常是從邊界開始，嘗試展示效能良好的位置與性能下降的區域。 此方法有助於辨識三者中問題路由領域。 這樣你就可以把故障排除重點放在那個特定的環境上。

工具

你可以利用 ping 和 traceroute 等基本工具分析並隔離大多數網路問題。 很少需要像使用 Wireshark 這類工具進行封包分析那樣深入。

為了協助故障排除，開發了 Azure 連接工具包（AzureCT），將部分工具整合成簡易的套件。 在效能測試方面，像 iPerf 和 PSPing 這類工具能提供網路資訊。 iPerf 是基本效能測試常用的工具，且相當容易使用。 PSPing 是由 SysInternal 開發的一種 ping 工具。 PSPing 可以同時執行 ICMP 和 TCP 的 ping 來連接遠端主機。 這兩種工具都很輕量，只要將檔案複製到主機上的目錄即可「安裝」。

你可以使用 PowerShell 模組（AzureCT）來包裝這些工具和方法。

AzureCT - Azure 連線工具包

AzureCT PowerShell 模組包含兩個元件：Availability Testing 以及 Performance Testing。 本文聚焦於效能測試，特別是本 PowerShell 模組中的兩個 Link Performance 指令。

要使用此工具包進行效能測試，請遵循以下三個基本步驟：

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）其中之一上接聽，並允許 iPerf 使用 5201 連接埠的流量通過。 如果遠端主機Windows，安裝 AzureCT，並執行 Install-LinkPerformance 指令來設定 iPerf 和必要的防火牆規則。

   當遠端機器準備好後，在本地電腦上開啟 PowerShell 並開始測試：

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   此指令會執行一系列同時負載與延遲測試，以估算網路連結的頻寬容量與延遲。

4. 檢視測試結果

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

   

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

針對效能問題進行疑難排解

如果效能測試結果與預期不符，請採取系統化的方法來找出問題所在。 鑑於路徑中元件數量，逐步進行比隨機測試更有效。

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 或企業網路。

如果兩個 VNet 連接到 same ExpressRoute 電路，你可以在 Azure 中進行測試來找出問題。

測試計劃

1. 在 VM1 和 VM2 之間跑 Get-LinkPerformance 測試。 此檢定能提供問題是否局部性的洞察。 如果測試的延遲和頻寬結果都可接受，你可以將本地虛擬網路標記為良好。

2. 假設本地虛擬網路流量正常，就在 VM1 和 VM3 之間執行 Get-LinkPerformance 測試。 此測試會透過 Microsoft 網路一路連接到 MSE，再回到 Azure。 如果測試延遲和頻寬結果可接受，就可以標記 Azure 網路為良好。

3. 如果排除 Azure，可以在企業網路上做類似測試。 如果這些測試也正常，請與你的服務提供商或 ISP 合作診斷你的 WAN 連線問題。 例如，在兩個分公司之間或你的辦公桌與資料中心伺服器之間進行測試。 找出可以執行您正在測試路徑的端點，例如伺服器和用戶端電腦。

問題已被識別和隔離，接下來我們該怎麼做？

你越能找出問題，就越能找到解決方案。 有時候，你會遇到無法再進一步排除故障的地步。 例如，你可能會看到你的服務連結穿過歐洲的多個節點進行跳轉，而你預期它會停留在亞洲。 這時，請根據你鎖定的問題所在的路由網域，尋求他人協助。 聚焦於特定元件會更好。

對於企業網路問題，您的內部 IT 部門或服務提供者可以協助裝置設定或硬體維修。

對於 WAN 問題，請將測試結果分享給你的服務提供商或 ISP，幫助他們處理工作，避免重複工作。 他們可能會根據信任原則來驗證你的結果， 但一定要確認。

針對Azure問題，一旦你盡可能詳細地找出問題，請檢視 Azure 網路文件，必要時開啟支援工單。

參考資料

延遲與頻寬預期

舉例來說，你在美國華盛頓州西雅圖設立了一條 ExpressRoute。 下表顯示你在測試不同 Azure 位置時觀察到的延遲與頻寬，以及估計距離。

測試設置：

• 一台運行 Windows Server 2016 的實體伺服器，搭配 10 Gbps 網卡，連接至 ExpressRoute 電路。

• 一個 10 Gbps 的 Premium ExpressRoute 電路，啟用了私有對等連線。

• 一個在指定區域內使用 UltraPerformance 閘道器的 Azure 虛擬網路。

• 一台 DS5v2 虛擬機在虛擬網路上運行 Windows Server 2016，使用預設的 Azure 映像檔並安裝 AzureCT。

• 所有測試皆使用 AzureCT Get-LinkPerformance 指令，且在六次測試執行中的每一次都進行 5 分鐘的負載測試。 例如：

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• 每個測試的資料流程是從本地伺服器（西雅圖的 iPerf 用戶端）到 Azure 虛擬機（位於列出的 Azure 區域的 iPerf 伺服器）。

• 「Latency」欄位顯示無負載測試（TCP 延遲測試，未執行 iPerf 時的數據）。

• 「最大頻寬」欄位顯示 16 TCP 流量負載測試中 1 Mb 視窗大小的資料。

延遲與頻寬結果

* 巴西的延遲時間是光纖鋪設距離與直線距離顯著差異的例子。 預期延遲約為 160 毫秒，但實際上是因為光纖路線較長，延遲是 189 毫秒。

後續步驟

• 下載 Azure 連接工具包
• 請依照指示進行link效能測試