共用方式為


針對資源健康情況和輸入可用性問題進行疑難解答

本文可協助您調查影響負載平衡器前端IP和後端資源可用性的問題。

您可以使用 Azure Load Balancer 中的資源健康 情況功能來判斷負載平衡器的健康情況。 它會分析數據路徑可用性計量,以判斷是否可使用負載平衡端點、前端IP和前端埠組合與負載平衡規則。

注意

基本 Load Balancer 不支援資源健康情況功能。

下表描述判斷負載平衡器健康狀態的邏輯。

資源健康情況狀態 Description
可用的 您的負載平衡器資源狀況良好且可供使用。
已降級 您的負載平衡器具有會影響效能的平臺或使用者起始事件。 數據路徑可用性計量報告小於 90%,但至少兩分鐘大於 25% 的健康情況。 您可能會遇到中度至嚴重效能降低的情況。
無法使用 您的負載平衡器資源狀況不良。 數據路徑可用性計量報告至少兩分鐘不到 25% 的健康情況。 您可能會遇到顯著的效能降低,或輸入連線不足。 使用者或平臺事件可能會導致無法使用。
Unknown 負載平衡器資源的資源健康情況狀態在過去 10 分鐘內尚未更新或收到數據路徑可用性資訊。 此狀態可能是暫時性的,或者您的負載平衡器可能不支持資源健康情況功能。

監視負載平衡器的可用性

Azure Load Balancer 用來檢查資源健康狀態的兩個計量是 數據路徑可用性健全狀態探查狀態。 請務必瞭解其意義來衍生正確的深入解析。

資料路徑可用性

TCP Ping 會在您設定負載平衡規則的所有前端埠上每隔 25 秒產生一次數據路徑可用性計量。 然後,此 TCP 偵測會透過路由導向至所有 (已經過探查) 狀況良好的後端執行個體。 計量是每個前端IP/埠組合上 TCP Ping 的匯總百分比成功率,可在一段範例期間內針對每個負載平衡規則。

健康狀態探查狀態

健康狀態探查中定義的通訊協定 Ping 會產生健康情況探查狀態計量。 偵測訊號 (Ping) 會送至後端集區中的每一個執行個體,以及在健全狀態探查中定義的連接埠。 針對 HTTP 和 HTTPS 探查,成功的 Ping 需要 HTTP 200 OK 回應。 使用 TCP 探查時,任何響應都會視為成功。

當探查達到您為探查閾值屬性設定的連續成功或失敗數目時,Azure Load Balancer 會決定每個後端實例的健康情況。 每個後端實例的健康情況狀態會決定是否允許後端實例接收流量。

如同數據路徑可用性計量,健全狀況探查狀態計量會在取樣間隔期間匯總平均成功和總 Ping。 [健康情況探查狀態] 值會藉由探查後端實例,而不透過前端傳送流量,來指出與負載平衡器隔離的後端健康情況。

重要

健康情況探查狀態會以一分鐘為基礎取樣。 此取樣可能會導致其他穩定值中的輕微波動。

例如,假設有兩個後端實例、一個已探查,另一個探查已向下探查的主動/被動案例。 健康情況探查服務可能會擷取狀況良好實例的七個範例,而狀況不良實例則擷取 6 個範例。 這種情況會導致先前穩定值為 50,顯示為 46.15 以一分鐘間隔。

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

如本文所述,資源健康情況的降級負載平衡器會顯示數據路徑可用性的 25% 到 90%。 無法使用的負載平衡器是數據路徑可用性在兩分鐘內少於 25% 的負載平衡器。

您可以採取相同的步驟來調查您在所設定的任何健全狀態探查狀態或數據路徑可用性警示中看到的失敗。 下列步驟會探索檢查資源健康情況,並發現負載平衡器無法使用數據路徑可用性值為 0% 時該怎麼辦。 您的服務已關閉。

  1. 在 Azure 入口網站 中,移至負載平衡器深入解析頁面的詳細計量檢視。 從負載平衡器資源的頁面,或從資源健康狀態訊息中的連結存取檢視。

  2. 移至前端和後端可用性的索引標籤,並檢閱發生降級或無法使用狀態的 30 分鐘時段。 如果數據路徑可用性值是 0%,您就會知道某些專案會阻止所有負載平衡規則的流量。 您也可以查看此問題持續的時間長度。

  3. 檢查健康情況探查狀態計量,以判斷您的數據路徑是否無法使用,因為您沒有狀況良好的後端實例來提供流量。 如果您的所有負載平衡和輸入規則至少有一個狀況良好的後端實例,您就知道您的設定不是導致數據路徑無法使用的原因。 此案例表示 Azure 平台問題。 雖然平台問題很少見,但它們會觸發自動化警示給小組,以快速解決。

診斷健全狀態探查失敗

如果您的健康情況探查狀態計量指出後端實例狀況不良,建議您使用下列檢查清單來排除常見的設定錯誤:

  • 檢查資源的CPU使用率,以判斷資源是否負載過大。

    您可以透過 [計量] 頁面檢視資源的 [百分比 CPU 計量 ] 來檢查。 如需詳細資訊,請參閱 針對 Azure Windows 虛擬機的高 CPU 問題進行疑難解答。

  • 如果您使用 HTTP 或 HTTPS 探查,請檢查應用程式是否狀況良好且有回應。

    透過與後端實例相關聯的私人IP位址或實例層級公用IP位址,直接存取應用程式是否正常運作。

  • 檢閱套用至後端資源的網路安全組 (NSG)。 確定沒有任何規則的優先順序高於 AllowAzureLoadBalancerInBound 封鎖健康情況探查。

    您可以造訪後端 VM 或虛擬機擴展集的網路設定來執行這項工作。 如果您發現發生此 NSG 問題,請移動現有的 Allow 規則或建立新的高優先順序規則,以允許 Azure Load Balancer 流量。

  • 檢查作業系統。 確定您的 VM 正在探查埠上接聽。 此外,請檢閱 VM 的 OS 防火牆規則,以確保它們不會封鎖源自 IP 位址 168.63.129.16的探查流量。

    您可以在 Windows 命令提示字元中執行 netstat -a,或是在 Linux 終端機中執行 netstat -l,以檢查接聽連接埠。

  • 請確定您使用的是正確的通訊協定。 例如,使用 HTTP 來探查接聽非 HTTP 應用程式的埠探查失敗。

  • 請勿將 Azure 防火牆 放在負載平衡器的後端集區中。 如需詳細資訊,請參閱整合 Azure 防火牆 與 Azure Standard Load Balancer