nginx の負荷分散戦略と構成

この記事では、主に nginx の負荷分散戦略と構成を紹介します。これは、必要な友人に参考にしていただけるようにしています。

まず、負荷分散とは何かを簡単に理解しましょう。 、文字通りの意味から理解すると、

N

サーバーが均等に負荷を共有しており、特定のサーバーの負荷が高いために特定のサーバーがアイドル状態になることはないと説明できます。したがって、負荷分散の前提は、複数のサーバーで実現できること、つまり 3 台以上のサーバーで十分であるということです。負荷分散は、同時実行性が高くトラフィックの多い Web サイトに実装する必要があるテクノロジーです。 環境

2台のマシンの負荷分散デプロイメントを使用

テストドメイン名

: a.com A

サーバー

IP: 10.1 .108.31 A サーバーはメイン サーバーとして使用され、ドメイン名は に直接解決されます。A サーバー (10.1.108.31 ) では、

A サーバーは負荷分散されます。それ自体 (10.1.108.31 ) と

B サーバー ( 192.168.112.128

) が優れています。 負荷分散が必要なプロジェクトnodejs webプロジェクト、プロジェクト名social、ポート6602。 でA

サーバーと

Bサーバーでそれぞれ

social

プロジェクトを起動します(nodejsプロジェクトの起動方法はここでは紹介しません)。 A サーバー nginxをインストールします（インストール方法はここでは紹介しません、

Bサーバーはインストールする必要がありません）。 展開ドメイン名解決実際の環境ではないので、テスト用にドメイン名a.comを使用するだけなので、a.comの解決はhostsファイル設定でのみ実行できます。

開く: C:WindowsSystem32driversetchosts

最後に

10.1.108.31 a.comを追加します

保存して終了し、コマンドモードを開始しますpingで設定が成功したかどうかを確認します

スクリーンショットから、a.comがに正常に解決されたことがわかります。 10.1.108.31

nginx.conf

を構成する nginxインストールディレクトリのconfディレクトリで、 nginx.confファイル

httpセクション結合 次のコード

upstream a.com {

            server 127.0.0.1:6602;

            server 192.168.112.128:6602;

        }

