![[アップデート] Amazon EBSの複数インスタンスへのアタッチが可能になりました！(プロビジョンドIOPS io1ボリュームに限る)](https://devio2023-media.developers.io/wp-content/uploads/2019/05/amazon-ebs.png)
[アップデート] Amazon EBSの複数インスタンスへのアタッチが可能になりました！(プロビジョンドIOPS io1ボリュームに限る)
コンバンハ、千葉（幸）です。
いくつか制約付きで、EBSボリュームを複数のEC2インスタンスにアタッチ（マルチアタッチ）できるようになりました！
制限・考慮事項
- 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インスタンスの設定が採用される
- マルチアタッチしているインスタンスで統一することを推奨する
- Amazon EC2 インスタンスを終了する - Amazon Elastic Compute Cloud
詳細は以下をご確認ください。
やってみた
以下のブログを参考に、やっていきます。
EBSの作成
今回はus-east-1で試してみます。ボリュームタイプでプロビジョンドIOPSを選択すれば、マルチアタッチの有効/無効を選択できるようになっています。
EC2へのアタッチ
今回はすでに同一AZに２台のEC2インスタンスを作成済みです。
- amzn2-ami-hvm-2.0.20200207.1-x86_64-gp2(ami-0a887e401f7654935)
- t3.micro
EBSボリュームの画面から、それぞれのインスタンスにアタッチしていきます。デバイスはデフォルトの/dev/sdfにしています。
２台目も同様に。
EBSの画面から、それぞれにアタッチされたことが確認できます。
EC2インスタンスの側からはこのように確認できます。「終了時に削除」は、デフォルトでfalseになっています。変更する場合は、マネジメントコンソールからでは不可のため、CLIやSDKで実施する必要があります。
OSでの確認
今回はSSMで接続してみます。まずは１号機での作業です。
デバイス/dev/sdfとしてアタッチしたEBSを、ファイルシステムタイプxfsでフォーマットし、/dataにマウントしています。
/data配下にfile.txtを作成し、このファイルを２号機からも参照できることをゴールとします。
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 ＜デバイス＞ ＜マウントポイント＞
２号機側での作業です。
同じように/dev/sdfを/dataにマウントし、file.txtを確認します。
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号機、２号機それぞれで加えた変更は、相手側からは見えておらず、アンマウント→マウントし直すといずれか一方の最終状態が見える、という挙動でした。ファイルシステムのタイプや、マウントの仕方によって変わる部分かと思います。
▼追記 ここから
関連する記述が公式からアナウンスされていました。
EBS Multi-Attach では、標準ファイルシステムはサポートされていません。XFS、EXT3、EXT4、NTFS などのファイルシステムは、複数のサーバーまたは EC2 インスタンスが同時にアクセスするようには設計されていません。したがって、これらのファイルシステムには、書き込み、読み取り、ロック、キャッシュ、マウント、フェンシングなどの調整と制御を管理するための組み込みメカニズムがありません。
複数のサーバーが標準ファイルシステムに同時にアクセスできるようにすると、データの破損または損失が発生する可能性があります。EBS Multi-Attach ボリューム上の標準ファイルシステムを操作できるようにする設定は、サポートされていません。
今回の例ではxfsを用いてインスタンスを跨いだ参照を行っていますが、あくまで分かりやすさを重視するためのものであり、実際の運用で使用できる状態ではありません。本番設計においてはさらに多くを考慮する必要があるでしょう。
▲追記 ここまで
おまけ
fdisk -lコマンドでデバイス/dev/sdfが確認できると思ったのですが、/dev/nvme1n1という見慣れない文字が。
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) を使用して名称変更されます。
以下のコマンドで元のデバイス名を確認することができます。
sh-4.2$ sudo /sbin/ebsnvme-id /dev/nvme1n1
Volume ID: vol-04c169afe360df05d
/dev/sdf
終わりに
「EBSは複数のインスタンスで共有できない」というのは長らく常識であったので、個人的には少し驚きのアップデートでした。クラスタ製品など、EBSの共有ができないためにAWSでの実装ができなかったものが、このアップデートによって解消されるかもしれません。
ただ、「オンプレではこういうことができていたから、AWSでも同じ構成にしたい！」の一助になるアップデートではありますが、果たしてそれが正解なのか？というのはよくよく考慮が必要かと思います。どういった使い道があるのかは、これからよく揉まれていくことでしょう。ウォッチしていきます。
▼追記
弊社しばたが使い所を考察したエントリを書きましたので、ぜひご参照ください。
以上、東京の千葉でした！
