為 MIG 中的執行個體設定健康狀態檢查與自動修復

代管執行個體群組 (MIG) 會主動讓您虛擬機器 (VM) 的執行個體保持可用 (即處於 RUNNING 狀態),以維持應用程式的高可用性,如果執行個體停止 RUNNING,且不是由 MIG 引發狀態變更 (例如,硬體故障而不是自動配置器決定),則 MIG 會自動重新建立該執行個體。但是,依賴執行個體狀態來判斷應用程式的健康狀況可能不夠周延。舉例來說,檢查執行個體是否為 RUNNING 無法偵測出應用程式是否故障,例如凍結、超載或當機等問題。

如要提高應用程式的可用性,以及驗證應用程式是否有回應,您可以為代管執行個體群組 (MIG) 設定自動修復政策。

自動修復政策會依賴以應用程式為基礎的健康狀態檢查,驗證應用程式是否如預期回應。相較於只驗證執行個體是否處於 RUNNING 狀態,檢查應用程式是否有回應的做法則更為精確。

如果自動修復程式判定應用程式沒有回應,代管執行個體群組會自動重新建立該執行個體。如果是先佔執行個體,只要能再使用必要資源,群組就會重新建立執行個體。

自動修復行為

當自動修復機制重新建立健康狀態不良的執行個體時,會透過原本用以建立虛擬機器 (VM) 執行個體的原始執行個體範本 (不一定是代管執行個體群組中的目前執行個體範本) 來進行修復。例如,如果 VM 執行個體使用 instance-template-a 建立,然後您將代管執行個體群組更新為在 OPPORTUNISTIC 模式下使用 instance-template-b,則自動修復功能仍會使用 instance-template-a 重新建立執行個體。這是因為在自動修復的情況下,重建執行個體的動作並不是使用者自己觸發的,因此 Compute Engine 不會假設 VM 執行個體應使用新的範本。如果您要套用新範本,請參閱變更代管執行個體群組的執行個體範本一節。

無論何時,自動並行修復的執行個體數都會小於代管執行個體群組大小,如以一來,即使自動修復政策不適用於現有的工作負載、防火牆規則設定有誤,或者存在網路連線或基礎架構問題,導致某個健康狀態良好的執行個體被誤判為健康狀態不良,仍然能夠確保代管的群組可以繼續執行一部分的執行個體。但是,如果區域代管執行個體群組只有一個執行個體,或地區代管執行個體群組中的每個區域只有一個執行個體,自動修復功能將在執行個體變為健康狀態不良時,重新建立這些執行個體。

自動修復不會在執行個體初始化期間重新建立該執行個體。詳情請參閱 autoHealingPolicies[].initialDelaySec 屬性。如果執行個體正在啟動中,這個設定會延遲自動修復,使系統無法進行檢查,以避免過早重新建立執行個體的可能性。當執行個體的 currentActionVERIFYING 時,初始延遲計時器會啟動。

自動修復功能與磁碟

根據執行個體的範本對其進行重新建立時,自動修復程式會以不同的方式處理不同類型的磁碟。一些磁碟設定可能會導致自動修復程式在嘗試重新建立代管執行個體時失敗。

磁碟類型 autodelete 自動修復作業期間的行為
新永久磁碟 true 系統會如執行個體範本所指定,重新建立磁碟。重新建立磁碟及其執行個體時,寫入該磁碟的任何資料都會遺失。
新永久磁碟 false 在自動修復程式重新建立執行個體時,系統會保留並重新連結磁碟。
現有的永久磁碟 true 舊磁碟會遭到刪除。VM 執行個體重新建立會失敗,因為 Compute Engine 無法將刪除的磁碟重新連結到執行個體。
現有的永久磁碟 false 系統會如執行個體範本所指定,重新連結舊磁碟。磁碟中的資料會保留。但是,針對現有讀寫磁碟,代管執行個體群組最多只能擁有一個 VM,因為在讀寫模式下,單一永久磁碟無法連結至多個執行個體。
新的本機 SSD 系統會如執行個體範本所指定,重新建立磁碟。重新建立或刪除執行個體時,本機 SSD 中的資料會遺失。

自動修復程式不會重新連結未在執行個體範本中指定的磁碟,例如建立 VM 之後您手動連結至 VM 的磁碟。

