目次
2. Haproxy で一般的に使用されるスケジューリング アルゴリズム
③ ソースベースのアクセススケジューリングアルゴリズム(Source Hashing)
6. ソフト接続を作成します (2 つのコマンドは同じです)。
8. ログ定義(HAProxyがインストールされているサーバー上で設定)
1. 一般的な Web クラスター スケジューラ
Webクラスタスケジューラはソフトウェアとハードウェアに分かれています
-
ソフトウェアで一般的に使用されるLVS、 Haproxy、Nginx
-
LVS は最高のパフォーマンスを持っていますが、構築が比較的複雑で、Nginx の上流モジュールはクラスター機能をサポートしていますが、クラスターノードのヘルスチェック機能は強力ではなく、高い同時実行性は Haproxy ほどではありません。
-
ハードウェアはF5が一般的で、BarracudaやNSFOCUSなどの国産製品を使っている人が多いです。
2. HAProxy クラスターの概要
LVS は企業の負荷に耐える強力な機能を備えていますが、欠点もあります。
LVS は定期的な処理をサポートしておらず、動的と静的な分離を実現できません。大規模な Web サイトの場合、LVS の実装と構成は複雑で、メンテナンスコストが比較的高くなります。
Haproxy は、TCP および HTTP アプリケーションに基づいて可用性、負荷分散、およびプロキシを改善できるソフトウェアです。負荷の高い Web サイトに適しており、ハードウェア上で実行される数万の同時接続要求をサポートできます。
1. Haproxy の特徴:
1. 信頼性と安定性は非常に優れており、ハードウェアレベルの F5 ロードバランサ装置に匹敵します。
2. 同時に最大 40,000 ~ 50,000 の同時接続を維持でき、単位時間あたりの最大処理リクエスト数は 20,000 で、最大処理能力は 10Git/t に達します。
3. 最大 8 つの負荷分散アルゴリズムをサポートし、セッション永続性もサポートします
4. 接続拒否や完全透過プロキシなどの独自機能をサポート
5. 仮想ホスト機能をサポートし、より柔軟な Web 負荷分散を実現します。
6. アクセス制御のための強力な ACL サポート
7. 独自の弾性バイナリ ツリー データ構造により、データ構造の複雑さが 0 (1) に増加します。つまり、データ エントリの増加によってデータのクエリ速度が低下することはありません。
8. クライアントのキープアライブ機能をサポートし、クライアントと haproxy 間の複数の 3 ウェイ ハンドシェイクによって引き起こされるリソースの無駄を削減し、複数のリクエストを 1 つの TCP 接続で完了できるようにします。
9. TCP アクセラレーション、mmap メカニズムと同様のゼロコピー機能をサポート
10. 応答バッファリングのサポート
11.RDPプロトコルをサポート
12. ソースベースのスティッキー性は、nginx の ip_hash 関数に似ており、一定期間内に常に同じクライアントからのリクエストを同じ上流サーバーにディスパッチします。
13. より優れた統計データ インターフェイス。Web インターフェイスには、バックエンド Jiquanzhong の各サーバーのデータの受け入れ、送信、拒否、エラー、その他のデータの統計情報が表示されます。
14. 詳細な健全性ステータスの検出。Web インターフェイスの上流サーバーの健全性検出ステータスに関連し、特定の管理機能を提供します。
15. トラフィックベースの健全性評価メカニズム
16. http認証に基づく
17. コマンドラインベースの管理インターフェイス
18. ログを解析できるログアナライザー
2. Haproxy で一般的に使用されるスケジューリング アルゴリズム
Haproxy はさまざまなスケジューリング アルゴリズムをサポートしています。最も一般的に使用されるアルゴリズムは 8 つです。
①ラウンドロビン
- RR アルゴリズムは最も単純で最も一般的に使用されるアルゴリズムで、アクセス要求をポーリングして割り当て、負荷分散効果を実現します。
② 最小接続数(Least Connections)
- 最小接続数アルゴリズムは、シック ノードの接続数に応じてフロントエンド リクエストを動的に割り当てるアルゴリズムであり、rr アルゴリズムと比較して大幅に改良され、より多く使用されるアルゴリズムです。
③ ソースベースのアクセススケジューリングアルゴリズム(Source Hashing)
- これは、セッション レコードがサーバー側で記録され、ソース IP、Cookie などに基づいてクラスターのスケジューリングを実行できる一部のシナリオで使用されます。
- 例: サーバーに 3 つのノードがある場合、最初のユーザーがノード A にアクセスすると、2 番目のユーザーはノード B にアクセスします。最初のユーザーがダウンロードして再度アクセスした場合、そのユーザーは引き続きノード A に割り当てられ、2 番目のユーザーもノード B に割り当てられます。ロード バランサーが再起動しない限り、常にこの方法で割り当てられます。
- サブスケジューリング アルゴリズムの利点は、セッションの保持を実現できることですが、一部の IP アクセスが非常に大きい場合、不均一な負荷分散が発生し、一部のノードのアクセス量が大きくなり、ビジネスの使用に影響を及ぼします。
④URi
- 要求された URI に従って、CDN を使用する必要があることを示します
⑤url_param
- 各 HTTP リクエストが HTTP リクエスト ヘッダーに従ってロックされていることを示します
⑥ rdp-cookie(名前)
- 各 TCP リクエストがロックされ、Cookie (名前) に従ってハッシュされることを示します。
⑦ソース
- リクエストの送信元 IP に応じて、Nginx の IP ハッシュ メカニズムに似ていることを示します
⑧ 静的 -rr
- 重みに応じてラウンドロビンで割り当てられることを示します。
3. nginx、LVS、Haproxy の違いは何ですか
LVS
- サードパーティアプリケーションに基づくソフトロードバランシング
- レイヤ4のIPロードバランシング技術のみを実現でき、ステータス監視機能は単一ですが、全体的なロードバランシングパフォーマンスは最強です。
nginx
-
サードパーティアプリケーションに基づくソフトロードバランシング
-
4層および7層テクノロジーを実装可能
-
主にWebサーバーやキャッシュサーバーとして利用されており、nginxの上流モジュールもクラスター機能をサポートしていますが、クラスターノードに対する強力なヘルスチェック機能はなく、性能もHaproxyに及びません。
ハプロキシ
- Linuxオペレーティングシステムカーネルに基づいたソフトロードバランシングを実現
- TCP および HTTP アプリケーションに包括的な負荷分散ソリューションを提供できます。
- ステータス監視に関しては、機能がより豊富かつ強力になり、ポート、URL、スクリプトなどのさまざまなステータス監視方法をサポートできます。
要約:
①システムカーネルまたはサードパーティアプリケーションに基づく、②レイヤー4またはレイヤー7での動作、③ステータスの監視の3つの側面から要約されます。
- LVS はオペレーティング システム カーネルに基づいてソフト ロード バランシングを実装し、nginx と haproxy はサードパーティ アプリケーションに基づいて実装されます。
- LVS は 4 層の IP ロード バランシング テクノロジーを実装できます。LVS ロード バランシングは 4 層の中で最も軽量で、nginx と haproxy は両方とも 4 層と 7 層を実現できます。
- LVS は単一の状態監視機能を持ち、Haproxy は強力な状態監視機能を持ち、ポート、URL、およびスクリプトの状態監視をサポートできます。Nginx は主に Web サーバーまたはキャッシュ サーバーです。クラスタリング機能をサポートする uostream モジュールもありますが、ヘルスノードのチェックが強くない。
3. 実験:
1. Haproxy は Web クラスターを構築します
サーバ | IPアドレス |
---|---|
ハプロキシサーバー | 192.168.77.26 |
nginx1サーバー | 192.168.77.27 |
nginx2サーバー | 192.168.77.28 |
クライアント | ローカルでアクセスする |
2. Haproxy サーバーの展開:
1. ファイアウォールをオフにし、Haproxy のインストールに必要なソフトウェア パッケージを /opt ディレクトリに転送します。 systemctl
stop firewalld
setenforce 02. Haproxy をコンパイルしてインストールします。
- yum install -y pcre-devel bzip2-devel gcc gcc-c++ make #依存環境のインストール
- tar zxvf haproxy-1.5.19.tar.gz #解凍
- cd haproxy-1.5.19/
- TARGET=linux2628 ARCH=x86_64 #TARGET=linux26 #カーネルバージョンを作成し、
- #uname -r を使用してカーネル (2.6.18-371.el5 など) を表示し、このパラメータに TARGET=linux26 を使用します。カーネルが 2.6.28 より大きい場合は、TARGET=linux2628 を使用します。
- make install #installation
3. Haproxyサーバーの設定
mkdir /etc/haproxy
cp examples/haproxy.cfg /etc/haproxy/
cd /etc/haproxy/
vim haproxy.cfg
global #全局配置,主要用于定义全局参数,属于进程级的配置,通常和操作系统配置有关
--4~5行--修改,定义haproxy日志输出设置和日志级别,local0为日志设备,默认存放到系统日志
log /dev/log local0 info #修改
log /dev/log local0 notice #修改
#log loghost local0 info
maxconn 4096 #最大连接数,需考虑ulimit -n限制,推荐使用10240
--8行--注释,chroot运行路径,为该服务自设置的根目录,一般需将此行注释掉
#chroot /usr/share/haproxy
uid 99 #用户UID
gid 99 #用户GID
daemon #守护进程模式
nbproc 1 #添加,设置并发进程数,建议与当前服务器CPU核数相等或为其2倍
defaults #配置默认参数,这些参数可以被用到Listen,frontend,backend组件
log global #引入global定义的日志格式
mode http #模式为http(7层代理http,4层代理tcp)
option httplog #日志类别为http日志格式
option dontlognull #不记录健康检查日志信息
retries 3 #检查节点服务器失败次数,连续达到三次失败,则认为节点不可用
redispatch #当服务器负载很高时,自动结束当前队列处理比较久的连接
maxconn 2000 #最大连接数,“defaults”中的值不能超过“global”段中的定义
#contimeout 5000 #设置连接超时时间,默认单位是毫秒
#clitimeout 50000 #设置客户端超时时间,默认单位是毫秒
#srvtimeout 50000 #设置服务器超时时间,默认单位是毫秒
timeout http-request 10s #默认http请求超时时间
timeout queue 1m #默认队列超时时间
timeout connect 10s #默认连接超时时间,新版本中替代contimeout,该参数向后兼容
timeout client 1m #默认客户端超时时间,新版本中替代clitimeout,该参数向后兼容
timeout server 1m #默认服务器超时时间,新版本中替代srvtimeout,该参数向后兼容
timeout http-keep-alive 10s #默认持久连接超时时间
timeout check 10s #设置心跳检查超时时间
--删除下面所有listen项--,添加
listen webcluster 0.0.0.0:80 #haproxy实例状态监控部分配置,定义一个名为webcluster的应用
option httpchk GET /test.html #检查服务器的test.html文件
balance roundrobin #负载均衡调度算法使用轮询算法roundrobin
server inst1 192.168.77.27:80 check inter 2000 fall 3 #定义在线节点
server inst2 192.168.77.28:80 check inter 2000 fall 3
4.haproxy システムサービスを追加する
cp /opt/haproxy-1.5.19/examples/haproxy.init /etc/init.d/haproxy
chmod +x haproxy
chkconfig --add /etc/init.d/haproxy
ln -s /usr/local/sbin/haproxy /usr/sbin/haproxy
service haproxy start 或 /etc/init.d/haproxy start
5. ノードサーバーの展開:
systemctl stop firewalld
setenforce 0
yum install -y pcre-devel zlib-devel gcc gcc-c++ make
useradd -M -s /sbin/nologin nginx
cd /opt
tar zxvf nginx-1.22.0.tar.gz -C /opt/
cd nginx-1.22.0/
./configure --prefix=/usr/local/nginx --user=nginx --group=nginx && make && make install
make && make install
--192.168.77.27---
echo "this is kgc web" > /usr/local/nginx/html/test.html
--192.168.77.28---
echo "this is benet web" > /usr/local/nginx/html/test.html
ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/
nginx #启动nginx 服务
他の操作は上記と同じです
--192.168.77.27---
--192.168.77.28---
6. ソフト接続を作成します (2 つのコマンドは同じです)。
7.nginxを起動する
8. Web クラスターのテスト
クライアント上のブラウザで http://192.168.77.26/test.html を開き、ブラウザを常に更新して負荷分散効果をテストします。
更新:
8. ログ定義(HAProxyがインストールされているサーバー上で設定)
vim /etc/haproxy/haproxy.cfg
global
log /dev/log local0 info
log /dev/log local0 notice
service haproxy restart #重启服务
#需要修改rsyslog配置,为了便于管理。将haproxy相关的配置独立定义到haproxy.conf,并放到/etc/rsyslog.d/下,rsyslog启动时会自动加载此目录下的所有配置文件。
vim /etc/rsyslog.d/haproxy.conf
if ($programname == 'haproxy' and $syslogseverity-text == 'info')
then -/var/log/haproxy/haproxy-info.log
&~
if ($programname == 'haproxy' and $syslogseverity-text == 'notice')
then -/var/log/haproxy/haproxy-notice.log
&~
#说明:
这部分配置是将haproxy的info日志记录到/var/log/haproxy/haproxy-info.log下,将notice日志记录到/var/log/haproxy/haproxy-notice.log下。“&~”表示当日志写入到日志文件后,rsyslog停止处理这个信息。
systemctl restart rsyslog.service
tail -f /var/log/haproxy/haproxy-info.log #查看haproxy的访问请求日志信息
分割されたログを表示します。
ここで報告されるエラーは、クライアントで 192.168.77.26/test.html を更新する必要があるというものです。