CentOS7に基づいてNginxロードバランシングを構成する

Nginx [Load Balancing]（https://cloud.tencent.com/product/clb?from=10680）は、Nginxのコア機能の1つであり、7番目のレイヤーで動作します。これは、lvsとhaproxyに加えて、市場でより人気のある負荷分散ソフトウェアです。クライアント要求は、複数のコンピューティングリソース（コンピューター、コンピュータークラスター、ネットワークリンク、中央処理装置、ディスクドライブなど）にわたるワークロード分散にオフロードできます。負荷分散は、リソースの使用を最適化し、スループットを最大化し、応答時間を最小化し、単一のリソースの過負荷を回避することを目的としています。単一のコンポーネントではなく、負荷分散を備えた複数のコンポーネントを使用すると、冗長性を通じて信頼性と可用性を向上させることができます。この記事では、参考のためにNginxロードバランシングの構成について簡単に説明します。

1.アップストリームモジュールのロードバランシングの概要##

アップストリームモジュールは、バックエンドアップストリームサーバーのセットを含む新しいコンテキストを定義できます。これらのサーバーには、異なる重み、異なるタイプが与えられ、メンテナンスやその他の理由でダウンとしてマークされることもあります。
上流の構文と例
構文：アップストリーム名{…}
proxy_passおよびfastcgi_passによって参照できるサーバーのセットを宣言します。これらのサーバーは異なるポートを使用でき、UnixSocketも使用できます。サーバーに異なる重みを指定することもできます。
例えば：
upstream backend {
server backend1.example.com weight=5 down backup;
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend2;
}

アップストリームモジュールで一般的に使用されるコマンドは次のとおりです。
ip_hash
要求の配布を完了するためのクライアントIPアドレスに基づいて、同じクライアントからの要求が常に同じアップストリームサーバーに転送されるようにすることができます。
keepalive
アップストリームサーバーに送信するために各ワーカープロセスによってキャッシュされた接続の数。
least_conn
最小接続スケジューリングアルゴリズム。
server
アップストリームサーバーのアドレスを定義し、次のような一連のオプションのパラメーターも含めます。
重量：重量;
max_fails：失敗した接続の最大数。失敗した接続のタイムアウト期間はfail_timeoutで指定されます。
fail_timeout：要求されたターゲットサーバーが応答を送信するのを待機する時間の長さ。
バックアップ：フォールバックの目的で、すべてのサービスに障害が発生するとサーバーが起動します。
ダウン：リクエストを処理しなくなったことを手動でマークします。

アップストリームモジュールの負荷分散ポーリングアルゴリズム

ポーリング（ラウンドロビンのデフォルト）
各リクエストは、異なるバックエンドサーバーに時系列で1つずつ割り当てられます。バックエンドサーバーがダウンしている場合は、自動的に削除できます。
重量
ポーリング確率を指定します。重みはアクセス率に比例し、バックエンドサーバーのパフォーマンスが不均一な場合に使用されます。
IPハッシュ（ip_hash）
各リクエストは、アクセスIPのハッシュ結果に従って割り当てられるため、各訪問者はバックエンドサーバーへの固定アクセスを持ち、セッションの問題を解決できます。
サードパーティ（公正）
要求はバックエンドサーバーの応答時間に従って割り当てられ、短い応答時間が優先されます。
サードパーティ（url_hash）

2つのバックエンドサーバー1の構成##

現在のデモ環境では、すべてのフロントエンドとバックエンドがNginxを使用していることに注意してください。
ホスト名とIPを表示する
# hostname
centos7-web.example.com
# ip addr|grep inet|grep global
inet 172.24.8.128/24 brd 172.24.8.255 scope global eno16777728

Nginxバージョン
# nginx -v
nginx version: nginx/1.9.0

テストファイルを追加する
# mv /etc/nginx/html/index.html /etc/nginx/html/index.html.bk
# echo "This a test home page from 172.24.8.128">/etc/nginx/html/index.html

# ss -nltp|grep nginx
LISTEN 0128*:90*:* users:(("nginx",pid=2399,fd=6),("nginx",pid=2398,fd=6))

# curl http://localhost:90
This a test home page from172.24.8.128

3つのバックエンドサーバー2の構成##

ホスト名とIPを表示する
# hostname
node132
# ip addr|grep inet|grep global
inet 192.168.1.132/24 brd 192.168.1.255 scope global eth0

Nginxバージョン
# nginx -v
nginx version: nginx/1.10.2

