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

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

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

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

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

事前準備

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

  請根據您打算如何使用本頁範例，選取對應的分頁標籤：

  控制台

  使用 Google Cloud 控制台存取 Google Cloud 服務和 API 時，不需要設定驗證機制。

  gcloud

  1. 安裝 Google Cloud CLI。 安裝完成後，請執行下列指令，初始化 Google Cloud CLI：

     gcloud init

     如果採用外部識別資訊提供者 (IdP)，必須先 使用聯合身分登入 gcloud CLI。

     注意：如果您已經安裝 gcloud CLI，請務必執行 gcloud components update，確認您安裝的是最新版本。
• 設定預設區域和可用區。

Terraform

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

1. 安裝 Google Cloud CLI。

2. 若您採用的是外部識別資訊提供者 (IdP)，請先 使用聯合身分登入 gcloud CLI。

3. 如果您使用的是本機殼層，請為使用者帳戶建立本機驗證憑證：

   gcloud auth application-default login

   如果您使用的是 Cloud Shell，則不必執行這項操作。

   如果系統傳回驗證錯誤，且您使用的是外部識別資訊提供者 (IdP)，請確認您已 使用聯合身分登入 gcloud CLI。

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

REST

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

安裝 Google Cloud CLI。

如果採用外部識別資訊提供者 (IdP)，必須先 使用聯合身分登入 gcloud CLI。

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

定價

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

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

如要在 MIG 中設定以應用程式為基礎的健康狀態檢查和自動修復功能，請務必執行下列操作：

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

提示： 負載平衡和自動修復功能應使用不同的健康狀態檢查。負載平衡的健康狀態檢查會偵測沒有回應的 VM，並將流量導向其他位置。自動修復的健康狀態檢查會偵測健康狀態不良的 VM，並主動重新建立這些 VM，因此這類檢查應比負載平衡的健康狀態檢查更為保守。詳情請參閱「如何建立良好的自動修復健康狀態檢查」。

建立健康狀態檢查

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

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

這項工作需要的權限

如要執行這項工作，您必須具備下列權限：

• 如要建立健康狀態檢查，則須具備專案的 compute.healthChecks.create。
• 要使用之健康狀態檢查的 compute.healthChecks.use 權限。
• 如要建立防火牆，則須具備專案的 compute.firewalls.create 權限。
• 如果建立防火牆，則為網路上的 compute.networks.updatePolicy。

下列預先設定的角色提供上述權限。

• compute.networkAdmin：可建立健康狀態檢查。
• compute.securityAdmin：可設定防火牆規則，以便進行健康狀態檢查連線。

控制台

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

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

   1. 前往 Google Cloud 控制台的「Create a health check」(建立健康狀態檢查) 頁面。

      前往「Create a health check」(建立健康狀態檢查) 頁面

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

   3. 選取「Scope」(範圍)。您可以選取「Regional」(區域) 或「Global」(全域)。在本範例中，請選取「Global」。

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

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

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

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

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

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

   注意： 如果健康狀態檢查探測遭到防火牆規則封鎖，就會將 VM 標示為 UNHEALTHY，因為探測無法連線至應用程式。這可能會導致系統自動重新建立可能健康的 VM。

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

   1. 前往 Google Cloud 控制台的「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 連續 3 次傳回失敗，就會標示為健康狀態不良。下列指令會建立全域健康狀態檢查。

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

   注意： 請使用支援 HTTP、HTTPS、TCP 和 SSL (TLS) 通訊協定的新版健康狀態檢查。舊版 Compute Engine HTTP/HTTPS 健康狀態檢查仍可正常運作。

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

   注意： 如果健康狀態檢查探測遭到防火牆規則封鎖，就會將 VM 標示為 UNHEALTHY，因為探測無法連線至應用程式。這可能會導致系統自動重新建立可能健康的 VM。

   健康狀態檢查探測來自 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 連續 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 資源建立防火牆。

   注意： 如果健康狀態檢查探測遭到防火牆規則封鎖，就會將 VM 標示為 UNHEALTHY，因為探測無法連線至應用程式。這可能會導致系統自動重新建立可能健康的 VM。

   健康狀態檢查探測器的來源位址範圍介於 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 連續 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
   }
   

   注意： 請使用支援 HTTP、HTTPS、TCP 和 SSL (TLS) 通訊協定的新版健康狀態檢查。舊版 Compute Engine HTTP/HTTPS 健康狀態檢查仍可正常運作。

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

   注意： 如果健康狀態檢查探測遭到防火牆規則封鎖，就會將 VM 標示為 UNHEALTHY，因為探測無法連線至應用程式。這可能會導致系統自動重新建立可能健康的 VM。

   健康狀態檢查探測器的來源位址範圍介於 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 中設定健康狀態檢查後，您也可以關閉自動修復功能。

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

這項工作需要的權限

如要執行這項工作，您必須具備下列權限：

• MIG 上的 compute.instanceGroupManagers.update。

下列預先設定的角色提供上述權限。

• compute.instanceAdmin.v1：在 MIG 中建立及更新自動修復政策。

控制台

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

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

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

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

