水平方向にスケーリングするWebサーバー間でファイルアップロードディレクトリを共有する最良の方法


9

私は現在、下のカラフルな図のような、ドルーパルベースのウェブアプリ用に水平方向にスケーラブルなクラスターを仕様化しようとしています。

ロードバランサーはスティッキーセッションを実装しているため、ユーザーは、作業するサーバーが割り当てられると状態を維持します。

各アプリサーバーには次のものがあります。

  • 正面のニス
  • ランプスタックで実行されている真ん中のdrupal 6
  • 後ろにmemcached

2つのmysqlデータベースサーバーは共有IP上にあり、DRBDとハートビートを備えたHAクラスター内にあるため、1つが失われてもプラットフォーム全体がダウンすることはありません。

ここに画像の説明を入力してください

次の点について、ご意見をいただければ幸いです。

ファイルストレージを水平方向に拡張するにはどうすればよいですか?

NFSを使用して各アプリサーバーに共有ファイルディレクトリをマウントすることを考えているので、一度にアップロードされたファイルをすべてのアプリサーバーで利用できます。私はNFSを考えています。それは古くからあるからです。また、MogileFSやGlusterFSの経験はありません。NFSは以前に使用したことがあるので、より慣れています。

この方法でNFSを介してディレクトリを共有するのが賢明なサーバーの数を算出するために従うべきガイドラインはありますか?

ここで共有ファイルストレージにHAをどのように提供する必要がありますか?

ここでの1つの問題は、NFSサーバーが単一障害点であることです。

私たちはすでにMysqlサーバーでハートビートとDRBDを使用しており、スタックに含まれるテクノロジの数をできるだけ少なくしたいのですが、ファイルに同じHA戦略を使用した場合、どのような落とし穴がありますかサーバーも?

代替アプローチ

これは、内部向けのサイトであり、内部のイニシアチブがオンになっているときに、限られた数のユーザーが時々非常に集中的に短期間使用する場合があります。したがって、これは一部のスタートアップのように無限に拡張する必要はありません。

とすれば

  • 予想できるトラフィックには上限があります
  • HAをファイルサーバーに追加し、このように水平方向にスケーリングするようにセットアップを設計すると、かなり複雑になります。

また、2台のWebサーバーを強化して、2台のWebサーバー間のピーク負荷を処理し、cronジョブで2台のサーバーにユニゾンまたはrsyncを設定することを検討しています。

  • それらのファイルはまだ同期しています(スティッキーセッションは、ファイルをアップロードしたのと同じサーバー上のユーザーを維持します)
  • 1つを失うと、サイトはまだ稼働しています。

これは、NFS / DRBD HAの複雑な頭痛を回避するための可能な方法のように聞こえますか?

おかげで、

C

回答:


3

NFSサーバーは、基本的に同じ機能と制限を持っているため(両方ともデータを書き込む場所です)、少なくともMySQLサーバーと同じプロビジョニングが必要です。NFSへの複数のライターのアイデアは好きではありません。ファイルロックの管理が非常に複雑になり、その点で私の経験はあまりうまくいきませんでした。

私の提案は、すべての書き込みを1つのアプリサーバー(NFSサーバーへの書き込み専用のアプリサーバーが1つある可能性があります)と、それを読み取り専用でマウントする複数のリーダーアプリサーバーに集中することです(私はdrupalに必要な動的サムネイルがいくつかあることを知っています)書きますが、RO fsにそのほとんどを保持できます)。HAを確保するには、少なくとも2台目のNFSサーバーが必要です(SANのような共有ストレージがない場合は、DRBDを使用するのが最適です)。

最後に、Glusterと他の分散システムを見てください。



0

最良の方法は、優れたストレージソリューションを見つけることです。アプリケーションの規模とタイプに応じて、NFSと少なくとも2つのギガビットポートと電源をサポートする優れたNASを使用できます(一部のエンタープライズソリューションを確認してください)。

アプリケーションに真剣に取り組んでいる場合は、いくつかのSANソリューションを確認することをお勧めしますが、特別なハードウェアを必要とするため、非常に高価になる可能性があります(既製のハードウェアで実行できますが、速度が遅すぎる可能性があります)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.