code up

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

EBSベースのインスタンスを別リージョンにバックアップ

(バックアップだけなら)今はもっと簡単にできますよ!AMIのコピーも簡単にできるようになったみたい。

Linuxカーネルは得意分野ではない担当者がリージョン間でEBSのインスタンスをバックアップした。次回行う時には忘れてそうなので方法を記録。

東京リージョン全体(ap-northeast-1)に障害があった場合に備えホットスタンバイのインスタンスを米国(オレゴン; us-west-2)に構築。この手順が確定するまで3日ほどかかったので結果的には一から作った方が早かった気もするけど実際の障害時にはきっと役立つでしょう。

以下はデータのバックアップを含む手順を記載しており、手順を誤るとデータの消失等が予想されます。本記事により損害が発生した場合でも責任は負えませんのでご了承の上ご覧下さい。

今回対象とするデータは、30GBのディスクにサーバーのセットアップと若干のトランザクションデータを入れて1.5GBくらいしかまだ使っていない状態のもの。

スナップショットが別リージョンに転送できれば一番楽なんだけど残念ながらそういうオプションは用意されていないみたい。CloudyScripts.comがCopy Snapshot To Different RegionというWebツールを提供しているが「一時的なID作ってやってね」と言われても、一時的でも他社に自社のデータを未契約の状態で触らせるのはまずかろう、ということでスルー。

その他どんな方法があるのか調べたところnetcat (nc)を使う方法がまず目についた。ただ、この方法はデバイスのサイズ(今回であれば30GB)をリージョン間転送するので、時間とお金がかかる。少しだけ試したところ最大で2MB/sほどの速度しか出ず5時間くらいかかりそうだったため途中で断念した。

次にここここを参考にしてrsyncを使ったEBSのコピーを試してみた。この場合転送は十数分で終わり転送後のEBSのサイズも自由に決められるので魅力的な方法ではあったけど、残念ながら試した限りはいずれも成功しなかった。ここ数日でコツは分かったので、ひょっとして今試したら成功するかも知れないけど後述する方法が簡単で転送量も少ないので追試をする機会はなさそう。

