2011年1月31日月曜日

EC2の障害復旧パターン

スズキです。

EC2で運用しているサーバがおかしくなったときの、
復旧パターンを下記にまとめてみました。
(cloudpackでも下記に近い形で復旧を試みています)

前提は、

- AMIはEBSベースのものを使用
- EBSはルートディスク用とデータディスク用の二つを利用
- OSはLinux(CentOS 5.x)
- プレミアムサポートには入っていない
- 本番運用前に初期AMIを作成

といった感じです。

(1) SSHでログイン
--------
OK: ★OS内で復旧作業(ログ調査、ミドルウェアのリスタートなど)して、終了。
NG: どうしようもないので、(2)へ。

(2) 他のAWS環境でもSSHでログイン
--------
NG: AWS全体に関わる障害の可能性が高いのでAWSに問い合わせ。
OK: インスタンス固有の問題として、(3)へ。

(3) インスタンスのリブート(& SSHでログイン)
※ついでにAMIも作成
--------
OK: ログインできれば、★へ。
NG: リブートでダメならストップ/スタートということで、(4)へ。

(4) インスタンスのストップ&スタート(& SSHでログイン)
--------
OK: ログインできれば、★へ。
NG: ストップ/スタートでダメならAMIから立ち上げ直しということで、(5)へ。

(5) ※で作成したAMIを同一ゾーンで立ち上げる(& SSHでログイン)
--------
OK: ログインできれば、★へ。
NG: ゾーンの問題を考慮して、(6)へ。

(6) ※で作成したAMIを別ゾーンで立ち上げる(& SSHでログイン)
--------
OK: ログインできれば、★へ。
NG: もうバックアップからの復旧しかないので、(7)へ。

(7) ルートディスクのスナップショット(バックアップ)からAMIを作成して起動(& SSHでログイン)
OK: ログインできれば、他のバックアップからルートディスクのデータを復旧して、(A)へ。
NG: スナップショットがダメなら最後の手段で、(8)へ。

(A) 障害発生インスタンスのデータディスク(EBS)をアタッチして動作確認
--------
OK: 問題なければ、★へ。。
NG: もうバックアップからの復旧しかないので、(B)へ。

(B) データディスクのスナップショット(バックアップ)からEBSを作成&アタッチして動作確認
--------
OK: 問題なければ、他のバックアップからデータを復旧して、★へ。。
NG: スナップショットがダメなら最後の手段で、(C)へ

(C) 初期AMIを起動しデータディスク(EBS)を切り離し、それをアタッチして動作確認
--------
OK: 問題なければ、他のバックアップからデータを復旧して、★へ。。
NG: 死亡。

(8) 初期AMIを起動(& SSHでログイン)
--------
OK: ログインできれば、他のバックアップからルートディスクのデータを復旧して、(A)へ。
NG: 死亡。

cloudpackの中の人が、わかりやすい図にしてくれるはず…
--------
http://www.suz-lab.com

0 コメント: