Dockerボリュームをglusterfsに保存することは良い考えですか？
現在、一部のサーバーとアプリを coreOS 環境に移行することを検討しています。ここで私が見る問題の1つは、コンテナーを新しいマシンに移動するときにcoreOSがDockerボリュームを処理しないため、永続データの管理です。いくつかの調査の後、私は glusterFS を見つけました。これは、すべての問題を解決できるクラスタファイルシステムであると主張しています。
私の現在のアイデアはこれです：私は各coreOSマシンで特権コンテナーとして実行され、ストレージ、たとえば/mnt/glusterを公開するglusterFSコンテナーを持っています。私のDockerfilesでは、すべてのボリュームをこのパスにマウントするように指定しています。
次に検討したのは、どのコンテナーが独自のボリュームを取得するか、どのコンテナーがボリュームを共有するかです。たとえば、mysqlコンテナはそれ自体がレプリケーションを処理できるため、独自のボリュームを取得します。私はそれをいじりたくありません。同じWebサイトを提供するWebサーバーは、「ユーザーがアップロードした画像」などのデータを複製できないため、同じボリュームを適切に使用します。
誰かがこのようなことを試しましたか、それとも私が見逃したことがありますか？
CoreOSの代わりにAtomic（ http://www.projectatomic.io/ ）を使用した同様のセットアップを、3つのレプリカ2セットを持つ複製された非分散GlusterFSストレージシステムにデプロイしました。これは非常にうまく機能します。
ただし、GlusterFSのいくつかの特別な特性を覚えておく必要があります。ブライアンがすでに述べたように、Glusterは一貫性と信頼性を何よりも重視しています。変更が頻繁に発生するほど、より多くのレプリケーションが発生します。これは多くのことを意味します。つまり、システムに大きな負荷をかけます。
IOサブシステムが高速であることに注意してください（ストレージです））、Glusterノードを利用可能な最速のネットワーク接続に接続します。GBitのみがある場合は、集約してください！最後に、ストレージシステムは深刻な計算能力を発揮する必要があるため、Glusterはその状態をチェックするために多くの計算を実行します。
MySQL戦略を再検討します。 Glusterはレプリケーションを実行し、配信の一種の負荷分散も提供します。 Glusterを使用する方が実際には高速かもしれません。
Glusterfsの使用は、使用しているストレージバックエンドによって異なります。クラスタファイルシステムとしては、物理ストレージをクラスタ化して、1つの大きな連続したボリュームとして表示することを目的としています。この 公式のクイックスタートガイド は、プロセスを適切に説明しています。
セットアップで2つ以上の個別のバックエンドストレージサーバーなどを使用してすべてのDockerボリュームを格納する場合、glusterfsまたは他の類似の並列ファイルシステムを使用すると、パフォーマンスが大幅に向上する場合があります。これが当てはまる場合は、HPCコミュニティで並列ファイルシステムとして広く使用されている Lustre の使用を検討することもできます。
そうは言っても、並列/クラスターファイルシステムのチューニング、デバッグ、構成は、多くの専門知識、忍耐力、そして時には最初からやり直す意欲を必要とする時間のかかるタスクになる可能性があります。並列ファイルシステムが提供するパフォーマンス上の利点は、それをセットアップして維持するために必要な労力に見合う価値があることを確認するのが賢明です。