2011-02-13

EC2のリージョンを変更しようと思いましたが、色々と知らないことだらけで試行錯誤しました。その試行錯誤した内容を記録しておきます。

まず結論

結局、泥臭くやることで、リージョンを変更することはできました。
色々と試しましたが、自分がEBS-Backed AMIについて理解していなかったために、色々と遠回りをしました。
最終的にな手順は別の記事にまとめます。以下は試行錯誤したことの記録です。

クラウドワークスを使うという選択肢

株式会社サーバーワークスさんより、クラウドワークスというEC2の管理コンソールが提供されています。こちらは無料で使用することができ、クラウドワークスの一機能にAMIのコピーという機能があります。この機能を使用してリージョン間でAMIをコピーすることができるはずです。
はず、というのは、実際使用してみたのですが、残念なことに何度か実行しても一度も成功しませんでした。コピー元とコピー先でEC2インスタンスを起動して作業をおこなっているようなのですが、いつも最後にコピーに失敗しましたというメールが私のアドレスに送信されてきてうまくいきませんでした。

ec2-migrate-bundleコマンドを使ってみる

リージョンの変更に関して、ぐぐってみるといくつかの情報が見つかります。
"AWSをeastからwestに移して稼働させる - yoshikiexの日記"
"Ring"
このコマンドは、AMIをあるリージョンから他のリージョンへコピーするために使用するコマンドであるため、自分の目的に合致していました。そこで、このコマンドを使用してリージョンを移動させることにしたのですが、コマンドをうまく実行することが出来ませんでした。理由としては、単純にmanifestファイルをうまく指定出来ていないというものです。

管理コンソール画面からAMIを作成した場合にmanifestが見つからないという落とし穴

私は、AMIの作成は管理コンソール画面のCreate Image(EBS AMI)からしかしたことがありませんでした。そのため、manifestファイルというものの存在をまったく知りませんでした。ec2-migrate-bundleコマンドでは、--manifestが必須の項目であるため、どうにかしてmanifestファイルを指定するべく調べていたのですが答えにたどり着くことが出来ませんでした。そこで、コマンドからAMIを作成するという方向に舵をきりました。

manifestについては、"Amazon EC2の機能を詳しく見てみる(3)--インスタンスデータとAMI - builder by ZDNet Japan"を見て勉強させて頂きました。manifestファイルは、AMIの各種情報が格納されているファイルのようです。

コマンドからAMIの作成、そしてリージョン間でコピー、しかし、、、

コマンドからAMIを作成してコピーすべく、"http://popowa.com/wiki/index.php?AWS#qd2e7a22"を参考にAMIを作成してS3にアップするところまでやってみたところ、大きな障害もなくS3のアップまでいけました。そして、コマンドから作成したAMIにはしっかりとmanifestファイルもありました。
ec2-migrate-bundleコマンドに関しては、S3上にあるmanifestファイルを指定することで実行することができました。コピーしたリージョン側でAMIを使用してEC2インスタンスを起動したところ、問題なく起動することができました。これでリージョン間の移動が終わったと思ったのですが、大きな問題が発覚しました。それは、AMIの作成がミスっており、root deviceがebsからinstance-storeになってしまっていたのです。

気になったこと：管理コンソール画面からAMIを作成したときのSourceの値

コマンドからAMIを作成するようになり、どの項目にどんな情報が入るのか少しわかるようになってきました。そんな時、コマンドから作成したAMIではSourceの値にmanifestファイルのパスが記述されていることに気づきました。そのため、管理コンソール画面から作成したAMIもSourceの値がmanifestファイルのパスなのではないかと想像しました。そこで、Sourceの値とec2-download-bundleコマンドを使用してAMIの取得を試みました。しかし、やはりこのコマンドも失敗に終わりました。メッセージ的には、manifestファイルが見つかりません、の一点張りでした。

AMIの作成を見直す

今までのところ、折角リージョン間でAMIをコピーできたのにもかかわらず、適当にAMIを作成していたため想定していたEC2インスタンスを起動することができませんでした。そこで、AMIの作成を見直します。

実作業に入る前に予習します。

"EBSタイプのインスタンスを他リージョンへ移行する手順 – サーバーワークスエンジニアブログ"にリージョン間でのコピーを解説して下さっています。こちらを読んで、リージョン間のコピーの細かい手順を学びます。
うーん、すごいですね。イメージをS3経由でコピーしてAMIとして認識させ、root deviceがinstance-storeのものところをEBSにしてますね。instance-storeからEBSにする手順に納得。EBSを作成してアタッチして、root deviceとして使用できるようにイメージ作成してそのデータをEBSにコピーしてます。こんな風にしてEBSをroot deviceとして使えるようにするんですね。
さらには、AMIのストレージに作成したEBSを使用するために、スナップショットを作成してそれをAMI作成に使っています。--snapshotオプションにスナップショットを指定するとroot deviceとして認識するんでしょうか？ドキュメントのec2-register部分をみると、"The ID of the Amazon EBS snapshot to be used as the root device."とばっちり書いてありますね。最後に作成したAMIでEC2インスタンスを起動するとEBSになっているって流れなんですね。うーん、すごい。
（カーネルIDとRAMディスクについてはちょっと知識不足で理解できてません）

実験1：EBSをマウントした状態でAMIを作成するとどうなるのか？

root deviceがinstance-storeになってしまうことは確認できましたが、EBSをアタッチ＆マウントした状態でイメージを作成した場合、どうなるのでしょうか？ちょっと実験してみます。ec2-bundle-volコマンドのオプションは何も付けずにいきます。

ec2-bundle-vol -d /mnt -k <private key file path> -c <certificate file path> --user <user number> -r x86_64
ec2-upload-bundle --bucket <bucket name> --manifest /mnt/image.manifest.xml -a <access key> -s <secret key>
ec2-register <bucket name>/image.manifest.xml -n <ami name> -K <private key file path> -C <certificate file path>

結果：やっぱりマウントしたEBSは消えていました。

当然といえば当然ですね。何も指定していないのですから。

実験2：ec2-bundle-volコマンドで--fstabオプションを指定してみる

fstabオプションを指定することで、マウントしているEBSに対して何か影響があるかどうか試してみます。

ec2-bundle-vol -d /mnt -k <private key file path> -c <certificate file path> --user <user number> -r x86_64 --fstab /etc/fstab
ec2-upload-bundle --bucket <bucket name> --manifest /mnt/image.manifest.xml -a <access key> -s <secret key>
ec2-register <bucket name>/image.manifest.xml -n <ami name> -K <private key file path> -C <certificate file path>

結果：ec2-registerコマンドのオプション指定が足らず、エラーになりました。

ec2-registerコマンド実行時に下記のようなエラーがでました。ちょっとぐぐってみたところ、"http://blog.netsket.com/koshiba/2010/06/clientinvalidmanifest_invalid.php#more"で参考となる情報を頂きました。block-device-mappingオプションが正しく指定されていないことが原因のようです。

Client.InvalidManifest: Invalid block device mapping: Invalid virtual name 'ebs1'

ということは、正しくデバイスの割り当てが指定されていないとAMIとして登録することは無理ということですかね。確かに、管理コンソール画面にてroot deviceがEBSのAMIを作成した場合、Block Devicesの値にスナップショットが指定されています。AMIにEBSを紐付けておきたい場合、しっかりとEBSをスナップショットにして確保してからやる必要があるということなのでしょうか。

あー、EC2について勉強不足ですね。。。

戦略を変えてチャレンジします。

結局やりたい事は、リージョン間でのコピーなわけです。で、私の場合ディスクは全てEBSにしているため、このディスクさえリージョン間で移動できてしまえば良いのではないか？と考えます。
自分が使っているEC2インスタンスには、root device用のebsとアプリケーション用にアタッチして使用してるebsがあります。そのため、アプリケーション用ebsのデータはs3やネットワーク経由でコピーし、root deviceのebsはinstance-storeになってしまったものを再度ebsに変更するようにします。

私はEC2の操作を基本的に管理コンソール画面からおこなっていました。そのため、AMIの作成について深く理解していませんでした。リージョンを変更する際に色々とはまったためAMIについて自分が調べた事を記録しておきます。

理解に誤りなどありましたらすいません。コメントでご指摘頂けると助かります。

管理コンソール画面から無意識に作成していたEBS-Backed AMI

私はAMIの作成は管理コンソール画面よりCreate Image(EBS AMI)よりおこなっており、それがEBS-Backed AMIを作成しているということを意識していませんでした。作成したAMIはS3のどこかにあるのだろうというぐらいの感覚でした。

AMIにはS3-Based AMIとEBS-Backed AMIがある

root deviceがebsかinstance-storeであるかという点は理解して使い分けていたのですが、AMIのイメージをどこに配置するか（どこにあるイメージを使用するか）という点は意識できていませんでした。
EC2のUser GuideやDeveloper Guideをみると、確かにS3-Based AMIとEBS-Backed AMIに関する記述がありますね。

S3-Based AMI

イメージファイルをS3上に配置して利用するタイプのAMIのようです。
AMI作成の手順的には、ec2-bundle-volコマンドでイメージファイルを作成し、ec2-upload-bundleコマンドでS3にアップして、その後AMI登録といった感じでした。
ファイルは、細かく分割されたイメージファイルとmanifestファイルとなります。ec2-bundle-volコマンドを実行することでイメージファイルとmanifestファイルが確認できます。

EBS-Backed AMI

ストレージ用のデバイスにEBS（スナップショット）を使用するタイプのAMIのようです。そのため、EBSにはイメージのデータがそのまま格納されます。
AMI作成の手順的には、ec2-bundle-volコマンドでイメージを作成して、ec2-unbundleコマンドで一つにまとめて、アタッチしておいたEBSにddコマンドでコピーし、EBSのスナップショットを作成してそれを指定してAMIとして登録といった感じでした。他にもやりかたはあるっぽいですね。それらしい記述を見た気がします。

コマンドを実行して試してみると理解できるものですね

結局私は、リージョンを変更する際にAMIの作成やS3へのアップなどを繰返しおこなうことで、色々と学ぶことができました。やはり、コマンドを実行して試すことが重要なのだと実感しました。管理コンソール画面にばかり頼っていると良くないってことですね。

"たゆたえども沈まず"で

EC2でリージョンを変更するため試行錯誤したこと