クラスタリング、分散、負荷分散の違いは何ですか? (写真とテキスト)
- 不言オリジナル
- 2018-07-25 16:46:493478ブラウズ
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 に変更してユーザーに転送します。アクセスの一貫性を確保します。 
- 比率 (Ratio): 各サーバーに重み付けされた値を比率として割り当て、この比率に基づいてユーザー リクエストを各サーバーに割り当てます。サーバ。サーバーの 1 つに障害が発生すると、AX はそのサーバーをサーバー キューから取り出し、正常に戻るまで次のユーザー リクエストの配信には参加しません。
- 優先順位: すべてのサーバーをグループ化し、各グループの優先順位を定義し、ユーザー要求を優先順位に割り当てます。事前に設定されたポーリングまたは比率アルゴリズムを使用してユーザー要求を割り当てます); すべてのサーバーまたは最も高い優先順位レベルの指定された数のサーバーに障害が発生すると、AX は次の優先順位サーバー グループに要求を送信します。この方法は実際にユーザーにホット バックアップ方法を提供します。
LeastConnection: AX は各サーバーまたはサービス ポートの現在の接続数を記録し、新しい接続は接続数が最も少ないサーバーに渡されます。サーバーの 1 つに障害が発生すると、AX はそのサーバーをサーバー キューから取り出し、正常に戻るまで次のユーザー リクエストの配信には参加しません。
- #高速応答時間: 新しい接続は、最も速い応答でサーバーに渡されます。サーバーの 1 つに障害が発生すると、AX はそのサーバーをサーバー キューから取り出し、正常に戻るまで次のユーザー リクエストの配信には参加しません。
- ハッシュ アルゴリズム (ハッシュ): クライアントの送信元アドレスとポートをハッシュし、その結果を各サーバーに転送します。サーバーの 1 つに障害が発生すると、そのサーバーはサーバー キューから削除され、正常に戻るまで次のユーザー リクエストの配信には参加しません。
- データ パケットに基づくコンテンツ配信: たとえば、HTTP URL を判断し、URL に .jpg 拡張子がある場合、パケットは指定されたサーバーに転送されます。
セッション永続化とは、セッションの継続性と一貫性を維持するために使用されますが、ユーザーのアクセス情報をサーバー間でリアルタイムに同期することは難しいため、ユーザーの前後のアクセスセッションを1台のサーバー上に保持して処理する必要があります。たとえば、ユーザーが電子商取引 Web サイトにアクセスした場合、ユーザーがログインすると、最初のサーバーで処理されますが、ユーザーの商品の購入は 2 番目のサーバーで処理され、2 番目のサーバーはユーザーの情報を知りません。 , したがって、この購入は成功しません。この場合、セッションを維持する必要があり、ユーザーの操作が成功するには最初のサーバーによって処理される必要があります。もちろん、すべてのアクセスにセッションの維持が必要なわけではなく、たとえば、Web サイトのニュース チャンネルなどの静的なページをサーバーが提供し、各サーバーが同じコンテンツを持っている場合、そのようなアクセスではセッションの維持は必要ありません。
ほとんどの負荷分散製品は、送信元/宛先アドレスのセッション永続性と Cookie セッションの永続性という 2 つの基本的なタイプのセッション永続性をサポートしています。さらに、ハッシュ、URL 永続性なども一般的に使用される方法ですが、すべてのデバイスがそれらをサポートしているわけではありません。異なるアプリケーションに基づいて異なるセッション保持を設定する必要があります。そうしないと、負荷の不均衡が発生したり、アクセス例外が発生したりすることがあります。主に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 アプリケーションに対応します。
関連する推奨事項:
以上がクラスタリング、分散、負荷分散の違いは何ですか? (写真とテキスト)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。