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サーバーを使用せずに後続のクライアントに転送できます。多くの場合、L7 HTTPロードバランサーと同じことを実行できます。
ある時点でバランサーにも助けが必要になると確信しているので、2番目のバランサーがあります。
まあ、確かに。ただし、負荷分散は簡単であり、多くの場合、単一のロードバランサーで高速化できます。私はこの記事にリンクします。これは、単一の近代的なサーバーが提供できるパフォーマンスの目安の単なる例として、ウェブに神経を打ちました。必要になる前に複数のLBを使用しないでください。共通のアプローチが必要な場合、最前面のIPレベルロードバランサー(またはDNSラウンドロビン)、HTTPレベルロードバランサー、プロキシおよびwebappサーバーに行きます。
「バランサー」がどうあるべきか、およびそれらの設定方法に関するベストプラクティスを支援します。
トラブルスポットは、セッション状態の処理と、ある程度の障害状態の動作です。ロードバランサー自体のセットアップは比較的簡単です。
2〜4個のバックエンドwebappサーバーのみを使用している場合、オリジンIPアドレスに基づく静的ハッシュは実行可能です。これにより、webappサーバー間でセッション状態を共有する必要がなくなります。各webappノードは全体のトラフィックの1 / Nを認識し、通常の動作では顧客からサーバーへのマッピングは静的です。ただし、大規模なインストールには適していません。
2つの最高のロードバランシングアルゴリズムは、彼らは高負荷、さらには負荷分散の下で良性の振る舞いを持っているという意味で、ラウンドロビンと真のランダム負荷分散されています。 どちらも、Webアプリケーションがwebappノードで利用可能なグローバルセッション状態を持っている必要があります。これがどのように行われるかは、webapp技術スタックに依存します。しかし、一般的にこれに利用できる標準的なソリューションがあります。
静的ハッシュも共有セッション状態も適切でない場合、一般的に選択は「スティッキーセッション」負荷分散とサーバーごとのセッション状態です。ほとんどの場合、これは正常に機能し、完全に実行可能な選択肢です。
バランサーは、各apacheインスタンス上にある接続の数を確認し(内部IPまたは外部IPの構成リストを介して)、接続を均等に分散します。
ええ、いくつかのサイトはこれを使用しています。存在する多くの異なる負荷分散アルゴリズムには多くの名前があります。ラウンドロビンまたはランダム(または重み付きラウンドロビン、重み付きランダム)を選択できる場合は、上記の理由から選択することをお勧めします。
最後に、多くのベンダー(F5、Ciscoなどのハイエンド、fx Coyote Point、Kemp Technologiesをよりリーズナブルな価格で提供)が成熟した負荷分散アプライアンスを提供していることを忘れないでください。