健康狀態檢查概念

Google Cloud Platform (GCP) 提供健康狀態檢查機制,可判斷後端 (例如執行個體群組和網路端點群組 (NEG)) 是否正確回應流量。本文件討論 GCP 及其負載平衡器特定的健康狀態檢查概念。

總覽

GCP 提供的全球與地區健康狀態檢查系統,可按照設定的間隔時間連線至後端。每次嘗試連線的作業稱為「探測」。GCP 會記錄每次探測是成功還是失敗。

健康狀態檢查和負載平衡器會共同合作。GCP 會根據可設定的連續探測成功或失敗次數,計算負載平衡器中每個後端的整體健康狀態。成功回應達設定次數的後端就會視為「健康狀態良好」。在指定次數內無法成功回應的後端,就是「健康狀態不良」

GCP 使用每個後端的整體健康狀態來確定其接收新要求的資格。除了能設定探測頻率和健康狀態門檻之外,您還可以設定定義成功探測的條件。本文件會詳細說明健康狀態檢查的運作方式

GCP 使用虛擬私人雲端網路中未定義的特殊路徑進行健康狀態檢查。如需完整相關資訊,請參閱負載平衡器傳回路徑一節。

健康狀態檢查類別、通訊協定和通訊埠

GCP 會按照「類別」和「通訊協定」來整理健康狀態檢查。

健康狀態檢查類別有兩種:健康狀態檢查舊版健康狀態檢查。每個類別支援一組不同的通訊協定,以及可指定用於健康狀態檢查的通訊埠。通訊協定和通訊埠會決定 GCP 健康狀態檢查系統如何與您的後端連線。舉例來說,您可以建立使用 TCP 通訊埠 80 上的 HTTP 通訊協定的健康狀態檢查,也可以針對在執行個體群組上設定的已命名通訊埠建立使用 TCP 通訊協定的健康狀態檢查。

大多數 GCP 負載平衡器都需要非舊版健康狀態檢查,但網路負載平衡需要使用 HTTP 通訊協定的舊版健康狀態檢查。如要具體瞭解如何選取類別和通訊協定,以及指定通訊埠,請參閱選取健康狀態檢查一節。

您不能將舊版健康狀態檢查轉換為健康狀態檢查,反之亦然。

健康狀態檢查一詞並不是指舊版健康狀態檢查。舊版健康狀態檢查在本文件中會明確稱為舊版健康狀態檢查

選取健康狀態檢查

健康狀態檢查必須與負載平衡器的類型及其所用後端 (執行個體群組或網路端點群組) 的類型相容。建立健康狀態檢查時,必須指定如下三個要素:

  • 類別:健康狀態檢查或舊版健康狀態檢查,必須與負載平衡器相容
  • 通訊協定:定義 GCP 系統用來定期探測後端的通訊協定
  • 通訊埠規格:定義用於健康狀態檢查通訊協定的通訊埠

本節末尾的指南將會根據指定類型的負載平衡器和後端類型,大致列出健康狀態檢查類別、通訊協定和通訊埠規格的有效組合。

如本節所述,「執行個體群組」一詞指的是非代管執行個體群組、代管區域執行個體群組或代管地區執行個體群組。

類別和通訊協定

負載平衡器的類型和負載平衡器使用的後端類型會決定健康狀態檢查的類別。網路負載平衡需要使用 HTTP 通訊協定的舊版健康狀態檢查。至於所有其他負載平衡器類型,請定期使用健康狀態檢查。

您必須從健康狀態檢查類別支援的通訊協定清單中選取通訊協定。最佳做法是使用與負載平衡器本身相同的通訊協定,但這不是必要的,也不一定都可行。例如,儘管網路負載平衡通常支援 TCP 和 UDP,但網路負載平衡器需要進行舊版健康狀態檢查,並且會要求舊版健康狀態檢查使用 HTTP 通訊協定。如果是網路負載平衡器,您必須在 VM 上執行 HTTP 伺服器,以便回應健康狀態檢查探測作業。

下表列出健康狀態檢查類別,以及每種類別支援的通訊協定。

健康狀態檢查類別 支援的通訊協定
健康狀態檢查 • HTTP
• HTTPS
• HTTP/2
• 安全資料傳輸層 (SSL)
• TCP
舊版健康狀態檢查 • HTTP
• HTTPS (網路負載平衡器不支援舊版 HTTPS 健康狀態檢查,也無法與大多數其他類型的負載平衡器搭配使用)。

類別和通訊埠規格

