複数サーバーの負荷分散を実現するためのNginx構成

Nginx ロード バランシング サーバー: IP: 192.168.0.4 (Nginx-Server)

Web サーバー リスト:

Web1: 192.168.0.5 (Nginx-Node1/Nginx-Web1)

Web2:192.168.0.7 (Nginx-Node2/Nginx-Web2)

目的: ユーザーが Nginx サーバーにアクセスすると、Nginx を介して Web1 サーバーと Web2 サーバーに負荷分散されます。

Nginx ロードバランシングサーバー nginx.conf

構成コメントは次のとおりです。

イベント
{
epoll を使用します。
ワーカー接続 65535;
}
http
{
##アップストリーム負荷分散、4 つのスケジューリング アルゴリズム##
#スケジューリング アルゴリズム 1: ポーリング。各リクエストは、時系列順に 1 つずつ異なるバックエンド サーバーに割り当てられます。
#バックエンドサーバーがダウンした場合、障害のあるシステムは自動的に削除され、ユーザーアクセスに影響が及ばなくなります
アップストリームウェブホスト {
サーバー 192.168.0.5:6666 ;
サーバー 192.168.0.7:6666 ;
}
#スケジューリング アルゴリズム 2: 重み。マシン構成に基づいて重みを定義できます。重みが高いほど、割り当てられる可能性が高くなります。
アップストリームウェブホスト {
サーバー 192.168.0.5:6666 重み=2;
サーバー 192.168.0.7:6666 重み=3;
}
#スケジューリング アルゴリズム 3: ip_hash。各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、同じ IP アドレスからの訪問者は固定のバックエンド サーバーにアクセスします。
#動的ウェブページのセッション共有問題を効果的に解決します
アップストリームウェブホスト {
ip_ハッシュ;
サーバー 192.168.0.5:6666 ;
サーバー 192.168.0.7:6666 ;
}
#スケジューリングアルゴリズム 4: url_hash (サードパーティのプラグインをインストールする必要があります)。このメソッドは、アクセス URL のハッシュ結果に従ってリクエストを割り当てます。
#各 URL を同じバックエンド サーバーに誘導すると、バックエンド キャッシュ サーバーの効率がさらに向上します。
#Nginx自体はurl_hashをサポートしていません。このスケジューリングアルゴリズムを使用する必要がある場合は、Nginxハッシュパッケージをインストールする必要があります。
アップストリームウェブホスト {
サーバー 192.168.0.5:6666 ;
サーバー 192.168.0.7:6666 ;
$request_uri をハッシュします。
}
#スケジューリング アルゴリズム 5: 公平 (サードパーティのプラグインをインストールする必要があります)。これは、上記の 2 つよりもスマートな負荷分散アルゴリズムです。
#このアルゴリズムは、ページ サイズと読み込み時間に基づいて負荷をインテリジェントに分散します。つまり、バックエンド サーバーの応答時間に基づいてリクエストを分散します。
# 応答時間が短いことを優先します。Nginx 自体はフェアをサポートしていません。このスケジューリングアルゴリズムを使用する必要がある場合は、Nginx のupstream_fair モジュールをダウンロードする必要があります。

#仮想ホストの設定（スケジューリングアルゴリズム3: ip_hashを使用）
サーバ
{
聞く 80;
サーバー名 mongo.demo.com;
# 「/」のリバースプロキシを有効にする
位置 / {
proxy_pass http://webhost;
proxy_redirect オフ;
proxy_set_header X-Real-IP $remote_addr;
#バックエンドWebサーバーはX-Forwarded-Forを通じてユーザーの実際のIPを取得できる
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#以下はオプションのリバース プロキシ構成です。
proxy_set_header ホスト $host;
client_max_body_size 10m; #クライアントが要求できる単一ファイルの最大バイト数
client_body_buffer_size 128k; #バッファプロキシがクライアントのリクエストをバッファリングする最大バイト数。
proxy_connect_timeout 90; #バックエンドサーバーとのNginx接続タイムアウト（プロキシ接続タイムアウト）
proxy_send_timeout 90; #バックエンドサーバーのデータ返信時間（プロキシ送信タイムアウト）
proxy_read_timeout 90; #接続が成功した後のバックエンドサーバーの応答時間（プロキシ受信タイムアウト）
proxy_buffer_size 4k; #ユーザーヘッダー情報を保存するためのプロキシサーバー（nginx）のバッファサイズを設定します
proxy_buffers 4 32k; #proxy_buffers バッファ、平均ウェブページサイズは 32k 未満に設定されます
proxy_busy_buffers_size 64k; #高負荷時のバッファサイズ (proxy_buffers*2)
proxy_temp_file_write_size 64k;
#キャッシュフォルダのサイズを設定します。この値より大きい場合は、上流サーバーから転送されます。
}
}
}
192.168.0.4 (Nginx サーバー) を構成する

設定ファイルを保存するフォルダを作成する

$ mkdir -p /opt/confs
$ vim /opt/confs/nginx.conf
イベント
{
epoll を使用します。
ワーカー接続 65535;
}
http
{
アップストリームウェブホスト {
ip_ハッシュ;
サーバー 192.168.0.5:6666 ;
サーバー 192.168.0.7:6666 ;
}
サーバ
{
聞く 80;
サーバー名 mongo.demo.com;
位置 / {
proxy_pass http://webhost;
proxy_redirect オフ;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header ホスト $host;
クライアントの最大ボディサイズは10mです。
クライアントボディバッファサイズ 128k;
プロキシ接続タイムアウト 90;
プロキシ送信タイムアウト 90;
プロキシ読み取りタイムアウト 90;
プロキシバッファサイズ 4k;
プロキシバッファ 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
}
}
負荷分散サーバー 192.168.0.4 (Nginx-Server) を起動します。

192.168.0.5 (Nginx-Node1/Nginx-Web1) を構成する

Webページを保存するフォルダを作成する

$ mkdir -p /opt/html
$ vim /opt/html/index.html
編集された内容は次のとおりです。

ホストは192.168.0.5 - ノード1です

192.168.0.5 (Nginx-Node1/Nginx-Web1) を起動します。

192.168.0.7 (Nginx-Node2/Nginx-Web2) を構成する

Webページを保存するフォルダを作成する

$ mkdir -p /opt/html
$ vim /opt/html/index.html
編集された内容は次のとおりです。

ホストは192.168.0.7 - ノード2

192.168.0.7 (Nginx-Node2/Nginx-Web2) を起動します

複数サーバーの負荷分散を実現するための Nginx 構成に関するこの記事はこれで終わりです。より関連性の高い Nginx 構成負荷分散コンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。