複数の AWS インスタンス間で、高パフォーマンスかつ低レイテンシの方法でデータを共有したいと考えています。すべてのインスタンスに読み取り専用アクセス (書き込みを処理する 1 つのインスタンスを除く) を与えることは問題ありません。このユースケースに関する 2 つのポイント:
- ボリュームに接続されたノードはいつでも追加または削除される可能性があります (開始、停止、終了など)。
- 共有データには、リスト化してメタデータをチェックする必要がある、潜在的に小さなファイルが何千個も含まれています。
そこで、最初は EFS を試してみましたが、数百または数千の小さなファイルを列挙または変更する必要がある操作では、かなり遅くなります。
そこで、EBS マルチアタッチを検討しています。ただし、データ破損を防ぐために、AWS では GFS2 や OCFS などのクラスター化されたファイルシステムのみの使用を推奨しています。これらはどちらも設定が複雑で扱いにくいようで、ノードがいつでも追加または削除される可能性があるクラスターのユースケースには脆弱です。たとえば、GFS2 では、ノード数が 2 を超える場合、すべてのノードのクラスター ソフトウェアを再起動する必要があります。また、新しいノードを追加するには、現在のノードにログインし、いくつかのコマンドを実行し、更新された構成ファイルを他のすべてのノードに再配布する必要があります。これは非常に柔軟性に欠け、余分なオーバーヘッドもかなりあるようです。
しかし、ディスクへの書き込みを行うインスタンスが 1 つだけであることが確実な場合 (または、各インスタンスが独自のサブフォルダーまたはディスク パーティションにのみ書き込むことができる場合)、このボリュームに XFS などの通常のファイル システムを使用しても問題ありませんか? または、アクセスが技術的に読み取り専用であったり、書き込みアクセスがインスタンス固有のサブフォルダーまたはパーティションに制限されている場合でも、微妙なデータ破損の問題が発生するでしょうか?
それとも、私が見逃しているまったく別の解決策があるのでしょうか?
答え1
私はこれ(XFS)をテストしましたが、動作しません。クラスタ化されたファイル システムが必要です。クラスタ化されたファイル システムを使用するのが最善策です。Veritas Infoscale などの他のオプションも検討してください。
答え2
静的ボリューム コンテンツの共有は、マルチアタッチと通常の XFS で問題なく機能するようです。ボリュームへのホット「追加」は、データを書き込んだインスタンスにのみ表示されます。これが確立されたため、ホット「更新」または「削除」はテストしませんでした。これらも作成者のみに表示されるが、他のインスタンスからそのデータへのアクセスが失われる可能性があると想定したためです。再起動、再始動、および/または再接続されたインスタンスは、最新のボリューム状態を表示します。したがって、1 つのインスタンスが新しいデータをまれに書き込むことで、強制的に再起動し、最終的に他のインスタンスがそのデータを表示するというユース ケースは、このテクノロジがサポートする可能性があるユース ケースであると思われます。