こんにちは、ディーネットの山田です。
ファイルシステムの冗長化について調べており、EBS マルチアタッチ機能について気になったので調べてみました。
目次
EBSマルチアタッチ機能とは
1 つのプロビジョンド IOPS SSD (io1 または io2) ボリュームを、同じアベイラビリティーゾーンにある複数のインスタンスにアタッチできます。
複数のマルチアタッチが有効なボリュームを 1 つのインスタンスまたはインスタンスセットにアタッチできます。
ボリュームがアタッチされている各インスタンスには、共有ボリュームに対する完全な読み取りおよび書き込みアクセス許可があります。
マルチアタッチを使用すると、同時書き込みオペレーションを管理するクラスター化された Linux アプリケーションで、アプリケーションの可用性を高めることが容易になります。
と公式のユーザーガイドに記載されておりました。
要約すると
- プロビジョンドIOPS SSD (io1またはio2)が対象
- 同じアベイラビリティゾーン(AZ)にある複数のインスタンスにアタッチ可能
- アタッチされているインスタンスからは、完全な読み書きが許可
- 同時書き込みが制御されたLinuxアプリケーションの可用性を高めることが可能
検証の前に制約事項等も記載します。
考慮事項と制約事項
マルチアタッチが有効なボリュームは、同じアベイラビリティーゾーンにある Nitro Systemで構築された最大 16 の Linux インスタンスにアタッチできます。マルチアタッチが有効なボリュームを Windows インスタンスにアタッチできますが、インスタンス間で共有されているボリューム上のデータはオペレーティングシステムによって認識されません。これにより、データの不整合が生じる可能性があります。
マルチアタッチは、Provisioned IOPS SSD ボリューム でのみサポートされています。
io2 ボリューム用のマルチアタッチは、io2 ボリュームをサポートするすべてのリージョンで使用できます。io1 ボリュームのマルチアタッチは、us-east-1、us-west-2、eu-west-1、および ap-northeast-2 のリージョンでのみ使用できます。
マルチアタッチが有効なボリュームは、R5b インスタンスにアタッチできません。
XFS や EXT4 などの標準ファイルシステムは、EC2 インスタンスなどの複数のサーバーから同時にアクセスできるように設計されていません。標準ファイルシステムでマルチアタッチを使用すると、データの破損や損失を招く可能性があるため、本稼働状態のワークロードでは安全ではありません。クラスター化されたファイルシステムを使用することで、本稼働ワークロードのデータに対し復元性と信頼性を確保できるようになります。
マルチアタッチが有効なボリュームは I/O フェンスをサポートしていません。I/O フェンスプロトコルは、データの一貫性を維持するために、共有ストレージ環境での書き込みアクセスを制御します。アプリケーションは、データの整合性を維持するために、アタッチされたインスタンスの書き込み順序を提供する必要があります。
マルチアタッチが有効なボリュームは、ブートボリュームとして作成できません。
マルチアタッチ対応のボリュームは、インスタンスあたり 1 つのブロックデバイスマッピングにアタッチできます。
マルチアタッチは、Amazon EC2 コンソールまたは RunInstances API を使用してインスタンスの起動時に有効にすることはできません。
Amazon EBS インフラストラクチャレイヤーに問題があるマルチアタッチが有効なボリュームは、アタッチされているすべてのインスタンスで使用できません。Amazon EC2 またはネットワークレイヤーでの問題は、一部のアタッチされたインスタンスにのみ影響する可能性があります。
と公式のユーザーガイドに記載されておりました。
要約すると
- 同じアベイラビリティゾーン(AZ)にあるNitro Systemで構築された最大16個のLinuxインスタンスにアタッチ可能
- Windowsインスタンスにアタッチすることも可能ではるが、OSによって保存されているデータは認識されない
- io2のマルチアタッチはio2をサポートする全てのリージョンで利用可能だが、io1は、us-east-1, us-west-2, eu-west-1, ap-northeast-2に限定されるので、東京,大阪リージョンでは使えない
- R5bインスタンスにはアタッチできない
- Linuxで一般的な、XFSやEXT4などのファイルシステムは複数のサーバーから同時にアクセスできるように設計されていないため、クラスター環境に最適化されたファイルシステムを使う必要がある
- I/Oフェンスプロトコルはサポートしていないので、アプリケーション側で書き込み順序を制御する必要がある
- ブートボリュームとしては、作成できない
この制約事項等をまとめて見て思いましたが、EBSマルチアタッチ機能をEFSのようなファイルの共有方法としては使えないようです。
RedHat社が開発したGFS2や、オラクル社が開発したOCFS2といった分散ファイルシステムで使うことが前提の機能なようです。
EBSマルチアタッチ機能は、分散ファイルシステムがあってこそ本領を発揮できる機能なようですので、XFSやEXT4などといった標準ファイルシステムをブロックデバイスレベルで共有できる機能ではないということはしっかり理解する必要があります。
ここからは、XFSやEXT4などといった標準ファイルシステムで無理矢理EBSマルチアタッチ機能を使うとどうなってしまうのかという掟破りな検証をしてみます。
今後EBSマルチアタッチ機能の利用を検討されている方で、そういった使い方は出来なかったんだという理解に繋がれば幸いです。
ではやっていきます。
検証内容
事前準備
- 同じアベイラビリティゾーン(AZ)にEC2を2台構築しました。
- OSは、Amazon Linux 2を使用しました。
EBSボリュームをEC2インスタンスが存在するAZに1本作成
EC2にそれぞれアタッチ
EC2から見たEBSの状態
1台目のサーバからアタッチした8GBの領域が見えますね
[root@ip-10-10-10-19 ~]# fdisk -l
Disk /dev/nvme0n1: 8 GiB, 8589934592 bytes, 16777216 sectors
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: C52DB3B7-097C-4067-908A-ED8095F37B2E
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: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
/dev/nvme1n1がマルチアタッチ機能を有効にしたEBSです
2台目のサーバからでもアタッチした8GBの領域が見えますね
[root@ip-10-10-10-45 ~]# fdisk -l
Disk /dev/nvme0n1: 8 GiB, 8589934592 bytes, 16777216 sectors
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: C52DB3B7-097C-4067-908A-ED8095F37B2E
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: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
/dev/nvme1n1がマルチアタッチ機能を有効にしたEBSです
パーティションを作ってみる
競合を起こす可能性があるためから1台目でパーティションを作る
[root@ip-10-10-10-19 ~]# fdisk /dev/nvme1n1
Welcome to fdisk (util-linux 2.30.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x72f7c2d2.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-16777215, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-16777215, default 16777215):
Created a new partition 1 of type 'Linux' and of size 8 GiB.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
/dev/nvme1n1に対してパーティションを1つ作成しています
1台目のサーバからパーティションが見えますね
[root@ip-10-10-10-19 ~]# fdisk -l
Disk /dev/nvme0n1: 8 GiB, 8589934592 bytes, 16777216 sectors
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: C52DB3B7-097C-4067-908A-ED8095F37B2E
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: 8 GiB, 8589934592 bytes, 16777216 sectors
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: dos
Disk identifier: 0x72f7c2d2
Device Boot Start End Sectors Size Id Type
/dev/nvme1n1p1 2048 16777215 16775168 8G 83 Linux
/dev/nvme1n1の中に/dev/nvme1n1p1のパーティションが作成されました
2台目のサーバからでもパーティションが見えますね
[root@ip-10-10-10-45 ~]# fdisk -l
Disk /dev/nvme0n1: 8 GiB, 8589934592 bytes, 16777216 sectors
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: C52DB3B7-097C-4067-908A-ED8095F37B2E
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: 8 GiB, 8589934592 bytes, 16777216 sectors
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: dos
Disk identifier: 0x72f7c2d2
Device Boot Start End Sectors Size Id Type
/dev/nvme1n1p1 2048 16777215 16775168 8G 83 Linux
/dev/nvme1n1の中に/dev/nvme1n1p1のパーティションが作成されました
XFSでフォーマットする
競合を起こす可能性があるためから1台目でXFSフォーマットしてみる
[root@ip-10-10-10-19 ~]# mkfs.xfs /dev/nvme1n1p1
meta-data=/dev/nvme1n1p1 isize=512 agcount=4, agsize=524224 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=0
data = bsize=4096 blocks=2096896, 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
XFSでフォーマットできました
ブロックデバイスの認識を確認してみる
1台目からの認識状態
[root@ip-10-10-10-19 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 8G 0 disk
├─nvme0n1p1 259:2 0 8G 0 part /
└─nvme0n1p128 259:3 0 1M 0 part
nvme1n1 259:1 0 8G 0 disk
└─nvme1n1p1 259:5 0 8G 0 part
2台目からの認識状態
[root@ip-10-10-10-45 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:0 0 8G 0 disk
nvme0n1 259:2 0 8G 0 disk
├─nvme0n1p1 259:3 0 8G 0 part /
└─nvme0n1p128 259:4 0 1M 0 part
2台目でnvme1n1p1のパーティションが認識されていないので再起動してみる
[root@ip-10-10-10-45 ~]# reboot
再起動後の2台目からの認識状態
[root@ip-10-10-10-45 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:0 0 8G 0 disk
└─nvme1n1p1 259:1 0 8G 0 part
nvme0n1 259:2 0 8G 0 disk
├─nvme0n1p1 259:3 0 8G 0 part /
└─nvme0n1p128 259:4 0 1M 0 part
nvme1n1p1が認識されました
1台目と2台目でマウントポイントを作成してみる
[root@ip-10-10-10-19 ~]# mkdir /data
[root@ip-10-10-10-45 ~]# mkdir /data
マウントコマンドでマウントしてみる
[root@ip-10-10-10-19 ~]# mount /dev/nvme1n1p1 /data
[root@ip-10-10-10-45 ~]# mount /dev/nvme1n1p1 /data
一応マウントされました
[root@ip-10-10-10-19 ~]# df -h /data
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1p1 8.0G 41M 8.0G 1% /data
[root@ip-10-10-10-45 ~]# df -h /data
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1p1 8.0G 41M 8.0G 1% /data
1台目と2台目でそれぞれファイルを作ってみる
[root@ip-10-10-10-19 ~]# echo "denet tech blog `date`" > /data/test1.txt
[root@ip-10-10-10-19 ~]# ls -la /data
total 4
drwxr-xr-x 2 root root 23 Aug 20 13:42 .
dr-xr-xr-x 19 root root 269 Aug 20 09:15 ..
-rw-r--r-- 1 root root 45 Aug 20 13:42 test1.txt
[root@ip-10-10-10-45 ~]# echo "denet tech blog `date`" > /data/test2.txt
ファイルの状態を見てみる
[root@ip-10-10-10-45 ~]# ls -la /data
total 4
drwxr-xr-x 2 root root 23 Aug 20 13:42 .
dr-xr-xr-x 19 root root 269 Aug 20 09:15 ..
-rw-r--r-- 1 root root 45 Aug 20 13:42 test2.txt
2台目から見たときに、1台目で作成したファイルは見えないですね
[root@ip-10-10-10-19 ~]# ls -la /data
total 4
drwxr-xr-x 2 root root 23 Aug 20 13:42 .
dr-xr-xr-x 19 root root 269 Aug 20 09:15 ..
-rw-r--r-- 1 root root 45 Aug 20 13:42 test1.txt
1台目から2台目で作成したファイルは見えないですね
1度それぞれで再マウントしてみます
[root@ip-10-10-10-19 ~]# umount /data
[root@ip-10-10-10-19 ~]# mount /dev/nvme1n1p1 /data
[root@ip-10-10-10-19 ~]# ls -la /data
total 4
drwxr-xr-x 2 root root 23 Aug 20 13:42 .
dr-xr-xr-x 19 root root 269 Aug 20 09:15 ..
-rw-r--r-- 1 root root 45 Aug 20 13:42 test2.txt
[root@ip-10-10-10-45 ~]# umount /data
[root@ip-10-10-10-45 ~]# mount /dev/nvme1n1p1 /data
[root@ip-10-10-10-45 ~]# ls -la /data
total 4
drwxr-xr-x 2 root root 23 Aug 20 13:42 .
dr-xr-xr-x 19 root root 269 Aug 20 09:15 ..
-rw-r--r-- 1 root root 45 Aug 20 13:42 test2.txt
なんということでしょう!!
1台目で作成したファイルが行方不明になりました(というか不整合起きたんでしょうね、はい)
わかったことのまとめ
- EBSマルチアタッチ機能で作成したXFSファイルシステムは、EFSのようには使えない!!
- 仮にマウントまで出来たとしても、ファイルが破損する
備考
- 機会があれば、RedHat社が開発したGFS2や、オラクル社が開発したOCFS2といった分散ファイルシステムを使ってみたいと思います
![](https://blog.denet.co.jp/wp-content/uploads/2023/09/20230929_yamada_profile.png)
プロフィール
テクニカルサポートは卒業して、フロントサイドでお客様環境の構築をさせていただいております。
たまに、テクニカルサポートでご対応させていただくことがあるかもしれませんが、その際はよろしくお願いいたします。
インフラ系のエンジニアですが、時々休日プログラマー(Python、PHP)をやっております。
LINK
クラウドベリージャム:プロフィールページ