Amazon　Elastic　Block　Store

EBSマルチアタッチ機能について調べてみた

aws, ebs コメントを残す

こんにちは、ディーネットの山田です。

ファイルシステムの冗長化について調べており、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といった分散ファイルシステムを使ってみたいと思います

返信を残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA