LVS、Nginx、HAProxy がどのように動作するかを本当に理解していますか?

現在のインターネット システムのほとんどは、サーバー クラスター テクノロジを使用しています。クラスターは、複数のサーバーに同じサービスを展開して、全体としてクラスターを形成し、外部にサービスを提供します。

[[272323]]

画像はUnsplashより

これらのクラスターには、Web アプリケーション サーバー クラスター、データベース サーバー クラスター、分散キャッシュ サーバー クラスターなどがあります。

実際のアプリケーションでは、Web サーバー クラスターの前に常に負荷分散サーバーが存在します。負荷分散デバイスの役割は、Web サーバー トラフィックの入り口として機能し、最適な Web サーバーを選択し、クライアントの要求をそのサーバーに転送して処理し、クライアントから実際のサーバーへの透過的な転送を実現することです。

近年普及しているクラウドコンピューティングや分散アーキテクチャは、基本的にバックエンドサーバーをコンピューティングリソースやストレージリソースとして利用し、管理サーバーによってサービスとしてパッケージ化されて外部に提供されるものです。クライアントは、実際にどのマシンがサービスを提供するかを気にする必要はありません。

その観点から見ると、ほぼ無制限の機能を備えたサーバーに直面しているように見えますが、本質的には、実際にサービスを提供するのはバックエンド クラスターです。

LVS、Nginx、HAProxy は、広く使用されている 3 つの負荷分散ソフトウェアです。一般的に、Web サイトの規模が大きくなるにつれて、さまざまな段階でさまざまなテクノロジを使用して負荷分散が行われます。

特定のアプリケーション要件を具体的に分析する必要があります。例えば、1日のPVが1000万未満の中小規模のWebアプリケーションであれば、Nginxで十分です。

マシンが多数ある場合は、DNS ポーリングを使用できます。 LVS はまだ多くのマシンを消費します。多数のサーバーを備えた大規模な Web サイトや重要なサービスの場合は、LVS の使用を検討できます。

現在、Web サイト アーキテクチャの最も合理的で人気のあるアーキテクチャ ソリューションは次のとおりです。

• Web フロントエンドは、ロードバランサーとして Nginx/HAProxy+Keepalived を使用します。
• バックエンドは、1 つのマスターと複数のスレーブ、および読み取りと書き込みの分離を備えた MySQL データベースを使用し、LVS + Keepalived アーキテクチャを採用しています。

LVS の

LVS は Linux Virtual Server の略で、Linux 仮想サーバーです。 LVS は現在、標準の Linux カーネルの一部となっています。

Linux 2.4 カーネル以降、LVS のすべての機能モジュールが完全に統合されています。カーネルにパッチを適用する必要がなく、LVS が提供するさまざまな機能を直接使用できます。

LVS は 1998 年から開発されており、比較的成熟した技術プロジェクトとなっています。

LVS アーキテクチャ:

LVS によって構築されるサーバー クラスター システムは、次の 3 つの部分で構成されます。

• フロントエンドの負荷分散層は、ロード バランサによって表されます。
• 中央のサーバー クラスター層は、サーバー アレイによって表されます。
• 最下位レベルのデータ共有ストレージ層は、共有ストレージによって表されます。

LVS 負荷分散メカニズム

HAProxy やその他のレイヤー 7 ソフト ロードとは異なり、LVS は HTTP パケットを対象としていません。したがって、LVS はレイヤー 7 ロードが実行できる URL 解決などのタスクを完了できません。

LVS は 4 層の負荷分散であり、OSI モデルの第 4 層であるトランスポート層上に構築されています。トランスポート層には、私たちがよく知っている TCP/UDP があります。 LVS は TCP/UDP 負荷分散をサポートします。

LVS は 4 層の負荷分散であるため、DNS ドメイン名ラウンドロビン解決、アプリケーション層負荷スケジューリング、クライアント スケジューリングなどの他の高レベル負荷分散ソリューションと比較して、効率が非常に高くなります。

いわゆる 4 層負荷分散は、主にメッセージ内のターゲット アドレスとポートに基づいています。 「コンテンツ スイッチング」とも呼ばれるレイヤー 7 ロード バランシングでは、主にメッセージ内の本当に意味のあるアプリケーション レイヤー コンテンツが使用されます。

LVS 転送は、主に IP アドレスの変更 (NAT モード、送信元アドレス変更 SNAT とターゲット アドレス変更 DNAT に分かれています) とターゲット MAC の変更 (DR モード) によって実現されます。

NAT モード: ネットワーク アドレス変換

NAT (ネットワーク アドレス変換) は、外部ネットワーク アドレスと内部ネットワーク アドレスをマッピングするテクノロジです。

NAT モードでは、すべての着信および発信ネットワーク データグラムは LVS によって処理される必要があります。 LVS は RS (実サーバー) のゲートウェイとして機能する必要があります。

パケットが LVS に到達すると、LVS は宛先アドレス変換 (DNAT) を実行し、宛先 IP を RS の IP に変更します。

RS はパケットを受信すると、クライアントが直接送信したかのように動作します。 RS が処理を完了して応答を返すと、送信元 IP は RS IP になり、宛先 IP はクライアント IP になります。

このとき、RS パケットはゲートウェイ (LVS) を介して転送され、LVS は送信元アドレス変換 (SNAT) を実行してパケットの送信元アドレスを VIP に変更します。この方法では、パケットは LVS によって直接クライアントに返されたように見えます。

DRモード: ダイレクトルーティング

DR モードでは、LVS クラスターと RS クラスターを同じ VIP にバインドする必要があります (RS は VIP をループバックにバインドすることによって実装されます)。

しかし、NAT との違いは、要求が LVS によって受信され、LVS を経由せずに実際にサービスを提供するサーバー (RealServer、RS) によって直接ユーザーに返されることです。

詳細には、要求が来ると、LVS はネットワーク フレームの MAC アドレスを特定の RS の MAC に変更するだけで、パケットは対応する RS に転送されて処理されます。現時点ではソース IP とターゲット IP は変更されておらず、LVS が移植を行っただけであることに注意してください。

RS が LVS によって転送されたパケットを受信すると、リンク層は MAC が自分のものであることを検出し、次に上位のネットワーク層に移動して IP も自分のものであることを検出するため、パケットは合法的に受け入れられ、RS は前方の LVS の存在を認識できません。

RS が応答を返すときは、LVS を経由せずに送信元 IP (つまり、ユーザーの IP) に直接返すだけで済みます。

DR ロード バランシング モードでは、データ配布中に IP アドレスは変更されず、Mac アドレスのみが変更されます。実際の処理要求の実際の物理 IP アドレスは、データ要求の宛先 IP アドレスと一致しているため、負荷分散サーバーを介してアドレス変換を実行する必要はありません。

応答データ パケットをユーザーのブラウザーに直接返すことで、負荷分散サーバーのネットワーク カード帯域幅がボトルネックになるのを防ぐことができます。

したがって、DR モードはパフォーマンスが向上し、大規模な Web サイトで広く使用されている負荷分散方法でもあります。

LVS の利点は次のとおりです。

• 強力な負荷耐性を備えており、トラフィックを生成せずに、配信のみを目的としてトランスポート層で動作します。この機能は、負荷分散ソフトウェアの中で最も強力なパフォーマンスを持ち、比較的少ないメモリと CPU リソースを消費することも判明しています。
• 構成可能性は比較的低いですが、これは欠点であると同時に利点でもあります。設定する項目がそれほど多くないため、多くの操作を必要とせず、人為的エラーの可能性が大幅に減少します。
• 強力な耐荷重性と、LVS + Keepalived などの完全なデュアルマシン ホット スタンバイ ソリューションを備えているため、安定して動作します。
• 渋滞はありません。 LVS はリクエストを分散するだけで、トラフィックは LVS から出ません。これにより、バランサー IO のパフォーマンスが大量のトラフィックの影響を受けなくなります。
• 応用範囲は比較的広いです。 LVS はトランスポート層で動作するため、HTTP、データベース、オンライン チャット ルームなど、ほぼすべてのアプリケーションの負荷を分散できます。

LVS の欠点は次のとおりです。

• ソフトウェア自体は正規表現処理をサポートしておらず、動的および静的分離を実行できません。ただし、現在多くの Web サイトではこの点に関して強い要求があり、これが Nginx、HAProxy+Keepalived の利点です。
• ウェブサイト アプリケーションが比較的大きい場合、LVS/DR+Keepalived の実装はより複雑になります。相対的に言えば、Nginx/HAProxy+Keepalived の方がはるかにシンプルです。

エンギンクス

Nginx は、高同時 HTTP リクエストを処理し、負荷分散のためのリバース プロキシ サーバーとして機能する強力な Web サーバー ソフトウェアです。

高性能、軽量、低メモリ消費、強力な負荷分散機能などの利点があります。

Nignx アーキテクチャ デザイン

従来のプロセスまたはスレッドベースのモデル (Apache はこのモデルを使用) と比較すると、同時接続を処理する場合、接続ごとに個別のプロセスまたはスレッドが確立され、ネットワークまたは入出力操作中にブロックされます。

これにより、新しい個別のプロセスまたはスレッドが、ヒープおよびスタック メモリの割り当て、新しい実行コンテキストを含む新しいランタイム環境を準備する必要があるため、大量のメモリと CPU が消費され、当然、過剰な CPU オーバーヘッドも発生します。

最終的には、コンテキストの切り替えが多すぎるためにサーバーのパフォーマンスが低下します。一方、Nginx のアーキテクチャは、モジュール式、イベント駆動型、非同期型、シングルスレッド型、非ブロッキング型となるように設計されています。

Nginx は多重化とイベント通知を広範に利用します。 Nginx が起動されると、マスター プロセスと n (n>=1) 個のワーカー プロセスを含む、システム内のデーモンとしてバックグラウンドで実行されます。

すべてのプロセスはシングルスレッド（つまり、メインスレッドは 1 つだけ）であり、プロセス間通信では主に共有メモリが使用されます。

