クラスタリング、分散、負荷分散の違いは何ですか? (写真とテキスト)-PHPチュートリアル-php.cn

php におけるクラスタリング、ディストリビューション、およびロードバランシングには大きな違いがあります。次の記事では、クラスタリング、ディストリビューション、ロードバランシングの具体的な違いについて詳しく説明します。これ以上は説明せずに、見ていきましょう。

クラスターの概念

コンピュータークラスターは、緩やかに統合された一連のコンピューターソフトウェアおよび/またはハードウェアを介して接続され、高度に緊密に連携してコンピューティング作業を完了します。ある意味、それらはコンピューターと考えることができます。クラスタ化システム内の個々のコンピュータは通常ノードと呼ばれ、通常はローカルエリアネットワークを介して接続されますが、他の接続も可能です。クラスターコンピューターは、単一コンピューターのコンピューティング 速度や信頼性 を向上させるためによく使用されます。一般に、クラスターコンピューターは、ワークステーションやスーパーコンピューターなどの単一コンピューターよりもはるかにコスト効率が高くなります。
例えば、負荷の高い単一の処理を複数のノード装置で分担して並列処理し、各ノード装置で処理が完了した後に結果をまとめてユーザーに返すことで、システムの処理能力が大幅に向上します。一般に、いくつかのタイプに分類されます:

高可用性クラスター: 一般に、クラスター内のノードに障害が発生した場合、そのノード上のタスクが他の通常のノードに自動的に転送されることを意味します。また、クラスター内のノードをオフラインに維持した後、再びオンラインに戻すことができることも意味しており、このプロセスはクラスター全体の動作には影響しません。
#ロードバランシングクラスター: ロードバランシングクラスターの実行中、ワークロードは通常、1 つ以上のフロントエンドロードバランサーを通じて分散されます。 . バックエンドのサーバー群上で、システム全体の高性能と高可用性を実現します。

クラスター: 同じビジネスが複数のサーバーにデプロイされます。分散: ビジネスが複数のサブビジネスに分割されているか、それらは異なるビジネスであり、異なるサーバーに展開されています。簡単に言うと、分散は 1 つのタスクの実行時間を短縮することで効率を向上させ、クラスタリングは単位時間あたりに実行されるタスクの数を増やすことで効率を向上させます。例: Sina.com を例に挙げると、より多くの人がアクセスする場合、クラスターを作成し、前面にバランシングサーバーを配置し、背面に複数のサーバーを配置して、同じビジネスを完了することができます。応答サーバーは、どのサーバーが負荷が高くないかを確認し、負荷が重い場合は、どのサーバーに割り当てられ、応答を完了します。1 つのサーバーがダウンしても、他のサーバーがステップアップできます。分散された各ノードは異なるサービスを実行するため、1 つのノードが崩壊するとビジネスが失敗する可能性があります。

ロードバランシング

コンセプト

ビジネス量の増加に伴い、既存のネットワークの各コア部分のアクセス数とデータトラフィックは増加しています。それに応じて処理能力と計算強度も増大し、単一のサーバーデバイスがそれに耐えることは不可能になりました。この場合、既存の設備を廃棄してハードウェアの更新を大量に行うと、既存のリソースの無駄が発生し、次の業務量の増加に直面した場合、再度のハードウェアの更新に多額のコストがかかることになります。コスト投資では、最も優れた設備であっても、現在のビジネス量の増加のニーズを満たすことはできません。

負荷分散技術は、仮想サーバー IP (VIP) を設定することにより、バックエンドの複数の実サーバーのアプリケーションリソースを高性能なアプリケーションサーバーに仮想化し、負荷分散アルゴリズムを通じてユーザーのリクエストをバックエンドのイントラネットに転送します。イントラネットサーバーはリクエストに対する応答をロードバランサに返し、ロードバランサはその応答をユーザーに送信します。これにより、イントラネットの構造がインターネットユーザーから隠蔽され、ユーザーがバックエンド (イントラネット) サーバーに直接アクセスできなくなります。サーバーの安全性が向上し、コアネットワークスタックや他のポートで実行されているサービスへの攻撃を防ぐことができます。また、負荷分散装置（ソフトウェアまたはハードウェア）がサーバー上のアプリケーションの状態を継続的にチェックし、無効なアプリケーションサーバーを自動的に隔離することで、問題を解決するシンプルかつスケーラブルで信頼性の高いアプリケーションソリューションを実現します。、拡張性が不十分、信頼性が低い。

