この記事では、6つの負荷分散技術の実装方法をまとめます（要約）

ロード バランシングは、サーバー クラスタの展開でよく使用されるデバイスです。マシンのパフォーマンスがビジネスの成長ニーズを満たせない場合は、より優れたパフォーマンスを持つマシンを探すのではなく、ロード バランシングとクラスタリングを使用して顧客の成長ニーズを満たします。

負荷分散テクノロジの実装は、主に次のカテゴリに分類されます。

• HTTP リダイレクト ペイロード
• DNSドメイン名解決負荷
• リバースプロキシの負荷
• IP 負荷 (NAT 負荷と IP トンネル負荷)
• ダイレクトルーティング (LVS-DR)
• IP トンネル (LVS-TUN)

負荷分散は、複数のサーバーの収容能力が異なるため、すべての実際のサーバーに同じ量の作業負荷を割り当てることとして狭義に理解することはできません。これは、ハードウェア構成とネットワーク帯域幅の違いに反映される場合もあれば、サーバーが複数の機能を持っている場合もあります。私たちが「バランス」と呼んでいるのは、すべてのサーバーが過負荷にならず、最大限に機能することを期待することを意味します。

http リダイレクト

http プロキシ (ブラウザなど) が Web サーバーから URL を要求すると、Web サーバーは http 応答ヘッダーの Location タグを通じて新しい URL を返すことができます。

つまり、自動ジャンプを完了するには、HTTP プロキシがこの新しい URL を要求し続ける必要があります。

パフォーマンスの欠点:

1. スループット制限

プライマリ サイト サーバーのスループットは、転送されたサーバーに均等に分散されます。

ここで、RR (ラウンドロビン) スケジューリング戦略が使用され、サブサーバーの最大スループットが 1000 リクエスト/秒であると仮定すると、3 つのサブサーバーを完全に活用するには、メインサーバーのスループットが 3000 リクエスト/秒に達する必要があります。サブサーバーが 100 台ある場合、メインサーバーのスループットがどの程度になるかは想像がつくでしょう。

逆に、メイン サービスの最大スループットが 6000 リクエスト/秒の場合、サブ サーバーに分散される平均スループットは 2000 リクエスト/秒であり、サブ サーバーの現在の最大スループットは 1000 リクエスト/秒であるため、要件を満たすにはサブ サーバーの数を 6 に増やす必要があります。

2. リダイレクトアクセスの深さの違い

静的ページをリダイレクトするものもあれば、複雑な動的ページをリダイレクトするものもあるため、実際のサーバー負荷の差は予測できず、メインサイト サーバーはそれについて何も知りません。したがって、サイト全体の負荷分散にリダイレクト方式を使用することはお勧めできません。

リクエストを転送するオーバーヘッドと実際のリクエストを処理するオーバーヘッドを比較検討する必要があります。前者が後者に比べて小さいほど、ダウンロードなどのリダイレクトの意味が大きくなります。

多くのミラー ダウンロード サイトを試してみると、ほとんどのダウンロードがリダイレクトに場所を使用していることがわかります。

DNS 負荷分散

DNS はドメイン名解決サービスを提供します。サイトにアクセスする場合、実際にはまずサイトのドメイン名の DNS サーバーを通じてドメイン名が指す IP アドレスを取得する必要があります。このプロセス中に、DNS サーバーはドメイン名と IP アドレスのマッピングを完了します。

同様に、このようなマッピングは 1 対多にすることもできます。このとき、DNS サーバーは負荷分散スケジューラとして機能します。これは、ユーザー要求を複数のサーバーに分散する http リダイレクト変換戦略に似ていますが、実装メカニズムはまったく異なります。

digコマンドを使用して「baidu」のDNS設定を表示します。

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

http リダイレクトと比較すると、DNS ベースの負荷分散では、いわゆるメイン サイトが完全に保存されるか、DNS サーバーがすでにメイン サイトとして機能します。

しかし、違いは、スケジューラとしては、DNS サーバー自体のパフォーマンスを心配する必要がほとんどないということです。

DNS レコードは、ユーザーのブラウザまたはインターネット アクセス サービス プロバイダーの DNS サーバーによってすべてのレベルでキャッシュされるため、キャッシュの有効期限が切れた場合にのみ、ドメイン名の DNS サーバーに再度解決が要求されます。

また、DNS には HTTP のようなスループットの制限はなく、理論上は実サーバの数を無制限に増やすことができるとも言われています。

特性：

1. ユーザーの IP に基づいてインテリジェントな分析を実行できます。 DNS サーバーは、ユーザーに最も近いサーバーの利用可能なすべての A レコードを検索できます。

2. ダイナミック DNS: IP アドレスが変更されるたびに DNS サーバーを適時に更新します。もちろん、キャッシュのため、ある程度の遅延は避けられません。

不十分：

1. DNS が実際にどのサーバーに解決されるかをユーザーが直接確認できないため、サーバー運用および保守担当者のデバッグに不便が生じます。

2. 戦略の限界。たとえば、HTTP リクエストのコンテキストをスケジューリング戦略に取り入れることはできません。先に紹介した HTTP リダイレクトに基づく負荷分散システムでは、スケジューラは HTTP レベルで動作します。スケジューラは HTTP リクエストを完全に理解し、サイトのアプリケーション ロジックに従って、たとえば、異なる要求された URL に応じた合理的なフィルタリングや転送など、スケジューリング戦略を設計できます。

3. 実際のサーバーのリアルタイムの負荷差に基づいてスケジュール戦略を調整する場合、DNS サーバーは各解決操作中に各サーバーの正常性状態を分析する必要があります。DNS サーバーの場合、このようなカスタム開発のハードルは高く、ほとんどのサイトではサードパーティの DNS サービスのみを使用していることは言うまでもありません。

4. DNS レコード キャッシュ。あらゆるレベルのノードにある DNS サーバー上のさまざまなプログラムのキャッシュは、目が回ってしまうほどです。

5. 上記の点から、DNS サーバーはワークロード バランシングの分散をうまく完了できません。最終的に、DNS ベースの負荷分散を選択するかどうかは、完全にニーズによって決まります。

リバースプロキシ負荷分散

ほとんどすべての主流の Web サーバーがリバース プロキシ ベースの負荷分散をサポートすることに熱心であるため、これは間違いなく誰もが経験したことがあるものです。その主な役割は、HTTP リクエストを転送することです。

以前の HTTP リダイレクトや DNS 解決と比較すると、リバース プロキシ ディスパッチャは、ユーザーと実際のサーバー間の仲介役としての役割を果たします。

1. 実際のサーバーへのHTTPリクエストはすべてスケジューラを通過する必要がある

2. スケジューラは実際のサーバーからの HTTP 応答を待機し、それをユーザーにフィードバックする必要があります (最初の 2 つの方法では、スケジューリング フィードバックは必要なく、実際のサーバーがそれを直接ユーザーに送信します)。

特性：

1. 豊富なスケジュール戦略。たとえば、実際のサーバーごとに異なる重みを設定することで、能力の高いサーバーにより多くの作業を割り当てる効果が得られます。

2. リバース プロキシ サーバーは HTTP レベルで動作するため、同時処理機能に対する要件が高くなります。

3. リバースプロキシサーバ自体の転送操作には、スレッドの作成、バックエンドサーバとのTCP接続の確立、バックエンドサーバから返される処理結果の受信、HTTPヘッダ情報の解析、ユーザ空間とカーネル空間の頻繁な切り替えなど、ある程度のオーバーヘッドが必要です。

この部分の時間は長くありませんが、バックエンド サーバーが非常に短時間でリクエストを処理する場合、転送のオーバーヘッドが特に顕著になります。たとえば、静的ファイルを要求する場合は、前に紹介した DNS ベースの負荷分散方法を使用する方が適切です。

4. リバース プロキシ サーバーは、システム負荷、応答時間、可用性、TCP 接続数、トラフィックなどのバックエンド サーバーを監視し、これらのデータに基づいて負荷分散戦略を調整できます。

5. リフレクティブ プロキシ サーバーを使用すると、セッション サイクル内のすべてのユーザー リクエストを特定のバックエンド サーバーに転送できます (スティッキー セッション)。この利点は、まず、セッションへのローカル アクセスが維持され、次に、バックエンド サーバー上の動的メモリ キャッシュ リソースの浪費が防止されることです。

IP 負荷分散 (LVS-NAT)

リバース プロキシ サーバーは HTTP レイヤーで動作するため、そのオーバーヘッドによってスケーラビリティが大幅に制限され、パフォーマンスの限界が制限されます。 HTTP レベル以下の負荷分散を実現することは可能ですか?

NAT サーバー: トランスポート層で動作します。送信された IP データ パケットを変更し、データ パケットの宛先アドレスを実際のサーバー アドレスに変更できます。

Linux 2.4 カーネル以降では、組み込みの Neftilter モジュールがカーネル内にいくつかのパケット フィルタリング テーブルを保持しています。これらのテーブルには、パケット フィルタリングを制御するためのルールが含まれています。

幸いなことに、Linux ではフィルター テーブルを挿入、変更、削除するための iptables が提供されています。さらに興味深いのは、Linux 2.6.x カーネルに IPVS モジュールが組み込まれていることです。このモジュールは Netfilter モジュールと同様に動作しますが、IP 負荷分散の実現に重点を置いています。

サーバーカーネルにIPVSモジュールがインストールされているかどうかを確認するには、

出力は IPVS がインストールされていることを意味します。 IPVS の管理ツールは ipvsadm です。これは、負荷分散システムを迅速に実装できるコマンドラインベースの構成インターフェイスを提供します。

これは有名なLVS（Linux Virtual Server）です。

1. スケジューラのパケット転送オプションを開く

エコー1 > /proc/sys/net/ipv4/ip_forward

2. 実際のサーバーがNATサーバーをデフォルトゲートウェイとして使用しているかどうかを確認します。使用していない場合は、

ルート追加デフォルト gw xx.xx.xx.xx

3. ipvsadm設定を使用する

ipvsadm -A -t 111.11.11.11:80 -s rr

仮想サーバーを追加します。-t の後にサーバーの外部ネットワーク IP とポートが続きます。-s rr は、単純なポーリングを使用する RR スケジューリング戦略を指します (これは静的スケジューリング戦略です。さらに、LVS は、最小接続 (LC)、重み付き最小接続 (WLC)、最短予想遅延 (SED) などの一連の動的スケジューリング戦略も提供します)。

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m 
ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m

実際のサーバーを2つ追加します（外部IPは不要）。-rの後には実際のサーバーの内部IPとポートが続き、-mはNATを使用してデータパケットを転送することを意味します。

実際のサーバーのステータスを表示するには、ipvsadm -L -n を実行します。それでおしまい。

実験では、NAT ベースの負荷分散システムの使用が示されました。ディスパッチャとして機能する NAT サーバーは、カーネルでの要求転送のオーバーヘッドが低いため、スループットをリバース プロキシ サーバーのほぼ 2 倍という新しいレベルにまで向上させることができます。

ただし、要求されたコンテンツが大きすぎると、負荷分散の全体的なスループットは、リバース プロキシまたは NAT のどちらに基づいていても、それほど変わりません。これは、オーバーヘッドの高いコンテンツの場合、単純なリバース プロキシを使用して負荷分散システムを構築することを検討する価値があることを示しています。

このような強力なシステムでも、内部ネットワークと外部ネットワークを含む NAT サーバーのネットワーク帯域幅というボトルネックが存在します。

もちろん、お金があれば、ギガビット スイッチや 10 ギガビット スイッチ、あるいは負荷分散ハードウェア デバイスを購入するためにお金を費やすこともできますが、お金がなければ、何ができるでしょうか?

シンプルで効果的な方法は、NAT ベースのクラスターと以前の DNS を混在させることです。たとえば、5 つの 100 Mbps エクスポート ブロードバンドのクラスターなどです。次に、DNS を使用してユーザー要求をこれらのクラスターに均等に転送します。同時に、DNS インテリジェント解決を使用して地域アクセスを実現することもできます。

このような構成はほとんどのビジネスには十分ですが、ダウンロードやビデオなどのサービスを提供する大規模なサイトでは、NAT サーバーはまだ十分ではありません。

ダイレクトルーティング (LVS-DR)

NAT はネットワーク階層化モデルのトランスポート層 (レイヤー 4) で動作しますが、ダイレクト ルーティングはデータ リンク層 (レイヤー 2) で動作し、より強力であるように見えます。

データ パケットの宛先 MAC アドレスを変更して (宛先 IP を変更せずに)、データ パケットを実際のサーバーに転送します。違いは、実際のサーバーの応答データ パケットがスケジューラを経由せずにクライアントに直接送信されることです。

1. ネットワーク設定

ここでは、負荷分散スケジューラと 2 台の実際のサーバーを想定し、各マシンに 1 つずつ、合計 3 つの外部 IP アドレスを購入します。3 台のマシンのデフォルト ゲートウェイは同じである必要があり、最後に同じ IP エイリアスを設定します。ここでは、エイリアスが 10.10.120.193 であると想定します。

この方法では、ディスパッチャは IP エイリアス 10.10.120.193 を介してアクセスされ、サイトのドメイン名をこの IP エイリアスにポイントすることができます。

2.ループバックインターフェースにIPエイリアスを追加します。

これは、実際のサーバーがこの IP エイリアスを使用して他のサーバーを検索するのを防ぐためです。実際のサーバーで実行します。

さらに、実際のサーバーがネットワークからの IP エイリアスの ARP ブロードキャストに応答しないようにする必要があります。これを行うには、以下も実行する必要があります。

• エコー "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
• エコー "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
• エコー "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
• エコー "1" > /proc/sys/net/ipv4/conf/all/arp_announce

設定が完了したら、ipvsadm を使用して LVS-DR クラスターを設定できます。

• ipvsadm -A -t 10.10.120.193:80 -s rr
• ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g
• ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g

-gはダイレクトルーティングを使用してパケットを転送することを意味します

LVS-DR が LVS-NAT より優れている最大の利点は、LVS-DR がスケジューラ帯域幅によって制限されないことです。たとえば、3 つのサーバーの WAN スイッチのエクスポート帯域幅が 10Mbps に制限されていると仮定すると、スケジューラと 2 つの実際のサーバーを接続する LAN スイッチには速度制限がありません。

さて、LVS-DR を使用すると、理論上は最大 20Mbps のエクスポート帯域幅を実現できます。これは、実際のサーバー応答データ パケットがスケジューラを通過せずにユーザー側に直接送信できるため、スケジューラのエクスポート帯域幅とは関係なく、LVS-DR 自身の帯域幅のみに関係するためです。

LVS-NAT を使用する場合、クラスターは最大 10 Mbps の帯域幅しか使用できません。したがって、応答パケットの数が要求パケットの数を大幅に上回るサービスの場合、要求を転送するためのスケジューラのオーバーヘッドを削減する必要があります。これにより、全体的なスケーラビリティが向上し、最終的には WAN 出力帯域幅への依存度が高まります。

一般的に、LVS-DR はスケーラブルな負荷分散システムの構築に適しており、Web サーバー、ファイル サーバー、ビデオ サーバーのいずれであっても優れたパフォーマンスを発揮します。前提条件として、実際のサーバー用の一連の有効な IP アドレスを購入する必要があるということです。

IP トンネル (LVS-TUN)

IP トンネルに基づく要求転送メカニズム: スケジューラによって受信された IP データ パケットは新しい IP データ パケットにカプセル化され、実際のサーバーに転送され、実際のサーバーの応答データ パケットがユーザー エンドに直接到達できます。

現在、ほとんどの Linux がこれをサポートしており、LVS で実装できます (LVS-TUN と呼ばれます)。LVS-DR とは異なり、実際のサーバーとスケジューラは同じ WANt セグメントに存在しない場合があります。スケジューラは IP トンネリング テクノロジを使用して実際のサーバーに要求を転送するため、実際のサーバーにも有効な IP アドレスが必要です。

一般的に、LVS-DR と LVS-TUN はどちらも、非対称の応答と要求を持つ Web サーバーに適しています。どちらを選択するかは、ネットワーク展開のニーズによって異なります。LVS-TUN は、必要に応じて実際のサーバーを異なるリージョンに展開し、近接性の原則に基づいて要求を転送できるため、同様のニーズがある場合は、LVS-TUN を選択する必要があります。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。