如要保留寫入磁碟的重要資料,請採取預防措施,例如:

  • 為一般永久磁碟建立快照

  • 將資料匯出至其他資源,例如 Cloud Storage。

如果執行個體有您要保留的重要設定,Google 也建議您在執行個體範本中使用自訂映像檔。自訂映像檔包含您需要的任何自訂設定。當您在執行個體範本中指定自訂映像檔時,代管執行個體群組 (MIG) 會使用自訂映像檔 (其中含有您所需要的自訂設定項目) 來重新建立執行個體。

設定健康狀態檢查和自動修復政策

一個代管執行個體群組最多可設定一項自動修復政策。

一項健康狀態檢查最多可以套用到 50 個代管執行個體群組。 如果超過 50 個群組,請建立多個健康狀態檢查。

健康狀態檢查設定範例

以下範例顯示如何在代管執行個體群組上使用健康狀態檢查。在這個範例中,您會建立健康狀態檢查,藉此查看通訊埠 80 的網路伺服器回應。為了讓健康狀態檢查探測器能連線到每個網路伺服器,請設定防火牆規則。最後,設定群組的自動修復政策,將健康狀態檢查套用至代管執行個體群組。

Console

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

    例如,建立會在通訊埠 80 中尋找回應的健康狀態檢查,且這個檢查必須能容忍幾次失敗,之後才將執行個體標示為 UNHEALTHY 並重新建立。在這個範例中,如果執行個體成功傳回一次,健康狀態就會標示為良好。如果連續 3 次未成功傳回,健康狀態就會標示為不良。

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

      前往建立健康狀態檢查頁面

    2. 為健康狀態檢查指定名稱,例如 example-check
    3. 針對「Protocol」(通訊協定)欄,確認 [HTTP] 已選取。
    4. 在「Port」(通訊埠) 欄中,輸入 80
    5. 在「Check interval」(檢查時間間隔) 欄中,輸入 5
    6. 在「Timeout」(逾時) 欄中,輸入 5
    7. 設定「Healthy threshold」(良好健康狀態判定門檻),決定系統必須連續傳回多少次成功執行的健康狀態檢查結果,才能將不良執行個體標示為健康狀態良好。在這個範例中,請輸入 1
    8. 設定「Unhealthy threshold」(不良健康狀態判定門檻),決定系統必須連續傳回多少次失敗的健康狀態檢查,才能將健康狀態良好的執行個體標示為不良。在這個範例中,請輸入 3
    9. 按一下 [Create] (建立),建立健康狀態檢查。
  2. 建立防火牆規則,允許健康狀態檢查探測器連線至應用程式。

    健康狀態檢查探測器的來源位址範圍介於 130.211.0.0/2235.191.0.0/16 之間,因此請確保網路防火牆規則允許健康狀態檢查連線。在這個範例中,我們的代管執行個體群組使用 default 網路,且執行個體使用通訊埠 80 接聽。如果尚未在預設網路開啟通訊埠 80,請建立防火牆規則。

    1. 前往 GCP 主控台的「Create a firewall rule」(建立防火牆規則) 頁面。

      前往建立防火牆規則頁面

    2. 在「Name」(名稱) 部分,輸入防火牆規則的名稱 (例如 allow-health-check)。
    3. 在「Network」(網路) 中選取 default
    4. 在「Source filter」(來源篩選器) 中選取 IP ranges
    5. 在「Source IP ranges」(來源 IP 範圍) 欄中,輸入 130.211.0.0/2235.191.0.0/16
    6. 在「Protocols and ports」(通訊協定與通訊埠) 中,選取 [Specified protocols and ports] (指定的通訊協定與通訊埠) 然後輸入 tcp:80
    7. 按一下 [Create] (建立)
  3. 為地區或區域代管執行個體群組設定自動修復政策,藉此套用健康狀態檢查。

    1. 前往 GCP Console 的「Instance Groups」(執行個體群組) 頁面。

      前往執行個體群組頁面

    2. 在清單的「Name」(名稱) 欄底下,按一下要套用健康狀態檢查之執行個體群組的名稱。
    3. 按一下 [Edit Group] (編輯群組),修改這個代管執行個體群組。
    4. 在「Autohealing」(自動修復) 底下,選取您先前建立的健康狀態檢查。
    5. 變更或保留「Initial delay」(初始延遲) 設定。如果執行個體正在啟動中,這個設定會延遲自動修復,避免過早重新建立執行個體的可能性。當執行個體的 currentActionVERIFYING 時,初始延遲計時器會啟動。
    6. 按一下 [Save] (儲存) 套用您的變更。

    自動修復功能可能要過 15 分鐘後,才會開始監控群組中的執行個體。