システムの拡張は、垂直(縦)拡張と横(横)拡張に分けられます。垂直拡張とは、大規模な分散システム (Web サイト) のニーズを満たすことができない CPU 処理能力、メモリ容量、ディスクなどのハードウェア処理能力を増強することにより、単一マシンの観点からサーバーの処理能力を高めることです。、大規模なトラフィック、高い同時実行性、および大量のデータの問題。そのため、大規模なWebサイトサービスの処理能力に合わせてマシンを追加して水平拡張する手法を採用する必要があります。たとえば、1 台のマシンが要件を満たせない場合は、2 台以上のマシンを追加してアクセス圧力を共有します。

負荷分散の最も重要なアプリケーションの 1 つは、複数のサーバーを使用して 1 つのサービスを提供することです. このソリューションはサーバーファームと呼ばれることもあります。通常、負荷分散は主に Web Web サイト、大規模なインターネットリレーチャットネットワーク、高トラフィックのファイルダウンロード Web サイト、NNTP (Network News Transfer Protocol) サービス、および DNS サービスで使用されます。現在、ロードバランサーは、データベースロードバランサーと呼ばれるデータベースサービスもサポートし始めています。
サーバー負荷分散には、負荷分散アルゴリズム、ヘルスチェック、セッション維持の 3 つの基本機能があり、これら 3 つの機能は負荷分散の正常な動作を保証するための基本要素です。他のいくつかの機能は、これら 3 つの機能をさらに深めたものです。ここではそれぞれの機能と原理を詳しく紹介していきます。
負荷分散デバイスが展開される前に、ユーザーはサーバーアドレスに直接アクセスします (サーバーアドレスはファイアウォール上の他のアドレスにマップされる場合がありますが、基本的には 1 対 1 のアクセスです)。 1台のサーバーでは性能不足により多くのユーザーのアクセスに対応できない場合、複数のサーバーを利用してサービスを提供することを検討する必要があり、これを実現するのが負荷分散です。ロードバランシングデバイスの実装原理は、複数のサーバーのアドレスを外部サービス IP (通常、VIP と呼びます) にマッピングすることです。サーバーマッピングの場合、サーバー IP を VIP アドレスに直接マッピングすることも、サーバーをマッピングすることもできます。 IP:ポートを VIP:ポートに変換します。異なるマッピング方法では、対応するヘルスチェックが行われます。ポートマッピング中、サーバーポートと VIP ポートは異なる場合があります)。このプロセスはユーザーには表示されません。ユーザーは実際にはサーバーが何であるかを知りません。負荷分散は、依然として同じ宛先 IP にアクセスするため、ユーザーのアクセスが負荷分散デバイスに到達した後、ユーザーのアクセスを適切なサーバーに分散する方法が負荷分散デバイスの仕事です。具体的には、大きな特徴は上記の3つ。
詳細なアクセスプロセス分析を行ってみましょう:

ユーザー (IP: 207.17.117.20) がドメイン名 www.a10networks.com にアクセスすると、最初に DNS クエリを渡し、このドメイン名のパブリックアドレス 199.237.202.124 を解決します。次に、ユーザー 207.17.117.20 はアドレス 199.237.202.124 にアクセスするため、データパケットは負荷分散デバイスに到達し、負荷分散デバイスはデータパケットを適切な宛先に配布します。サーバー、下の図を見てください:

負荷分散デバイスがデータパケットをサーバーに送信すると、データパケットにはいくつかの変更が加えられます。上の図に示すように、データパケットは負荷分散デバイスに到達します。デバイスの前では、送信元アドレスは 207.17.117.20、宛先アドレスは 199.237.202.124 でした。負荷分散デバイスがデータパケットを選択したサーバーに転送したとき、送信元アドレスは 207.17.117.20 のままで、宛先アドレスは 172.16.20.1 に変更されました。この方法は宛先アドレス NAT (DNAT、宛先アドレス変換) と呼ばれます。一般に、DNAT はサーバーの負荷分散で実行する必要があり (DNAT を実行しない、サーバーダイレクトリターン DSR と呼ばれる別のモードがあります。これについては別途説明します)、ソースアドレスは展開モードによって異なります。他のアドレスに変換する必要があります。これをソースアドレス NAT (SNAT) と呼びます。一般的に、バイパスモードには SNAT が必要ですが、シリアルモードには必要ありません。この図はシリアルモードであるため、ソースアドレス NAT は実行されませんでした。
下の図に示すように、サーバーからの返信パケットを見てみましょう。IP アドレス変換プロセスも経ていますが、応答パケットと要求パケットの送信元/宛先アドレスは正確に交換されています。サーバーから返されたパケットの送信元アドレスは 172.16.20.1 、宛先アドレスは 207.17.117.20 です。負荷分散デバイスに到達すると、負荷分散デバイスは送信元アドレスを 199.237.202.124 に変更してユーザーに転送します。アクセスの一貫性を確保します。

#負荷分散アルゴリズム

一般に、負荷分散装置は、デフォルトで次のような複数の負荷分散分散戦略をサポートします。 #ポーリング (ラウンドロビン) は、周期的なシーケンスで各サーバーにリクエストを送信します。サーバーの 1 つに障害が発生すると、AX はそのサーバーを順次循環キューから取り出し、正常に戻るまで次のポーリングに参加しません。

比率 (Ratio): 各サーバーに重み付けされた値を比率として割り当て、この比率に基づいてユーザーリクエストを各サーバーに割り当てます。サーバ。サーバーの 1 つに障害が発生すると、AX はそのサーバーをサーバーキューから取り出し、正常に戻るまで次のユーザーリクエストの配信には参加しません。
優先順位: すべてのサーバーをグループ化し、各グループの優先順位を定義し、ユーザー要求を優先順位に割り当てます。事前に設定されたポーリングまたは比率アルゴリズムを使用してユーザー要求を割り当てます); すべてのサーバーまたは最も高い優先順位レベルの指定された数のサーバーに障害が発生すると、AX は次の優先順位サーバーグループに要求を送信します。この方法は実際にユーザーにホットバックアップ方法を提供します。
LeastConnection: AX は各サーバーまたはサービスポートの現在の接続数を記録し、新しい接続は接続数が最も少ないサーバーに渡されます。サーバーの 1 つに障害が発生すると、AX はそのサーバーをサーバーキューから取り出し、正常に戻るまで次のユーザーリクエストの配信には参加しません。
#高速応答時間: 新しい接続は、最も速い応答でサーバーに渡されます。サーバーの 1 つに障害が発生すると、AX はそのサーバーをサーバーキューから取り出し、正常に戻るまで次のユーザーリクエストの配信には参加しません。
ハッシュアルゴリズム (ハッシュ): クライアントの送信元アドレスとポートをハッシュし、その結果を各サーバーに転送します。サーバーの 1 つに障害が発生すると、そのサーバーはサーバーキューから削除され、正常に戻るまで次のユーザーリクエストの配信には参加しません。
データパケットに基づくコンテンツ配信: たとえば、HTTP URL を判断し、URL に .jpg 拡張子がある場合、パケットは指定されたサーバーに転送されます。

ヘルスチェック

