Dockerボリュームをglusterfsに保存することをお勧めしますか？

現在、サーバーとアプリの一部をcoreOS環境に移行することを考えています。ここで見た問題の1つは、コンテナーを新しいマシンに移動するときにcoreOSがDockerボリュームを処理しないため、永続データの管理です。いくつかの調査の後、glusterFSを見つけました。これは、すべての問題を解決できるクラスターファイルシステムであると主張しています。

私の現在のアイデアは次のとおり/mnt/glusterです。たとえば、各coreOSマシンで特権コンテナーとして実行され、ストレージを公開するglusterFSコンテナーがあります。私の中でDockerfileの私はすべてのボリュームがこのパスにマウントする必要があることを指定します。

次に検討したのは、どのコンテナが独自のボリュームを取得し、どのコンテナがボリュームを共有するかです。たとえば、すべてのmysqlコンテナは複製を自分で処理できるため、独自のボリュームを取得します。それをいじりたくありません。同じWebサイトにサービスを提供するWebサーバーは、「ユーザーがアップロードした画像」などのデータにデータを複製できないため、同じボリュームを適切に使用します。

誰かがこのようなことを試しましたか、私が見逃したものはありますか？

CoreOSの代わりにAtomic（http://www.projectatomic.io/）と同様のセットアップを、3つのレプリカ2セットを持つ複製された非分散GlusterFSストレージシステムに展開しました。これは非常にうまく機能します。

ただし、GlusterFSのいくつかの特別な特性に留意する必要があります。既に述べたブライアンのように、Glusterは何よりも一貫性と信頼性を重視しています。より頻繁に変更が行われるほど、より多くの複製が行われます。これは多くのことを意味しますが、私はあなたのシステムに多大な圧力をかけています。

IOサブシステムが高速であることに注意して（ストレージであるため）、Glusterノードを利用可能な最速のネットワーク接続で接続します。GBitのみがある場合は、集計してください！最後に重要なことですが、ストレージシステムは深刻な計算能力を発揮する必要があり、Glusterはその状態を確認するために多くの計算を行います。そうは言っても、Glusterは高負荷でも配信します。

MySQL戦略を再考してください。Glusterはユーザーに代わってレプリケーションを実行し、配信時に一種の負荷分散を提供します。実際には、Glusterを使用する方が速い場合があります。

glusterfsの使用は、使用しているストレージバックエンドに依存します。クラスターファイルシステムとして、物理ストレージをクラスター化して、1つの大きな連続ボリュームとして表示することを目的としています。この公式クイックスタートガイドには、プロセスの説明があります。

セットアップで2つ以上の個別のバックエンドストレージサーバーまたはすべてのDockerボリュームを保存する類似のものを使用する場合、glusterfsまたは他の類似の並列ファイルシステムを使用すると、パフォーマンスが大幅に向上します。この場合、HPCコミュニティで並列ファイルシステムとして広く使用されているLustreの使用を検討することもできます。

そうは言っても、並列/クラスターファイルシステムのチューニング、デバッグ、および構成は、多くの専門知識、忍耐、時には最初から再起動する意欲を必要とする時間のかかるタスクです。並列ファイルシステムが提供するパフォーマンス上の利点は、それをセットアップして維持するのに必要な労力に見合うだけの価値があることを確認するのが賢明でしょう。