設定以應用程式為基礎的健康狀態檢查和自動修復

本文說明如何設定以應用程式為準的健康狀態檢查，自動修復代管執行個體群組 (MIG) 中的 VM。本文也說明如何執行下列操作：使用健康狀態檢查但不啟用自動修復功能、移除健康狀態檢查、查看自動修復政策，以及檢查每個 VM 的健康狀態。

您可以設定以應用程式為準的健康狀態檢查，確認 VM 上的應用程式是否能正常回應。如果您設定的健康狀態檢查偵測到 VM 上的應用程式沒有回應，MIG 就會將該 VM 標示為「健康狀態不良」，並預設修復該 VM。根據以應用程式為準的健康狀態檢查結果修復 VM，稱為「自動修復」。

您也可以在 MIG 中關閉自動修復功能，這樣就能使用健康狀態檢查，而不必觸發健康狀態不良 VM 的修復作業。

如要進一步瞭解 MIG 中的修復作業，請參閱「關於修復 VM 以確保高可用性」。

事前準備

  • 如果尚未設定驗證，請先完成設定。 驗證可確認您的身分，以便存取 Cloud de Confiance by S3NS 服務和 API。如要從本機開發環境執行程式碼或範例，請選取下列其中一個選項，向 Compute Engine 進行驗證：

    選取這個頁面上範例的預計用途分頁：

    控制台

    使用 Cloud de Confiance 控制台存取 Cloud de Confiance by S3NS 服務和 API 時，不需要設定驗證。

    gcloud

    1. 安裝 Google Cloud CLI，然後 使用聯合身分登入 gcloud CLI。登入後，執行下列指令來初始化 Google Cloud CLI：

      gcloud init
  • 設定預設區域和可用區。

    • Terraform

    如要在本機開發環境中使用本頁的 Terraform 範例，請安裝並初始化 gcloud CLI，然後使用使用者憑證設定應用程式預設憑證。

    1. 安裝 Google Cloud CLI。

    2. 設定 gcloud CLI，使用您的聯合身分。

      詳情請參閱「 使用聯合身分登入 gcloud CLI」。

    3. 為使用者帳戶建立本機驗證憑證： 

      gcloud auth application-default login

      如果系統傳回驗證錯誤，請確認您已 使用聯合身分登入 gcloud CLI。

    詳情請參閱「 設定本機開發環境的驗證機制」。

    REST

    如要在本機開發環境中使用本頁的 REST API 範例，請使用您提供給 gcloud CLI 的憑證。

      安裝 Google Cloud CLI，然後 使用聯合身分登入 gcloud CLI。

    詳情請參閱 Cloud de Confiance 驗證說明文件中的「使用 REST 進行驗證」。

定價

設定以應用程式為基礎的健康狀態檢查時，只要 VM 的健康狀態發生變化，Compute Engine 預設會在 Cloud Logging 中寫入記錄項目。 Cloud Logging 每個月都會提供免費配額，超過配額後，系統會根據資料量計費。如要避免產生 Cloud Logging 費用，可以停用健康狀態變更記錄。

設定以應用程式為基礎的健康狀態檢查和自動修復功能

如要在 MIG 中設定以應用程式為準的健康狀態檢查和自動修復功能，請完成下列步驟：

  1. 如果尚未建立健康狀態檢查，請先建立。
  2. 在 MIG 中設定自動修復政策，套用健康狀態檢查。

建立健康狀態檢查

單一健康狀態檢查最多可套用至 50 個 MIG。如果超過 50 個群組，請建立多項健康狀態檢查。

以下範例說明如何建立自動修復的健康狀態檢查。您可以為 MIG 中的自動修復功能建立區域或全域健康狀態檢查。在本範例中，您會建立全域健康狀態檢查，在通訊埠 80 上尋找網路伺服器回應。如要讓健康狀態檢查探測連線至網頁伺服器，請設定防火牆規則。

控制台

  1. 建立比負載平衡健康狀態檢查更為保守的自動修復健康狀態檢查。

    舉例來說，您可以建立健康狀態檢查，在連接埠 80 上尋找回應，並在將 VM 標示為 UNHEALTHY 並導致 VM 重新建立之前，容許發生一些失敗。在這個範例中，如果健康狀態檢查成功傳回一次，系統就會將 VM 標示為正常。如果健康狀態檢查連續 3 次傳回失敗，系統就會將 VM 標示為健康狀態不良。

    1. 前往 Cloud de Confiance 控制台的「建立健康狀態檢查」頁面。

      前往「建立健康狀態檢查」

    2. 為健康狀態檢查指定名稱，例如 example-check。

    3. 選取「範圍」。您可以選取「區域」或「全球」。 在本例中，請選取「全域」。

    4. 針對「Protocol」(通訊協定)欄，確認 [HTTP] 已選取。

    5. 在「Port」(通訊埠) 欄中，輸入 80。

    6. 在「健康狀態條件」部分，提供下列值：

      1. 在「Check interval」(檢查時間間隔) 欄中，輸入 5。
      2. 在「Timeout」(逾時) 欄中，輸入 5。
      3. 設定「良好健康狀態判定門檻」，決定健康狀態不良的 VM 必須連續通過健康狀態檢查幾次，才能判定為健康狀態良好。在這個範例中，請輸入 1。
      4. 設定「不良健康狀態判定門檻」，判斷健康狀態檢查必須連續失敗幾次，才能將健康狀態良好的 VM 標示為不良。在這個範例中，請輸入 3。

    7. 點選「建立」來建立健康狀態檢查。

  2. 建立防火牆規則，允許健康狀態檢查探測器連線至應用程式。

    健康狀態檢查探測的來源位址範圍為 130.211.0.0/22 和 35.191.0.0/16，因此請確保網路防火牆規則允許健康狀態檢查連線。在本範例中，MIG 使用 default 網路，而 VM 正在接聽通訊埠 80。如果尚未在預設網路開啟通訊埠 80，請建立防火牆規則。

    1. 前往 Cloud de Confiance 控制台的「Firewall policies」(防火牆政策) 頁面。

      前往「Firewall policies」(防火牆政策)

    2. 按一下「Create firewall rule」(建立防火牆規則)。

    3. 輸入防火牆規則的「Name」(名稱)。例如：allow-health-check。

    4. 在「Network」(網路) 中選取 default。

    5. 在「Targets」(目標) 中選取 All instances in the network。

    6. 在「Source filter」(來源篩選器) 中選取 IPv4 ranges。

    7. 在「Source IPv4 ranges」(來源 IPv4 範圍) 中，輸入 130.211.0.0/22 和 35.191.0.0/16。

    8. 在「Protocols and ports」(通訊協定和通訊埠) 中，選取「Specified protocols and ports」(指定的通訊協定和通訊埠)，然後執行下列操作：

      1. 選取「TCP」TCP。
      2. 在「Ports」(通訊埠) 欄位中輸入 80。

    9. 點選「建立」。

gcloud

  1. 建立比負載平衡健康狀態檢查更為保守的自動修復健康狀態檢查。

    舉例來說，您可以建立健康狀態檢查，在連接埠 80 上尋找回應，並在將 VM 標示為 UNHEALTHY 並導致 VM 重新建立之前，容許發生一些失敗。在本例中，如果 VM 成功傳回一次，就會標示為正常。如果 VM 連續 3 次傳回失敗，就會標示為健康狀態不良。下列指令會建立全域健康狀態檢查。

    gcloud compute health-checks create http example-check --port 80 \
   --check-interval 30s \
   --healthy-threshold 1 \
   --timeout 10s \
   --unhealthy-threshold 3 \
   --global

  2. 建立防火牆規則，允許健康狀態檢查探測器連線至應用程式。

    健康狀態檢查探測的來源位址範圍為 130.211.0.0/22 和 35.191.0.0/16，因此請確認防火牆規則允許健康狀態檢查連線。在本範例中，MIG 使用 default 網路，而 VM 則監聽通訊埠 80。如果預設網路尚未開啟通訊埠 80，請建立防火牆規則。

    gcloud compute firewall-rules create allow-health-check \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default

Terraform

  1. 使用 google_compute_http_health_check 資源建立健康狀態檢查。

    舉例來說，您可以建立健康狀態檢查，在連接埠 80 上尋找回應，並在將 VM 標示為 UNHEALTHY 並導致 VM 重新建立之前，容許發生一些失敗。在本範例中，如果 VM 成功傳回一次，就會標示為正常。如果 VM 連續 3 次傳回失敗，就會標示為健康狀態不良。下列要求會建立全域健康狀態檢查。

    resource "google_compute_http_health_check" "default" {
  name                = "example-check"
  timeout_sec         = 10
  check_interval_sec  = 30
  healthy_threshold   = 1
  unhealthy_threshold = 3
  port                = 80
}

  2. 使用 google_compute_firewall 資源建立防火牆。

    健康狀態檢查探測器的來源位址範圍介於 130.211.0.0/22 至 35.191.0.0/16 之間，因此請確認防火牆規則允許健康狀態檢查連線。在本範例中，MIG 使用 default 網路，而 VM 監聽通訊埠 80。如果尚未在預設網路開啟通訊埠 80，請建立防火牆規則。

    resource "google_compute_firewall" "default" {
  name          = "allow-health-check"
  network       = "default"
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  allow {
    protocol = "tcp"
    ports    = [80]
  }
}