4. 按一下「Instance lifecycle and autohealing」(執行個體生命週期和自動修復)，展開該部分。
   1. 在「Autohealing」(自動修復) 區段中，針對「Health check」(健康狀態檢查) 選取全域或區域健康狀態檢查。
   2. 在「Initial delay」(初始延遲) 部分，請使用預設值或視需要修改。

      「初始延遲時間」是指新 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：執行個體範本的網址，用於在 MIG 中建立執行個體。網址可以包含執行個體範本的 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，請使用 instanceGroupManager.patch 方法。
• 如果是區域性 MIG，請使用 regionInstanceGroupManager.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，請使用 instanceGroupManager.insert 方法。
• 如果是區域性 MIG，請使用 regionInstanceGroupManager.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：執行個體範本的網址，用於在 MIG 中建立執行個體。網址可以包含執行個體範本的 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 分鐘 (設定的初始延遲時間)
• + 1 分鐘 (檢查間隔 * 健康狀態良好門檻，即 60 秒 * 1)
• = 16 分鐘後，VM 會標示為健康狀態良好或重新建立

設定健康狀態檢查，但不啟用自動修復功能

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

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

這項工作需要的權限

如要執行這項工作，您必須具備下列權限：

• MIG 上的 compute.instanceGroupManagers.update。

下列預先設定的角色提供上述權限。

• compute.instanceAdmin.v1：在 MIG 中建立及更新自動修復政策。

控制台

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

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

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

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

4. 按一下「Instance lifecycle and autohealing」(執行個體生命週期和自動修復)，展開該部分。
   1. 在「Autohealing」(自動修復) 區段中，針對「Health check」(健康狀態檢查) 選取全域或區域健康狀態檢查。
   2. 在「Initial delay」(初始延遲) 部分，請使用預設值或視需要修改。

      「初始延遲時間」是指新 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：執行個體範本的網址，用於在 MIG 中建立執行個體。網址可以包含執行個體範本的 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，請使用 instanceGroupManager.patch 方法。
  • 如果是區域性 MIG，請使用 regionInstanceGroupManager.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，請使用 instanceGroupManager.insert 方法。
  • 如果是區域性 MIG，請使用 regionInstanceGroupManager.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：執行個體範本的網址，用於在 MIG 中建立執行個體。網址可以包含執行個體範本的 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. 前往 Google Cloud 控制台的「Instance groups」(執行個體群組) 頁面。

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

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

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

4. 按一下「Instance lifecycle and autohealing」(執行個體生命週期和自動修復)，展開該部分。

5. 在「Autohealing」(自動修復) 區段中，針對「Health check」(健康狀態檢查) 選取「No health check」(不進行健康狀態檢查)。

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

gcloud

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

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

將 MIG_NAME 替換為 MIG 名稱。

REST

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

• 如為可用區 MIG，請使用 instanceGroupManagers.patch 方法
• 如果是區域性 MIG，請使用 regionInstanceGroupManagers.patch 方法

舉例來說，如要移除可用區 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. 前往 Google Cloud 控制台的「Instance groups」(執行個體群組) 頁面。

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

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

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

   「VM instance lifecycle」(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，請使用 instanceGroupManagers.get 方法
• 如果是區域性 MIG，請使用 regionInstanceGroupManagers.get 方法

舉例來說，如要查看可用區 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 是否健康
• 查看 VM 目前執行的動作
• 檢查 MIG 是否穩定

檢查 VM 是否健康

如果您在 MIG 中設定了以應用程式為基礎的健康狀態檢查，可以查看每個代管執行個體的健康狀態。

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

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

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

這項工作需要的權限

如要執行這項工作，您必須具備下列權限：

• MIG 的compute.instanceGroupManagers.get

控制台

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

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

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

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

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。

根據預設，gcloud CLI 會在支援 ANSI 顏色輸出的互動式終端機視窗中，顯示以不同顏色標示的值，除非已啟用螢幕閱讀器模式。如要進一步瞭解色彩配置和如何關閉著色功能，請參閱「瞭解 gcloud CLI 中的狀態顏色」。

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 正在進行排空作業。VM 的現有連線有時間完成，但新的連線會遭到拒絕。
• UNHEALTHY：可連線至 VM，但不符合健康狀態檢查定義的需求。
• TIMEOUT：無法連線至 VM、無法連線至應用程式健康狀態檢查端點，或 VM 上的伺服器未在指定逾時時間內回應。舉例來說，這可能是因為防火牆規則設定錯誤，或 VM 上的伺服器應用程式超載。
• UNKNOWN：健康狀態檢查系統不知道 VM，或目前不知道其健康狀態。MIG 中新 VM 的監控作業可能需要 10 分鐘才會開始。

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

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

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

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

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

我們想瞭解您的用途、遇到的問題，或對 VM 健康狀態值的意見。歡迎透過 [e-mail] 與我們的團隊分享意見。

查看 VM 目前執行的動作

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

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

檢查 MIG 是否穩定

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

如果群組中的所有 VM 都在運作且健康狀態良好 (也就是每個代管執行個體的 currentAction 欄位都設為 NONE)，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 個執行個體。

• 後續修復嘗試之間的延遲時間：如果執行個體在自動修復後仍多次未通過健康狀態檢查，MIG 會逐漸增加後續修復嘗試之間的間隔時間。重試之間的延遲時間最多可延長至約 60 分鐘。

後續步驟

• 請嘗試針對高可用性應用程式使用自動修復功能教學課程。
• 監控 VM 健康狀態變更。
• 在修復期間套用設定更新。
• 如果您已關閉自動修復功能，請開啟修復或自動修復功能。