社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
负载均衡技术对于一个网站尤其是大型网站的web服务器集群来说是至关重要的！做好负载均衡架构，可以实现故障转移和高可用环境，避免单点故障，保证网站健康持续运行。关于负载均衡介绍，可以参考：linux负载均衡总结性说明（四层负载/七层负载）
由于业务扩展，网站的访问量不断加大，负载越来越高。现需要在web前端放置nginx负载均衡,同时结合keepalived对前端nginx实现HA高可用。1）nginx进程基于Master+Slave(worker)多进程模型，自身具有非常稳定的子进程管理功能。在Master进程分配模式下，Master进程永远不进行业务处理，只是进行任务分发，从而达到Master进程的存活高可靠性，Slave(worker)进程所有的业务信号都 由主进程发出，Slave(worker)进程所有的超时任务都会被Master中止，属于非阻塞式任务模型。2）Keepalived是Linux下面实现VRRP备份路由的高可靠性运行件。基于Keepalived设计的服务模式能够真正做到主服务器和备份服务器故障时IP瞬间无缝交接。二者结合，可以构架出比较稳定的软件LB方案。
Keepalived介绍：Keepalived是一个基于VRRP协议来实现的服务高可用方案，可以利用其来避免IP单点故障，类似的工具还有heartbeat、corosync、pacemaker。但是它一般不会单独出现，而是与其它负载均衡技术（如lvs、haproxy、nginx）一起工作来达到集群的高可用。
VRRP协议：VRRP全称 Virtual Router Redundancy Protocol，即 虚拟路由冗余协议。可以认为它是实现路由器高可用的容错协议，即将N台提供相同功能的路由器组成一个路由器组(Router Group)，这个组里面有一个master和多个backup，但在外界看来就像一台一样，构成虚拟路由器，拥有一个虚拟IP（vip，也就是路由器所在局域网内其他机器的默认路由），占有这个IP的master实际负责ARP相应和转发IP数据包，组中的其它路由器作为备份的角色处于待命状态。master会发组播消息，当backup在超时时间内收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，保证路由器的高可用。
在VRRP协议实现里，虚拟路由器使用 00-00-5E-00-01-XX 作为虚拟MAC地址，XX就是唯一的 VRID （Virtual Router IDentifier），这个地址同一时间只有一个物理路由器占用。在虚拟路由器里面的物理路由器组里面通过多播IP地址 224.0.0.18 来定时发送通告消息。每个Router都有一个 1-255 之间的优先级别，级别最高的（highest priority）将成为主控（master）路由器。通过降低master的优先权可以让处于backup状态的路由器抢占（pro-empt）主路由器的状态，两个backup优先级相同的IP地址较大者为master，接管虚拟IP。
[root@master-node ~]
user www;
worker_processes 8;
events {
worker_connections 65535;
}
http {
include mime.types;
default_type application
/octet-stream
;
charset utf-8;
log_format main
'$http_x_forwarded_for $remote_addr $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_cookie" $host $request_time'
;
#######
#######
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
proxy_cache_path
/var/www/cache
levels=1:2 keys_zone=mycache:20m max_size=2048m inactive=60m;
proxy_temp_path
/var/www/cache/tmp
;
fastcgi_connect_timeout 3000;
fastcgi_send_timeout 3000;
fastcgi_read_timeout 3000;
fastcgi_buffer_size 256k;
fastcgi_buffers 8 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;
client_header_timeout 600s;
client_body_timeout 600s;
client_max_body_size 100m;
client_body_buffer_size 256k;
gzip
on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 9;
gzip_types text
/plain
application
/x-javascript
text
/css
application
/xml
text
/javascript
application
/x-httpd-php
;
gzip_vary on;
include vhosts/*.conf;
}
[root@master-node ~]# mkdir /usr/local/nginx/conf/vhosts[root@master-node ~]# mkdir /var/www/cache[root@master-node ~]# ulimit 65535
[root@master-node ~]
upstream LB-WWW {
ip_hash;
server 192.168.1.101:80 max_fails=3 fail_timeout=30s;
server 192.168.1.102:80 max_fails=3 fail_timeout=30s;
server 192.168.1.118:80 max_fails=3 fail_timeout=30s;
}
upstream LB-OA {
ip_hash;
server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.102:8080 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
server_name dev.wangshibo.com;
access_log
/usr/local/nginx/logs/dev-access
.log main;
error_log
/usr/local/nginx/logs/dev-error
.log;
location
/svn
{
proxy_pass http:
//192
.168.1.108
/svn/
;
proxy_redirect off ;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 600;
proxy_buffer_size 256k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_cache mycache;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
}
location
/submin
{
proxy_pass http:
//192
.168.1.108
/submin/
;
proxy_redirect off ;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 600;
proxy_buffer_size 256k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_cache mycache;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
}
}
server {
listen 80;
server_name www.wangshibo.com;
access_log
/usr/local/nginx/logs/www-access
.log main;
error_log
/usr/local/nginx/logs/www-error
.log;
location / {
proxy_pass http:
//LB-WWW
;
proxy_redirect off ;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 600;
proxy_buffer_size 256k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_cache mycache;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
}
}
server {
listen 80;
server_name oa.wangshibo.com;
access_log
/usr/local/nginx/logs/oa-access
.log main;
error_log
/usr/local/nginx/logs/oa-error
.log;
location / {
proxy_pass http:
//LB-OA
;
proxy_redirect off ;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 600;
proxy_buffer_size 256k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_cache mycache;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
}
}
验证方法（保证从负载均衡器本机到后端真实服务器之间能正常通信）：1）首先在本机用IP访问上面LB.cong中配置的各个后端真实服务器的url2）然后在本机用域名和路径访问上面LB.cong中配置的各个后端真实服务器的域名/虚拟路径
----------------------------------------------------------------------------------------------------------------------------后端应用服务器的nginx配置，这里选择192.168.1.108作为例子进行说明由于这里的192.168.1.108机器是openstack的虚拟机，没有外网ip，不能解析域名。所以在server_name处也将ip加上，使得用ip也可以访问。[root@108-server ~]# cat /usr/local/nginx/conf/vhosts/svn.conf server {listen 80;#server_name dev.wangshibo.com;server_name dev.wangshibo.com 192.168.1.108;
access_log /usr/local/nginx/logs/dev.wangshibo-access.log main;error_log /usr/local/nginx/logs/dev.wangshibo-error.log;
location / {root /var/www/html;index index.html index.php index.htm;}}
[root@108-server ~]# ll /var/www/html/drwxr-xr-x. 2 www www 4096 Dec 7 01:46 submindrwxr-xr-x. 2 www www 4096 Dec 7 01:45 svn[root@108-server ~]# cat /var/www/html/svn/index.htmlthis is the page of svn/192.168.1.108[root@108-server ~]# cat /var/www/html/submin/index.htmlthis is the page of submin/192.168.1.108
[root@108-server ~]# cat /etc/hosts127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6192.168.1.108 dev.wangshibo.com
[root@108-server ~]# curl http://dev.wangshibo.com //由于是内网机器不能联网，亦不能解析域名。所以用域名访问没有反应。只能用ip访问[root@ops-server4 vhosts]# curl http://192.168.1.108this is 192.168.1.108 page!!![root@ops-server4 vhosts]# curl http://192.168.1.108/svn/ //最后一个/符号要加上，否则访问不了。this is the page of svn/192.168.1.108[root@ops-server4 vhosts]# curl http://192.168.1.108/submin/this is the page of submin/192.168.1.108----------------------------------------------------------------------------------------------------------------------------
然后在master-node和slave-node两台负载机器上进行测试（iptables防火墙要开通80端口）：[root@master-node ~]# curl http://192.168.1.108/svn/this is the page of svn/192.168.1.108[root@master-node ~]# curl http://192.168.1.108/submin/this is the page of submin/192.168.1.108
浏览器访问：在本机host绑定dev.wangshibo.com，如下，即绑定到master和slave机器的公网ip上测试是否能正常访问（nginx+keepalive环境正式完成后，域名解析到的真正地址是VIP地址）103.110.98.14 dev.wangshibo.com103.110.98.24 dev.wangshibo.com
! Configuration File
for
keepalived
global_defs {
notification_email {
}
notification_email_from ops@wangshibo.cn
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id master-node
}
vrrp_script chk_http_port {
script
"/opt/chk_nginx.sh"
interval 2
weight -5
fall 2
rise 1
}
vrrp_instance VI_1 {
state MASTER
interface em1
mcast_src_ip 103.110.98.14
virtual_router_id 51
priority 101
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
103.110.98.20
}
track_script {
chk_http_port
}
}
2）slave-node负载机上的keepalived配置[root@slave-node ~]# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak[root@slave-node ~]# vim /etc/keepalived/keepalived.conf
! Configuration File
for
keepalived
global_defs {
notification_email {
}
notification_email_from ops@wangshibo.cn
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id slave-node
}
vrrp_script chk_http_port {
script
"/opt/chk_nginx.sh"
interval 2
weight -5
fall 2
rise 1
}
vrrp_instance VI_1 {
state BACKUP
interface em1
mcast_src_ip 103.110.98.24
virtual_router_id 51
priority 99
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
103.110.98.20
}
track_script {
chk_http_port
}
}
让keepalived监控NginX的状态：1）经过前面的配置，如果master主服务器的keepalived停止服务，slave从服务器会自动接管VIP对外服务；一旦主服务器的keepalived恢复，会重新接管VIP。 但这并不是我们需要的，我们需要的是当NginX停止服务的时候能够自动切换。2）keepalived支持配置监控脚本，我们可以通过脚本监控NginX的状态，如果状态不正常则进行一系列的操作，最终仍不能恢复NginX则杀掉keepalived，使得从服务器能够接管服务。
如何监控NginX的状态最简单的做法是监控NginX进程，更靠谱的做法是检查NginX端口，最靠谱的做法是检查多个url能否获取到页面。
注意：这里要提示一下keepalived.conf中vrrp_script配置区的script一般有2种写法：1）通过脚本执行的返回结果，改变优先级，keepalived继续发送通告消息，backup比较优先级再决定。这是直接监控Nginx进程的方式。2）脚本里面检测到异常，直接关闭keepalived进程，backup机器接收不到advertisement会抢占IP。这是检查NginX端口的方式。上文script配置部分，"killall -0 nginx"属于第1种情况，"/opt/chk_nginx.sh" 属于第2种情况。个人更倾向于通过shell脚本判断，但有异常时exit 1，正常退出exit 0，然后keepalived根据动态调整的 vrrp_instance 优先级选举决定是否抢占VIP：如果脚本执行结果为0，并且weight配置的值大于0，则优先级相应的增加如果脚本执行结果非0，并且weight配置的值小于0，则优先级相应的减少其他情况，原本配置的优先级不变，即配置文件中priority对应的值。
提示：优先级不会不断的提高或者降低可以编写多个检测脚本并为每个检测脚本设置不同的weight（在配置中列出就行）不管提高优先级还是降低优先级，最终优先级的范围是在[1,254]，不会出现优先级小于等于0或者优先级大于等于255的情况在MASTER节点的 vrrp_instance 中 配置 nopreempt ，当它异常恢复后，即使它 prio 更高也不会抢占，这样可以避免正常情况下做无谓的切换以上可以做到利用脚本检测业务进程的状态，并动态调整优先级从而实现主备切换。
另外：在默认的keepalive.conf里面还有 virtual_server,real_server 这样的配置，我们这用不到，它是为lvs准备的。
如何尝试恢复服务由于keepalived只检测本机和他机keepalived是否正常并实现VIP的漂移，而如果本机nginx出现故障不会则不会漂移VIP。所以编写脚本来判断本机nginx是否正常，如果发现NginX不正常，重启之。等待3秒再次校验，仍然失败则不再尝试，关闭keepalived，其他主机此时会接管VIP；
根据上述策略很容易写出监控脚本。此脚本必须在keepalived服务运行的前提下才有效！如果在keepalived服务先关闭的情况下，那么nginx服务关闭后就不能实现自启动了。该脚本检测ngnix的运行状态，并在nginx进程不存在时尝试重新启动ngnix，如果启动失败则停止keepalived，准备让其它机器接管。监控脚本如下（master和slave都要有这个监控脚本）：[root@master-node ~]# vim /opt/chk_nginx.sh
counter=$(
ps
-C nginx --no-heading|
wc
-l)
if
[
"${counter}"
=
"0"
];
then
/usr/local/nginx/sbin/nginx
sleep
2
counter=$(
ps
-C nginx --no-heading|
wc
-l)
if
[
"${counter}"
=
"0"
];
then
/etc/init
.d
/keepalived
stop
fi
fi
[root@master-node ~]# chmod 755 /opt/chk_nginx.sh[root@master-node ~]# sh /opt/chk_nginx.sh80/tcp open http
此架构需考虑的问题1）master没挂，则master占有vip且nginx运行在master上2）master挂了，则slave抢占vip且在slave上运行nginx服务3）如果master上的nginx服务挂了，则nginx会自动重启，重启失败后会自动关闭keepalived，这样vip资源也会转移到slave上。4）检测后端服务器的健康状态5）master和slave两边都开启nginx服务，无论master还是slave，当其中的一个keepalived服务停止后，vip都会漂移到keepalived服务还在的节点上；如果要想使nginx服务挂了，vip也漂移到另一个节点，则必须用脚本或者在配置文件里面用shell命令来控制。（nginx服务宕停后会自动启动，启动失败后会强制关闭keepalived，从而致使vip资源漂移到另一台机器上）
最后验证（将配置的后端应用域名都解析到VIP地址上）：关闭主服务器上的keepalived或nginx，vip都会自动飘到从服务器上。验证keepalived服务故障情况：1）先后在master、slave服务器上启动nginx和keepalived，保证这两个服务都正常开启:[root@master-node ~]# /usr/local/nginx/sbin/nginx [root@master-node ~]# /etc/init.d/keepalived start[root@slave-node ~]# /usr/local/nginx/sbin/nginx [root@slave-node ~]# /etc/init.d/keepalived start2）在主服务器上查看是否已经绑定了虚拟IP： [root@master-node ~]# ip addr.......2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000link/ether 44:a8:42:17:3d:dd brd ff:ff:ff:ff:ff:ffinet 103.110.98.14/26 brd 103.10.86.63 scope global em1valid_lft forever preferred_lft foreverinet 103.110.98.20/32 scope global em1valid_lft forever preferred_lft foreverinet 103.110.98.20/26 brd 103.10.86.63 scope global secondary em1:0valid_lft forever preferred_lft foreverinet6 fe80::46a8:42ff:fe17:3ddd/64 scope link valid_lft forever preferred_lft forever......3）停止主服务器上的keepalived: [root@master-node ~]# /etc/init.d/keepalived stop Stopping keepalived (via systemctl): [ OK ][root@master-node ~]# /etc/init.d/keepalived status[root@master-node ~]# ps -ef|grep keepalivedroot 26952 24348 0 17:49 pts/0 00:00:00 grep --color=auto keepalived[root@master-node ~]# 4）然后在从服务器上查看，发现已经接管了VIP：[root@slave-node ~]# ip addr.......2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000link/ether 44:a8:42:17:3c:a5 brd ff:ff:ff:ff:ff:ffinet 103.110.98.24/26 brd 103.10.86.63 scope global em1inet 103.110.98.20/32 scope global em1inet6 fe80::46a8:42ff:fe17:3ca5/64 scope link valid_lft forever preferred_lft forever.......发现master的keepalived服务挂了后，vip资源自动漂移到slave上，并且网站正常访问，丝毫没有受到影响！5）重新启动主服务器上的keepalived，发现主服务器又重新接管了VIP，此时slave机器上的VIP已经不在了。[root@master-node ~]# /etc/init.d/keepalived startStarting keepalived (via systemctl): [ OK ][root@master-node ~]# ip addr.......2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000link/ether 44:a8:42:17:3d:dd brd ff:ff:ff:ff:ff:ffinet 103.110.98.14/26 brd 103.10.86.63 scope global em1valid_lft forever preferred_lft foreverinet 103.110.98.20/32 scope global em1valid_lft forever preferred_lft foreverinet 103.110.98.20/26 brd 103.10.86.63 scope global secondary em1:0valid_lft forever preferred_lft foreverinet6 fe80::46a8:42ff:fe17:3ddd/64 scope link valid_lft forever preferred_lft forever......
[root@slave-node ~]# ip addr.......2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000link/ether 44:a8:42:17:3c:a5 brd ff:ff:ff:ff:ff:ffinet 103.110.98.24/26 brd 103.10.86.63 scope global em1inet6 fe80::46a8:42ff:fe17:3ca5/64 scope link valid_lft forever preferred_lft forever
接着验证下nginx服务故障，看看keepalived监控nginx状态的脚本是否正常？如下：手动关闭master机器上的nginx服务，最多2秒钟后就会自动起来（因为keepalive监控nginx状态的脚本执行间隔时间为2秒）。域名访问几乎不受影响！[root@master-node ~]# /usr/local/nginx/sbin/nginx -s stop[root@master-node ~]# ps -ef|grep nginxroot 28401 24826 0 19:43 pts/1 00:00:00 grep --color=auto nginx[root@master-node ~]# ps -ef|grep nginxroot 28871 28870 0 19:47 ? 00:00:00 /bin/sh /opt/chk_nginx.shroot 28875 24826 0 19:47 pts/1 00:00:00 grep --color=auto nginx[root@master-node ~]# ps -ef|grep nginxroot 28408 1 0 19:43 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginxwww 28410 28408 0 19:43 ? 00:00:00 nginx: worker processwww 28411 28408 0 19:43 ? 00:00:00 nginx: worker processwww 28412 28408 0 19:43 ? 00:00:00 nginx: worker processwww 28413 28408 0 19:43 ? 00:00:00 nginx: worker process
最后可以查看两台服务器上的/var/log/messages，观察VRRP日志信息的vip漂移情况~~~~
***************当你发现自己的才华撑不起野心时，就请安静下来学习吧***************
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