マスター プロセスは、外部からの信号を受信し、ワーカー プロセスに信号を送信し、ワーカー プロセスの動作状態を監視するために使用されます。

ワーカー プロセスは、外部要求の実際のプロセッサです。各ワーカーのリクエストは独立しており、クライアントからのリクエストに対して平等に競合します。

リクエストは 1 つのワーカー プロセスでのみ処理でき、ワーカー プロセスにはメイン スレッドが 1 つしかないため、一度に処理できるリクエストは 1 つだけです。 (原理はNettyと非常に似ています)

Nginx 負荷分散

Nginx ロード バランシングは、主に 7 層ネットワーク通信モデルの 7 番目のアプリケーション層で HTTP と HTTPS をサポートします。 Nginx はリバース プロキシ モードで負荷分散を実行します。

リバースプロキシ方式とは、インターネット上の接続要求をプロキシサーバーで受け付け、その要求を社内ネットワーク上のサーバーに転送し、サーバーから取得した結果をインターネット上の接続を要求しているクライアントに返す方式です。このとき、プロキシ サーバーは外部からはサーバーとして表示されます。

Nginx には多くの負荷分散戦略があります。 Nginx Upstream は現在、次のメソッドをサポートしています。

• ポーリング (デフォルト): 各リクエストは時系列順に異なるバックエンド サーバーに割り当てられます。バックエンド サーバーがダウンしている場合は、自動的に削除されます。
• 重み: ポーリング確率を指定します。重みはアクセス比率に比例し、バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。
• IP_Hash: 各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、各訪問者は固定のバックエンド サーバーにアクセスし、セッションの問題を解決できます。
• 公平 (サードパーティ): リクエストはバックエンド サーバーの応答時間に基づいて分散され、応答時間が短いリクエストが優先されます。
• URL_Hash (サードパーティ): アクセスされた URL のハッシュ結果に従ってリクエストを分散し、各 URL が同じバックエンド サーバーに送信されるようにします。これは、バックエンド サーバーがキャッシュされている場合に、より効果的です。

Nginx の利点は次のとおりです。

• クロスプラットフォーム: Nginx はほとんどの Unix 系 OS でコンパイルして実行でき、Windows に移植されたバージョンもあります。
• 非常にシンプルな構成: 始めるのは非常に簡単です。構成スタイルはプログラム開発と同じ、神のような構成です。
• ノンブロッキング、高同時接続: 公式テストでは 50,000 の同時接続をサポートできることが示されており、実際の運用環境では 20,000 ～ 30,000 の同時接続に達することができます。
• イベント駆動型: 通信メカニズムは、大規模な同時接続をサポートするために Epoll モデルを採用しています。
• マスター/ワーカー構造: マスター プロセスは 1 つ以上のワーカー プロセスを生成します。
• メモリ消費量が少ない: 大量の同時リクエストを処理する場合、メモリ消費量は非常に少なくなります。同時接続数が 30,000 の場合、開かれた 10 個の Nginx プロセスは 150M のメモリのみを消費します (15M * 10 = 150M)。
• 組み込みのヘルスチェック機能: Nginx プロキシの背後にある Web サーバーがダウンしても、フロントエンドのアクセスには影響しません。
• 帯域幅を節約: GZIP 圧縮をサポートし、ブラウザのローカル キャッシュにヘッダーを追加します。
• 高い安定性: リバース プロキシとして使用する場合、ダウンタイムの可能性は最小限に抑えられます。

Nginx の欠点は次のとおりです。

• Nginx は HTTP、HTTPS、TCP、電子メールなどのプロトコルのみをサポートしているため、適用範囲が狭く、それが欠点です。
• バックエンド サーバーのヘルス チェックでは、URL 経由ではなく、ポート経由の検出のみがサポートされます。直接的なセッションの永続性はサポートされていませんが、IP_Hash を通じて解決できます。

HAプロキシ

HAProxy は、TCP (レイヤー 4) と HTTP (レイヤー 7) の 2 つのプロキシ モードをサポートし、仮想ホストもサポートします。

HAProxy の利点は、セッション保持や Cookie ガイダンスのサポートなど、Nginx の欠点の一部を補うことができます。また、指定された URL を取得してバックエンド サーバーの状態を検出することもサポートしています。

HAProxy は LVS に似ており、それ自体は単なる負荷分散ソフトウェアです。効率性の観点から見ると、HAProxy は Nginx よりも負荷分散速度が優れており、並行処理でも Nginx よりも優れています。

HAProxy は、TCP プロトコルの負荷分散転送をサポートし、MySQL 読み取りの負荷分散、バックエンドの MySQL ノードの検出と負荷分散を行うことができます。 LVS+Keepalived を使用して、MySQL マスターとスレーブの負荷を分散できます。

HAProxy には多くの負荷分散戦略があります。

• ラウンドロビン
• ウェイトラウンドロビン
• ソース（元のアドレスを保持）
• RI (リクエスト URL)
• RDP-Cookie (Cookie による)

参照：

• 鍾呉: https://zhongwuzw.github.io
• 王晨春: http://www.importnew.com/11229.html
• 周秀龍: http://edisonchou.cnblogs.com