gcloud

如要使用本指南提供的指令列範例,請安裝 gcloud 指令列工具,或是使用 Cloud Shell

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

    例如,建立會在通訊埠 80 中尋找回應的健康狀態檢查,且這個檢查必須能容忍幾次失敗,之後才將執行個體標示為 UNHEALTHY 並重新建立。在這個範例中,如果執行個體成功傳回一次,健康狀態就會標示為良好。如果連續 3 次未成功傳回,健康狀態就會標示為不良。

    gcloud compute health-checks create http example-check --port 80 \
        --check-interval 30s \
        --healthy-threshold 1 \
        --timeout 10s \
        --unhealthy-threshold 3
    
  2. 建立防火牆規則,允許健康狀態檢查探測器連線至應用程式。

    健康狀態檢查探測器的來源位址範圍介於 130.211.0.0/2235.191.0.0/16 之間,因此請確認防火牆規則允許健康狀態檢查連線。在這個範例中,我們的代管執行個體群組使用 default網路,且執行個體使用通訊埠 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
    
  3. 為地區或區域代管執行個體群組設定自動修復政策,藉此套用健康狀態檢查。

    使用 update 指令,將健康狀態檢查套用至代管執行個體群組。

    如果執行個體正在啟動中,initial-delay 設定會延遲自動修復,避免過早重新建立執行個體的可能性。當執行個體的 currentActionVERIFYING 時,初始延遲計時器會啟動。

    例如:

    gcloud compute instance-groups managed update my-mig \
        --health-check example-check \
        --initial-delay 300 \
        --zone us-east1-b
    

    自動修復功能可能要過 15 分鐘後,才會開始監控群組中的執行個體。

API

如要使用本指南中的 API 範例,請設定 API 存取權

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

    例如,建立會在通訊埠 80 中尋找回應的健康狀態檢查,且這個檢查必須能容忍幾次失敗,之後才將執行個體標示為 UNHEALTHY 並重新建立。在這個範例中,如果執行個體成功傳回一次,健康狀態就會標示為良好。如果連續 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/2235.191.0.0/16 之間,因此請確認防火牆規則允許健康狀態檢查連線。在這個範例中,我們的代管執行個體群組使用 default 網路,且執行個體使用通訊埠 80 接聽。如果尚未在預設網路開啟通訊埠 80,請建立防火牆規則。

    POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://compute.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"
      }
     ]
    }
    
  3. 為地區或區域代管執行個體群組設定自動修復政策,藉此套用健康狀態檢查。

    自動修復政策是 instanceGroupManager 資源或 regionInstanceGroupManager 資源的一部分。

    您可以使用 insertpatch 方法設定自動修復政策。

    下列範例使用 instanceGroupManagers.patch 方法設定自動修復政策。

    PATCH https://compute.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
    {
      "autoHealingPolicies": [
        {
          "healthCheck": "global/healthChecks/example-check",
          "initialDelaySec": 300
        }
      ],
    }
    

    如果執行個體正在啟動中,initialDelaySec 設定會延遲自動修復,避免過早重新建立執行個體的可能性。當執行個體的 currentActionVERIFYING 時,初始延遲計時器會啟動。

    自動修復功能可能要過 15 分鐘後,才會開始監控群組中的執行個體。

    如要關閉以應用程式為基礎的自動修復功能,請將自動修復政策設為空白值 (autoHealingPolicies[])。如果使用 autoHealingPolicies[],則代管執行個體群組僅會重新建立非 RUNNING 狀態的執行個體。

    您可以讀取 instanceGroupManagers.autoHealingPolicies 欄位來取得代管執行個體群組的自動修復政策,並使用下列其中一種方法取得代管執行個體群組資源:

檢查狀態

您可以檢查每個執行個體目前的健康狀態、在每個執行個體上檢查目前的動作或查看群組狀態,藉此驗證是否已建立執行個體,以及其應用程式是否有回應。

首次為代管執行個體群組附加健康狀態檢查時,監控作業可能要過 15 分鐘後才會開始進行。

