Azure Load Balancer 健全狀態探查

Azure Load Balancer 規則需要使用健全狀態探查來偵測端點狀態。 健全狀態探查和探查回應的設定會判斷要接收新連線的後端集區執行個體。 使用健全狀態探查來偵測應用程式失敗。 產生健全狀態探查的自訂回應。 使用流量控制的健全狀態探查,以管理負載或計劃性停機。 當健全狀態探查失敗時,負載平衡器將停止將新連線傳送至狀況不良的各實例。 只有輸入連線受影響,輸出連線則不受影響。

健康情況探查支援多個通訊協定。 特定健全狀態探查通訊協定的可用性會依 Load Balancer SKU 而有所不同。 此外,該服務的行為會依 Load Balancer 的 SKU 而有所不同,如下表所示:

標準 SKU 基本 SKU
探查類型 TCP, HTTP, HTTPS TCP, HTTP
探查關閉行為 關閉所有探查、繼續所有 TCP 流程。 當所有探查關閉時,所有 TCP 流量皆會到期。

重要

Load Balancer 健全狀態探查源自於 IP 位址 168.63.129.16,且不得封鎖探查,您的執行個體才會標示為已開啟。 檢閱探查來源 IP 位址,以取得詳細資料。 若要查看後端執行個體的此探查流量,請參閱 Azure Load Balancer 常見問題

若伺服器傳回的狀態碼不是 HTTP 200 OK,或連線已透過 TCP 重設而終止,則無論設定的逾時閾值為何,HTTP(S) 負載平衡器健全狀態探查皆會將執行個體自動標示為已關閉。

探查設定

健全狀態探查設定由下列元素所組成:

  • 個別探查的間隔持續時間

  • 通訊協定

  • 連接埠

  • 使用 HTTP(S) 探查時,用於 HTTP GET 的 HTTP 路徑

注意

使用 Azure PowerShell、Azure CLI、範本或 API 時,不強制要求或檢查探查定義。 只有在使用 Azure 入口網站時,才會進行探查驗證測試。

應用程式訊號、偵測訊號,以及 Load Balancer 反應

間隔值會決定健全狀態探查由後端集區執行個體探查回應的頻率。 若健全狀態探查失敗,您的後端集區執行個體便會立即標示為狀況不良。 在下一個狀況良好的探查上,健全狀態探查會立即將後端集區執行個體標示為狀況良好。

例如,健全狀態探查設為五秒。 當應用程式變更狀態時,探查的傳送時間不會同步。 健全狀態探查反映應用程式狀態所需的總時間,可能屬於以下兩種情況之一:

  1. 若您的應用程式在下一個探查抵達前產生逾時回應,偵測這些事件將需要 5 秒的時間,再加上探查抵達時應用程式逾時的持續時間。 您可假設偵測花了 5 秒多的時間。

  2. 若您的應用程式在下一個探查抵達後才產生逾時回應,則會等到探查抵達並逾時、再額外加上 5 秒後,才開始偵測事件。 您可假設偵測花了 10 秒內的時間。

在此範例中,一旦開始偵測,平台便會花一小段時間來回應變更。

回應取決於:

  • 應用程式變更狀態時
  • 偵測到變更時
  • 傳送下一個健全狀態探查時
  • 整個平台已進行偵測時

假設回應逾時回應需要最短 5 秒、最長 10 秒來回應變更。

本範例提供的目的是描述發生的情況。 無法預測在範例中指引之後的確切持續時間。

注意

健全狀態探查會探查後端集區內正在執行的所有執行個體。 若執行個體已停止,則不會於再次啟動前進行探查。

探查類型

健全狀態探查使用的通訊協定可設為下列選項之一:

  • 接聽程式

  • HTTP 端點

  • HTTPS 端點

可用的通訊協定取決於使用的負載平衡器 SKU:

TCP HTTP HTTPS
標準 SKU
基本 SKU

TCP 探查

TCP 探查會利用定義的連接埠執行三向開放 TCP 交握,藉此初始化連線。 TCP 探查會終止與四向 TCP 交握的連線。

探查最小間隔為 5 秒,且不得超過 120 秒。

在以下情況,TCP 探查會失敗:

  • 執行個體上的 TCP 接聽程式在逾時期間完全沒有回應。 系統會根據逾時探查要求數目將探查標示為已關閉,而將探查標示為已關閉之前,這些要求會設為未獲得回應。

  • 探查會從執行個體接收 TCP 重設。

HTTP/HTTPS 探查

注意

HTTPS 探查僅適用於 Standard Load Balancer

