LVSを深く理解する。それでも習得できないなら、私の負けです！

現在、さまざまなインターネット アプリケーションでは、ハードウェア パフォーマンス、応答速度、サービスの安定性、データの信頼性などに対するサイトの要件がますます厳しくなり、単一のサーバーではすべてのアクセス ニーズを満たすことができなくなります。

[[333902]]

画像はPexelsより

もちろん、コスト効率の高い機器や専用の負荷分散装置を使用する以外にも、複数の通常のサーバー機器を統合してクラスターサーバーを構築し、同じアドレスで外部に同じサービスを提供するという、この問題を解決するのに役立つ他のオプションがあります。

今日は、企業でよく使われるクラスター技術である LVS を紹介します。

• LVSとは
• LVS を使用する理由は何ですか?
• LVSの構成と機能
• 負荷分散の起源と利点
• LVS 負荷分散クラスターの種類
• DNS/ソフトウェアおよびハードウェア負荷分散の種類
• LVS クラスタの一般的なアーキテクチャ
• LVS負荷分散の基本原理
• LVS 負荷分散の 3 つの動作モード
• LVS の 10 個の負荷スケジューリング アルゴリズム
• LVS関連の用語と説明
• 要約する

LVSとは何ですか?

LVS は Linux Virtual Server の略称で、仮想サーバー クラスタ システムです。このプロジェクトは、1998 年 5 月に Zhang Wensong 博士によって設立され、中国で最も初期のフリー ソフトウェア プロジェクトの 1 つです。

公式ウェブサイト: http://www.linuxvirtualserver.org。 LVS は、実際には IP アドレスに基づく仮想化アプリケーションと同等です。 IP アドレスとコンテンツ要求の分散に基づいて負荷分散を行う効率的なソリューションを提供します。現在、LVS は Linux カーネル標準の一部となっています。

LVS を使用することで達成できる技術的目標は、LVS によって実現される負荷分散テクノロジと Linux オペレーティング システムを通じて、優れた信頼性、拡張性、操作性を備えた高性能で高可用性の Linux サーバー クラスターを実装し、低コストで最適なパフォーマンスを実現することです。

LVS は、負荷分散クラスターを実装するオープン ソース ソフトウェア プロジェクトです。 LVS アーキテクチャは、論理的にスケジューリング層、サーバー クラスター層、共有ストレージ層に分割できます。

LVS を使用する理由は何ですか?

では、なぜ LVS がまだ必要なのでしょうか?インターネットの爆発的な成長と日常生活におけるその役割の重要性の高まりにより、インターネット上のトラフィックは年間 100% 以上の割合で増加しています。

サーバーにかかる負荷も急速に増加するため、特に人気のある Web サイトの場合、サーバーは短期間で過負荷状態になります。

サーバーの過負荷問題を克服するには、次の 2 つの解決策があります。

• 1 つは、単一サーバーソリューションです。これは、サーバーをより高性能なサーバーにアップグレードすることですが、リクエストの数が増えるとすぐに過負荷になるため、再度アップグレードする必要があります。アップグレードプロセスは複雑でコストがかかります。
• もう 1 つは、サーバー クラスター上にスケーラブルなネットワーク サービス システムを構築するマルチ サーバー ソリューションです。負荷が増加した場合は、クラスターに新しいサーバーまたはサーバーを追加するだけで、増大する需要に対応できます。コモディティ サーバーは、パフォーマンスとコストの比率が最も高くなります。したがって、ネットワーク サービス用のサーバー クラスター システムを構築すると、スケーラビリティとコスト効率が向上します。

サーバー クラスターを構築する方法は次のとおりです。

DNS ベースの負荷分散クラスター: DNS 負荷分散は、おそらくネットワーク サービス クラスターを構築する最も簡単な方法です。

ドメイン ネーム システムを使用して、ドメイン名をサーバーの異なる IP アドレスに解決することで、要求を異なるサーバーに分散します。

DNS 要求がドメイン名を解決するために DNS サーバーに到達すると、DNS サーバーはスケジュール ポリシーに基づいてサーバーの IP アドレスの 1 つを発行し、同じローカル キャッシュ ネーム サーバーを使用するクライアントからの要求が、指定された名前解決の有効期間 (TTL) 内に同じサーバーに送信されます。

しかし、クライアントのキャッシュの性質と階層型 DNS システムにより、サーバー間の動的な負荷の不均衡が生じやすく、サーバーがピーク負荷を処理することが困難になります。名前マッピングの TTL 値が DNS サーバー上で適切に選択されていません。

