NginxサーバーでTCPの負荷分散を構成する方法

1. nginx のインストール
1. nginx のダウンロード

# wget http://nginx.org/download/nginx-1.2.4.tar.gz

2. TCP モジュール パッチのダウンロード

# wget https://github.com/yaoweibin/nginx_tcp_proxy_module/tarball/master

ソース コードのホームページ: https://github.com/yaoweibin/nginx_tcp_proxy_module

3. nginx

# tar xvf nginx-1.2.4.tar.gz
# tar xvf yaoweibin-nginx_tcp_proxy_module-v0.4-45-ga40c99a.tar.gz
# cd nginx-1.2.4
# patch -p1 < ../yaoweibin-nginx_tcp_proxy_module-a40c99a/tcp.patch
#./configure --prefix=/usr/local/nginx --with-pcre=../pcre-8.30 --add-module=../yaoweibin-nginx_tcp_proxy_module-ae321fd/
# make
# make install

2. 設定ファイルを変更します
nginx を変更します.conf 設定ファイル

# cd /usr/local/nginx/conf
# vim nginx.conf

worker_processes 1;
events {
worker_connections 1024;
}

tcp {
upstream mssql {
server 10.0.1.201:1433;
server 10.0.1.202:1433;
check interval=3000 rise=2 fall=5 timeout=1000;
}
server {
listen 1433;
server_name 10.0.1.212;
proxy_pass mssql;
}
}

3. nginx

# cd /usr/local/nginx/sbin/
# ./nginx

View 1433 ポートを開始します:

#lsof :1433

4. テスト

#

# telnet 10.0.1.201 1433

5. SQL サーバー クライアント ツールを使用してテスト

6. TCP ロード バランシングの実行原理
nginx は、リスニング ポートから新しいクライアント リンクを受信すると、すぐにルーティング スケジューリング アルゴリズムを実行し、接続する必要がある指定されたサービス IP を取得して、指定されたサーバーへの新しいアップストリーム接続を作成します。

tcp ロード バランシングは、ラウンド ロビン (デフォルト、ポーリング スケジューリング)、ハッシュ (一貫性のある選択) などを含む、nginx の独自のスケジューリング アルゴリズムをサポートします。同時に、スケジューリング情報データも堅牢性検出モジュールと連携して、接続ごとに適切なターゲット上流サーバーを選択します。ハッシュ ロード バランシング スケジューリング方法を使用する場合、$remote_addr (クライアント IP) を使用して単純な永続セッションを実現できます (同じクライアント IP による接続は常に同じサービス サーバー上にあります)。

他のアップストリーム モジュールと同様に、tcp ストリーム モジュールは、カスタムのロード バランシング転送重み (構成 "weight=2") に加えて、障害が発生したアップストリーム サーバーを追い出すためのバックアップおよびダウン パラメーターもサポートします。 max_conns パラメーターを使用すると、サーバーの TCP 接続の数を制限し、サーバーの容量に応じて適切な構成値を設定でき、特に同時実行性の高いシナリオで過負荷保護の目的を達成できます。

nginx はクライアント接続とアップストリーム接続を監視し、データを受信すると、tcp 接続でのデータ検出を実行せずに、すぐに読み取り、アップストリーム接続にプッシュします。 nginx は、クライアントとアップストリームのデータ書き込み用にメモリ バッファを維持します。クライアントまたはサーバーが大量のデータを送信すると、バッファによってメモリ サイズが適切に増加します。

nginx がいずれかの当事者から接続終了通知を受信した場合、または tcp 接続が proxy_timeout で設定された時間を超えてアイドル状態になった場合、接続は閉じられます。 TCP の長い接続の場合、適切な proxy_timeout 時間を選択すると同時に、早期の切断を防ぐために監視ソケットの so_keepalive パラメータに注意を払う必要があります。

ps: サービスの堅牢性モニタリング

tcp ロード バランシング モジュールは、組み込みの堅牢性検出をサポートしています。上流サーバーが proxy_connect_timeout で設定された時間を超えて tcp 接続を拒否した場合、期限が切れたものとみなされます。この場合、nginx はすぐにアップストリーム グループ内の別の通常のサーバーへの接続を試みます。接続失敗情報はnginxエラーログに記録されます。

サーバーが繰り返し失敗した場合(max_failsまたはfail_timeoutで構成されたパラメータを超えた場合)、nginxはサーバーもキックします。サーバーが起動されてから 60 秒後、nginx はサーバーが通常に戻っているかどうかを確認するために時々再接続を試みます。サーバーが正常に戻ると、nginx はそのサーバーをアップストリーム グループに追加し、接続リクエストの割合を徐々に増やします。

「徐々に増加している」理由は、通常、サービスには「ホット データ」があるためです。つまり、リクエストの 80% 以上が実際に「ホット データ キャッシュ」でブロックされることになります。実際に処理されるのはリクエストのほんの一部だけです。マシンが起動したばかりのときは、実際には「ホット データ キャッシュ」が確立されておらず、この時点で大量のリクエストが爆発的に転送されるため、マシンが耐えられなくなり、再びハングアップする可能性があります。 。 mysql を例にとると、通常、mysql クエリの 95% 以上がメモリ キャッシュに分類され、実際に実行されるクエリはそれほど多くありません。

実際には、単一マシンであってもクラスターであっても、同時要求の多いシナリオでの再起動や切り替えにはこのリスクが伴います。これを解決するには主に 2 つの方法があります:

(1 ) リクエストは、少ない状態から多い状態へと徐々に増加し、ホットスポット データが徐々に蓄積され、最終的には通常のサービス状態に達します。

(2) 「よく使用される」データを事前に準備し、サービスを積極的に「プレヒート」し、プレヒート完了後にサーバーへのアクセスをオープンします。

tcp ロード バランシングの原理は lvs の原理と同じで、より低いレベルで動作し、そのパフォーマンスは元の http ロード バランシングよりもはるかに高くなります。ただし、lvs より優れているわけではなく、lvs はカーネル モジュール内に配置されますが、nginx はユーザー モードで動作し、nginx は比較的重いです。もう一つ、非常に残念なのが、このモジュールが有料機能であることです。

TCP ロード バランシング モジュールは、組み込みの堅牢性検出をサポートしています。上流サーバーが proxy_connect_timeout で設定された時間を超えて TCP 接続を拒否した場合、失敗したものとみなされます。この場合、nginx はすぐにアップストリーム グループ内の別の通常のサーバーへの接続を試みます。接続失敗情報はnginxエラーログに記録されます。

サーバーが繰り返し失敗した場合(max_failsまたはfail_timeoutで設定されたパラメータを超えた場合)、nginxはサーバーもキックします。サーバーが起動されてから 60 秒後、nginx はサーバーが通常に戻っているかどうかを確認するために時々再接続を試みます。サーバーが正常に戻ると、nginx はそのサーバーをアップストリーム グループに追加し、接続リクエストの割合を徐々に増やします。

「徐々に増加している」理由は、通常、サービスには「ホット データ」があるためです。つまり、リクエストの 80% 以上、またはそれ以上が実際に「ホット データ キャッシュ」でブロックされるためです。 、実際に処理されるのはリクエストのほんの一部だけです。マシンが起動したばかりのときは、実際には「ホット データ キャッシュ」が確立されておらず、この時点で大量のリクエストが爆発的に転送されるため、マシンが耐えられなくなり、再びハングアップする可能性があります。 。 mysql を例にとると、通常、mysql クエリの 95% 以上がメモリ キャッシュに分類され、実際に実行されるクエリはそれほど多くありません。

実際には、単一マシンであってもクラスターであっても、同時要求の多いシナリオでの再起動や切り替えにはこのリスクが伴います。これを解決するには主に 2 つの方法があります:

(1 ) リクエストは、少ない状態から多い状態へと徐々に増加し、ホットスポット データが徐々に蓄積され、最終的には通常のサービス状態に達します。
(2) 「よく使用される」データを事前に準備し、サービスを積極的に「プレヒート」し、プレヒート完了後にサーバーへのアクセスをオープンします。

tcp ロード バランシングの原理は lvs の原理と同じで、より低いレベルで動作し、そのパフォーマンスは元の http ロード バランシングよりもはるかに高くなります。ただし、lvs よりも優れているわけではなく、lvs はカーネル モジュール内に配置されますが、nginx はユーザー モードで動作し、nginx は比較的重いです。もう一つ、非常に残念なのが、このモジュールが有料機能であることです。

以上がNginxサーバーでTCPの負荷分散を構成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。