今回は先日公開しようとしてしていた内容の後半部分を説明します。
なんか長くなってしまったのですが。。
内容サマリ
１）移行するEC2環境の構成について
２）AMIのリージョン間コピー/APリージョンでAMIの登録
*** 上記、二つの手順は前回に説明しています ***
３）Amazon EBS(Elastic Block Store)データの移行
４）移行後のシェルの修正
５）Amazon Machine Image（AMI）の再作成
Amazon EBS(Elastic Block Store)データの移行
Amazon EC2には不揮発性のディスクを提供するEBS（Elastic Block Store）というサービスがあります。
EBSはデータベースのデータなど永続的に保持したいデータの格納用に提供されたものです。
小職のテスト環境のデータベースは、Oracle社から無償で提供されている Oracle Database 10g Express Edition（XE） です。
このXEをEBS上に構築しています。
EBSを別のEC2リージョンに移行するコマンドは、見当たらなかった(たぶんない)のでLinuxのコマンドで移行作業を行いました。
*** 小ネタ: 無償のOracleはどこで手に入る？ ***********************
◆
Oracle Technology Network からDL
※ユーザ登録必須
※私はここからDLしたXEを自分のEC2にuploadしてOracle Database環境をEBS上に構築しました。
◆AmazonEC2のAMIもあった！
＠US Eastリージョン
AMI ID:ami-98be5cf1
Source:incharge/www.mototaker.com/ja_JP.32/ruby-db-ami/oracle_10gR2_XE_Univ_32Bit-Ruby_on_Rails233_Server-1.0-image.manifest.xml
※AmazonのAMIでは日本語が使えるもの(Universal版)はあまりないのでご注意。
※上記のAMIは日本語っぽいですねw
※US East、APリージョンではキーワードoracleで検索してもありませんでした。
※APリージョンには製品版のOracleがバンドルされたAMIすら存在しません。
******************************************************************
*** 豆知識: リージョン間AMIコピーコマンド（ec2-migrate-image） ***
※昨年末くらいからEBS上にAMIを構築するサービスも提供されていますが、前回のBLOGで説明したAMIのリージョン間コピー用コマンド(ec2-migrate-image)はEBS上のAMIを移行できません。
******************************************************************
◆データ移行手順＠US Eastリージョンでの作業
1)EBSにあるすべてのファイルをtarなどでアーカイブ
2)アーカイブしたファイルをs3へアップロード
＠Asia Pacificリージョンでの作業
3)APリージョンに登録したAMIの起動(前回のBLOGで説明したAMI)
4)EBS上にVolumを作成
5)S3からダウンロード
6)ダウンロードファイルの展開とファイルのアクセス権限変更
◆データ移行内容詳細＠US Eastリージョンでの作業1)EBSにあるすべてのファイルをtar+gzipでアーカイブ※EBSボリュームは/volというフォルダにマウントされています。
oracle関連のファイルはすべて/vol/oracle配下にありますので oracle フォルダ以下すべてをアーカイブして2GBづつのファイルに分割します。
cd /vol
tar czvf oracle.tar.gz ./oracle
split -b 500m oracle.tar.gz oracle.tar.gz.
mkdir /vol/oracleimg
mv oracle.tar.gz.* /vol/oracleimg/.
2)アーカイブしたファイルをs3へアップロードEC2からS3へのアップロードはrubyで作成されたスクリプト：s3sync.rb で行います。
以下の例では、S3に101ora-ap バケットを作成しそこに /vol/oracleimg フォルダを
同一名でコピーします。
cd /usr/local/s3sync
export AWS_ACCESS_KEY_ID='xxxxxxxxxxxxxxxx'
export AWS_SECRET_ACCESS_KEY='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
ruby s3cmd.rb createbucket 101ora-ap
ruby s3sync.rb -r --delete /vol/oracleimg/ 101ora-ap:oracleimg
*** 小ネタ：s3sync.rb はどこで手に入る？ *************************
以下の記事に書いてある通りやれば簡単に使えるようになります。
http://developer.amazonwebservices.com/connect/entry!default.jspa?categoryID=100&externalID=931&fromSearchPage=true・s3sync.rbのセットアップ
wget http://s3.amazonaws.com/ServEdge_pub/s3sync/s3sync.tar.gz
tar -xzvf s3sync.tar.gz
cp -r s3sync/ /usr/local/
******************************************************************
＠Asia Pacificリージョンでの作業3)APリージョンに登録されているAMIの起動(前回のBLOGで説明したAMI)※ここで起動されたAMIはrcが正しく動作しないためElasticIPも設定されずに動的なグローバルIPが割り当てられたままのとりあえずのインスタンスという状態です。
4)EBS上にVolumを作成US Eastで使用しているボリュームは使えませんのでAPリージョン用にボリュームを作成します。
EC2コンソールで50GBのボリュームを作成後、フォーマット（/dev/sdh）してマウントします。
4-1.EC2コンソールで50GBのボリューム作成とアタッチコンソールのメニュー Volumes をクリックして EBS Volumes の画面を表示します。
「Create Volumes」をクリックすると以下の画面が表示されるので Size 入力エリアに50と入力します。
Availavility Zone:は現在インスタンスが起動しているZoneに合わせます。ボリュームはZone固有です。
※ec2-create-volumeというコマンドもあるのですがなぜか実行するとエラーになりました。
# ec2-create-volume --size 50 --availability-zone ap-southeast-1
Client.InvalidZone.NotFound: The zone 'ap-southeast-1' does not exist.
次に作成された Volume をデバイスに Attach します。
作成したVolumeはコンソールに表示されますので左のチェックボックスをチェックして「Attach Volumes」をクリックすると以下の画面が表示されるのでDevice:を選択して「Attach」ボタンをクリックします。
アタッチ後確認してみるとブロックデバイスができています。
# ls -al /dev/sdh
brw-r----- 1 root disk 8, 112 May 5 07:58 /dev/sdh
※コマンドで実行する場合は以下の通り
# ec2-attach-volume vol-80d160e8 --instance i-9dace8cf --device /dev/sdh
4-2.mkfsコマンドでデバイスのフォーマット（プロンプトはすべてyesとする実行例）# yes | mkfs -t ext3 /dev/sdh
mke2fs 1.40.4 (31-Dec-2007)
/dev/sdh is entire device, not just one partition!
Proceed anyway? (y,n) Filesystem label=
OS type: Linux
Block size=4096 (log=2)
・・・省略・・・
This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
4-3.フォーマットされたデバイスのマウント# mount /dev/sdh /vol
5)S3からダウンロード作成したVolumeがファイルシステムから見えるようになったのでS3からoracle関連のアーカイブファイルをダウンロードします。
S3へのアクセスのために以下の環境変数を設定します。
# export AWS_ACCESS_KEY_ID='xxxxxxxxxxxxxxxx'
# export AWS_SECRET_ACCESS_KEY='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
# export AWS_CALLING_FORMAT='SUBDOMAIN'
※US Eastでは環境変数 AWS_CALLING_FORMAT はデフォルトの REGULAR でよいので指定していませんでしたがAPでは必須です。（
参照）
# cd /usr/local/s3sync
# ruby s3cmd.rb get 101ora-ap:oracleimg/oracle.tar.gz.ad /vol/oracle.tar.gz.ad &
# ruby s3cmd.rb get 101ora-ap:oracleimg/oracle.tar.gz.ac /vol/oracle.tar.gz.ac &
# ruby s3cmd.rb get 101ora-ap:oracleimg/oracle.tar.gz.ab /vol/oracle.tar.gz.ab &
# ruby s3cmd.rb get 101ora-ap:oracleimg/oracle.tar.gz.aa /vol/oracle.tar.gz.aa &
分割したファイルの結合
# cd /vol
# cat oracle.tar.gz.aa oracle.tar.gz.ab oracle.tar.gz.ac oracle.tar.gz.ad > oracle.tar.gz
6)ダウンロードファイルの展開とファイルのアクセス権限変更# chown oracle oracle.tar.gz
# chgrp dba oracle.tar.gz
# su - oracle
% cd /vol
% ls
lost+found oracle.tar.gz
% tar xvfz oracle.tar.gz
◆sビットを付与
% chmod ug+s oracle
% chmod ug+s tnslsnr
移行後のシェルの修正
US EastリージョンからコピーしてきたAMIで起動されたインスタンスはrc（起動シェル）に記載された内容がUS Eastリージョン用になったままです。
ここではリージョン固有の記述がされたシェルの内容を修正します。
◆rcで実行させているシェルの修正について
1)Elastic IP Address
Elastic IP Addressとは固定IPを利用できるサービスです。
（Elastic IP Addressについては書きだめのテキストがあるのでこれも後日掲載します。鮮度はなくなってますが。。）
リージョンが変わればもちろんIPアドレスも振り直しですね。
まずはAWSのWebコンソールからAPリージョンのElasticIPを購入します。
購入したIPアドレスをインスタンスIDに関連付けなければいけません。
AmazonEC2のインスタンスIDは起動時に動的に付与されますので起動するたびに変化します。
起動後に手動で関連付けることももちろん可能ですが。。
インスタンス起動時に動的に関連付けるためのシェルが以下のようになります。
シェルをみるとわかると思いますが引数 region でAPリージョンの値を指定しています。
てっきりコマンドを実行しているインスタンスがデフォルトの region なると勝手に信じていたのでエラーになる理由がわからずちょっとハマりました。
#!/bin/bash
#
# Associate EC2 Elastic IP Address with INSTANCE
source /root/.ec2env
var1=`ec2din
--region ap-southeast-1| grep running | gawk '{print $2}'`
#echo $var1
ec2assocaddr 購入したIPアドレス -i $var1 >/dev/null 2>&1
2)EBSのアタッチ
EBSを作成すると固定の識別ID（Volume ID）が付与されます。
インスタンスIDは起動時に動的に付与されますので起動ごとに変化します。
つまりEBSはインスタンス起動後にアタッチしてあげる必要があります。
そのための起動シェルは以下のようになります。
このシェルにも region 引数を追加しています。
#!/bin/bash
#
# Attach EBS VolumeID: vol-84ac00ec to INSTANCE
source /root/.ec2env
var1=`ec2din
--region ap-southeast-1 | grep running | gawk '{print $2}'`
#echo $var1
ec2attvol
--region ap-southeast-1 vol-84ac00ec -i $var1 -d /dev/sdh >/dev/null 2>&1
mount /dev/sdh /vol
Amazon Machine Image（AMI）の再作成
システム起動時のシェルを修正したら忘れずに再度AMIを作成します。
これを忘れてシステムを停止してしまうと設定が消えて苦労が水の泡なので注意しましょう！
※上記はRoot Device Type: instance-store
※EBS上にAMIを作成できるサービスも始まっているのでそれを利用すれば設定は消えません。
私のインスタンスはまだS3上に置いたAMIから起動するタイプです。
以下AMI再作成の手順です。
1)AMIのサイズは10GBまでという制限があるのでoracleが配置してあるボリュームをumountします。
umount /vol
2)AMIを作成するコマンドの実行
ec2-bundle-vol -d /tmp -k pk-xxxxxxxxxxxxxxxxx.pem -c cert-xxxxxxxxxxxxxxxx.pem -u 999999999 -r i386 -p oracle10gXE32bitUniv2
正常に終わると/tmpの下にmanifestファイルとAMIを10MB単位に分割したファイルがたくさんできています。
3)作成されたAMIをS3にアップロード
ec2-upload-bundle
-r ap-southeast-1a -b tnoraclexe -m /tmp/oracle10gXE32bitUniv2.manifest.xml -a AccsessKey値 -s SecretAccessKey値
上記のコマンドが2)で作成したファイルをS3の tnoraclexe バケットにアップロードします。
4)S3に保管したAMIをAPリージョンに登録
ec2-register
--region ap-southeast-1 tnoraclexe/oracle10gXE32bitUniv2.manifest.xml
※ここでも region 引数を指定しています。
US Eastでは指定する必要なかったのですが、ほとんどのコマンドで region 引数を明示的に指定する必要があるようですね。
以上、長々と書いてしまいましたがなんとなくお分かりいただけましたでしょうか？
おまけ
US East と AP ネットワークレイテンシを計測した結果の画面スナップショットを掲載します。
ググルとすでにBLOGなどで掲載しているのを見つけることができますね。
結論から言うとAPリージョンのほうがUS Eastに比べると2.5倍くらい早いですね。
いままでレイテンシーが大きいのではと懸念されていた方もAPリージョンならその心配もない様に思います。
ちなみにAmazonが提供しているAMIはデフォルトではpingは通らない設定になっているのでWebコンソールのSecurity Group設定でpingを通す設定してください。
ピングを通す設定は以下の通りです。
Protocol FromPort ToPort IP
-------------------------------------------
icmp -1 -1 許可するIPアドレス
◆以下レイテンシーの計測結果1)ローカルPCからUS EastとAsia Pacificリージョンにping実行結果
2)US Eastインスタンスからwww.nikkei.comへping実行結果
3)Asia Pacificインスタンスからwww.nikkei.comへping実行結果
以上 前後半2回に分けて紹介したEC2インスタンスのリージョン間移行手順。
みなさまのお役立てば幸いです。
ではまた。