値が小さい場合、DNS トラフィックが多くなり、DNS サーバーがボトルネックになります。値が大きい場合、動的負荷の不均衡が悪化します。

TTL 値がゼロに設定されている場合でも、スケジュールの粒度はホストごとに設定され、ユーザーのアクセス パターンによって動的な負荷の不均衡が発生する可能性があります。一部のユーザーはサイトから多くのページを取得する一方で、他のユーザーは数ページのみを閲覧して立ち去る場合があります。

また、信頼性もそれほど高くなく、サーバー ノードに障害が発生すると、名前を IP アドレスにマップするクライアントはサーバーがダウンしていることに気付きます。

ディスパッチャベースの負荷分散クラスタリング: ディスパッチャ (ロード バランサとも呼ばれます) を使用すると、クラスタ内のサーバ間で負荷を分散できます。これにより、サーバの並列サービスが単一の IP アドレス上の仮想サービスとして表示され、エンド ユーザーはクラスタ内のすべてのサーバを認識していないかのように単一のサーバと対話できます。

DNS ベースの負荷分散と比較して、スケジューラはリクエストを細かい粒度 (接続ごとなど) でスケジュールできるため、サーバー間の負荷分散が向上します。 1 台以上のサーバーに障害が発生した場合、その障害を隠すことができます。

サーバー管理はより容易になり、管理者はエンドユーザーへのサービスを中断することなく、いつでも 1 台以上のサーバーのサービスを開始または停止することができます。

負荷分散は、アプリケーション レベルと IP レベルの 2 つのレベルに分けられます。たとえば、リバース プロキシと pWEB は、スケーラブルな Web サーバーを構築するためのアプリケーション レベルの負荷分散方法です。

HTTP リクエストをクラスター内の他の Web サーバーに転送し、結果を取得してクライアントに返します。

アプリケーション レベルで HTTP リクエストと応答を処理するオーバーヘッドは大きいため、サーバー ノードの数が 5 以上に増えると、各サーバーのスループットに応じて、アプリケーション レベルのロード バランサーが新たなボトルネックになると考えられます。

LVS と Nginx の機能比較は次のとおりです。

• LVS は Nginx よりも負荷耐性が強く、パフォーマンスが高く、メモリと CPU リソースの消費量が少ないという特徴があります。
• LVS はネットワーク層で動作し、特定のトラフィックはオペレーティング システム カーネルによって処理されます。 Nginx はアプリケーション層で動作し、HTTP アプリケーションに対していくつかの転送戦略を実装できます。
• LVS のインストールと構成は複雑で、ネットワークに大きく依存し、非常に安定しています。 Nginx のインストールと設定は比較的簡単で、ネットワークへの依存性もほとんどありません。
• LVS は通常のマッチング処理をサポートしていないため、動的および静的分離効果を実現できません。
• LVS は幅広いプロトコルに適用できます。 Nginx は HTTP、HTTPS、および電子メール プロトコルのみをサポートしており、適用範囲が狭いです。

LVSの構成と機能

LVS は次の 2 つのプログラムで構成されています。

• ipvs (ip virtual server): LVS は、カーネル状態の Netfilter フレームワークに基づいて実装された IPVS 機能であり、カーネル状態で動作します。 VIP およびその他の関連情報を設定し、それを IPVS に渡すには、ipvsadm ツールが必要です。
• ipvsadm: ipvsadm は LVS のユーザー モード サポート ツールです。 VIP および RS の追加、削除、変更、チェックの機能を実装できます。 Netlink または raw ソケットに基づいてカーネル LVS と通信します。 LVS が Netfilter に類似しているとすれば、ipvsadm は iptables ツールに類似しています。

効果は以下のとおりです。

• 主に複数のサーバーの負荷分散に使用されます。
• ネットワーク層で動作し、高性能かつ高可用性のサーバー クラスター テクノロジーを実現します。
• 安価で、パフォーマンスの低いサーバーを多数組み合わせてスーパーサーバーを形成できます。
• 使いやすく、設定も簡単で、複数の負荷分散方法を備えています。
• 安定性と信頼性が高く、クラスター内のサーバーが正常に動作しなくなった場合でも、全体の効果には影響しません。
• 優れたスケーラビリティ。

負荷分散の起源と利点

ビジネスを始めたばかりの頃は、外部にサービスを提供するために通常 1 台のサーバーが使用されます。後期にビジネスが成長するにつれて、トラフィックも増加します。

