Nginx フォワードプロキシとリバースプロキシ、および負荷分散機能の構成コード例

この記事は主に、Nginx のフォワードプロキシとリバースプロキシ、および負荷分散機能の設定コード例を紹介します。この記事ではサンプルコードを詳細に紹介しており、皆さんの学習や仕事に一定の参考値があります。困っている友人は参考にしてください。

システム環境:

VirtualBox マネージャー

セントロス6.4

nginx1.10.0

IPに対応するマシン名:

IP マシン名役割名

10.0.0.139 [elk] クライアント

10.0.0.136 [lvs-master] nginx サーバー

10.0.0.137 [kvm] ウェブサーバー1

10.0.0.111 [lvs-backup] ウェブサーバー2

1. フォワードプロキシ

1.1 環境の紹介

1.2 構成の概要

Nginx サーバー: (イントラネットアドレス: 10.0.0.136、外部ネットワークアドレス: 172.16.27.64)

VirtualBox Manager を使用してデュアルネットワークカードを仮想化します。

[root@lvs-master conf.d]# ifconfig 
eth0 リンク カプセル化:イーサネット HWaddr 08:00:27:30:56:99 
     inet アドレス:10.0.0.136 Bcast:10.255.255.255 マスク:255.0.0.0 
     inet6 アドレス: fe80::a00:27ff:fe30:5699/64 スコープ:リンク 
     アップブロードキャスト 実行中マルチキャスト MTU:1500 メトリック:1 
     RXパケット:891978 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:9509 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 トランザクションキュー数:1000 
     RX バイト:81841095 (78.0 MiB) TX バイト:13339058 (12.7 MiB) 
 
eth1 リンク カプセル化:イーサネット HWaddr 08:00:27:55:4C:72 
     inet アドレス:172.16.27.64 Bcast:172.16.27.255 マスク:255.255.255.0 
     inet6 アドレス: fe80::a00:27ff:fe55:4c72/64 スコープ:リンク 
     アップブロードキャスト 実行中マルチキャスト MTU:1500 メトリック:1 
     RXパケット:913671 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:22712 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 トランザクションキュー数:1000 
     RX バイト:109369858 (104.3 MiB) TX バイト:1903855 (1.8 MiB) 
 
lo リンクカプセル化:ローカルループバック 
     inet アドレス:127.0.0.1 マスク:255.0.0.0 
     inet6 アドレス: ::1/128 スコープ:ホスト 
     アップループバック実行中 MTU:16436 メトリック:1 
     RXパケット:36222 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:36222 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 送信キュー:0 
     RX バイト:3899937 (3.7 MiB) TX バイト:3899937 (3.7 MiB)

