Auto Recoverとは

CloudWatchアラームのアクションの一つとして設定するもので、物理ホストに障害があった場合に仮想マシンをマイグレーションしてくれるものです。

詳細は下記をご覧ください。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html

Auto Recover発動全体イメージ

file

発動流れ:

1.AutoRecoveryの発動条件(Alarm)を定義
2.ステータスチェック(システム)を行う
3.Alarm条件を達成
 3-1.AutoRecoveryを発動
 3-2.定義あるなら、AWS SNSを利用して通知する
4.AutoRecovery発動後、OS、ミドルウェア等の挙動を定義

実行主体

Amazon CloudWatchアラーム

実行契機

システムステータスチェックの失敗の原因となる問題には、次のようなものがあります。

  • ネットワーク接続の喪失
  • システム電源の喪失
  • 物理ホストのソフトウェアの問題
  • ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

発動時の挙動

元のインスタンスと同じEC2復旧する

発動後も保持されるデータ

EC2各種情報を引き継ぎます。

  • インスタンスID
  • プライベートIPアドレス
  • パブリックIPアドレス
  • Elastic IPアドレス
  • メタデータ

注意点

発動には条件があります。

  • インスタンスタイプが特定のものであること
  • (A1、C3、C4、C5、C5n、Inf1、M3、M4、M5、M5a、M5n、P3、R3、R4、R5、R5a、R5n、T2、T3、T3a、X1、または X1eのいずれかを使用する)
  • EBS ボリュームのみ持っている (インスタンスストアボリュームは設定しない)
  • defaultまたはdedicatedインスタンステナンシーを使用する
  • マイグレーション先の物理ホストに空きが無い場合など、復旧処理に失敗することもあります。

発動後の後続作業

  • 発動後はEC2各種情報を引き継ぎますので、パラメータシートより各種設定データが復元できるか確認作業を行う必要になります、
  • 発動時のメモリデータや接続セッションなど、永続化していないデータがなくなるので、要確認。
  • 連携がある他のサービス確認が必要、Lambda、ELB、EFSなど
Last modified: 2020-12-10

Comments

Write a Reply or Comment

Your email address will not be published.