執行個體健康狀態

如果您為代管執行個體群組設定了自動修復功能,則可以檢視每個執行個體的健康狀態。

檢查代管執行個體的健康狀態以獲得下列資訊:

  • 識別未經自動修復而健康狀態不良的 VM。即使 VM 執行個體在下列情況中已診斷為不良狀態,也可能無法立即修復:
    • VM 仍在啟動中,並且尚未經過初始延遲。
    • 目前有大量健康狀態不良的執行個體正在自動修復。自動修復程式會延遲進一步的自動修復操作,以確保群組繼續執行執行個體的子集。
  • 偵測健康狀態檢查設定錯誤。舉例來說,如果執行個體回報健康狀態為 TIMEOUT,即可偵測到設定錯誤的防火牆規則,或無效的應用程式健康狀態檢查端點。
  • 透過測量 VM 轉換為 RUNNING 狀態到 VM 轉換為 HEALTHY 健康狀態之間的時間長度,判斷要設定的初始延遲值。您可以透過輪詢 list-instances 方法測量這個時間差距。

我們想要瞭解您的用途、難題或 VM 執行個體健康狀態值的相關意見。請前往以下網址,並與我們的團隊分享您的寶貴意見:mig-discuss@google.com

健康狀態

可用的執行個體健康狀態如下:

  • HEALTHY:可連線至執行個體,可建立到應用程式健康狀態檢查端點的連線,且回應符合由健康狀態檢查定義的需求。
  • DRAINING:正在排除執行個體。有時間完成執行個體的現有連線,但是系統會拒絕新的連線。
  • UNHEALTHY:可連線至執行個體,但不符合健康狀態檢查所定義的需求。
  • TIMEOUT:不能連線至執行個體;無法建立與應用程式健康狀態檢查端點的連線,或是 VM 執行個體上的伺服器在指定的逾時時間內未回應。例如,原因可能是防火牆規則設定錯誤,或是 VM 執行個體上的伺服器應用程式超載。
  • UNKNOWN:健康狀態檢查系統目前不知道該執行個體或其健康狀態為何。系統可能要過 15 分鐘後,才會開始監控 MIG 中的新執行個體。

新執行個體會傳回 UNHEALTHY 狀態,直到健康狀態檢查系統對其進行驗證。

執行個體是否已修復取決於其健康狀態:

  • 如果執行個體的健康狀態為 UNHEALTHYTIMEOUT,且已超過初始化期間,則自動修復服務會立即嘗試修復作業。
  • 如果執行個體的健康狀態為 UNKNOWN,則不會立即修復。這是為了防止不必要的執行個體修復作業,因為健康狀態檢查訊號會暫時無法使用。

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

  • 連續多次修復後,執行個體的健康狀態仍為不良。
  • 存於群組中健康狀態不良的執行個體佔了絕大部分。

可使用主控台gcloud 指令列工具或 API 檢視健康狀態。

Console

  1. 前往 GCP Console 的「Instance Groups」(執行個體群組) 頁面。

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

  2. 在清單的「Name」(名稱) 欄底下,按一下要檢查之執行個體群組的名稱。按一下名稱會開啟頁面,其中包含執行個體群組的屬性及群組內執行個體的清單。

  3. 如果執行個體健康狀態不良,您可在健康狀態問題欄位中檢視執行個體的健康狀態。

gcloud

使用 list-instances 子指令。

$ gcloud beta compute instance-groups managed list-instances [INSTANCE_GROUP]
NAME              ZONE                  STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE                            VERSION_NAME  LAST_ERROR
igm-with-hc-fvz6  europe-west1          RUNNING  HEALTHY       NONE    my-template
igm-with-hc-gtz3  europe-west1          RUNNING  HEALTHY       NONE    my-template

HEALTH_STATE 欄位會顯示出每個執行個體的健康狀態。

API

針對地區代管執行個體群組,請對 listManagedInstances 方法建構 POST 要求:

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP]/listManagedInstances

針對區域代管執行個體群組,請使用區域代管執行個體群組 listManagedInstances 方法:

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]/listManagedInstances

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

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

目前對執行個體的動作