ヘルスチェックは、サーバーによって開かれているさまざまなサービスの可用性ステータスを確認するために使用されます。負荷分散デバイスは通常、Ping、TCP、UDP、HTTP、FTP、DNS などのさまざまなヘルスチェック方法を使用して構成されます。 Ping はヘルスチェックの第 3 層に属し、サーバー IP の接続を確認するために使用され、TCP/UDP はヘルスチェックの第 4 層に属し、サービスポートの UP/DOWN を確認するために使用されます。より正確には、レイヤー 7 に基づくヘルスチェックを使用する必要があります。たとえば、HTTP ヘルスチェックを作成し、ページを取得し、ページコンテンツに指定された文字列が含まれているかどうかを確認します。含まれている場合、サービスは稼働しています。含まれていない場合、またはページが取得できない場合は、サーバーのWebサービスが利用できない（DOWN）と考えられます。たとえば、負荷分散デバイスがサーバー 172.16.20.3 のポート 80 がダウンしていることを検出した場合、負荷分散デバイスは後続の接続をこのサーバーに転送しませんが、アルゴリズムに基づいてデータパケットを他のサーバーに転送します。ヘルスチェックを作成するときに、チェックの間隔と試行回数を設定できます。たとえば、間隔を 5 秒、試行回数を 3 に設定すると、負荷分散デバイスは 5 秒ごとにヘルスチェックを開始します。チェックが失敗した場合は、3 回試行されます。チェックが 3 回失敗した場合、サービスは DOWN としてマークされ、その後もサーバーは 5 秒ごとに DOWN サーバーをチェックします。サーバーのヘルスチェックが失敗したことが判明した場合、ある瞬間に再び成功すると、サーバーは UP 用に再マークされます。ヘルスチェックの間隔や回数は、業務への影響や負荷分散装置に多大な負荷を与えないことを原則とし、総合的な状況に応じて設定する必要があります。

セッション永続性

ユーザーからの 2 つの http リクエストが確実に同じサーバーに転送されるようにするには、負荷分散デバイスでセッション永続性を構成する必要があります。

セッション永続化とは、セッションの継続性と一貫性を維持するために使用されますが、ユーザーのアクセス情報をサーバー間でリアルタイムに同期することは難しいため、ユーザーの前後のアクセスセッションを1台のサーバー上に保持して処理する必要があります。たとえば、ユーザーが電子商取引 Web サイトにアクセスした場合、ユーザーがログインすると、最初のサーバーで処理されますが、ユーザーの商品の購入は 2 番目のサーバーで処理され、2 番目のサーバーはユーザーの情報を知りません。 , したがって、この購入は成功しません。この場合、セッションを維持する必要があり、ユーザーの操作が成功するには最初のサーバーによって処理される必要があります。もちろん、すべてのアクセスにセッションの維持が必要なわけではなく、たとえば、Web サイトのニュースチャンネルなどの静的なページをサーバーが提供し、各サーバーが同じコンテンツを持っている場合、そのようなアクセスではセッションの維持は必要ありません。
ほとんどの負荷分散製品は、送信元/宛先アドレスのセッション永続性と Cookie セッションの永続性という 2 つの基本的なタイプのセッション永続性をサポートしています。さらに、ハッシュ、URL 永続性なども一般的に使用される方法ですが、すべてのデバイスがそれらをサポートしているわけではありません。異なるアプリケーションに基づいて異なるセッション保持を設定する必要があります。そうしないと、負荷の不均衡が発生したり、アクセス例外が発生したりすることがあります。主にB/S構造のセッション維持を分析します。

B/S構造に基づく申請:

Web サイトの静的ページなど、通常の B/S 構造を持つアプリケーションコンテンツの場合は、セッションの永続化を設定する必要はありませんが、B/S 構造に基づいたビジネスシステム、特にミドルウェアプラットフォームの場合は、セッションの永続化を設定する必要があります。通常の状況では、ニーズに合わせて送信元アドレスのセッション保持を設定しますが、クライアントが上記の送信元アドレスのセッション保持に適さない環境にある可能性があることを考慮すると、Cookie のセッション保持を使用する方が良い方法です。 Cookie セッション永続化では、負荷分散装置が選択したサーバー情報を Cookie に保存し、クライアントに送信します。クライアントが継続的に訪問すると、Cookie が送信されます。ロードバランサーは Cookie を分析して、以前のセッションを維持します。選択したサーバー。 Cookie はファイル Cookie とメモリ Cookie に分けられます。ファイル Cookie はクライアントコンピュータのハードドライブに保存されます。Cookie ファイルは有効期限が切れない限り、ブラウザを繰り返し閉じたり、閉じたりしても同じサーバー上に保持されます。ない。メモリ Cookie は Cookie 情報をメモリに保存します。Cookie の存続時間は、ブラウザを開いたときに始まり、ブラウザを閉じたときに終了します。現在のブラウザには Cookie に対する特定のデフォルトのセキュリティ設定があるため、一部のクライアントはファイル Cookie の使用を許可しないと規定している場合があるため、現在のアプリケーション開発では主にメモリ Cookie が使用されます。
ただし、メモリ Cookie は全能ではありません。たとえば、ブラウザはセキュリティ上の理由から Cookie を完全に無効にし、Cookie セッションの保持の効果が失われる場合があります。 Session-id を通じてセッションを維持できます。つまり、セッション ID を URL パラメーターとして使用するか、隠しフィールド <input type="hidden"> に入れてから、セッションを分析します。配布用の -id。
別の解決策は、各セッション情報をデータベースに保存することです。このソリューションはデータベースの負荷を増加させるため、パフォーマンスの向上には向いていません。データベースは、長時間のセッションのセッションデータを保存するのに最適です。データベースの単一障害点を回避し、そのスケーラビリティを向上させるために、通常、データベースは複数のサーバー上で複製され、リクエストはロードバランサーを通じてデータベースサーバーに分散されます。
送信元/宛先アドレスに基づくセッション永続性は、あまり使いやすいものではありません。顧客は DHCP、NAT、または Web プロキシ経由でインターネットに接続する可能性があり、IP アドレスが頻繁に変更される可能性があるため、このソリューションのサービス品質は保証されません。
NAT (ネットワークアドレス変換、ネットワークアドレス変換): プライベートネットワーク内の一部のホストにローカル IP アドレス (つまり、このプライベートネットワーク内でのみ使用されるプライベートアドレス) が割り当てられている場合、しかし今、インターネット上のホストと (暗号化なしで) 通信したい場合は、NAT 方式を使用できます。この方法では、プライベートネットワークをインターネットに接続するルーターに NAT ソフトウェアをインストールする必要があります。 NAT ソフトウェアを搭載したルータは NAT ルータと呼ばれ、有効な外部グローバル IP アドレスを少なくとも 1 つ持ちます。このように、ローカルアドレスを使用するすべてのホストが外部と通信する場合、インターネットに接続する前に、ローカルアドレスを NAT ルーターでグローバル IP アドレスに変換する必要があります。

負荷分散のその他の利点

高いスケーラビリティ

サーバーの数を追加または削減することで、同時多発リクエストに適切に対処できます。

(サーバー) ヘルスチェック

ロードバランサーは、バックエンドサーバーアプリケーション層の健全性をチェックし、障害が発生したサーバーをサーバープールから削除して信頼性を向上させることができます。

TCP 接続の再利用

