第八章：部署haproxy代理 搭建nginx集群
Haproxy の概要
Haproxy は、オープンソースの高性能リバース プロキシまたはロード バランシング サービス ソフトウェアの 1 つであり、デュアルマシン ホット バックアップ、仮想ホスト、TCP および HTTP ベースのアプリケーション プロキシなどの機能をサポートしています。
構成がシンプルで、サーバーノードのヘルスチェック機能(keepalivedヘルスチェックに相当)が充実しており、プロキシのバックエンドサーバーに障害が発生した場合、Haproxyは障害が発生したサーバーを自動的に削除します
。最後に、Haproxy は RS サーバーを自動的に追加します。
Haproxy は、トラフィックが多い場合に特に便利です。ただし、セッションの維持または 7 層のアプリケーション サービスが必要です。Haproxy は通常のサーバー ハードウェア上で実行され、簡単な最適化だけで数万の同時接続をサポートできます。
また、その動作モードにより、アプリケーション サーバーがネットワークに公開されるのを防ぎながら、さまざまな Web サイトのアーキテクチャに簡単かつ安全に統合できます。
Haproxy ソフトウェアでは、フロントエンドとバックエンドの機能が導入されています。フロントエンド (ACL ルール マッチング) により、運用および保守管理者は、任意の HTTP リクエスト ヘッダーに基づいてルールをマッチングし、リクエストを関連するバックエンド (フロント エンドの転送を待機しているサーバー プール) に送信できます
。サーバーグループへのリクエスト））。フロントエンドとバックアップにより、
haproxy の 7 層プロキシ機能を簡単に実装できる、数少ない優れたプロキシ サービス ソフトウェアです。
Haproxy は 2 つの主要なプロキシ モードをサポートしています。1 つ目は 4 層 tcp プロキシです (例: メール サービスの内部プロトコル通信サーバー、Mysql サービスなどに使用できます)。
2 つ目はレイヤー 7 プロキシ (HTTP プロキシなど) です。レイヤ 4 TCP プロキシ モードでは、Haproxy はクライアントとサーバー間の両方向にのみトラフィックを転送します。
ただし、7 層モードでは、Haproxy はアプリケーション層プロトコルを分析し、リクエストまたは応答内の指定されたコンテンツを実行、拒否、交換、追加、変更、または削除することでプロトコルを制御できます。
haproxy メイン設定ファイルの概要
vim /usr/src/haproxy-1.5.19/examples/haproxy.cfg
#グローバル設定, グローバル パラメータの設定に使用されます, プロセス レベルの設定, 通常はオペレーティング システムの設定に関連しています。
グローバル
#グローバル ログを定義します, ローカルに設定されています, local0 を介して出力されます, デフォルトは情報レベルです, 2 つの
ログ 127.0 を設定できます。 0.1 local0 warning #
ログレベルの定義 [error warning info debug]
#log 127.0.0.1 local1 info
#実行パス
chroot /usr/local/haproxy
#PID ファイルの格納パス
pidfile /var/run/haproxy.pid
#処理の設定各 haproxy プロセス 同時接続の最大数。コマンド ライン オプション "-n" に相当します。"ulimit -n" の自動計算結果は、このパラメータ設定を参照します。 maxconn 4096 #haproxy user を実行するか、キーワードを使用
し
ますuid
user haproxy
# haproxy user group を実行するか、キーワード gid
group haproxyを使用します
# haproxy
デーモンをバックグラウンドで
実行 # 開始する haproxy プロセスの数を設定します (デーモン モードの haproxy にのみ使用できます)
# 1 つのプロセスのみが開始されますデバッグの難しさなどのさまざまな理由を考慮して、通常はマルチプロセス モードでのみ使用され、単一プロセスが少数のファイル記述子しか開けないシナリオで使用されます
。
#各プロセスで開くことができるファイル記述子の最大数を設定します。デフォルトでは、自動的に計算されるため、このオプションを変更することはお勧めできません。 #ulimit-n 819200 #デバッグ レベル、通常、単一のファイル記述子の場合のみデバッグし
ます
。プロセスが開始され、運用環境では無効になります。
#debug
#haproxy は開始後に関連情報を表示しません。これは、コマンド ラインから haproxy を開始するときにパラメーター「-q」を追加するのと同じです。 #quit #場所を定義し
ます
。統計情報は保存されます
statsソケット /usr/local/haproxy/stats
# デフォルト設定の
デフォルト
#デフォルトモード [tcp: レイヤ 4; http: レイヤ 7; health: OK のみを返す]
モード http
#グローバルログ定義の継承 出力
ロググローバル
#ログカテゴリ, httplog
#option httplog
#バックエンド サーバーがクライアントの実際の IP を記録する必要がある場合は、HTTP リクエストに「X-Forwarded-For」フィールドを追加する必要があります; #ただし、haproxy 独自の正常性検出メカニズムがバックエンド サーバーにアクセスする
場合-end サーバーの場合、アクセス ログは記録されません。127.0.0.0、つまり haproxy 自体を除外する場合は、Exception を使用できます。 #option forwardfor 例外
127.0.0.0/8
option forwardfor
#http プロトコルでのサーバー側のシャットダウン機能を有効にする、各リクエストが完了した後は積極的に http チャネルを閉じます。これにより、長時間の接続がサポートされ、セッションが再利用され、各ログ レコードがすべて記録されます。
option httpclose
#空の接続が生成された場合、この空の接続のログは記録されません。
option dontlognull
#バックエンド サーバーとのセッションが失敗した場合 (サーバー障害またはその他の理由)、セッションを他の正常なサーバーに再配布します。障害が発生したサーバーが回復すると、セッションは回復したサーバーに転送されます。 #
「retries」キーワードを使用して、セッション障害を判断する際の接続試行回数を設定することもできます。オプションの
再ディスパッチの
再試行数は 3 です
。 #haproxy の負荷が高い場合、リンクが高くなります。現在のキューで長時間処理されているリクエストは自動的に終了されます。option
abortonclose
#デフォルトの http リクエスト タイムアウト
タイムアウト http-request 10s
#デフォルトのキュー タイムアウト時間、バックエンド サーバーの負荷が高い場合、haproxy によって送信されたリクエストはbe put into in a queue.
timeout queue 1m
#haproxy とバックエンド サーバー間の接続のタイムアウト時間 timeout
connect 5s
#クライアントが haproxy に接続した後、データ送信は完了し、それ以上のデータ送信はありません。つまり、非アクティブな接続のタイムアウト時間
timeout client 1m
# haproxy とバックエンド サーバー間の非アクティブな接続のタイムアウト時間
timeout server 1m
# 新しい http リクエスト接続確立のデフォルトのタイムアウト時間 この時間が短い場合は、リソースを
節約するために、リソースをできるだけ早く解放できます。
#ハートビート検出タイムアウト
タイムアウトチェック 10秒
#同時接続の最大数
maxconn 2000
#デフォルトのロードバランシング方法を設定
#バランスソース
#balnaceleastconn
#統計ページの構成、フロントエンドとバックエンドの組み合わせ、監視グループの名前はカスタマイズ可能
listen必要に応じてadmin_status
#監視操作モードを設定します
mode http
#統計ページのアクセス ポートを設定します
バインド 0.0.0.0:1080
#統計ページのデフォルトの最大接続数
maxconn 10
#http ログ形式
オプション httplog #
統計を有効にする
stats Enable #haproxy バージョン情報を非表示にする
統計ページの
統計 Hide-version
#モニタリング ページの自動更新時間
statsfresh 30s
#統計ページのアクセス URL
stats uri /stats
#統計ページのパスワード ボックス プロンプト テキスト
stats レルム mCloud\ Haproxy
#モニタリング ページのユーザーとパスワード: admin、複数のユーザー名統計情報を設定できます
authadmin:admin
#バックエンド サーバーを手動で起動/無効にします。TRUE
の場合、Web 管理ノードの統計管理を使用できます。
#haproxy エラー ページを設定します
。 errorfile 400 /usr/local/haproxy/errorfiles/400.http
errorfile 403 /usr/local/haproxy /errorfiles/403.http
エラーファイル 408 /usr/local/haproxy/errorfiles/408.http
エラーファイル 500 /usr/local/haproxy/errorfiles/500.http
エラーファイル 502 /usr/local/haproxy/errorfiles/502.http
エラーファイル 503 /usr/local/ haproxy/errorfiles/503.http
errorfile 504 /usr/local/haproxy/errorfiles/504.http
#haproxy バックエンドサーバーの監視ステータスを監視
listen site_status
binding 0.0.0.0:1081 #Listen port
mode http #http Layer 7 mode
log 127.0.0.1 local2 err #[err warning info debug]
monitor-uri /site_status #Webサイト健全性検出URL, HAProxyで管理されているWebサイトが利用できるかどうかを確認するために使用され、正常時は200、異常時は503を返します。
acl site_dead nbsrv(php_server) lt 1 #Web サイトがダウンしたときの戦略を定義します。ロード バランサーにハングしている指定されたバックエンド内の有効なマシンの数が 1 未満の場合に true を返します。 acl site_dead nbsrv(html_server) lt 1 acl site_dead nbsrv (backend_default
)
lt 1
モニターは site_dead の場合に失敗します #ポリシーが満たされた場合、503 が返されます。オンライン文書には 500 と記載されていますが、実際のテストは 503 です
monitor-net 192.168.4.171/32 #192.168.4.152 からのログ情報は表示されません記録され転送された
monitor-net 192.168.4.172/32
#frontend、名前はカスタム
フロントエンドHAproxy_Cluster #
フロントエンドリスニングポートを定義します。bind:80の形式を使用することをお勧めします。そうしないと、クラスターの高可用性を実現するときに問題が発生します。 , 他のマシンに切り替えると VIP はアクセスできなくなります。bind
0.0.0.0 :80
#acl の後にルール名が続きます。要求された URL が .php で終わる場合、一致によって php_web ルールがトリガーされます。両方の#要求され
た URL が .css、.jpg、.png で終わる場合、.jpeg、.js、.gif で終わる場合、static_web ルールに一致してトリガーします #acl static_web
path_end .gif .png .jpg 。 css .js .jpeg
#acl static_web url_reg /.(css|jpg|png|jpeg|js| gif)$
#-i は大文字と小文字を無視します。要求されたホストが www.test.com で始まるホストである場合、dns_name ルールが一致してトリガーされます。
acl html_web hdr_beg(host) -i www.haproxytest.com
#acl html_web hdr_beg(host) 10.11 .4.152
#クライアントの IP が xxxx の場合、src_ip ルールに一致し、トリガーされます。
#acl src_ip src xxxx
#acl ルール php_web が一致した場合、リクエストは処理のために php_server グループに転送されます; acl ルール html_web が一致した場合、リクエストは処理のために php_server グループに転送されます, リクエストは html_server グループに転送されます。処理中です。
use_backend php_server if php_web
use_backend html_server if html_web
#上記のルールのいずれにも一致しない場合、処理のためにリクエストをdefault_backend グループに転送します
。default_backend backend_default
#バックエンド バックエンド設定、php_server を設定しますgroup および html_server group
backend php_server
#負荷分散方式をラウンドロビン方式、つまり重みベースのラウンドロビン スケジューリング アルゴリズムとして定義し、サーバーのパフォーマンスが比較的均一に分散されている場合に推奨されます
。 #-- static-rr: これも重み
に基づくラウンドロビン スケジューリングですが、静的メソッドであり、実行時にバックエンド ユニットの重みを調整しても新しい重みは使用されません; #-- ソース: ハッシュ操作を実行し
ますリクエストのソース IP に基づいてバックエンド サーバー グループと一致します。
#-- minimumconn: http ベースのアプリケーションなど、セッションが短い環境には適していません;
#-- uri: URI 全体のハッシュ操作;
#-- uri_param: URI 内の転送パラメータ;
#-- hdr() : http ヘッダーに基づいて転送します。そのようなヘッダーがない場合は、代わりにラウンドロビンが使用されます。
バランス ラウンドロビン
モード http
#サーバー ID を Cookie に挿入できるようにします。
サーバー ID の後にクッキーを定義できます。SERVERID
#ハートビート検出方法は、バックエンド サーバーのindex.html ファイル、および他の方法もあります。
オプション httpchk GET /index.html
#バックエンド サーバー定義、maxconn 1024 はサーバーへの最大接続数を表し、cookie 1 はサーバー ID 1 を表し、weight は重みを表します (デフォルトは 1、最大 265、0 は負荷分散に参加しないことを意味します）、
#check inter 1500 はハートビート頻度を検出することを意味します。上昇 2 は 2 回が正しく、サーバーは利用可能であると見なされ、下降 3 は 3 回の障害でサーバーはサーバー php1 192.168.4.171:80 maxconn 1024 cookie 1重み
3 チェックインター 1500 上昇 2 降下 3
バックエンド html_server
バランス ソース
モード http
サーバー html1 192.168.4.172:80 maxconn 1024 Cookie 1 重み 3 チェック インター 1500 上昇 2 フォール 3 バック
エンド backend_default
バランス ソース
モード http
サーバー デフォルト 1 192.168.4.171:80 maxconn 1024 Cookie 1 ウェイト 3 チェック インター 1500 上昇 2 フォール 3
ラボ環境:
- linux-1 haproxy プロキシサーバー
192.168.10.1
2.linux-2 nginx-1
192.168.10.2
3.linux-3 nginx-2
192.168.10.3
実験手順：
1. Nginx サーバー (nginx-1、nginx-2) をコンパイルしてインストールします。
1.nginx-1サーバー
[root@localhost ~]# yum -y install pcre-devel zlib-devel
[root@localhost ~]# tar xf nginx-1.12.0.tar.gz -C /usr/src/
[root@localhost ~]# cd /usr/src/nginx-1.12.0
[root@localhost ~]# useradd -M -s /sbin/nologin nginx
[root@localhost ~]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx &&make &&make install
[root@localhost ~]# echo “
サーバー192.168.10.3
” >/usr/local/nginx/html/index.html[root@localhost ~]# /usr/local/nginx/sbin/nginx
[root@localhost ~]# netstat -anput |grep nginx
サービス /usr/local/nginx/sbin/nginx をシャットダウンする必要がある場合 -s stop
2.nginx-2 サーバー (スクリプトを使用してインストールし、ソース コード ソフトウェアが /root ディレクトリに保存されていることを確認できます)
[root@localhost ~]# vim nginx-install.sh
#!/bin/bash
read -p "ホームページのコンテンツを入力してください:"index
yum -y インストール pcre-devel zlib-devel
tar zxvf nginx-1.12.0.tar.gz -C /usr/src/
cd /usr/src/nginx-1.12.0
useradd -M -s /sbin/nologin nginx
./configure --prefix=/usr/local/nginx --user=nginx --group=nginx && make && make install
echo “$index” > /usr/local/nginx/html/index.html
/usr/local/nginx/sbin/nginx
netstat -anput|grep nginx &>/dev/null
if [ $? -eq 0 ] ;then
echo "nginx サービスが正常に開始されました"
else
echo "nginx サービスが正常に開始されませんでした。インストール プロセスを確認してください"
fi
…
[root@localhost ~]# chmod +x nginx-install.sh
[root@localhost ~]# ./nginx-install.sh
2. Haproxy プロキシ サーバー
1. haproxy をコンパイルしてインストールします。
[root@localhost ~]# yum -y install pcre-devel bzip2-devel
[root@localhost ~]# tar xf haproxy-1.5.19.tar.gz -C /usr/src/
[root@localhost ~]# cd /usr/src/haproxy-1.5.19/
##64 ビット システム
[root@localhost ~]# make TARGET=linux26
[root@localhost ~]# make install
2.Haproxy の構成
[root@localhost haproxy-1.5.19]# vim /usr/src/haproxy-1.5.19/examples/haproxy.cfg
k 注:
global --global part
log /dev/log local0 info
log /dev/log local1 Notice ----表示用に情報ログと通知ログを別々に保存します
maxconn 4096 ----最大接続数
uid 99
gid 99 —ユーザーとグループ ID # pidfile /var/run/haproxy.pid -バックグラウンドで実行されている
pid ファイル デーモンのパスとファイル名
defaults ----デフォルトの設定
ログ グローバル ——ログ設定モードのグローバル部分を適用します
http ——モードは http
オプション httplog
オプション dontlognull
retries 3 です --------ノード障害の数を確認します。連続 3 回に達すると、ノードは使用不可とみなされます
maxconn を使用します 2000-----最大接続数
contimeout 5000-接続タイムアウト 5000
clitimeout 50000
srvtimeout 50000---クライアントとサーバーのタイムアウトは両方とも 50000
# option httpclose ----关闭客户端请求
listen webcluster 0.0.0.0:80 ----Web クラスター (リスニング アドレスとインターフェイス)
オプション httpchk GET /index.html ----check http ファイル
バランス ラウンドロビン - ロード バランシング スケジューリング アルゴリズム ポーリング ラウンドロビン
サーバー inst1 192.168.10.2 :80 チェックinter 2000 fall 3
server inst2 192.168.10.3:80 check inter 2000 fall 3 - サーバー ノードのアドレス、名前、ポート、チェック間隔、ヘルス チェック番号は 3 回失敗したとみなされます。
/dev/log ディレクトリ内のログ ファイルはソケットです。通信回線の敷地であり、これらのエンドポイント（ソケット）の間にはデータ通信ネットワークが存在します。
その通信プロセスは、
プログラムがリモート コンピュータのソケット アドレスにアクセスし、アクセスされたコンピュータのソケット アドレスとリモート コンピュータのソケット アドレスの間に通信回線が確立されるというものです。
[root@localhost ~]# cd
[root@localhost ~]# mkdir /etc/haproxy
設定ファイルを次のように編集します
[root@localhost ~]# vim /etc/haproxy/haproxy.cfg
global
log /dev/log local0 info
log /dev/log local1 Notice
maxconn 4096
uid 99
gid 99
daemon
デフォルト
ログ グローバル
モード http
オプション httplog
オプション dontlognull
再試行 3
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
listen webcluster 0.0.0.0:80
オプション httpchk GET /index.html
バランス ラウンドロビン
サーバー inst1 192.168.10.2:80 2000 年秋 3 間を確認
サーバー inst2 192.168.10.3:80 2000 年中 3 年間を確認
[root@localhost ~]# cp /usr/src/haproxy-1.5.19/examples/haproxy.init /etc/init.d/haproxy
[root@localhost ~]# chmod +x /etc/init.d/haproxy
[root@localhost ~]# ln -s /usr/local/sbin/haproxy /usr/sbin/haproxy
[root@localhost ~]# /etc/init.d/haproxy restart
3. 検証:
クライアントは 2 つの IE ブラウザを開き、http://192.168.10.1 にアクセスします。
別の Web コンテンツを取得できるかどうかを確認し、成功するかどうかを確認します。
4. haproxy のログ管理:
Haproxy のログはデフォルトでシステムの syslog に出力されるため、閲覧が不便ですが、haproxy のログの管理を容易にするために、本番環境では個別にログを定義します。
[root@localhost ~]# cd /etc/rsyslog.d/
[root@localhost ~]# vim haproxy.conf
local0.* /var/log/haproxy/ha-info.log
local1.* /var/log/haproxy/ha-notice.log
※以下の設定を追加しない場合、/var/log/haproxy.logにログが書き込まれるだけでなく、メッセージファイルも書き込まれます。
[root@localhost ~]# vi /etc/sysconfig/rsyslog
に追加：
SYSLOGD_OPTIONS="-r -m 0 -c 2"
:wq
#-c 2 互換モードを使用します。デフォルトは -c 5 です。
#-r リモート ログを有効にします
。 #-m 0 タイムスタンプをマークします。単位は分で、0の場合は機能が無効であることを示します。
[root@localhost ~]# systemctl restart rsyslog
[root@localhost ~]# /etc/init.d/haproxy restart
[root@localhost ~]# vim /etc/haproxy/haproxy.cfg
グローバル
ログ /dev/log local0 情報
ログ /dev/log local1 通知
構成を確認すると、haproxy.cfg が構成されています。
検証テスト:
[root@localhost ~]# tail /var/log/haproxy/ha-info.log
生成されたログがあるかどうかを確認する
...
教科書にある関連する rsyslog 設定は Rainerscript 言語で書かれており、複雑な環境に適しています。省略 - 上記の方法を使用するだけで実現できます
vim /etc/rsyslog.d/haproxy.conf
コンテンツの編集:
if ($programname == 'haproxy' および $syslogserverity-text == 'info') then -/var/log/haproxy/haproxy-info.log
& ~
if ($programname == 'haproxy' および $syslogserverity-text == 'notice') then -/var/log/haproxy/haproxy-notice.log
& ~
…
Haproxy パラメータの最適化
maxconn 最大接続数には 10240 デーモンを使用することをお勧めします
デーモン プロセス モードでは、デーモン以外のデフォルトの
nbproc を使用できます ロード バランシングのための同時プロセス数は 2 倍以上であることを推奨します現在のサーバーのCPUコア、
リトライ回数はクラスタノードを確認するため、ノード数が多い場合は同時実行、量は多めに2～3回に設定、オプションhttp-server-closeでhttpリクエストオプションをアクティブに
クローズタイムアウト時間の設定が長すぎることによる http 接続の蓄積を避けるために、運用環境でこのオプションを使用してください。
timeout http-keep-alive 長い接続タイムアウト (10 秒) )
timeout http-request http リクエストのタイムアウト時間 (5 ～ 10 秒) http 接続のリリース
タイムアウトの速度 クライアント クライアント タイムアウト時間