帯域幅を均等に分散するために、複数の静的ファイルサーバー間で負荷を分散する最良の方法は?


12

まず、私の状況を説明します。私はかなり人気のあるWebサイトをサイドプロジェクトとして運営しているため、大量のお金を投資することはできません。現在、Apacheに通常のリクエストを送信し、Lighttpdにすべての静的ファイルリクエストを送信するHAProxyを備えたサーバーが1台しかありません。すべてのphpおよびpostリクエストはApacheによって処理されるため、これは非常にうまく機能しますが、すべての画像はより高速なLighttpdに送信されます(サイトはほとんど画像なので、これは非常に重要です)。短いURLも非常に重要であるため、画像を提供するためにサブドメインを設定する必要がないのは良いことです。したがって、HAProxyを使用する私の理由です。

私が使用している非常に安価な未測定の帯域幅を提供するホスティングプロバイダーを見つけました.100mbsのネットワークカードが処理できる帯域幅を押し出すと問題が発生します。したがって、2台目のサーバーが必要です。

私は私のオプションに多くの考えを入れましたので、それぞれについて説明します。どれが私にとって最良の選択肢であるかについての洞察を提供できれば幸いです。あるいは、まだ考えていない別の選択肢があるかもしれません。

要件:

  • 帯域幅の分配も必須です。私は非常に強力なサーバーを持っているので、スケールアップはオプションではありません。帯域幅を増やすためにスケールアウトする必要があります。

  • 短いURL。画像を提供するためにimg.example.comのようなサブドメインを設定することは本当にありません。example.com/image.jpgは現在の状態であり、どのようにそれを維持したいのかです。しかし、他に方法がなければ、私は理解しています。

  • 要求を処理するclostestサーバーは本当に便利ですが、必須ではありません。心に留めておくべきこと。

負荷分散するHAProxy:

  • とにかくHAProxyを既に使用しているので、それは本当に簡単です。ただし、帯域幅を分配するときに問題が発生すると思います。私はこれで間違っているかもしれませんが、HAProxyはリクエストをサーバーに送信し、そこでサーバーはそれを処理し、HAProxyを介してクライアントに送り返しますか?したがって、すべてのトラフィックはロードバランサーを経由して戻り、すべてのサーバーを合わせた帯域幅を使用します。

DNSラウンドロビン:

  • これが私の最良の選択肢かもしれません。Webサイトを複数のサーバーに複製し、私が今していることを行うだけです。マイナス面は、1つのサーバーがダウンしても、クライアントがサーバーに送信されることです。また、複数のサーバーにサイトを複製する必要があります。私は、静的ファイルを除くすべてを処理する1つのメインサーバーがあり、その後にいくつかの静的ファイルサーバーがあることを望んでいました。また、これは一種の「貧乏人の負荷分散」であり、もう少し洗練されたものがあればいいと読みました。

ダイレクトサーバーリターン:

  • それは本当に複雑に思えますが、良い選択肢かもしれません。特定のURLを特定のサーバーに送信することはできますか?現在HAProxyと同様に、正しいファイル拡張子で終わるすべてのURLはLighttpdに送信され、他の拡張子はApacheに送信されます。だから私は似たようなものが必要だろう。同様に、すべてのphp要求は、バランシングソフトウェアを実行している同じサーバーによって処理されますが、すべてのjpg要求は複数のサーバーに送信されます。

理想的には、HAProxyがDirect Server Returnをサポートしていれば、私の問題は解決するでしょう。また、CDNを使用したくありません。それらは本当に高価であり、結局のところ、これは単なる副プロジェクトです。

私の問題を理解していますか?正しく説明しなかった場合や、さらに情報が必要な場合はお知らせください。


1
これはImgurで、最近4000万ドルを調達しました。:O
L1th1um 14

回答:


3

アプリケーションの要求/応答サイクルの図を描き、ボトルネックを特定します。単一のプロキシが負荷を多くのアプリケーションサーバーに分散するには、すべてのアプリケーションサーバーの帯域幅の合計が必要になることは正しいです。従来のソリューションはRR DNSです。Google、Yahoo、およびAmazonはすべて、この手法を短いTTLで使用しています。私はしばらく前にいくつかの調査を行い、私の発見文書化しました

もう1つのソリューションは、仮想IPアドレスを使用した派手なエンタープライズ負荷分散ソリューションを使用して、実際のIPアドレスを持つ複数のアプリケーションサーバー間で要求のバランスを取ることです。私はNetscalerおよびStonesoft製品を扱ってきました。どちらもうまく機能しますが、ひどい特異性があり、非常に複雑です。