そして最後に試したのがEBSを含むAMIをS3にバックアップして別リージョンで復元する方法。ここここの記事を参考にさせて頂きました。以下は(おそらく私がLinuxの知識が足りないからだけど)書かれた通りに行ってもうまくいかなかったので注意点を含めその行間を埋めた方法。

  1. 移行元はap-northeast-1(Tokyo)、移行先はus-west-2(Oregon)
  2. 移行するインスタンスはEBSベースのm1.largeにエフェメラルディスク(ephemeral disk)を追加してあるAmazon Linux 64bitのインスタンス1台
  3. EBSの容量は30GB。構築したばかりなのでデータは1.5GBほどしか使っていない
  4. 移行元のインスタンスは停止せずに実施 = そのインスタンス上で作業
  5. 一部はManagement Console(Web画面)で実施
  6. 移行先の環境にはキーペアを登録済み
  7. 次のような変数を/root/.bashrcあたりに追加しておく。以後の作業はすべてrootで実施
    ap-northeast-1# vi /root/.bashrc
    export EC2_PRIVATE_KEY=/home/aws/pk-[32桁の英大文字].pem
    export EC2_CERT=/home/aws/cert-[32桁の英大文字].pem
    export EC2_URL=https://ec2.ap-northeast-1.amazonaws.com
    export AWS_ACCOUNT_NUMBER=[12桁のハイフンつきの数字]
    export AWS_ACCESS_KEY_ID=[20桁の英大文字+数字]
    export AWS_SECRET_ACCESS_KEY=[40桁のbase64値っぽい値]
  8. エフェメラルディスク上にAMIのイメージの圧縮版を作成
    ap-northeast-1# mkdir /media/ephemeral0/ami
    ap-northeast-1# ec2-bundle-vol -d /media/ephemeral0/ami -r x86_64 -c $EC2_CERT -k $EC2_PRIVATE_KEY --user $AWS_ACCOUNT_NUMBER
  9. イメージのマニフェストファイル(たぶんメタデータみたいなもの)を移行先のリージョンに最適化
    ap-northeast-1# ec2-migrate-manifest -a $AWS_ACCESS_KEY_ID -s $AWS_SECRET_ACCESS_KEY -c $EC2_CERT -k $EC2_PRIVATE_KEY --manifest /media/ephemeral0/ami/image.manifest.xml --region us-west-2
  10. Management ConsoleからS3を呼び出し、移行先のリージョン(オレゴン)にバケットを作成
  11. そのバケットに対して移行先に最適化されたイメージデータをアップロード
    ap-northeast-1# ec2-upload-bundle -a $AWS_ACCESS_KEY_ID -s $AWS_SECRET_ACCESS_KEY -b (バケット名) -d /media/ephemeral0/ami -m /media/ephemeral0/ami/image.manifest.xml
  12. S3からAMIを登録
    ap-northeast-1# ec2-register (バケット名)/image.manifest.xml -K $EC2_PRIVATE_KEY -C $EC2_CERT --region us-west-2
  13. IMAGE ami-[8桁の英小文字+数字]という応答が返ってくるのでami-の値を控えておく
  14. AMIからインスタンスを起動(たぶんManagement Consoleからでも可)
    ap-northeast-1# ec2-run-instances -K $EC2_PRIVATE_KEY -C $EC2_CERT ami-[8桁の英小文字+数字] --region us-west-2 -k (キーペア名)
  15. インスタンスのID(i-[8桁の英小文字+数字])とKernel ID(aki-[8桁の英小文字+数字])を控えておく
  16. ec2-run-instancesで指定したキーペアを使ってSSHでログイン
  17. この時点では*.pemファイルがまったくコピーされていないので、移行元サーバーから入手してなんとか移行先のサーバーに転送
    ap-northeast-1# find / -name '*.pem' | xargs tar -zcvf /tmp/pem.tar.gz
    (SCP等で転送)
    us-west-2# cd /
    us-west-2# tar xvfz /tmp/pem.tar.gz
  18. その他コピーしていないファイルは/opt/aws/amitools/ec2/lib/ec2/platform/base/constants.rbで確認できる
  19. また、このインスタンスはEBSベースではなくインスタンスストレージ(Instance Storage)ベースなのでもう一手間加えてEBSベースに。まずはそのインスタンスストレージのAMIイメージを移行元と同じように作成
    us-west-2# mkdir /media/ephemeral0/ami
    us-west-2# ec2-bundle-vol -d /media/ephemeral0/ami -r x86_64 -c $EC2_CERT -k $EC2_PRIVATE_KEY --user $AWS_ACCOUNT_NUMBER
  20. 次に、出来上がった圧縮版(ついでに分割されている)イメージ達をひとつのイメージファイル(ファイル名: image)に結合+解凍
    ec2-unbundle -k $EC2_PRIVATE_KEY -m /media/ephemeral0/ami/image.manifest.xml -s /media/ephemeral0/ami/ -d /media/ephemeral0/ami/
  21. ボリュームを作成する(おそらくManagement Consoleでも可)。後でddで書き出すためイメージファイル(/media/ephemeral0/ami/image)と同じサイズとする。この記事によるとAMIの種類によってイメージファイルのサイズは自動的に決定するようである。今回は最低値の10GBになっていた。ボリュームID(vol-[8桁の英小文字+数字])を控えておく
    ec2-create-volume --size 10 --availability-zone us-west-2c --region us-west-2
  22. 作成したボリュームをアタッチ(おそらくManagement Consoleでも可)。vol-の部分には先ほど作成したボリュームを指定。i-の部分にはec2-run-instancesで得られたインスタンスのIDを指定
    ec2-attach-volume vol-[8桁の英小文字+数字] --instance i-[8桁の英小文字+数字] -d /dev/sdf1 --region us-west-2
  23. イメージファイルを作成したボリュームに焼く(書き込む)
    dd if=/media/ephemeral0/ami/image of=/dev/sdf1
  24. 後はManagement Consoleで実施した
  25. 書き込みを行ったボリュームからスナップショットを作成(Create Snapshot)
  26. 作成したスナップショットからAMIを作成(Create Image)。Architectureは元のサーバーのものに合わせる。この際必ず上記で控えたKernel ID(aki-で始まるID)を指定すること。最初指定し忘れてデフォルトで作成した時次のエラーに遭遇した
    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
  27. 作成したAMIでインスタンスを作成(Launch)し、無事Status Checksまで完了すれば無事終了

イメージの出し入れに関するコマンドはそれなりに時間がかかったけど、上記ストレートで実施してデータが少なかったということもあり2時間はかからなかった。

ec2-bundle-volでは圧縮したイメージが作成されるが今回は400MB程度であった。また副次的ではあるが、30GBのディスクを米国のインスタンスでは縮小したいと考えていた要件も叶えてくれた。

関連記事
タグ:AWS Amazon EBS EC2
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。