帯域幅を分散するために複数の静的ファイルサーバー間で負荷を分散する最良の方法は？
まず、私の状況を説明します。私はかなり人気のあるウェブサイトをサイドプロジェクトとして運営しているので、それに大量のお金を投資することはできません。私は現在、Apacheに通常のリクエストを送信し、すべての静的ファイルリクエストをLighttpdに送信するHAProxyを前面に持つサーバーを1つだけ持っています。すべての画像がより高速なLighttpdに送信される一方で、すべてのphpおよびpostリクエストがApacheによって処理されるため、これは本当にうまく機能しています（サイトはほとんど画像なので、これは本当に重要です）。短いURLも非常に重要であるため、画像を提供するためにサブドメインを設定する必要がないのはいいことです。したがって、HAProxyを使用する理由はここにあります。
私が使用していたかなり安価な非計測帯域幅を提供するホスティングプロバイダーを見つけました。100mbsネットワークカードが処理できる最大の帯域幅を使い始めたときに問題が発生するため、2台目のサーバーが必要です。
私は私の選択肢に多くの考えを入れたので、それぞれについて説明します。うまくいけば、どれが私にとって最良の選択肢であるか、おそらくまだ考えていない別の選択肢があるかもしれないという洞察を提供していただければ幸いです。
要件：
帯域幅の配分さえ必須です。私はかなり強力なサーバーを持っているので、スケールアップはオプションではありません。帯域幅を増やすには、スケールアウトする必要があります。
短いURL。画像を提供するために、img.example.comのようなサブドメインを設定するつもりはありません。 example.com/image.jpgは、現在の状態であり、私がそれを維持したい方法です。しかし、他に方法がない場合、私は理解しています。
リクエストを処理するclostestサーバーは本当に素晴らしいですが、必須ではありません。覚えておくべきこと。
HAProxy to loadbalance：
- とにかくHAProxyを使っているので、とても簡単です。ただし、帯域幅を分散するときに問題が発生すると思います。私はこれについて間違っているかもしれませんが、HAProxyはサーバーがリクエストをサーバーで処理し、それをHAProxyを介してクライアントに送り返さないのですか？したがって、すべてのトラフィックはロードバランサーを経由して戻り、すべてのサーバーを組み合わせたのと同じだけの帯域幅を使用します。
DNSラウンドロビン：
- これは私の最良のオプションかもしれません。複数のサーバー間でWebサイトを複製し、今行っていることを実行するだけです。欠点は、1つのサーバーがダウンしても、クライアントは引き続きそのサーバーに送信されることです。また、複数のサーバー間でサイトを複製する必要があります。静的ファイル以外のすべてを処理する1つのメインサーバーを用意し、次にいくつかの静的ファイルサーバーを設置できることを期待していました。また、これは一種の「貧乏人の負荷分散」であり、もう少し洗練されたものがあればいいと思います。
Direct Server Return：
- それは本当に複雑に見えますが、良いオプションかもしれません。特定のURLを特定のサーバーに送信できますか？現在HAProxyの場合と同様に、正しいファイル拡張子で終わるすべてのURLはLighttpdに送信され、他の拡張子はApacheに送信されます。だから私は似たようなものが必要になります。同様に、すべてのphpリクエストはバランシングソフトウェアを実行している同じサーバーによって処理され、すべてのjpgリクエストは複数のサーバーに送信されます。
理想的には、HAProxyがDirect Server Returnをサポートしていれば、私の問題は解決されます。また、CDNは非常に高価であり、これは副次的なプロジェクトにすぎないため、CDNを使用したくありません。
私の問題を理解していますか？正しく説明しなかった場合や、詳しい情報が必要な場合はお知らせください。
アプリケーションのリクエスト/レスポンスサイクルの図を描き、ボトルネックを特定します。多くのアプリケーションサーバーに負荷を分散する単一のプロキシには、すべてのアプリケーションサーバーの総帯域幅が必要であることは間違いありません。古典的な解決策はRR DNSです。 Google、Yahoo、Amazonはすべて、短いTTLでこの手法を使用します。私はしばらく前に調査を行い、 私の発見を文書化 しました。
別のソリューションは、仮想IPアドレッシングを使用したファンシーパンツエンタープライズロードバランシングソリューションを使用して、実際のIPアドレスを持つ複数のアプリケーションサーバー間でリクエストのバランスをとることです。 NetscalerおよびStonesoft製品を使用してきました。どちらもうまく機能しますが、ひどい特異性があり、非常に複雑です。
いくつかの答え：
- はい、HTTPレベルのプロキシとして機能するため、すべてのトラフィックはHAProxyを通過します。これは、HAProxyが複数のバックエンドサーバーの負荷を分散する別のサーバーにインストールされている場合でも同じです。したがって、ホスティングプロバイダーが100MBitのネットワークポートしか提供しておらず、すでに100MBitをプッシュしている場合は、問題があります。
- ドメインに関しては、Cookieが画像リクエストで送信されないように、サブドメインではなく別のドメインからWebアプリケーションとは異なるドメインから画像を提供するのが最適です。 Steve Soudersオリジナルの作業 、または ここでのスタックオーバーフローの実装 を参照してください。短いURLが非常に重要である場合、おそらくWebアプリケーションをメインURLから移動すること、つまり、ファイル管理アプリケーションをlogin.sitename.comに移動することをお勧めします。
画像リクエストで認証が必要ですか？そうでない場合は、Amazon S3などを使用しませんか？これは非常にスケーラブルであり、データ転送コストはかなり安価です。この場合、Amazon S3バケットのホスト名のDNS CNAMEとしてi.sitename.comのようなものを使用します Amazonsのドキュメントを参照 。 AFAIKでは、ルートドメイン名（sitename.com）をCNAMEとして使用することはできないため、i.sitename.comのようなサブドメインを使用する必要があります。
複数のサーバー間でイメージをハッシュすることもできます。つまりlogin.sitename.comやa.sitename.comのようなDNS構造を作成します。 b.sitename.com; c.sitename.comなど。 「a。」そして「b。」 etcサーバーには、画像付きのファイルシステムと軽量のHTTPサーバー（すでにLighttpdを使用しているため、引き続き使用します。今後のプロジェクトでは、nginxをより優れた代替品として検討することをお勧めします。）画像の場合、作成するのは 一意の識別子のハッシュ、おそらくユーザー名、ファイル名、または複数の識別子の組み合わせ です。このハッシュから、イメージを格納するサーバーを決定します。
編集ハッシングについてはすでに説明しました。基本的にここで提案しているのは、ホスト名にもハッシュを使用して、ネットワークトラフィックを複数のホストに均等に分散することです。
これがどれほど安価である必要があるかわかりません-しかし、100MBitのネットワークトラフィックをプッシュしているときは、すぐに「安くて良い」幻想であることが判明。たぶん、最初に優れたビジネスモデル（定期的な収益を提供するもの）を取得し、その後適切なテクノロジを実装することを検討する必要がありますか？
HAProxyが他のアプリケーションと同じサーバー上にあると思いますか？ HAProxyを別のシステムに分割して、リクエストを実行し、通常のリクエストを1つのサーバーに送信し、イメージリクエストを別のサーバーに送信することができます。これらの問題は、すべてのリクエストがまだ1つのボックスに送信されることであり、その帯域幅を飽和させている場合、それはあまり役に立ちません。
あなたは短いURLが重要だと言っています。どうして？画像を「example.com」から「i.example.com」に切り替えるのは本当にそれほど難しいことですか？ Lighttpdを使用して独自のサーバー上の独自のIPに「i」を設定し、HAProxyを完全にバイパスして、スループットの問題を解決できます。また、リクエストを異なるドメイン名と見なし、より多くの同時接続を開くことができるため、一度に多くのリクエストを開くことができるWebブラウザーの利点も得られます。単一の「i」サーバーが飽和した場合は、DNSラウンドロビンを使用して別のサーバーを追加できます。その時までに、より良いソリューションを実装するのに十分な収益が得られることを願っています。
ホスティングプロバイダーは負荷分散サービスを提供していますか？最善の解決策だと思います。
それを行うもう1つの方法ですが、テストする必要がありますが、リクエストを（LightyまたはApacheで）書き換えます。例：example.com/file.htmlはApacheに残り、example.com/image.jpgはi.example.com/image.jpgにリダイレクトします。すべての要求はApacheを介して管理されますが、応答（アップストリーム帯域幅）はlighttpdサーバーに送られます。ドメインはユーザーに対して透過的です。それでも、Apacheがすべての要求を処理できるかどうか、またはlighttpdにこの仕事を任せるかどうかをテストする必要があります。
すべてのデータがHAProxyを通過するのは正しいので、（私の知る限り）サーバーから直接サーバーに返送することはできません。
[〜＃〜]更新[〜＃〜]
HAproxyのドキュメントを見る 「redir」パラメータが見つかりました。 Apache rewriteのように機能するかどうかはわかりませんが、役に立つ場合があります。ドキュメントは言う：
主な用途は、クライアントを直接接続することで静的サーバーの帯域幅を増やすことです。
多分それはあなたのケースで動作します。
名前の競合がすぐに発生する可能性があるため、かなり大きな画像のセットでは、元のファイル名に基づいて画像を保存していないと想定しています。
これらのタイプの問題を処理する多くのアプリケーションは、ファイルのハッシュとそのハッシュに基づくディレクトリ構造を使用します。ディレクトリ構造は次のようになります。ディレクトリパスはハッシュの最初の2文字で、2番目のレベルのディレクトリはハッシュの次の2文字です。
/image root/AA/AA/images
/image root/AA/AB/images
ここでの利点は、ハッシュによってファイルの分散が均等に保たれ、複数のサーバーに簡単に分割できる名前空間が提供されることです。基本的に、異なるサーバーからハッシュ空間の一部を提供し、必要に応じてこれをさらに分割できます。
欠点は、ハッシュが完全ではなく、衝突が発生する可能性があることです。これがどのように扱われるかはわかりません。そのため、あなたの側で少し研究が必要かもしれません。プロキシの書き換えルールは、ハッシュA3A8BBC83261.jpgを取得して、それを http://img3.domain.com/A3/A8/BBC83261.jpg に書き換えることができると思います。ただし、これを短いURLと見なすことはできません。
あなたの投稿では、DNSラウンドロビンが最善の選択肢であると感じたと述べましたが、単一のサーバーの障害について心配していました...
その場合は、JH SoftwareのSimple Failoverをご覧ください。私は過去にそれを使用したことがあり、それは非常にうまく機能します。
基本的にそれはあなたのサーバーを監視し、それがダウンしたのを見ると、それはすぐにDNSを書き換えて死んだサーバーをローテーションから外します。
ここに彼らのウェブサイトからのスニペットがあります：
シンプルフェイルオーバーは、サーバーを継続的に監視して、稼働中と停止中を特定し、それに応じてDNSレコードを動的に更新して、ドメイン名が常に機能しているサーバーを指すようにします。
Webサーバー（HTTP）、メールサーバー（SMTP、IMAP、POP3）、FTPサーバー、および実質的に他のTCP/IPベースのサーバータイプで動作します。
前述のように、私は過去にWebサイトとメールサーバーの両方に使用しました。それはかなりうまくいきました。ほとんどの場合、フェイルオーバーはかなり速く（2〜5分と推定）、ほぼ全員が15分未満でフェイルオーバーしたと思います。
必ずしも完璧ではありません...しかし、間違いなく迅速で簡単です。
注：これはWindows製品です。 Linuxバージョンがあるかどうかはわかりませんが、DNSベースなので、好きなサーバーをフェイルオーバーできます。
私たちのケースでは、XP=マシンにそれを投げ、マシンに1夜に1回リブートするように指示しました。それは何年も問題なく動作しました。