TCP 接続の再利用テクノロジは、フロントエンドの複数のクライアントからの HTTP 要求を、バックエンドとサーバーの間に確立された TCP 接続に多重化します。このテクノロジーにより、サーバーのパフォーマンス負荷が大幅に軽減され、サーバーとの新しい TCP 接続によって引き起こされる遅延が軽減され、クライアントからバックエンドサーバーへの同時接続要求の数が最小限に抑えられ、サーバーのリソース占有が軽減されます。
一般に、クライアントは HTTP リクエストを送信する前に、サーバーと TCP スリーウェイハンドシェイクを実行し、TCP 接続を確立してから、HTTP リクエストを送信する必要があります。 HTTP リクエストを受信したサーバーはそれを処理し、処理結果をクライアントに返し、クライアントとサーバーは相互に FIN を送信し、FIN の ACK 確認を受信した後に接続を閉じます。このように、単純な HTTP リクエストの処理には十数個の TCP パケットが必要です。
TCP 接続再利用テクノロジの採用後、クライアント (ClientA など) と負荷分散デバイスの間で 3 ウェイハンドシェイクが実行され、HTTP リクエストが送信されます。リクエストを受信した負荷分散デバイスは、サーバー上にアイドル状態の長い接続があるかどうかを検出し、存在しない場合は、サーバーは新しい接続を確立します。 HTTP リクエストの応答が完了すると、クライアントは負荷分散デバイスとネゴシエートして接続を閉じ、負荷分散デバイスはサーバーとの接続を維持します。別のクライアント (ClientB など) が HTTP リクエストを送信する必要がある場合、負荷分散デバイスはサーバーと維持されているアイドル接続に HTTP リクエストを直接送信し、新しい TCP 接続によって引き起こされる遅延とサーバーリソースの消費を回避します。

HTTP 1.1 では、クライアントは TCP 接続で複数の HTTP リクエストを送信できます。このテクノロジは HTTP 多重化と呼ばれます。 TCP 接続多重化との最も基本的な違いは、TCP 接続多重化は複数のクライアント HTTP リクエストをサーバー側 TCP 接続に多重化するのに対し、HTTP 多重化は TCP を介してクライアントの HTTP リクエストを多重化して接続を処理することです。前者は負荷分散デバイスの独自の機能であり、後者は HTTP 1.1 プロトコルでサポートされる新機能であり、現在ほとんどのブラウザでサポートされています。

HTTP キャッシュ

ロードバランサは静的コンテンツを保存し、ユーザーがリクエストしたときにバックエンドサーバーにリクエストを行うことなく直接応答できます。

TCP バッファリング

TCP バッファリングは、バックエンドサーバーのネットワーク速度と顧客のフロントエンドネットワーク速度の不一致によって引き起こされるサーバーリソースの浪費の問題を解決します。クライアントとロードバランサー間のリンクは遅延が大きく帯域幅が狭いのに対し、ロードバランサーとサーバー間のリンクは遅延が低く帯域幅が広い LAN 接続を使用します。ロードバランサーはバックエンドサーバーの応答データをクライアントに一時的に保存し、応答時間が長くネットワーク速度が遅いクライアントにデータを転送できるため、バックエンド Web サーバーは対応するスレッドを解放して他のタスクを処理できます。

SSL アクセラレーション

通常の状況では、HTTP はクリアテキストでネットワーク上に送信されるため、特に認証に使用されるパスワード情報が不正に盗聴される可能性があります。このようなセキュリティの問題を回避するために、一般に SSL プロトコル (つまり、HTTPS) を使用して HTTP プロトコルを暗号化し、送信プロセス全体のセキュリティを確保します。 SSL通信では、まず非対称鍵技術を利用して認証情報を交換し、サーバーとブラウザ間でデータの暗号化に使用するセッション鍵を交換し、通信中にその鍵を使って情報の暗号化と復号化を行います。
SSL は、大量の CPU リソースを消費するセキュリティテクノロジです。現在、ほとんどのロードバランシングデバイスは、SSL アクセラレーションチップ (ハードウェアロードバランサ) を使用して SSL 情報を処理します。この方式は、従来のサーバーベースの SSL 暗号化方式よりも高い SSL 処理パフォーマンスを提供するため、サーバーリソースを大幅に節約し、サーバーはビジネスリクエストの処理に集中できます。さらに、SSL 処理を一元化することで証明書の管理が簡素化され、日々の管理の負担も軽減されます。

コンテンツフィルタリング

一部のロードバランサーは、必要に応じて、通過するデータを変更できます。

侵入防御機能

