共用方式為

Azure Load Balancer 健全狀態探查

  • 發行項

Azure Load Balancer 健全狀態探查是一項功能，可偵測應用程式執行個體的健康情況狀態。 它會將要求傳送至執行個體，以檢查它們是否可用，並回應要求。 健全狀態探查可以設定為使用不同的通訊協定，例如 TCP、HTTP 或 HTTPS。 這是一項重要功能，因為它可協助您偵測應用程式失敗、管理負載，以及規劃停機時間。

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

探查通訊協定

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

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

探查屬性

健全狀態探查具有下列屬性:

健全狀態探查屬性名稱 詳細資料
名稱 健全狀況探查的名稱。 這是您為健全狀況探查定義的名稱
通訊協定 健全狀態探查的通訊協定。 這是您希望健全狀態探查使用的通訊協議類型。 選項包括: TCP、HTTP、HTTPS
連接埠 健全狀況探查的連接埠。 您希望健全狀態探查連線到虛擬機器時要使用的目的地連接埠，以檢查其健康情況
間隔 (秒) 健全狀態探查的間隔。 兩個連續嘗試對虛擬機器進行不同探查的健全狀態探查之間相隔的時間 (以秒為單位)
使用對象 使用此特定健全狀態探查的負載平衡器規則清單。 您應該至少有一個規則使用健全狀態探查，它才能生效

探查設定

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

健全狀態探查設定 詳細資料
通訊協定 健全狀態探查的通訊協定。 這是您希望健全狀態探查使用的通訊協議類型。 可用選項包括: TCP、HTTP、HTTPS
連接埠 健全狀況探查的連接埠。 您希望健全狀態探查連線到虛擬機器時要使用的目的地連接埠，以檢查虛擬機器的健康情況。 您必須確定虛擬機器也在此連接埠上接聽 (也就是連接埠已開啟)。
間隔 健全狀態探查的間隔。 兩個連續嘗試對虛擬機器進行的健全狀態探查之間相隔的時間 (以秒為單位)

探查通訊協定

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

案例 TCP 探查 HTTP/HTTPS 探查
概觀 TCP 探查會藉由以已定義的連接埠執行的三向開啟的 TCP 交握來啟動連線。 TCP 探查會終止與四向 TCP 交握的連線。 HTTP 和 HTTPS 會發出具有指定路徑的 HTTP GET。 這兩個探查皆支援 HTTP GET 的相對路徑。 HTTPS 探查即是加入傳輸層安全性 (TLS) 的 HTTP 探查。 若探查連接埠也是服務的接聽程式，HTTP/HTTPS 探查很適合用來實作您自己的邏輯，從負載平衡器移除執行個體。
探查失敗行為 在以下情況，TCP 探查會失敗: 1。 執行個體上的 TCP 接聽程式在逾時期間完全沒有回應。 系統會根據逾時探查要求數目將探查標示為已關閉，而將探查標示為已關閉之前，這些要求會設為未獲得回應。 2. 探查會從執行個體接收 TCP 重設。 在以下情況，HTTP/HTTPS 探查會失敗: 1。 探查端點會傳回 200 以外的 HTTP 回應碼 (例如，403、404 或 500)。 2. 在探查最短間隔及 30 秒的逾時期間內，探查端點皆不會回應。 在探查被標示為非執行中之前，直到達到所有逾時時間間隔總和為止，這段時間內已有多個探查要求並未獲得回應。 3. 探查端點會透過 TCP 重設關閉連線。
探查行為 TCP 健全狀態探查會視為狀況良好，且後端端點在下列情況會標示為狀況良好: 1。 健康情況探查在 VM 開機時就成功。 2. 所有已達良好狀態的後端端點皆符合接收新流量的資格。 當執行個體在逾時期限內以 HTTP 狀態 200 回應時，健康情況探查會標示為已啟動。 HTTP/HTTPS 健全狀態探查會視為狀況良好，且後端端點在下列情況會標示為狀況良好: 1。 健康情況探查在 VM 開機時就成功。 2. 所有已達良好狀態的後端端點皆符合接收新流量的資格。

注意

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

探查關閉行為

案例 TCP 連線 UDP 資料包
單一執行個體探查關閉 新的 TCP 會連線成功連線到保持健康的後端端點。 已建立此後端端點的 TCP 連線會繼續。 現有的 UDP 流量將會移至後端集區中另一個狀況良好的執行個體。
所有執行個體探查關閉 不會將任何新的流程傳送至後端集區。 Standard Load Balancer 可讓已建立的 TCP 流程繼續，因為後端集區有多個後端執行個體。 Basic Load Balancer 會終止後端集區的所有現有 TCP 流程。 所有現有 UDP 流程都會終止。

探查間隔和逾時

間隔值會決定健全狀態探查探查來自後端集區執行個體回應的頻率。 若健全狀態探查失敗，您的後端集區執行個體便會立即標示為狀況不良。 如果健全狀態探查在下一個狀況良好的探查上成功，Azure Load Balancer 會將後端集區執行個體標示為狀況良好。 根據預設，健全狀態探查會在 Azure 入口網站中每隔 5 秒嘗試檢查一次已設定的健全狀態探查連接埠，但可以明確設定為另一個值。

為了確保收到及時的回應，HTTP/S 健全狀態探查具有內建逾時。 以下是 TCP 和 HTTP/S 探查的逾時持續時間:

  • TCP 探查逾時持續時間: N/A (一旦超過設定的探查間隔持續時間且已傳送下一個探查，探查將會失敗)
  • HTTP/S 探查逾時持續時間: 30 秒

針對 HTTP/S 探查，如果設定的間隔超過上述逾時期間，健康情況探查將會逾時，如果逾時期間未收到任何回應，則會失敗。 例如，如果 HTTP 健全狀態探查設定的探查間隔為 120 秒 (每 2 分鐘)，且前 30 秒內未收到探查回應，探查就會達到逾時期限並失敗。 當設定的間隔比上述逾時期間短時，如果未在已設定間隔期間完成之前收到任何回應，健全狀態探查將會失敗，並且會立即傳送下一個探查。

設計指引

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

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

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

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

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

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

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

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

  • 請確定您的虛擬機器執行個體正在執行。 針對後端集區中每個執行中的執行個體，健全狀態探查會檢查可用性。 若執行個體已停止，則不會於再次啟動前進行探查。

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

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

  • 不同於負載平衡規則，輸入 NAT 規則不需要連結健全狀態探查。

  • 不建議使用 NSG 規則封鎖 Azure Load Balancer 健全狀態探查 IP 或連接埠。 這是不支援的案例，可能導致 NSG 規則延遲生效，造成健全狀態探查無法準確表示後端執行個體的可用性。

監視

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

探查來源 IP 位址

為了讓 Azure Load Balancer 的健全狀態探查標記執行個體，您必須在任何 Azure 網路安全性群組和本機防火牆原則中允許 168.63.129.16 IP 位址。 AzureLoadBalancer 服務標籤會識別網路安全性群組中的此來源 IP 位址，且依預設允許健全狀態探查的流量。 您也可以在此處了解更多相關資訊。

如果您不允許防火牆原則中有此探查的來源 IP，則健健全狀態探查將會失敗，因為它無法接觸您的執行個體。 接著，Azure Load Balancer 會因為健全狀態探查失敗而將您的執行個體標示為關閉。 此種設定會造成負載已平衡的應用程式案例失敗。 所有 IPv4 Load Balancer 健全狀態探查都源自 IP 位址 168.63.129.16 作為其來源。 IPv6 探查會使用連結本機位址 (fe80::1234:5678:9abc) 作為其來源。 針對雙堆疊 Azure Load Balancer，您必須設定網路安全性群組，IPv6 健全狀態探查才能正常運作。

限制

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

  • HTTP 探查不支援使用主機名稱來探查後端

  • 啟用 TCP 時間戳記可能導致節流或其他效能問題，進而造成健全狀態探查逾時。

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

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

下一步