【AWS】Tokyo Regionからコンニチハ!~OpenVZがTokyoにやってきた~

このエントリーをはてなブックマークに追加
SingaporeからTokyoへ引っ越しました記念ブログ。

どうも、fujya.shです。3月3日夜に突然のTokyoRegionの発表でTLが一気にTokyoRegionNightになってしまいましたね。私も興奮し勢い余ってSingaporeで稼動していたEC2のサーバをTokyoへの引越し作業に没頭してました。とりあえずSingaporeのEC2で稼働中のOpenVZサーバをTokyoへの引越しができましたので、移行手順とやった事などを投稿したいと思います。

それにしても大変だった。。。




■ AMIの引越し作業 その1(EBSタイプからinstance-storeタイプの作成)

AWSではRegion間またがってのEBSタイプのAMIのコピーがサポートされていません。instance-storeタイプのAMIはS3に保存されているため、どこのRegionからも参照できます。SingaporeにあるEBSタイプのAMIをTokyoに引っ越すためには一度instance-storeタイプに変換させる必要があります。

※ instance-storeタイプのAMIの作成には以下のブログを参考にさせていただきました。 感謝!
http://gigazine.net/news/20080609_aws3/
http://blog.kirie.net/cloud/ec2/361.html

1: root@singapore# ec2-bundle-vol -d /tmp -k <Private Key File> -c <X.509 certificate file> -u <AWS account ID> --block-device-mapping "ami=/dev/sda1,root=/dev/sda1" --kernel aki-d409a2d5

2: root@singapore# ec2-upload-bundle -b <tokyo-S3-bucket> -m /tmp/image.manifest.xml -a <aws-access-key-id> -s <aws-secret-access-key>

3: root@tokyo# ec2-register --region ap-northeast-1 <tokyo-S3-bucket>/image.manifest.xml -K <Private Key File> -C <X.509 certificate file>
上から順番に説明します。

1:シャノンではOpenVZカーネルを利用しているので、yutuki_rさんのブログを参考にカスタマイズkernelの指定をする必要があります。ここではkernelIDをaki-d409a2d5に指定してimageを作成。(x86_64用)
attachしているEBSはイメージ化対象にならないので、device-mappingを明示的に指定する必要があります。

2:作成したイメージをS3上にupload。

3:TokyoRegionで立ち上げておいたインスタンス(何でも良い)からAMIの登録を実施。--region ap-northeast-1がポイントです。これでinstance-storeタイプのAMIがTokyo Regionにやってきました。


ためしにnstance-storeタイプのAMIから起動すると、ちゃんと起動/接続ができる事が確認できます。




<aws-access-key-id>

<aws-secret-access-key>

<AWS account ID>
は管理画面のセキュリティ証明書から確認できます。


<Private Key File>と<X.509 certificate file>はX.509証明書タブから発行し、それをサーバ上に設置してください。












■ AMIの引越し作業 その2(instance-storeタイプからEBSタイプの作成)

instance-storeタイプのAMIが起動ができることが確認できたら、次はEBSに戻す作業を実施します。

※ こちらの作業は下記ブログを参考にさせて頂きました。
http://blog.serverworks.co.jp/tech/2010/08/20/ebs-instance-convert-reg/

1: root@tokyo # ec2-bundle-vol -d /mnt -k <aws-access-key-id> -c <aws-secret-access-key> -u <AWS account ID>

2: root@tokyo # ec2-unbundle -k <aws-access-key-id> -m /mnt/image.manifest.xml -s /mnt/ -d /mnt/

3: root@tokyo # ec2-create-volume --region ap-northeast-1 -z ap-northeast-1a --size 10
VOLUME <EBS Vol ID> 10 ap-northeast-1a creating <create date>

4: root@tokyo # ec2-attach-volume --region ap-northeast-1 <EBS Vol ID> --device /dev/sdh --instance `curl -s http://169.254.169.254/latest/meta-data/instance-id`

5: root@tokyo # dd if=/mnt/image of=/dev/sdh

