GlusterFSとWindowsでSPOFSを回避する
処理機能に使用するGlusterFSクラスターがあります。 Windowsを統合したいのですが、GlusterFSボリュームを提供するSambaサーバーである単一障害点を回避する方法を理解するのに問題があります。
ファイルフローは次のように機能します。
- ファイルはLinux処理ノードによって読み取られます。
- ファイルが処理されます。
- 結果（小さくすることも、かなり大きくすることもできます）は、完了時にGlusterFSボリュームに書き戻されます。
- 結果をデータベースに書き込むことも、さまざまなサイズのファイルをいくつか含めることもできます。
- 処理ノードはキューから別のジョブをピックアップし、GOTO 1を実行します。
Glusterは分散ボリュームとインスタントレプリケーションを提供するので素晴らしいです。災害耐性はいいです！私たちはそれが好き。
ただし、WindowsにはネイティブのGlusterFSクライアントがないため、Windowsベースの処理ノードが同様に復元力のある方法でファイルストアと対話するための何らかの方法が必要です。 GlusterFSのドキュメントに記載 Windowsアクセスを提供する方法は、マウントされたGlusterFSボリュームの上にSambaサーバーをセットアップすることです。これは次のようなファイルフローにつながります。
それは私にとって単一障害点のように見えます。
1つのオプションは cluster 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=enableマウントオプションが役立ちますしかし、それで十分かどうかはわかりません。一貫性を向上させるために他に何をすべきですか？
または、私は完全に別の方法を追求すべきですか？
トムが下で指摘したように、NFSは別のオプションです。だから私はテストを実行しました。上記のファイルには保持する必要があるクライアント提供の名前があり、どの言語でも使用できるため、ファイル名を保持する必要があります。だから私はこれらのファイルでディレクトリを構築しました：
NFSクライアントがインストールされているServer 2008 R2システムからマウントすると、次のようなディレクトリリストが表示されます。
明らかに、Unicodeは保持されていません。したがって、NFSは私にとってはうまくいきません。
GlusterFSが好きです。実際、私はGlusterFSが大好きです。専用の帯域幅を提供できる限り、すべて問題ありません。
GlusterFSの最も優れた点の1つは、NFSで使用することです。私が最近取り組んできた驚くべきことの1つは Windows 7および2k8R2のNFS です。
これが私がすることです。
- NFSをエクスポートできる2つのGlusterFSサーバーをセットアップします。
- それらの間にハートビートリンクを設定します。
- おそらくハートビート/ペースメーカーのようなものを展開しますか？
- Glusterノード間に仮想IP（VIP）をセットアップします。
- VIPのIPアドレスを使用して、Windows boxenのマップされたネットワークドライブを接続します。
- 想像できるすべてのものをテストしてください。
Sambaのクラスタリングは恐ろしいように聞こえますが、それを行ったとしても、Sambaは一部のWindowsネットワークで信頼性のある動作を行う機能をまだ備えていません（NT4ドメインの互換性はすべて、それを超えることができないようです）。
Ithink各glusterノードは分散、複製モードであるため、理論的にはどちらにも接続できるはずですそして、データの移動を心配することができます。結果として、ハートビートはリダイレクトを実行し、話しているものを制御するものでなければなりません。
あなたの
- ファイル数は数千万に達する可能性があります。
XFSを基礎となるファイルシステムとして使用することを検討することをお勧めします。これは、大きなファイルシステムではかなり良いことであり、 GlusterFSでサポートされています
たぶん、HAソリューションで考えることができます...認証にLDAPを使用し（必要なだけLDAPサーバーを複製できます）、IPを配置してSMBサービスをリッスンします。
このIPはメインサーバーにフロートします。これがダウンすると、Heartbeatは2番目のサーバーでサービスを開始できます。
このサーバーにはglusterfsへのマウントポイントがあり、すべてのデータがそこにあります。
それは可能な解決策であり、管理がとても簡単です...