この単一のサーバーへのアクセス量が増えるほど、サーバーにかかる負荷が大きくなり、そのパフォーマンスがビジネス ニーズを満たせなくなります。アクセス圧力が指定値を超えると、崩壊します。このような事件が起きないようにするためです。

他のソリューションも採用し、複数のサーバーでクラスター システムを形成してサーバー全体の処理パフォーマンスを向上させ、統一されたエントランス (トラフィック スケジューラ) を使用してバランスの取れたアルゴリズムを通じて外部サービスを提供し、多数のユーザー要求をバックエンド クラスター内の異なるサーバーに均等に分散します。

そのため、サーバーにかかる負荷を分散するための負荷分散が行われます。負荷分散を使用する利点は、システム全体のパフォーマンスの向上、システムのスケーラビリティの向上、システムの高可用性の向上です。

LVS 負荷分散クラスターの種類

ロード バランス クラスター: ロード バランス クラスターは、アプリケーション システムの応答性を向上させ、可能な限り多くのアクセス要求を処理し、レイテンシを削減することで、高い同時実行性と高負荷の全体的なパフォーマンスを実現することを目的としています。

高可用性クラスター: 高可用性クラスターは、アプリケーション システムの信頼性を向上させ、端末時間を可能な限り短縮し、サービスの継続性を確保し、高可用性とフォールト トレランスを実現することを目的としています。

高性能コンピュータ クラスター: 高性能コンピュータ クラスターの目標は、アプリケーション システムの CPU コンピューティング速度を向上させ、ハードウェア リソースと分析機能を拡張し、大型コンピュータやスーパーコンピュータと同等の高性能コンピューティング機能を実現することです。

DNS/ソフトウェアおよびハードウェア負荷分散の種類

①DNSは負荷分散を実装する

ドメイン名は DNS を通じて複数の IP に解決され、各 IP は異なるサーバー インスタンスに対応するため、トラフィックのスケジュールが完了します。これは、DNS を使用して負荷分散を実現する最も簡単な方法でもあります。

この方法を使用する最大の利点は、実装が簡単でコストが低く、負荷分散装置を自分で開発または保守する必要がないことです。

ただし、サーバーのフェイルオーバーの遅延が長い、アップグレードが不便、トラフィックのスケジュールが不均一、粒度が大きい、トラフィック分散戦略が単純、サポートされるアルゴリズムが少ない、DNS でサポートされる IP リストが制限されるなど、いくつかの欠点もあります。

②ハードウェア負荷分散

ハードウェア負荷分散では、専用のハードウェア デバイスを使用して負荷分散機能を実現します。たとえば、スイッチやルーターは負荷分散専用のネットワーク デバイスです。

現在、代表的なハードウェア負荷分散デバイスは F5 と A10 の 2 つです。しかし、このようなハードウェア負荷分散装置を利用できる企業は、普通の企業ではありません。逆に言えば、取引量が少ない企業では基本的に利用できません。

ハードウェア負荷分散の利点:

• 強力な機能: あらゆるレベルでの負荷分散と包括的な負荷分散アルゴリズムをサポートします。
• 強力なパフォーマンス: パフォーマンスは一般的なソフトウェア ロード バランサーをはるかに上回ります。
• 高い安定性: ハードウェアの負荷分散と大規模な使用が厳密にテストされている必要があります。
• セキュリティ保護: 負荷分散機能に加えて、ファイアウォール、DDoS 攻撃対策などのセキュリティ機能も備えています。

ハードウェア負荷分散の欠点:

• 高い。
• スケーラビリティが低い。
• デバッグやメンテナンスが面倒です。

③ ソフトウェア負荷分散

ソフトウェア負荷分散にはいくつかの種類があります。

• Nginx: レイヤー 4/レイヤー 7 の負荷分散、HTTP、および電子メール プロトコルをサポートします。
• LVS: カーネル状態で実行される純粋な 4 層負荷分散。ソフトウェア負荷分散の中で最も高いパフォーマンスを実現します。
• HAproxy: 7 層ルールの設定をサポートし、優れたパフォーマンスを発揮する 7 層負荷分散ソフトウェアです。

ソフトウェア ロード バランシングの利点: シンプル、柔軟、安価 (上記で使用したソフトウェア ロード バランシングは、Linux オペレーティング システムに直接インストールできるため、導入と保守が比較的簡単です。レイヤー 4 とレイヤー 7 のロード バランシングは、業務や業務の特性に応じて選択でき、機能の拡張やカスタマイズも比較的簡単です)。

LVS クラスタの一般的なアーキテクチャ