除了通訊協定以外,您還必須為健康狀態檢查選取通訊埠規格。健康狀態檢查提供三種通訊埠規格方法,舊版健康狀態檢查則提供一種;並非所有的通訊埠規格方法都適用於各種類型的負載平衡器。負載平衡器的類型及其使用的後端類型會決定可使用的通訊埠規格方法。

健康狀態檢查類別 通訊埠規格方法和含義
健康狀態檢查 --port:指定 TCP 通訊埠編號
--port-name:指定執行個體群組上設定的任何已命名通訊埠
--use-serving-port:針對執行個體群組,使用後端服務所用的同名通訊埠;針對網路端點群組,則使用每個端點上定義的通訊埠
舊版健康狀態檢查 --port:指定 TCP 通訊埠編號

請注意,在此處和下列內容中:旗標 --use-serving-port 可以和 gcloud beta compute health-checks create 一起使用,但不能與 gcloud beta compute health-checks update 搭配。

負載平衡器指南

請利用下表,為特定負載平衡器選擇正確的健康狀態檢查類別和通訊協定。

負載平衡器 後端類型 健康狀態檢查類別和範圍 通訊埠規格
內部 TCP/UDP 地區內部後端服務上的執行個體群組 健康狀態檢查 (全球) 通訊埠編號 (--port) 或已命名通訊埠 (--port-name)。
您無法使用 --use-serving-port 旗標,因為具有 INTERNAL 負載平衡配置的後端服務沒有相關聯的已命名通訊埠。
內部 HTTP(S) 網路端點群組
(後端服務上)
健康狀態檢查 (地區) 通訊埠編號 (--port) 或
--use-serving-port
後端服務上的執行個體群組 健康狀態檢查 (地區) 通訊埠編號 (--port)、已命名通訊埠 (--port-name) 或
--use-serving-port
網路 使用目標集區的執行個體群組 舊版健康狀態檢查 (全球)
使用 HTTP 通訊協定
舊版健康狀態檢查僅支援按照通訊埠編號 (--port ) 的通訊埠規格。
TCP Proxy
SSL Proxy
HTTP(S) 1
網路端點群組
(後端服務上)
健康狀態檢查 (全球) 通訊埠編號 (--port) 或
--use-serving-port
後端服務上的執行個體群組 健康狀態檢查 (全球) 通訊埠編號(--port)、已命名通訊埠 (--port-name) 或
--use-serving-port

1在下列情況下,可以 (但不建議) 對關聯 HTTP(S) 負載平衡器的後端服務使用舊版健康狀態檢查:

  • 後端服務使用的後端是執行個體群組,不是網路端點群組。
  • 您可以使用 HTTPHTTPS 來探測後端 VM。

健康狀態檢查的運作方式

探測

建立健康狀態檢查建立舊版健康狀態檢查時,您可以指定下列旗標或接受其預設值。這些旗標可控制「每個」GCP 健康狀態檢查系統探測執行個體群組或 NEG 後端的頻率。GCP 使用多個系統實作探測作業。

您無法針對各個後端進行健康狀態檢查設定。健康狀態檢查會與整個後端服務建立關聯,而對於某些 HTTP(S) 負載平衡器來說,舊版健康狀態檢查會與整個目標集區或後端服務建立關聯。因此,針對指定後端服務或目標集區參照的所有後端,探測作業的參數都是相同的。

設定旗標 用途 預設值
檢查時間間隔
check-interval
檢查時間間隔是從「某個探測系統發出」一次探測作業開始,到「同一系統發出」下一次探測作業開始之間的時間長度。單位為秒。 如果省略這個旗標,GCP 會採用 5s (5 秒)。
逾時
timeout
逾時是 GCP 等待探測回應的時間長度,這個值必須小於或等於檢查時間間隔。單位為秒。 如果省略這個旗標,GCP 會採用 5s (5 秒)。

探測 IP 範圍

GCP 探測系統的來源 IP 位址取決於負載平衡器的類型。請利用下表建立輸入允許防火牆規則,允許從 GCP 探測系統到後端的流量。

負載平衡器 探測 IP 範圍 防火牆規則範例
內部
TCP Proxy
SSL Proxy
HTTP(S)
內部 HTTP(S)
35.191.0.0/16
130.211.0.0/22
網路負載平衡器「除外」,所有負載平衡器的防火牆規則
網路 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
網路負載平衡器的防火牆規則

多重探測和頻率

GCP 會從適當來源 IP 範圍中的多個備援系統,傳送健康狀態檢查探測。所有的探測作業並非由單一探測系統所負責。多個系統會同時發出探測作業,因此單項探測失敗並不會導致 GCP 無法追蹤後端健康狀態。