如要瞭解如何套用或移除 Terraform 設定，請參閱「基本 Terraform 指令」。

REST

  1. 建立自動修復用的健康狀態檢查，這類檢查應較負載平衡的健康狀態檢查保守。

    舉例來說，您可以建立健康狀態檢查，在連接埠 80 上尋找回應，並在將 VM 標示為 UNHEALTHY 並導致 VM 重新建立之前，容許發生一些失敗。在本範例中，如果 VM 成功傳回一次，就會標示為正常。如果 VM 連續 3 次傳回失敗，就會標示為健康狀態不良。下列要求會建立全域健康狀態檢查。

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks

{
 "name": "example-check",
 "type": "http",
 "port": 80,
 "checkIntervalSec": 30,
 "healthyThreshold": 1,
 "timeoutSec": 10,
 "unhealthyThreshold": 3
}

  2. 建立防火牆規則，允許健康狀態檢查探測器連線至應用程式。

    健康狀態檢查探測器的來源位址範圍介於 130.211.0.0/22 至 35.191.0.0/16 之間，因此請確認防火牆規則允許健康狀態檢查連線。在本範例中，MIG 使用 default 網路，而 VM 監聽通訊埠 80。如果尚未在預設網路開啟通訊埠 80，請建立防火牆規則。

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "allow-health-check",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
 "sourceRanges": [
  "130.211.0.0/22",
  "35.191.0.0/16"
 ],
 "allowed": [
  {
   "ports": [
    "80"
   ],
   "IPProtocol": "tcp"
  }
 ]
}

    將 PROJECT_ID 替換為專案 ID。

在 MIG 中設定自動修復政策

在 MIG 中，您只能設定一項自動修復政策來套用健康狀態檢查。

設定自動修復政策前，如果沒有健康狀態檢查，請建立一個。您可以使用區域或全域健康狀態檢查，在 MIG 中啟用自動修復功能。區域性健康狀態檢查可減少跨區域的依附元件，並協助實現資料落地，而如果您想為多個區域的 MIG 使用相同的健康狀態檢查，全球健康狀態檢查就非常方便。

如要在設定新的健康狀態檢查時，避免不慎觸發自動修復功能，或想使用健康狀態檢查但不啟用自動修復功能，請參閱「設定健康狀態檢查但不啟用自動修復功能」。在 MIG 中設定健康狀態檢查後，您也可以關閉自動修復功能。

如要設定自動修復政策，請選取下列任一選項：

控制台

  1. 前往 Cloud de Confiance 控制台的「Instance groups」(執行個體群組) 頁面。

    前往「Instance groups」(執行個體群組)

  2. 在清單的「Name」(名稱) 欄下方，按一下要套用健康狀態檢查的 MIG 名稱。

  3. 按一下「編輯」即可修改這個 MIG。

  4. 按一下「執行個體生命週期和自動修復」展開該部分。

    1. 在「自動修復」專區中，針對「健康狀態檢查」，選取全域或區域健康狀態檢查。
    2. 「初始延遲」請使用預設值，或視需要修改。

      初始延遲時間是指新 VM 初始化並執行開機指令碼所需的秒數。在 VM 的初始延遲期間，MIG 會忽略失敗的健康狀態檢查，因為 VM 可能處於啟動程序。這樣可防止 MIG 過早重建 VM。如果健康狀態檢查在初始延遲期間收到健康狀態良好的回應，表示啟動程序已完成，VM 已準備就緒。當 VM 的 currentAction 欄位變更為 VERIFYING 時，初始延遲計時器就會啟動。計時器會在設定時間結束或健康檢查成功時停止。初始延遲值必須介於 0 至 3600 秒之間。 在控制台中，預設值為 300 秒。

  5. 按一下 [Save] (儲存) 套用您的變更。

gcloud

如要在現有 MIG 中設定自動修復政策，請使用 update 指令。舉例來說，您可以使用下列指令，在現有的區域 MIG 中設定自動修復政策：

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

如要在建立 MIG 時設定自動修復政策，請使用 create 指令。舉例來說，建立區域 MIG 時，請使用下列指令設定自動修復政策：

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

