Linux には 4 種類のロード バランシングがあります: 1. 仮想 MAC アドレスを使用するレイヤ 2 ロード バランシング (mac) 仮想 MAC アドレスに対する外部リクエストは、ロード バランサとロード バランサの実際の MAC アドレスによって受信されます。バックエンドは応答として割り当てられます; 2. 3 層ロード バランシング (ip)、仮想 IP アドレスを使用し、仮想 IP アドレスに対する外部リクエスト、ロード バランシングはリクエストを受信した後に実際のバックエンド IP アドレス応答を割り当てます; 3. 4 層負荷分散 (tcp)、第 4 層から開始 「トランスポート層」層から開始、リクエストの受信には「ip ポート」を使用; 4. 7 層負荷分散 (http)。
#このチュートリアルの動作環境: linux7.3 システム、Dell G3 コンピューター。
通常の 開発 および 運用保守 作業では、負荷分散サービスがよく使用され、多くの場合 4 層で構成されます。の負荷と 7 つの負荷階層について説明します。 レイヤー 4 負荷とは正確には何ですか?レイヤ 7 負荷とは何ですか? この 2 つの違いは何ですか?
1)ロード バランシング (ロード バランス) は既存のネットワーク上に構築されますさらに、ネットワーク デバイスとサーバーの帯域幅を拡張し、スループットを向上させ、ネットワーク データ処理機能を強化し、ネットワークの柔軟性と可用性を向上させるための、安価で効果的かつ透過的な方法を提供します。 負荷分散には 2 つの意味があります : 1 つ目は、大量の同時アクセスまたはデータ トラフィックが複数のノード デバイスでそれぞれ処理のために共有され、ユーザーが応答を待つ時間を短縮します。2 つ目は、単一の高負荷操作が共有されることです。各ノード装置で並列処理を行い、各ノード装置での処理完了後に結果をまとめてユーザーに返すため、システムの処理能力が大幅に向上します。
2) 簡単に言えば、: 1 つは、大量の同時処理を複数のバックエンド ノードに転送して処理し、作業の応答時間を短縮することです。もう 1 つは、単一の重いワークロードを処理のために複数のバックエンド ノードに転送し、ユーザーに返す前に負荷分散センターに返すことです。現在、負荷分散テクノロジは主に、Web サーバー、FTP サーバー、その他のミッションクリティカルなサーバーなどのインターネット サーバー プログラムの可用性とスケーラビリティを向上させるために使用されています。
開発で最も一般的な 4 層負荷分散および 7 層運用と保守の負荷分散。
OSI モデルに従って分割されたレイヤ 2 負荷は、通常、仮想 MAC アドレスを使用し、外部仮想マシン MAC アドレス要求を受信した後、ロード バランサーはバックエンドからの実際の MAC アドレス応答を割り当てます。
通常は仮想 IP アドレス方式を採用しており、外部からの仮想 IP アドレス要求を負荷分散により受信し、実際のバックエンド IP アドレスが応答します。 (つまり、1 つの IP を 1 つの IP に転送し、すべてのポートがオープンになります)
3 つのロード バランシングに基づく, つまり、第 4 層の「トランスポート層」から始まり、「ip ポート」を使用してリクエストを受信し、対応するマシンに転送します。
は、IP ポートベースの負荷分散です。3 層の負荷分散に基づいており、3 層の IP アドレス (VIP) を公開し、次に 4 層のポート番号を追加して、どのトラフィックを処理する必要があるかを決定します。負荷分散し、処理する必要があるトラフィックに対して NAT 処理を実行し、それをバックエンド サーバーに転送し、どのサーバーが TCP または UDP トラフィックを処理するかを記録します。この接続の後続のすべてのトラフィックは、処理のために同じサーバーに転送されます。
対応するロードバランサは 4 層スイッチ (L4 スイッチ) と呼ばれ、主に IP 層と TCP/UDP 層を分析して 4 層の負荷分散を実現します。このタイプのロード バランサは、アプリケーション プロトコル (HTTP/FTP/MySQL など) を認識しません。
4 層負荷分散を実現するソフトウェアは次のとおりです。
F5: ハードウェア ロード バランサー。機能は優れていますが、コストが高くなります。
lvs: 重量級の 4 層ロード ソフトウェア
nginx: 軽量の 4 層ロード ソフトウェア、キャッシュ機能付き、より柔軟な正規表現
haproxy: 4 層の転送をシミュレート、より柔軟
7 層目の「アプリケーション層」から開始し、仮想 URL または IP、ホスト名に従ってリクエストを受信し、リダイレクトします。対応するプロセスサーバー。
は、仮想 URL またはホスト IP に基づく負荷分散です。4 層の負荷分散 (4 層なしで 7 層にすることは絶対に不可能です) に基づいて、アプリケーション層の特性を考慮します。同じ Web サーバーの負荷分散などでは、VIP とポート 80 に基づいてトラフィックを処理する必要があるかどうかを特定するだけでなく、7 層の URL、ブラウザ カテゴリ、言語に基づいて負荷分散を実行するかどうかも決定できます。たとえば、Web サーバーが 2 つのグループ (中国語用と英語用) に分割されている場合、ユーザーがドメイン名にアクセスすると、7 層の負荷分散によってユーザーの言語が自動的に識別され、対応する言語が選択されます。サーバーグループは負荷分散処理を行います。
対応するロードバランサは7層スイッチ(L7スイッチ)と呼ばれ、4層の負荷分散をサポートするほか、HTTPプロトコルのURIやCookie情報などのアプリケーション層の情報を解析して7層化を実現します。負荷分散。このタイプのロード バランサはアプリケーション プロトコルを理解します。
7 層の負荷分散を実装するソフトウェアには次のものが含まれます:
haproxy: 負荷分散テクノロジを生成し、7 層のプロキシ、セッション永続性、マーキング、およびパス転送を完全にサポートします。 ## nginx: http プロトコルとメール プロトコルでのみ優れた機能を備えており、そのパフォーマンスは haproxy に似ています;
apache: 機能が不十分
Mysql プロキシ: 機能は許容範囲内です。
一般的に、lvs は通常 4 層のロードを実行します。nginx は 7 層のロードを実行します (ストリーム モジュールを通じて 4 層のロードも実行できます)。haproxy はより柔軟で、4 層のロードを実行します。層と7層の負荷をバランスよく行うことができます。
いわゆる 4 層の負荷分散。つまり、主にメッセージ内の宛先アドレスとポートに加え、負荷によって設定されたサーバー選択方法に基づきます。バランシング デバイス、最終的な選択を決定します 内部サーバー。 一般的な TCP を例にとると、負荷分散デバイスはクライアントから最初の SYN リクエストを受信すると、上記の方法で最適なサーバーを選択し、メッセージ内のターゲット IP アドレスを変更します。バックエンド サーバー IP) を使用してサーバーに直接転送されます。 TCP 接続の確立、つまり 3 ウェイ ハンドシェイクはクライアントとサーバーの間で直接確立され、負荷分散デバイスはルーターのような転送アクションとしてのみ機能します。導入状況によっては、サーバーからのパケットがロード バランシング デバイスに正しく返されることを保証するために、パケットの転送中にパケットの元の送信元アドレスが変更される場合があります。
いわゆる 7 層の負荷分散 (「コンテンツ スイッチング」とも呼ばれる) は、主に実際のメッセージ内のコンテンツ 意味のあるアプリケーション層のコンテンツと、負荷分散デバイスによって設定されたサーバー選択方法とが組み合わされて、最終的な内部サーバーの選択が決定されます。 一般的な TCP を例にとると、負荷分散デバイスが実際のアプリケーション層のコンテンツに基づいてサーバーを選択したい場合、最終的なサーバーとクライアントの間の接続 (3 ウェイ ハンドシェイク) のみを受け入れることができます。クライアントは実際のアプリケーション層のコンテンツを含むメッセージを送信し、メッセージ内の特定のフィールドと負荷分散デバイスによって設定されたサーバー選択方法に基づいて、最終的に選択される内部サーバーが決定されます。この場合の負荷分散デバイスはプロキシ サーバーに似ています。負荷分散、フロントエンド クライアントとバックエンド サーバーはそれぞれ TCP 接続を確立します。したがって、この技術原理の観点から、7 層負荷分散は負荷分散装置に対する要求が明らかに高く、7 層の処理能力は 4 層モードの展開方法よりも必然的に低くなります。
は中間トランスポート層で実行され、メッセージの配信は処理されますが、メッセージの配信は考慮されません。メッセージの内容。たとえば、TCP は、ネットワーク上のハイパーテキスト転送プロトコル (HTTP) トラフィックのレイヤー 4 プロトコルです。このプロセス中、レイヤー 4 ロード バランシングはネットワーク パケットを上流サーバーに転送しますが、パケットの内容は検査せず、TCP ストリームの最初の数パケットを検査することによってのみ限定的なルーティング決定を行うことができます。
7 層負荷分散4 層負荷分散とは異なり、高レベルのアプリケーション層で実行され、各メッセージの実際のコンテンツが処理されます。 。 HTTP は、Web 上の Web サイト トラフィックの主要なレイヤー 7 プロトコルです。レイヤ 7 ロード バランシングは、レイヤ 4 ロード バランシングよりも複雑な方法でネットワーク トラフィックをルーティングし、特に TCP ベースのトラフィック (HTTP など) に適しています。レイヤ 7 ロード バランシングは、ネットワーク トラフィックを終了し、サーバー内のメッセージを読み取り、メッセージ コンテンツ (URL や Cookie など) に基づいてロード バランシングを決定できます。その後、7 層の負荷分散によって、選択されたサーバーとの新しい TCP 接続が確立され、サーバーにリクエストが書き込まれます。
簡単に言えば、この 2 つの違いは次のとおりです。- 7 層負荷分散は基本的に http プロトコルに基づいており、Web サーバーの負荷分散に適しています。 (nginx) 7 層ロード バランシングは、パケット ベースの 4 層ロード バランシングよりも効率的です。 -layer 負荷分散 CPU を消費しますが、サーバーのパフォーマンス低下を引き起こすことはほとんどありません。 7 層の負荷分散により、ロード バランサーはより多くの情報に基づいた決定を下し、圧縮や暗号化などのコンテンツの最適化や変更を行うことができます。レイヤ 7 ロード バランシングでは、バッファリングを使用して上流のサーバーから遅い接続をオフロードすることもできるため、パフォーマンスが向上します。 7 層負荷分散の例 簡単な例として、ユーザーがトラフィックの多い Web サイトにアクセスしたとします。静的コンテンツ (画像やビデオなど)、動的コンテンツ (ニュースフィードなど)、またはトランザクション情報 (注文ステータスなど) などを要求する場合があります。レイヤ 7 ロード バランシングにより、ロード バランサはコンテンツ タイプなど、リクエスト自体内のメッセージに基づいてリクエストをルーティングできます。つまり、画像またはビデオのリクエストは、それを保存し、マルチメディア コンテンツを提供するために高度に最適化されたサーバーにルーティングでき、割引価格などの取引情報のリクエストは、価格管理を担当するアプリケーション サーバーにルーティングできます。レイヤ 7 負荷分散を使用すると、ネットワークおよびアプリケーションのアーキテクトは、信頼性を確保しながら効率的に拡張できる、高度に最適化されたサーバー インフラストラクチャやアプリケーション配信ネットワークを作成できます。 上記の比較から、4 層負荷と 7 層負荷の最大の違いは、効率と負荷の違いであるように見えます。機能性。 4 層負荷分散の設計は比較的シンプルで、特定のメッセージ コンテンツを解析する必要がなく、比較的高いネットワーク スループットと処理能力を備えています。7 層負荷分散の利点は、その複数の機能と柔軟で強力な制御に反映されています。 。特定のビジネス アーキテクチャを設計する場合、特定の状況に基づいて 7 層または 4 層の負荷の使用を考慮する必要があります。 TCP メッセージの送信元アドレスと宛先アドレスを変更することで、Web サーバーから返されたデータが直接クライアントに返されます。これは、7 層の負荷分散では実行できないことです。 TCP スリーウェイ ハンドシェイク。クライアントとロード バランシング サーバー間で確立され、http プロトコルは tcp プロトコルに基づいています。tcp リンクが確立された後、http メッセージが送信されます。http メッセージの受信は、ロード バランサとロード バランサがクライアントは TCP 接続を確立しましたが、Web サーバーとクライアントの TCP 接続が確立されていません。クライアントにデータを返すにはどうすればよいですか?上記の方法では問題が発生します。クラスタ内のすべてのホストが内部 IP アドレスを持ち、外部と通信できません。 使用するために非常に多くの外部 IP アドレスを購入できる場合は、TCP リンクの接続時にそれらのアドレスを実際の IP アドレスに負荷分散します。 Web サーバーにより、クライアントとサーバーが TCP リンクを確立できるようになります。 解決策 2: 7 つの利点-layer アプリケーションの負荷 は、ネットワーク全体をより「インテリジェント」にするためのものです。たとえば、Web サイトを訪問するユーザー トラフィックは、画像のリクエストを特定の画像サーバーに転送し、7 層アプローチを通じてキャッシュ テクノロジを使用することができ、テキストのリクエストは特定のテキスト サーバーに転送して圧縮を使用できます。もちろん、これは 7 層アプリケーションのほんの小さな例にすぎませんが、技術的な観点から見ると、この方法はクライアントのリクエストとサーバーの応答をあらゆる意味で変更できるため、ネットワーク層でのアプリケーション システムの柔軟性が大幅に向上します。 Nginx や Apache など、バックグラウンドでデプロイされる多くの機能 (クライアント リクエストのヘッダー書き換え、サーバー応答でのキーワード フィルタリングやコンテンツ挿入、その他の機能など) を負荷分散デバイスに移動できます。 よく言及されるもう 1 つの機能はセキュリティです。ネットワークで最も一般的な SYN フラッド攻撃は、ハッカーが多数のソース クライアントを制御し、偽の IP アドレスを使用して同じターゲットに SYN 攻撃を送信するものです。通常、この攻撃は大量の SYN メッセージを送信し、サーバー上の関連リソースを使い果たします。サービス拒否 (DoS) の目的を達成します。また、4 層モードでは、これらの SYN 攻撃はバックエンド サーバーに転送され、7 層モードでは、これらの SYN 攻撃は負荷分散デバイスで自然に終了し、バックエンド サーバーの通常の動作には影響しません。さらに、負荷分散デバイスは 7 層レベルで複数のポリシーを設定し、SQL インジェクションやその他のアプリケーション レベルの攻撃方法などの特定のメッセージをフィルタリングして、アプリケーション レベルからシステム全体のセキュリティをさらに向上させることができます。 本当に必要ですか。 7 層アプリケーションは確かにトラフィック インテリジェンスを向上させることができますが、同時に、複雑なデバイス構成、負荷分散の負荷の増大、トラブルシューティングの複雑さなどの問題が必然的に発生します。システム設計時には、4層と7層の同時適用が混在する状況を考慮する必要があります。 セキュリティは本当に改善できるかどうか。たとえば、SYN フラッド攻撃、7 層モードはサーバーからのこれらのトラフィックをブロックしますが、負荷分散デバイス自体には強力な DDoS 対策機能が必要です。そうでない場合は、サーバーが正常で負荷分散デバイスがサーバーとして使用されている場合でも、中央のスケジューリングが失敗すると、アプリケーション全体が崩壊します。 十分な柔軟性がありますか? 7 層アプリケーションの利点は、アプリケーション全体のトラフィックをインテリジェントにできることですが、負荷分散デバイスは、さまざまな状況に応じて顧客のアプリケーションベースのスケジューリングを満たすために完全な 7 層の機能を提供する必要があります。最も単純な評価は、Nginx や Apache などのバックエンド サーバー上のスケジューリング機能を置き換えることができるかどうかです。 7層のアプリケーション開発インターフェースを提供できるロードバランシングデバイスにより、お客様のニーズに合わせて機能を設定することができ、強力な柔軟性とインテリジェンスの提供が可能になります。 4.1) インテリジェンス レイヤ 7 ロード バランシングには、OIS のレイヤ 7 のすべての機能があるため、理論的には、7 層モデルではサーバーに対するすべてのユーザー リクエストを変更できます。たとえば、ファイル ヘッダーに情報を追加し、さまざまなファイル タイプに応じて分類して転送します。 4 層モデルは、ネットワーク層に基づくデマンド転送のみをサポートし、ユーザー要求の内容を変更することはできません。 4.2) セキュリティ 7 層の負荷分散には OSI モデルのすべての機能があるため、ネットワークからの攻撃にさらに簡単に抵抗できます。レイヤー モデルは、ユーザーのリクエストをバックエンド ノードに直接転送しても、ネットワーク攻撃に直接抵抗することはできません。 4.3) 複雑さ 一般に、4 層モデルは比較的単純なアーキテクチャであり、管理が容易で、問題の特定が容易です。7 層モデル アーキテクチャはより複雑です。通常、4 層モデルの組み合わせを検討する必要があります。混合ユースケースでは、問題の特定がより複雑になります。 4.4) 効率率 ソフトウェア負荷分散ソリューションとは、DNS負荷分散、CheckPoint Firewall-1 ConnectControl、Keepalive ipvsなどの負荷分散を実現するために、1つまたは複数のサーバーの対応するオペレーティング システムに1つまたは複数の追加ソフトウェアをインストールすることを指します。特定の環境、シンプルな構成、柔軟な使用、低コストに基づいており、一般的な負荷分散のニーズを満たすことができます。 ソフトウェア ソリューションには多くの欠点もあります。各サーバーに追加のソフトウェアをインストールするとシステム リソースが無制限に消費されるためです。モジュールが強力であればあるほど、より多くのリソースが消費されます。そのため、接続要求が特に大きい場合、ソフトウェア自体がサーバーの成否の鍵となる、ソフトウェアの拡張性があまり良くなく、オペレーティング システムによって制限される、オペレーティング システム自体のバグがセキュリティ上の問題を引き起こすことがよくあります。 ハードウェア負荷分散ソリューションは、サーバーと外部ネットワークの間に負荷分散デバイスを直接インストールすることです。このデバイスは通常、システムから独立したハードウェアの一部です。ロードバランシングデバイスと呼ばれます。 特殊な機器が特殊なタスクを実行し、オペレーティング システムから独立しているため、全体的なパフォーマンスが大幅に向上し、多様なロード バランシング戦略とインテリジェントなトラフィック管理と組み合わせることで、最適なロード バランシング要件を達成できます。ロードバランサにはさまざまな形態があり、独立したロードバランサのほか、スイッチング装置に組み込まれてサーバとインターネット回線の間に配置されるもの、ネットワークアダプタを2つ使用して接続するものなど、機能が統合されているものがあります。 PC の 1 台はインターネットに接続され、もう 1 台はバックエンド サーバー ファームの内部ネットワークに接続されています。 ソフトウェア負荷分散とハードウェア負荷分散の比較: ソフトウェア負荷分散の利点は、明確な需要環境、シンプルな構成、および柔軟性です。低コストで効率的ではなく、一般企業のニーズを満たすことができます。欠点は、システムに依存し、リソースのオーバーヘッドが増加することです。ソフトウェアの品質が環境のパフォーマンスを決定します。システムのセキュリティソフトウェアの安定性は環境全体のセキュリティに影響します。 ハードウェア負荷分散の利点は、システムから独立しており、全体的なパフォーマンスが大幅に向上し、機能とパフォーマンスの点でソフトウェア方式よりも優れていることです。インテリジェントなトラフィック管理、複数の戦略が可能です。オプションであり、最高の負荷分散効果を実現できますが、欠点は高価であることです。 ロード バランシングは、地理的構造に基づいて ローカル ロード バランス(ローカル ロード バランス)に分割されます。そのアプリケーションとグローバル ロード バランス (グローバル ロード バランス、リージョン ロード バランシングとも呼ばれます)、ローカル ロード バランシングはローカル サーバー グループのロード バランシングを指します。グローバル ロード バランシングは、地理的に異なる場所に配置されたサーバーのロード バランシングを指します。異なるネットワーク構造を持つサーバー グループ間の負荷分散。 ローカル負荷分散は、過剰なデータトラフィックと過負荷のネットワークの問題を効果的に解決でき、優れたパフォーマンスのサーバーを購入するために高価な費用を費やす必要がなく、既存の機器を最大限に活用できます。サーバーの単一障害点によりデータ トラフィックの損失が発生することを回避します。柔軟で多様なバランシング戦略を備えており、負荷を共有するためにサーバー グループ内のサーバーにデータ トラフィックを合理的に割り当てます。既存のサーバーを拡張・アップグレードする場合でも、既存のネットワーク構成を変更したり、既存のサービスを停止したりすることなく、サービスグループに新しいサーバーを追加するだけで済みます。 グローバル負荷分散は、主にマルチリージョンに独自のサーバーを持つサイトで使用され、グローバル ユーザーが 1 つの IP アドレスだけで最も近いサーバーにアクセスできるようにするため、または最速のアクセス速度を得るために、分散した子会社や広範囲に分散した拠点を持つ大企業でも、イントラネット (社内インターネット) を介したリソースの統一的かつ合理的な割り当てを実現するために、このドメイン名を使用することもできます。 ネットワークが過負荷になっているさまざまなボトルネックに応じて、ネットワークのさまざまなレベルから開始して、対応する負荷分散を使用できます。既存の問題を解決するテクノロジー。 帯域幅が増加し、データ トラフィックが増加し続けると、ネットワークのコア部分のデータ インターフェイスがボトルネックの問題に直面します。元の単一回線では需要を満たすことが困難になり、回線のアップグレードは費用がかかりすぎます。現時点では、リンク アグリゲーション (トランキング) テクノロジーの使用を検討できます。 リンク アグリゲーション テクノロジ (レイヤ 2 ロード バランシング) は、複数の物理リンクを 1 つの集約された論理リンクとして使用します。ネットワーク データ トラフィックは、集約された論理リンク内のすべての物理リンクによって共有されます。これにより、リンクの容量が論理的に増加します。増加する帯域幅需要に対応できるということです。 最新の負荷分散テクノロジは通常、ネットワークの 4 番目または 7 番目の層で動作します。レイヤ 4 負荷分散は、インターネット上で合法的に登録された IP アドレスを複数の内部サーバーの IP アドレスにマッピングし、TCP 接続要求ごとに内部 IP アドレスの 1 つを動的に使用して負荷分散を実現します。レイヤ 4 スイッチでは、このバランシング テクノロジが広く使用されています。宛先アドレスは、サーバ グループの VIP (仮想 IP アドレス) 接続要求データ パケットがスイッチを通過することです。スイッチは、送信元および宛先 IP アドレス、TCP または UDP ポート番号、および特定の負荷分散戦略、サーバー IP と VIP 間のマッピング、および接続要求を処理するサーバー グループ内の最適なサーバーの選択。 7 層の負荷分散は、アプリケーション層サービスのコンテンツを制御し、アクセス トラフィックの高レベルの制御方法を提供し、HTTP サーバー グループ内のアプリケーションに適しています。レイヤ 7 負荷分散テクノロジーは、通過する HTTP ヘッダーをチェックし、ヘッダー内の情報に基づいて負荷分散タスクを実行します。 7 層負荷分散の利点は次の点で示されます: 1) HTTP ヘッダーをチェックすることで、HTTP400、500、および 600 シリーズのエラーを確認できます。検出された情報を使用して、接続要求を別のサーバーに透過的にリダイレクトし、アプリケーション層の障害を回避します。 7 層負荷分散の欠点は、次の側面に反映されています: 1) 7 層負荷分散は、サポートするプロトコルによって制限されます (通常は、 HTTP) のため、これによりアプリケーションの幅が制限されます。 実際のアプリケーションでは、サーバーがダウンしているかどうかに関係なく、クライアント サービス リクエストを内部サーバーに均等に分散するだけでは不十分な場合があります。 。代わりに、Pentium III サーバーが Pentium II よりも多くのサービス リクエストを受け入れるようにします。処理するサービス リクエストが少ないサーバーには、より多くのサービス リクエストを割り当てることができます。障害が発生したサーバーは、障害が回復するまでサービス リクエストを受け付けなくなります。待機します。適切な負荷分散戦略を選択して、複数のデバイスが一緒にタスクを完了し、不均一なネットワーク負荷分散、データ トラフィックの輻輳、および長い応答時間によって引き起こされる既存のボトルネックを排除または回避できるようにします。各負荷分散方法には、さまざまなアプリケーション要件に基づいて、OSI 参照モデルのレイヤー 2、3、4、および 7 で負荷分散を行うための対応する負荷分散戦略があります。 負荷分散戦略の長所と短所、および実装の容易さには、負荷分散アルゴリズム、ネットワーク システム状態を検出する方法と機能という 2 つの重要な要素があります。 関連する推奨事項: 「Linux ビデオ チュートリアル 」
- 4 層負荷分散 主に TCP プロトコル メッセージに基づいて 、TCP に基づいて何でも実行できます/ip プロトコル ソフトウェアの負荷分散。 (haproxy, LVS)
- 2 つの主な違いは、使用されるメッセージのレベルが異なり、それぞれに独自の利点があることです。
- 7 層アプリケーション負荷の利点は、ネットワーク全体がより「インテリジェント」になることです。たとえば、Web サイトを訪問するユーザー トラフィックは、画像のリクエストを特定の画像サーバーに転送し、7 層アプローチを通じてキャッシュ テクノロジを使用することができ、テキストのリクエストは特定のテキスト サーバーに転送して圧縮を使用できます。もちろん、これは 7 層アプリケーションのほんの小さな例にすぎませんが、技術的な観点から見ると、この方法はクライアントのリクエストとサーバーの応答をあらゆる意味で変更できるため、ネットワーク層でのアプリケーション システムの柔軟性が大幅に向上します。 Nginx や Apache など、バックグラウンドでデプロイされる多くの機能 (クライアント リクエストのヘッダー書き換え、サーバー応答でのキーワード フィルタリングやコンテンツ挿入、その他の機能など) を負荷分散デバイスに移動できます。 #-
レイヤ 4 ロード バランシングは主に柔軟性が高く、さまざまなソフトウェアのロード バランサとして使用できます。 わかりやすく説明するために例を挙げてみましょう: 4 層の負荷分散は銀行のセルフサービス キューイング マシンのようなものです。銀行に到着した各顧客は、順番に従ってサービスを受けるための対応する窓口を選択します。一方、7 層の負荷分散 Qian Qing は、まず顧客が処理する必要がある業務を確認し、次に番号を手配する銀行のロビーマネージャーのようなものです。これにより、財務管理や入出金などを行う顧客が銀行内部のリソースに合わせて連携・対応することで、顧客の業務プロセスが迅速化されます。
レイヤー 7 負荷分散を実行するコンポーネントは、リバース プロキシ サーバーと呼ばれることがよくあります。
ロードバランシング時のデータの流れはすべてロードバランサーを経由しますが、ロードバランサーがボトルネックになる問題を解決するにはどうすればよいでしょうか?
引用: コンピュータの問題はすべて、仮想層を確立することで解決できます。
すべてのサーバー ホスト IP を負荷分散サーバー IP に仮想化し、サーバー クラスター内のすべてのホストが外部ネットワークにアクセスできるようにすることができます。IP アドレス (ネットワーク層、3 層) が同じであるため、それらは通過することしかできません。 2 番目の層ではデータ フローの方向を識別し、データ リンク層 (層 2) で宛先ホストの MAC アドレスを変更して、リクエストが Web サーバーに送信され、実際に TCP 接続が確立されます。 Web サーバーはインターネットに接続できるため、クライアントにデータを直接返すことができます
2) アプリケーション シナリオの要件を分析します
3) 7 層アプリケーションで考慮すべき問題
3.1) 4) 全体的な比較
4 層モデルは下位レベルの設定に基づいており、通常はより効率的ですが、適用範囲が限られています。7 層モデルはより多くのリソース消費を必要とします。理論的には 4 層モデルよりも効率的です。4 層モデルはより強力な機能を備えており、現在の実装は http アプリケーションに基づいています。
4. 負荷分散技術ソリューションの説明
1) ソフトウェア/ハードウェア負荷分散
2) ローカル/グローバル ロード バランシング
3) ネットワーク レベルでの負荷分散
2) 通過するデータの種類 (データ パケットが画像ファイル、圧縮ファイル、マルチメディア ファイル形式のいずれであるかなど) に応じて、データ トラフィックを対応するコンテンツのサーバーに送信できます。処理に使用され、システムのパフォーマンスが向上します。
3) 接続要求のタイプに応じて、それが通常のテキストや画像などの静的ドキュメント要求であるか、ASP、CGI などの動的ドキュメント要求であるかに応じて、対応する要求を対応する接続要求に送信できます。サーバーで処理することで、システムのパフォーマンスと安全性が向上します。
2) HTTP ヘッダーの 7 層の負荷分散チェックは、大量のシステム リソースを占有し、必然的にシステムのパフォーマンスに影響を及ぼします。多数の接続要求の場合、負荷分散デバイス自体がネットワーク全体のパフォーマンスのボトルネックになりやすいです。
5. 負荷分散戦略
負荷分散アルゴリズム
1) ラウンド ロビン : ネットワークからの各リクエストは、1 から N まで順番に内部サーバーに割り当てられ、その後再び開始されます。このバランシング アルゴリズムは、サーバー グループ内のすべてのサーバーが同じハードウェアおよびソフトウェア構成を持ち、平均的なサービス リクエストが比較的バランスがとれている状況に適しています。
2) 加重ラウンドロビン : サーバーのさまざまな処理能力に応じて、各サーバーに異なる重みが割り当てられ、対応する重みでサービス リクエストを受け入れることができます。たとえば、サーバー A の重みは 1、B の重みは 3、C の重みは 6 になるように設計されている場合、サーバー A、B、および C は 10%、30%、および 60% のサービスを受け取ることになります。それぞれリクエストします。このバランシング アルゴリズムにより、高性能サーバーの使用率が向上し、低パフォーマンス サーバーの過負荷が防止されます。
3) ランダムバランス (ランダム) : ネットワークからのリクエストを複数の内部サーバーにランダムに分散します。
4) 加重ランダム バランシング (加重ランダム): このバランシング アルゴリズムは加重ラウンドロビン アルゴリズムに似ていますが、リクエストの共有を処理する際のランダムな選択プロセスです。
5) 応答速度のバランシング (応答時間) : 負荷分散デバイスは、各内部サーバーに検出リクエスト (Ping など) を送信し、各内部サーバーの最速の応答時間に基づいて、クライアントのサービス要求に応答するサーバーを決定します。このバランシング アルゴリズムは、サーバーの現在の実行ステータスをより適切に反映できますが、最速の応答時間は、負荷分散デバイスとサーバー間の最速の応答時間を指すだけであり、クライアントとサーバー間の最速の応答時間ではありません。
6) 最小接続バランス : 各クライアント要求サービスがサーバー上に滞留する時間には大きな差が生じる可能性があります。作業時間が長くなるにつれて、単純なラウンドロビンを使用する場合は、循環またはランダムを使用します。分散アルゴリズムを使用すると、各サーバーの接続プロセスが大きく異なる可能性があり、真の負荷分散は実現されません。最小接続数バランシング アルゴリズムには、内部的に読み込む必要がある各サーバーのデータ レコードがあり、サーバーによって現在処理されている接続数が記録されます。新しいサービス接続リクエストがある場合、現在のリクエストはサービス接続リクエストに割り当てられます。接続数が最も少ないサーバーを使用すると、バランスが実際の状況により一致し、負荷がより分散されます。このバランシング アルゴリズムは、FTP などの長期処理リクエスト サービスに適しています。
7) 処理能力のバランシング: このバランシング アルゴリズムは、サービス リクエストを内部処理負荷 (サーバーの CPU モデル、CPU 数、メモリ サイズ、現在の接続数などに基づいて変換) に割り当てます。 ) 軽量サーバーの場合、このバランシング アルゴリズムは、特にレイヤー 7 (アプリケーション層) のロード バランシングに適用される場合、内部サーバーの処理能力と現在のネットワーク動作条件を考慮するため、比較的正確です。
8) DNS 応答バランシング (Flash DNS) : インターネット上では、HTTP、FTP、その他のサービス要求のいずれであっても、クライアントは通常、ドメイン名解決を通じてサーバーの正確な IP アドレスを見つけます。の。このバランシング アルゴリズムでは、地理的に異なる場所にある負荷バランシング デバイスが同じクライアントからドメイン名解決要求を受信し、同時にドメイン名を対応するサーバー (つまり、負荷バランシング デバイス) の IP アドレスに解決します。同じ地理的位置にあるサーバーの IP アドレス）を取得してクライアントに返すと、クライアントは最初に受信したドメイン名解決 IP アドレスを使用してサービスを要求し続け、他の IP アドレス応答を無視します。このバランシング戦略がグローバルなロード バランシングには適している場合でも、ローカルなロード バランシングには意味がありません。
以上がLinux にはいくつかの種類の負荷分散がありますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
