はじめに
次世代インスタンスタイプが発表され、少なくともt2シリーズに関しては無料枠を利用したい場合以外t3を利用しない手はないと思いますので、会社のt2系インスタンスたちをt3に変更しようとしたところ、ちょっとしたハマりポイントに遭遇しましたので備忘録として残しておきます。
Nitro Systemについては公式ドキュメントを。
概要
- 旧世代のAMIで作成したEC2インスタンスはENAを有効化する必要がある
- ルートデバイス以外にEBSをアタッチしているEC2インスタンスはfstabのデバイス名を修正する必要がある
変更手順
変更手順についてはこちらの記事に付け加える点はないです。感謝!
現在のEC2インスタンスがENAに対応しているか確認
$ aws ec2 describe-instances \
--instance-ids YOUR_INSTANCE_ID \
--query 'Reservations[].Instances[].EnaSupport'
結果の出力が空
であれば未対応です。
このままインスタンスタイプを変更しようとすると(NITRO世代インスタンスタイプを選択することは可能)、下記エラーが出て起動できません。
Enhanced networking with the Elastic Network Adapter (ENA) is required for the 't3.medium' instance type. Ensure that your instance 'YOUR_INSTANCE_ID' is enabled for ENA.
NITRO世代のインスタンスタイプはENA対応が必須なので、有効化しましょう。
ENA有効化
$ aws ec2 modify-instance-attribute \
--instance-id YOUR_INSTANCE_ID \
--ena-support
EC2インスタンス起動
あとは普通に起動すればOKです。
ルートデバイス以外にEBSをアタッチしている場合は注意が必要
ここからが本題です。
EC2インスタンスにおいて、ルートデバイスは/dev/xvda1
となり、それ以外のEBSをアタッチすると、xvdb
,xvdc...
というデバイス名で認識されます。
ここで、ルートデバイスのみのNITRO世代EC2インスタンスのdfの結果とfstabを確認してみます。
ルートデバイスのみ
# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 1988132 12 1988120 1% /dev
tmpfs 398668 328 398340 1% /run
/dev/nvme0n1p1 51466360 9004128 40265740 19% /
none 4 0 4 0% /sys/fs/cgroup
none 5120 0 5120 0% /run/lock
none 1993332 0 1993332 0% /run/shm
none 102400 0 102400 0% /run/user
ルートデバイス名が/dev/xvda1
から/dev/nvme0n1p1
になっています。
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
/etc/fstab
については、LABELによる指定のため、変更されていません。
ルートデバイス以外にEBSをアタッチしている場合
fstabが下記のように書かれている状態で、NITRO世代インスタンスタイプに変更してみます。
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
/dev/xvdb /data ext4 defaults,nofail 0 0
インスタンスタイプ変更後
# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 1984692 0 1984692 0% /dev
tmpfs 398540 5740 392800 2% /run
/dev/nvme0n1p1 20263528 7514240 12732904 38% /
tmpfs 1992680 0 1992680 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 1992680 0 1992680 0% /sys/fs/cgroup
tmpfs 398540 0 398540 0% /run/user/1000
OSは起動しましたが、/dev/xvdb
がマウントされていません。
デバイスを確認してみます。
# ll /dev | grep nvme
crw------- 1 root root 248, 0 10月 16 23:04 nvme0
brw-rw---- 1 root disk 259, 1 10月 16 23:04 nvme0n1
brw-rw---- 1 root disk 259, 2 10月 16 23:04 nvme0n1p1
crw------- 1 root root 248, 1 10月 16 23:04 nvme1
brw-rw---- 1 root disk 259, 0 10月 16 23:04 nvme1n1
/dev/xvdb
が/dev/nvme1n1
になっています。
※デバイス名はアタッチしているディスク数、パーティションの切り方で変わるので環境に合わせて読み替えてください。
そこで、fstabを下記のように修正します。
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
/dev/nvme1n1 /data ext4 defaults,nofail 0 0
OSを再起動します。
# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 1984692 0 1984692 0% /dev
tmpfs 398540 5856 392684 2% /run
/dev/nvme0n1p1 20263528 7514548 12732596 38% /
tmpfs 1992680 4 1992676 1% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 1992680 0 1992680 0% /sys/fs/cgroup
/dev/nvme1n1 51475068 736676 48100568 2% /data
tmpfs 398540 0 398540 0% /run/user/1000
うまくマウントされました。
デバイス名については公式ドキュメントに記載があります。
注意
今回のケースでは、fstabのマウントオプションnofail
をつけていたためデバイス名が変わってもマウントされずにOS自体は起動できましたが、オプションなしだと起動時のマウントに失敗し、OSが起動せず焦る羽目になるので、前もってfstabにはnofail
をつけておきましょう。