EC2のt1.microをt2.microへ移行する
@agilegroup_twさんをフォロー
AWS EC2 に t2 インスタンスが追加されました。
t2 インスタンスはスペック的にも料金的にも魅力的だったので、t1 インスタンスからの移行を試みました。
昨日作業してみて、無事作業完了したので行った事を晒してみます。
はじめに
某県会議員さんの記者会見のあまりのすごさに、暑さも吹っ飛びそうな今日この頃、みなさまいかがお過ごしですか?
先日新しい低コストEC2インスタンスに関するアナウンスがAmazonからありました。
【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス
アナウンスではバースト可能である点等があげられていますが、T1世代の同クラスのインスタンスと単純にスペック比較しただけでもかなり魅力的です。
( ※スペック等は執筆時 ( 2014/7/3 ) )
T1インスタンス
モデル | vCPU | メモリ(GB) | I/O | Price/Hour |
---|---|---|---|---|
t1.micro | 1 | 0.613 | Very Low | $0.026 |
m1.small | 1 | 1.7 | Low | $0.061 |
m1.medium | 1 | 3.7 | Moderate | $0.122 |
T2インスタンス
モデル | vCPU | メモリ(GB) | I/O | Price/Hour |
---|---|---|---|---|
t2.micro | 1 | 1.0 | Moderate | $0.013 |
t2.small | 1 | 2.0 | Moderate | $0.026 |
t2.medium | 2 | 4.0 | Moderate | $0.052 |
特に T1マイクロ はメモリが 60%増しになって、I/Oが改善された上に、価格も下がっています ( 他のもですが )。
これを見たら、とりあえず t1.micro で動作しているインスタンスは t2.micro に移行してみたくなるというものです。
「t1.micro を・・・・・・ウッ・・・・・ガエダイ!」
移行の壁
AWS EC2 の場合、動作しているインスタンスのスナップショットを取得しておけば、これを元にAMIイメージを作成して別のインスタンスタイプで実行する事が可能です。
が、これは仮想化方式が同じ場合にのみ使えるようで、
PV (paravirtual, 準仮想化) 方式である t1.micro から HVM (Hardware-assited VM) 方式のみサポートしている t2.micro への変更は、現状では aws コンソール等でサクッと行うという事はできないようです。
※PV, HVM に関する違いに関しては、こちらの記事がよくまとまっています。 仮想化方式(HVM と PV)についてまとめ
とはいえ、一からT2インスタンスを作成して、環境を再構築するという手順はあまり踏みたくありません。
ブートローダ、及び、ブート領域がきちんと設定されていれば、PVインスタンスをHVMインスタンスに変更する事も可能なはずです。
移行手順を探す
上記の考えのもと PV から HVM へ移行するための手順を探ってみました。
当初、HVMインスタンス ( t2.micro ) のブート領域、及び、ブートローダを PV ( t1.micro ) に適切にコピーする事で対応できるはずと考え、手順を探していたのですが、aws のフォーラムにありました。
t1.micro から t2.micro への移行だけではなく、PV から HVM インスタンスへの移行全般で利用可能だと思います。
手順に関しては上記リンクの提示で十分な気もしますが、社内の備忘録的な意味も含めて、以下日本語でまとめてみます。
手順
手順の概要は下図のようになります。
注意事項
- コピー元は実稼働しているインスタンスを利用するのではなく、インスタンスのコピー(スナップショット)を作成し、これで作業するようにしましょう。
作業に失敗したりした場合、インスタンスを破壊する可能性があります。 -
作成するVolumeとInstanceのAvailability Zone は併せましょう。
ap-northeast-1a/1c が混在するとアタッチできなくて作業のやり直しが増えます ( 経験者談 )。
PV に grub をインストールする
移行元の t1.microインスタンス (以下 コピー元インスタンス) に grub をインストールします。
$ sudo yum install grub
コピー元インスタンスのスナップショットを取得する
- awsのマネジメントコンソールから、EC2に移動します。
- メニューから [ ELASTIC BLOCK STORE ] > [ Volumes ] をクリックします。
- コピー元インスタンスのボリュームを右クリックして、コンテキストメニューから [ Create Snapshot ] をクリックします。
- Create Shapshot ウィンドウが開くので、適当な名前と説明を入力して [ Create ] ボタンをクリックします。
コピー元ボリュームを作成する
上で作成したスナップショットから、コピー元ボリュームを作成します。
- メニューから [ ELASTIC BLOCK STORE ] > [ Snapshots ] をクリックします。
- 上で作成したスナップショットを右クリックして、コンテキストメニューから [ Create Volume ] をクリックします。
- Create Volume ウィンドウが開くので、各種値を設定して [ Create ] ボタンをクリックします。
Availability Zone だけ併せましょう。他は初期値のままでOKです。
HVM用に新規ボリュームを作成する
t2.micro 用に 新規に Volume (以下 コピー先ボリューム) を作成します。
- [ ELASTIC BLOCK STORE ] > [ Volumes ] をクリックします。
- [ Create Volume ] ボタンをクリックします。
- Create Volume ウィンドウが開くので、各種値を設定して [ Create ] ボタンをクリックします。
作業用インスタンスの起動
コピー元/コピー先ボリュームに対する操作は作業用のインスタンスを利用して行います。
作業用EC2インスタンスを作成して起動しておきます。 参考: 十分あれば十分? - EC2インスタンスの作成から起動まで
コピー元/コピー先ボリュームのアタッチ
作業用インスタンスにコピー先/コピー元ボリュームをアタッチします。
ボリュームのアタッチに関しては、起動中のインスタンスに対してでも行う事が可能です。
起動前にアタッチした場合、コピー元/コピー先がシステムのボリュームとしてマウントされてしまう可能性があるため、起動後の作業用インスタンスにアタッチした方が確実です。
- [ ELASTIC BLOCK STORE ] > [ Volumes ] をクリックします。
- コピー元ボリュームを右クリックして、コンテキストメニューから [ Attach Volume ] をクリックします。
- Attach Volume ウィンドウが開くので、以下を指定して [ Attach ] ボタンをクリックします。
Instance 作業用インスタンス
欄をクリックするとアタッチ可能なインスタンスが表示されます。
作業用インスタンスが表示されない場合Zone設定を誤ってないか確認しましょう。Device /dev/sdm
元記事と併せています。これ以外でも構いませんが、以下手順では適宜読み替えて下さい。 - コピー先ボリュームも同様に作業用インスタンスにアタッチします。
Instance 作業用インスタンス Device /dev/sdo
これも元記事と併せています。
作業用インスタンスでコピー先のパーティションを作成します。
以下作業は root ユーザでの作業を前提として書いています。必要に応じて sudo して下さい。
- パーティション作成
# parted /dev/xvdo --script 'mklabel msdos mkpart primary 1M -1s print quit'
- OSに作成を通知
# partprobe /dev/xvdo
- udevd にも通知
# udevadm settle
コピー元ボリュームをリサイズ
元記事ではコピー元ボリュームをリサイズ(最小化)しています。( 空き領域を圧縮し、後のコピープロセスの時間短縮を図るため )
リサイズします。
# e2fsck -f /dev/xvdm # resize2fs -M /dev/xvdm - Output from resize command: Resizing the filesystem on /dev/xvdm to 1391485 (4k) blocks. The filesystem on /dev/xvdm is now 1391485 blocks long.
リサイズの結果が出力されるので、ブロックサイズとブロック数を控えておいてください。
ボリュームの複製
dd コマンドを利用して、コピー元からコピー先に複製します。
ブロックサイズとブロック数は上で控えた値を指定する事。
# dd if=/dev/xvdm of=/dev/xvdo1 bs=4K count=269020
コピー先ボリュームをリサイズします。
# resize2fs /dev/xvdo1
コピー先へのおまじない
chroot を利用した grub インストールのための準備を行います。
# mount /dev/xvdo1 /mnt # cp -a /dev/xvdo /dev/xvdo1 /mnt/dev/ # rm -f /mnt/boot/grub/*stage* # cp /mnt/usr/*/grub/*/*stage* /mnt/boot/grub/ # rm -f /mnt/boot/grub/device.map
grub インストール
chrootを利用した grub インストールを行います。
# cat <device (hd0) /dev/xvdo > root (hd0,0) > setup (hd0) > EOF Probing devices to guess BIOS drives. This may take a long time. GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> device (hd0) /dev/xvdo grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 31 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+31 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded Done.
テンポラリデバイスの削除
コピー先からテンポラリデバイスを削除します。
# rm -f /mnt/dev/xvdo /mnt/dev/xvdo1
grub設定を更新します。
# vi /mnt/boot/grub/menu.lst
以下内容で編集
- root (hd0) → root (hd0,0) に変更
- console=* の部分を console=ttyS0 に変更
- xen_pv_hvm=enable を kernel ... 行に追記
以下例
# created by imagebuilder default=0 timeout=1 hiddenmenu title Amazon Linux 2014.03 (3.10.42-52.145.amzn1.x86_64) root (hd0,0) kernel /boot/vmlinuz-3.10.42-52.145.amzn1.x86_64 root=LABEL=/ console=ttyS0 LANG=ja_JP.UTF-8 KEYTABLE=us xen_pv_hvm=enable initrd /boot/initramfs-3.10.42-52.145.amzn1.x86_64.img
fstab を編集
# vi /mnt/etc/fstab
元記事では以下のように編集する必要がある旨記載がありますが、私の環境では特に変更の必要はありませんでした。
LABEL=/ / ext4 defaults,noatime 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0
コピーボリュームにラベルを作成しアンマウント
# e2label /dev/xvdo1 / # sync # umount /mnt
コピー先ボリュームのスナップショットを作成
vol-xxxxxxxx は コピー先ボリュームIDを指定、 description は適当に設定して下さい。
# aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "amazon-linux HVM snapshot"
※awsコマンドで怒られた場合、以下設定を行ってください。
# aws configure AWS Access Key ID None: XXXXXXXXXXXXXXXXXXXX AWS Secret Access Key None: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Default region name None: ap-northeast-1 Default output format None: json
スナップショットから HVM AMI を作成
元記事では以下で作成する旨記載がありますが、うまくいかなかったため、awsマネジメントコンソールから行いました。
#aws ec2 register-image --name "amazon-linux HVM" --description "amazon-linux HVM" --architecture x86_64 --root-device-name "/dev/sda1" --virtualization-type hvm --block-device-mappings ''
以下手順
- [ELASTIC BLOCK STORE] > [Volumes]をクリック。
- スナップショットを右クリックし、コンテキストメニューから [Create Image] をクリック。
- Create Image from EBS Snapshot ウィンドウが開くので、値を設定して、[Create] ボタンをクリック。
以上で HVM 対応の AMI が完成しました。
T2インスタンスを起動する
AMIが作成されたら、このAMIを利用してインスタンスをローンチします。
IMAGES > AMIs メニューに移動し、作成したAMI を右クリックし、[ Launch ] をクリックします。
後はウィザードに従ってインスタンスを起動して、問題なくインスタンスが起動すればOKです。
環境確認
当然ですが、起動したインスタンスの動作や設定に問題がないか確認してください。
私が確認した環境では、CMSの動作やコンテンツ自体には問題がなかったのですが、一部のシステム設定が移行前と違っていたため、 EC2インスタンス(Amazon Linux)の初期設定 にある設定の一部をやり直しました。
弊社の場合、特段問題もなかったので、数時間テストした後Webサイトも入れ替えてしまったのですが、あまり急がずにきちんと確認を取った方がよいと思います。
「本当にt2.micro インスタンスで動いているのか?」と不安になった方は、
$ free
とでも叩いてみましょう。きちんと1GBのメモリが割り当てられている事が確認できます。
$ free total used free shared buffers cached Mem: 1020536 927580 92956 0 7448 190036 -/+ buffers/cache: 730096 290440 Swap: 1310716 13664 1297052
まとめ
T2インスタンスの登場により、EC2のインスタンスラインナップは更に魅力的なものになったと感じています。
Webサイト入れ替え前に簡単なパフォーマンステストも流したのですが、t2.microはパフォーマンスもt1.micro に比べてかなりよい数値を出してくれています。
特に t1.micro は大量のリクエストを投げた場合、ある程度時間が経過するとパフォーマンスがかなり落ちてしまう傾向にあったのですが、t2.microに関してはその傾向が殆ど見られませんでした。
これはT2インスタンスのバースト可能である点が発揮されたものかもしれません。( パフォーマンス計測結果の比較に関してはまた別記事で書こうと思います )。
パフォーマンスや価格の点を考えても、低コストインスタンスをこれから新規に利用する場合、T2インスタンスを利用する方がよいと思います。
個人的には、既にT1インスタンス等を利用している場合も、T2インスタンスに移行するのをお勧めします。
簡単に行えないという制約がありますが、上記手順により新規に作り直すよりは大分少ない手間で移行が可能です。
テストしてみる価値はあるのではないでしょうか。