HTTP 和 HTTPS 探查建立在 TCP 探查的基礎上,並會發出含有指定路徑的 HTTP GET。 這兩個探查皆支援 HTTP GET 的相對路徑。 HTTPS 探查即是加入傳輸層安全性 (TLS) 的 HTTP 探查。 當執行個體在逾時期限內以 HTTP 狀態 200 回應時,健康情況探查會標示為已啟動。 依預設,健康情況探查會每隔 15 秒嘗試檢查一次已設定的健康情況探查連接埠。 探查最小間隔為 5 秒,且不得超過 120 秒。

若探查連接埠也是服務的接聽程式,HTTP/HTTPS 探查很適合用來實作您自己的邏輯,從負載平衡器移除執行個體。 例如,如果執行個體使用超過 90% CPU,並傳回非 200 HTTP 狀態,您可以決定移除執行個體。

注意

HTTPS 探查需要使用憑證,該憑證在整個鏈結中至少以 SHA256 簽章雜湊為基礎。

如果您使用雲端服務而且有使用 w3wp.exe 的 Web 角色,您達到網站的監視自動化。 網站程式碼中的失敗,會將非 200 的狀態傳回給負載平衡器探查。

在以下情況,HTTP / HTTPS 探查會失敗:

  • 探查端點會傳回 200 以外的 HTTP 回應碼 (例如,403、404 或 500)。 探查會立即標記為關閉。

  • 在探查最短間隔及 30 秒的逾時期間內,探查端點皆不會回應。 在探查被標示為非執行中之前,直到達到所有逾時時間間隔總和為止,這段時間內已有多個探查要求並未獲得回應。

  • 探查端點會透過 TCP 重設關閉連線。

探查行為

TCP、HTTP 和 HTTPS 健全狀態探查視為狀況良好,且後端端點在下列情況會標示為狀況良好:

  • 健康情況探查在 VM 開機時就成功。

所有已達良好狀態的後端端點皆符合接收新流量的資格。

注意

若健全狀態探查有所變動,負載平衡器等待後端端點恢復良好狀態的時間則會較長。 此額外等候時間可保護使用者和基礎結構,且為刻意設計的原則。

探查關閉行為

TCP 連線

新的 TCP 連線會接續用於其餘狀況良好的後端端點。

若後端端點的健全狀態探查失敗,已與此後端端點建立的 TCP 連線則會持續。

如果後端集區中所有執行個體的所有探查都失敗,則不會有任何新流量傳送至後端集區。 Standard Load Balancer 將允許已建立的 TCP 流量繼續。 Basic Load Balancer 會終止後端集區的所有現有 TCP 流量。

Load Balancer 是一種通過服務。 Load Balancer 不會終止 TCP 連線。 流量一律介於用戶端與 VM 的客體 OS和應用程式之間。 前端中具有所有探查關閉結果的集區不會回應 TCP 連線開啟嘗試。 沒有良好的後端端點可以接收流量並回應確認。

UDP 資料包

UDP 資料包將會傳遞至狀況良好的後端端點。

UDP 無需連線,因此 UDP 沒有流量狀態追蹤。 若任何後端端點的健全狀態探查失敗,現有的 UDP 流量將會移至後端集區中另一個狀況良好的執行個體。

若後端集區中所有執行個體的所有探查皆失敗,Basic 和 Standard Load Balancer 的現有 UDP 流量便會終止。

探查來源 IP 位址

Load Balancer 會為其內部健康情況模型使用分散式探查服務。 探查服務駐留在 VM 所在的每個主機上,可以視需要透過程式設計方式來為每個客戶的組態產生健康情況探查。 健康情況探查流量會直接在產生健康情況探查的探查服務和客戶虛擬機器之間產生。 所有 Load Balancer 健康情況探查都源自作為其來源的 IP 位址 168.63.129.16。

AzureLoadBalancer 服務標籤會識別網路安全性群組中的此來源 IP 位址,且依預設允許健全狀態探查的流量。

除了 Load Balancer 健全狀態探查外,下列作業也會使用此 IP 位址

  • 啟用 VM 代理程式來與平台通訊,藉此表示它處於「就緒」狀態

  • 啟用與 DNS 虛擬伺服器的通訊,為未定義自訂 DNS 伺服器的客戶提供篩選後的名稱解析。 此篩選可確保客戶只可以解析其部署的主機名稱。

  • 允許 VM 從 Azure 中的 DHCP 服務取得動態 IP 位址。

