排解 VM 關機和重新啟動的問題

本文將說明 Compute Engine 執行個體意外關閉及重新啟動的常見原因和防範方式。

系統事件或管理員活動可能會導致執行個體關閉和重新啟動。系統事件關閉和重新啟動是由 Google 系統或執行個體的作業系統所造成。管理員活動關閉和重新啟動是由使用者或服務帳戶產生的 API 呼叫所造成。系統會記錄所有關閉和重新啟動狀況，但從執行個體內部啟動的重新啟動作業除外。

事前準備

• 如果尚未設定，請先設定驗證機制。「驗證」是指驗證身分，以便存取 Google Cloud 服務和 API 的程序。如要從本機開發環境執行程式碼或範例，請選取下列任一選項，以便對 Compute Engine 進行驗證：
  

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

  gcloud

  1. After installing the Google Cloud CLI, initialize it by running the following command:

     gcloud init

     If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  2. Set a default region and zone.

診斷執行個體關機和重新啟動的問題

如要診斷執行個體自行關閉或重新啟動的原因，您必須查詢執行個體的記錄檔。如要快速找出日後 VM 關閉或重新啟動的原因，請建立資訊主頁，其中包含記錄檔。查詢記錄檔後，請查看 method 和 principalEmail 欄位，找出是哪些事件和使用者/服務展開關閉/重新啟動作業。

查詢 Cloud 稽核記錄

查詢 Cloud 稽核記錄，以便列出可能造成關機或重新啟動的系統事件和管理活動。

查看 Cloud 稽核記錄

查看 Cloud 稽核記錄的 method 和 principalEmail 欄位，瞭解 VM 關閉或重新啟動的原因。

1. 請查看 Cloud 稽核記錄的 method 欄位，並與下表列出的各項方法進行比較。

   方法	關機類型	說明
   compute.instances.repair.recreateInstance	系統事件	如果 VM 屬於代管執行個體群組 (MIG)，當 VM 狀態從 RUNNING 變更，且 MIG 未發起狀態變更時，MIG 會重新建立 VM。 非由 MIG 啟動的執行個體狀態變更包括： 硬體故障。 終止 先占執行個體。 當 VM 執行個體未設為即時遷移時，基礎架構維護事件。 使用下列任一方法刪除 MIG 執行個體： instances.delete API 方法 gcloud compute instances delete 指令
   compute.instances.hostError	系統事件	如果出現主機錯誤 (compute.instances.hostError)，表示託管您運算執行個體的實體機器或資料中心基礎架構發生硬體或軟體錯誤，導致執行個體當機。主機發生全面硬體故障或其他硬體問題時，可能會導致無法即時遷移執行個體。如果執行個體已設定為自動重新啟動 (這是預設設定)，Compute Engine 會重新啟動執行個體，通常會在偵測到錯誤後的三分鐘內完成。視問題而定，重新啟動作業最多可能需要 5.5 分鐘。 有時，在主機發生錯誤前，運算執行個體可能會停止回應。您可以設定主機錯誤復原逾時時間，縮短 Compute Engine 等待重新啟動或終止執行個體的時間。詳情請參閱「設定可用性政策」。 實體硬體和軟體故障可能偶爾會發生，但並不常見。如要保護您的應用程式和服務，不受這類可能會造成干擾的系統事件影響，請參閱以下資源： 設計完善可靠的系統 可擴充及具有彈性的應用程式模式 建立代管執行個體群組 Google 還提供代管服務，例如 App Engine 和 App Engine 彈性環境。
   compute.instances.automaticRestart	系統事件	如果 VM 的 automaticRestart 主機維護政策設為 true，則會在 hostError 事件或 terminateOnHostMaintenance 事件後發生此事件。在記錄中，這個記錄前面會先出現 hostError 或 terminateOnHostMaintenance 記錄項目。 如要變更 VM 的主機維護政策，請參閱「 更新執行個體的選項」。
   compute.instances.guestTerminate	系統事件	VM 的作業系統啟動關機程序。
   compute.instances.terminateOnHostMaintenance	系統事件	如果您將 VM 的 onHostMaintenance 主機維護政策設為 TERMINATE，當 Google 必須將 VM 移至其他主機的維護事件發生時，Compute Engine 就會停止 VM。 如要變更 VM 的 onHostMaintenance 政策，請參閱 更新執行個體的選項。
   compute.instances.preempted	系統事件	Compute Engine 先占 Spot VM 或舊版先占 VM： 當 Compute Engine 先佔 Spot VM 時，會根據 Spot VM 的 終止動作，停止或刪除 Spot VM。Spot VM 沒有執行時間上限。 當 Compute Engine 先占先占 VM 時，Compute Engine 會在 VM 執行 24 小時後將其停止。如要避免這些限制，請改用 Spot VM。 Spot VM 和先占 VM 是額外的 Compute Engine 容量，因此 Compute Engine 可能會在其他地方需要容量時搶佔這些 VM。您可以遵循最佳做法，減輕優先權的影響。或者，如果您需要使用者控管的執行階段 VM，請改為建立標準 VM。
   compute.instances.stop	管理員活動	使用者或服務帳戶已停止 VM。 請繼續執行下一個步驟，找出停止 VM 的使用者或服務帳戶。如要瞭解如何重新啟動 VM，請參閱「 重新啟動已停止的執行個體」。
   compute.instances.delete	管理員活動或系統事件	使用者或服務帳戶刪除了您的 VM，或是 VM 已設為自動刪除。 具體來說，compute.instances.delete 方法的記錄可能會指出 VM 的下列任何要求： 使用者或服務帳戶要求直接刪除 VM 的請求，只會透過使用者或服務帳戶的 compute.instances.delete 方法表示。 自動刪除 VM 的要求會透過 system@google.com 的 compute.instances.delete 方法表示，但說明自動刪除原因的方法可能會或不會顯示在 Cloud Audit Logs 中。 舉例來說，如果 Spot VM 已設定為在先占期間自動刪除，且遭到先占，您會看到 system@google.com 中的 compute.instances.delete 方法，但不一定會看到 compute.instances.preempted 方法。 在 compute.instances.delete 方法前後發生的 VM 要求，可能會或不會出現在 Cloud 稽核記錄中。 舉例來說，如果 VM 在刪除前不久因主機維護而停止運作，您會看到 compute.instances.delete 方法，但可能也會看到 compute.instances.terminateOnHostMaintenance 方法，也可能不會。 請繼續執行下一個步驟，找出刪除 VM 的使用者或服務帳戶。如要瞭解如何建立新的 VM，請參閱「 建立及啟動 VM」。
   compute.instances.insert	管理員活動	使用者或服務帳戶建立了 VM。 請繼續執行下一個步驟，找出建立 VM 的使用者或服務帳戶。如要瞭解如何建立新的 VM，請參閱「 建立及啟動 VM」。
   compute.instances.reset	管理員活動	使用者或服務帳戶重設了您的 VM。 請繼續執行下一個步驟，找出停止 VM 的使用者或服務帳戶。

2. 查看 Cloud 稽核記錄的 principalEmail 欄位，找出啟動關閉或重新啟動作業的使用者或服務。下表列出會啟動關機或重新啟動作業的常見 Google 代管服務。

   電子郵件	說明
   system@google.com	系統事件導致關機或重新啟動。
   project-number@cloudservices.gserviceaccount.com	服務代理啟動了關機程序。 如要判斷服務是從哪個專案啟動關閉作業，請查看服務代理人的 project-number。 如要判斷哪項 Google 服務提出要求，請查看 protoPayload.requestMetadata.callerSuppliedUserAgent 欄位。

   如果使用者觸發關機或重新啟動，系統會在 principalEmail 欄位中顯示使用者的電子郵件地址。例如：cloudysanfrancisco@gmail.com。

   管理員可以變更使用者帳戶的 Identity and Access Management 權限，防止使用者變更專案 VM 的狀態。詳情請參閱「授予、變更及撤銷資源的存取權」。

監控 VM 生命週期事件

您可以建立 Cloud Monitoring 資訊主頁，監控 VM 生命週期事件 (包括關閉、重新啟動和主機錯誤)。

這個資訊主頁可讓您以視覺化方式查看系統事件和管理員活動，詳情請參閱本文「查看稽核記錄」一節。

圖 1. 範例資訊主頁，顯示執行個體的可用性及其生命週期事件，例如已停止的執行個體。

建立記錄指標

如要擷取 VM 生命週期事件，請建立使用者定義的記錄指標。這項指標會使用稽核記錄，記錄特定 VM 生命週期事件發生的次數。

如要取得建立指標所需的權限，請要求管理員為您授予專案的 Logs Writer (roles/logging.logWriter) IAM 角色。如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和機構的存取權」。

您或許還可透過自訂角色或其他預先定義的角色取得必要權限。

如要建立使用者定義的記錄指標，請按照下列步驟操作：

1. 在 Google Cloud 控制台中，前往「記錄指標」頁面。

   前往「Logs-based Metrics」(記錄指標)

2. 按一下 [建立指標]。

在「指標類型」部分執行下列操作：