更改下列內容：

  • MIG_NAME：要設定自動修復功能的 MIG 名稱。
  • SIZE：群組中的 VM 數量。
  • INSTANCE_TEMPLATE_URL：您要用來在代管執行個體群組中建立執行個體的執行個體範本網址。網址可以包含執行個體範本的 ID 或名稱。請指定下列其中一個值：
    • 如果是區域執行個體範本：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 全域執行個體範本：INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL：您要設定自動修復功能的健康狀態檢查部分網址。例如：
    • 區域健康狀態檢查：projects/example-project/regions/us-central1/healthChecks/example-health-check。
    • 全域健康狀態檢查：projects/example-project/global/healthChecks/example-health-check。
  • INITIAL_DELAY： 新 VM 初始化並執行開機指令碼所需的時間 (以秒為單位)。在 VM 的初始延遲期間，MIG 會忽略失敗的健康狀態檢查，因為 VM 可能處於啟動程序。這樣可防止 MIG 過早重建 VM。如果健康狀態檢查在初始延遲期間收到健康狀態良好的回應，表示啟動程序已完成，VM 已準備就緒。當 VM 的 currentAction 欄位變更為 VERIFYING 時，初始延遲計時器就會啟動。計時器會在設定時間結束或健康檢查成功時停止。初始延遲值必須介於 0 至 3600 秒之間。 預設值為 0。
  • ZONE：MIG 所在的可用區。如為區域 MIG，請使用 --region 旗標。

Terraform

如要在 MIG 中設定自動修復政策，請使用 auto_healing_policies 區塊。

下列範例會在可用區 MIG 中設定自動修復政策。如要進一步瞭解範例中使用的資源，請參閱 google_compute_instance_group_manager。如果是區域 MIG，請使用 google_compute_region_instance_group_manager 資源。

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

如要瞭解如何套用或移除 Terraform 設定，請參閱「基本 Terraform 指令」。

REST

如要在現有 MIG 中設定自動修復政策，請使用 patch 方法，如下所示：

舉例來說，請發出下列呼叫，在現有的區域 MIG 中設定自動修復功能：

  PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
  {
    "autoHealingPolicies": [
      {
        "healthCheck": "HEALTH_CHECK_URL",
        "initialDelaySec": INITIAL_DELAY
      }
    ]
  }

如要在建立 MIG 時設定自動修復政策，請使用 insert 方法，如下所示：

舉例來說，建立可用區 MIG 時，請發出下列呼叫來設定自動修復政策：

  POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
  {
    "name": "MIG_NAME",
    "targetSize": SIZE,
    "instanceTemplate": "INSTANCE_TEMPLATE_URL",
    "autoHealingPolicies": [
      {
        "healthCheck": "HEALTH_CHECK_URL",
        "initialDelaySec": INITIAL_DELAY
      }
    ]
  }

更改下列內容：

  • PROJECT_ID：您的專案 ID。
  • MIG_NAME：要設定自動修復功能的 MIG 名稱。
  • SIZE：群組中的 VM 數量。
  • INSTANCE_TEMPLATE_URL：您要用來在代管執行個體群組中建立執行個體的執行個體範本網址。網址可以包含執行個體範本的 ID 或名稱。請指定下列其中一個值：
    • 如果是區域執行個體範本：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 全域執行個體範本：INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL：您要設定自動修復功能的健康狀態檢查部分網址。例如：
    • 區域健康狀態檢查：projects/example-project/regions/us-central1/healthChecks/example-health-check。
    • 全域健康狀態檢查：projects/example-project/global/healthChecks/example-health-check。
  • INITIAL_DELAY： 新 VM 初始化並執行開機指令碼所需的時間 (以秒為單位)。在 VM 的初始延遲期間，MIG 會忽略失敗的健康狀態檢查，因為 VM 可能處於啟動程序。這樣可防止 MIG 過早重建 VM。如果健康狀態檢查在初始延遲期間收到健康狀態良好的回應，表示啟動程序已完成，VM 已準備就緒。當 VM 的 currentAction 欄位變更為 VERIFYING 時，初始延遲計時器就會啟動。計時器會在設定時間結束或健康檢查成功時停止。初始延遲值必須介於 0 至 3600 秒之間。 預設值為 0。
  • ZONE：MIG 所在的可用區。如果是區域 MIG，請在網址中使用 regions/REGION。

