N個のApacheサーバー間で着信Webトラフィックのバランスを取るにはどうすればよいですか？
Heartbeat/Squid/Varnish/etcのようなものを使用して、内部Apacheインスタンス間で着信トラフィックの量のバランスを取ることを検討しています。私のものはすべてVPSで実行されるため、これはハードウェアではなくソフトウェアである必要があります。私はこの分野での経験があまりないので、用語を誤用して間違ったパッケージを選んだ場合は、申し訳ありません。
私は自分が何を求めているかを説明するために何かを描きました。緑の面は初期設定がどのように見えるかであり、青の面はトラフィックの増加のためにApacheインスタンスを追加した後の様子です。これはこれらがどのように機能するかではないかもしれませんが、理想的には、バランサーのIPをドメインのDNSに追加します。次に、バランサーは各Apacheインスタンスに接続がいくつあるかを（内部IPまたは外部IPの構成リストを介して）確認し、接続を均等に分散します。ある時点でバランサーも助けを必要とすると確信しているので、青色には2番目のバランサーがあります。
たぶん私はこれについて間違っているのかもしれませんが、「バランサー」がどうあるべきか、そしてそれらを設定する方法のベストプラクティスについての助けを探しています。
どんな助けでも素晴らしいでしょう。 
ほぼすべての「リバースプロキシ」が、あなたが求めることを実行します。
たとえば、Varnish、Pound、およびHAProxyはすべて、それらの機能に優れていますが、違いもあります。ただし、あなたが求めていることについては、いずれも機能します。個人的には、HAProxyを使用するのが最善だと思いますが、それは単なる推測です。
ロードバランサーに関する記事を読んで、必要な種類を決定するのに役立つと思います。 http://1wt.eu/articles/2006_lb/
また、AmazonのElastic Compute Cloudでソフトウェアを実行し、Elastic Load Balancingを使用するなど、このために事前に構築されたサービスの使用を検討することもできます。
最初に、答えなければならない重要な質問があります：
ユーザーセッションがロードバランサーによって処理され、常に同じWebサーバーに接続されている必要がありますか（稼働中の場合）？
セッションは必要ありません：この場合、ロードバランサーとして効率的なnginxプログラムを使用する必要があります。構成は簡単に設定できます。基本的には、
upstream upstream_name { server1, ..., serverN }ステートメントでWebサーバーのリストを指定するだけでよく、特定のドメインに対して、単純なproxy_pass upstream_nameディレクティブが必要です。
Nginx wiki を参照してください。セッションが必要ですpoundにも同様の設定があり、セッションをホストするCookieの名前を指定しますID（
ID MYCOOKIENAME）、次にすべてのサーバーのBACKENDのリスト。
たとえば、 ポンド設定の例 を参照してください。
複数のロードバランサーが必要になった場合は、heartbeat構成を選択することをお勧めします。これにより、1つのバランサーのみが特定のドメインの仮想IPをマウントするようになります（セッションが必要な場合、または両方をマウントしてフィードするたとえば、2つのIPアドレスを持つDNS）。 （ツールが急速に進化するにつれて）必要になったときに、これは別の質問で詳しく説明する必要があります。
たとえば、 このリンク も参照してください。
アーキテクチャにさらに複雑さと単一障害点を導入するには、十分な理由が必要です。
ラウンドロビン負荷分散
- 費用はかかりません
- 実装と管理が簡単です
- クライアントでフェイルオーバーを実装します-障害を確実に検出できる唯一の場所
- サーバーアフィニティを暗黙的にサポートしますが、スティッキーセッションに関連するセッション管理の問題なしにフェイルオーバーを許可します
- クラスターノードに追加のソフトウェア/ハードウェア/構成は必要ありません
ラウンドロビンに関して出される誤った情報の量に驚かされます。私が皮肉な人だったとしたら、高価な負荷分散ハードウェアを製造しているベンダーとの関係があるのではないかと思うかもしれません。
私が認める唯一のポイントはそれです
バランサーについては、LVSを http://www.linuxvirtualserver.org/ で調べ、ldirectordとハートビートを実行してトラフィックを転送し、フェイルオーバーを実行することができます。
Nginx はアップストリームプロキシとして素晴らしいです。毎日100万個以上の一意を実行する構成で大成功しました。
OK、これはしばらく前に尋ねられました、そして私はパーティーに遅れています。それでも、ここに追加するものがあります。
ジャッキー、あなたはほとんどそれを釘付けにしました。あなたの図は、ほとんどの中小規模のインストールで負荷分散がどのように処理されるかを示しています。
Nakedibleがリンクしている Willy Tarreauによる負荷分散の概要 を読む必要があります。それはまだ有効であり、良い入門書です。
これらがあなたのニーズにどのように適合するかを考慮する必要があります：
- TCP/IPレベルのロードバランサー（Linux Virtual Serverなど）。接続あたりのオーバーヘッドが最も低く、速度が最も高いため、HTTPを「見る」ことはできません。
- HTTPレベルのロードバランサー（HAProxy、nginx、Apache 2.2、Pound、Microsoft ARRなど）。オーバーヘッドが高く、HTTPを表示でき、HTTPをgzipで圧縮でき、SSLを実行でき、スティッキーセッションの負荷分散を実行できます。
- HTTPリバースプロキシ（Apache Traffic Server、Varnish、Squid）。キャッシュ可能なオブジェクト（一部のWebページ、css、js、画像）をRAMに保存し、バックエンドWebサーバーを使用せずに後続のクライアントに転送できます。多くの場合、L7HTTPと同じことを実行できます。ロードバランサーはそうします。
ある時点でバランサーにも助けが必要になると確信しているので、2番目のバランサーがあります。
そうですね。ただし、負荷分散は単純であり、多くの場合、単一のロードバランサーが高速になります。 単一の最新サーバーのパフォーマンスボールパーク が提供できるものの単なる例として、Webで神経質になったこの記事にリンクします。必要になる前に複数のLBを使用しないでください。一般的なアプローチが必要な場合は、最前線にあるIPレベルのロードバランサー（またはDNSラウンドロビン）、HTTPレベルのロードバランサー、プロキシおよびWebアプリケーションサーバーに移動します。
「バランサー」がどうあるべきか、およびそれらを設定する方法のベストプラクティスについてのヘルプ。
問題点はセッション状態の処理であり、ある程度は障害状態の動作です。ロードバランサー自体のセットアップは比較的簡単です。
2〜4台のバックエンドWebアプリケーションサーバーを使用している場合は、オリジンIPアドレスに基づく静的ハッシュが実行可能です。これにより、webappサーバー間でセッション状態を共有する必要がなくなります。各webappノードはトラフィック全体の1/Nを認識し、顧客からサーバーへのマッピングは通常の操作では静的です。ただし、大規模なインストールには適していません。
2つの最良の負荷分散アルゴリズムは、高負荷および負荷分散でさえも良性の動作をするという意味で、ラウンドロビンと真のランダム負荷分散です。これらは両方とも、WebアプリケーションがWebアプリケーションノードで利用可能なグローバルセッション状態を持っている必要があります。これはどうですか行われるのはwebapp技術スタックに依存します。しかし、これには一般的に利用できる標準的なソリューションがあります。
静的ハッシュも共有セッション状態も適切でない場合は、通常、「 スティッキーセッション 」負荷分散とサーバーごとのセッション状態を選択します。ほとんどの場合、これは問題なく機能し、完全に実行可能な選択です。
バランサーは、各Apacheインスタンスにある接続の数を（内部IPまたは外部IPの構成リストを介して）確認し、接続を均等に分散します
ええ、いくつかのサイトはこれを使用しています。存在する多くの 異なる負荷分散アルゴリズム には多くの名前があります。ラウンドロビンまたはランダム（または加重ラウンドロビン、加重ランダム）を選択できる場合は、上記の理由から、そうすることをお勧めします。
最後に：多くのベンダー（F5、Ciscoなどのハイエンドのfx CoyotePointおよびKempTechnologiesをよりリーズナブルな価格で提供していることを忘れないでください）提供 成熟した負荷分散アプライアンス 。