レイヤー4とレイヤー7の負荷分散

データセンターにレイヤー4の負荷分散ソリューションを使用するか、レイヤー7のソリューションを使用するかを決定しようとしています。残念なことに（つまり、私の正気のために）、私のユースケースは両方のソリューションがうまく機能するのに十分なほど単純であり、ほとんどの弱点を回避し、他の長所を実際には利用しません。最終的にどのソリューションを使用するにしても、高い可用性と高いスループットが必要です。ただし、Webサーバーのクラスターでの負荷分散にのみ使用することを計画しています。これらのサーバーには、 "スティッキー"セッション管理（CookieまたはIP）、複雑な書き換えルール、または、すべて。

ロードバランサーは2つのスイッチに接続され、どちらもデータセンターアグリゲーションレイヤーまで独立して接続され、ラピッドスパニングツリーとスイッチが仮想化に使用する独自のプロトコルを使用してマージされます。ロードバランサーは、クロスケーブルを介して相互にクロスリンクされます。クラスタ内のすべてのサーバーが両方のスイッチに接続されています。ロードバランサーがしなければならないことは、それらにトラフィックを向けることだけです。

HTTPであるため、HAProxyやnginxなどのレイヤー7負荷分散ソリューションを使用できます。しかし、ldirectordやkeepalivedなどと一緒にLVSプロジェクトを使用することもできます。

私は彼らが見ているように長所と短所を分割しようとしましたが、それはちょうど洗い流されてしまいます。何をお勧めしますか？その理由は何ですか？何か不足していますか？

haproxyのような「L7」の有用な利点の1つは、Cookieを使用して、同じブラウザーが同じバックエンドサーバーにアクセスし続けることです。これにより、クライアントヒットのデバッグがはるかに簡単になります。

L4バランシングは、複数のバックエンドサーバーで1人のユーザーをバウンスさせる場合があります。（場合によっては有利かもしれませんが、デバッグ/プロファイリングの意味では、「L7」を使用するほうがはるかに価値があります。）

編集：HTTPバランシングを使用すると、潜在的な速度の利点もあります。キープアライブを使用すると、クライアントはバランサーへの単一のTCPセッションを確立し、新しいTCPセッションを再確立する必要なしに多くのHITを送信できます（3ウェイハンドシェイク）。同様に、多くのLBはバックエンドシステムへのキープアライブセッションを維持し、バックエンドで同じハンドシェイクを行う必要性を取り除きます。

厳密なTCPロードバランシングでは、これらの両方を簡単に達成できない場合があります。

/ * FWIW：「L7」または「L4」とは言わず、HTTPまたはTCPと言います。しかし、私はOSIを使用して、一致しないものを説明することを避けることにこだわりを持っています。* /

基本的に、何を展開するかわからない場合は、シンプルで自然な感じで進んでください。テストし（Apacheベンチを使用しますか？）、ニーズに合っていることを確認します。私にとってHTTP LBはより自然です。

L7バランシングを行うことによる利点がないため、代わりにL4バランシングを採用します。私はそれをできるだけ犠牲にすることなく、できるだけシンプルに保つことの大ファンです。

L7では、バランサーが適切なルーティングのために通過するパケットのhttpヘッダーを検査する必要があります。これにより、オーバーヘッドが増加し、エンドユーザーのレイテンシがわずかに増加します。あなたがそれによって何も得られないなら、それは無意味な費用のようです。

一部のDNSプロバイダーには、単純なフェールオーバー機能があります。要件が何であり、何であるかについては言及していませんが、何かがダウンした場合に必要なのはフェイルオーバー付きのラウンドロビンだけであれば、たとえばzoneedit.comのFailoverを使用できます。HAのニーズに応じて、それで十分である場合があり、アーキテクチャ内の層全体をスキップできます。