nginxロードバランシングを構成する方法

ポーリング

nginx は、すべてのリクエストをクラスター内の各サーバーに均等に分散します。

upstream test {
server 127.0.0.1:7001; # 等同于server 127.0.0.1:7001 weight=1;server 150.109.118.85:7001; # 等同于server 150.109.118.85:7001 weight=1;}

server {
listen 8081;
server_name localhost;

location / {
 proxy_pass http://test/;
}
}

upstream: サービス クラスターを定義します。 proxy_pass: 一致するリクエスト プロキシを proxy_pass の背後に設定されたサービスに転送します。ロード バランシングをここで設定する必要があるため、http:// の後にアップストリームで定義されたサービス クラスターを続ける必要があります。

注: アップストリームがサービス クラスターを定義する場合、構成されたサービス アドレスはドメイン名ポートまたは IP ポートのみにすることができ、プロトコルとパスを含めることはできません。それ以外の場合は、nginx が を報告します。 nginx: [ emerg] アップストリームのホストが無効ですこのエラー メッセージ。

Weighted

upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}

最初の 2 つのリクエストは 127.0.0.1:7001 に転送され、次のリクエストは 150.109.118.85 :7001 に転送されます。 このサービスは 127.0.0.1:7001 に 2 回転送されます。 。 。

最小接続数

ファイルの場所: src/http/modules/ngx_http_upstream_least_conn_module.c

nginx リクエストは、最小の active_connection/weight を持つサーバーに割り当てられます。

upstream test {
  least_conn;
server 127.0.0.1:7001 weight=1;
server 150.109.118.85:7001 weight=1;
}

ip_hash

ファイルの場所: src/http/modules/ngx_http_upstream_ip_hash_module.c

ユーザーの IP に従って、ハッシュ値を計算します。ロード バランシング キャッシュ内にこのハッシュに対応するサーバーがある場合、対応するサーバーに直接転送されます。

upstream test {
  ip_hash;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

nginx が ip_hash ポリシーを使用した後は、ユーザーのコンピューターの IP が変更されない限り、常に同じビジネス サービスを要求します。

アプリケーション シナリオ: ファイル アップロード機能を実装する場合、大きなファイルをアップロードする場合、大きなファイルを複数のフラグメントに分割してサーバーにアップロードすることがよくありますが、上記の戦略を使用すると、同じ問題が発生します。ファイルの断片が別のサーバーにアップロードされたため、ファイルの結合が失敗し、期待した結果が得られませんでした。 nginx が ip_hash ポリシーを使用した後、クライアントは現在のファイルのフラグメントをアップロードするだけで済み、後続のファイル フラグメントがアップロードされると、nginx は IP のハッシュを計算して、ハッシュに対応するサーバーにリクエストを自動的に転送します。

hash

ファイルの場所: src/http/modules/ngx_http_upstream_hash_module.c

ハッシュ計算に使用できるremote_addr (クライアントIP) (テストでは問題ないようです)結果) ip_hash)、request_uri (リクエスト URI)、および args (リクエスト パラメーター) を直接置き換えます。以下では主に request_uri の使用法をデモンストレーションとして使用します。他の 2 つの使用法は同様です。

リクエストされた URI に基づいてハッシュ値を計算し、リクエストをサーバーに転送します。後続のリクエストがハッシュによって計算された後、同じハッシュが存在する場合、リクエストはそのハッシュに転送されます。対応するサーバー。

クラスター内のサーバーがダウンした後に何が起こるかを想定します。r1 がサーバー a にヒットした場合、r2 はどのサーバーにヒットしますか? 。サーバaがダウンすると、r1で計算したハッシュ値とサーバaの対応関係が失われ、r1はサーバbに再配布されます。サーバー a が正常に戻った後も、r1 はサーバー b に割り当てられます。

upstream test {
  hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

アプリケーション シナリオ: 同じファイル リソースに対するすべてのリクエストが同じサーバーに転送されるため、リソースがキャッシュにヒットしやすくなり、帯域幅とリソースのダウンロード時間が削減されます。

consistent_hash

consistent_hash (一貫性のあるハッシュ) このモジュールは、nginx の組み込みハッシュ モジュールとほぼ同じ方法で使用されます。 consistent_hashで計算できる内容は、remote_addr、request_uri、argsなど、先ほどのnginxの組み込みハッシュモジュールと同じです。ここから ngx_http_consistent_hash をダウンロードできます。これはサードパーティ モジュール用のソフトウェアです。

upstream test {
consistent_hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

fair

応答時間が短いサービス リクエストが最初に割り当てられます。このサードパーティ モジュールは、nginx_upstream_fair のダウンロード ページから入手できます。このモジュールは 8 年前に最後に更新されました。これを使用する必要があるかどうかを検討してください。

upstream test {
fair;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

テスト結果は、デフォルトのポーリング状況と同じ効果があり、問題はまだ見つかっていないことを示しています。 。 。

負荷分散関連パラメータ

down

down で識別されるサーバーは、リソース要求を一時的にサポートしていません。

upstream test {
server 127.0.0.1:7001 down;
server 150.109.118.85:7001;
}

上記の負荷分散の例では、127.0.0.1:7001 が down として識別されるため、このサービスにはリクエストは転送されず、すべてのリクエストが転送されます。サービス 150.109.118.85:7001 に転送します。

weight

クラスター内のサービスの重み値。デフォルトは 1 です。重みのみが影響を受け、クラスター内のすべてのサービスが正常であるという条件下では、nginx はより多くのリクエストをより大きな重みを持つサービスに転送します。

upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}

このクラスター内のサービス 127 とサービス 150 によって処理されるリクエストの比率は 2:1 です。

max_fails

サービスがリクエストを処理するときに許可されるサービス エラーの数。デフォルトは 1 です。サービス処理リクエストのエラー数が max_fails を超えると、以降のリクエストはエラーが発生したサービスに転送されません。

upstream test {
server 127.0.0.1:7001 max_fail=1;
server 150.109.118.85:7001;
}

fail_timeout

如果某个服务处理请求时发生错误的次数超过 max_fails，nginx 将暂时禁止将请求转发到该服务。当过去fail_timeout设置的时间以后，nginx会尝试将请求转发到刚才被禁止的服务，如果服务正常，那么后续的请求可以继续转发到这台服务，如果服务错误，那么继续等待fail_timeout时间后再来检测。fail_timeout默认时间是10s。

upstream test {
server 127.0.0.1:7001 max_fail=1 fail_timeout=10s;
server 150.109.118.85:7001;
}

backup

备用服务器，当所有非backup服务发生错误被停用或者设置为down时，nginx会启用标识为backup的服务。

upstream test {
server 127.0.0.1:7001 backup;
server 150.109.118.85:7001;
}

max_conns

这个功能存在于nginx商业版。同一服务同时处理请求的个数。防止服务因处理请求过多，服务器性能不足，发生宕机的情况。

upstream test {
server 127.0.0.1:7001 max_conns=10000;
server 150.109.118.85:7001;
}

slow_start

这个功能存在于nginx商业版。当集群中错误服务等待fail_timeout时间后，nginx检测到这个服务能够正常使用后，再等待slow_start时间后，才正式使用这个服务。

upstream test {
server 127.0.0.1:7001 slow_start=30s;
server 150.109.118.85:7001;
}

以上がnginxロードバランシングを構成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。