搭建web群集案例分析
常见的Web集群调度器
- 目前常见的Web集群调度器分为软件和硬件，软件通常使用开源的LVS、Haproxy、Nginx，硬件一般使用比较多的是F5，也有很多人使用国内的一些产品，如梭子鱼、绿盟等
Haproxy应用分析
- LVS在企业应用中抗负载能力很强，但存在不足
LVS不支持正则处理，不能实现动静分离
对于大型网站，LVS的实施配置复杂，维护成本相对较高- nginx的upstream模块支持群集功能，但是对群集节点的健康检查功能不强，性能没有Haproxy好
- Haproxy是一款可提供高可用性、负载均衡、及基于TCP和HTTP应用的代理的软件
特别适用于负载特别大的Web站点
运行在当前的硬件上可支持数以万计的并发连接连接请求
Haproxy官方网站http://www.haproxy.org/
负载均衡常用调度算法
LVS、Haproxy、Nginx最常用的调度算法有三种：
- RR（Round Robin）：RR算法是最简单最常用的一种算法，即轮询调度
举例理解：- 有三个节点A、B、C，第一个用户访问会被指派到节点A，第二个用户访问会被指派到节点B，第三个用户访问会被指派到节点
- 第四个用户访问继续指派到节点A，轮询分配访问请求实现负载均衡效果
- LC（Least Connections）：LC算法即最小连接数算法，根据后端的节点连接数大小动态分配前端请求
理解举例：- 有三个节点A、B、C，各节点的连接数分别为A:4、B:5、C:6，此时如果有第一个用户连接请求，会被指派到 A上，连接数变为A:5、B:5、C:6
- 第二个用户请求会继续分配到A上，连接数变为A:6、B:5、C:6；再有新的请求会分配给B，每次将新的请求指派给连接数最小的客户端
- 由于实际情况下A、B、C的连接数会动态释放，很难会出现一样连接数的情况，因此此算法相比较rr算法有很大改进，是目前用到比较多的一种算法
- SH（Source Hashing）：SH即基于来源访问调度算法，此算法用于一些有Session会话记录在服务器端的场景，可以基于来源的IP、Cookie等做集群调度
理解举例：- 有三个节点A、B、C，第一个用户第一次访问被指派到了A ，第二个用户第一次访问被指派到了B
- 当第一个用户第二次访问时会被继续指派到A，第二个用户第二次访问时依旧会被指派到B，只要负载均衡调度器不重启，第一个用户访问都会被指派到A，第二个用户访问都会被指派到B，实现集群的调度
- 此调度算法好处是实现会话保持，但某些IP访问量非常大时会引起负载不均衡，部分节点访问量超大，影响业务使用
新版本Haproxy
新版本采用Haproxy1.7.2，配置文件由旧版本的global、defaults、listen三部分改为global、defaults、listen、frontend、backend五部分组成，增加SSL支持、可定义ACL控制、根据不同策略由不同后端服务器做响应。
案例实施：使用Haproxy搭建Web群集
案例环境
- 使用一台物理机器，三台虚拟服务器模拟搭建一套web集群
- 虚拟机安装Centos7.5的64位系统
| 主机 | 操作系统 | IP地址 | 主要软件 |
|---|---|---|---|
| Haproxy服务器 | Centos7.5 | 192.168.137.90 | haproxy |
| Nginx服务器1 | Centos7.5 | 192.168.137.91 | nginx |
| Nginx服务器2 | Centos7.5 | 192.168.137.92 | Nginx |
| 客户端 | win10 | 192.168.137.1 | firefox浏览器 |
编译安装Nginx服务器
- 搭建Nginx1
使用nginx-1.12.2.tar.gz安装包进行编译安装
[root@localhost ~]# yum -y install pcre-devel zlib-devel gcc gcc-c++
安装依赖包
[root@localhost ~]# useradd -M -s /sbin/nologin nginx
创建nginx运行用户
[root@localhost ~]# tar -xzf nginx-1.12.2.tar.gz
[root@localhost ~]# cd nginx-1.12.2/
[root@localhost nginx-1.12.2]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx
[root@localhost nginx-1.12.2]# make && make install
安装后的默认信息如下：
- 默认安装目录：/usr/lcoal/nginx
- 默认日志：/usr/local/nginx/logs
- 默认监听端口：80
- 默认web目录：/usr/local/nginx/html
设置测试页面并启动Nginx服务
[root@localhost nginx-1.12.2]# cd /usr/local/nginx/html/
[root@localhost html]# echo '192.168.137.91' > test.html
[root@localhost html]# /usr/local/nginx/sbin/nginx
[root@localhost html]# netstat -antp | grep nginx
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6502/nginx: master
方便实验，直接使用IP地址访问。
- 搭建Nginx2
编译安装的步骤与Nginx1相同，不同之处在于建立测试页面
[root@localhost html]# echo '192.168.137.92' > test.html
访问http://192.168.137.92/test.html,测试正常
编译安装Haproxy
使用yum方式安装Haproxy即可，源码安装时需要注意Linux版本位宽（64bit还是32bit）
[root@localhost ~]# yum -y install haproxy
[root@localhost haproxy]# rpm -qc haproxy
/etc/haproxy/haproxy.cfg 主配置文件
...
Haproxy配置项介绍
Haproxy根据功能和用途通常分为五个部分，即global、defaults、listen、frontend和backend。但有些部分不是必需的，可以根据需要进行选择配置。
global配置
为设定的全局配置部分。属于进程级别的配置，通常和使用的操作系统配置相关。
global
log 127.0.0.1 local0 notice
#配置全局日志记录，local0为日志设备，默认存放到系统日志，notice为输出的日志级别
#表示使用本地（127.0.0.1）机器上的rsyslog服务中的local0设备记录日志等级为notice的日志
pidfile /var/run/haproxy.pid
#指定haproxy进程的pid文件，启动进程的用户需要有访问此文件的相关权限
maxconn 20000
#每个haproxy进程可以接受的最大并发连接数
user haproxy
group haproxy
#运行haproxy进程的用户和组，也可以使用uid和gid选项来指定用户和组的ID号来代替
nbproc 1
#设置haproxy的负载均衡的并发的进程数
daemon
#设置haproxy进程使用后台模式即守护进程方式运行，是推荐的运行模式
stats socket /var/lib/haproxy/stats
# 创建监控所用的套接字目录
defaults配置
为缺省默认配置部分。这些设置参数属于公告配置，一般会被自动继承到listen、frontend和backend中，如果没有在这几部分特别声明，将按默认配置参数设置。
defaults
mode http
#设置Haproxy默认运行方式，有tcp、http和health三种模式。
#tcp模式下客户端与服务端之间会建立全双工的连接，常用于SSL\SSH\SMTP等应用，也是这里的默认模式
#http模式下客户端请求在转发到后端服务器之前会进行分析，会把不兼容RFC格式的请求拒绝、
#health模式已经废弃不用
log global
#缺省日志配置，定义日志为global配置中定义的日志记录方式
option httplog
#表示采用http日志格式进行日志的记录，默认不记录http请求日志
option dontlognull
#启用该选项，日志中将不会记录空连接
option forwardfor except 127.0.0.0/8
#表示后端服务器日志中可获得并记录客户端的源IP地址信息
retries 3
#检查节点服务器失败次数，连接到达该失败次数则认为节点不可用。
timeout connect 10s
#连接超时时间，连接到一台服务器最长等待时间，默认单位为毫秒，也可以修改单位
timeout client 1m
#客户端超时时间，连接客户端发送数据时最长等待时间。默认单位为毫秒
timeout server 1m
#服务器超时时间，服务端回应客户端数据发送的最长等待时间，默认单位为毫秒
option httpclose
#表示客户端和服务端请求完毕后主动关闭http通道
listen配置
为应用组件配置部分，属于frontend和backend的结合体，在之前老版本中所有的配置项都在这一部分完成。为了保证配置的兼容性，这一部分被保留使用，也可以不添加此部分的设置，非必需。
示例：
listen stats
bind 0.0.0.0:8080
stats uri /stats
stats refresh 30s
stats realm Haproxy Manager
stats auth admin:admin
stats hide-version
stats admin if TRUE
这部分通过listen关键字，定义了一个名为‘stats’的Haproxy监控页面，监听端口为8080，指定‘stats uri/stats’设置统计页面url为 /stats,那么可以直接访问 IP地址:8080/stats 查看监控页面
选项含义如下：
- stats refresh：统计页面自动刷新时间
- stats realm：统计页面密码框上显示的文本
- stats auth：设置统计页面登录用户名和密码。用户名和密码通过冒号进行分割
- stats hide-versio：隐藏统计页面上的Haproxy版本信息
- stats admin if TRUE：添加此选项可在监控页面手动启用或禁用后端真实服务器，主要仅在Haproxy 1.4.9之后版本有效。
frontend配置
为前端配置部分。用于设置用户接收请求的前端虚拟节点及端口，可根据ACL规则直接指定要使用的后端服务器。
frontend main
#通过frontend关键字定义一个名为“main”的前端虚拟节点。
bind *:80
#用于定义监听端口，语法格式为bind[<address>:<prot_range>] interface <interface>,这里“*”表示监听当前所有IPV4地址，与“0.0.0.0”格式含义相同。
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js
#用来设置ACL规则策略，此处设置了url_path匹配.jpg .gif .png .css .js静态文件
use_backend static if url_static
#指定符合ACL策略的请求所访问的后端真实服务器池
default_backend app
#指定默认的后端真实服务器池，这些服务器将会在backend部分定义
backend配置
为后端服务器配置部分。此部分用于进行群集后端服务器的配置，即用来添加一组真实服务器处理前端用户请求。
backend static
balance roundrobin
server static 127.0.0.1:80 check
backend web
balance roundrobin
option redispatch
option abortonclose
option httpchk GET /index.html
option persist #强制将请求发送到已经down掉的服务器
server web1 192.168.137.91:80 check fall 3
server web2 192.168.137.92:80 check fall 3
- backend static：通过backend关键字定义了一个名为static的后端真实服务器池，使用了动静分离，如果url_path匹配.jgp、.gif、.png、.css、.js静态文件，则访问此后端
- backend web：定义了一个名为app的后端真实服务器池，用来指定默认的后端真实服务器池
- balance：负载均衡算法，常用的有：
roundrobin(简单轮询调度)、static-rr(基于权重的调度算法)、leastconn(最小连接数算法)、source(根据请求的源IP地址)、url(根据请求的URL)等 - server：用来定义多个真实的后端服务器池中的服务器，语法格式为：server < name > < address > [ :port ] [ param ]，其中name为服务器池指定的内部名称；address是服务器的IP地址或主机名；port为指定连接请求发往真实服务器时的目标端口，未指定则为客户端请求端口；
param为后端服务器设定的参数，常见的有check（健康检查）、inter（健康检查间隔时间，单位默认为ms）、rise（从故障状态到正常状态需要成功检查的次数）、fall(从正常状态到不可用状态需要重复检查的次数)、weight（服务器的权重）、backup（备份服务器） - option abortonclose：此参数可以在服务器负载很高的情况下，自动结束当前队列中处理时间比较长的连接。
- option redispatch：表示当使用了cookie时。Haproxy会将其请求的后端服务器的的serverID插入到cookie中，以保证会话的session持久性。一旦后端服务器出现故障，就会将客户请求强制定向到另外一个健康的后端服务器上，以保证服务的正常运行。
- option httpchk：启用HTTP服务状态监测，支持后端节点的健康检查，可以将故障节点上的服务迁移至其他健康节点，从而保证服务的可用性。语法格式为：option httpchk < method >、< url >、< version >，其中method表示http的请求方式，常用的有OPTIONS、GET、HEAD几种方式；url是要检测的URL地址，通过此地址获得后端服务器运行状态；version用来指定检测时的HTTP版本号。这里的OPTIONS httpchk GET 、index.html 表示检查服务器的index.html文件。
使用Haproxy配置web群集
global
log 127.0.0.1 local0 notice
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 20000
user haproxy
group haproxy
nbproc 1
daemon
stats socket /var/lib/haproxy/stats
defaults
mode http
log global
option httplog
option dontlognull
option httpclose
option forwardfor except 127.0.0.0/8
retries 3
timeout connect 10s
timeout client 1m
timeout server 1m
listen stats
bind 0.0.0.0:8080
stats uri /stats
stats refresh 30s
stats realm Haproxy Manager
stats auth admin:admin
stats hide-version
stats admin if TRUE
frontend main
bind *:80
default_backend web
backend web
balance roundrobin
server web1 192.168.137.91:80 check fall 3
server web2 192.168.137.92:80 check fall 3
测试Haproxy负载均衡功能
- 测试高性能
在客户端浏览器打开http://192.168.137.90/test.html
再打开一个新的页面访问http://192.168.137.90/test.html
可以看到群集的负载均衡调度已经生效，已经满足了群集的高性能需求。 - 测试高可用
将192.168.137.91的Nginx停用，在客户端使用浏览器打开http://192.168.137.90/test.html
从中可以看出，当一台节点出现故障，不会影响群集的使用，满足了群集的高可用性。
2540
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
