Nginx が ngx_http_upstream_module を使用して負荷分散機能を実装する方法

負荷分散の概要

負荷分散とは

負荷分散 (ロード バランス) とは、負荷 (作業タスク、アクセス リクエスト) を意味します。 ) は、実行のために複数のオペレーティング ユニット (サーバー、コンポーネント) に分散され、バランスがとれています。

負荷分散が必要な理由

単一の Web サーバーがユーザーに直接対応する場合、多数の同時リクエストを処理する可能性があります。単一のサーバーでは負荷がかかる可能性があります。複数のサーバーを使用する必要があります。クラスターは、Nginx 負荷分散機能を使用してリクエストをさまざまなバックエンド サーバーに分散し、負荷トラフィックの分散を実現し、全体的なパフォーマンスとシステムの災害復旧機能を向上させます。

• ロード バランシングとプロキシの違いは何ですか

プロキシは、URI に基づいてスケジュールされ、ディスパッチされるサーバーのプロキシです。さまざまな機能を持つアプリケーション ノード

ロード バランシングは、proxy_pass を介して一連の上流リソース プールにクライアント リクエストをプロキシすることです

• #ロード バランシング シナリオを実現するには

負荷を実現するには、バランシング機能には 2 つのモジュールを使用する必要があります:

• proxy_pass: プロキシ モジュール

• upstream: virtualリソース プール

例: 公式の負荷分散表示

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

例: 小さな例を自分で完成させてください

upstream node {
    server 192.168.10.3:80;
    server 192.168.10.4:80;
}
server {
    listen 80;
    server_name www.yyang.com;
    location / {
        proxy_pass http://node;
        include prxoy_params;
    }
}

負荷分散スケジュール アルゴリズム

ポーリング スケジューリング

##異なるバックエンド ノードに 1 つずつ順番に割り当てられます。これはデフォルトのアルゴリズムでもあります。 (簡単に言うと、1:1:1 です)

重み付きポーリング サーバーごとに異なるパフォーマンスを考慮して、ノードが受信できるように異なる重みをノードに与えます。対応する重み付けされたリクエストの数

server 192.168.10.3:80 weight=3;
server 192.168.10.4:80 weight=1;

上記の例は、4 つのリクエストごとに、10.3 の場合は 3 つのリクエスト、10.4 の場合は 1 つのリクエストに割り当てられることを意味します。

ip_hash

ユーザーがリクエストした IP に従って、IP 上でハッシュ操作を実行し、リクエストをバックエンドの特定のノードに割り当てて、ベースの処理を実行します。計算された値について。

値の範囲は、ipv4 アドレスの最初の 3 つの 8 ビット、またはハッシュ キーとしての ipv6 のアドレス全体であり、セカンダリ サーバーが指定されていない限り、1 つのクライアントからの IP が常に同じサーバーに渡されることが保証されます。利用できません。簡単に言うと、172.16.20.1と172.16.20.2の最初の3組の番号は同じです（すべて172.16.20）

ip_hash演算式：hash (ip) %node_counts=index

ip_hash によって引き起こされる問題:

同じ IP に対する大量のリクエストにより、ノード上で過剰なトラフィックが発生します
ノードが一時的にオフラインになった場合、ハッシュ値が再計算されます。 state

例: ip_hash とweight は同時に使用できないことに注意してください

ip_hash;
server 192.168.10.3:80;
server 192.168.10.4:80;

Consistency hash

上記の問題を回避するには、モジュロ方式で一貫性のあるハッシュが生まれましたが、正しくありません サーバノード数はモジュロですが、モジュロの2の32乗です ハッシュ関数の値は0~2^32-1となります。 (仮想リングを形成すると、ユーザーのリクエストは時計回りに隣接するノードに送信されます)

問題があります: バックエンド ノードが少ない場合、データ スキューが発生する可能性があるため、コンシステント ハッシュは仮想ノード メカニズムを導入します。 , for 各サーバーは複数のハッシュを計算し、各計算結果の場所に仮想ノードを配置します。
ip_hashを使いたいけど、計算式がコンシステントハッシュを使っている場合はどうすればいいでしょうか？

hash $remote_addr consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

url_hash

ユーザーの URL に基づいてハッシュモジュロを実行し、操作値に基づいてリクエストを特定のバックエンド サーバーに割り当てます。

1. ユーザーは nginx ロード バランシングをリクエストし、そのリクエストは URL アルゴリズムを通じてキャッシュ 1 にスケジュールされます。

2. キャッシュ 1 にデータがない場合は、バックエンドからデータを取得し、データを返します。他のユーザーが同じ URL にアクセスすると、スケジューラは引き続きキャッシュ 1 ノード
4 にスケジュールします。キャッシュ 1 はデータを

hash $request_uri consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

least_conn に直接返します。

どのサーバー接続数が最も少ない場合、リクエストはこのサーバーにディスパッチされます

least_conn;
server 192.168.10.3:80;
server 192.168.10.4:80;

負荷分散バックエンド ノードのステータス

down

サーバー ノードを利用不可ステータスとしてマークします。これは通常、シャットダウン メンテナンスに使用されます。

server 192.168.10.3:80 down;
server 192.168.10.4:80;

backup

スタンバイ ノード。このノードは通常の状況ではスケジュールされません。通常の動作ノードがすべて利用できない場合、このノードは有効になります。ノードが回復すると、このノードはスタンバイ状態に戻り続けます。

server 192.168.10.3:80;
server 192.168.10.4:80;
server 192.168.10.5:80 backup;

max_conns

は、各バックエンド ノードが受信する TCP 接続の最大数を制限するために使用されます。制限を超えると、エラーがスローされます。

server 192.168.10.3:80 max_conns=10;
server 192.168.10.4:80 max_conns=10;

1台で10接続可能。2台で20台接続可能。20を超えるとエラーとなります。

keepalived

バックエンド サーバーでのキャッシュ (長いリンク) をアクティブにして、Web サイトのスループットを向上させます。

この機能はデフォルトでは有効になっていません。リクエストがあると、接続が確立され、維持され、閉じられるため、ネットワークが消費されます。ただし、すべての接続がキャッシュされると、接続時に他のシステム リソースが占有されます。接続はアイドル状態であるため、keepalived パラメーターを使用できます。

server 192.168.10.3:80;
server 192.168.10.4:80;

keepalived 32;   # 最大空闲连接数的个数
keepalived_timeout 100s; # 空闲连接的超时时间

# 需要配合以下两个参数使用

proxy_http_version 1.1;
proxy_set_header connection "";

max_fails とfail_timeout

max_fails=2：服务器通信失败两次，认为服务器不可用
fail_timeout=5s：服务器通信失败后，每5秒探测一次服务器是否恢复正常。
在fail_timeout设定时间内，与服务器连接失败次数达到max_fails数量，则认为服务器不可用。
如果不设置的话默认是探测一次，间隔10s。

server 192.168.10.3:80 max_fails=2 fail_timeout=5s;
server 192.168.10.4:80 max_fails=2 fail_timeout=5s;

以上がNginx が ngx_http_upstream_module を使用して負荷分散機能を実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。