您為健康狀態檢查設定的時間間隔和逾時設定,會套用於所有探測系統。對於指定的後端,軟體存取記錄檔和 tcpdump 顯示的健康狀態檢查探測會比您的設定更頻繁。與單一探測系統的設定相比,同時與後端連線的多個探測系統會產生更多的健康狀態檢查探測作業。

這是意料中的行為,您無法設定 GCP 使用多少個探測系統來進行健康狀態檢查。不過,您可以考慮下列因素,估計多個同步探測作業的效果:

  • 如要預估每個後端服務的探測頻率,請考慮下列事項:

    • 每個後端服務的基本頻率:每個健康狀態檢查都有一個關聯的檢查頻率,與設定的檢查時間間隔成反比:

      1(檢查時間間隔)

      將健康狀態檢查與後端服務相關聯時,就會建立每個探測系統用於該後端服務上後端的基本頻率。

    • 探測比例因數:後端服務的基本頻率乘以 GCP 同時使用的探測系統數量。這個數字可能不盡相同,但通常介於 5 到 10 之間。

  • 內部 TCP/UDP 負載平衡器的多個轉送規則:如果您設定了多個指向同一地區內部後端服務的內部轉送規則 (各有不同的 IP 位址),則 GCP 會使用多個探測系統檢查每個 IP 位址。每個後端服務的探測頻率乘以設定的轉送規則數量。

  • 網路負載平衡器的多個轉送規則:如果您設定了多個指向同一目標集區的轉送規則,則 GCP 會使用多個探測系統檢查每個 IP 位址。目標集區中的每個後端所看到的探測頻率乘以設定的轉送規則數量。

  • HTTP(S) 負載平衡器的多個目標 Proxy:如果您為 HTTP(S) 負載平衡的同一網址對應設定了多個目標 Proxy,則 GCP 會使用多個探測系統檢查與每個目標 Proxy 相關聯的 IP 位址。每個後端服務的探測頻率乘以設定的目標 Proxy 數量。

  • SSL Proxy 和 TCP Proxy 負載平衡器的多個目標 Proxy:如果您為 SSL Proxy 或 TCP Proxy 負載平衡的相同後端服務設定了多個目標 Proxy,則 GCP 會使用多個探測系統檢查與每個目標 Proxy 相關聯的 IP 位址。每個後端服務的探測頻率乘以設定的目標 Proxy 數量。

  • 後端服務總和:如果一個後端 (例如一個執行個體群組) 由多個後端服務所使用,則系統與後端執行個體連線的頻率,等於每個後端服務的健康狀態檢查頻率總和。

    如果使用網路端點群組後端 (NEG),就很難確定健康狀態檢查探測的確切數量。舉例來說,同一個端點可以在多個 NEG 中,這些 NEG 不一定擁有相同的一組端點,而且不同的端點可以指向同一個後端。

健康狀態檢查封包的目的地

GCP 健康狀態檢查探測作業只會將封包傳送到每個後端執行個體的主要網路介面。這些封包的目標 IP 位址取決於負載平衡器的類型:

  • 對於內部 TCP/UDP 負載平衡器和網路負載平衡器,健康狀態檢查封包的目的地是負載平衡器的轉送規則的 IP 位址。如果多個轉送規則都指向相同的後端服務或目標集區,GCP 就會將探測作業傳送至各個轉送規則的 IP 位址。這可能會導致探測次數增加,如上一節所述
  • 如果 HTTP(S)、TCP Proxy、SSL Proxy 和內部 HTTP(S) 負載平衡器將執行個體群組當成後端使用,健康狀態檢查封包的目的地會是與每個後端執行個體的主要網路介面相關聯的主要內部 IP 位址。
  • 如果 HTTP(S)、TCP Proxy、SSL Proxy 和內部 HTTP(S) 負載平衡器將網路端點群組當成後端使用,健康狀態檢查封包的目的地會是端點的 IP 位址,主要或次要端點 (別名 IP) 位址皆可。

依據內容的健康狀態檢查

HTTP(S)、HTTP/2、TCP 和 SSL 健康狀態檢查也可以依據內容進行 (要求/回應)。在依據內容的健康狀態檢查中,健康狀態檢查探測器會將要求字串傳送至後端。健康狀態檢查會設定為預期收到探測的特定回應。

HTTP、HTTPS 和 HTTP/2 的成功標準

只有在 GCP 收到其送出要求的 HTTP 200 (OK) 回應,並且在探測逾時之前傳送回應時,使用 HTTP、HTTPS 或 HTTP/2 通訊協定進行健康狀態檢查的探測回應才算成功。

要求會被傳送至可設定的要求路徑,如未指定,則為 /。除非您使用內容檢查來提供預期的回應字串,否則系統會接受所有回應。可用來控制 HTTP、HTTPS 和 HTTP/2 健康狀態檢查成功標準的旗標有:

設定旗標 用途
要求路徑
request-path
指定網址路徑,讓 GCP 將健康狀態檢查探測要求傳送至此處。
如果省略這個旗標,GCP 會將探測要求傳送至根路徑 /request-path 選項不支援查詢參數。
回應
response
選用的回應旗標可讓您設定「依據內容的健康狀態檢查」。預期的回應字串必須小於或等於 1,024 個 ASCII (半形) 字元。設定這個旗標後,GCP 除了接收 HTTP 200 (OK) 狀態外,也會預期收到回應的前 1,024 個位元組內的字串。

您可以自行選擇是否使用依據內容的健康狀態檢查。無論是否指定預期的回應字串,GCP 都預期待檢查的後端應傳回 HTTP 200 (OK) 的回應。當您提供預期的回應時,每個 GCP 健康狀態檢查探測器都會搜尋後端提供的回應,在傳回的前 1,024 個位元組內尋找預期回應字串。如果收到 HTTP 200 (OK) 在傳回回應的前 1,024 個位元組中找到預期的回應,則系統會將依據內容的 HTTP 健康狀態檢查視為成功。

SSL 和 TCP 的成功標準

根據預設,只有 GCP 能成功完成 SSL 或 TCP 交握,以在探測逾時之前建立工作階段時,使用 SSL 和 TCP 通訊協定進行健康狀態檢查的探測回應才算成功。

除了完成交握之外,您也可以提供要求字串和預期的回應字串,每個字串長度上限為 1,024 個 ASCII (半形) 字元。設好預期的回應字串後,只有在 SSL 或 TCP 交握完成傳回的回應字串與預期的回應字串完全相符時,GCP 才會認為探測成功。下列的要求和回應旗標組合適用於使用 SSL 和 TCP 通訊協定的健康狀態檢查:

設定旗標 行為
未指定要求或回應
未指定這兩個旗標:--request--response
如果在探測逾時之前建立了 TCP 或 SSL 工作階段,則 GCP 會認為探測成功。
指定要求和回應
指定這兩個旗標:--request--response
GCP 傳送您設定的要求字串,並等待預期的回應字串。如果 TCP 或 SSL 工作階段已建立,且傳回的回應字串與探測逾時之前的預期回應字串完全相符,則探測即告成功。
僅指定回應
指定的旗標:僅指定 --response
GCP 會等待預期的回應字串。如果 TCP 或 SSL 工作階段已建立,且傳回的回應字串與探測逾時之前的預期回應字串完全相符,則探測即告成功。
如果負載平衡的後端會自動在交握過程中傳送回應字串,則僅應使用 --response
僅指定要求
指定的旗標:僅指定 --request
GCP 會傳送您設定的要求字串。如果在探測逾時之前建立了 TCP 或 SSL 工作階段,則探測即告成功。系統不會檢查回應 (如果有)。

健康狀態

GCP 會使用下列設定旗標,以及觀察探測是否成功來判斷每個負載平衡後端的整體健康狀態:

設定旗標 用途 預設值
良好健康狀態判定門檻
healthy-threshold
良好健康狀態判定門檻會指定探測結果連續成功次數,據此將後端認定為健康狀態良好。 如果省略這個旗標,GCP 會採用 2 的探測門檻值。
不良健康狀態判定門檻
unhealthy-threshold
不良健康狀態判定門檻會指定探測結果連續失敗次數,據此將後端認定為健康狀態不良。 如果省略這個旗標,GCP 會採用 2 的探測門檻值。

GCP 會在符合這個健康狀態判定門檻後,將後端視為健康狀態良好。健康狀態良好的後端就可以接收新的連線。

如果達到不良健康狀態判定門檻,GCP 會將後端認定為健康狀態不良。健康狀態不良的後端將無法接收新的連線,但現有的連線「不會」立即終止。連線會一直保持開啟,直到發生逾時或流量中斷為止。具體行為會因使用的負載平衡器類型而有不同。

現有連線可能無法傳回回應,具體取決於導致探測失敗的原因。如果健康狀態不良的後端重新達到健康狀態判定門檻,就會是健康狀態良好的後端。

後續步驟

如需瞭解如何設定健康狀態檢查,請參閱建立健康狀態檢查一文。