最初のレイヤー: ロード スケジューラ: ロード バランサ。これは、クラスター システム全体への唯一の入り口です。すべてのサーバーで共有される仮想 IP アドレス (クラスター IP アドレスとも呼ばれます) を使用します。

ロード バランサ: サーバー クラスタ システムへの単一のエントリ ポイントであり、Linux カーネル内で IP ロード バランシング テクノロジを実装する IPVS または Linux カーネル内でアプリケーション レベルのロード バランシングを実装する KTCPVS を実行できます。

IPVS を使用する場合、すべてのサーバーは同じサービスとコンテンツを提供する必要があり、ロード バランサーは指定されたスケジューリング アルゴリズムと各サーバーの負荷に従って新しいクライアント要求をサーバーに転送します。どのサーバーが選択されても、クライアントは同じ結果を得るはずです。

KTCPVS を使用すると、サーバーは異なるコンテンツを持つことができ、ロード バランサーは要求のコンテンツに基づいて要求を他のサーバーに転送できます。

KTCPVS は Linux カーネル内に実装されているため、データ中継のオーバーヘッドは非常に小さく、高いスループットを維持できます。

第 2 層: サーバー プール。クラスターによって提供されるアプリケーション サービス (HTTP、FTP サーバー プールなど)。各ノードには独立した実 IP アドレスがあり、スケジューラによって分散されたクライアント要求のみを処理します。

サーバー クラスターのノードは、システムが負担する負荷に応じて負荷を分散できます。すべてのサーバーが過負荷になった場合、増加するワークロードを処理するために複数のサーバーを追加できます。

ほとんどのインターネット サービス (Web など) では、リクエストは通常​​、あまり相関性がなく、異なるサーバー上で並行して実行されることがあります。したがって、サーバー クラスター内のノードの数が増えると、全体的なパフォーマンスはほぼ直線的に向上します。

3 番目のレイヤー: 共有ストレージは、サーバー プール内のすべてのノードに安定した一貫性のあるファイル ストレージ サービスを提供して、クラスター全体の統一性を保証します。 NFS (Network File System) ネットワーク ファイル システム共有サービスを提供する NAS デバイスまたは専用サーバーを使用できます。

共有ストレージ: データベース システム、ネットワーク ファイル システム、または分散ファイル システムになります。サーバー ノードが動的に更新する必要があるデータは、データベース システムに保存する必要があります。サーバー ノードがデータベース システム内のデータを並行して読み書きすると、データベース システムは同時データ アクセスの一貫性を確保できます。

静的データは通常、すべてのサーバー ノードでデータを共有できるように、ネットワーク ファイル システム (NFS や CIFS など) に保存されます。

ただし、単一のネットワーク ファイル システムのスケーラビリティには制限があります。たとえば、単一の NFS/CIFS では、4 ～ 8 台のサーバーからのデータ アクセスしかサポートできません。

大規模なクラスター システムでは、共有ストレージに GPFS、Coda、GFS などの分散/クラスター ファイル システムを使用でき、システム要件に応じて共有ストレージを拡張することもできます。

LVS負荷分散の基本原理

Netfilterの基本原理

LVS 負荷分散の基本原理を紹介する前に、まず Netfilter の基本原理について説明します。 LVS は、Linux カーネルの Netfilter フレームワークに基づいて実装された負荷分散システムであるためです。

Netfilter は実際には非常に複雑かつ重要です。私たちがよく話題にする Linux ファイアウォールは Netfilter ですが、私たちは今でも iptables を運用しています。 Iptables と Netfilter は、システム保護を完了するために連携して動作する Linux ファイアウォール ツールの組み合わせです。

Iptables はユーザー空間に配置されますが、Netfilter はカーネル空間に配置されます。 Iptables は、ユーザー空間でルールを記述して送信するための単なるツールであり、実際の作業は依然として Netfilter です。

両者の違い: Netfilter はカーネル モードの Linux ファイアウォール メカニズムです。一般的な抽象フレームワークとして、パケット フィルタリング、ネットワーク アドレス変換、プロトコル タイプに基づく接続追跡など、フック関数管理メカニズムの完全なセットを提供します。データ パケットのフロー中に関連する操作を実行するためのルールに従って複数のチェックポイント (フック関数) を設定できます。

合計 5 つのポイントを設定します。

• 事前ルーティング: このチェーン内のルールは、パケットのルーティングが実行される前に適用されます。
• 入力: ファイアウォールのローカル アドレス宛てのパケットを受信すると、このチェーンのルールが適用されます。
• forward: ファイアウォールを介して別のアドレスに転送する必要があるパケットを受信すると、このチェーンのルールが適用されます。
• 出力: ファイアウォールがパケットを外部に送信するときに、このチェーン内のルールが適用されます。
• postrouting: このチェーンのルールは、パケットのルーティングが完了した後に適用されます。