如果正在建立代管執行個體,則其 currentActionCREATING。如果該群組已附加自動修復政策,則當代管執行個體建立完成且開始運作時,執行個體的 currentAction 將變成 VERIFYING,且健康狀態檢查工具會開始探測執行個體的應用程式。如果應用程式在啟動期間內通過這項初始健康狀態檢查,則執行個體會通過驗證,且其 currentAction 會變成 NONE

如要查看代管執行個體群組中每個執行個體正在執行的 currentAction 及其 status,請使用 gcloud 指令列工具API

gcloud

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] [--filter="zone:([ZONE])" | --filter="region:([REGION])"]

gcloud 傳回執行個體群組中的執行個體清單,以及其各自的狀態和目前動作。例如:

NAME               ZONE           STATUS    ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f            CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING  DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING   NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING   NONE      my-old-template

API

在 API 中,對 regionInstanceGroupManagers.listManagedInstances 方法提出 POST 要求:針對區域代管執行個體群組,請使用 instanceGroupManagers.listManagedInstances 方法。

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

API 傳回群組的執行個體清單,其中包含每個執行個體的 instanceStatuscurrentAction

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  }
 ]
}

對於代管執行個體群組中的每個執行個體,執行個體的狀態將由其 instanceStatus 欄位描述。如要查看有效 instanceStatus 欄位值的清單,請參閱檢查執行個體狀態

假如執行個體正在經歷某種類型的變更,則系統會用下列任一動作填入 currentAction 欄位,協助您追蹤變更進度。否則,currentAction 欄位為 NONE

可能的 currentAction 值為:

  • ABANDONING:執行個體正從代管執行個體群組中移除。
  • CREATING:執行個體目前正在建立。
  • CREATING_WITHOUT_RETRIES:執行個體目前正在建立,且不會重試;如果執行個體在第一次嘗試時無法建立,則代管執行個體群組將不會嘗試再次取代執行個體。
  • DELETING:執行個體目前正在刪除。
  • RECREATING:執行個體已遭刪除,目前正被取代。
  • REFRESHING:執行個體正從其目前目標集區中移除,並正讀入至現有的目標集區清單中 (此清單可能會與現有目標集區相同或不同)。
  • RESTARTING:正在使用 stopstart 方法重新啟動執行個體。
  • VERIFYING:執行個體已建立,目前正受到驗證。
  • NONE:目前並未對執行個體執行任何動作。

群組狀態

在群組層級,Compute Engine 會在名稱為 status 的唯讀欄位中填入值,該欄位包含isStable 標記。

如果群組中的所有執行個體均為執行中且健康狀態良好 (也就是說,每個代管執行個體的 currentAction 都是 NONE),則狀態值將顯示為 status.isStable==true。請注意,代管執行個體群組的穩定性取決於自動修復政策以外的群組設定;舉例來說,假設您的群組能自動調度資源且目前正在擴充資源,則因為自動配置器作業的關係,狀態值將顯示為 isStable==false

如想確認代管執行個體群組是否正在執行中且健康狀態良好,查看 instanceGroupManagersregionInstanceGroupManagers 資源的 status.isStable 欄位值即可驗證。

您也可以使用帶有 --stable 標記的 gcloud 指令列工具 wait-until 指令,等候群組的 status.isStable 設為 true

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

status.isStable 設為 false 時,代表變更已生效、待處理或代管執行個體群組本身遭到修改。

status.isStable 設為 true,則表示:

  • 代管執行個體群組中沒有任何執行個體遭到任何類型的變更,且所有執行個體的 currentAction 都顯示 NONE
  • 代管執行個體群組中的執行個體沒有任何待處理的變更。
  • 代管執行個體群組本身未經修改。

您可以透過多種方式來修改代管執行個體群組,例如:

  • 由您發出推出新執行個體範本的要求。
  • 由您發出建立、刪除、調整大小或更新群組中執行個體的要求。
  • 自動配置器要求調整群組的大小。
  • 自動修復程式資源正在取代代管執行個體群組中一或多個健康狀態不良的執行個體。
  • 在地區代管執行個體群組中,部分執行個體正在重新分配

完成所有動作後,該代管執行個體群組的 status.isStable將再次設為 true

查看自動修復作業記錄

您可以使用 gcloud 工具或 API 檢視過去的自動修復事件。

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

API

針對地區代管執行個體群組,請向 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

如果是區域代管執行個體群組,請使用 zoneOoperations 資源。

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/us-east1-b/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

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

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

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

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Compute Engine 說明文件