ネットワーク層/トランスポート層のセキュリティを確保するファイアウォールをベースに、アプリケーション層のセキュリティ防御を提供します。

分類

以下では、さまざまなレベルからの負荷分散の実装について説明します。

DNS 負荷分散

DNS は、ドメイン名解決サービスを提供する役割を果たします。特定のサイトにアクセスする場合、実際には、まずサイトのドメイン名の DNS サーバーを介して、ドメイン名が指す IP アドレスを取得する必要があり、このプロセスで、DNS サーバーはドメイン名と IP アドレスのマッピングを完了します。同様に、このマッピングは 1 対多にすることもでき、このとき、DNS サーバーは負荷分散スケジューラとして機能し、ユーザーのリクエストを複数のサーバーに分散します。 dig コマンドを使用して、「baidu」の DNS 設定を確認します。

baidu には 3 つの A レコードがあることがわかります。

このテクノロジーの利点は、実装が簡単で、低コストで、ほとんどの TCP/IP アプリケーションに適しており、DNS サーバーは、利用可能なすべてのサーバーの中からユーザーに最も近いサーバーを見つけることができることです。記録。。ただし、欠点も非常に明白です。第一に、このソリューションは本当の意味での負荷分散ではありません。DNS サーバーは、現在のステータスに関係なく、バックグラウンドの Web サーバー (または地理的な位置に従って) HTTP リクエストを均等に分散します。各 Web サーバーの負荷状況、バックエンド Web サーバーの構成や処理能力が異なると、最も遅い Web サーバーがシステムのボトルネックとなり、処理能力の高いサーバーがその役割を十分に果たせなくなります。バックグラウンドで特定の Web サーバーに障害が発生した場合でも、DNS サーバーはこの障害が発生したサーバーに DNS 要求を割り当て続けるため、クライアントに応答できなくなります。最後の点は致命的で、かなりの数のお客様が Web サービスを利用できなくなる可能性があり、DNS キャッシュのせいでその影響は長期間続きます (DNS の一般的な更新周期は約 24 時間です)。。したがって、最新の外国建設センターの Web サイトソリューションでは、このソリューションはほとんど使用されていません。

リンク層 (OSI 層 2) 負荷分散

負荷分散のために通信プロトコルのデータリンク層の MAC アドレスを変更します。
データを配布するときは、IP アドレスを変更せず (IP アドレスはまだ表示できないため)、ターゲット MAC アドレスのみを変更し、すべてのバックエンドサーバーの仮想 IP がロードバランサーの IP アドレスと一致するように構成します。データパケットの送信元アドレスと宛先アドレスがデータ配信の目的で変更されないようにします。
実際の処理サーバーの IP はデータ要求の宛先 IP と一致します。アドレス変換のために負荷分散サーバーを経由する必要はありません。負荷分散サーバーを回避するために、応答データパケットはユーザーのブラウザに直接返されます。ネットワークカードの帯域幅がボトルネックになっています。ダイレクトルーティングモード (DR モード) とも呼ばれます。以下に示すように:

パフォーマンスは非常に優れていますが、構成が複雑なため、現在広く使用されています。

トランスポート層 (OSI レイヤ 4) ロードバランシング

トランスポート層は、TCP と UDP を含む OSI レイヤ 4 です。一般的なトランスポート層のロードバランサーは、HAProxy (これはアプリケーション層のロードバランシングにも使用されます) と IPVS です。
最終的に選択される内部サーバーは、主にメッセージ内の宛先アドレスとポート に加え、負荷分散装置によって設定されたサーバー選択方法によって決定されます。
一般的な TCP を例にとると、負荷分散デバイスはクライアントから最初の SYN リクエストを受信すると、上記の方法で最適なサーバーを選択し、メッセージ内のターゲット IP アドレスを変更します (バックエンドサーバー IP に変更)。サーバーに直接転送されます。 TCP 接続の確立、つまり 3 ウェイハンドシェイクはクライアントとサーバーの間で直接確立され、負荷分散デバイスはルーターのような転送アクションとしてのみ機能します。導入状況によっては、サーバーからのパケットがロードバランシングデバイスに正しく返されることを保証するために、パケットの転送中にパケットの元の送信元アドレスが変更される場合があります。

アプリケーション層 (OSI 層 7) の負荷分散

アプリケーション層は OSI 層 7 です。これには、HTTP、HTTPS、WebSocket が含まれます。非常に人気があり実績のあるアプリケーション層ロードバランサーは、Nginx [エンジン X = エンジン X] です。
いわゆる 7 層の負荷分散 (「コンテンツスイッチング」とも呼ばれます) は、主に、メッセージ内の真に意味のあるアプリケーション層のコンテンツに基づいて、負荷分散デバイスによって設定されたサーバー選択方法と組み合わせて、最終的な内部選択サーバー。この時点で、特定の http リクエストの完全な URL を確認できるため、次の図に示すような分布を実現できることに注意してください。

一般的な TCP を例に挙げると、ロードバランシングデバイスは、実際のアプリケーション層コンテンツに基づいて、サーバーを選択する必要があります。最終サーバーとクライアントがプロキシされて接続 (3 ウェイハンドシェイク) を確立した後、実際のアプリケーション層コンテンツメッセージが表示されます。クライアントによって送信されたフィールドが表示され、負荷分散デバイスによって設定されたサーバー選択方法と組み合わせて、内部サーバーの最終的な選択が決定されます。この場合の負荷分散デバイスはプロキシサーバーに似ています。負荷分散、フロントエンドクライアントとバックエンドサーバーはそれぞれ TCP 接続を確立します。したがって、この技術原理の観点から、7 層負荷分散は負荷分散装置に対する要求が明らかに高く、7 層の処理能力は 4 層モードの展開方法よりも必然的に低くなります。では、なぜレイヤー 7 の負荷分散が必要なのでしょうか?

7 層の負荷分散の利点は、ネットワーク全体をより「インテリジェント」にすることです。たとえば、上に挙げた負荷分散の利点のほとんどは、7 層の負荷分散に基づいています。たとえば、Web サイトを訪問するユーザートラフィックは、画像のリクエストを特定の画像サーバーに転送し、7 層アプローチを通じてキャッシュテクノロジを使用することができ、テキストのリクエストは特定のテキストサーバーに転送して圧縮を使用できます。もちろん、これは 7 層アプリケーションのほんの小さな例にすぎませんが、技術的な観点から見ると、この方法はクライアントのリクエストとサーバーの応答をあらゆる意味で変更できるため、ネットワーク層でのアプリケーションシステムの柔軟性が大幅に向上します。
よく言及されるもう 1 つの機能はセキュリティです。ネットワークで最も一般的な SYN フラッド攻撃は、ハッカーが多数のソースクライアントを制御し、偽の IP アドレスを使用して同じターゲットに SYN 攻撃を送信するものです。通常、この攻撃は大量の SYN メッセージを送信し、サーバー上の関連リソースを使い果たします。サービス拒否 (DoS) の目的を達成します。また、4 層モードでは、これらの SYN 攻撃はバックエンドサーバーに転送され、7 層モードでは、これらの SYN 攻撃は負荷分散デバイスで自然に終了し、バックエンドサーバーの通常の動作には影響しません。さらに、負荷分散デバイスは 7 層レベルで複数のポリシーを設定し、SQL インジェクションやその他のアプリケーションレベルの攻撃方法などの特定のメッセージをフィルタリングして、アプリケーションレベルからシステム全体のセキュリティをさらに向上させることができます。
現在の7層負荷分散は広く使われているHTTPプロトコルを中心にしているため、多くのWebサイトや社内情報基盤などB/Sをベースに開発されたシステムが主な適用範囲となります。レイヤ 4 ロードバランシングは、ERP や C/S に基づいて開発されたその他のシステムなど、他の TCP アプリケーションに対応します。