>##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 50m;
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;
## includes vhosts
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 ~]# vim /usr/local/nginx/conf/f
upstream LB-WWW {
ip_hash;
server 192.168.1.101:80 max_fails=3 fail_timeout=30s; #max_fails = 3 为允许失败的次数，默认值为1
server 192.168.1.102:80 max_fails=3 fail_timeout=30s; #fail_timeout = 30s 当max_fails次失败后，暂停将请求分发到该后端服务器的时间 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;
access_log /usr/local/nginx/logs/dev-access.log main;
error_log /usr/local/nginx/logs/dev-error.log;
location /svn {
proxy_pass 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; #代理请求缓冲区，会保存⽤户的头信息以供nginx进⾏处理
proxy_buffers 4 256k; #同上，告诉nginx保存单个⽤⼏个buffer最⼤⽤多少空间
proxy_busy_buffers_size 256k; #如果系统很忙时候可以申请最⼤的proxy_buffers
proxy_temp_file_write_size 256k; #proxy缓存临时⽂件的⼤⼩
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 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;
access_log /usr/local/nginx/logs/www-access.log main;
error_log /usr/local/nginx/logs/www-error.log;
location / {
proxy_pass 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;
access_log /usr/local/nginx/logs/oa-access.log main;
error_log /usr/local/nginx/logs/oa-error.log;
location / {
proxy_pass 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中配置的各个后端真实服务器的url
2）然后在本机⽤域名和路径访问上⾯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/f
server {
listen 80;
#server_name dev.wangshibo;
server_name dev.wangshibo 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;
}twamp
}
[root@108-server ~]# ll /var/www/html/
drwxr-xr-x. 2 www www 4096 Dec 7 01:46 submin自动杀菌净手器
drwxr-xr-x. 2 www www 4096 Dec 7 01:45 svn
[root@108-server ~]# cat /var/www/html/svn/index.html
this is the page of svn/192.168.1.108
[root@108-server ~]# cat /var/www/html/submin/index.html
this is the page of submin/192.168.1.108
[root@108-server ~]# cat /etc/hosts
巧克力喷泉机127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.108 dev.wangshibo
浏览器访问：
在本机host绑定dev.wangshibo，如下，即绑定到master和slave机器的公⽹ip上测试是否能正常访问（nginx+keepalive环境正式完成后，域名解析到的真正地址是VIP地址）
103.110.98.14 dev.wangshibo
103.110.98.24 dev.wangshibo
2.keepalived配置
1）master-node负载机上的keepalived配置（sendmail部署可以参考：）
[root@master-node ~]# cp /etc/f /etc/f.bak
[root@master-node ~]# vim /etc/f
! Configuration File for keepalived #全局定义
global_defs {
notification_email { #指定keepalived在发⽣事件时(⽐如切换)发送通知邮件的邮箱
ops@wangshibo #设置报警邮件地址，可以设置多个，每⾏⼀个。需开启本机的sendmail服务
tech@wangshibo
}
notification_email_from ops@wangshibo #keepalived在发⽣诸如切换操作时需要发送email通知地址
smtp_server 127.0.0.1 #指定发送email的smtp服务器
smtp_connect_timeout 30 #设置连接smtp server的超时时间
router_id master-node #运⾏keepalived的机器的⼀个标识，通常可设为hostname。故障发⽣时，发邮件时显⽰在邮件主题中的信息。
}
vrrp_script chk_http_port { #检测nginx服务是否在运⾏。有很多⽅式，⽐如进程，⽤脚本检测等等 script "/opt/chk_nginx.sh" #这⾥通过脚本监测
interval 2 #脚本执⾏间隔，每2s检测⼀次
weight -5 #脚本结果导致的优先级变更，检测失败（脚本返回⾮0）则优先级 -5
fall 2 #检测连续2次失败才算确定是真失败。会⽤weight减少优先级（1-255之间）
rise 1 #检测1次成功就算成功。但不修改优先级
}
vrrp_instance VI_1 { #keepalived在同⼀virtual_router_id中priority（0-255）最⼤的会成为master，也就是接管VIP，当priority最⼤的主机发⽣故障后次priority将会接管
state MASTER #指定keepalived的⾓⾊，MASTER表⽰此主机是主服务器，BACKUP表⽰此主机是备⽤服务器。注意这⾥的state指定instance(Initial)的初始状态，就是说在配置好后，这台服务器的初
始状态就是这⾥指定的，但这⾥指定的不算 interface em1 #指定HA监测⽹络的接⼝。实例绑定的⽹卡，因为在配置虚拟IP的时候必须是在已有的⽹卡上添加的
mcast_src_ip 103.110.98.14 # 发送多播数据包时的源IP地址，这⾥注意了，这⾥实际上就是在哪个地址上发送VRRP通告，这个⾮常重要，⼀定要选择稳定的⽹卡端⼝来发送，这⾥相当于heartbeat的⼼跳端⼝，如果没有设置那么就⽤默认的绑定 virtual_router_id 51 #虚拟路由标识，这个标识是⼀个数字，同⼀个vrrp实例使⽤唯⼀的标识。即同⼀vrrp_instance下，MASTER和BACKUP必须是⼀致的
priority 101 #定义优先级，数字越⼤，优先级越⾼，在同⼀个vrrp_instance下，MASTER的优先级必须⼤于BACKUP的优先级
advert_int 1 #设定MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒
authentication { #设置验证类型和密码。主从必须⼀样
auth_type PASS #设置vrrp验证类型，主要有PASS和AH两种
auth_pass 1111 #设置vrrp验证密码，在同⼀个vrrp_instance下，MASTER与BACKUP必须使⽤相同的密码才能正常通信
}
virtual_ipaddress { #VRRP HA 虚拟地址如果有多个VIP，继续换⾏填写
103.110.98.20
}
track_script { #执⾏监控的服务。注意这个设置不能紧挨着写在vrrp_script配置块的后⾯（实验中碰过的坑），否则nginx监控失效！！
chk_http_port #引⽤VRRP脚本，即在 vrrp_script 部分指定的名字。定期运⾏它们来改变优先级，并最终引发主备切换。
}
}
2）slave-node负载机上的keepalived配置
[root@slave-node ~]# cp /etc/f /etc/f.bak
[root@slave-node ~]# vim /etc/f
! Configuration File for keepalived
global_defs {
notification_email {
ops@wangshibo
tech@wangshibo
}
notification_email_from ops@wangshibo
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能否获取到页⾯。
注意：这⾥要提⽰⼀下f中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 更⾼也不会抢占，这样可以避免正常情况下做⽆谓的切换
以上可以做到利⽤脚本检测业务进程的状态，并动态调整优先级从⽽实现主备切换。
另外：在默认的f⾥⾯还有 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
#!/bin/bash
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.sh
80/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 start
2）在主服务器上查看是否已经绑定了虚拟IP：
[root@master-node ~]# ip addr
.......
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 44:a8:42:17:3d:dd brd ff:ff:ff:ff:ff:ff
inet 103.110.98.14/26 brd 103.10.86.63 scope global em1
valid_lft forever preferred_lft forever
inet 103.110.98.20/32 scope global em1
valid_lft forever preferred_lft forever
inet 103.110.98.20/26 brd 103.10.86.63 scope global secondary em1:0
valid_lft forever preferred_lft forever
inet6 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 keepalived
root 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 1000
link/ether 44:a8:42:17:3c:a5 brd ff:ff:ff:ff:ff:ff
inet 103.110.98.24/26 brd 103.10.86.63 scope global em1
inet 103.110.98.20/32 scope global em1
inet6 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 start
Starting keepalived (via systemctl): [ OK ]
[root@master-node ~]# ip addr
.......
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
纸制品加工link/ether 44:a8:42:17:3d:dd brd ff:ff:ff:ff:ff:ff
inet 103.110.98.14/26 brd 103.10.86.63 scope global em1
valid_lft forever preferred_lft forever
inet 103.110.98.20/32 scope global em1
valid_lft forever preferred_lft forever
inet 103.110.98.20/26 brd 103.10.86.63 scope global secondary em1:0
valid_lft forever preferred_lft forever
inet6 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 1000
link/ether 44:a8:42:17:3c:a5 brd ff:ff:ff:ff:ff:ff
inet 103.110.98.24/26 brd 103.10.86.63 scope global em1
inet6 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 nginx
root 28401 24826 0 19:43 pts/1 00:00:00 grep --color=auto nginx
[root@master-node ~]# ps -ef|grep nginx
root 28871 28870 0 19:47 ? 00:00:00 /bin/sh /opt/chk_nginx.sh
root 28875 24826 0 19:47 pts/1 00:00:00 grep --color=auto nginx
[root@master-node ~]# ps -ef|grep nginx
root 28408 1 0 19:43 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议