設計指引

  • 使用健全狀態探查可使您的服務具有復原性且可擴縮。 錯誤的設定可能會影響您服務的可用性和可擴縮性。 請參閱這一整份文件,考慮當探查回應啟動或關閉時,對您的案例有何影響。 請考慮探查回應會如何影您響應用程式的可用性。

  • 設計應用程式的健全狀況模型時,請在後端端點上,探查可反映該執行個體應用程式服務健全狀況的連接埠。 應用程式連接埠和探查連接埠不一定要相同。 在某些情況下,探查連接埠可能需要與您應用程式使用的連接埠不同。

  • 對您的應用程式而言,無論您的執行個體是否應接收新連線,產生健全狀態探查回應並將訊號發送給負載平衡器,這點相當有用。 您可以透過使健全狀態探查失敗,運用探查回應將傳遞到執行個體的新連線加以節流。 您可以準備維護應用程式並開始清空應用程式的連線。 在 Standard Load Balancer 中,探查失敗訊號一律會允許 TCP 流量繼續,直到閒置逾時或連線關閉為止。

  • 若是 UDP 負載平衡應用程式,從後端端點產生自訂健全狀態探查訊號。 針對符合對應接聽程式的健全狀態探查,使用 TCP、HTTP 或 HTTPS。

  • 使用 Standard Load BalancerHA 連接埠負載平衡規則。 所有連接埠皆會進行負載平衡,且單一健全狀態探查回應須反映整個執行個體的狀態。

  • 請勿透過接受健全狀態探查的執行個體,將該健全狀態探查轉譯或通過 Proxy 處理至虛擬網路中的另一個執行個體。 這項設定可能會導致您的案例發生連鎖性失敗。 例如:有一組第三方設備部署在負載平衡器的後端集區中,提供設備所需的規模和備援能力。 健全狀態探查設定為探查第三方設備經由 Proxy 處理或轉譯至設備後方其他虛擬機器時所使用的連接埠。 若您所探查的連接埠,即是用於將要求轉譯或通過 Proxy 處理至該設備後方其他虛擬機器的連接埠,則單一虛擬機器的任一探查回應會將設備標記為關閉。 這項設定可能會導致應用程式發生連鎖性失效。 觸發程序可以是間歇性探查失敗,會導致負載平衡器將設備執行個體標記為關閉。 此動作可停用您的應用程式。 請探查設備本身的健全狀態。 挑選用來判定健全狀態訊號的探查,對網路虛擬設備 (NVA) 案例而言是一大考量。 請諮詢您的應用程式供應商,了解適合此類案例的健全狀態訊號。

  • 如果您不允許防火牆原則中有此探查的來源 IP,則健康情況探查將會失敗,因為它無法接觸您的執行個體。 接著,Load Balancer 會因為健康情況探查失敗而將您的執行個體標示為已關閉。 此種設定會造成負載已平衡的應用程式案例失敗。

  • 為了讓 Load Balancer 的健康情況探查將您的執行個體標示為已開啟,您必須在任何 Azure 網路安全性群組和本機防火牆原則中允許此 IP 位址。 預設中,每個網路安全性群組皆含有服務標籤 AzureLoadBalancer,以許可健康情況探查流量。

  • 若要測試健全狀態探查失敗或將個別執行個體標示為關閉,請使用網路安全性群組明確封鎖健全狀態探查。 建立 NSG 規則,封鎖目的地連接埠或來源 IP 以模擬探查失敗。

  • 請勿使用 Microsoft 所擁有的 IP 位址範圍 (含 168.63.129.16) 設定您的虛擬網路。 該設定會與健全狀態探查的 IP 位址相衝突,因而可能導致您的案例失敗。

  • 若您在虛擬機器設定多個介面,請確保在接收探查的介面上回應探查。 您可能需要在每個介面上將來源網路位址在虛擬機器中轉換成此位址。

  • 請勿啟用 TCP 時間戳記。 TCP 時間戳記可能導致健全狀態探查失敗,因為 VM 的客體 OS TCP 堆疊丟棄 TCP 封包。 丟棄的封包可能會導致負載平衡器將端點標記為關閉。 TCP 時間戳記依預設會在安全性強化的虛擬機器映像上定期啟用,而必須停用。

監視

公用和內部 Standard Load Balancer 會透過 Azure 監視器,公開各端點和後端端點的健全狀態探查狀態。 這些計量可供其他 Azure 服務或合作夥伴應用程式使用。

公用及內部 Basic Load Balancer 皆無法使用 Azure 監視器記錄。

限制

  • HTTPS 探查不支援使用用戶端憑證來相互驗證。

  • 您應假設健全狀態探查會在啟用 TCP 時間戳記時失敗。

  • 基本 SKU 負載平衡器健全狀況探查不支援使用虛擬機器擴展集。

  • 由於安全性考量,HTTP 探查不支援下列連接埠進行探查:19、21、25、70、110、119、143、220、993。

下一步