検索

ホームページ  >  記事  >  運用・保守  >  nginx 負荷分散インスタンス分析

nginx 負荷分散インスタンス分析

WBOY
WBOY転載
2023-05-21 08:01:321108ブラウズ

nginx 負荷分散

ご覧のとおり、私たちの Web サイトは開発の初期段階にあるため、nginx は 1 つのバックエンドのエージェントとしてのみ機能することに注意してください。しかし、当社の Web サイトの評判が高まり、アクセスする人が増えるにつれ、1 台のサーバーでは処理できなくなったため、複数のサーバーを追加しました。これほど多くのサーバーにプロキシを設定するにはどうすればよいですか? ここでは例として 2 台のサーバーを使用します。みんなにデモンストレーションするために。

1.上流負荷分散モジュールの説明

Case:

以下は負荷分散サーバーのリストを設定します。 

upstream test.net{
ip_hash;
server 192.168.10.13:80;
server 192.168.10.14:80 down;
server 192.168.10.15:8009 max_fails=3 fail_timeout=20s;
server 192.168.10.16:8080;
}
server {
 location / {
  proxy_pass http://test.net;
 }
}

upstream は、nginx の http アップストリーム モジュールです。このモジュールは、シンプルなスケジューリング アルゴリズムを使用して、クライアント IP からバックエンド サーバーまでの負荷分散を実現します。上記の設定では、upstream ディレクティブを通じてロード バランサー名 test.net が指定されています。この名前は任意に指定でき、後で必要なときに直接呼び出すことができます。

2. アップストリームでサポートされている負荷分散アルゴリズム

nginx の負荷分散モジュールは現在 4 つのスケジューリング アルゴリズムをサポートしており、以下で個別に紹介します。パーティー、スケジュールアルゴリズム。

  • ポーリング (デフォルト)。各リクエストは時系列に1つずつ異なるバックエンドサーバーに振り分けられ、バックエンドサーバーがダウンした場合には障害が発生したシステムが自動的に排除されるため、ユーザーのアクセスに影響はありません。 Weight はポーリングの重みを指定します。重みの値が大きいほど、高いアクセス確率が割り当てられます。主に、各バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。

  • ip_ハッシュ。各リクエストはアクセスされた IP のハッシュ結果に従って割り当てられるため、同じ IP からの訪問者はバックエンド サーバーにアクセスでき、動的 Web ページのセッション共有の問題を効果的に解決できます。 ＃＃＃＃＃＃＃＃＃＃＃＃公平。これは、上記の 2 つよりもインテリジェントな負荷分散アルゴリズムです。このアルゴリズムは、ページ サイズと読み込み時間に基づいて負荷分散をインテリジェントに実行できます。つまり、バックエンド サーバーの応答時間に基づいてリクエストを割り当て、応答時間の短いリクエストを優先します。 nginx 自体はフェアをサポートしていないため、このスケジューリング アルゴリズムを使用する必要がある場合は、nginx のupstream_fair モジュールをダウンロードする必要があります。

  • url_ハッシュ。この方法では、アクセス URL のハッシュ結果に応じてリクエストが振り分けられるため、各 URL が同じバックエンド サーバーに振り分けられるため、バックエンド キャッシュ サーバーの効率をさらに向上させることができます。 nginx 自体は url_hash をサポートしていないため、このスケジューリング アルゴリズムを使用する必要がある場合は、nginx ハッシュ ソフトウェア パッケージをインストールする必要があります。


  • 3. アップストリームでサポートされるステータス パラメーター

http アップストリーム モジュールでは、バックエンド サーバーの IP アドレスとポートを指定できます。 server ディレクティブを使用すると、負荷分散スケジュールで各バックエンド サーバーのステータスを設定することもできます。一般的に使用される状態は



#down で、現在のサーバーが一時的に負荷分散に参加していないことを示します。

  • #バックアップ、予約されたバックアップ マシン。スタンバイ以外の他のすべてのマシンがダウンしているかビジー状態である場合にのみ、リクエストがスタンバイ マシンに送信されるため、スタンバイ マシンの負荷が最も軽くなります。

  • max_fails、許可されるリクエスト失敗の数。デフォルトは 1 です。この数が最大数を超える場合、proxy_next_upstream モジュールによって定義されたエラーが返されます。

  • 複数回失敗すると (max_fails 回に達すると)、サービスは一定期間一時停止され、fail_timeout がトリガーされます。 max_fails は、fail_timeout と一緒に使用できます。

  • 負荷スケジューリング アルゴリズムが ip_hash の場合、負荷分散スケジューリングにおけるバックエンド サーバーのステータスを重みとバックアップにすることはできないことに注意してください。

    • 4. 実験用トポロジ


5. nginx 負荷分散の構成

[root@nginx ~]# vim /etc/nginx/nginx.conf
upstream webservers {
   server 192.168.18.201 weight=1;
   server 192.168.18.202 weight=1;
 }
 server {
   listen    80;
   server_name localhost;
   #charset koi8-r;
   #access_log logs/host.access.log main;
   location / {
       proxy_pass   http://webservers;
       proxy_set_header x-real-ip $remote_addr;
   }
}

注、アップストリームはサーバーで定義されています。{ } server{ } の外部では、内部で定義することはできません。上流を定義したら、proxy_pass を使用してそれを参照するだけです。 nginx 負荷分散インスタンス分析

#6. 設定ファイルをリロードします

[root@nginx ~]# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
重新载入 nginx：                      [确定]

7. テストします


注: 閲覧コンテンツを常に更新すると、web1 と web2 が交互に表示され、負荷分散効果が得られることがわかります。 nginx 負荷分散インスタンス分析