6: root@tokyo # ec2-create-snapshot --region ap-northeast-1 <EBS Vol ID> --description "snapshot AMI"
SNAPSHOT <Snapshot ID> <EBS Vol ID> pending <create date> 169857008331 10 AWS Tokyo

7: root@tokyo # ec2-register --region ap-northeast-1 --snapshot <Snapshot ID> -n "AWS Tokyo" --architecture x86_64 --root-device-name /dev/sda1 --kernel aki-d409a2d5


少し長いですが、上から順番に説明していきます。ここでは引越ししてきたTokyo Region上で稼動しているinstance-storeのサーバ上で作業しています。

1:イメージファイルの作成

2:1で作成したファイルを一つにまとめる

3:EBSの作成。--region ap-northeast-1 -z ap-northeast-1a がポイントになります

4:3で作成したEBSのIDをメモしておき、<EBS Vol ID>に入れる。3で作成したEBSにattachする。`curl -s http://169.254.169.254/latest/meta-data/instance-id`では自分のインスタンスIDを取得しています

5:2で作成したイメージファイルをattachしたEBSに書き込む

6:EBSからsnpashotの作成

7:snapshotからEBSタイプのAMIの作成。64bitのサーバを利用しているので--architecture x86_64を指定


これでTokyoRegionへの引越しが完了です。ただし、SingaporeでattachしていたEBSのボリュームは残念ながら引越しの対象外となりました。EBSボリュームは泥臭いやりかたですが、security groupにルールを追加してrsyncで同期を取る方法をとりました。




ちゃんとEBSタイプのOpenVZカーネルイメージがTokyoRegionで起動している事が確認できました!








■ 結論:Region超えは面倒くさい&不完全

まとめるとRegion超えての引越しは非常に面倒でした。作業時間を考えると1からインスタンス立てて、データはrsyncした方が早かったんだろうなぁと思いました。

以下ポイントです
・AWS上でRegion超えるAMIのコピー機能が無い
・S3はRegionをまたいで参照ができる(これを利用してinstance-storeを別Regionに登録する)
カスタマイズkernelを利用している場合は明示的にkernelIDの指定が必須
・--region ap-northeast-1はおまじない
・EBSデータのの移行はrsyncするしか無い?
・Region間では別々のSecurity Groupsが必要
・Region間では別々のKeyPairが必要(上記の移行をすれば、元のKeyが登録されているので別々にはならないが・・・)
・環境変数「export EC2_URL="https://ec2.ap-northeast-1.amazonaws.com"」をしておくと幸せ


引越し作業に関しては以上ですが、各所で話題になっている通りTokyoはネットワーク早いです。
TokyoRegionのサーバから社内へのpingは2.5~2.6msと安定して高速で返ってきます。手元の100MbpsのインターネットVPNで(YAMAHA RT107eで実装)拠点間のpingの結果が2.2~80msとばらつき有り&低速の結果でした。
この結果を見ると、VPNで拠点間を結ぶという方向よりも各拠点からTokyoRegionへアクセスするという方向にした方が良いのかもしれません。(もちろん用途によりますが)

TokyoRegionのEC2を利用する事で、場所に縛られず・安価に・スケーラビビリティのある環境が構築できそうです。

TokyoRegionはプラットフォームのイノベーションとなる予感満載ですね!引越しもできたので、これから積極的に使っていきたいと思います。



※ 2011年3月9日 追記
■ yumリポジトリもTokyoRegionに変更よう
amazon linux用のyumリポジトリもtokyo用に変更しましょう。具体的には/etc/yum.repos.d/amzn.repo の中身のmirrorlistのURLを変更します。Singaporeからの移動の場合は下記の通りになります。

mirrorlist=http://repo.ap-southeast-1.amazonaws.com/amzn-v0.9/mirror.list

mirrorlist=http://repo.ap-northeast-1.amazonaws.com/amzn-v0.9/mirror.list


リポジトリを同じRegion内にしていないとyumのupdateなどの速度が落ちてしまいますからね。




次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...