server {

        listen       80;

e

        location / {

注:

2 ノードのうちの 1 つがダウンしています、 nginxは引き続きリクエストをItに配布します タイムアウトになるまで応答がなく、その後別のノードに送信されます。デフォルトでは、1 分以内にそれ以上のリクエストは送信されず、1 分後に上記のアクションが繰り返されます。その結果、Web サイトが速くなったり遅くなったりすることがあります。遅すぎないように、proxy_connect_timeout を 2 秒に設定します。

設定を保存し、nginxを起動し、a.comにアクセスします

写真2

上の写真に示すように、

a.comにそれぞれ2回アクセスしたデータAサーバーとBサーバーで返されます。 nginx負荷分散構成が成功したことを示します。 nginx 設定の詳細

rreee

            proxy_pass http://a.com;      #设置反向代理的地址

            proxy_connect_timeout 2;      #代理服务器超时时间，秒

        }

user    www-data;                        #运行用户worker_processes  4;                   #启动进程,通常设置成和cpu的核数相等

worker_cpu_affinity 0001 0010 0100 1000;   #为每个进程绑定cpu内核，参考下面注解1

error_log  /var/log/nginx/error.log;   #全局错误日志pid        /var/run/nginx.pid;          #PID文件

#events模块中包含nginx中所有处理连接的设置

events {                            
   use   epoll;  #连接处理方式，参考注解2

  worker_connections  1024;    #单个后台worker process进程的最大并发链接数，不能超过最大文件打开数，最大文件打开数可以通过worker_rlimit_nofile修改。  multi_accept on;   #on:worker process一次接受所有新连接, off: 一次接受一个新的连接

}

#设定http服务器，利用它的反向代理功能提供负载均衡支持

http {
     
    include       /etc/nginx/mime.types;       #设定mime类型,类型由mime.type文件定义

   include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

    default_type  application/octet-stream;  #默认文件类型

   #charset utf-8; #默认编码

rええ、

nginx 設定注釈

1.worker_cpu_affinity

注釈Nginx

使用率はデフォルトでは有効になっていません CPU、

増加worker_cpu_affinity マルチコアCPUを最大限に活用するようにパラメータを構成します。 CPU はタスクの処理と計算に最も重要なリソースです。CPU コアが多いほど、パフォーマンスが向上します。 Nginx マルチコア CPU、worker_cpu_affinity の使用方法と例を構成する
2

core

CPU、start 2processesworker_processes 2;worker_cアフィニティ 01 10;

01は最初のCPUコアを有効にすることを意味し、10は2番目のCPUコアを有効にすることを意味します
worker_cpu_affinity 01 10; 2つのプロセスを開始することを意味し、最初のプロセスは最初のCPUコアに対応し、2番目のプロセスは2番目のCPUに対応します芯。

2Core CPU、4つのプロセスを開くworker_processes 4;
worker_cpu_affinity 01 10 01 10;

4つのプロセスを開く、それぞれ2つのCPUを開くことに対応しますコア

4コア CPU、アカウント 4 プロセスworker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

000 1 は、最初の CPU コアを有効にすることを意味します0010 は最初の 2 つの CPU コアを有効にすることを意味します。など

4core CPU、2つのプロセスを開きますworker_processes 2;
worker_cpu_affinity 0101 1010;

0101 は、 1番目と3番目の3つのコア、1010は開くことを意味します2番目と4番目のコア2つのプロセスは4つのコアに対応します
worker_cpu_affinityの設定は/etc/nginx/nginx.confに書かれています。
2 コアは 01、4 コアは 0001、8 コアは 00000001 です。コアの数に応じていくつかの桁があり、1 はコアがオンであることを意味し、0 はコアがオフであることを意味します。

8コア CPU、8 つのプロセスのアカウントworker_processes 8;worker_cpu_affinity 00000001 00000010 00000100 00001000 0001000 00 10000001000000 10000000;

0001

は最初のCPUコアを有効にすることを意味し、0010はそれを意味します2 番目の CPU コアを有効にするなど、worker_processes は最大 8 つまで開くことができます。8 つを超えるとパフォーマンスの向上は改善されず、安定性が低下するため、8 つのプロセスで十分です。

2.接続処理メソッド

nginx

は複数の接続処理メソッドをサポートしており、どのメソッドを使用するかは使用されるシステムによって異なります。システムが複数の方法をサポートしている場合、nginx は最も効率的な方法を自動的に選択します。必要に応じて、使用するメソッドを use ディレクティブで指定できます。

select:

1.Socket

数量制限:このモードが動作できるSocketの数はFD_SETSIZEによって決定されます 、カーネルデフォルト 30 ソケット
はい アクティブ、はすべて通過します。

投票:

1.ソケットその数はほぼ無制限です:のfdに対応するソケットこのモード リストは次の方法で保存されます配列、サイズ制限なし(デフォルト4k)
2.操作制限:

と同じ。

エポール:

Linux 2.6

上記のバージョン

1.

ソケット数量無制限:ポーリングと同じ2.
操作無制限: によって提供される反射モードに基づいています。 kernel , がアクティブな Socket の場合、カーネルは Socket の コールバックにアクセスし、 はポーリングをトラバースする必要はありません.

: は

epoll

とあまり変わりません。原理は同じで、次のオペレーティング システムで使用されます: FreeBSD 4.1+、OpenBSD 2.9+、NetBSD 2.0、およびMacOS X

モードが非効率的である理由モードの非効率性は、セレクトの定義によって決定され、オペレーティングシステムの実装とは関係ありません これらの
ソケットのステータスを知るにはラウンドロビンを実行する必要があり、 CPUを消費します。さらに、ソケットの大規模なコレクションがある場合、たとえ一度にソケットのほんの一部だけが「アクティブ」であっても、すべてのソケットを1つのFD_SETに埋めないでください。これにより、一部のcpuも消費されます。また、selectが返されるとき、ビジネスを処理するときにを実行する必要がある場合もあります" コンテキストマッピング"もパフォーマンスに多少の影響を与えるため、 selectはepollよりも比較的非効率的です。 epollは、socketsの数が多いが、アクティビティがそれほど高くない場合に適用できます。
3. tcp_nolayとtcp_nopush

tcp_nolayNginx

の違い新しい

ソケット を開くときに TCP_NODELAY

オプションが追加されますTCP_NODELAY オプション。 しかし、これは状況を引き起こします: 端末アプリケーションは操作が発生するたびにパケットを送信し、通常、パケットには 1 バイトのデータと 40 バイト長のパケットヘッダーが含まれます。その結果、

4000%

の過負荷が発生し、ネットワークの輻輳が容易に発生する可能性があります。

これを回避するために、TCPスタックは 0.2秒間のデータ待機を実装しているため、操作後はパケットは送信されませんが、この期間内のデータは大きなバッグになります。

このメカニズムは、Nagleアルゴリズムによって保証されています。

Nagle化は後に標準となり、すぐにインターネットに実装されました。現在はデフォルト設定になっていますが、状況によってはこのオプションをオフにすることが望ましい場合があります。

次に、アプリケーションがリクエストを行い、小さなデータの塊を送信したいと考えていると想像してください。データをすぐに送信するか、さらにデータが生成されるのを待ってから再度送信するかを選択できます。

インタラクティブなアプリケーションだけでなく、クライアント /サーバーベースのアプリケーションも、データをすぐに送信できれば大きなメリットがあります。リクエストがすぐに行われると、応答時間が短縮されます。

上記の操作は、ソケットの TCP_NODELAY = on オプションを設定して、Nagle アルゴリズムを無効にすることで完了できます。

別の状況では、データ量が最大に達するまで待ってから、すべてのデータをネットワーク経由で一度に送信する必要があります。このデータ送信方法は、大量のデータの通信パフォーマンスに有利です。ファイルサーバーです。

Nginx は、 キープアライブ との接続で TCP_NODELAY を使用します。 キープアライブ データ送信後も接続は維持され、さらに多くのデータを送信することもできます。

これにより、より少ない数のソックスされた接続と、各接続の 3 ウェイ ハンドシェイク プロセスをインスタンス化できます。

tcp_nopush

nginx 、tcp_nopush 設定および tcp_nolay 叱責。一度に送信するデータのパケットサイズを設定できます。

つまり、累積時間に基づいて 0.2 秒を超えるとパケットは送信されませんが、パケットが一定のサイズに蓄積されると送信されます。

nginx では、tcp_nopush は sendfile と一緒に使用する必要があります。

4.ロードバランス

nginx

は、次の負荷分散メカニズムをサポートしています：

1

）round-robin：ポーリング。ポーリング方式でリクエストをさまざまなサーバーに分散します。デフォルトはポーリングです。

2）least-connected：最少连接数。将下一个请求分配到连接数最少的那台服务器上。

3）ip-hash ：基于客户端的IP地址。散列函数被用于确定下一个请求分配到哪台服务器上。

在一些要求需要更长的时间才能完成的应用情况下，最少连接可以更公平地控制应用程序实例的负载。使用最少连接负载均衡，nginx不会向负载繁忙的服务器上分发请求，而是将请求分发到负载低的服务器上。配置如下：

upstream mysvr {

   least-connected
  server 192.168.8.1:3128
  server 192.168.8.2:80
  server 192.168.8.3:80
}

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