VMWare や他の仮想化システムに慣れ親しんだ人からすれば、ディスクイメージさえ取れればなんとか復旧できる、というのは自明かもしれませんが、EC2 上で実際にどういう手順で復旧が行われうるのか、というのをAlestic がFixing Files on the Root EBS Volume of an EC2 Instance - Alestic.com にて書いていたので、簡単にまとめてみました。
先に簡単に流れを説明すると、
- 問題のインスタンスID を確認
- 問題のボリュームIDを確認
- 復旧作業用の別インスタンスを起動
- 問題のインスタンスを停止
- 問題のEBS ボリュームをデタッチ
- 問題のEBS ボリュームを別インスタンスにアタッチ
- 復旧作業を行う
- 元のインスタンスにアタッチして起動を試す
どういうときに使えるか。
- ssh key を無くした、ログインパスワードを忘れた、等
- /etc/sudoers を編集ミスしてroot になれなくなった
- 長時間走らせて来たインスタンスがハングして繋がらなくなった。ブートもうまく行かない。
- ファイルシステムが壊れ、復旧もうまく行かない。別マシンでfsck 等したい。
- ルートボリューム（起動ディスク）がEBS でないと適用できない。
EC2 特有ですが、S3-Backed（S3 に置いてあるAMI をベースにしたインスタンス起動。インスタンスストアとも呼ばれる。）とEBS-Backed（文字通りEBS からの起動）の特性から、EBS-Backed でないと他のインスタンスにそのディスクイメージをアタッチしたりできないのでS3-Backed で起動しているインスタンスの場合はここで諦める事になります。 - バックアップがあってそちらを復旧してしまったほうが早ければそのほうが良いかもしれません。（これは物理サーバーでも言える事ですが。）このへんの見極めは慎重に。
※ 元記事から若干、手順を書き換えています。Alestic.com の記事と合わせて比較してお読みください。
- 問題のインスタンスID を確認
壊れたEBS ボリュームを起動ボリュームにしているインスタンスのインスタンスID を確認します。ここでは、仮にこれをi-BROKEN とします。 - 問題のボリュームIDを確認
問題のインスタンスにくっついている起動ボリュームを確認します。マネジメントコンソールからも確認できると思いますが、コマンドラインで以下のようにしても出来るようです。コマンドの意味が分からない人はパイプに渡さないで一つ一つ確認しましょう。
$ ec2-describe-instances i-BROKEN | egrep '^BLOCKDEVICE./dev/sda1' | cut -f3
※ 上記コマンドでは/dev/sda1 を指定していますがこれはひょっとしたらOS、起動方法などによって異なるのではないかとも思います。
ここではこのボリュームを仮にvol-DAMAGED とします。 - 復旧作業用の別インスタンスを起動
適当なLinux インスタンスなど自分が使いやすいものを起動します。このインスタンスのIDを仮にi-RECOVERY とします。このインスタンスに問題のEBS をアタッチするため、同じアベイラビリティゾーン内に作る必要があります。
もちろん既に動いているインスタンス等でも構わないです。 - 問題のインスタンスを停止
$ ec2-stop-instances i-BROKEN
にて、i-BROKEN を停止します。間違ってもterminate はしないようにしましょう。terminate はデフォルトではEBS-Backed のインスタンスであれ、起動に使ったルートボリュームを削除してしまいます。焦っていても落ち着いて、stop をするように注意しましょう。
terminate とstop の違いがわかっていない方は先にそこをクリアにして置いた方が良いかもしれません。
また、ディスクが問題を抱えているため停止までに時間がかかるかもしれません。ステータスがstopping などのままあまり長時間経過してしまうような場合には、フォーラムにインスタンスID を含め書き込んでサポートしてもらう手順もあるようです。プレミアムサポートサービスもあるのでそちら経由でサポートしてもらうことも出来ると思います。
なお、running 以外のステータスでは課金されない（日本語訳が微妙ですが、英語ページでは、Instance-hours are billed for any time your instances are in a “running” state. となっているので間違いありません。）ので気持ちに余裕があれば1日2日（？！）じっと待ってみるのも良いかもしれません。
--force オプションというのもあり、これも試す価値はありそうです。
$ ec2-stop-instances i-BROKEN --force
※ --force オプションはWindows では推奨されないようです。というかそもそもLinux 等でも推奨されないとは思いますが。その他の注意点を含め、詳しくはec2-stop-instancesのマニュアルをご参照ください。 - 問題のEBS ボリュームをデタッチ
$ ec2-detach-volume vol-DAMAGED
問題となっているEBS ボリュームをアタッチされているインスタンスから引き離します。
こちらも--force オプションが使えるようです。注意点などについては ec2-detach-volume のマニュアルを参照。
また、「Firefoxのadd-onであるElasticfoxをご利用いただくと、マウス操作でforce detachを行えるようです。」とのこと。 - 問題のEBS ボリュームを別インスタンスにアタッチ
$ ec2-attach-volume --instance i-RECOVERY --device /dev/sdj vol-DAMAGED
ここでは/dev/sdj に割り当ててますがこの辺は任意で良いのだと思います。ただしWindows の場合はデバイス名体系が異なるかもしれません。またEC2で予約デバイスとなっているデバイス名は避けるべきだと思われます。Attaching the Volume to an Instance に予約デバイス名等が出ているので参照した方が良さそうです。
個人的にはここでアタッチをする前に、ボリュームのスナップショットを取っておいた方が良いのではないかと思います。 - 復旧作業を行う
復旧用のインスタンスi-RECOVERYにssh して煮るなり焼くなりfsck するなりマウントしてファイルを書き換えるなりするというところです。
復旧作業時の注意点として、i-BROKEN とi-RECOVERY のuid はマッチしない可能性があるのでroot 以外のユーザーでファイルを作成／コピー／編集したりする場合、それらのファイルのオーナーなどが変わってしまう可能性がある事に注意してください。（root でコピーする際などにもオーナーや実行権限が変わらないよう注意する必要があるかと思います。） - 元のインスタンスにアタッチして起動を試す
復旧作業が完了したと思ったら、
$ ec2-detach-volume vol-DAMAGED
でi-RECOVERY からデタッチし、その後、
$ ec2-attach-volume --instance i-BROKEN --device /dev/sda1 vol-DAMAGED
で、元のi-BROKEN インスタンスの/dev/sda1 としてアタッチし、
$ ec2-start-instances i-BROKEN
にて、元のインスタンス i-BROKEN を起動して復旧が成功したか確認します。
この際、最初に問題があったインスタンス（ここでは i-BROKEN）にElastic IP を割り当てている場合、stop したら再度立ち上げる際にもう一度立ち上げたインスタンスにそのEIP を割り当てる必要がある、ということにご注意ください。また、復旧作業用のインスタンスがテンポラリ作業用だった場合は作業終了後、terminate するのを忘れずに。
手順は概ね●nix でのものを意識して書かれていますが、Windows も・・、まあ大体同じ流れで出来るんじゃないかとは思います。
ということで、Good Luck! 焦らずじっくり復旧しましょう。
0 件のコメント:
コメントを投稿