Nginx ストリーム構成プロキシ (Nginx TCP/UDP ロードバランシング)

序章

nginx が優れたリバースプロキシサービスであることは誰もが知っています。nginx を使用したことがある人は、upstream についても知っているはずです。upstream ノードは、通常、http ノードブラケット内に配置されます。負荷分散が必要なサーバーのリストは、通常、upstream で構成されます。

より一般的な用途は次のとおりです。

#user 誰も誰も。
#ワーカープロセス 2;
nginx の pid を変更します。
error_log ログ/error.log デバッグ;
イベント {
    …
}
http {
    …
    アップストリームテストサーバー{   
      サーバー 192.168.1.5:8080;
      サーバー 192.168.1.6:8080;
      …
    }

    サーバー{
        …
        位置 / {
           …     
           proxy_pass http://テストサーバー;
        } 
    }
}

構造からわかるように、この構成は主に http リバースプロキシを処理するためによく使用されます。

しかし、バックエンドサービスの TCP をプロキシしたい場合、nginx はそれをサポートしますか?たとえば、mysql、redis などの場合、答えは「はい」です。実際、nginx は TCP/UDP の負荷分散もサポートしています。次にお話ししたいのは、nginx のストリームモジュールです。ストリームを構成することで、このような要件を満たすことができます。ここでは、主に http リバースプロキシに nginx を使用することをお勧めします。

メイン記事

Nginx の TCP/UDP 負荷分散は、ストリームプロキシモジュール (ngx_stream_proxy_module) とストリームアップストリームモジュール (ngx_stream_upstream_module) を適用することによって実装されます。 Nginx の TCP 負荷分散と LVS はどちらも 4 層の負荷分散アプリケーションです。違いは、LVS が Linux カーネルに配置され、Nginx がユーザーレベルで実行されることです。Nginx ベースの TCP 負荷分散では、より柔軟なユーザーアクセスの管理と制御を実現できます。

基本的な概念を理解したので、具体的な構成例を見てみましょう。

ワーカープロセス 4;
ワーカー_rlimit_nofile 40000;

イベント {
    ワーカー接続数 8192;
}

ストリーム {
    アップストリーム my_servers {
        最小接続数;
        # 5秒以内に3つのエラーが発生した場合、サーバーは5秒間切断されます
        サーバー <IP_SERVER_1>:3306 max_fails=3 fail_timeout=5s;
        サーバー <IP_SERVER_2>:3306 max_fails=3 fail_timeout=5s;
        サーバー <IP_SERVER_3>:3306 max_fails=3 fail_timeout=5s;
    }
    サーバー{
        聞く 3306;
        proxy_connect_timeout 5s; # プロキシサーバーとの接続を確立するためのタイムアウトは5秒です
        proxy_timeout 10s; # プロキシサーバーからの応答を取得するための最大タイムアウトは10秒です
        proxy_next_upstream on; # プロキシされたサーバーがエラーを返すかタイムアウトすると、応答を返さなかったクライアント接続要求は上流の次のサーバーに渡されます proxy_next_upstream_tries 3; # 試行要求を最大 3 回転送します proxy_next_upstream_timeout 10s; # 合計試行タイムアウトは 10 秒です
        proxy_socket_keepalive on; # ハートビート検出の SO_KEEPALIVE オプションを有効にします proxy_pass my_servers;
    }
}

詳しい説明

Nginx の TCP/UDP 負荷分散は、接続を割り当てるときにパッシブヘルス検出モードもサポートします。バックエンドサーバーへの接続が失敗し、連続した失敗回数が fail_timeout パラメーター内の max_fails パラメーターを超えると、Nginx はサーバーを使用不可状態にし、fail_timeout パラメーター内でサーバーへの接続を割り当てません。 fail_timeout パラメータの有効期限が切れると、サーバーが回復したかどうかを検出するために接続を割り当てようとします。接続を確立できる場合は、回復したとみなされます。
パラメーター max_fails は、Nginx によって現在のサーバーに 10 秒以内に割り当てられた接続失敗の数の累積値を参照し、10 秒ごとに 0 にリセットされます。
パラメータ fail_timeout は、失敗回数の最大時間と、サーバーが失敗状態に設定されるヒューズ時間の両方です。この時間を超えると、接続が再度割り当てられます。
proxy_connect_timeout または proxy_timeout パラメータがタイムアウト状態の場合、proxy_next_upstream メカニズムがトリガーされます。
proxy_next_upstream パラメータは、Nginx での接続成功率を向上させるためのメカニズムです。プロキシサーバーがエラーを返すかタイムアウトすると、次に利用可能なプロキシサーバーに転送しようとします。
パラメータ proxy_next_upstream_tries が設定される回数には、最初のリクエストが転送される回数が含まれます。
TCP 接続は、接続終了通知を受信するまで接続されたままになります。Nginx とプロキシサーバー間の 2 つの連続した正常な読み取りまたは書き込み操作間の最大間隔が proxy_timeout ディレクティブで設定された時間を超えると、接続は閉じられます。 TCP 長時間接続のシナリオでは、proxy_timeout 設定を適切に調整し、早期切断を防ぐためにシステムカーネルの SO_KEEPALIVE オプションの構成に注意する必要があります。

注意: Steam モジュールの設定が無効な場合は、使用しているバージョンがストリームをサポートしているかどうかを確認してください。モジュールが組み込まれていない場合は、コンパイル時に --with-stream パラメータを指定して、ストリームプロキシをサポートするようにコンパイルする必要があります。

Nginx ストリーム構成プロキシ (Nginx TCP/UDP ロードバランシング) に関するこの記事はこれで終わりです。Nginx ストリーム構成プロキシに関するより関連性の高いコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: