本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
自動執行個體復原功能
重要
本節描述如何在 EC2 執行個體上主動設定復原機制。當 AWS 偵測到導致系統狀態檢查失敗的基礎硬體或軟體問題時,這些復原機制可用於還原執行個體可用性。如果您目前在存取執行個體時遇到問題,請參閱對 EC2 執行個體進行疑難排解。
如果 AWS 偵測到執行個體因基礎硬體或軟體問題而無法使用,有兩種機制可以自動還原執行個體可用性:簡化的自動復原和 Amazon CloudWatch 動作型復原。還原執行個體可用性亦稱為執行個體復原。
在執行個體復原程序期間, AWS 會嘗試將執行個體從具有基礎硬體或軟體問題的主機移至不同的主機。如果成功,執行個體復原程序為非計劃的重新啟動。您可驗證執行個體復原是否已發生。
若復原程序未成功,執行個體可能會在存在基礎硬體或軟體問題的主機上繼續執行。在此情形下,需手動介入處理。如果執行個體無法連線,或系統狀態檢查持續未通過,我們建議您以手動方式,來停止並啟動執行個體。當您啟動執行個體時,其通常會移轉至新的基礎主機電腦。不過,與自動執行個體復原 (執行個體會保留其公有 IPv4 位址) 不同,重新啟動的執行個體會獲得新的公有 IPv4 位址,除非其設定了彈性 IP 位址。
若要享受自動復原機制的益處,必須在系統狀態檢查失敗前,預先在執行個體上設定這些機制。您啟動執行個體期間,預設會啟用簡化的自動復原。您可在啟動後選擇性地設定基於 Amazon CloudWatch 動作的復原。設定其中一個機制可提升您執行個體的彈性。
簡化自動復原和基於 Amazon CloudWatch 動作的復原僅適用於支援的執行個體。如需詳細資訊,請參閱啟用簡化自動復原的需求及基於 CloudWatch 動作的復原的需求。
警告
當 因基礎硬體或軟體問題 AWS 而復原執行個體時,請注意下列後果:儲存在揮發性記憶體 (RAM) 中的資料將會遺失,而且作業系統的執行時間會從零開始。此外,透過基於 CloudWatch 動作的復原,執行個體儲存體磁碟區上的資料也會遺失。為協助防範資料遺失,建議您定期建立重要資料的備份。如需有關 EC2 執行個體備份與復原最佳實務的詳細資訊,請參閱 Amazon EC2 的最佳實務。
自動執行個體復原機制是為個別執行個體設計的。如需有關建置彈性系統的指引,請參閱 建置彈性系統。
主題
自動執行個體復原的核心概念
自動執行個體復原是 Amazon EC2 的一項功能,可在發生基礎硬體或軟體故障時自動還原執行個體可用性,提升 EC2 執行個體的彈性和可靠性。
以下是自動執行個體復原的核心概念:
- 組態選項
-
可設定兩種機制來支援自動執行個體復原:
-
簡化的自動復原:支援的執行個體預設會啟用。
-
基於 CloudWatch 動作的復原:在支援的執行個體上需手動設定。
-
- 系統狀態檢查
-
系統狀態檢查會自動監控 EC2 執行個體執行所在的 AWS 基礎設施。
-
如果系統狀態檢查失敗, 會 AWS 啟動自動執行個體復原,嘗試將受影響的執行個體遷移到不同的硬體。
-
系統狀態檢查失敗表示主機的硬體或軟體存在問題,而非執行個體本身的問題。自動執行個體復原可復原系統狀態檢查失敗的執行個體。但若只有執行個體狀態檢查失敗,則自動執行個體復原不會運作。
-
有關執行個體和系統狀態檢查之間的差異,請參閱狀態檢查的類型。
-
- 基礎硬體或軟體問題的範例
-
可能會導致系統狀態檢查失敗的硬體或軟體問題包括:網路連線中斷、系統供電中斷、實體主機上的軟體問題,以及影響網路可達性的實體主機硬體問題。
- 復原後執行個體的特性
-
復原後執行個體與原始執行個體相同,但不包含遺失的元素。
保留的元素:
-
執行個體 ID
-
公有、私有和彈性 IP 位址
-
執行個體中繼資料
-
置放群組
-
已連接 EBS 磁碟區
-
可用區域
遺失的元素:
-
儲存於揮發性記憶體 (RAM) 中的資料
-
儲存於執行個體儲存體磁碟區的資料 (僅適用於基於 CloudWatch 動作的復原)
-
作業系統運行時間重設為零
-
- 使用 CloudWatch 監控系統狀態檢查
-
CloudWatch 中的 StatusCheckFailed_System 指標會指出,系統狀態檢查是否通過。
指標值:
-
0 – 系統狀態檢查通過。
-
1 – 系統狀態檢查失敗。
-
- 中的事件 AWS Health Dashboard
-
在自動執行個體復原嘗試期間, AWS Health Dashboard 會根據設定的復原機制及其結果,將事件 AWS 傳送至您的 :
-
簡化的自動復原
-
成功事件:
AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS -
失敗事件:
AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE
-
-
基於 CloudWatch 動作的復原
-
成功事件:
AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS -
失敗事件:
AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE
-
-
簡化自動復原與基於 CloudWatch 動作的復原之間的差異
下表比較簡化自動復原與基於 CloudWatch 動作的復原之間的核心差異。
| 比較項目 | 簡化的自動復原 | 基於 CloudWatch 動作的復原 |
|---|---|---|
| Configuration | 預設在支援的執行個體上啟用 | 需要手動設定 CloudWatch 警示與動作 |
| 彈性 | 修正 管理的復原行為 AWS | 可自訂的動作與條件 |
| 通知 | 透過 的基本通知 AWS Health Dashboard | 透過 SNS 可自訂通知 |
| 裸機執行個體大小 | 已排除 | 包含 |
| 執行個體儲存體磁碟區只會在啟動時連接 | 不支援在啟動時連接執行個體儲存體磁碟區的執行個體 | 在所選取執行個體類型上受支援。請注意,執行個體復原期間,執行個體儲存體磁碟區上的資料會遺失。 |
| 復原時間 | 標準復原嘗試 | 復原嘗試比簡化自動復原更快 |
| 主機問題會在移轉期間解決 | 移轉可能會取消,執行個體會保留在原始主機上 | 繼續移轉至新的主機 |
| 成本 | 無額外費用 | 可能產生 CloudWatch 費用 |
建置彈性系統
雖然簡化的自動復原和 CloudWatch 動作型復原可有效維護個別執行個體的可用性,但 AWS 建議實作高可用性架構,以允許流量容錯移轉至運作狀態良好的執行個體。
若要達成此目的,請考慮使用 Elastic Load Balancing (將傳入流量分配到多個 EC2 執行個體) 和 Amazon EC2 Auto Scaling (根據需求和運作狀態自動調整執行個體數量) 等 AWS 服務。
有關使用 EC2 執行個體建置具備彈性、容錯系統的詳細資訊,請參閱下列資源: