AWSのEBSについては単一のEC2にしかアタッチできないことが有名ですが、なんとEBSのマルチアタッチ機能が発表(クリックで開く)されました!!
複数のEC2インスタンスで共通のストレージを利用するにはEFSが既に存在していますが、EFSでは速度面でのパフォーマンスが問題になりがちです。
EC2インスタンスからGlusterFSやNFSでファイルサーバーを用意してマウントする方法も考えられますが、ファイルサーバー側の保守コストが気になりますね。
もしもEBSが複数のEC2インスタンスにマウントできるようになると、その辺りが一気に解決されそうです!
今回は新機能であるEBSマルチアタッチについて検証してみたので、最後まで読んでいただけますと幸いです。
※ 記事内の画像はクリックでズームされます。
見出し
検証手順
1, EC2インスタンスでマウント用のサーバーを2台用意する
2, マルチアタッチを有効にしたEBSを作成する
3, それぞれのEC2インスタンスでEBSをマウントする
4, 一方のEC2からファイルを編集して、もう一方で編集されたファイルを確認する
5, それぞれのEC2インスタンスから同じファイルを操作してみる
検証用のEC2インスタンスを用意する
事前に軽く調査した限りでは、同一のアベイラビリティゾーンでなければ共有のEBSをアタッチできないようです。
そこで今回はバージニアリージョンのAZ-aに2台のEC2インスタンスを作成しました。
※ ここではt2.nanoで作成していますが、後述する理由によりオススメしません。Nitro系のインスタンスを使いましょう。
マルチアタッチ対応のEBSを作成
マルチアタッチが対応したEBSを作成するためには、プロビジョンドIOPSのEBSをバージニア、オレゴン、アイルランド、ソウルいずれかのリージョンで作成します。
該当のリージョンから作成する場合には「Multi-Attach」という項目が追加されているため、これを有効にすればOKです。
作成したEBSのアタッチはコンソールから「ボリュームのアタッチ」を押して対象のインスタンスIDを選択すればOKです!
問題発生と注意点
コンソールからアタッチを実施しようとしたところ、エラーが発生してしまいました。
今回の調査で立てていたインスタンスがt2.nanoだったため、アタッチできなかったようです。
ドキュメントをよく読んでいなかったのですが、今回やろうとしているEBSのマルチアタッチはNitro(ナイトロ)システムのEC2インスタンスしか利用できないようです。
基本的に最新世代のインスタンスタイプを選んでいれば問題ないですが、該当のインスタンスはこちら(クリックで開く)からご確認ください。
ということで検証用のEC2インスタンスはt3.nanoに変更しました。
検証用のEC2からマウント
今回はAWSのコンソールからEBSをそれぞれの検証用EC2にアタッチしました。
EC2インスタンスにボリュームを追加したり増設したことがある人はご存知だと思いますが、コンソールからEBSをアタッチしただけではEC2インスタンス側で認識することはできません。
画像からdfコマンドを叩いてもマウントされていないことが分かると思います。
そこで下記のコマンドを実行します。
# 追加したEBSを認識させる
$ sudo mkfs -t xfs /dev/sdf
# 指定したパスに対してマウントを行う(今回は/mntにマウント)
$ sudo mount /dev/sdf /mnt
これで添付画像のように16GBのストレージがマウントされたことが確認できると思います。
/mntの権限ユーザーがrootでは不便なので、ついでにec2-userへchownしておきました。
このマウントを検証用の2つのサーバーでそれぞれ実行します。
1点だけ注意事項があり、他のサーバーがマルチアタッチ用のEBS内で作業していると、マウントに失敗してしまいます。
sshでマウント先のファイルパスに移動してるだけでも発生するので注意しましょう。
エラーメッセージ:
mkfs.xfs: /dev/sdf appears to contain an existing filesystem (xfs).
mkfs.xfs: Use the -f option to force overwrite.
サーバー1から試験的にファイルを作成
サーバー1にsshしている状態で「server1-test.txt」というテストファイルを作成しました。
・・・が、サーバー2からはなぜか参照できません。
sshし直す / 権限を変更してみる / ファイル名指定でcatしてみるなど試したのですが、サーバー1で作成したファイルを見ることはできませんでした。
サーバー2からの参照方法
流石に他にも方法があるだろうと高を括っていたのですが、今のところEBSをアンマウントしてマウントし直す以外に変更を読み込む手段が見つかっていません。
# EBSをアンマウント
$ sudo umount /mnt
# EBSをマウント
$ sudo mount /dev/sdf /mnt
もしもこれが仕様だとしたら、今回の機能は非常に用途が限られてしまいます。
時間があればAWSに同期方法を問い合わせてみたいと思います。
同時編集について
同期できないことに対しては一旦置いておいて、同じEBSに対してサーバー1とサーバー2で同時に編集したらどうなるのでしょうか。
例えば同じファイルを同時に編集した場合などのケースです。
実際にサーバー1がvimで「server1-test.txt」を開いている間に、サーバー2もvimで「server1-test.txt」を開くことができました。(同期しているわけでは無いので当たり前かもしれませんが・・。)
このようなケースでは、変更時間が新しい方が優先的に反映されるようです。
サーバー1でテストファイル内に「hogehoge1」と記入して保存。
数秒遅れてサーバー2でテストファイル内に「hogehoge2」と記入して保存。
この段階ではそれぞれのサーバーから見える内容は
サーバー1からは「hogehoge1」
サーバー2からは「hogehoge2」です。
その後、EBSをマウントし直すとどちらからみても「hogehoge2」に切り替わりました。
むしろEBS内の整合性を保つためにリアルタイムに同期されない仕様なのかもしれないですね・・・(要調査)
まとめると
・バージニア、オレゴン、アイルランド、ソウルのリージョンのみ対応
・プロビジョンドIOPSのEBSのみ対応
・Nitroのインスタンスのみマルチアタッチに対応
・最大で16台のインスタンスにアタッチ可能
・同一のAZである必要がある
・リアルタイムに同期されず、同期には何かしらのアクションが必要(今のところマウントし直すのみ判明)
・同時編集した場合には編集時間の新しいものが優先
終わりに
もしも今回の調査以上の進展がなかった場合には、EFSの代わりに使用することはできないことになります。
EFSは並列処理は得意ですが、単一スレッドでの処理は苦手なためgit cloneなどのコマンド実行に非常に時間がかかります。
今回のマルチアタッチEBSでこの辺りが解決できればと思っていたのですが想像していた機能ではなかったようです。
リリース直後の検証のため誤っている可能性もあると思いますが、しばらくは私の方でも情報を集めて検討してみようと思います。
皆さんもぜひ検証してみて、判明した仕様をQiitaなどであげて下さいね(笑)
コメントを残す