Iptable は、コマンド ライン インターフェイスを提供し、Netfilter にルール ポリシーを追加して、パケット フィルタリング、変更、その他の機能を実装できるユーザー レベルのツールです。

次の図から、Netfilter の動作メカニズムを理解できます。

データ パケットがネットワーク インターフェイスから入力されると、リンク層を通過し、ネットワーク層に入って PREROUTING に到達し、ターゲット IP アドレスに基づいてルートを検索します。

ターゲット IP がローカル マシンの場合、データ パケットは INPUT に送信され、プロトコル スタックを通過した後、データはポートに応じて対応するアプリケーションに送信されます。アプリケーションは要求を処理し、応答データ パケットを OUTPUT に送信し、最後に POSTROUTING を介してネットワーク インターフェイスから送信します。

ターゲット IP がローカル マシンではなく、サーバーで FORWARD パラメータがオンになっている場合、データ パケットは FORWARD に配信され、最終的に POSTROUTING を介してネットワーク インターフェイスから送信されます。

LVSの基本原則

LVS は Netfilter フレームワークに基づいており、INPUT チェーン上で動作します。 INPUTチェーンにip_vs_in HOOK関数を登録し、IPVSに関するメイン処理を実行します。

詳細な原則は次のように要約されます。

① クライアントユーザーがwww.baidu.comウェブサイトにアクセスすると、ユーザーのアクセス要求はネットワークの層を通過し、最終的にスイッチを介してLVSサーバーネットワークカードに入り、カーネル空間層に入ります。

②PREROUTINGに入った後、経路検索により宛先VIPがローカルIPアドレスであると判定された場合、データパケットはINPUTチェーンに入ります。

③IPVSはINPUTチェーン上で動作するため、アクセスされたVIPとポートに基づいて、要求がIPVSサービスに対するものであるかどうかを判断します。そうであれば、登録された IPVS HOOK 関数を呼び出し、IPVS 関連のプロセスを実行し、データ パケットの関連データを強制的に変更し、データ パケットを POSTROUTING チェーンに送信します。

④データパケットを受信した後、POSTROUTINGチェーンはターゲットIPアドレスサーバーに基づいてルートを選択し、最終的にデータパケットをバックエンドの実サーバーに送信します。

以上が今回ご紹介したLVSの動作原理です。 LVS 負荷分散にも 3 つの動作モードが含まれており、各モードの動作原理は異なり、さまざまなアプリケーション シナリオに適しています。最終的な目標は、バランスの取れたトラフィック スケジューリングと優れたスケーラビリティを実現することです。

LVS 負荷分散の 3 つの動作モード

クラスターの負荷スケジューリング技術は、IP、ポート、コンテンツなどに基づいて分散できますが、その中でも IP ベースの負荷分散が最も効率的です。

IP 負荷分散モードに基づいて、アドレス変換 (NAT)、IP トンネル (TUN)、およびダイレクト ルーティング (DR) の 3 つの一般的な動作モードがあります。

NAT モード

アドレス変換: ネットワーク アドレス変換 (NAT モードとも呼ばれます) は、ファイアウォールのプライベート ネットワーク構造に似ています。ロード スケジューラは、すべてのサーバー ノードのゲートウェイ、クライアントのアクセス入口、および各ノードがクライアントに応答するためのアクセス出口として機能します。サーバー ノードはプライベート IP アドレスを使用し、ロード スケジューラと同じ物理ネットワーク内に配置されます。他の 2 つの方法よりも安全です。

NAT 実装の原則的なプロセスは次のとおりです。

① クライアントから送信された要求データパケットはネットワークを経由してLVSネットワークカードに到達します。データ パケットの送信元 IP は CIP で、宛先 IP は VIP です。

②次にPREROUTINGチェーンに入り、宛先IPに応じてルートを検索し、それがローカルIPアドレスであるかどうかを判断してから、送信元IPと宛先IPを変更せずにデータパケットをINPUTチェーンに転送します。

③ LVSに到達後、宛先IPと宛先PORTを使用してIPVSサービスかどうかを確認します。 IPVS サービスの場合、バックエンド サーバーとして RS が選択され、データ パケットの宛先 IP アドレスが RIP に変更されます。このとき、宛先 IP として RIP でルート検索が行われます。次のホップと PORT 情報を決定した後、データ パケットは OUTPUT チェーンに転送されます。

④ 変更されたデータパケットはPOSTROUTINGチェーンを通過し、RSサーバーに到達します。データ パケットの送信元 IP は CIP で、宛先 IP は RIP です。

⑤処理後、RSサーバーはデータパケットをユーザー空間のアプリケーションに送信します。処理が完了すると、応答データ パケットが送信されます。 RS サーバーのデフォルト ゲートウェイは LVS の IP です。アプリケーションはデータ パケットを次のホップ LVS サーバーに転送します。データ パケットの送信元 IP は RIP で、宛先 IP は CIP です。

⑥LVSサーバーはRSサーバーからデータパケットを受信した後、ルートを検索します。宛先 IP がローカル IP ではなく、LVS サーバーで FORWARD モードがオンになっている場合、データ パケットは変更されずに転送されます。

⑦応答データパケットを受信すると、LVSサーバーは宛先IPと宛先ポートに応じて対応するサービスを検索します。このとき、送信元 IP は VIP です。ルートを検索することで、ネクストホップ情報を決定し、データパケットをゲートウェイに送信し、最終的にクライアントユーザーに応答します。

NAT モードの利点:

• Windows オペレーティング システムをサポートします。
• ポートマッピングをサポートします。 RS サーバーの PORT と VPORT が一致しない場合、LVS はポート マッピングをサポートするために宛先 IP アドレスと DPORT を変更します。

NAT モードの欠点:

• RS サーバーはゲートウェイを使用して構成する必要があります。
• 双方向の流れにより、LVS にかかる負荷圧力が大きくなります。

NAT モードの使用シナリオ: Windows オペレーティング システムのユーザーにとってより使いやすいです。 LVS を使用する場合は、NAT モードを選択する必要があります。

TUNモード

IP トンネル: TUN モードと呼ばれる IP トンネルは、オープン ネットワーク構造を採用しています。ロード スケジューラは、クライアントのアクセス ポータルとして機能します。各ノードは、ロード スケジューラを経由せずに、独自のインターネット接続を介してクライアントに直接応答します。サーバー ノードはインターネット上のさまざまな場所に分散しており、独立したパブリック IP アドレスを持っています。専用の IP トンネルを介してロード スケジューラと通信します。

TUN 実装の原則的なプロセスは次のとおりです。

① クライアントはネットワーク経由でデータパケットをLVSネットワークカードに送信します。データ パケットの送信元 IP は CIP で、宛先 IP は VIP です。

②PREROUTINGチェーンに入った後、宛先IPに応じてルートを検索し、ローカルIPかどうかを判断します。データ パケットは INPUT チェーンと LVS に転送されます。送信元 IP と宛先 IP は変更されません。

③ LVSに到着後、宛先IPと宛先PORTからIPVSサービスかどうかを確認します。 IPVS サービスの場合、RS バックエンド サーバーが選択され、送信元 IP は DIP、宛先 IP は RIP となり、データ パケットは OUTPUT チェーンに転送されます。

④データパケットはルーティング情報に従ってLVSネットワークカードに到達し、ルータゲートウェイに送信され、最終的にバックエンドサーバーに到達します。

⑤ データパケットを受信すると、バックエンドサーバーは最も外側の IP アドレスを削除し、IP ヘッダーの別の層があることを検出します。送信元 IP は CIP、宛先 IP は VIP です。 VIP は TUNL0 に設定されています。ルート検索後、ローカルIPアドレスであると判定されます。ユーザー空間層のアプリケーションに送信されます。応答後、VIP は送信元 IP、CIP は宛先 IP になります。データ パケットはネットワーク カードに送信され、最終的にクライアント ユーザーに返されます。

TUN モードの利点:

• シングルアームモードでは、LVS 負荷圧力は小さくなります。
• データ パケットの変更が少なく、情報の整合性が高い。
• コンピューター室を横断できます。

TUN モードの欠点:

• ポート マッピングはサポートされていません。
• RS バックエンド サーバーにモジュールをインストールし、VIP を構成する必要があります。
• トンネル ヘッダーの IP アドレスは固定されており、RS バックエンド サーバーのネットワーク カードが不均一である可能性があります。
• トンネル ヘッダーを追加すると断片化が発生し、最終的にはサーバーのパフォーマンスに影響する可能性があります。

TUN モードの使用シナリオ: 転送パフォーマンスに対する要件が高く、コンピューター ルームをまたぐ必要がある場合は、TUN モードを選択できます。

DRモード

ダイレクト ルーティング: ダイレクト ルーティング (DR モードとも呼ばれます) は、TUN モードの構造に似た半オープン ネットワーク構造を採用していますが、ノードはさまざまな場所に分散しているのではなく、スケジューラと同じ物理ネットワーク内に配置されます。ロード スケジューラはローカル ネットワークを介して各ノード サーバーに接続されるため、専用の IP トンネルを確立する必要はありません。強力な機能を備えているため、最も一般的に使用される作業モードです。

DR 実装プロセスは次のとおりです。

① クライアントユーザーがwww.baidu.comウェブサイトにリクエストを送信すると、まずDNSを通じてIPが解決され、その後Baiduサーバーにリクエストが送信されます。データ パケットはネットワークを経由して Baidu LVS 負荷分散サーバーに渡されます。

このとき、LVS ネットワーク カードに到着するデータ パケットには、送信元 IP アドレス (クライアント アドレス)、宛先 IP アドレス (Baidu の外部サーバー IP アドレス、つまり VIP)、送信元 MAC アドレス (LVS 接続ルーターの CMAC/MAC アドレス)、宛先 MAC アドレス (VIP に対応する VMAC/MAC アドレス) が含まれます。

②データパケットがネットワークカードに到達した後、リンク層を経由してPREROUTINGチェーンに渡され、ルートを検索し、宛先IPがLVSのVIPであることがわかります。このとき、INPUT チェーンに送信され、データ パケットの IP アドレス、MAC アドレス、ポートは変更されません。

③データパケットがINPUTチェーンに到着すると、LVSは宛先IPとポートに基づいてLVSで定義されたサービスであるかどうかを確認します。

定義された VIP サービスの場合、設定されたサービス情報に従って RealServer からバックエンド サーバー RS1 が選択され、RS1 がターゲットの送信ルートとして使用され、次のホップ情報と、データ パケットが送信される特定のネットワーク カードが決定されます。データ パケットを INET_HOOK 経由で OUTPUT チェーンに送信するのが最適です。

④ データパケットがPOSTROUTINGチェーンを通過した後、宛先MACアドレスはRealServer MACアドレス（RMAC）に変更され、送信元MACアドレスはLVSとRSの同じネットワークセグメント内のIPアドレスのMACアドレス（DMAC）に変更されます。この時点で、データ パケットは RealServer サーバーに送信されます。

⑤ データパケットがRealServerサーバに到着すると、要求メッセージのMACアドレスが自身のネットワークカードのMACアドレスであることがわかり、メッセージを受け入れます。処理が完了すると、lo インターフェースを介して eth0 ネットワーク カードに応答メッセージを送信し、送信します。

このとき、送信元 IP アドレスは VIP、宛先 IP は CIP、送信元 MAC アドレスは RS1 の RMAC、宛先 MAC アドレスはネクストホップ ルータの MAC アドレス (CMAC) となります。最後に、データ パケットは RS に接続されたルーターを介してクライアントに転送されます。

DS モードの利点:

• 応答データはLVSを経由しないため、パフォーマンスが高くなります。
• データ パケットの変更は少なく、情報の整合性は良好です。

DS モードの欠点:

• LVS と RS は同じ物理ネットワーク上に存在する必要があります。
• lo およびその他のカーネル パラメータは RS 上で設定する必要があります。
• ポート マッピングはサポートされていません。

DS モードの使用シナリオ: 高いパフォーマンス要件の場合は DR モードが推奨され、クライアントのソース IP アドレスを透過的に送信できます。

NAT モード: 必要なパブリック IP アドレスは 1 つだけです。これは最も使いやすい負荷分散モードであり、セキュリティも優れています。

TUN モードと DR モード: 負荷容量が強く、適用範囲が広く、ノードのセキュリティが低い。

LVS の 10 個の負荷スケジューリング アルゴリズム

LVS の 10 個の負荷スケジューリング アルゴリズムは次のとおりです。

① ラウンドロビン：受信したアクセス要求は、実際の接続数やサーバーのシステム負荷に関係なく、クラスター内の各ノードの実サーバーに順番に分配されます。

② 加重ラウンドロビン：受信したアクセス要求を実サーバーの処理能力に応じて順番に分配します。スケジューラは、各ノードの負荷を自動的に照会し、その重みを動的に増加させることで、処理能力の高いサーバーがより多くのアクセスを処理するようにします。

③ 最小接続数：実サーバーが確立した接続数に基づいてリクエストを割り当て、受信したアクセス要求を接続数の少ないノードに優先的に割り当てます。すべてのサーバー ノードのパフォーマンスがバランスが取れている場合は、この方法を使用して負荷をより適切に分散できます。

④ 重み付け最小接続：サーバーノードのパフォーマンスが大きく異なる場合、実サーバーの重みを自動的に調整し、重みの高いノードがより大きなアクティブ接続負荷を負担します。

⑤ ローカリティベースの最小接続: ローカリティベースの最小接続スケジューリング アルゴリズムである LBLC は、ターゲット IP ロード バランシングに使用され、通常はキャッシュ クラスターで使用されます。

このアルゴリズムは通常、サーバーがアクティブで負荷がかかっている場合、IP アドレス宛てのパケットをそのサーバーに送信します。サーバーが過負荷状態（アクティブな接続数が重みを超えている状態）にあり、サーバーの負荷が半分の場合、重み付けが最も低い接続のサーバーが IP アドレスに割り当てられます。

⑥ 複雑な局所性ベースの最小接続：複雑なスケジューリング アルゴリズムを備えた局所性ベースの最小接続である LBLCR もターゲット IP 負荷分散に使用され、通常はキャッシュ クラスターで使用されます。

LBLC スケジューリングとの違い: ロード バランサは、ターゲットから、そのターゲットにサービスを提供できる一連のサーバー ノードへのマッピングを維持します。ターゲットへのリクエストは、ターゲット サーバー セット内で接続が最も少ないノードに割り当てられます。

サーバー セット内のすべてのノードが過負荷になった場合は、クラスター内で接続が最も少ないノードが選択され、ターゲット サーバー クラスターに追加されます。指定された時間内にサーバー クラスターが変更されない場合、高負荷を回避するために、最も負荷の高いノードがサーバー クラスターから削除されます。

targetターゲットアドレスハッシュスケジューリングアルゴリズム：DH、このアルゴリズムは、ターゲットIPアドレスに基づいてハッシュ関数を介してターゲットIPとサーバーの間のマッピング関係を確立します。サーバーが利用できないか過負荷になっている場合、ターゲットIPに送信された要求がサーバーに固定されます。

sourceアドレスハッシュスケジューリングアルゴリズム：shはターゲットアドレスハッシュスケジューリングアルゴリズムに似ていますが、ソースアドレスアドレスハッシュアルゴリズムに基づいて固定サーバーリソースを静的に割り当てます。

shortest Delayスケジューリング：SED、最短の予想遅延スケジューリングアルゴリズムは、最短の予想遅延でネットワーク接続をサーバーに割り当てます。

リクエストがITHサーバーに送信される場合、予想されるレイテンシは（CI +1）/UIです。ここで、CIはITHサーバーの接続数、UIはITHサーバーの固定サービスレート（重量）です。

noverキュースケジューリング：NQ、QUEUEスケジューリングアルゴリズムは2速モデルを採用します。アイドルサーバーが使用可能な場合、リクエストは、高速応答サーバーを待つ代わりにアイドルサーバーに送信されます。

アイドルサーバーが利用できない場合、リクエストは予想される遅延が最小化されるサーバーに送信されます（最短の遅延スケジューリングアルゴリズム）。

LVS関連用語と説明

上記のコンテンツには、多くの用語または略語が含まれています。簡単に理解するための特定の意味の簡単な説明を次に示します。

• DS：ディレクターサーバー、フロントエンドロードバランシングノードサーバー。
• RS：リアルサーバー、バックエンドリアルサーバー。
• CIP：クライアントIP、クライアントIPアドレス。
• VIP：Virtual IP、ロードバランシングサーバーが外部アクセスに提供するIPアドレス。一般に、ロードバランシングIPアドレスは、仮想IPを介して高可用性を実現します。
• RIP：RealServer IP、ロードバランシングバックエンドの実際のサーバーIPアドレス。
• DIP：ディレクターIP、ロードバランスがバックエンドサーバーと通信するIPアドレス。
• CMAC：クライアントMACアドレス、LVSが接続されているルーターのMACアドレス。
• VMAC：MACアドレスは、負荷分散LVのVIPに対応しています。
• DMAC：MACアドレスは、LODバランスLVのディップに対応しています。
• RMAC：Macアドレスは、バックエンドREALサーバーのRIPアドレスに対応しています。

要約する

レビューするには、この記事を通して、LVSとは何か、LVS、LVSの組成、および作業原則を使用する理由を学ぶことができます。

参考文献:

• http://www.linuxvirtualserver.org/
• http://www.linuxvirtualserver.org/how.html
• http://www.linuxvirtualserver.org/documents.html