要約: この記事では、分散ネットワーク サーバーで使用される負荷分散テクノロジと負荷分散戦略について説明し、ネットワーク アドレス変換に基づく負荷分散ゲートウェイを FreeBSD に実装します。これは、負荷を複数のサーバーに分散するためにインターネット ネットワーク サーバーに適用されます。インターネットサーバーが直面する多数の同時アクセスによって引き起こされるCPUまたはI/Oの高負荷問題を解決します。最適な負荷分散効果を実現するには、負荷コントローラーが各サーバーの現在の CPU および I/O ステータスに応じて負荷を割り当てる必要があります。これには、サーバーの負荷を動的に監視し、均等な負荷を実現するために最適化された負荷分散戦略を適用する必要があります。配布の目的。
キーワード: 負荷分散、ネットワーク アドレス変換、FreeBSD
1. はじめに
インターネットの急速な成長により、マルチメディア ネットワーク サーバーが直面するアクセス数が急増しています。多数の同時アクセス サービスを提供すると、処理能力と I/O 能力がサービスを提供する際のボトルネックになります。単一サーバーのパフォーマンスは常に制限されているため、多数の同時アクセスのニーズを満たすには、マルチサーバーおよび負荷分散テクノロジーを使用する必要があります。
初期の負荷分散テクノロジーは DNS を通じて実装されており、DNS 内の複数のアドレスに対して同じ名前が設定されているため、この名前をクエリするクライアントはいずれかのアドレスを取得し、異なる顧客が異なるサーバーにアクセスできるようにします。 1]。 DNS 負荷分散はシンプルで効果的な方法ですが、サーバー間の違いを区別したり、サーバーの現在の動作状態を反映したりすることはできません。
リバース プロキシ サーバーはリクエストを内部 Web サーバーに転送できます。プロキシ サーバーがリクエストを複数の内部サーバーに均等に転送できれば、負荷分散を実現できます [2]。リバース プロキシ モードでは、最適化された負荷分散戦略を適用でき、サービスを提供するために毎回最もアイドル状態の内部サーバーにアクセスします。しかし、同時接続数が増加すると、プロキシサーバー自体の負荷が非常に大きくなり、最終的にはリバースプロキシサーバー自体がサービスのボトルネックになってしまいます。
負荷分散をサポートするアドレス変換ゲートウェイは、外部 IP アドレスを複数の内部 IP アドレスにマッピングし、TCP 接続要求ごとに内部アドレスの 1 つを動的に使用して、負荷分散の目的を達成できます [3]。多くのハードウェア メーカーは、このテクノロジを第 4 層スイッチングの機能としてスイッチに統合し、負荷を分散するためにサーバー接続数または応答時間に基づいてランダムに選択する負荷分散戦略を使用しています。ただし、ハードウェアによって実装される負荷コントローラーは柔軟性があまりなく、より最適化された負荷分散戦略やより複雑なアプリケーション プロトコルをサポートできません。
これらの 3 つの負荷分散方法に加えて、一部のプロトコルは HTTP プロトコルのリダイレクト機能など、負荷分散関連の機能を内部的にサポートしていますが、特定のプロトコルに依存するため、使用範囲は限定されます。これらの既存の負荷分散テクノロジーに基づいて、ハードウェア ロード バランサーの柔軟性の低さを補うためにソフトウェアを使用してネットワーク アドレス変換負荷分散を実装することを選択し、最適化された分散戦略を適用してバックエンド サーバーの最適な負荷分散を実現しました。状態。
2. 負荷分散戦略
複数の内部サーバーに負荷を均等に分散するには、特定の負荷分散戦略を適用する必要があります。従来の負荷分散戦略では、さまざまな種類のサービス リクエスト、バックエンド サーバーのさまざまな機能、ランダムな選択によって生じる不均一な負荷分散が考慮されていません。負荷分散を非常に均一にするためには、各サーバーの CPU および I/O ステータスを正確に反映できる負荷分散戦略を適用する必要があります [4]。
顧客によって開始されるサービスリクエストにはさまざまな種類があり、プロセッサ、ネットワーク、および I/O のリソース要件に応じて、異なる処理戦略を適用するために単純に 2 つの異なるカテゴリに分類できます。
静的ドキュメント。リクエスト: たとえば、通常のテキスト、画像、その他の静的マルチメディア データはプロセッサの負荷にほとんど影響を与えません。発生するディスク I/O 負荷はドキュメントのサイズに比例し、主にネットワーク I/O に圧力をかけます。
動的なドキュメント リクエスト: より一般的なリクエストでは、データベースの検索、マルチメディア ファイルの圧縮と解凍など、サーバーによる前処理が必要になることがよくあります。これらのリクエストは、かなりのプロセッサとディスク I/O リソースを必要とします。
静的ドキュメントの場合、各サービス プロセスはほぼ同じシステム リソースを占有するため、プロセス数を使用してシステム負荷を表すことができます。動的ドキュメント サービスには追加の処理が必要であり、静的リクエストの処理よりも多くのシステム リソースを占有するため、重みで表す必要があります。このような最も単純なサーバー負荷の式は次のとおりです。
ここで、L はサーバーの負荷、Ns は静的ドキュメント サービス プロセスの数、Nd は動的ドキュメント サービス プロセスの数、a は各動的ドキュメント サービスに対する相対的な各動的ドキュメント サービスです。静的ドキュメントサービス 重みは 10 ~ 100 の間で選択できます。
この計算式ではサーバーのハードウェアの制限は考慮されていません。ハードウェアの制限に達すると、リソースの制約によりサーバーの負荷が大幅に増加します。たとえば、サーバーのメモリ サイズの制限により、一部のプロセスをハードディスクにスワップする必要があり、システム負荷が急速に増加します。システムのハードウェア制限を考慮すると、サーバー負荷は次のように表すことができます:
新しく追加されたパラメーター Ll は、このサーバーの通常負荷の制限を表し、各サーバー自体のハードウェア機能に従って設定する必要があります。また、b は、通常の負荷を超えた場合にサーバー タスクの割り当てを制限するために使用される重みを表します。ハードウェア制限の影響を表すには、L1 より大きい値に設定する必要があります。通常、サーバー クラスターでは、すべてのサーバーが過負荷になったときに、最も悪いハードウェアを備えたサーバーの負荷が最も高くなるのを避けるために、より悪いハードウェア設定を備えたサーバーの重みを大きく設定する必要があります。したがって、b はこのサーバーのハードウェア制限 Ll に反比例し、b は次のように設定できます。
Llmax は、サーバー クラスター内で最も高いハードウェア構成を持つサーバーの Ll 値です。各サーバーの負荷が決定されると、負荷分散を制御する中央サーバーが負荷をアイドル状態のサーバーに正しく分散できるため、他の負荷分散戦略のような不均一な負荷分散を防ぐことができます。
3. 実装方法と実験結果
私たちのサーバーシステムは、Fast Ethernet を使用して接続された複数の FreeBSD システムで構成されています。各バックエンド サーバーはデーモン プロセスを実行して自身の負荷状況を動的に取得し、FreeBSD を使用して実装された中央制御ゲートウェイは、これらのデーモン プロセスを通じて各サーバーの負荷を更新し、適切な負荷分散を実行します。
3.1 ロードバランシングをサポートするゲートウェイ
FreeBSD システムでは、ネットワークアドレス変換機能をサポートするために迂回インターフェイスが提供されます。 IP データ パケットは、システム カーネルの ipfw フィルタリング機能を介して宛先インターフェイスに送信されるため、外部デーモン natd は元のデータ パケットを受信して処理し、通常の IP 配布のためにシステム カーネルに送り返すことができます [5] ]。
そのため、FreeBSD のアドレス変換構造に従って、負荷分散機能をサポートする独自のネットワーク アドレス変換デーモンを作成し、FreeBSD システムを負荷分散をサポートするゲートウェイとして使用することができます。ソフトウェアで実装されているため、非標準プロトコルを簡単にサポートし、最適化された負荷分散戦略を適用でき、優れた柔軟性を備えています。
3.2 実験と分析
この実装の使いやすさをテストするために、最も一般的な HTTP プロトコルでテスト実験を実施しました。さまざまなリクエスト タイプを区別するために、パフォーマンスのさまざまな側面をテストする 3 つの異なるタイプのテストが設計されました。
CGI プログラムによって生成された動的ドキュメント: サーバーの処理能力の負荷分散ステータスをテストするために使用されます。
小さな静的ドキュメント: 頻繁な接続の負荷分散ステータスをテストするには、より小さな静的ドキュメントを使用します。
大きな静的ドキュメント: ディスクとネットワーク I/O の負荷分散ステータスをテストするには、より大きなドキュメントを使用します。結果は、1 秒あたりにリクエストを完了する単一サーバーのパフォーマンスに基づいており、負荷分散に複数のサーバーを使用した場合の、1 秒あたりに完了したリクエストの数とベンチマーク リクエストの数の比率を示しています。
図 1: 負荷分散パフォーマンス
上の図の最初の曲線 a は、サーバーの数が増加するにつれて、そのパフォーマンスが指数関数的に増加します。 3 番目の曲線 c は、サイズの小さい静的ドキュメント リクエストを処理し、パフォーマンスの変化はほとんどありません。負荷分散システムが理想的な状態に到達できない理由を見つけるために、サーバー リソースの使用率を調べました。サーバー3
a
53%
97%
95%
98%
b
76%
43%
39%
41%
c
94%
32%
31%
35%
この表からわかるように、動的ドキュメント a を処理するとき、3 つのサーバーすべてがフルスピードで実行され、負荷が均等に分散されます。これは理想的な状態です。静的ドキュメント タイプ b および c を処理する場合、負荷は 3 つのサーバー間で均等に分散されますが、各サーバーはフルスピードで実行されません。特にサイズの大きなドキュメントを処理する場合、負荷分散デバイスの natd プロセスが処理リソースのほとんどを占有します。すべてのネットワーク トラフィックは natd プロセスを介して変換される必要があるため、ネットワーク トラフィックと同時接続の数が大量になると、natd プロセスの負荷が増加します。実験で異なる数のバックエンド サーバーを使用した場合、負荷分散ゲートウェイを通過する実際のネットワーク帯域幅は次のとおりです。
表 2: 大きなサイズのドキュメントを提供する場合のサーバー クラスターの帯域幅
サーバーの数
1
2
3
ネットワーク速度 (Kb/s)
10042.14
11015.10
11442.67
明らかに、これはこのテストで使用される負荷分散プロセスの帯域幅制限であることがわかります。実際、このプログラムはネットワーク アドレス変換のステータスを維持するためにリンク リストを使用しますが、ハードウェアのパフォーマンスを向上させ、アルゴリズムを改善することで、そのパフォーマンスをさらに向上させることができます。
4. 考察
上記の実験から、ネットワーク アドレス変換に基づくロード バランサーはサーバー側の CPU とディスク I/O 負荷を効果的に解決できることがわかります。 O の制限には、特定のハードウェア条件下で特定の帯域幅制限がありますが、アルゴリズムを改善し、負荷分散プログラムを実行するハードウェアのパフォーマンスを向上させることで、この帯域幅制限を増やすことができます。また、異なるサービス タイプが異なるサーバー リソースを占有することもわかります。私たちが使用する負荷測定戦略は、ほとんどの条件に適した同じ負荷を使用することです。ただし、最善の方法は、CPU などの異なるリソースをターゲットにすることです。 、ディスク I/O またはネットワーク I/O、それぞれサーバーの負荷を監視し、中央コントローラーが顧客のリクエストを分散するために最適なサーバーを選択します。私たちの今後の取り組みは、この負荷分散コントローラーを改善するために、これら 2 つの側面から始まります。
参考文献:
[1] E.Kata、M.Butler、および R. McGrath。スケーラブルな HTTP サーバー: ncsa プロトタイプ、27 巻、P155-164
[ 2] Ralf S.Engelschall、Web テクニック マガジン (http://www.WebTechniques.com)、1998 年 5 月、vol.3、iss.5
[3] LocalDirector ドキュメント。 //www.cisco.com、1997
[4] H.Zhu. T.Yang、Q.Zheng、D.Watson、O.H.Ibarra、T.Smith、クラスタ化されたデジタル ライブラリ サーバーの適応型負荷分散技術レポート、CS。 、UCSB、1998年。
[5] FreeBSDコアチーム。http://www.freebsd.org。1995年
NATによる負荷分散ゲートウェイの実装。 NongYe Road 70, ZhengZhou, 450002, P.R.China
wb@email.online.ha.cn
要約: この文書では、負荷分散技術と戦略を調査し、インターネット サーバー用の負荷分散ゲートウェイ ベースの NAT を実装します。サーバーは同時アクセス要求により CPU と I/O の負荷が高くなりますが、対称クラスター化されたサーバーはサーバーの負荷を分散して問題を解決し、最適な方法で負荷のバランスをとることができます。ゲートウェイはサーバーの状態に応じて負荷を分散します。 CPU と I/O。ゲートウェイは、インターネット サービスに高いパフォーマンスを提供できるように、すべてのサーバーの負荷を監視し、最適なスキームを適用する必要があります。
キーワード: 負荷分散、NAT、FreeBSD
。
http://www.bkjia.com/PHPjc/316165.html
www.bkjia.com
true