[root@lvs-master conf.d]# cat zxproxy.conf 
サーバー{ 
  listen 80; #リッスンポート server_name 10.0.0.136; #クライアントリゾルバとのネットワーク通信を必要とするサーバーコンテンツアドレス 172.16.5.1; #DNS、これはDNS、外部ネットワークロケーションへのアクセス / { 
      proxy_pass http://$http_host$request_uri; #$http_host と $request_uri は nginx のシステム変数なので、置き換える必要はなく、そのままにしておきます}

Nginx クライアント:

イントラネットネットワークカードは1枚だけあり、Nginxサーバーにアクセスすることでインターネットにアクセスします。実際、「壁登り」や「ゾンビチキン」などの一般的な名前はこの原理に基づいています。

[root@kvm ~]# ifconfig 
eth0 リンク カプセル化:イーサネット HWaddr 08:00:27:72:8C:3B 
     inet アドレス:10.0.0.137 Bcast:10.255.255.255 マスク:255.0.0.0 
     inet6 アドレス: fe80::a00:27ff:fe72:8c3b/64 スコープ:リンク 
     アップブロードキャスト 実行中マルチキャスト MTU:1500 メトリック:1 
     RXパケット:1462448 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TXパケット:21130 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 トランザクションキュー数:1000 
     RX バイト:145119904 (138.3 MiB) TX バイト:2814635 (2.6 MiB) 
 
lo リンクカプセル化:ローカルループバック 
     inet アドレス:127.0.0.1 マスク:255.0.0.0 
     inet6 アドレス: ::1/128 スコープ:ホスト 
     アップループバック実行中 MTU:16436 メトリック:1 
     RXパケット:60800 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TXパケット:60800 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 送信キュー:0 
     RX バイト:4831102 (4.6 MiB) TX バイト:4831102 (4.6 MiB) 
 
[root@kvm ~]# wget www.baidu.com 
--2016-06-08 13:02:08-- http://www.baidu.com/ 
ホスト www.baidu.com を解決しています... 失敗: ドメイン名の解決が一時的に失敗しました。 #Baidu wget にアクセスできません: ホスト アドレス "www.baidu.com" を解決できません 
 
[root@kvm ~]# export http_proxy=http://10.0.0.136:80 #環境変数を設定し、プロキシサーバーの IP とポートを指定します [root@kvm ~]# wget www.baidu.com #Baidu に正常にアクセスできます--2016-06-08 13:08:15-- http://www.baidu.com/ 
10.0.0.136:80 に接続しています...接続されました。 
プロキシ要求が送信されました。応答を待機しています... 200 OK 
長さ: 未指定 [text/html] 
保存先: "index.html.1" 
 
  [ <=> ] 0.07秒で99,762 --.-K/s 
 
2016-06-08 13:08:16 (1.36 MB/秒) - 「index.html.1」が保存されました [99762]

2. リバースプロキシ

フォワードプロキシの紹介記事

2.1 環境の紹介

1. テストページを見てみましょう:

[root@kvm ~]# yum install httpd 
[root@kvm ~]# echo "<html>10.0.0.137</html>" > /var/www/html/index.html 
[root@lvs-backup ~]# yum install httpd 
[root@lvs-backup~]# echo "<html>10.0.0.111</html>" > /var/www/html/index.html

2. 効果を見てみましょう:

[root@lvs-backup html]# curl 10.0.0.111 
<html> 
10.0.0.111 
</html> 
[root@lvs-backup html]# curl 10.0.0.137 
<html> 
10.0.0.137 
</html>  
##すべて成功しました。次のステップに進みましょう。

2.2 構成の概要

[root@lvs-master conf.d]# ls #nginxディレクトリ内の設定ファイルzxproxy.conf 
[root@lvs-master conf.d]# cp zxproxy.conf fxproxy.conf #コピーを作成します。以前はフォワードプロキシでしたが、現在はリバースプロキシです。 [root@lvs-master conf.d]# mv zxproxy.conf zxproxy.conf.bak

[root@lvs-master conf.d]# cat fxproxy.conf  
サーバー{ 
  聞く 80; 
  server_name 10.0.0.136; #環境紹介によると、nginxサーバのIP 
 
  位置 / { 
      proxy_pass http://10.0.0.137; #プロキシされるサーバーのIP 
        } 
 
#proxy_pass: プロキシパス URL 
#デフォルト値: NO 
# フィールドを使用: location (location にフィールドがある場合) # このパラメータは、プロキシされたサーバーのアドレスとマップされた URL を設定します。アドレスは、ホスト名、ドメイン名、IP とポート モードのいずれかになります。例: 
#プロキシパス http://192.168.1.6:8099/linuxtone/; 
 
[root@lvs-master conf.d]# service nginx restart #再起動して設定をロードします

結果を見てみましょう:

#まず、実験環境のクライアントマシンにログインします。IP は次のとおりです。 
[root@elk ~]# ifconfig              
eth0 リンク カプセル化:イーサネット HWaddr 08:00:27:3D:40:40 
     inet アドレス:10.0.0.139 Bcast:10.255.255.255 マスク:255.0.0.0 
     inet6 アドレス: fe80::a00:27ff:fe3d:4040/64 スコープ:リンク 
     アップブロードキャスト 実行中マルチキャスト MTU:1500 メトリック:1 
     RXパケット:2618345 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:247926 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 トランザクションキュー数:1000 
     RX バイト:336182790 (320.6 MiB) TX バイト:35145157 (33.5 MiB) 
 
lo リンクカプセル化:ローカルループバック 
     inet アドレス:127.0.0.1 マスク:255.0.0.0 
     inet6 アドレス: ::1/128 スコープ:ホスト 
     アップループバック実行中 MTU:16436 メトリック:1 
     RXパケット:177352 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:177352 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 送信キュー:0 
     RX バイト:26547640 (25.3 MiB) TX バイト:26547640 (25.3 MiB) 
 
[root@elk ~]# curl 10.0.0.136 #リバースプロキシサーバーにアクセス <html> 
10.0.0.137          
</html> 
#プロキシサーバーにアクセスし、結果がWebサーバー1に転送されていることがわかります。 
 
#次に、nginx-server と web-server1 のログをそれぞれ見てみましょう。 
nginx サーバー: 
[root@lvs-master ~]# /var/log/nginx/access.log の末尾を表示します 
10.0.0.139- - [2016年6月8日:15:35:43 +0800] "GET / HTTP/1.1" 200 26 "-" "curl/7.19.7  
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" "-" 
 
ウェブサーバー: 
[root@kvm httpd]# /var/log/httpd/access_log の末尾 
10.0.0.136 - - [2016年6月8日:15:21:12 +0800] "GET / HTTP/1.0" 200 26 "-" "curl/7.19.7  
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" 
 
##nginx-server 上の nginx ログを見ると、アクセスされたユーザーは 10.0.0.139 であり、これが私たちの環境のクライアントであることが分かります。 
#Web サーバーに表示される IP は 10.0.0.136 で、これは nginx-server です。 
#簡単に言うと、リバース プロキシとは、nginx-server が顧客にとっての実際のサーバーであることを意味します。実際には、ユーザーが nginx-server にアクセスすると、リクエストは #web-server1 に転送され、次に web-server1 はリクエストの結果を nginx-server に送信し、次に ngin small-server がリクエストの結果をユーザーに転送します。 
 
#Web サーバーでは、プロキシ IP のみが表示されます。実際のユーザー IP も表示されますか? 
 
[root@lvs-master conf.d]# cat fxproxy.conf         
サーバー{ 
  聞く 80; 
  server_name 10.0.0.136; #環境紹介によると、nginxサーバのIP 
 
  位置 / { 
      proxy_pass http://10.0.0.137; #プロキシされるサーバーのIP 
      proxy_set_header X-Real-IP $remote_addr; #この行が追加されます}

[root@lvs-master conf.d]# サービスnginxを再起動します 
[root@kvm ~]# /var/log/httpd/access_log の末尾 
10.0.0.136 - - [2016年6月8日:16:10:53 +0800] "GET / HTTP/1.0" 200 26 "-" "curl/7.19.7 
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" 
 
# 変更後もプロキシサーバーの IP アドレスは表示されます。Web サーバーの設定を変更します [root@kvm ~]# vim /etc/httpd/conf/httpd.conf 
ログフォーマット "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" の組み合わせ 
ログフォーマット "%h %l %u %t \"%r\" %>s %b" 共通 
LogFormat "%{Referer}i -> %U" リファラー 
LogFormat "%{User-agent}i" エージェント 
 
# 変更後: (%h はアクセスされているホストを参照しますが、アクセスされている実際のホスト IP に変更されました) 
ログフォーマット "%{X-Real-IP}i</span> %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" の組み合わせ 
ログフォーマット "%h %l %u %t \"%r\" %>s %b" 共通 
LogFormat "%{Referer}i -> %U" リファラー 
LogFormat "%{User-agent}i" エージェント

[root@kvm ~]# サービス httpd を再起動します 
httpdを停止しています: [ OK ] 
httpdを起動しています: [ OK ] 
 
[root@kvm ~]# /var/log/httpd/access_log の末尾 
10.0.0.136 - - [2016年6月8日:16:10:53 +0800] "GET / HTTP/1.0" 200 26 "-" "curl/7.19.7 
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" 
<span style="color:#FF0000;">10.0.0.139</span> - - [2016/06/08:16:16:01 +0800] "GET / HTTP/1.0" 200 26 "-" "curl/7.19.7 
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" 
#実際のアクセスアドレスになりました

複数の Web サーバーをプロキシします。

[root@lvs-master conf.d]# cat fxproxy.conf 
サーバー{ 
  聞く 80; 
  サーバー名 10.0.0.136; 
 
  位置 / { 
      プロキシパス http://10.0.0.137; 
      proxy_set_header X-Real-IP $remote_addr; 
        } 
  location /web2 { #別の場所を追加 
      プロキシパス http://10.0.0.111; 
      proxy_set_header X-Real-IP $remote_addr;   
        } 
 
[root@lvs-backup ~]# cd /var/www/html/ # 10.0.0.111 の web-server2 に入ります 
[root@lvs-backup html]# mkdir web 
[root@lvs-backup html]# echo "<html>10.0.0.111</html>" > index.html 
# クライアント側でアクセスしてみましょう: 
[root@elk ~]# curl 10.0.0.136/web2/ 
<html> 
10.0.0.111 
</html> 
#アクセス成功

3. 負荷分散

負荷分散を実装する方法は多数あります。一般的に使用されている LVS は 4 層の負荷分散であり、nginx は 7 層の負荷分散です。関連情報はオンラインで検索できます。

3.1 環境の紹介

3.2 構成の概要

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

2. Nginx の負荷分散モジュールは現在、以下で紹介する 4 つのスケジューリングアルゴリズムをサポートしています。最後の 2 つはサードパーティのスケジューリングアルゴリズムです。

ポーリング（デフォルト）。各リクエストは時系列順に 1 つずつ異なるバックエンドサーバーに割り当てられます。バックエンドサーバーがダウンした場合、障害のあるシステムは自動的に排除されるため、ユーザーアクセスには影響しません。 Weight はポーリングの重みを指定します。Weight 値が大きいほどアクセスされる確率が高くなります。主に各バックエンドサーバーのパフォーマンスにばらつきがある場合に使用されます。
ip_ハッシュ。各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、同じ IP アドレスからの訪問者は固定のバックエンドサーバーにアクセスし、動的 Web ページのセッション共有の問題を効果的に解決します。
公平。これは、上記の 2 つよりもスマートな負荷分散アルゴリズムです。このアルゴリズムは、ページサイズと読み込み時間に基づいてインテリジェントに負荷分散を実行できます。つまり、バックエンドサーバーの応答時間に基づいて要求を分散し、応答時間が短い要求を優先します。 Nginx 自体は fair をサポートしていません。このスケジューリングアルゴリズムを使用する必要がある場合は、Nginx の upload_fair モジュールをダウンロードする必要があります。
url_ハッシュ。この方法では、アクセスされた URL のハッシュ結果に応じてリクエストが分散されるため、各 URL が同じバックエンドサーバーに送信されるようになり、バックエンドキャッシュサーバーの効率がさらに向上します。 Nginx 自体は url_hash をサポートしていません。このスケジューリングアルゴリズムを使用する必要がある場合は、Nginx ハッシュソフトウェアパッケージをインストールする必要があります。

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

HTTP Upstream モジュールでは、server ディレクティブを通じてバックエンドサーバーの IP アドレスとポートを指定できるほか、負荷分散スケジュールで各バックエンドサーバーのステータスを設定することもできます。よく使用される状態は次のとおりです。

down: 現在のサーバーが一時的に負荷分散に参加していないことを示します。
バックアップ、予約済みのバックアップマシン。バックアップマシンは、他のすべての非バックアップマシンが故障しているかビジー状態の場合にのみ要求されるため、このマシンにかかる負荷は最も軽くなります。
max_fails は、許容されるリクエスト失敗の数です。デフォルトは 1 です。最大回数を超えると、proxy_next_upstream モジュールで定義されたエラーが返されます。
fail_timeout、max_fails 回の失敗後にサービスを一時停止するまでの時間。 max_fails は fail_timeout と一緒に使用できます。

注意: 負荷スケジューリングアルゴリズムが ip_hash の場合、負荷分散スケジューリングにおけるバックエンドサーバーのステータスは、重み付けまたはバックアップにすることはできません。
具体的な構成を見てみましょう。

[root@lvs-master conf.d]# cat ../nginx.conf 
http { 
  /etc/nginx/mime.types を含めます。 
  デフォルトタイプ アプリケーション/オクテットストリーム; 
 
  log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 
           '$status $body_bytes_sent "$http_referer" ' 
           '"$http_user_agent" "$http_x_forwarded_for"'; 
 
  access_log /var/log/nginx/access.log メイン; 
 
  ファイル送信オン; 
  #tcp_nopush オン; 
 
  キープアライブタイムアウト65; 
 
  #gzip オン; 
アップストリーム 1.2.3.4 { 
  サーバー 10.0.0.111:80; 
  サーバー 10.0.0.137:80; 
  } 
  /etc/nginx/conf.d/*.conf を含めます。 
} 
 
[root@lvs-master conf.d]# cat slb.confserver  
{  
位置 / {  
   proxy_pass http://1.2.3.4; proxy_set_header X-Real-IP $remote_addr;  
      } 
#注: アップストリームは server{ } の外部で定義され、server{ } 内では定義できません。アップストリームを定義したら、proxy_pass を使用してそれを参照するだけです。

4. テスト結果

[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.111 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.137 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.111 
</html> 
#結果として、server1 と 2 が交互に表示され、デフォルトの負荷分散方法がポーリングであることを示します。

5. 健康チェック

通常、ヘルスチェックには keepalived が必要ですが、nginx にも設定できる対応するパラメータがあります。

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

fail_timeout、max_fails 回の失敗後にサービスを一時停止するまでの時間。 max_fails はヘルスチェックのために fail_timeout と一緒に使用できます。

[root@lvs-master conf.d]# cat ../nginx.conf 
http {   
  /etc/nginx/mime.types を含めます。 
  デフォルトタイプ アプリケーション/オクテットストリーム; 
 
  log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 
           '$status $body_bytes_sent "$http_referer" ' 
           '"$http_user_agent" "$http_x_forwarded_for"'; 
 
  access_log /var/log/nginx/access.log メイン; 
 
  ファイル送信オン; 
  #tcp_nopush オン; 
 
  キープアライブタイムアウト65; 
 
  #gzip オン; 
  アップストリーム 1.2.3.4 { 
  サーバー 10.0.0.111:80 重み=1 max_fails=2 fail_timeout=2; 
  サーバー 10.0.0.137:80 重み=1 max_fails=2 fail_timeout=2; 
  } 
  /etc/nginx/conf.d/*.conf を含めます。 
  } 
[root@lvs-master conf.d]# サービスnginxを再起動します

6. 結果をテストする

[root@kvm httpd]# service httpd stop #web-server1 サービスをシャットダウンします [root@elk ~]# curl 10.0.0.136 
<html> 
10.0.0.111 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.111 
</html> 
#現在、web-server2 のみにアクセスできます。 
 
[root@kvm httpd]# service httpd start #web-server1 サービスを開く [root@elk ~]# curl 10.0.0.136       
<html> 
10.0.0.111 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.137 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.111 
</html>

7. ip_hashの負荷分散

[root@lvs-master conf.d]# cat ../nginx.conf 
アップストリーム 1.2.3.4 { 
  ip_ハッシュ; 
  サーバー 10.0.0.111:80 重み=1 max_fails=2 fail_timeout=2; 
  サーバー 10.0.0.137:80 重み=1 max_fails=2 fail_timeout=2; 
  } 
[root@lvs-master conf.d]# サービスnginxを再起動します 
nginxを停止: [OK] 
nginx を起動しています: [OK] 
 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.137 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.137 
</html> 
#この負荷分散を構成すると、各リクエストはアクセス IP のハッシュ結果に従って分散され、同じ IP アドレスからの訪問者は固定のバックエンド サーバーにアクセスするようになります。 
#動的 Web ページのセッション共有問題を効果的に解決します。 （一般的には、電子商取引のウェブサイトで多く使用されています）

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: