Linux 負荷分散 LVS の詳細な理解

1. LVS 負荷分散

ロード バランシング クラスターは Load Balance cluster の略称で、中国語では load balance cluster と翻訳されます。一般的に使用される負荷分散オープンソース ソフトウェアには、Nginx、LVS、Haproxy などがあり、商用ハードウェア負荷分散デバイスには、F5、Netscale などがあります。

2. 負荷分散LVSの基本紹介

LB クラスターのアーキテクチャと原理は非常にシンプルです。ユーザーからのリクエストが入ると、そのリクエストは Director Server に直接配信され、その後、設定されたスケジューリング アルゴリズムに従って、バックエンドの実サーバーにユーザー リクエストがインテリジェントかつ均等に配信されます。異なるマシン上のユーザーによって異なるデータが要求されるのを回避するには、すべてのユーザーが要求するデータが同じであることを保証する共有ストレージが必要です。

これは、Zhang Wensong 博士が始めたオープン ソース プロジェクトです。公式 Web サイトは http://www.linuxvirtualserver.org です。現在、LVS は Linux カーネル標準の一部となっています。 LVS を使用することで達成できる技術的目標は、LVS によって実現される負荷分散テクノロジと、優れた信頼性、拡張性、操作性を備えた Linux オペレーティング システムを通じて、高性能で可用性の高い Linux サービス クラスターを実装することです。これにより、低コストで最適なパフォーマンスを実現します。

LVS クラスターは、IP 負荷分散テクノロジーとコンテンツ要求分散テクノロジーを使用します。スケジューラは優れたスループット レートを備えており、リクエストをさまざまなサーバーに転送してバランスよく実行します。スケジューラはサーバー障害を自動的に遮断し、サーバー グループを高性能で可用性の高い仮想サーバーとして形成します。サーバー クラスター全体の構造はクライアントに対して透過的であり、クライアント プログラムとサーバー プログラムを変更する必要はありません。

3. LVSアーキテクチャ

負荷分散の原理は非常にシンプルです。クライアントがリクエストを開始すると、リクエストは直接 Director Server (スケジューラ) に送信されます。このとき、設定されたスケジューリング アルゴリズムに従って、リクエストはアルゴリズムの規則に従って実際のバックグラウンド サーバーにインテリジェントに分散されます。圧力を均等に分散させるためです。しかし、HTTP 接続はステートレスであることがわかっています。次のようなシナリオを考えてみましょう。何かを購入するために Taobao にログインします。特定の製品が気に入ったら、ショッピング カートに追加しますが、ページを更新します。このとき、負荷分散のため、スケジューラは新しいサーバーを選択してサービスを提供し、ショッピング カートの内容はすべて消えてしまいます。その結果、ユーザー エクスペリエンスが非常に悪くなります。したがって、ユーザーが要求したデータが同じであることを確認するには、ストレージ共有が必要です。したがって、LVS 負荷分散は 3 層アーキテクチャ (LVS 負荷分散の主要コンポーネント) に分割されます。

図に示すように:

LVS の各レベルの詳細な紹介:

3.1 ロードバランサ層

クラスタ システム全体のフロント エンドに位置し、1 つ以上の負荷スケジューラ (Director Server) で構成されます。LVS モジュールは Director Server にインストールされ、Director の主な機能はルータの機能に似ています。LVS 機能を実行するために設定されたルーティング テーブルが含まれており、これらのルーティング テーブルを通じて、ユーザー要求を Server Array 層のアプリケーション サーバー (Real Server) に配布します。同時に、リアル サーバー サービス監視モジュール Ldirectord をディレクター サーバーにインストールする必要があります。このモジュールは、各リアル サーバー サービスのヘルス状態を検出するために使用されます。実サーバーが使用できない場合は、LVS ルーティング テーブルから削除し、復元されたら再度追加します。

3.2 サーバーアレイ層

実際にアプリケーション サービスを実行するマシンのグループで構成されます。リアル サーバーは、WEB サーバー、MALL サーバー、FTP サーバー、DNS サーバーなどです。各リアル サーバーは、さまざまな場所に分散された高速 LAN または WAN を介して接続されます。実際のアプリケーションでは、ディレクター サーバーは同時にリアル サーバーとして機能することもできます。

3.3 共有ストレージ層

すべてのリアルサーバーに共有ストレージスペースとコンテンツの一貫性を提供するストレージ領域です。物理的には、一般的にディスクアレイデバイスで構成されます。コンテンツの一貫性を提供するために、一般的には NFS ネットワークファイルシステムを介してデータを共有できます。ただし、NFS のパフォーマンスは、忙しいビジネスシステムではあまり良くありません。このとき、Red Hat の GFS ファイルシステムなどのクラスターファイルシステムを使用できます。企業は、調整できるようにバックエンド アカウントを持っている必要があります。そうでない場合、顧客は A にお金を支払い、同一の口座がないため B が顧客の受け取りを引き継ぎます。 B は、顧客が支払いをしなかったため、これは顧客体験の問題ではないと述べました。

4. LVSの実装原則

（１）ユーザー負荷分散スケジューラ（ディレクターサーバー）がリクエストを開始すると、スケジューラはリクエストをカーネル空間に送信する。

（２）PREROUTINGチェーンはまずユーザーリクエストを受信し、ターゲットIPが実際にローカルIPであることを確認し、データパケットをINPUTチェーンに送信する。

（3）IPVSはINPUTチェーン上で動作します。ユーザーリクエストがINPUTに到着すると、IPVSはユーザーリクエストを定義されたクラスタサービスと比較します。ユーザーがクラスタサービスを要求した場合、IPVSはデータパケット内のターゲットIPアドレスとポートを強制的に変更し、新しいデータパケットをPOSTROUTINGチェーンに送信します。

（4）データパケットを受信した後、POSTROUTINGチェーンはターゲットIPアドレスがまさに自身のバックエンドサーバーであることを見つけます。その後、データパケットは最終的にルーティング選択を通じてバックエンドサーバーに送信されます。

5. LVSの動作原理

LVS には、NAT、DR、TUN、FULL-NAT の 4 つの動作モードがあります。比較すると、動作原理上、NAT は最もシンプルな構成ですが、NAT はスケジューラに過度の負荷をかけ、効率が最も低くなります。DR と TUN の動作原理は似ていますが、DR ではすべてのホストが同じ物理環境にある必要がありますが、TUN ではすべてのホストを異なる場所に分散でき、1 つのサーバーをニューヨークに、もう 1 つのサーバーを深センに置くことができます。最も一般的に使用されるのは FULL-NAT です。

6. LVS関連用語

（１）DS：ディレクターサーバーはフロントエンドロードバランサーノードを指します。

（２）RS：実サーバー、バックエンドで実際に動作するサーバー。

（３）VIP：ユーザのリクエストを外部に直接向け、ユーザのリクエストの対象となるIPアドレスです。

（4）DIP：ディレクターサーバーIPは、主に内部サーバーとの通信に使用されるIPアドレスです。

（５）RIP：実サーバーIP：バックエンドサーバーのIPアドレス。

（6）CIP：クライアントIP：アクセスクライアントのIPアドレス。

7. NAT モード - ネットワーク アドレス変換

これは、ネットワーク アドレス変換を使用することで実現されます。まず、スケジューラ (LB) は、クライアントの要求データ パケット (要求の宛先 IP は VIP) を受信すると、スケジューリング アルゴリズムに基づいて、どのバックエンド リアル サーバー (RS) に要求を送信するかを決定します。次に、ディスパッチャは、クライアントから送信された要求データ パケットのターゲット IP アドレスとポートをバックエンド リアル サーバーの IP アドレス (RIP) に変更し、リアル サーバー (RS) がクライアントの要求データ パケットを受信できるようにします。実サーバーは要求に応答した後、デフォルト ルートをチェックし (NAT モードでは、RS のデフォルト ルートを LB サーバーに設定する必要があります)、応答データ パケットを LB に送信します。LB は応答パケットを受信すると、パケットの送信元アドレスを仮想アドレス (VIP) に変更し、クライアントに返送します。

VS/NAT は最も簡単な方法です。すべての RealServer は、ゲートウェイを Director に向けるだけで済みます。クライアントは任意のオペレーティング システムを使用できますが、この方法では、Director によって駆動できる RealServer の数は比較的制限されます。 VS/NAT モードでは、Director は RealServer としても機能します。 VS/NAT アーキテクチャを図に示します。

8. NATモードの動作原理

（1）ユーザー要求がディレクターサーバーに到達すると、要求データパケットはまずカーネル空間のPREROUTINGチェーンに送られます。このとき、メッセージの送信元 IP は CIP、宛先 IP は VIP です。

（２）PREROUTINGは、データパケットの宛先IPがローカルマシンであることを確認し、データパケットをINPUTチェーンに送信します。

（3）IPVSは、データパケットによって要求されたサービスがクラスタサービスであるかどうかを比較し、クラスタサービスである場合は、データパケットのターゲットIPアドレスをバックエンドサーバIPに変更し、データパケットをPOSTROUTINGチェーンに送信します。このとき、メッセージの送信元 IP は CIP、宛先 IP は RIP です。

（4）POSTROUTINGチェーンはルートを選択し、データパケットをリアルサーバーに送信します。

（５）リアルサーバーは、ターゲットが自身のIPアドレスであるかどうかを比較して判断し、応答メッセージを構築してディレクターサーバーに返送します。このとき、メッセージの送信元 IP は RIP、宛先 IP は CIP です。

（6）ディレクターサーバーは、クライアントに応答する前に、送信元IPアドレスを自身のVIPアドレスに変更してから、クライアントに応答します。このとき、メッセージの送信元 IP は VIP で、宛先 IP は CIP です。

9. DRモード - ダイレクトルーティングモード

DR モードは、ダイレクト ルーティング テクノロジを使用して仮想サーバーを実装します。接続のスケジュールと管理は VS/NAT や VS/TUN と同じですが、メッセージの転送方法が異なります。VS/DR は要求メッセージの MAC アドレスを書き換えて要求をリアルサーバーに送信し、リアルサーバーは応答を直接クライアントに返すため、VS/TUN の IP トンネルのオーバーヘッドが排除されます。この方法は、3 つの負荷スケジューリング メカニズムの中で最もパフォーマンスが高く、最適ですが、ディレクター サーバーと実サーバーの両方に、同じ物理ネットワーク セグメントに接続されたネットワーク カードが必要です。

Director と RealServer は、中断のない LAN を介してネットワーク カードで物理的に接続されている必要があります。 RealServer にバインドされた VIP は、それぞれの非 ARP ネットワーク デバイス (lo や tunl など) 上で設定されます。ディレクターの VIP アドレスは外部から参照できますが、RealServer の VIP は外部からは参照できません。 RealServer のアドレスは、内部アドレスまたは実アドレスのいずれかになります。

DR モードでは、要求メッセージのターゲット MAC アドレスを書き換えて、実サーバに要求を送信します。実サーバの応答の処理結果は、クライアント ユーザに直接返されます。 TUN モードと同様に、DR モードではクラスター システムのスケーラビリティを大幅に向上できます。さらに、DR モードでは IP トンネルのオーバーヘッドがないため、クラスター内の実サーバーが IP トンネル プロトコルをサポートする必要がありません。ただし、スケジューラ LB と実サーバ RS は、同じ物理ネットワークセグメントに接続されたネットワークカードを持ち、同じ LAN 環境にある必要があります。

9.1、DRモードの動作原理図

（１）まず、ユーザーはCIPを使ってVIPをリクエストします。

(2) 上の図からわかるように、ディレクターサーバーとリアルサーバーの両方に同じ VIP を設定する必要があります。そのため、ユーザー要求がクラスターネットワークのフロントエンドルーターに到達すると、要求データパケットの送信元アドレスは CIP で、宛先アドレスは VIP です。このとき、ルーターは VIP が誰であるかを尋ねるブロードキャストも送信します。クラスター内のすべてのノードは VIP で設定されているため、ルーターは最初にルーターに応答したノードにユーザー要求を送信します。この場合、クラスターシステムは無意味です。ゲートウェイルーターで静的ルーティングを設定して VIP がディレクターサーバーであることを指定するか、リアルサーバーがネットワークからの ARP アドレス解決要求を受け入れないようにするメカニズムを使用できます。このようにして、ユーザーの要求パケットはディレクターサーバーを通過します。

（3）ユーザ要求がディレクターサーバに到達すると、要求されたデータパケットはまずカーネル空間のPREROUTINGチェーンに送られます。このとき、パケットの送信元IPはCIP、宛先IPはVIPです。

（4）PREROUTINGは、データパケットの宛先IPがローカルマシンであることを確認し、データパケットをINPUTチェーンに送信します。

（５）IPVSは、データパケットが要求したサービスがクラスタサービスであるかどうかを比較する。クラスタサービスである場合、要求メッセージ内の送信元MACアドレスはDIPのMACアドレスに変更され、宛先MACアドレスはRIPのMACアドレスに変更される。その後、データパケットはPOSTROUTINGチェーンに送られる。このとき、送信元IPと宛先IPは変更されない。送信元MACアドレスのみがDIPのMACアドレスに変更され、宛先MACアドレスがRIPのMACアドレスに変更される。

（6）DSとRSは同じネットワーク内にあるため、データパケットはレイヤー2を介して送信されます。POSTROUTINGチェーンは、ターゲットMACアドレスがRIPのMACアドレスであることを確認した後、データパケットをリアルサーバーに送信します。

（７）RSは要求メッセージのMACアドレスが自身のMACアドレスであることを確認してメッ​​セージを受信する。処理が完了すると、対応するメッセージが lo インターフェースを介して eth0 ネットワーク カードに送信され、送信されます。このとき、送信元 IP アドレスは VIP、ターゲット IP アドレスは CIP です。

（８）応答メッセージが最終的にクライアントに配信される。

DR を構成する方法は 3 つあります。

• 最初の方法: VIP に対応するアドレスは Director 上の MAC でなければならないことがルーターに明記されています。一度バインドすると、今後 VIP と通信するときに再度要求する必要はありません。このバインドは静的であるため、期限切れになることはなく、再度要求を開始することもありません。ただし、前提条件があります。ルーティング デバイスには、MAC アドレスをバインドするための操作権限が必要です。ルーターがオペレーターによって操作され、私たちが操作できない場合はどうなるでしょうか?最初の方法は単純ですが、必ずしも実行可能ではありません。
• 2 番目のタイプ: 一部のホスト (Red Hat など) では、iptables に似た arptables というプログラムが導入されています。これは、アクセス制御のために arp または MAC に基づいています。明らかに、各実サーバーで arptables ルールを定義するだけで済みます。ユーザーの arp ブロードキャスト要求のターゲット アドレスがローカル VIP である場合、応答は返されないか、応答メッセージの送信が許可されません。明らかに、(ゲートウェイ) はそれを受信できません。つまり、ディレクターからの応答メッセージはゲートウェイに到達できます。これも問題ありません。使用できる 2 番目の方法は、arptables に基づいています。
• 3 番目のタイプ: 比較的新しいバージョンでは、2 つの新しいカーネル パラメータ (kernelparameter) が追加されました。1 つ目は arp_ignore で、ARP 要求を受信するときの応答レベルを定義します。2 つ目は arp_announce で、外部に自身のアドレスをアナウンスするときのアナウンス レベルを定義します。 [ヒント: 言うまでもなく、現在のシステムではカーネル内でこれらのパラメータが一般的にサポートされています。パラメータを使用すると、より簡単に調整できます。arptables などの追加条件や外部ルーティング構成設定に依存しません。代わりに、通常は 3 番目の構成方法を使用します。

arp_ignore: ARP要求を受信する際の応答レベルを定義します

0: 対応するアドレスがローカルに設定されている限り、応答が返されます。 （デフォルト）

1: ターゲット IP アドレスがローカル ネットワーク アドレスである ARP 要求にのみ応答します。

2: ターゲット IP アドレスがローカル ネットワーク アドレスであり、ソース IP とターゲット IP が同じサブネット内にある ARP 要求にのみ応答します。

3: ネットワーク インターフェイスの ARP 要求には応答せず、設定された一意の接続アドレスにのみ応答します。

4-7: 予約済みで使用されません。

8: すべての ARP 要求に応答しません。

arp_announce: 外部へのアドレスのアナウンスレベルを定義します。

0: 任意のローカル インターフェイス上の任意のアドレスを外部にアドバタイズします。

1: ビューは、そのネットワークと一致するアドレスのみをターゲット ネットワークにアドバタイズします。

2: ローカル インターフェイス上のアドレスに一致するネットワークにのみアドバタイズします。

9.2. DRモードの特徴

• フロントエンド ルータが、宛先アドレスが VIP であるすべてのメッセージを RS ではなくディレクター サーバーに送信することを確認します。
• ディレクターとRSのVIPは同じVIPです。
• RS はプライベート アドレスまたはパブリック ネットワーク アドレスを使用できます。パブリック ネットワーク アドレスを使用すると、インターネット経由で RIP に直接アクセスできます。
• RS と Director Server は同じ物理ネットワーク内に存在する必要があります。
• すべての要求メッセージは Director Server を経由しますが、応答メッセージは Director Server を経由しません。
• アドレス変換もポート変換もサポートされていません。
• RS は最も一般的なオペレーティング システムです。
• RS ゲートウェイは DIP を指すことはできません (Director を経由することは許可されていないため)
• RSのloインターフェースにVIP IPアドレスを設定する
• DR モードは市場で最も広く使用されています。
• 欠点: RS と DS は同じコンピューター ルームに存在する必要があります。

10. トンネルモード

10.1. トンネルモードの動作原理

（1）ユーザー要求がディレクターサーバーに到達すると、要求されたデータパケットはまずカーネル空間でPREROUTINGチェーンを取得します。このとき、パケットの送信元IPはCIP、宛先IPはVIPです。

（２）PREROUTINGは、データパケットの宛先IPがローカルマシンであることを確認し、データパケットをINPUTチェーンに送信します。

（3）IPVSは、データパケットによって要求されたサービスがクラスタサービスであるかどうかを比較します。クラスタサービスである場合、送信元IPをDIP、宛先IPをRIPとして、IPパケットの別のレイヤーを要求メッセージのヘッダーにカプセル化します。次に、送信元 IP が DIP、宛先 IP が RIP である POSTROUTING チェーンに送信されます。

（４）POSTROUTINGチェーンは、最新のカプセル化されたIPメッセージに基づいてデータパケットをRSに送信する（外側の層で追加のIPヘッダーがカプセル化されているため、この時点ではトンネルを介して送信されていると理解できる）。このとき、送信元 IP は DIP、ターゲット IP は RIP です。

(5) メッセージを受信したRSは、それが自分のIPアドレスであることに気づき、メッセージを受信します。最も外側のIPを削除すると、内部に別のIPヘッダー層があり、ターゲットが自分のloインターフェースVIPであることがわかります。次に、RSは要求の処理を開始します。処理が完了すると、loインターフェースを介してeth0ネットワークカードに送信し、それを渡します。このとき、送信元 IP は VIP、ターゲット IP は CIP です。

（６）応答メッセージが最終的にクライアントに配信される。

10.2. トンネルモードの機能

• RIP、VIP、DIP はすべてパブリック ネットワーク アドレスです。
• RS ゲートウェイは DIP をポイントしませんし、ポイントすることもできません。
• すべての要求メッセージは Director Server を経由しますが、応答メッセージは Director Server を経由しません。
• ポート マッピングはサポートされていません。
• RS システムはトンネリングをサポートしている必要があります。

11. LVSスケジューリングアルゴリズム

固定スケジューリングアルゴリズム: rr、wrr、dh、sh

動的スケジューリング アルゴリズム: wlc、lc、lblc、lblcr

固定スケジューリング アルゴリズム: スケジューラはバックエンド サーバーがビジーかどうかを判断せず、通常どおりにリクエストをディスパッチします。

動的スケジューリング アルゴリズム: スケジューラはバックエンド サーバーのビジー状態を判断し、スケジューリング アルゴリズムに基づいて要求を動的にディスパッチします。

11.1. rr: ラウンドロビン

このアルゴリズムは最も単純で、ラウンドロビン方式で異なるサーバーにリクエストをディスパッチします。このアルゴリズムの最大の特徴はその単純さです。ポーリング アルゴリズムでは、すべてのサーバーが要求を処理する能力が同じであると想定しています。スケジューラは、バックエンド RS の構成と処理能力に関係なく、すべての要求を各実サーバーに均等に分散し、非常に均等に分散します。このスケジューリングの欠点は、バックエンド サーバーがどれだけビジーであっても、スケジューラがリクエストを順番に送信することです。サーバー A のリクエストがすぐに完了しても、サーバー B のリクエストが継続する場合、サーバー B は常に非常にビジー状態になり、サーバー A は非常にアイドル状態になり、バランスが取れなくなります。

11.2. wrr: 加重ラウンドロビン

このアルゴリズムには、rr アルゴリズムと比較して重みの概念が追加されています。RS の重みを設定できます。重みが高いほど、より多くのリクエストが分散されます。重みの範囲は 0 ～ 100 です。これは主に rr アルゴリズムの最適化と補足です。LVS は各サーバーのパフォーマンスを考慮し、各サーバーに重みを追加します。サーバー A の重みが 1、サーバー B の重みが 2 の場合、サーバー B にスケジュールされるリクエストはサーバー A の 2 倍になります。サーバーの重みが増すほど、処理するリクエストの数も増えます。

11.3. dh: 宛先ハッシュスケジューリングアルゴリズム（宛先ハッシュ）

簡単に言えば、同じタイプのリクエストは同じバックエンド サーバーに割り当てられます。たとえば、.jgp、.jpg などで終わるリクエストは同じノードに転送されます。このアルゴリズムは、真の負荷分散用ではなく、リソースの分類された管理用です。このスケジューリング アルゴリズムは、キャッシュ ヒット率を向上させるためにキャッシュ ノードを使用するシステムで主に使用されます。

11.4. sh: ソースハッシュスケジューリングアルゴリズム

つまり、バックエンド サーバーが正常に動作していて過負荷になっていない場合は、同じ IP アドレスからのリクエストはバックエンドの同じサーバーに送信されます。これにより、セッション共有の問題は解決できますが、ここで問題があります。多くの企業、コミュニティ、学校が 1 つの IP アドレスを共有しているため、リクエストが不均等に分散されてしまいます。

11.5、lc: 最小接続

このアルゴリズムは、バックエンド RS の接続数に基づいて、リクエストを誰に配布するかを決定します。たとえば、RS1 の接続数が RS2 の接続数より少ない場合、リクエストは最初に RS1 に送信されます。ここでの問題は、セッションの永続性、つまりセッションの共有が実現できないことです。

11.6. wlc: 重み付け最小接続

これには、最小接続数と比較した重み付けの概念が追加されています。つまり、最小接続数に基づいて重み値が追加されます。接続数が似ている場合、重み値が大きいほど、割り当てられるリクエストの優先度が高くなります。

11.7. LBLC: 局所性に基づく最小接続スケジューリングアルゴリズム

同じ宛先アドレスからのリクエストは、サーバーがまだ完全にロードされていない場合は同じ RS に割り当てられ、それ以外の場合は接続数が最も少ない RS に割り当てられ、次の割り当てではその RS が最初に考慮されます。

上記は、Linux 負荷分散 LVS を深く理解するための詳細な内容です。Linux 負荷分散 LVS の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。