[アップデート]Amazon EBSの複数インスタンスへのアタッチが可能になりました!(プロビジョンドIOPS io1ボリュームに限る)
コンバンハ、千葉(幸)です。
いくつか制約付きで、EBSボリュームを複数のEC2インスタンスにアタッチ(マルチアタッチ)できるようになりました!
Amazon EBS Multi-Attach now available on Provisioned IOPS io1 volumes
制限・考慮事項
- I/Oフェンシングプロトコルに対応していないため、アプリケーション側で同時書き込みの排他制御を担保する必要がある
- ボリュームタイプはプロビジョンドIOPS(io1)である必要がある
- マルチアタッチするEC2インスタンスはEBSボリュームと同一アベイラビリティゾーンである必要がある
- マルチアタッチするEC2インスタンスはNitroベースのインスタンスである必要がある
- マルチアタッチできるのは最大16台まで
- 現状マルチアタッチできるのはus-east-1、us-east-2、us-west-2、eu-west-1、ap-northeast-2である
- 東京リージョンはまだ!
- マルチアタッチ対応ボリュームはブートボリュームとして作成できない
- マルチアタッチ対応ボリュームはインスタンスごとにアタッチできるのは1つのデバイスのみ
- ボリュームの作成後にマルチアタッチの有効/無効を変更することはできない
- マルチアタッチ対応ボリュームのボリュームタイプ、サイズ、プロビジョンドIOPSを変更することはできない
- EBSの物理ホストに影響があった場合、マルチアタッチしているEC2インスタンスすべてで使用できない
- EC2インスタンスにおけるEBSボリュームの「終了時に削除」の有効/無効は、最後にアタッチされたEC2インスタンスの設定が採用される
- マルチアタッチしているインスタンスで統一することを推奨する
- インスタンス終了時のEBSボリュームの保持についてはこちら
詳細は以下をご確認ください。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volumes-multi.html
やってみた
以下のブログを参考に、やっていきます。
https://aws.amazon.com/jp/blogs/aws/new-multi-attach-for-provisioned-iops-io1-amazon-ebs-volumes/
EBSの作成
今回はus-east-1
で試してみます。ボリュームタイプでプロビジョンドIOPSを選択すれば、マルチアタッチの有効/無効を選択できるようになっています。
EC2へのアタッチ
今回はすでに同一AZに2台のEC2インスタンスを作成済みです
- amzn2-ami-hvm-2.0.20200207.1-x86_64-gp2(ami-0a887e401f7654935)
- t3.micro
EBSボリュームの画面から、それぞれのインスタンスにアタッチしていきます。デバイスはデフォルトの/dev/sdf
にしています。
2台目も同様に。
EBSの画面から、それぞれにアタッチされたことが確認できます。
EC2インスタンスの側からはこのように確認できます。「終了時に削除」は、デフォルトでfalseになっています。変更する場合は、マネジメントコンソールからでは不可のため、CLIやSDKで実施する必要があります。
OSでの確認
今回はSSMで接続してみます。まずは1号機での作業です。
/dev/sdf
としてアタッチしたEBSを、/data
にマウントし、/data
配下にfile.txt
を作成しています。
ここで作成したfile.txt
を2号機からも参照できることがゴールです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | sh-4.2$ uname -a Linux ip-192-168-1-239.ec2.internal 4.14.165-131.185.amzn2.x86_64 #1 SMP Wed Jan 15 14:19:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux sh-4.2$ whoami ssm-user sh-4.2$ sudo mkfs -t xfs /dev/sdf meta-data=/dev/sdf isize=512 agcount=4, agsize=655360 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=0 data = bsize=4096 blocks=2621440, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 sh-4.2$ sudo mkdir /data sh-4.2$ sudo mount /dev/sdf /data sh-4.2$ cd /data sh-4.2$ sudo vi file.txt sh-4.2$ cat file.txt Hello from a Multi-Attach EBS volume!;) sh-4.2$ |
(コマンドの意味が自分の中で怪しかったのでメモ。)
mkfs -t <ファイルシステムの種類> <デバイス名>
mount <デバイス> <マウントポイント>
2号機側での作業です。
同じように/dev/sdf
を/data
にマウントし、file.txt
を確認します。
1 2 3 4 5 6 7 8 9 | sh-4.2$ uname -a Linux ip-192-168-1-178.ec2.internal 4.14.165-131.185.amzn2.x86_64 #1 SMP Wed Jan 15 14:19:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux sh-4.2$ whoami ssm-user sh-4.2$ sudo mkdir /data sh-4.2$ sudo mount /dev/sdf /data sh-4.2$ cd /data sh-4.2$ cat file.txt Hello from a Multi-Attach EBS volume!;) |
問題なくfile.txt
の中身のHello from a Multi-Attach EBS volume!;)
が確認できました。
ちなみに
上記の状態で、1号機と2号機で同じファイルに対して読み書きができる状態になっていると勘違いしていたのですが、そのようなことはありませんでした。1号機、2号機それぞれで加えた変更は、相手側からは見えておらず、アンマウント→マウントし直すといずれか一方の最終状態が見える、という挙動でした。
おまけ
fdisk -l
コマンドでデバイス/dev/sdf
が確認できると思ったのですが、/dev/nvme1n1
という見慣れない文字が。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | sh-4.2$ sudo fdisk -l Disk /dev/nvme0n1: 8 GiB, 8589934592 bytes, 16777216 sectors #EC2ローンチ時に作成したEBS Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 65E66B8B-7479-4A5D-8D3C-3570E8F219E7 Device Start End Sectors Size Type /dev/nvme0n1p1 4096 16777182 16773087 8G Linux filesystem /dev/nvme0n1p128 2048 4095 2048 1M BIOS boot Partition table entries are not in disk order. Disk /dev/nvme1n1: 10 GiB, 10737418240 bytes, 20971520 sectors #マルチアタッチしたEBS Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes |
Nitroベースのインスタンスの場合はそうなるようです。
Nitro ベースのインスタンスでは、EBS ボリュームは NVMe ブロックデバイスとして公開されます。デバイス名は、/dev/nvme0n1、/dev/nvme1n1 などです。ブロックデバイスマッピングで指定したデバイス名は、NVMe デバイス名 (/dev/nvme[0-26]n1) を使用して名称変更されます。
以下のコマンドで元のデバイス名を確認することができます。
1 2 3 | sh-4.2$ sudo /sbin/ebsnvme-id /dev/nvme1n1 Volume ID: vol-04c169afe360df05d /dev/sdf |
Linux インスタンスの Amazon EBS および NVMe
終わりに
「EBSは複数のインスタンスで共有できない」というのは長らく常識であったので、個人的には少し驚きのアップデートでした。クラスタ製品など、EBSの共有ができないためにAWSでの実装ができなかったものが、このアップデートによって解消されるかもしれません。
ただ、「オンプレではこういうことができていたから、AWSでも同じ構成にしたい!」の一助になるアップデートではありますが、果たしてそれが正解なのか?というのはよくよく考慮が必要かと思います。どういった使い道があるのかは、これからよく揉まれていくことでしょう。ウォッチしていきます。
以上、東京の千葉でした!