web-dev-qa-db-ja.com

HA-Proxyを使用したWindowsファイル共有の負荷分散

DFSを介して髪を引っ張った後、この奇妙で潜在的に危険なアイデアが頭に浮かびました。それにより、おそらく、HA-Proxyを使用してサーバー間のファイル共有の負荷を分散できる可能性があります。

私はいくつかの修復パケットトレースを実行しましたが、TCPポート445がWindowsファイル共有の使用に関係する唯一のものであるように見えます。私は長年、UDP 139、135などを常に考えてきました。少なくとも接続の確立にも関与していましたが、明らかにそうではありませんでした。

だから私は基本的なテストを設定します：

listen SMBTest *:445
  mode tcp
  server Smb1 172.16.61.201:445
  server Smb2 172.16.61.202:445

そして、あなたは何を推測することは決してないでしょう...それはうまくいきますか？ （！）

今では明らかに、ファイルサーバー間の同期に関する全体的な懸念があります（もちろん）。これは、Robocopyスクリプトを少し使用するだけで簡単に処理できます。

また、HAの読み取り専用ファイル共有のみが必要であることを考えると、ファイルロックなどに関して問題はありません。

  • 私がここで遊んでいるのが火であるかどうか誰かに教えてもらえますか？まったくうまくいかないと思っていたので、少しショックを受けました。
  • 欠点は何ですか？
  • これは、実稼働環境で信頼できますか？
sambaload-balancingfile-sharinghaproxyserver-message-block
5
nbevans

ファイル複製は、最初に想像するよりもはるかに難しい問題です。

通常、ファイルレプリケーションは適切に拡張できません。処理するファイルの数が50万以上になると、問題が発生し始めます。コピーは同期にかかる時間よりも時間がかかるため、セッションを長期間スティッキーにして、セッションを減らす必要があります。コピーの間隔またはコピーするファイルの数を減らします。

あなたの特定のワークロードについて私が知っている少しから、これはまだあなたにとって大丈夫かもしれません。ファイル共有は読み取り専用であるとのことで、大量のデータを更新していると思われます。これらの状況ではRobocopyは遅いかもしれませんが、変更の間隔が非常に長いため、これは許容できるリスクである可能性があります。

このセットアップでは、HAProxyがレイヤー4ロードバランサーに比較インテリジェンスを提供するため、レイヤー4ロードバランサーを使用すると、通常、高負荷でより少ないレイテンシでより多くのスループットを処理できるため、より有益な場合があります。それはあなたの問題には当てはまらないかもしれませんが、思考の糧です。

機能とパフォーマンス（厳密に同期する必要があるr/w共有など）が必要な場合、これは機能しません。将来このデータセットでこれが必要になると思われる場合は、データセットのサイズがテラバイトになる可能性があり、データセットをスクラップして再アップロードしなければならない状況になりたくないため、ソリューションを慎重に検討してください。新しいソリューション。

2
Matthew Ife