まず最初に、ロード バランシングとは何かについて説明します。ロード バランシングとは、リクエストの内容に応じて、一連のリクエストを異なるバックエンドに分散して対応する処理を実行することで、負荷分散、マスター スレーブ切り替えなどの機能を実現することです。 異なる負荷分散ソフトウェアには、異なるトラフィック分散アルゴリズムがあります。今日は、市場で最も主流の 2 つの負荷分散ソフトウェアを比較し、それぞれの長所と短所、および多くの場合の連携方法を確認します。 【4階・7階】 まず、4 層と 7 層の違いについて説明します。 レイヤー 4 ロード バランシングは、IP + ポート ロード バランシングを指します。 レイヤー 7 負荷分散とは、WEB リクエストや URL などのアプリケーション層情報に基づく負荷分散を指します。 もちろん、同様に、MAC アドレスに基づくレイヤー 2 負荷分散や、IP アドレスに基づくレイヤー 3 負荷分散もあります。 4 層負荷分散では、主に IP 層と TCP/UDP 層を分析します。 7 層の負荷分散では、HTTP プロトコル、URL、Cookie などのアプリケーション層プロトコルやその他の情報の分析が必要です。 【LVSについて】 LVS は動作モードが非常にシンプルなため、負荷容量が強力です。リクエストを分散するだけです。さらに、トラフィックなしで第 4 層で動作し、最高の効率を実現します。 LVS はレイヤー 4 にあり、ほぼすべてのアプリケーションの負荷分散を実行できます。 ただし、LVS はバックエンドの障害には影響されません。たとえば、DR モードでは、バックエンド サーバーが VIP で構成されていない場合、要求されたデータの一部が直接失われます。 さらに、LVS はネットワーク環境の安定性に対する要件が高く、リクエストが失敗した場合は、フロントエンド アプリケーション自体の再試行メカニズムにのみ依存し、負荷分散によってリクエストが再送信されることはありません。 さらに、LVS はネットワーク アーキテクチャによっても制限されます。設計の開始時に、ネットワーク アーキテクチャが LVS 負荷の前提条件を満たしているかどうかを考慮する必要があります。 【nginxについて】 同様に、nginx も負荷分散に使用できますが、nginx は送信元と送信先の両方の端に接続を確立する必要があるため、トラフィックの処理速度はマシンの I/O、CPU メモリなどの一連の構成によって制限され、nginx の負荷容量は比較的低くなります。 nginx のインストールと設定は比較的簡単です。LVS と比較すると、nginx はネットワークに接続できる限り、それほど厳密なネットワーク アーキテクチャを必要としません。 また、nginx 独自の再試行メカニズムにより、リクエストの送信に失敗した場合、正常なバックエンドに再送信されるようになります。 ただし、nginx には既成のホット スタンバイ メカニズムがないため、単一障害点の問題があり、通常は keepalived と併用する必要があります。 ただし、アプリケーション層のロードバランサーとして (後に、ストリーム モジュールの導入により、第 4 層もサポートされるようになりました)、nginx は負荷分散、リザーブ スイッチング、HTTPS 書き込み、帯域幅速度制限、実 IP の非表示、実ポートの非表示、攻撃のシールドなどの機能を提供できますが、LVS では提供できません。 【対比】 LVS と nginx はどちらも非常に主流の負荷分散方法です。それぞれに長所と短所があり、実稼働環境ではそれぞれの特性に応じて選択する必要があります。 | LVS の | エンギンクス | | 4層 | 4階/7階 | 耐荷重 | 強力 | 弱い | 構成可能性 | 構成可能性が低い また、人為的ミスの可能性も減ります | 高い構成可能性 いくつかの高度な機能は設定可能 | 安定性 | 高い安定性 完全なデュアルマシンホットスタンバイソリューションがあります | 安定性が低い、単一のマシンが故障する 既製のデュアルマシンホットスタンバイソリューションがない | ネットワークアーキテクチャの依存関係 | 強い依存 ネットワークアーキテクチャ設計に大きく依存 もちろん、より単純なNAT方式を使用してこの問題を解決することもできます。 | 依存関係なし | ネットワーク安定性の依存性 | 頼る データ パケットが不良なバックエンドに配布されると、再配布されず、直接エラーが返されます。 | 依存性なし パケットが不良バックエンドに配布されエラーが返された後、正常なバックエンドに再配布しようとします。 | ネットワークトラフィック | 要求トラフィックのみが lvs ネットワークを通過し、応答トラフィックはバックエンド サーバーのネットワークによって返されます。 FULL_NAT は Nginx と同じです。 | すべてのリクエストとレスポンスのトラフィックはnginxを経由します | ホストのパフォーマンス要件 | 要件が低い LVS はリクエストを分散するだけで、トラフィックは LVS から出ないので、ボトルネックはネットワーク帯域幅とネットワーク カードのパフォーマンスによってのみ制限されます。 | 高い要件 nginx は送信元と送信先の両方に個別の接続を確立する必要があり、途中でデータ パケットの解析が行われるため、ホスト マシンの I/O パフォーマンスと CPU メモリに依存します。 | 転送方法 | 同期転送 LVS サーバーは要求を受信するとすぐにバックエンド サーバーにリダイレクトし、クライアントはバックエンド サーバーとの接続を直接確立します。 | 非同期転送 クライアント接続を維持しながら、同じ内容の新しいリクエストがバックエンドに送信されます。バックエンドが結果を返した後、nginx はそれをクライアントに返します。 | 他の | | 書き換えルールをサポート: 異なるドメイン名と URL に応じて、HTTP リクエストを異なるバックエンド サーバー グループに分割できます。 帯域幅を節約: gzip 圧縮をサポートし、ローカル ブラウザー キャッシュのヘッダーを追加します。 |
【両者の組み合わせ】
使用面では、フロントエンドで一般的に採用される戦略はLVS、つまりDNSがLVSバランサーを指すようにする必要があります。主な理由は、nginxは強力ですが、バックエンドサーバーの規模が大きい場合、nginxのネットワーク帯域幅が大きなボトルネックになるためです。 ただし、LVS をロードバランサーとして使用する場合、リクエストを受信するバックエンドサーバーに問題が発生すると、リクエストは失敗します。 そのため、多くの場合、nginx は LVS のノードとして使用され、負荷分散を実行します。これにより、nginx のパフォーマンスによって引き起こされる深刻な帯域幅のボトルネックを回避できるだけでなく、nginx のエラー再送信を使用して LVS ワンショットトランザクションを回避し、https オフロードやメッセージヘッダーの変更など、nginx のさまざまな高度な機能も使用できます。 以上がnginxとlvsのメリットとデメリット、適切な使用環境についての詳しい内容です。nginxとlvsの比較についてさらに詳しく知りたい方は、123WORDPRESS.COMの他の関連記事もぜひご覧ください! 以下もご興味があるかもしれません:- Nginx における 2 つの現在の制限方法についての簡単な説明
- Nginx + consul + upsync を使用して動的負荷分散を実現する方法の詳細な説明
- https暗号化アクセス用にnginxを設定するための詳細なチュートリアル
- nginx 設定ファイルパスとリソースファイルパスを表示する方法
- Windows 上で Nginx+Tomcat クラスタを実装するプロセスの分析
- nginxがドメイン名を設定した後のセカンダリディレクトリ内の異なるプロジェクトの設定操作
|