Linux にはいくつかの種類の負荷分散があります

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:
引用: コンピュータの問題はすべて、仮想層を確立することで解決できます。
すべてのサーバー ホスト IP を負荷分散サーバー IP に仮想化し、サーバー クラスター内のすべてのホストが外部ネットワークにアクセスできるようにすることができます。IP アドレス (ネットワーク層、3 層) が同じであるため、それらは通過することしかできません。 2 番目の層ではデータ フローの方向を識別し、データ リンク層 (層 2) で宛先ホストの MAC アドレスを変更して、リクエストが Web サーバーに送信され、実際に TCP 接続が確立されます。 Web サーバーはインターネットに接続できるため、クライアントにデータを直接返すことができます

2) アプリケーション シナリオの要件を分析します

7 つの利点-layer アプリケーションの負荷 は、ネットワーク全体をより「インテリジェント」にするためのものです。たとえば、Web サイトを訪問するユーザー トラフィックは、画像のリクエストを特定の画像サーバーに転送し、7 層アプローチを通じてキャッシュ テクノロジを使用することができ、テキストのリクエストは特定のテキスト サーバーに転送して圧縮を使用できます。もちろん、これは 7 層アプリケーションのほんの小さな例にすぎませんが、技術的な観点から見ると、この方法はクライアントのリクエストとサーバーの応答をあらゆる意味で変更できるため、ネットワーク層でのアプリケーション システムの柔軟性が大幅に向上します。 Nginx や Apache など、バックグラウンドでデプロイされる多くの機能 (クライアント リクエストのヘッダー書き換え、サーバー応答でのキーワード フィルタリングやコンテンツ挿入、その他の機能など) を負荷分散デバイスに移動できます。

よく言及されるもう 1 つの機能はセキュリティです。ネットワークで最も一般的な SYN フラッド攻撃は、ハッカーが多数のソース クライアントを制御し、偽の IP アドレスを使用して同じターゲットに SYN 攻撃を送信するものです。通常、この攻撃は大量の SYN メッセージを送信し、サーバー上の関連リソースを使い果たします。サービス拒否 (DoS) の目的を達成します。また、4 層モードでは、これらの SYN 攻撃はバックエンド サーバーに転送され、7 層モードでは、これらの SYN 攻撃は負荷分散デバイスで自然に終了し、バックエンド サーバーの通常の動作には影響しません。さらに、負荷分散デバイスは 7 層レベルで複数のポリシーを設定し、SQL インジェクションやその他のアプリケーション レベルの攻撃方法などの特定のメッセージをフィルタリングして、アプリケーション レベルからシステム全体のセキュリティをさらに向上させることができます。

3) 7 層アプリケーションで考慮すべき問題

本当に必要ですか。 7 層アプリケーションは確かにトラフィック インテリジェンスを向上させることができますが、同時に、複雑なデバイス構成、負荷分散の負荷の増大、トラブルシューティングの複雑さなどの問題が必然的に発生します。システム設計時には、4層と7層の同時適用が混在する状況を考慮する必要があります。

セキュリティは本当に改善できるかどうか。たとえば、SYN フラッド攻撃、7 層モードはサーバーからのこれらのトラフィックをブロックしますが、負荷分散デバイス自体には強力な DDoS 対策機能が必要です。そうでない場合は、サーバーが正常で負荷分散デバイスがサーバーとして使用されている場合でも、中央のスケジューリングが失敗すると、アプリケーション全体が崩壊します。

十分な柔軟性がありますか? 7 層アプリケーションの利点は、アプリケーション全体のトラフィックをインテリジェントにできることですが、負荷分散デバイスは、さまざまな状況に応じて顧客のアプリケーションベースのスケジューリングを満たすために完全な 7 層の機能を提供する必要があります。最も単純な評価は、Nginx や Apache などのバックエンド サーバー上のスケジューリング機能を置き換えることができるかどうかです。 7層のアプリケーション開発インターフェースを提供できるロードバランシングデバイスにより、お客様のニーズに合わせて機能を設定することができ、強力な柔軟性とインテリジェンスの提供が可能になります。

4) 全体的な比較

4.1) インテリジェンス レイヤ 7 ロード バランシングには、OIS のレイヤ 7 のすべての機能があるため、理論的には、7 層モデルではサーバーに対するすべてのユーザー リクエストを変更できます。たとえば、ファイル ヘッダーに情報を追加し、さまざまなファイル タイプに応じて分類して転送します。 4 層モデルは、ネットワーク層に基づくデマンド転送のみをサポートし、ユーザー要求の内容を変更することはできません。

4.2) セキュリティ 7 層の負荷分散には OSI モデルのすべての機能があるため、ネットワークからの攻撃にさらに簡単に抵抗できます。レイヤー モデルは、ユーザーのリクエストをバックエンド ノードに直接転送しても、ネットワーク攻撃に直接抵抗することはできません。

4.3) 複雑さ 一般に、4 層モデルは比較的単純なアーキテクチャであり、管理が容易で、問題の特定が容易です。7 層モデル アーキテクチャはより複雑です。通常、4 層モデルの組み合わせを検討する必要があります。混合ユースケースでは、問題の特定がより複雑になります。

4.4) 効率率
4 層モデルは下位レベルの設定に基づいており、通常はより効率的ですが、適用範囲が限られています。7 層モデルはより多くのリソース消費を必要とします。理論的には 4 層モデルよりも効率的です。4 層モデルはより強力な機能を備えており、現在の実装は http アプリケーションに基づいています。

4. 負荷分散技術ソリューションの説明

1) ソフトウェア/ハードウェア負荷分散

ソフトウェア負荷分散ソリューションとは、DNS負荷分散、CheckPoint Firewall-1 ConnectControl、Keepalive ipvsなどの負荷分散を実現するために、1つまたは複数のサーバーの対応するオペレーティング システムに1つまたは複数の追加ソフトウェアをインストールすることを指します。特定の環境、シンプルな構成、柔軟な使用、低コストに基づいており、一般的な負荷分散のニーズを満たすことができます。 ソフトウェア ソリューションには多くの欠点もあります。各サーバーに追加のソフトウェアをインストールするとシステム リソースが無制限に消費されるためです。モジュールが強力であればあるほど、より多くのリソースが消費されます。そのため、接続要求が特に大きい場合、ソフトウェア自体がサーバーの成否の鍵となる、ソフトウェアの拡張性があまり良くなく、オペレーティング システムによって制限される、オペレーティング システム自体のバグがセキュリティ上の問題を引き起こすことがよくあります。

ハードウェア負荷分散ソリューションは、サーバーと外部ネットワークの間に負荷分散デバイスを直接インストールすることです。このデバイスは通常、システムから独立したハードウェアの一部です。ロードバランシングデバイスと呼ばれます。 特殊な機器が特殊なタスクを実行し、オペレーティング システムから独立しているため、全体的なパフォーマンスが大幅に向上し、多様なロード バランシング戦略とインテリジェントなトラフィック管理と組み合わせることで、最適なロード バランシング要件を達成できます。ロードバランサにはさまざまな形態があり、独立したロードバランサのほか、スイッチング装置に組み込まれてサーバとインターネット回線の間に配置されるもの、ネットワークアダプタを2つ使用して接続するものなど、機能が統合されているものがあります。 PC の 1 台はインターネットに接続され、もう 1 台はバックエンド サーバー ファームの内部ネットワークに接続されています。

ソフトウェア負荷分散とハードウェア負荷分散の比較:

ソフトウェア負荷分散の利点は、明確な需要環境、シンプルな構成、および柔軟性です。低コストで効率的ではなく、一般企業のニーズを満たすことができます。欠点は、システムに依存し、リソースのオーバーヘッドが増加することです。ソフトウェアの品質が環境のパフォーマンスを決定します。システムのセキュリティソフトウェアの安定性は環境全体のセキュリティに影響します。

ハードウェア負荷分散の利点は、システムから独立しており、全体的なパフォーマンスが大幅に向上し、機能とパフォーマンスの点でソフトウェア方式よりも優れていることです。インテリジェントなトラフィック管理、複数の戦略が可能です。オプションであり、最高の負荷分散効果を実現できますが、欠点は高価であることです。

2) ローカル/グローバル ロード バランシング

ロード バランシングは、地理的構造に基づいて ローカル ロード バランス(ローカル ロード バランス)に分割されます。そのアプリケーションとグローバル ロード バランス (グローバル ロード バランス、リージョン ロード バランシングとも呼ばれます)、ローカル ロード バランシングはローカル サーバー グループのロード バランシングを指します。グローバル ロード バランシングは、地理的に異なる場所に配置されたサーバーのロード バランシングを指します。異なるネットワーク構造を持つサーバー グループ間の負荷分散。

ローカル負荷分散は、過剰なデータトラフィックと過負荷のネットワークの問題を効果的に解決でき、優れたパフォーマンスのサーバーを購入するために高価な費用を費やす必要がなく、既存の機器を最大限に活用できます。サーバーの単一障害点によりデータ トラフィックの損失が発生することを回避します。柔軟で多様なバランシング戦略を備えており、負荷を共有するためにサーバー グループ内のサーバーにデータ トラフィックを合理的に割り当てます。既存のサーバーを拡張・アップグレードする場合でも、既存のネットワーク構成を変更したり、既存のサービスを停止したりすることなく、サービスグル​​ープに新しいサーバーを追加するだけで済みます。

グローバル負荷分散は、主にマルチリージョンに独自のサーバーを持つサイトで使用され、グローバル ユーザーが 1 つの IP アドレスだけで最も近いサーバーにアクセスできるようにするため、または最速のアクセス速度を得るために、分散した子会社や広範囲に分散した拠点を持つ大企業でも、イントラネット (社内インターネット) を介したリソースの統一的かつ合理的な割り当てを実現するために、このドメイン名を使用することもできます。

3) ネットワーク レベルでの負荷分散

ネットワークが過負荷になっているさまざまなボトルネックに応じて、ネットワークのさまざまなレベルから開始して、対応する負荷分散を使用できます。既存の問題を解決するテクノロジー。

帯域幅が増加し、データ トラフィックが増加し続けると、ネットワークのコア部分のデータ インターフェイスがボトルネックの問題に直面します。元の単一回線では需要を満たすことが困難になり、回線のアップグレードは費用がかかりすぎます。現時点では、リンク アグリゲーション (トランキング) テクノロジーの使用を検討できます。

リンク アグリゲーション テクノロジ (レイヤ 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 シリーズのエラーを確認できます。検出された情報を使用して、接続要求を別のサーバーに透過的にリダイレクトし、アプリケーション層の障害を回避します。
2) 通過するデータの種類 (データ パケットが画像ファイル、圧縮ファイル、マルチメディア ファイル形式のいずれであるかなど) に応じて、データ トラフィックを対応するコンテンツのサーバーに送信できます。処理に使用され、システムのパフォーマンスが向上します。
3) 接続要求のタイプに応じて、それが通常のテキストや画像などの静的ドキュメント要求であるか、ASP、CGI などの動的ドキュメント要求であるかに応じて、対応する要求を対応する接続​​要求に送信できます。サーバーで処理することで、システムのパフォーマンスと安全性が向上します。

7 層負荷分散の欠点は、次の側面に反映されています:

1) 7 層負荷分散は、サポートするプロトコルによって制限されます (通常は、 HTTP) のため、これによりアプリケーションの幅が制限されます。
2) HTTP ヘッダーの 7 層の負荷分散チェックは、大量のシステム リソースを占有し、必然的にシステムのパフォーマンスに影響を及ぼします。多数の接続要求の場合、負荷分散デバイス自体がネットワーク全体のパフォーマンスのボトルネックになりやすいです。

5. 負荷分散戦略

実際のアプリケーションでは、サーバーがダウンしているかどうかに関係なく、クライアント サービス リクエストを内部サーバーに均等に分散するだけでは不十分な場合があります。 。代わりに、Pentium III サーバーが Pentium II よりも多くのサービス リクエストを受け入れるようにします。処理するサービス リクエストが少ないサーバーには、より多くのサービス リクエストを割り当てることができます。障害が発生したサーバーは、障害が回復するまでサービス リクエストを受け付けなくなります。待機します。適切な負荷分散戦略を選択して、複数のデバイスが一緒にタスクを完了し、不均一なネットワーク負荷分散、データ トラフィックの輻輳、および長い応答時間によって引き起こされる既存のボトルネックを排除または回避できるようにします。各負荷分散方法には、さまざまなアプリケーション要件に基づいて、OSI 参照モデルのレイヤー 2、3、4、および 7 で負荷分散を行うための対応する負荷分散戦略があります。

負荷分散戦略の長所と短所、および実装の容易さには、負荷分散アルゴリズム、ネットワーク システム状態を検出する方法と機能という 2 つの重要な要素があります。
負荷分散アルゴリズム
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 ビデオ チュートリアル 」