檢閱設定和計量以診斷問題
監視 Azure Load Balancer 的效能,可為任何可能的失敗提前發出警告。 Azure 監視器提供許多重要的計量,可用來檢視 Load Balancer 的效能趨勢。 如果有一或多部虛擬機器 (VM) 未達到健全狀態探查要求,您也可以觸發警示。
在範例案例中,您將監視負載平衡系統的效能,以確保效能符合需求。 如果效能下降且 VM 連線開始失敗,您會對系統進行疑難排解,以判斷原因並修正問題。 本單元結束時,您將能夠:
- 描述可用來測量負載平衡系統輸送量和效能的計量。
- 使用 Azure 入口網站中的資源健康情況頁面,以監視系統的健康情況。
- 說明如何解決負載平衡系統中常見的問題。
使用 Azure 監視器對 Load Balancer 進行疑難排解
透過 Azure 監視器,您可以擷取及檢查 Load Balancer 的診斷記錄和效能資料。
監視連線
您可以使用 Azure 入口網站中的 [計量] 窗格,將 Load Balancer 的計量視覺化。 從對連線進行疑難排解的觀點來看,最重要的計量是 [資料路徑可用性] 和 [健康狀態探查狀態]。
Load Balancer 持續測試是否有路徑前往前端 IP 位址、通過負載平衡規則和後端集區,然後到達 VM 上執行的應用程式。 此資訊會記錄為資料路徑可用性計量。 套用 [平均] 計量會顯示特定時間間隔的平均可用性。 此彙總是介於 0 (無可用性) 和 100 之間的值,其中,從前端 IP 位址到後端集區中的 VM,至少有一個成功的路徑可用。
健全狀態探查狀態計量也類似,但僅適用於 VM 的健全狀態探查,而不適用於通過 Load Balancer 的完整路徑。 同樣,此計量的平均彙總提供介於 0 (所有 VM 都狀況不良,無法回應) 和 100 (所有 VM 都回應健全狀態探查) 之間的值。
針對在後端集區有兩個 VM 的負載平衡器,下列螢幕擷取畫面顯示其平均「資料路徑可用性」和平均「健全狀態探查狀態」的圖表。 其中一部機器並未回應健康狀態探查。 平均健全狀態探查狀態暫留在約 50% 的標記。
檢查這些計量的另一個方法,是使用計數彙總。 這種方法可以提供其他關於設定潛在問題的深入解析。 下列範例顯示「健全狀態探查狀態」和「資料路徑可用性」計量的計數圖表。 此圖表顯示一段時間內成功完成探查的數量。
此圖表有趣的是成功的「資料路徑可用性」探查次數保持在一致範圍內。 不過,成功的「健全狀態探查狀態」檢查次數短暫暴增,隨即降到大約尖峰之前的一半。
在用來產生此圖形的設定中,後端集區只包含兩部 VM。 為了模擬失敗,其中一部機器已停止。 「資料路徑可用性」計量指出用戶端應用程式仍可能連線至仍在運作中 VM 上執行的應用程式。 但健全狀態探查狀態指出後端集區整體的「健康情況」只有先前的一半。
檢視服務健康狀態
Load Balancer 的 [資源健康狀態] 頁面報告系統的整體狀態。 您可在入口網站中從 Azure 監視器存取此頁面。 選取 [服務健康狀態],選取 [資源健康狀態],然後選取 [Load Balancer] 作為資源類型。
選取負載平衡器。 您會看到一份報告詳述您的服務的健康情況歷程記錄。 您可以展開報告中的任何項目來檢視詳細資料。 下圖顯示後端集區的其中一部 VM 離線時所產生的摘要。
監視每部 VM 的工作負載
Load Balancer 還有其他計量,可讓您追蹤每個「前端」通過 Load Balancer 的位元組和網路封包數量。 Load Balancer IP 位址、用來接受傳入要求的通訊協定,以及供負載平衡規則用來連線至 VM 的連接埠號碼,組成前端的定義。 這些計量可衡量每個使用中 VM 的系統輸送量。
下圖顯示以 500 個並行使用者執行測試工作負載兩分鐘時,流經 Load Balancer 的平均封包計數。 工作負載執行兩次。 第一次時,後端集區包含兩個 VM 執行個體。 執行第二次時,其中一個 VM 已關機 (模擬失敗)。
在此圖表中,當一部 VM 關機時,每個前端的平均封包計數會加倍。 此工作量可能使剩餘的 VM 超載,導致回應時間延長,甚至逾時。
調查及補救 Load Balancer 的常見問題
本節涵蓋您可能會在 Load Balancer 中遇到的一些常見失敗案例。 每個情節概述失敗的徵兆,以及解決問題的可能方法。
Load Balancer 後方 VM 未回應探查連接埠上的流量
此問題可能起因於下列問題:
後端集區的 VM 未在正確的探查連接埠上接聽。
請確認 Load Balancer 中的健康狀態探查是否設定正確。 確定每部 VM 上執行的應用程式程式碼適當回應探查要求。 應該傳回 HTTP 200 (確定) 回應訊息。
裝載 VM 的虛擬網路子網路 NSG 封鎖探查連接埠。
檢查 VM 所在虛擬網路子網路的 NSG 設定。 確定 NSG 允許來自 Load Balancer 的流量通過健康狀態探查連接埠。
您嘗試從相同的 VM 和虛擬網路卡存取 Load Balancer。 此問題與探查無關,而是不支援的資料路徑情節。
您正嘗試從後端集區的 VM 存取 Load Balancer 前端。
這兩項都是應用程式設計問題。 避免從後端集區的 VM 將要求傳送至相同的 Load Balancer 執行個體。
後端集區的 VM 狀況不良
在此情況下,大部分的 VM 都能夠正常回應,但總有一兩部會出狀況。 由於一部分 VM 接受流量,健全狀態探查的設定大概正確。 子網路的 NSG 未封鎖健全狀態探查使用的連接埠。 問題可能與狀況不良的 VM 有關。 此問題可能是因為 VM 無法存取或已關閉,或這些機器上發生應用程式問題。
使用下列步驟來判斷狀況不良 VM 有問題的原因:
- 登入狀況不良的 VM,驗證是否已啟動。 檢查 VM 是否可以回應來自後端集區的其他 VM 提出的基本檢查,例如 ping、rdp 或 ssh 要求。
- 如果 VM 已啟動且可供存取,請確認應用程式正在執行。
- 執行
netstat -an
命令,並確認健全狀態探查和應用程式使用的連接埠列為 LISTENING。
Load Balancer 設定錯誤
Load Balancer 要求您正確設定路由規則,將前端傳入的流量導向後端集區。 如果路由規則遺失或未正確設定,則會卸除抵達前端的流量。 一旦卸除流量,應用程式就會對用戶端回報無法存取。
驗證路由自前端通過 Load Balancer 到達後端集區。 您可以使用 Ping、TCPing 和 netsh 等工具,適用於 Windows 和 Linux。 您也可以在視窗上使用 psping。 下列各節說明如何使用這些工具。
使用 ping
ping 命令會測試透過端點使用 ICMP 通訊協定的 ping 連線。 若要驗證路由是否從用戶端通過 Load Balancer 到達 VM,請執行下列命令。 將 <IP 位址> 換成 Load Balancer 執行個體的 IP 位址。
ping -n 10 <ip address>
Switch | 說明 |
---|---|
-n | 此切換會指定要傳送的 Ping 要求數目。 |
一般輸出類似如下:
ping -n 10 nn.nn.nn.nn
Pinging nn.nn.nn.nn with 32 bytes of data:
Reply from nn.nn.nn.nn: bytes=32 time=34ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Ping statistics for nn.nn.nn.nn:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 34ms, Average = 30ms
使用 PsPing
PsPing 命令會測試透過端點的 ping 連線能力。 此命令也測量服務的延遲和頻寬可用性。 若要驗證路由是否從用戶端通過 Load Balancer 到達 VM,請執行下列命令。 將 <IP 位址> 和 連接埠<> 換成 Load Balancer 執行個體的 IP 位址和前端連接埠。
psping -n 100 -i 0 -q -h <ip address>:<port>
旗標 | 說明 |
---|---|
-n | 指定要執行的 ping 次數。 |
-i | 表示反覆測試之間的間隔秒數。 |
-q | 抑制 ping 期間的輸出。 只在結束時顯示摘要。 |
-h | 列印長條圖來顯示要求的延遲。 |
一般輸出類似如下:
TCP connect to nn.nn.nn.nn:nn:
101 iterations (warmup 1) ping test: 100%
TCP connect statistics for nn.nn.nn.nn:nn:
Sent = 100, Received = 100, Lost = 0 (0% loss),
Minimum = 7.48ms, Maximum = 9.08ms, Average = 8.30ms
Latency Count
7.48 3
7.56 2
7.65 2
7.73 2
7.82 7
7.90 4
7.98 4
8.07 6
8.15 9
8.24 9
8.32 11
8.40 7
8.49 11
8.57 12
8.66 3
8.74 2
8.82 2
8.91 1
8.99 2
9.08 1
使用 tcping
tcping 公用程式類似於 ping,不同之處在於它會透過 TCP 連線而非 ICMP 運作。 使用 tcping,如下所示:
tcping <ip address> <port>
一般輸出類似如下:
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.042ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.810ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.266ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.181ms
Ping statistics for nn.nn.nn.nn:nn
4 probes sent.
4 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 9.042ms, Maximum = 9.810ms, Average = 9.325ms
使用 netsh
netsh 公用程式是一般用途的網路設定工具。 在 netsh 中使用 trace 命令來擷取網路流量。 然後,使用 Wireshark 之類的工具來分析。 測試經過 Load Balancer 的連線能力時,使用 netsh trace 來檢查 psping 傳送和接收的網路封包,如下所示:
以系統管理員身分執行命令提示字元,在此啟動網路追蹤。 下列範例追蹤往返特定 IP 位址的網際網路用戶端流量 (HTTP 要求)。 將 <IP 位址> 換成 Load Balancer 執行個體的位址。 追蹤資料會寫入名為 trace.etl 的檔案。
netsh trace start ipv4.address=<ip address> capture=yes scenario=internetclient tracefile=trace.etl
執行 psping,以透過 Load Balancer 測試連線。
psping -n 100 -i 0 -q <ip address>:<port>
停止追蹤。
netsh trace stop
此命令建立追蹤輸出檔案時會將資訊相互關聯和合併,需要幾分鐘才能完成。
啟動 Wireshark 並開啟追蹤檔案。
將下列篩選條件新增至追蹤。 將 <nn> 換成 Load Balancer 前端連接埠號碼。
TCP.Port==80 or TCP.Port==<nn>
將 HTTP 要求來源和目的地當作欄位新增至追蹤輸出。
檢查追蹤訊息:
- 如果沒有封包傳入 Load Balancer,表示可能發生網路安全性問題或使用者定義的路由問題。
- 如果沒有傳出封包傳回給用戶端,表示可能發生應用程式設定問題或使用者定義的路由問題。
VM 防火牆或 NSG 封鎖連接埠
如果網路和 Load Balancer 已正確設定,VM 已啟動,且應用程式正在執行,則 VM 的防火牆或 NSG 設定可能會封鎖健全狀態探查或應用程式所使用的連接埠。 使用下列步驟來判斷這是否為此情況:
如果 VM 上有防火牆,則健全狀態探查和應用程式使用的連接埠上可能封鎖要求。 驗證主機上的防火牆設定,確定健全狀態探查和應用程式使用的連接埠上允許流量。
確認 VM NIC 的任何 NSG 在必要連接埠上允許輸入和輸出。 檢查 VM NIC 的 NSG 中是否有「全部拒絕」規則,其優先順序高於預設規則。
重要
您可以將 NSG 與子網路及子網路中 VM 的個別 NIC 建立關聯。 您可能已將子網路的 NSG 設定為允許流量通過連接埠。 不過,如果 VM 的 NSG 關閉此連接埠,則要求不會通過該 VM。
Load Balancer 的限制
Load Balancer 在 ISO 網路堆疊的第 4 層運作,不檢查或操作網路封包的內容。 無法用來實作以內容為基礎的路由。
所有用戶端要求最終到達後端集區的 VM。 用戶端看不到 Load Balancer。 如果沒有可用的 VM,用戶端要求就會失敗。 用戶端應用程式無法與 Load Balancer 或其任何元件通訊,也不會詢問其狀態。
如果需要根據訊息內容來實作負載平衡,請考慮使用 Azure 應用程式閘道。 或者,您可以設定 Proxy 網頁伺服器來處理傳入的用戶端要求,並將要求導向特定的 VM。