自動修復設定完成後，可能要過 10 分鐘，自動修復功能才會開始監控群組中的 VM。開始監控後，Compute Engine 會根據自動修復設定，將 VM 標示為正常 (或重新建立 VM)。舉例來說，如果您將初始延遲時間設為 5 分鐘、健康狀態檢查間隔設為 1 分鐘，且健康狀態良好門檻為 1 次檢查，時間軸會如下所示：

  • 自動修復功能會在 10 分鐘後，開始監控群組中的 VM
  • + 設定的初始延遲時間 (5 分鐘)
  • + 檢查間隔 * 健康狀態良好門檻 (60 秒 * 1)
  • = 16 分鐘，VM 會標示為正常或重新建立

設定健康狀態檢查 (不含自動修復功能)

您可以關閉 MIG 的自動修復功能，並使用設定的健康狀態檢查監控應用程式健康狀態，也可以自行實作修復邏輯。在 MIG 中關閉自動修復功能不會影響健康狀態檢查的運作。健康狀態檢查會持續探測應用程式，並提供 VM 健康狀態。不過，MIG 不會再修復健康狀態不良的 VM。

如要設定健康狀態檢查，但不啟用自動修復功能，請選取下列其中一個選項。

控制台

  1. 前往 Cloud de Confiance 控制台的「Instance groups」(執行個體群組) 頁面。

    前往「Instance groups」(執行個體群組)

  2. 在清單的「Name」(名稱) 欄下方，按一下要套用健康狀態檢查的 MIG 名稱。

  3. 按一下「編輯」即可修改這個 MIG。

  4. 按一下「執行個體生命週期和自動修復」展開該部分。

    1. 在「自動修復」專區中，針對「健康狀態檢查」，選取全域或區域健康狀態檢查。
    2. 「初始延遲」請使用預設值，或視需要修改。

      初始延遲時間是指新 VM 初始化並執行開機指令碼所需的秒數。在 VM 的初始延遲期間，MIG 會忽略失敗的健康狀態檢查，因為 VM 可能處於啟動程序。這樣可防止 MIG 過早重建 VM。如果健康狀態檢查在初始延遲期間收到健康狀態良好的回應，表示啟動程序已完成，VM 已準備就緒。當 VM 的 currentAction 欄位變更為 VERIFYING 時，初始延遲計時器就會啟動。計時器會在設定時間結束或健康檢查成功時停止。初始延遲值必須介於 0 至 3600 秒之間。 在控制台中，預設值為 300 秒。

    1. 在「On failed health check」(健康狀態檢查失敗時) 清單中，選取「No action」(不採取任何動作)。

  5. 按一下 [Save] (儲存) 套用您的變更。

gcloud

如要設定健康狀態檢查，但不啟用自動修復功能，指定健康狀態檢查設定時，也必須將 --action-on-vm-failed-health-check 旗標設為 do-nothing，如下所示：

  • 在現有 MIG 中，使用 update 指令。

    舉例來說，在現有的區域 MIG 中使用下列指令：

    gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

  • 建立 MIG 時，請使用 create 指令。

    舉例來說，建立可用區 MIG 時，請使用下列指令：

    gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

更改下列內容：

  • MIG_NAME：要設定自動修復功能的 MIG 名稱。
  • SIZE：群組中的 VM 數量。
  • INSTANCE_TEMPLATE_URL：您要用來在代管執行個體群組中建立執行個體的執行個體範本網址。網址可以包含執行個體範本的 ID 或名稱。請指定下列其中一個值：
    • 如果是區域執行個體範本：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 全域執行個體範本：INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL：您要設定自動修復功能的健康狀態檢查部分網址。例如：
    • 區域健康狀態檢查：projects/example-project/regions/us-central1/healthChecks/example-health-check。
    • 全域健康狀態檢查：projects/example-project/global/healthChecks/example-health-check。
  • INITIAL_DELAY： 新 VM 初始化並執行開機指令碼所需的時間 (以秒為單位)。在 VM 的初始延遲期間，MIG 會忽略失敗的健康狀態檢查，因為 VM 可能處於啟動程序。這樣可防止 MIG 過早重建 VM。如果健康狀態檢查在初始延遲期間收到健康狀態良好的回應，表示啟動程序已完成，VM 已準備就緒。當 VM 的 currentAction 欄位變更為 VERIFYING 時，初始延遲計時器就會啟動。計時器會在設定時間結束或健康檢查成功時停止。初始延遲值必須介於 0 至 3600 秒之間。 預設值為 0。
  • ZONE：MIG 所在的可用區。如為區域 MIG，請使用 --region 旗標。

REST