テストファイルを追加する
# cp /usr/share/nginx/html/index.html /usr/share/nginx/html/index.html.bk
# echo "This a test home page from 192.168.1.132">/usr/share/nginx/html/index.html

# ss -nltp|grep nginx
LISTEN 0128:::80:::* users:(("nginx",2808,7),("nginx",6992,7))
#
# curl http://localhost
This a test home page from192.168.1.132

4、Nginxロードバランシングの構成と検証##

ホスト名とIPの負荷分散
# hostname
centos7-router
# ip addr|grep inet|grep global
inet 172.24.8.254/24 brd 172.24.8.255 scope global eno16777728
inet 192.168.1.175/24 brd 192.168.1.255 scope global dynamic eno33554960

Nginxバージョン
# nginx -v
nginx version: nginx/1.12.2

負荷分散構成
# vim /etc/nginx/conf.d/slb.conf
upstream www {
 server 172.24.8.128:90 max_fails=3 fail_timeout=30s;
 server 192.168.1.132:80 max_fails=3 fail_timeout=30s;
 keepalive 32;}

server {

 listen 9090;
 server_name localhost;

 location /{
  proxy_set_header Host $host;
  proxy_set_header x-for $remote_addr;
  proxy_set_header x-server $host;
  proxy_set_header x-agent $http_user_agent;
  proxy_pass http://www;}}

負荷分散効果を確認する
# systemctl reload nginx
# curl http://localhost:9090
This a test home page from172.24.8.128
# curl http://localhost:9090
This a test home page from192.168.1.132
# curl http://localhost:9090
This a test home page from172.24.8.128
# curl http://localhost:9090
This a test home page from192.168.1.132

IPハッシュポーリング戦略を構成します。改訂された部分は次のとおりです。
# head -n6 /etc/nginx/conf.d/slb.conf
upstream www {
 ip_hash;
 server 172.24.8.128:90 max_fails=3 fail_timeout=30s;
 server 192.168.1.132:80 max_fails=3 fail_timeout=30s;
 keepalive 32;....}

# systemctl reload nginx
# curl http://localhost:9090
This a test home page from172.24.8.128
# curl http://localhost:9090
This a test home page from172.24.8.128
# curl http://localhost:9090
This a test home page from172.24.8.128

ip_hashポーリングをテストした後も、特定の問題があります。つまり、どのマシンにアクセスしても、常に最初のマシンが要求されます。
以前にテストを行って失敗しました。その後、実稼働環境はTengineに変更されました。バージョン：Tengine / 2..1.2（nginx / 1.6.2）
Tengineでsession_sticky命令を使用して、セッションのスティッキ性を実現します。
このip_hashに関して、一部のネットユーザーは理由を説明しました。クラスA、クラスB、クラスCなどのネットワークアドレスに関係なく、Nginxのip_hashアルゴリズムは、ipアドレスの最初の3つのセグメントをハッシュキーワードとして使用します。
Nginxのip_hash命令[http://blog.csdn.net/fygkchina/article/details/41841915]（http://blog.csdn.net/fygkchina/article/details/41841915）

5、tomcat構成へのNginxプロキシに基づく（デモは省略）##

# more tomcat.conf 
upstream app {
    ip_hash;
    server 192.168.81.146:8080;
    server 192.168.81.147:8080;
    keepalive 32;}

server {
 listen 80;
 server_name localhost;
 location /{
  proxy_pass http://app;

  proxy_set_header Host $http_host;   #Auhtor : Leshami
  proxy_set_header X-Real-IP $remote_addr;  #Blog : http://blog.csdn.net/leshami
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-scheme $scheme;
  proxy_set_header x-agent $http_user_agent;}

server {
 listen      443 ssl;
 server_name  localhost;
 server_name node132.ydq.com;
 ssl_certificate      /etc/nginx/conf.d/node132.ydq.com.crt;
 ssl_certificate_key  /etc/nginx/conf.d/node132.ydq.com.key;

 ssl_session_cache    shared:SSL:1m;
 ssl_session_timeout  5m;

 ssl_ciphers  HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers  on;

 location /{
  proxy_pass http://app;

  proxy_set_header Host $http_host;
  proxy_set_header X-Real-Port $remote_port;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-scheme $scheme;
  proxy_set_header x-agent $http_user_agent;
  add_header backendIP $upstream_addr;
  proxy_set_header Proxy_Port $proxy_port;}}