GlusterFSとWindowsでSPOFSを回避する
処理機能に使用するGlusterFSクラスターがあります。Windowsを統合したいのですが、GlusterFSボリュームを提供するSambaサーバーである単一障害点を回避する方法を理解するのに問題があります。 ファイルフローは次のように機能します。 ファイルはLinux処理ノードによって読み取られます。 ファイルが処理されます。 結果（小さくすることもかなり大きくなることもあります）は、完了時にGlusterFSボリュームに書き戻されます。 結果をデータベースに書き込むことも、さまざまなサイズのファイルをいくつか含めることもできます。 処理ノードは、キューおよびGOTO 1から別のジョブをピックアップします。 Glusterは分散ボリュームとインスタントレプリケーションを提供するので素晴らしいです。耐災害性がいいです！私たちはそれが好き。 ただし、WindowsにはネイティブのGlusterFSクライアントがないため、Windowsベースの処理ノードが同様に復元力のある方法でファイルストアと対話するための何らかの方法が必要です。GlusterFSドキュメント状態のWindowsへのアクセスを提供する方法がマウントされGlusterFSのボリュームの上にSambaサーバを設定することであること。これは、次のようなファイルフローになります。 それは私にとって単一障害点のように見えます。 1つのオプションはSambaをクラスター化することですが、現在は不安定なコードに基づいているため、実行されていません。 だから私は別の方法を探しています。 使用するデータの種類に関するいくつかの重要な詳細： 元のファイルサイズは、数KBから数十GBまでの範囲です。 処理されるファイルサイズは、数KBから1〜2 GBです。 .zipや.tarなどのアーカイブファイルを掘り下げるなどの特定のプロセスでは、含まれているファイルがファイルストアにインポートされるときに、さらに多くの書き込みが発生する可能性があります。 ファイル数は数千万に達する可能性があります。 このワークロードは、「静的ワークユニットサイズ」のHadoopセットアップでは機能しません。同様に、S3スタイルのオブジェクトストアを評価しましたが、不足していることがわかりました。 私たちのアプリケーションはRubyでカスタム作成されており、WindowsノードにCygwin環境があります。これは私たちを助けるかもしれません。 私が検討している1つのオプションは、GlusterFSボリュームがマウントされているサーバーのクラスター上の単純なHTTPサービスです。Glusterで実行しているのは基本的にGET / PUT操作だけなので、HTTPベースのファイル転送メソッドに簡単に転送できるようです。それらをロードバランサーペアの背後に配置すると、WindowsノードはHTTPでそれらの小さな青いハートのコンテンツにPUTできます。 私が知らないのは、GlusterFSの一貫性がどのように維持されるかです。HTTPプロキシレイヤーは、書き込みが完了したことを処理ノードが報告してから、実際にGlusterFSボリュームに表示されるまでの間に十分な待機時間を導入します。それを見つける。direct-io-mode=enablemount-option を使用すると効果があると確信していますが、それで十分かどうかはわかりません。一貫性を向上させるために他に何をすべきですか？ または、私は完全に別の方法を追求すべきですか？ トムが下で指摘したように、NFSは別のオプションです。だから私はテストを実行しました。上記のファイルには、保持する必要があるクライアント提供の名前があり、どの言語でも使用できるため、ファイル名を保持する必要があります。だから私はこれらのファイルでディレクトリを構築しました： NFSクライアントがインストールされているServer 2008 R2システムからマウントすると、次のようなディレクトリリストが表示されます。 明らかに、Unicodeは保持されていません。したがって、NFSは私にとってうまくいきません。