如要設定健康狀態檢查，但不啟用自動修復功能，指定健康狀態檢查設定時，也必須將 onFailedHealthCheck 欄位設為 DO_NOTHING，如下所示：

  • 在現有 MIG 中，使用 patch 方法，如下所示：

    舉例來說，在現有的可用區 MIG 中進行下列呼叫：

    PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
{
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

  • 建立 MIG 時，請使用 insert 方法，如下所示：

    舉例來說，建立可用區 MIG 時，請進行下列呼叫：

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL",
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

更改下列內容：

  • PROJECT_ID：您的專案 ID。
  • MIG_NAME：要設定自動修復功能的 MIG 名稱。
  • SIZE：群組中的 VM 數量。
  • INSTANCE_TEMPLATE_URL：您要用來在代管執行個體群組中建立執行個體的執行個體範本網址。網址可以包含執行個體範本的 ID 或名稱。請指定下列其中一個值：
    • 如果是區域執行個體範本：projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • 全域執行個體範本：INSTANCE_TEMPLATE_ID
  • HEALTH_CHECK_URL：您要設定自動修復功能的健康狀態檢查部分網址。例如：
    • 區域健康狀態檢查：projects/example-project/regions/us-central1/healthChecks/example-health-check。
    • 全域健康狀態檢查：projects/example-project/global/healthChecks/example-health-check。
  • INITIAL_DELAY： 新 VM 初始化並執行開機指令碼所需的時間 (以秒為單位)。在 VM 的初始延遲期間，MIG 會忽略失敗的健康狀態檢查，因為 VM 可能處於啟動程序。這樣可防止 MIG 過早重建 VM。如果健康狀態檢查在初始延遲期間收到健康狀態良好的回應，表示啟動程序已完成，VM 已準備就緒。當 VM 的 currentAction 欄位變更為 VERIFYING 時，初始延遲計時器就會啟動。計時器會在設定時間結束或健康檢查成功時停止。初始延遲值必須介於 0 至 3600 秒之間。 預設值為 0。
  • ZONE：MIG 所在的可用區。如果是區域 MIG，請在網址中使用 regions/REGION。

設定健康狀態檢查後，您可以監控 VM 健康狀態，確認健康狀態檢查是否正常運作。如要讓 MIG 修復健康狀態不良的 VM，可以開啟自動修復功能。

移除健康狀態檢查

如要移除自動修復政策中設定的健康狀態檢查，請按照下列步驟操作：

控制台

  1. 前往 Cloud de Confiance 控制台的「Instance groups」(執行個體群組) 頁面。

    前往「Instance groups」(執行個體群組)

  2. 按一下要移除健康狀態檢查的 MIG 名稱。

  3. 按一下「編輯」即可修改這個 MIG。

  4. 按一下「執行個體生命週期和自動修復」展開該部分。

  5. 在「自動修復」部分，針對「健康狀態檢查」選取「沒有健康狀態檢查」。

  6. 點選「儲存」來套用變更。

gcloud

如要移除自動修復政策中的健康狀態檢查設定，請在 update 指令中使用 --clear-autohealing 標記，如下所示：

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

將 MIG_NAME 替換為 MIG 名稱。

REST

如要移除自動修復政策中的健康狀態檢查設定，請將自動修復政策設為空值。

舉例來說，如要移除區域 MIG 中的健康狀態檢查，請提出下列要求：

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

更改下列內容：

  • PROJECT_ID：您的專案 ID。
  • MIG_NAME：要設定自動修復功能的 MIG 名稱。
  • ZONE：MIG 所在的可用區。如果是區域 MIG，請使用 regions/REGION。

查看 MIG 中的自動修復政策

如要查看 MIG 的自動修復政策，請按照下列步驟操作：

控制台

  1. 前往 Cloud de Confiance 控制台的「Instance groups」(執行個體群組) 頁面。

    前往「Instance groups」(執行個體群組)

  2. 按一下要查看自動修復政策的 MIG 名稱。

  3. 前往「詳細資料」分頁。

    「VM 執行個體生命週期」部分會顯示健康狀態檢查，以及在自動修復政策中設定的初始延遲時間。

gcloud

如要查看 MIG 中的自動修復政策，請使用下列指令：

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

將 MIG_NAME 替換為 MIG 名稱。

以下是輸出內容範例： 

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

如要在 MIG 中查看自動修復政策，請使用下列 REST 方法：

舉例來說，您可以發出下列要求，查看區域 MIG 中的自動修復政策：

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

在回應主體中，檢查是否有 autoHealingPolicies[] 物件。

以下是回應範例：

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

更改下列內容：

  • PROJECT_ID：您的專案 ID。
  • MIG_NAME：要設定自動修復功能的 MIG 名稱。
  • ZONE：MIG 所在的可用區。如果是區域 MIG，請使用 regions/REGION。

查看狀態

在 MIG 中設定以應用程式為準的健康狀態檢查後，您可以使用下列方式確認 VM 是否正在執行，以及應用程式是否正常回應：

檢查 VM 是否正常運作

如果您已在 MIG 中設定以應用程式為準的健康狀態檢查，可以查看每個受管理執行個體的健康狀態。

檢查代管執行個體的健康狀態，以便：

  • 找出未修復的健康狀態不良 VM。即使 VM 在下列情況下診斷為異常，也可能不會立即修復：
    • VM 仍在啟動中，並且尚未經過初始延遲。
    • 正在修復大量健康狀態不良的執行個體。 MIG 會延遲進一步的自動修復作業，確保群組持續執行部分執行個體。
  • 偵測健康狀態檢查設定錯誤。舉例來說，如果執行個體回報健康狀態為 TIMEOUT，即可偵測到設定錯誤的防火牆規則，或無效的應用程式健康狀態檢查端點。
  • 如要設定初始延遲值，請測量 VM 轉換為 RUNNING 狀態的時間，以及 VM 轉換為 HEALTHY 健康狀態的時間，兩者之間的時間差即為初始延遲值。您可以輪詢 list-instances 方法，或觀察 instances.insert 作業與收到的第一個正常訊號之間的時間，來評估這個差距。

使用控制台、gcloud 指令列工具或 REST 查看健康狀態。

控制台

  1. 前往 Cloud de Confiance 控制台的「Instance groups」(執行個體群組) 頁面。

    前往執行個體群組。

  2. 在清單的「Name」(名稱) 欄底下，按一下要檢查的 MIG 名稱。系統隨即開啟一個頁面，頁面中包含執行個體群組的屬性及群組包含之 VM 的清單。

  3. 如果 VM 狀態不佳，您可以在「健康狀態檢查狀態」欄中查看其健康狀態。

gcloud

使用 list-instances 子指令。

gcloud compute instance-groups managed list-instances MIG_NAME
    --zone ZONE

指令會輸出類似以下的結果。「HEALTH_STATE」欄位會顯示每個 VM 的健康狀態。

NAME: igm-with-hc-fvz6
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

NAME: igm-with-hc-gtz3
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

更改下列內容：

  • MIG_NAME：MIG 的名稱。
  • ZONE：MIG 所在的可用區。如果是區域 MIG，請使用 --region REGION。

REST

如果是區域 MIG，請對 listManagedInstances 方法建構 POST 要求：

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/MIG_NAME/listManagedInstances

如果是可用區 MIG，請使用可用區 MIG listManagedInstances 方法：

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/MIG_NAME/listManagedInstances

要求會傳回類似以下的回應，其中包含每個代管執行個體的 instanceHealth 欄位。

{
  "managedInstances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/sproject-id/zones/zone/instances/igm-with-hc-fvz6",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6159431761228150698",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-fvz6"
    },
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/igm-with-hc-gtz3",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6622324799312181783",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-gtz3"
    }
  ]
}