• 選取「Counter」。
• 將「Distribution」保留在未選取的預設設定。

在「詳細資料」部分中，輸入以下資訊：

• 記錄指標名稱：vm-lifecycle-events。您必須使用這個確切名稱，資訊主頁才能正常運作。
• 說明：選填 - 輸入這項指標的說明。
• 單位：1

1. 在「Filter selection」部分中，指定下列項目：

   • 在「選取專案或記錄檔 bucket」選單中，選取「專案記錄」。
   • 在「Build filter」中輸入：

     resource.type = "gce_instance" AND
     log_id("cloudaudit.googleapis.com/activity") OR
     log_id("cloudaudit.googleapis.com/system_event")
     operation.first="true"

2. 在「標籤」部分中，按一下「新增標籤」。

3. 指定下列屬性：

   • 標籤名稱：method
   • 標籤類型：STRING
   • 欄位名稱：protoPayload.methodName
   • 規則運算式：

     (recreateInstance|hostError|automaticRestart|guestTerminate|terminateOnHostMaintenance|preempted|insert|stop|delete|reset|start)

4. 然後按一下 [完成]。

5. 點選「建立指標」。

使用資訊主頁

在執行個體發生系統事件或管理員活動之前，資訊主頁上不會顯示任何資料。如要測試資訊主頁是否正常運作，請執行系統管理員活動，例如 stop 和 start 作業：

1. 在任何現有執行個體上執行 stop 和 start 作業，或建立新的 VM 以供測試。

如要取得使用資訊主頁所需的權限，請要求管理員為您授予專案的 Monitoring Dashboard Viewer (roles/monitoring.dashboardViewer) IAM 角色。如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和機構的存取權」。

您或許還可透過自訂角色或其他預先定義的角色取得必要權限。

1. 在 Google Cloud 控制台中開啟「Dashboards」。

   前往資訊主頁

2. 在「Dashboard List」分頁中開啟 GCE VM Lifecycle Events Monitoring 資訊主頁。

3. 從「Name」下拉式選單中選取 VM。

4. 將時間序列縮小至相關時間範圍。

   如要瞭解更多篩選資訊主頁的方式，請參閱「新增臨時篩選器」。

資訊主頁包含兩個圖表，分別顯示系統事件和執行個體上發生的管理員活動時間軸：

1. 「VM 生命週期時間表」圖表會顯示下列資訊：

   • compute.googleapis.com/instance/uptime 指標：指出 VM 是否在特定時間點執行，1 代表執行中，0 代表未執行。請注意，這項指標反映的是使用者活動和系統事件所導致的可用性，並非 Compute Engine SLA 的指標。
   • vm-lifecycle-events 記錄式指標，用於計算生命週期動作的數量，例如在特定時間點針對執行個體執行的 stop 或 start

2. 「事件」圖表會顯示相同的 vm-lifecycle-events 以記錄為基礎的指標，但會以放大檢視畫面顯示，方便閱讀。請注意，雖然 X 軸已對齊，但兩個圖表之間的顏色並未同步。

調查跨專案的大量 VM 關閉情況

如果 Shared VPC 主專案的計費功能未啟用或遭停用，Compute Engine 可能會關閉連至 Shared VPC 主專案的多個 VM。

如要判斷 VM 是否因大量關閉要求而關機，請確認是否具有透過 cloud-cluster-manager@prod.google.com 展開的停止作業。

啟動受影響的執行個體會傳回類似以下的錯誤：

Starting instance(s) INSTANCE_NAME...failed.
ERROR: (gcloud.compute.instances.start) The default network interface [nic0] is frozen.

如要解決這個問題，請按照下列步驟操作：

1. 使用 gcloud compute instances describe 指令，找出 VM 使用的共用虛擬私有雲：

   gcloud compute instances describe VM_NAME \
      --format="flattened(networkInterfaces[].network)"
   

   輸出結果會與下列內容相似：

   networkInterfaces[0].network: https://www.googleapis.com/compute/v1/projects/SHARED_VPC_PROJECT/global/networks/FROZEN_NETWORK
   

2. 在共用虛擬私有雲的主專案中確認是否已停用計費功能。

   resource.type="project"
   protoPayload.request.@type="type.googleapis.com/google.internal.cloudbilling.billingaccount.v1.DisableResourceBillingRequest"
   protoPayload.response.resourceBillingInfo.billingAccountAssignmentType="DISABLED"
   

3. 如適用，請啟用主機專案的計費功能。

為避免問題一再發生，請參閱這篇文章，瞭解如何確保專案與帳單帳戶之間的連結安全無虞。