EC2のt1.microをt2.microへ移行する

PV から HVM への移行

AWS EC2 に t2 インスタンスが追加されました。
t2 インスタンスはスペック的にも料金的にも魅力的だったので、t1 インスタンスからの移行を試みました。
昨日作業してみて、無事作業完了したので行った事を晒してみます。

※chroot でのgrub設定部分で一部htmlエンコードしていませんでした。修正しました。
※t2インスタンスの価格を東京リージョンの価格に修正しました。
※PVからHVMへの変換手順としても使えると思います。

はじめに

某県会議員さんの記者会見のあまりのすごさに、暑さも吹っ飛びそうな今日この頃、みなさまいかがお過ごしですか?

先日新しい低コスト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.020
t2.small 1 2.0 Moderate $0.040
t2.medium 2 4.0 Moderate $0.080

※最新の価格は Amazon EC2 料金表 を参照

特に 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 のフォーラムにありました。

Convert CentOS PV to HVM

t1.micro から t2.micro への移行だけではなく、PV から HVM インスタンスへの移行全般で利用可能だと思います。
CentOSとタイトルにありますが、記事中には Amazon, CentOS, Red Hat でもOKである旨記載があります。
実際弊社では Amazon Linux での移行を行いました。

手順に関しては上記リンクの提示で十分な気もしますが、社内の備忘録的な意味も含めて、以下日本語でまとめてみます。

手順

手順の概要は下図のようになります。

migration steps

注意事項

  • コピー元は実稼働しているインスタンスを利用するのではなく、インスタンスのコピー(スナップショット)を作成し、これで作業するようにしましょう。
    作業に失敗したりした場合、インスタンスを破壊する可能性があります。
  • 作成するVolumeとInstanceのAvailability Zone は併せましょう。
    ap-northeast-1a/1c が混在するとアタッチできなくて作業のやり直しが増えます ( 経験者談 )。

PV に grub をインストールする

移行元の t1.microインスタンス (以下 コピー元インスタンス) に grub をインストールします。

$ sudo yum install grub

コピー元インスタンスのスナップショットを取得する

  1. awsのマネジメントコンソールから、EC2に移動します。
  2. メニューから [ ELASTIC BLOCK STORE ] > [ Volumes ] をクリックします。
  3. コピー元インスタンスのボリュームを右クリックして、コンテキストメニューから [ Create Snapshot ] をクリックします。
    Create Snapshot
  4. Create Shapshot ウィンドウが開くので、適当な名前と説明を入力して [ Create ] ボタンをクリックします。

コピー元ボリュームを作成する

上で作成したスナップショットから、コピー元ボリュームを作成します。

  1. メニューから [ ELASTIC BLOCK STORE ] > [ Snapshots ] をクリックします。
  2. 上で作成したスナップショットを右クリックして、コンテキストメニューから [ Create Volume ] をクリックします。
  3. Create Volume ウィンドウが開くので、各種値を設定して [ Create ] ボタンをクリックします。
    Availability Zone だけ併せましょう。他は初期値のままでOKです。

HVM用に新規ボリュームを作成する

t2.micro 用に 新規に Volume (以下 コピー先ボリューム) を作成します。

  1. [ ELASTIC BLOCK STORE ] > [ Volumes ] をクリックします。
  2. [ Create Volume ] ボタンをクリックします。
  3. Create Volume ウィンドウが開くので、各種値を設定して [ Create ] ボタンをクリックします。
    Create Volume

作業用インスタンスの起動

コピー元/コピー先ボリュームに対する操作は作業用のインスタンスを利用して行います。
作業用EC2インスタンスを作成して起動しておきます。 参考: 十分あれば十分? - EC2インスタンスの作成から起動まで

コピー元/コピー先ボリュームのアタッチ

作業用インスタンスにコピー先/コピー元ボリュームをアタッチします。
ボリュームのアタッチに関しては、起動中のインスタンスに対してでも行う事が可能です。
起動前にアタッチした場合、コピー元/コピー先がシステムのボリュームとしてマウントされてしまう可能性があるため、起動後の作業用インスタンスにアタッチした方が確実です。

  1. [ ELASTIC BLOCK STORE ] > [ Volumes ] をクリックします。
  2. コピー元ボリュームを右クリックして、コンテキストメニューから [ Attach Volume ] をクリックします。
  3. Attach Volume ウィンドウが開くので、以下を指定して [ Attach ] ボタンをクリックします。
    Instance作業用インスタンス
    欄をクリックするとアタッチ可能なインスタンスが表示されます。
    作業用インスタンスが表示されない場合Zone設定を誤ってないか確認しましょう。
    Device/dev/sdm
    元記事と併せています。これ以外でも構いませんが、以下手順では適宜読み替えて下さい。
  4. コピー先ボリュームも同様に作業用インスタンスにアタッチします。
    Instance作業用インスタンス
    Device/dev/sdo
    これも元記事と併せています。

作業用インスタンスでコピー先のパーティションを作成します。

以下作業は root ユーザでの作業を前提として書いています。必要に応じて sudo して下さい。

  1. パーティション作成
    # parted /dev/xvdo --script 'mklabel msdos mkpart primary 1M -1s print quit'
    
  2. OSに作成を通知
    # partprobe /dev/xvdo
    
  3. 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=1391485

コピー先ボリュームをリサイズします。

# 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 <<EOF | chroot /mnt grub --batch
> 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 ''

以下手順

  1. [ELASTIC BLOCK STORE] > [Volumes]をクリック。
  2. スナップショットを右クリックし、コンテキストメニューから [Create Image] をクリック。
  3. Create Image from EBS Snapshot ウィンドウが開くので、値を設定して、[Create] ボタンをクリック。 Create Image from EBS Snapshot

以上で 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インスタンスのバースト可能である点が発揮されたものかもしれません。( パフォーマンス計測結果の比較に関してはまた別記事で書こうと思います )。
→ 書きました。 t1.micro と t2.micro のパフォーマンス比較

パフォーマンスや価格の点を考えても、低コストインスタンスをこれから新規に利用する場合、T2インスタンスを利用する方がよいと思います。

個人的には、既にT1インスタンス等を利用している場合も、T2インスタンスに移行するのをお勧めします。
簡単に行えないという制約がありますが、上記手順により新規に作り直すよりは大分少ない手間で移行が可能です。
テストしてみる価値はあるのではないでしょうか。