Nginx がロード バランシングを実装する方法

1. Nginx の概要

Nginx は、高性能の Http およびリバース プロキシ サーバーであり、IMAP/POP3 でもあります。 /SMTP サーバー (電子メール プロキシ)。この製品の開発当初の目的の 1 つは、メール プロキシ サーバーとしても機能します。安定性、豊富な機能セット、サンプル構成ファイル、システム リソースの消費量の少なさ、同時実行パフォーマンスの高さにより、さまざまな運用環境で広く使用されています。さらに、nginx はイベント駆動型モデル (epoll) に基づいて I/O 多重化を実装し、リクエストを非同期かつノンブロッキングで処理します。接続の同時実行性が高い場合、Nginx は Apache サーバーの良い代替手段となります。そして、なぜ Nginx を選択する必要があるのでしょうか?

2. Nginx の機能

• 高い同時実行性と高いパフォーマンス;

• 高い信頼性 (7*24 時間中断なし可能) Run);

• 強力なスケーラビリティ (高度なモジュール設計、モジュールのスムーズな追加);

• Web サーバーとして: Apache と比較して、Nginx はリソースが減り、より多くの同時接続がサポートされます。

• は負荷分散サーバーとして機能します。仮想ホスト、URL リダイレクト、ネットワーク監視などをサポートするようにカスタマイズおよび構成できます。

• Nginx のインストールは非常に簡単で、設定ファイルは非常に簡潔で (Perl 構文もサポートできます)、バグはほとんどありません。 #静的ファイルとインデックスの処理 ファイルと自動インデックス作成;

• リバース プロキシ アクセラレーション (キャッシュなし)、シンプルなロード バランシングとフォールト トレランス;

• ホット デプロイメントをサポートします (サーバーを停止せずに nginx をアップグレードできます)。

• これが、Nginx を選択すべき理由です。また、Nginx の機能や特徴はこれらに限定されるものではなく、上記は一般的な機能の一部を簡単にリストしたものです。

3. Nginx 負荷分散

実際の運用環境では、サーバーの処理能力とストレージ容量は限られているため、より強力なサーバーに変更しようとしないでください。 -scale Web サイトに関する限り、サーバーがどれほど強力であっても、Web サイトの継続的な成長に対応することはできません。この場合、より適切なアプローチは、サーバーを追加して、元のサーバーのアクセスとストレージの負荷を共有することです。実際、これは

負荷分散

と呼ばれるもので、負荷分散サーバーとして、Nginx はリバース プロキシを使用して複数のバックエンド サーバーの負荷を分散します。まず、Nginx の負荷分散戦略と負荷分散アルゴリズムについて説明します。

3.1 アップストリーム モジュールの理解upstream このモジュールは、プロキシ サーバー アドレスのセットを書き込み (つまり、ユーザー リクエストを受け入れるために、定義されたバックエンド サーバー リストからサーバーを選択します)、負荷分散アルゴリズムを構成します。最も基本的な負荷分散の例を見てみましょう:

upstream test { 
      server 10.20.151.114:80;
      server 10.20.151.115:80;
}
server {
      ....
      location / {         
             proxy_pass  http://test;     --请求转向 test 定义的服务器列表         
      }

3.2 Nginx 負荷分散戦略

(1) ポーリング

最も基本的な構成方法である上記の例は次のとおりです。ラウンドロビン クエリ方式は、上流モジュールのデフォルトの負荷分散戦略です。各リクエストは時系列順に 1 つずつ異なるバックエンド サーバーに分散されます。

upstream test { 
      server 10.20.151.114:80; weight=1;
      server 10.20.151.115:80; weight=2;
}

(2) ip_hash

各リクエストはアクセスした IP のハッシュ結果に応じて割り当てられ、バックエンド サーバーには常に同じ IP クライアントがアクセスします。同じ IP からのリクエストが固定マシンに送信されるようにすることで、セッションの問題を解決できます。

upstream test { 
	  ip_hash;  --同一个IP客户端固定访问一个后端服务器
      server 10.20.151.114:80; weight=1;
      server 10.20.151.115:80; weight=2;
}

(3) url_hash

アクセスされた URL のハッシュ結果に応じて、各 URL が同じバックエンド サーバに振り分けられるようにリクエストを振り分けます。リソースがキャッシュされると、リクエストを受信したときにキャッシュからリソースを読み取ることができます。

upstream test { 
	  hash $request_uri;  --实现每个url定向到同一个后端服务器
      server 10.20.151.114:80; weight=1;
      server 10.20.151.115:80; weight=2;
}

(4) minimum_conn

より少ない接続数でリクエストをバックエンド サーバーに転送します。ポーリング アルゴリズムは、負荷がほぼ同じになるようにリクエストを各バックエンドに均等に転送しますが、一部のリクエストには時間がかかるため、リクエストが配置されているバックエンドの負荷が高くなります。この場合、least_conn はより優れた負荷分散効果を実現できます。

upstream test { 
	  least_conn;  --把请求转发给连接数较少的后端服务器
      server 10.20.151.114:80; weight=1;
      server 10.20.151.115:80; weight=2;
}

(5) 重み

重みメソッドは、ポーリング戦略に基づいてポーリングの確率を指定します。

upstream test { 
      server 10.20.151.114:80; weight=1;
      server 10.20.151.115:80; weight=2;  --轮询的几率相对上一条要大
}

(6) フェア

このアルゴリズムは、ページ サイズと読み込み時間に基づいて負荷分散をインテリジェントに実行できます。つまり、バックエンド サーバーの応答時間に基づいてリクエストを割り当てます。短い応答時間の優先割り当て。

upstream test { 
      server 10.20.151.114:80; weight=1;
      server 10.20.151.115:80; weight=2;
      fair;  --实现响应时间短的优先分配
}

nginx ロード バランシング設定ステータス パラメータ

down: 現在のサーバーが一時的にロード バランシングに参加していないことを示します。

• #backup: 予約済みのバックアップ マシン。バックアップ マシンは、バックアップ以外の他のすべてのマシンに障害が発生するかビジー状態になると要求されるため、このマシンへの負担は最も少なくなります。

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

• fail_timeout: max_fails 回の失敗が発生した後、サービスを一時停止する時間単位は秒です。 max_fails は、fail_timeout と一緒に使用できます。

Nginx可分为二层、三层、四层、七层负载均衡。 所谓的二层就是基于MAC地址的负载均衡， 三层就是基于IP地址的负载均衡，四层就是基于IP+端口的负载均衡，七层就是基于URL等应用层信息的负载均衡。因篇幅较长这里不再做具体的介绍，有兴趣的可自行百度。这里以七层负载均衡来做实例。

3.3 Nginx负载均衡实例

环境准备：准备3台Nginx服务器，一台作为负载均衡服务器，其它两台作为后端服务器。

10.20.151.240 ----proxy_server（负载均衡服务器）

10.20.151.112 ----server1（后端服务器1）

10.20.151.113 ----server2（后端服务器2）

（1）负载均衡服务器配置

vim /etc/nginx/nginx.conf        --配置主配置文件
vim /etc/nginx/conf.d/test.conf  --配置子配置文件

（2）后端服务器配置

vim /usr/local/nginx/conf/nginx.conf    --修改配置文件
vim /usr/local/nginx/html/index.html    --添加测试数据

（3）负载均衡测试

在浏览器端访问http://10.20.151.240/，在实际生产中，这两个页面返回的结果是一样的，这里是为了测试效果，所以返回了不同的内容。而为什么刷新后又会返回不同结果呢？那是因为负载均衡默认的均衡策略（或算法）是轮询，所以每刷新一次就会从不同的后端服务器返回不同的请求结果，减轻单个后端服务器的访问量，提升客户端的访问效率，从而达到负载均衡的效果。

当我添加权重（weight）时

再次访问http://10.20.151.240/

加权重和没加权重有什么区别呢？在实际生产中，我们一般会将配置较高的服务器的权重设置高一点，其实就是客户端在访问时，权重较高的服务器会被多次请求，这样能减轻配置较低的服务器的请求量，从而更好的实现负载均衡。

当我添加backup状态参数时

再次访问http://10.20.151.240/

此时我故意停掉第一台后端服务器，继续访问http://10.20.151.240/

当我给113这台后端服务器添加backup后，它就会作为热备服务器，添加的主要目的就是当我其他后端服务器都宕机的情况下，我的热备服务器还能继续提供同样的服务（注意：在其他后端服务器还未宕机之前，该热备服务器是不工作的）。因此负载均衡不仅能达到各个后端服务器负载的均衡，同时通过配置相关转态参数还能保证客户端请求时不造成服务器宕机的情况，保证了后端服务器的稳定性。其他状态参数这里我不再做演示（因为配置方式都一样）。

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