健康狀態

可用的 VM 健康狀態如下：

  • HEALTHY：系統可連線至 VM，也能建立與應用程式健康狀態檢查端點的連線，且回應符合健康狀態檢查定義的要求。
  • DRAINING：虛擬機器正在排空。現有 VM 連線會等候完成，但系統會拒絕新連線。
  • UNHEALTHY：可連線至 VM，但不符合健康狀態檢查定義的要求。
  • TIMEOUT：無法連線至 VM、無法與應用程式健康狀態檢查端點建立連線，或 VM 上的伺服器未在指定逾時時間內回應。舉例來說，這可能是因為防火牆規則設定錯誤，或是 VM 上的伺服器應用程式超載。
  • UNKNOWN：健康狀態檢查系統不瞭解 VM，或目前不瞭解 VM 的健康狀態。在 MIG 中，新的 VM 可能需要 10 分鐘才會開始監控。

新 VM 會傳回 UNHEALTHY 狀態，直到通過健康狀態檢查系統驗證為止。

VM 是否會修復取決於健康狀態：

  • 如果 VM 的健康狀態為 UNHEALTHY 或 TIMEOUT，且已通過初始化期間，代管執行個體群組會立即嘗試修復。
  • 如果 VM 的健康狀態為 UNKNOWN，代管執行個體群組不會立即修復，這是為了避免健康狀態檢查信號暫時無法使用時，系統對 VM 進行不必要的修復。

在下列情況下，自動修復嘗試可能會延遲：

  • VM 在連續多次修復後仍處於不良狀態。
  • 群組中健康狀態不良的 VM 占整體比例相當高。

我們想瞭解您對 VM 健康狀態值的用途、遇到的挑戰或意見回饋。歡迎傳送電子郵件至 mig-discuss@google.com，與我們的團隊分享意見。

查看 VM 的目前動作

當 MIG 正在建立 VM 執行個體時，MIG 會將該執行個體的唯讀 currentAction 欄位設為 CREATING。如果群組附加了自動修復政策，在 VM 建立並執行後，MIG 會將執行個體的目前動作設為 VERIFYING，健康狀態檢查程式則會開始探查 VM 的應用程式。如果應用程式在啟動所需的時間內通過這項初步健康狀態檢查，系統就會驗證 VM，且 MIG 會將 VM 的 currentAction 欄位變更為 NONE。

如要查看 VM 的目前動作，請參閱「查看 VM 的目前動作」。

檢查 MIG 是否穩定

在群組層級，Compute Engine 會填入名為 status 的唯讀欄位，其中包含 isStable 旗標。

如果群組中的所有 VM 都在執行中且健康狀態良好 (也就是每個代管執行個體的currentAction NONE 欄位都設為 true)，則 MIG 會將 status.isStable 欄位設為 true。請注意，MIG 的穩定性取決於自動修復政策以外的群組設定；舉例來說，如果群組自動調整資源配置，且正在水平縮減或擴充，則 MIG 會因自動配置器作業將 status.isStable 欄位設為 false。

如要檢查 MIG 的 status.isStable 欄位值，請參閱「檢查 MIG 是否穩定」。

查看歷來自動修復作業

您可以使用 gcloud CLI 或 REST 查看過去的自動修復事件。

gcloud

使用 gcloud compute operations list 指令搭配篩選器，即可只查看專案中的自動修復事件。

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

如要進一步瞭解特定修復作業，請使用 describe 指令。例如：

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

REST

如果是區域 MIG，請向 regionOperations 資源提交 GET 要求，並加入篩選器，將輸出清單的範圍限定為 compute.instances.repair.* 事件。

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

如為可用區 MIG，請使用 zoneOperations 資源。

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

如要進一步瞭解特定維修作業，請針對該作業提出GET要求。例如：

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

什麼是良好的自動修復健康狀態檢查

用於自動修復功能的健康狀態檢查必須較為保守，這樣才不會預先刪除及重新建立執行個體。如果自動修復程式的健康狀態檢查過於嚴格，自動修復程式可能會將忙碌的執行個體誤判為失敗的執行個體，不必要地加以重新啟動，因而降低了可用性。

  • unhealthy-threshold。應大於 1。最好將此值設為 3 或更大的值。這樣可防止發生如網路封包遺失等罕見失敗狀況。
  • healthy-threshold。值為 2 可以滿足大多數應用程式的需求。
  • timeout。將此時間值設為遠大於 (五倍以上) 預期回應時間。逾時時間必須小於或等於check-interval。這樣可防止意外的延遲狀況 (例如執行個體忙碌運作或網路連線速度緩慢)。
  • check-interval。此值應介於 1 秒和兩倍的逾時值之間 (不會過長也不會過短)。當值過長時，就無法及時找出失敗的執行個體。如果過短，執行個體和網路可能會因每秒發送的大量健康狀態檢查探測器而變得非常忙碌。

自動修復延遲的可能原因

為確保 MIG 在自動修復期間維持穩定，Compute Engine 會套用下列限制。因此，自動修復功能可能會延遲運作。

  • 並行修復次數上限：如果 MIG 中的執行個體健康狀態檢查失敗，MIG 會嘗試在每個區域中自動修復最多 30% 的執行個體 (向上取整)。舉例來說，如果可用區 MIG 有 10 部 VM，其中 4 部健康狀態檢查失敗，則 MIG 最多會嘗試修復 3 部 VM (10 部 VM 的 30%)。如果是區域性 MIG，MIG 會嘗試在 VM 發生故障的每個可用區中，修復最多 30% 的執行個體。舉例來說，如果某個可用區有 3 個執行個體，MIG 最多只能修復該可用區的 1 個執行個體。

  • 後續修復嘗試之間的延遲時間：如果執行個體在自動修復後仍持續未通過健康狀態檢查，代管執行個體群組會逐步增加後續修復嘗試之間的間隔時間。重試間隔最多約 60 分鐘。

後續步驟