どうもありがとうございました。あなたの調査結果はとても役に立ちました。これが最終的に解決策になると思います。ただし、「優秀な研究者のように、十分なデータを取得するまで行動しません。」:)
アラン

洞察力をありがとう。残念ながら、皮肉なことに、調査結果へのリンクはダウンしているようですが、修正できますか?
TCB13

3

いくつかの答え:

  • はい。HTTPレベルのプロキシとして機能するため、すべてのトラフィックはHAProxyを通過します。これは、複数のバックエンドサーバーの負荷分散を行う別のサーバーにHAProxyがインストールされている場合でも同じです。したがって、ホスティングプロバイダーが100MBitのネットワークポートのみを提供し、すでに100MBitをプッシュしている場合、問題が発生します。
  • ドメインに関しては、Webアプリケーションとは異なるドメインの画像を提供するのが最適です。サブドメインではなく、別のドメインの画像を提供し、画像リクエストでCookieが送信されないようにします。参照してくださいスティーブ・ソーダーズオリジナル作品、またはスタックオーバーフローにここに実装します。短いURLが非常に重要な場合は、webappをメインURLから移動する、つまり、ファイル管理アプリケーションをlogin.sitename.comに移動するのが最良の方法かもしれません。

画像リクエストで認証が必要ですか?そうでない場合は、Amazon S3のようなものを使用してはどうですか?それは非常にスケーラブルであり、データ転送コストはかなり安いです。この場合、Amazon S3バケットのホスト名のDNS CNAMEとしてi.sitename.comのようなものを使用します。Amazonsのドキュメントを参照してください。知る限り、CNAMEとしてルートドメイン名(sitename.com)を使用することはできません。そのため、i.sitename.comのようなサブドメインを使用する必要があります。

複数のサーバー間で画像をハッシュすることもできます。つまり、login.sitename.comやa.sitename.comなどのDNS構造を作成します。b.sitename.com; c.sitename.comなど。「a。」および「b」etcサーバーには、画像を含むファイルシステムと軽量のHTTPサーバーが含まれています(Lighttpdを既に使用しているので、引き続き使用します。今後のプロジェクトでは、nginxをより良い代替として検討することを提案します。)画像の場合、一意の識別子、おそらくはユーザー名、おそらくはファイル名、または複数の識別子の組み合わせのハッシュを作成します。このハッシュから、イメージを保存するサーバーを決定します。

編集ハッシュについてはすでに説明したはずです。基本的に、ここで提案しているのは、ホスト名でもハッシュを使用して、ネットワークトラフィックを複数のホストに均等に分散することです。

これがどれほど安く必要なのかはわかりませんが、100MBitのネットワークトラフィックをプッシュしている場合、「安くて良い」というのはすぐに幻想になります。たぶん、最初に良いビジネスモデルを取得することを検討する必要があります。これは、継続的な収益を提供し、その後適切なテクノロジーを実装するものです。


1

HAProxyは他のアプリケーションと同じサーバー上にあると思いますか?HAProxyを別のシステムに分割してリクエストを実行し、1つのサーバーに通常のリクエストを送信し、別のサーバーにイメージリクエストを送信することができます。これらの問題は、すべての要求がまだ1つのボックスに送られることであり、帯域幅が飽和している場合、それはあまり役に立ちません。

あなたは短いURLが重要だと言います。どうして?画像を「example.com」から「i.example.com」に切り替えるのは本当に大したことですか?Lighttpdを使用して独自のサーバーの独自のIPに「i」を設定し、HAProxyを完全にバイパスして、スループットの問題を解決できます。また、リクエストが異なるドメイン名であると見なし、より多くの同時接続を開くことができるため、一度に多くのリクエストを開くことができるWebブラウザの利点も得られます。単一の「i」サーバーが飽和状態になった場合、DNSラウンドロビンを使用して別のサーバーを追加できます。その時までに、より良いソリューションを実装するのに十分な収益が得られることを願っています。


はい、HAProxyは同じサーバー上にあります。これまでのところ1つしかありません。上記で説明したように、別のサーバーに分割したとしても、HAProxyを使用してすべてのデータがサーバーを通過するわけではありませんか?ショートURLは、サイトの目的の一種であるため重要です。ImageShackとTinyPicのクロスオーバーです。URLが長いほど、サイトのポイントが少なくなります。しかし、私が言ったように、唯一の実行可能なオプションがサブドメインのセットアップである場合、私はそれをしなければなりません。私は本当にしたくないのですが。
アラン

1

ホスティングプロバイダーは負荷分散サービスを提供していますか?最善の解決策だと思います。

それを行う別の方法ですが、テストする必要があるのは、リクエストを(軽やかに)書き直すことです。例:example.com/file.htmlはapacheに残り、example.com / image.jpgはi.example.com/image.jpgにリダイレクトします。すべてのリクエストはApacheで管理されますが、応答(上流の帯域幅)はlighttpdサーバーに送られます。ドメインはユーザーに対して透過的です。それでも、Apacheがすべての要求を処理できるかどうかをテストするか、おそらくlighttpdにこのジョブを実行させる必要があります。

すべてのデータがHAProxyを通過するのは正しいので、(私が知る限り)それを使用して直接サーバーに戻ることはできません。

更新

HAproxyのドキュメントを見ると、「redir」パラメーターが見つかりました。apache rewriteのように機能するかどうかはわかりませんが、役に立つ可能性があります。ドキュメントには次のように書かれています:

主な用途は、クライアントを直接接続して静的サーバーの帯域幅を増やすことです。

たぶんそれはあなたの場合に機能します。


ねえ、応答に感謝します。実際にこれを試しましたが、実際には理論上はうまくいきません。その理由は、Apacheがすべてのリクエストを処理するため、ユーザーが画像にヒットするたびに、Apacheが生成され、URLを確認して、それを簡単に送信します。そもそも、Apacheが最初にイメージを処理するようになっているのと同じです。ホストが提供するロードバランサーが最適な選択肢であることに同意しますが、これは最も高価なものの1つでもあります。同時接続ごとに課金され、私は数百を取得します。
アラン

軽量サーバーが、自分の帯域幅を消費するクライアントに直接応答を送信する方法が異なります。問題は、Apacheサーバーが多くのリクエストを処理することです。私の答えの更新を確認して、別の解決策を見つけました。
hdanniel

1

サイズの大きな画像セットでは、名前の競合がすぐに発生するため、元のファイル名に基づいて画像を保存していないと想定しています。

これらのタイプの問題に対処する多くのアプリケーションは、ファイルのハッシュとそのハッシュに基づくディレクトリ構造を使用します。ディレクトリ構造は次のようになります。ディレクトリパスはハッシュの最初の2文字で、2番目のレベルのディレクトリはハッシュの次の2文字です。

/image root/AA/AA/images  
/image root/AA/AB/images

ここでの利点は、ハッシュがファイルの配布を均一に保ち、複数のサーバーに簡単に分割できる名前空間を提供することです。基本的には、さまざまなサーバーからハッシュスペースの一部を提供し、スケーリングするときに必要に応じてさらに細分化できます。

欠点は、ハッシュが完全ではなく、衝突が発生する可能性があることです。これがどのように扱われるのか分かりません。そのため、あなたの側で少し調査する必要があります。プロキシの書き換えルールは、ハッシュA3A8BBC83261.jpgを取得してhttp://img3.domain.com/A3/A8/BBC83261.jpgに書き換えることができるはずだと思います。ただし、それを短いURLと見なすことはできません。


はい、それがまさに画像を保存する方法です。ただし、問題はストレージにあるのではなく、帯域幅の分配にあります。
アラン

ただし、1つのサーバーにAA〜33、別のサーバーに34〜99を保存すると、ストレージの問題だけでなく帯域幅の分散も調整されます。
3dinfluence 09

0

あなたの投稿で、DNSラウンドロビンが最良の選択肢であると感じていると述べましたが、単一のサーバーに障害が発生することを心配していました...

その場合は、JH SoftwareのSimple Failoverをご覧ください。過去に使用したことがありますが、非常にうまく機能します。

http://www.simplefailover.com

基本的にはサーバーを監視し、サーバーがダウンした場合は、DNSをすばやく書き換えて、停止したサーバーをローテーションから引き出します。

ウェブサイトからの抜粋は次のとおりです。

Simple Failoverは、サーバーを継続的に監視して、稼働しているサーバーと停止しているサーバーを検出し、それに応じてDNSレコードを動的に更新して、ドメイン名が常に機能するサーバーを指すようにします。

Webサーバー(HTTP)、メールサーバー(SMTP、IMAP、POP3)、FTPサーバー、および事実上他のTCP / IPベースのサーバータイプで動作します。

前述したように、私は過去にWebサイトとメールサーバーの両方で使用しました。それはかなりよく機能しました。ほとんどの場合、フェイルオーバーはかなり速く(2〜5分と推測)、15分以内にほぼ全員がフェイルオーバーしたと思います。

必ずしも完璧ではありません...しかし、間違いなく迅速かつ簡単です。

注:これはWindows製品です。Linuxバージョンを持っているかどうかはわかりませんが、DNSベースなので、好きなサーバーをフェイルオーバーできます。

私たちの場合、私たちはそれをXPマシンに放り込み、マシンに1晩に1回再起動するように指示しましたが、何年も問題なく動作しました。

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