8. Web アクセス サーバーのログを確認しますnginx 負荷分散インスタンス分析

web1:

[root@web1 ~]# tail /var/log/httpd/access_log
192.168.18.138 - - [04/sep/2013:09:41:58 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:41:58 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:41:59 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:41:59 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:42:00 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:42:00 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:42:00 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:44:21 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:44:22 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:44:22 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"

web2:


最初にそれを変更します。 Web サーバーのログの形式。 

[root@web2 ~]# vim /etc/httpd/conf/httpd.conf
logformat "%{x-real-ip}i %l %u %t \"%r\" %>s %b \"%{referer}i\" \"%{user-agent}i\"" combined
[root@web2 ~]# service httpd restart
停止 httpd：                        [确定]
正在启动 httpd：                      [确定]

その後、複数回アクセスしてログを確認し続けます。 

[root@web2 ~]# tail /var/log/httpd/access_log
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:28 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:29 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"
192.168.18.138 - - [04/sep/2013:09:50:29 +0800] "get / http/1.0" 200 23 "-" "mozilla/5.0 (compatible; msie 10.0; windows nt 6.1; wow64; trident/6.0)"

ご覧のとおり、両方のサーバーのログに 192.168.18.138 のアクセス ログが記録されており、負荷分散構成が成功していることもわかります。

9. 健全性ステータス チェックを実行するように nginx を設定します


max_fails、許可されるリクエストの失敗の数、デフォルトは 1 です。この数が最大数を超える場合、proxy_next_upstream モジュールによって定義されたエラーが返されます。


    許容最大失敗数 (max_fails) に達すると、サービスは一定期間 (fail_timeout) 中断されます。ヘルス ステータス チェックは、max_fails とfail_timeout を使用して実行できます。 
[root@nginx ~]# vim /etc/nginx/nginx.conf
upstream webservers {
    server 192.168.18.201 weight=1 max_fails=2 fail_timeout=2;
    server 192.168.18.202 weight=1 max_fails=2 fail_timeout=2;
  }

10.重新加载一下配置文件

[root@nginx ~]# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
重新载入 nginx：                      [确定]

11.停止服务器并测试

先停止web1，进行测试。
[root@web1 ~]# service httpd stop
停止 httpd：                        [确定]

nginx 負荷分散インスタンス分析

注，大家可以看到，现在只能访问web2，再重新启动web1，再次访问一下。

[root@web1 ~]# service httpd start
正在启动 httpd：                      [确定]

nginx 負荷分散インスタンス分析

nginx 負荷分散インスタンス分析

注，大家可以看到，现在又可以重新访问，说明nginx的健康状态查检配置成功。但大家想一下，如果不幸的是所有服务器都不能提供服务了怎么办，用户打开页面就会出现出错页面，那么会带来用户体验的降低，所以我们能不能像配置lvs是配置sorry_server呢，答案是可以的，但这里不是配置sorry_server而是配置backup。

12.配置backup服务器

[root@nginx ~]# vim /etc/nginx/nginx.conf
server {
        listen 8080;
        server_name localhost;
        root /data/www/errorpage;
        index index.html;
    }
upstream webservers {
    server 192.168.18.201 weight=1 max_fails=2 fail_timeout=2;
    server 192.168.18.202 weight=1 max_fails=2 fail_timeout=2;
    server 127.0.0.1:8080 backup;
  }
[root@nginx ~]# mkdir -pv /data/www/errorpage
[root@nginx errorpage]# cat index.html
<h1>sorry......</h1>

13.重新加载配置文件

[root@nginx errorpage]# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
重新载入 nginx：                      [确定]

14.关闭web服务器并进行测试

[root@web1 ~]# service httpd stop
停止 httpd：                        [确定]
[root@web2 ~]# service httpd stop
停止 httpd：                        [确定]

nginx 負荷分散インスタンス分析

注，大家可以看到，当所有服务器都不能工作时，就会启动备份服务器。好了，backup服务器就配置到这里，下面我们来配置ip_hash负载均衡。

15.配置ip_hash负载均衡

ip_hash，每个请求按访问ip的hash结果分配，这样来自同一个ip的访客固定访问一个后端服务器，有效解决了动态网页存在的session共享问题。（一般电子商务网站用的比较多）

[root@nginx ~]# vim /etc/nginx/nginx.conf
upstream webservers {
    ip_hash;
    server 192.168.18.201 weight=1 max_fails=2 fail_timeout=2;
    server 192.168.18.202 weight=1 max_fails=2 fail_timeout=2;
    #server 127.0.0.1:8080 backup;
  }

注，当负载调度算法为ip_hash时，后端服务器在负载均衡调度中的状态不能有backup。（有人可能会问，为什么呢？大家想啊，如果负载均衡把你分配到backup服务器上，你能访问到页面吗？不能，所以了不能配置backup服务器）

16.重新加载一下服务器

[root@nginx ~]# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
重新载入 nginx：                      [确定]

17.测试一下

nginx 負荷分散インスタンス分析

注，大家可以看到，你不断的刷新页面一直会显示的民web2，说明ip_hash负载均衡配置成功。下面我们来统计一下web2的访问连接数。

18.统计web2的访问连接数

[root@web2 ~]# netstat -an | grep :80 | wc -l
304

注，你不断的刷新，连接数会越来越多。

以上がnginx 負荷分散インスタンス分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明：
この記事はyisu.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。
前の記事：nginx で PHP の $_SERVER 変数をカスタマイズする方法次の記事：nginx で PHP の $_SERVER 変数をカスタマイズする方法

関連記事

続きを見る