針對資源健康狀態和輸入可用性問題進行疑難排解

  • 發行項

本文是一份指南，可用於調查對負載平衡器前端 IP 和後端資源可用性造成影響的問題。

Load Balancer 的資源健康狀態檢查 (RHC) 可用來判斷負載平衡器的健康情況。 它會以 2 分鐘 為間隔，分析資料路徑可用性計量，以判斷負載平衡端點、前端 IP，以及前端連接埠與負載平衡規則的組合是否可用。

注意：基本 SKU Load Balancer 不支援 RHC

下表說明了用來判斷負載平衡器健全狀態的 RHC 邏輯。

資源健康情況狀態 Description
可用的 您的標準負載平衡器資源狀況良好且可使用。
已降級 您的標準負載平衡器有由平台或使用者所起始的事件在影響效能。 資料路徑可用性計量在至少兩分鐘內回報了小於 90% 但大於 25% 的健康情況。 您會遭遇中等至嚴重的效能降低問題。
[無法使用] 您的標準負載平衡器資源狀況不良。 資料路徑可用性計量在至少兩分鐘內回報了低於 25% 的健全狀況。 您會遭遇嚴重的效能降低，或者會失去可用的輸入連線能力。 這有可能是使用者或平台事件導致無法使用的情形。
未知 在過去的 10 分鐘內，標準負載平衡器資源的資源健全狀態尚未更新，或未收到資料路徑可用性資訊。 此狀態是暫時的，系統會在收到資料後立即反/映正確的狀態。

關於我們使用的計量

我們會使用的兩個計量為資料路徑可用性以及健全狀態探查狀態，請務必了解這些計量的意義，才能推導出正確的見解。

資料路徑可用性

資料路徑可用性計量是由 TCP 對已設定負載平衡和輸入 NAT 規則的所有前端連接埠，以 25 秒為間隔進行偵測所產生的計量資料。 然後，此 TCP 偵測會透過路由導向至所有 (已經過探查) 狀況良好的後端執行個體。 如果服務收到偵測的回應，就是成功的回應，且計量總和會反覆運算一次。 如果沒有回應，就不會發生反覆運算。 此計量的計數為：單位取樣期間 TCP 偵測總數的百分之一 (1/100)。 因此，我們所要考慮的是平均值，也就是在該時間週期內總和除以計數的平均值。 此資料顯示依平均值彙總的路徑可用性計量，可以提供每個負載平衡和輸入 NAT 規則在前端 IP：連接埠上的 TCP 偵測成功率百分比。

健康情況探查狀態

健全狀態探查狀態計量，是由健全狀態探查中所定義的通訊協定偵測所產生的計量資料。 偵測訊號 (Ping) 會送至後端集區中的每一個執行個體，以及在健全狀態探查中定義的連接埠。 在進行 HTTP 和 HTTPS 探查時，若有收到 HTTP 200 OK 回應就算是偵測成功，而對 TCP 探查而言，只要收到任何回應就可視為成功。 每項探查的連續成功或失敗都會決定後端執行個體的健康情況，以及指派的後端集區是否能夠接收流量。 類似於在資料路徑可用性中使用平均彙總的方法，我們可以得知在取樣間隔期間，成功偵測除以偵測總數的平均值。 此一健全狀態探查狀態值代表了以不經由前端傳送流量的方式，在與負載平衡器隔離的情況下，對後端執行個體進行探查所得到的後端健康情況。

重要

健全狀態探查狀態是以一分鐘為單位來進行取樣。 這可能會在穩定的數值中導致一小部分的輕微波動。 例如，假設有兩個後端執行個體，一個探查正常而另一個探查為不良，則健全狀態探查服務可能會從狀況良好的執行個體擷取到 7 個取樣，並從狀況不良的執行個體擷取到 6 個取樣。 於是，會讓我們看到從原先穩定的數值 50，突然在一分鐘的間隔之後就變為 46.15。

診斷已降級和無法使用的負載平衡器

如資源健康情況一文所述，降級的負載平衡器具有 25% 到 90% 的資料路徑可用性。 無法使用的負載平衡器是指在兩分鐘內資料路徑可用性低於 25% 的負載平衡器。 您可以採取相同的步驟，調查您在自己設定的任何健全狀態探查狀態或資料路徑可用性警示中，所發現的失敗。 案例探索：在檢查我們的資源健康情況後，發現負載平衡器的資料路徑可用性為 0% 而無法使用 - 我們的服務已經關閉。

首先，前往 Azure 入口網站中負載平衡器深入解析頁面的詳細計量檢視。 從負載平衡器資源頁面或資源健康情況訊息中的連結存取此檢視。 接下來，我們會巡覽至 [前端和後端可用性] 索引標籤，並在發生降級或無法使用的狀態時，進行時間週期三十分鐘範圍的檢閱。 如果我們觀察到資料路徑可用性為 0% 的情況，就可以判定是有一個問題導致所有負載平衡和輸入 NAT 規則的流量無法流通，並且可以觀察到此問題所持續的時間長度。

我們需要檢視的下一個項目是健全狀態探查狀態計量，可協助我們判斷資料路徑無法使用的原因，是否是因為沒有狀況良好的後端執行個體來提供流量所致。 如果我們所有的負載平衡和輸入規則都至少有一個狀況良好的後端執行個體，則可以知道資料路徑無法使用的原因不會是設定的問題。 此案例表示 Azure 平台問題。 雖然平台問題很少見，但系統會將自動化警示傳送給小組，以便快速解決所有平台問題。

診斷健全狀態探查失敗

假設我們在檢查健全狀態探查狀態時，發現所有的執行個體都出現狀況不良的情況。 這項發現解釋了因為流量無處可去，所以導致資料路徑無法使用。 接著，我們應該要逐一查驗下列檢查清單中的項目，以期排除常見的設定錯誤：

  • 檢查資源的 CPU 使用率，以判斷資源是否處於高負載。
  • 當使用 HTTP 或 HTTPS 進行探查時，請檢查應用程式的狀況是否良好且正常回應。
    • 透過與後端執行個體相關聯的私人 IP 位址或執行個體層級公用 IP 位址，直接存取應用程式，以驗證應用程式是否正常運作。
  • 檢查套用至後端資源的網路安全性群組。 確定沒有會導致封鎖健全狀態探查的規則 (優先順序高於 AllowAzureLoadBalancerInBound 的規則)。
    • 您可以透過瀏覽後端 VM 或虛擬機器擴展集的 [網路] 設定，進行這項作業。
    • 如果您發現 NSG 問題就是原因，請移動現有的允許規則，或建立新的高優先順序規則以允許 AzureLoadBalancer 流量。
  • 檢查作業系統。 請確定您的 VM 正在探查連接埠上接聽，並檢查其作業系統上的防火牆規則，以確保它們不會封鎖來自 IP 位址 168.63.129.16 的探查流量。
    • 您可以在 Windows 命令提示字元中執行 netstat -a，或是在 Linux 終端機中執行 netstat -l，以檢查接聽連接埠。
  • 請確定您使用正確的通訊協定。 例如，使用 HTTP 來探查接聽非 HTTP 應用程式的連接埠時，探查會失敗。
  • Azure 防火牆不應該放在負載平衡器的後端集區中。 請參閱整合 Azure 防火牆與 Azure Standard Load Balancer，以正確整合 Azure 防火牆與負載平衡器。

如果您已完成檢查清單中的項目，但仍發現健全狀態探查失敗的情況，則可能是有罕見的平台問題，對執行個體的探查服務造成影響。 在這種情況下，Azure 會提供相關的援助，將自動化警示傳送給我們的小組，以便盡快解決所有的平台問題。

下一步