phpempt技巧_若何基于搭建NginxKeepalived双机热备情形

也有不幼年伙伴让我更新一篇基于主从模式搭建Nginx+Keepalived双机热备的环境，怎么办呢？那必须安排上啊！
不多说了，我们直接进入正文。

负载均衡技能对付一个网站尤其是大型网站的web做事器集群来说是至关主要的！
做好负载均衡架构，可以实现故障转移和高可用环境，避免单点故障，担保网站康健持续运行。

由于业务扩展，网站的访问量不断加大，负载越来越高。
现须要在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是一个基于VRRP协议来实现的做事高可用方案，可以利用其来避免IP单点故障，类似的工具还有heartbeat、corosync、pacemaker。
但是它一样平常不会单独涌现，而是与其它负载均衡技能（如lvs、haproxy、nginx）一起事情来达到集群的高可用。

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。

keepalived与heartbeat/corosync等比较

Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好呢？

首先要解释的是，Heartbeat、Corosync是属于同一类型，Keepalived与Heartbeat、Corosync，根本不是同一类型的。
Keepalived利用的vrrp协议办法，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)； Heartbeat或Corosync是基于主机或网络做事的高可用办法；

大略的说便是，Keepalived的目的是仿照路由器的高可用，Heartbeat或Corosync的目的是实现Service的高可用。
以是一样平常Keepalived是实现前端高可用，常用的前端高可用的组合有，便是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。
而Heartbeat或Corosync是实现做事的高可用，常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web做事器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL做事器的高可用。

总结一下，Keepalived中实现轻量级的高可用，一样平常用于前端高可用，且不须要共享存储，一样平常常用于两个节点的高可用。
而Heartbeat(或Corosync)一样平常用于做事的高可用，且须要共享存储，一样平常用于多节点的高可用。
这个问题我们解释白了。

那heartbaet与corosync又该当选择哪个好？

一样平常用corosync，由于corosync的运行机制更优于heartbeat，就连从heartbeat分离出来的pacemaker都说在往后的开拓当中更方向于corosync，以是现在corosync+pacemaker是最佳组合。

双机高可用一样平常是通过虚拟IP（飘移IP）方法来实现的，基于Linux/Unix的IP别名技能。

双机高可用方法目前分为两种：

1）双机主从模式：即前端利用两台做事器，一台主理事器和一台热备做事器，正常情形下，主理事器绑定一个公网虚拟IP，供应负载均衡做事，热备做事器处于空闲状态；当主理事器发生故障时，热备做事器接管主理事器的公网虚拟IP，供应负载均衡做事；但是热备做事器在主机器不涌现故障的时候，永久处于摧残浪费蹂躏状态，对付做事器不多的网站，该方案不经济实惠。

2）双机主主模式：即前端利用两台负载均衡做事器，互为主备，且都处于活动状态，同时各自绑定一个公网虚拟IP，供应负载均衡做事；当个中一台发生故障时，另一台接管发生故障做事器的公网虚拟IP（这时由非故障机器一台包袱所有的要求）。
这种方案，经济实惠，非常适宜于当前架构环境。

本日在此分享下Nginx+keepalived实现高可用负载均衡的主从模式的操作记录：

keepalived可以认为是VRRP协议在Linux上的实现，紧张有三个模块，分别是core、check和vrrp。

操作系统：centos6.8，64位 master机器（master-node）：103.110.98.14/192.168.1.14 slave机器（slave-node）：103.110.98.24/192.168.1.24 公用的虚拟IP（VIP）：103.110.98.20 //负载均衡器上配置的域名都解析到这个VIP上

安装nginx和keepalive做事（master-node和slave-node两台做事器上的安装操作完备一样）。

安装依赖

[root@master-node~]#yum-yinstallgccpcre-develzlib-developenssl-devel

大家可以到链接：https://download.csdn.net/download/l1028386804/10376846下载nginx1.9.7+keepalive1.3.2，也可以将nginx.1.9.7更新为nginx1.19.2。
nginx1.19.2与nginx1.9.7的安装办法相同，这里我以nginx1.9.7为例进行安装。

[root@master-node~]#cd/usr/local/src/[root@master-nodesrc]#wgethttp://nginx.org/download/nginx-1.9.7.tar.gz[root@master-nodesrc]#wgethttp://www.keepalived.org/software/keepalived-1.3.2.tar.gz

安装nginx

[root@master-nodesrc]#tar-zvxfnginx-1.9.7.tar.gz[root@master-nodesrc]#cdnginx-1.9.7

添加www用户，个中-M参数表示不添加用户家目录，-s参数表示指定shell类型

[root@master-nodenginx-1.9.7]#useraddwww-M-s/sbin/nologin[root@master-nodenginx-1.9.7]#vimauto/cc/gcc#将这句注释掉取消Debug编译模式大概在179行#CFLAGS="$CFLAGS-g"[root@master-nodenginx-1.9.7]#./configure--prefix=/usr/local/nginx--user=www--group=www--with-http_ssl_module--with-http_flv_module--with-http_stub_status_module--with-http_gzip_static_module--with-pcre[root@master-nodenginx-1.9.7]#make&&makeinstall

安装keepalived

[root@master-nodesrc]#tar-zvxfkeepalived-1.3.2.tar.gz[root@master-nodesrc]#cdkeepalived-1.3.2[root@master-nodekeepalived-1.3.2]#./configure[root@master-nodekeepalived-1.3.2]#make&&makeinstall[root@master-nodekeepalived-1.3.2]#cp/usr/local/src/keepalived-1.3.2/keepalived/etc/init.d/keepalived/etc/rc.d/init.d/[root@master-nodekeepalived-1.3.2]#cp/usr/local/etc/sysconfig/keepalived/etc/sysconfig/[root@master-nodekeepalived-1.3.2]#mkdir/etc/keepalived[root@master-nodekeepalived-1.3.2]#cp/usr/local/etc/keepalived/keepalived.conf/etc/keepalived/[root@master-nodekeepalived-1.3.2]#cp/usr/local/sbin/keepalived/usr/sbin/

将nginx和keepalive做事加入开机启动做事

[root@master-nodekeepalived-1.3.2]#echo"/usr/local/nginx/sbin/nginx">>/etc/rc.local[root@master-nodekeepalived-1.3.2]#echo"/etc/init.d/keepalivedstart">>/etc/rc.local配置做事

先关闭SElinux、配置防火墙 （master和slave两台负载均衡机都要做）

[root@master-node~]#vim/etc/sysconfig/selinux#SELINUX=enforcing#注释掉#SELINUXTYPE=targeted#注释掉SELINUX=disabled#增加[root@master-node~]#setenforce0#使配置立即生效[root@master-node~]#vim/etc/sysconfig/iptables.......-AINPUT-s103.110.98.0/24-d224.0.0.18-jACCEPT#许可组播地址通信-AINPUT-s192.168.1.0/24-d224.0.0.18-jACCEPT-AINPUT-s103.110.98.0/24-pvrrp-jACCEPT#许可VRRP（虚拟路由器冗余协）通信-AINPUT-s192.168.1.0/24-pvrrp-jACCEPT-AINPUT-ptcp-mstate--stateNEW-mtcp--dport80-jACCEPT#开通80端口访问[root@master-node~]#/etc/init.d/iptablesrestart#重启防火墙使配置生效配置nginx

master-node和slave-node两台做事器的nginx的配置完备一样,紧张是配置/usr/local/nginx/conf/nginx.conf的http，当然也可以配置vhost虚拟主机目录，然后配置vhost下的比如LB.conf文件。

个中: 多域名指向是通过虚拟主机（配置http下面的server）实现; 同一域名的不同虚拟目录通过每个server下面的不同location实现; 到后真个做事器在vhost/LB.conf下面配置upstream,然后在server或location中通过proxy_pass引用。

要实现前面方案的接入办法，LB.conf的配置如下（添加proxy_cache_path和proxy_temp_path这两行，表示打开nginx的缓存功能）

[root@master-node~]#vim/usr/local/nginx/conf/nginx.confuserwww;worker_processes8;#error_loglogs/error.log;#error_loglogs/error.lognotice;#error_loglogs/error.loginfo;#pidlogs/nginx.pid;events{worker_connections65535;}http{includemime.types;default_typeapplication/octet-stream;charsetutf-8;########setaccesslogformat######log_formatmain'$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';#########httpsetting#######sendfileon;tcp_nopushon;tcp_nodelayon;keepalive_timeout65;proxy_cache_path/var/www/cachelevels=1:2keys_zone=mycache:20mmax_size=2048minactive=60m;proxy_temp_path/var/www/cache/tmp;fastcgi_connect_timeout3000;fastcgi_send_timeout3000;fastcgi_read_timeout3000;fastcgi_buffer_size256k;fastcgi_buffers8256k;fastcgi_busy_buffers_size256k;fastcgi_temp_file_write_size256k;fastcgi_intercept_errorson;#client_header_timeout600s;client_body_timeout600s;#client_max_body_size50m;client_max_body_size100m;#许可客户端要求的最大单个文件字节数client_body_buffer_size256k;#缓冲区代理缓要冲求的最大字节数，可以理解为先保存到本地再传给用户gzipon;gzip_min_length1k;gzip_buffers416k;gzip_http_version1.1;gzip_comp_level9;gzip_typestext/plainapplication/x-javascripttext/cssapplication/xmltext/javascriptapplication/x-httpd-php;gzip_varyon;##includesvhostsincludevhosts/.conf;}

[root@master-node~]#mkdir/usr/local/nginx/conf/vhosts[root@master-node~]#mkdir/var/www/cache[root@master-node~]#ulimit65535

[root@master-node~]#vim/usr/local/nginx/conf/vhosts/LB.confupstreamLB-WWW{ip_hash;server192.168.1.101:80max_fails=3fail_timeout=30s;#max_fails=3为许可失落败的次数，默认值为1server192.168.1.102:80max_fails=3fail_timeout=30s;#fail_timeout=30s当max_fails次失落败后，停息将要求分发到该后端做事器的韶光server192.168.1.118:80max_fails=3fail_timeout=30s;}upstreamLB-OA{ip_hash;server192.168.1.101:8080max_fails=3fail_timeout=30s;server192.168.1.102:8080max_fails=3fail_timeout=30s;}server{listen80;server_namedev.wangshibo.com;access_log/usr/local/nginx/logs/dev-access.logmain;error_log/usr/local/nginx/logs/dev-error.log;location/svn{proxy_passhttp://192.168.1.108/svn/;proxy_redirectoff;proxy_set_headerHost$host;proxy_set_headerX-Real-IP$remote_addr;proxy_set_headerREMOTE-HOST$remote_addr;proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;proxy_connect_timeout300;#跟后端做事器连接超时时间，发起握手期待相应韶光proxy_send_timeout300;#后端做事器回传韶光，便是在规定韶光内后端做事器必须传完所有数据proxy_read_timeout600;#连接成功后等待后端做事器的相应韶光，已经进入后真个排队之中期待处理proxy_buffer_size256k;#代理要求缓冲区,会保存用户的头信息以供nginx进行处理proxy_buffers4256k;#同上，见告nginx保存单个用几个buffer最大用多少空间proxy_busy_buffers_size256k;#如果系统很忙时候可以申请最大的proxy_buffersproxy_temp_file_write_size256k;#proxy缓存临时文件的大小proxy_next_upstreamerrortimeoutinvalid_headerhttp_500http_503http_404;proxy_max_temp_file_size128m;proxy_cachemycache;proxy_cache_valid20030260m;proxy_cache_valid4041m;}location/submin{proxy_passhttp://192.168.1.108/submin/;proxy_redirectoff;proxy_set_headerHost$host;proxy_set_headerX-Real-IP$remote_addr;proxy_set_headerREMOTE-HOST$remote_addr;proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;proxy_connect_timeout300;proxy_send_timeout300;proxy_read_timeout600;proxy_buffer_size256k;proxy_buffers4256k;proxy_busy_buffers_size256k;proxy_temp_file_write_size256k;proxy_next_upstreamerrortimeoutinvalid_headerhttp_500http_503http_404;proxy_max_temp_file_size128m;proxy_cachemycache;proxy_cache_valid20030260m;proxy_cache_valid4041m;}}server{listen80;server_namewww.wangshibo.com;access_log/usr/local/nginx/logs/www-access.logmain;error_log/usr/local/nginx/logs/www-error.log;location/{proxy_passhttp://LB-WWW;proxy_redirectoff;proxy_set_headerHost$host;proxy_set_headerX-Real-IP$remote_addr;proxy_set_headerREMOTE-HOST$remote_addr;proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;proxy_connect_timeout300;proxy_send_timeout300;proxy_read_timeout600;proxy_buffer_size256k;proxy_buffers4256k;proxy_busy_buffers_size256k;proxy_temp_file_write_size256k;proxy_next_upstreamerrortimeoutinvalid_headerhttp_500http_503http_404;proxy_max_temp_file_size128m;proxy_cachemycache;proxy_cache_valid20030260m;proxy_cache_valid4041m;}}server{listen80;server_nameoa.wangshibo.com;access_log/usr/local/nginx/logs/oa-access.logmain;error_log/usr/local/nginx/logs/oa-error.log;location/{proxy_passhttp://LB-OA;proxy_redirectoff;proxy_set_headerHost$host;proxy_set_headerX-Real-IP$remote_addr;proxy_set_headerREMOTE-HOST$remote_addr;proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;proxy_connect_timeout300;proxy_send_timeout300;proxy_read_timeout600;proxy_buffer_size256k;proxy_buffers4256k;proxy_busy_buffers_size256k;proxy_temp_file_write_size256k;proxy_next_upstreamerrortimeoutinvalid_headerhttp_500http_503http_404;proxy_max_temp_file_size128m;proxy_cachemycache;proxy_cache_valid20030260m;proxy_cache_valid4041m;}}验证Nginx配置

验证方法（担保从负载均衡器本机到后端真实做事器之间能正常通信）： 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/vhosts/svn.confserver{listen80;#server_namedev.wangshibo.com;server_namedev.wangshibo.com192.168.1.108;access_log/usr/local/nginx/logs/dev.wangshibo-access.logmain;error_log/usr/local/nginx/logs/dev.wangshibo-error.log;location/{root/var/www/html;indexindex.htmlindex.phpindex.htm;}}[root@108-server~]#ll/var/www/html/drwxr-xr-x.2wwwwww4096Dec701:46submindrwxr-xr-x.2wwwwww4096Dec701:45svn[root@108-server~]#cat/var/www/html/svn/index.htmlthisisthepageofsvn/192.168.1.108[root@108-server~]#cat/var/www/html/submin/index.htmlthisisthepageofsubmin/192.168.1.108[root@108-server~]#cat/etc/hosts127.0.0.1localhostlocalhost.localdomainlocalhost4localhost4.localdomain4::1localhostlocalhost.localdomainlocalhost6localhost6.localdomain6192.168.1.108dev.wangshibo.com[root@108-server~]#curlhttp://dev.wangshibo.com//由于是内网机器不能联网，亦不能解析域名。
以是用域名访问没有反应。
只能用ip访问[root@ops-server4vhosts]#curlhttp://192.168.1.108thisis192.168.1.108page!!![root@ops-server4vhosts]#curlhttp://192.168.1.108/svn///末了一个/符号要加上，否则访问不了。
thisisthepageofsvn/192.168.1.108[root@ops-server4vhosts]#curlhttp://192.168.1.108/submin/thisisthepageofsubmin/192.168.1.108

然后在master-node和slave-node两台负载机器上进行测试（iptables防火墙要开通80端口）：

[root@master-node~]#curlhttp://192.168.1.108/svn/thisisthepageofsvn/192.168.1.108[root@master-node~]#curlhttp://192.168.1.108/submin/thisisthepageofsubmin/192.168.1.108

浏览器访问： 在本机host绑定dev.wangshibo.com，如下，即绑定到master和slave机器的公网ip上测试是否能正常访问（nginx+keepalive环境正式完成后，域名解析到的真正地址是VIP地址） 103.110.98.14 dev.wangshibo.com 103.110.98.24 dev.wangshibo.com

keepalived配置

1）master-node负载机上的keepalived配置

[root@master-node~]#cp/etc/keepalived/keepalived.conf/etc/keepalived/keepalived.conf.bak[root@master-node~]#vim/etc/keepalived/keepalived.conf

!ConfigurationFileforkeepalived#全局定义global_defs{notification_email{#指定keepalived在发生事宜时(比如切换)发送关照邮件的邮箱ops@wangshibo.cn#设置报警邮件地址，可以设置多个，每行一个。
需开启本机的sendmail做事tech@wangshibo.cn}notification_email_fromops@wangshibo.cn#keepalived在发生诸如切换操作时须要发送email关照地址smtp_server127.0.0.1#指定发送email的smtp做事器smtp_connect_timeout30#设置连接smtpserver的超时时间router_idmaster-node#运行keepalived的机器的一个标识，常日可设为hostname。
故障发生时，发邮件时显示在邮件主题中的信息。
}vrrp_scriptchk_http_port{#检测nginx做事是否在运行。
有很多办法，比如进程，用脚本检测等等script"/opt/chk_nginx.sh"#这里通过脚本监测interval2#脚本实行间隔，每2s检测一次weight-5#脚本结果导致的优先级变更，检测失落败（脚本返回非0）则优先级-5fall2#检测连续2次失落败才算确定是真失落败。
会用weight减少优先级（1-255之间）rise1#检测1次成功就算成功。
但不修正优先级}vrrp_instanceVI_1{#keepalived在同一virtual_router_id中priority（0-255）最大的会成为master，也便是接管VIP，当priority最大的主机发生故障后次priority将会接管stateMASTER#指定keepalived的角色，MASTER表示此主机是主理事器，BACKUP表示此主机是备用做事器。
把稳这里的state指定instance(Initial)的初始状态，便是说在配置好后，这台做事器的初始状态便是这里指定的，但这里指定的不算，还是得要通过竞选通过优先级来确定。
如果这里设置为MASTER，但如若他的优先级不及其余一台，那么这台在发送通知布告时，会发送自己的优先级，其余一台创造优先级不如自己的高，那么他会就回抢占为MASTERinterfaceem1#指定HA监测网络的接口。
实例绑定的网卡，由于在配置虚拟IP的时候必须是在已有的网卡上添加的mcast_src_ip103.110.98.14#发送多播数据包时的源IP地址，这里把稳了，这里实际上便是在哪个地址上发送VRRP通知布告，这个非常主要，一定要选择稳定的网卡端口来发送，这里相称于heartbeat的心跳端口，如果没有设置那么就用默认的绑定的网卡的IP，也便是interface指定的IP地址virtual_router_id51#虚拟路由标识，这个标识是一个数字，同一个vrrp实例利用唯一的标识。
即同一vrrp_instance下，MASTER和BACKUP必须是同等的priority101#定义优先级，数字越大，优先级越高，在同一个vrrp_instance下，MASTER的优先级必须大于BACKUP的优先级advert_int1#设定MASTER与BACKUP负载均衡器之间同步检讨的韶光间隔，单位是秒authentication{#设置验证类型和密码。
主从必须一样auth_typePASS#设置vrrp验证类型，紧张有PASS和AH两种auth_pass1111#设置vrrp验证密码，在同一个vrrp_instance下，MASTER与BACKUP必须利用相同的密码才能正常通信}virtual_ipaddress{#VRRPHA虚拟地址如果有多个VIP，连续换行填写103.110.98.20}track_script{#实行监控的做事。
把稳这个设置不能紧挨着写在vrrp_script配置块的后面（实验中碰过的坑），否则nginx监控失落效！
！
chk_http_port#引用VRRP脚本，即在vrrp_script部分指定的名字。
定期运行它们来改变优先级，并终极引发主备切换。
}}slave-node负载机上的keepalived配置

[root@slave-node~]#cp/etc/keepalived/keepalived.conf/etc/keepalived/keepalived.conf.bak[root@slave-node~]#vim/etc/keepalived/keepalived.conf

!ConfigurationFileforkeepalivedglobal_defs{notification_email{ops@wangshibo.cntech@wangshibo.cn}notification_email_fromops@wangshibo.cnsmtp_server127.0.0.1smtp_connect_timeout30router_idslave-node}vrrp_scriptchk_http_port{script"/opt/chk_nginx.sh"interval2weight-5fall2rise1}vrrp_instanceVI_1{stateBACKUPinterfaceem1mcast_src_ip103.110.98.24virtual_router_id51priority99advert_int1authentication{auth_typePASSauth_pass1111}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：

提示： 优先级不会不断的提高或者降落

可以编写多个检测脚本并为每个检测脚本设置不同的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#!/bin/bashcounter=$(ps-Cnginx--no-heading|wc-l)if["${counter}"="0"];then/usr/local/nginx/sbin/nginxsleep2counter=$(ps-Cnginx--no-heading|wc-l)if["${counter}"="0"];then/etc/init.d/keepalivedstopfifi

[root@master-node~]#chmod755/opt/chk_nginx.sh[root@master-node~]#sh/opt/chk_nginx.sh80/tcpopenhttp

此架构需考虑的问题 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/keepalivedstart[root@slave-node~]#/usr/local/nginx/sbin/nginx[root@slave-node~]#/etc/init.d/keepalivedstart

2）在主理事器上查看是否已经绑定了虚拟IP

[root@master-node~]#ipaddr.......2:em1:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500qdiscmqstateUPqlen1000link/ether44:a8:42:17:3d:ddbrdff:ff:ff:ff:ff:ffinet103.110.98.14/26brd103.10.86.63scopeglobalem1valid_lftforeverpreferred_lftforeverinet103.110.98.20/32scopeglobalem1valid_lftforeverpreferred_lftforeverinet103.110.98.20/26brd103.10.86.63scopeglobalsecondaryem1:0valid_lftforeverpreferred_lftforeverinet6fe80::46a8:42ff:fe17:3ddd/64scopelinkvalid_lftforeverpreferred_lftforever

3）停滞主理事器上的keepalived:

[root@master-node~]#/etc/init.d/keepalivedstopStoppingkeepalived(viasystemctl):[OK][root@master-node~]#/etc/init.d/keepalivedstatus[root@master-node~]#ps-ef|grepkeepalivedroot2695224348017:49pts/000:00:00grep--color=autokeepalived[root@master-node~]#

4）然后在从做事器上查看，创造已经接管了VIP：

[root@slave-node~]#ipaddr.......2:em1:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500qdiscmqstateUPqlen1000link/ether44:a8:42:17:3c:a5brdff:ff:ff:ff:ff:ffinet103.110.98.24/26brd103.10.86.63scopeglobalem1inet103.110.98.20/32scopeglobalem1inet6fe80::46a8:42ff:fe17:3ca5/64scopelinkvalid_lftforeverpreferred_lftforever.......

创造master的keepalived做事挂了后，vip资源自动漂移到slave上，并且网站正常访问，丝毫没有受到影响！

5）重新启动主理事器上的keepalived，创造主理事器又重新接管了VIP，此时slave机器上的VIP已经不在了

[root@master-node~]#/etc/init.d/keepalivedstartStartingkeepalived(viasystemctl):[OK][root@master-node~]#ipaddr.......2:em1:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500qdiscmqstateUPqlen1000link/ether44:a8:42:17:3d:ddbrdff:ff:ff:ff:ff:ffinet103.110.98.14/26brd103.10.86.63scopeglobalem1valid_lftforeverpreferred_lftforeverinet103.110.98.20/32scopeglobalem1valid_lftforeverpreferred_lftforeverinet103.110.98.20/26brd103.10.86.63scopeglobalsecondaryem1:0valid_lftforeverpreferred_lftforeverinet6fe80::46a8:42ff:fe17:3ddd/64scopelinkvalid_lftforeverpreferred_lftforever......[root@slave-node~]#ipaddr.......2:em1:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500qdiscmqstateUPqlen1000link/ether44:a8:42:17:3c:a5brdff:ff:ff:ff:ff:ffinet103.110.98.24/26brd103.10.86.63scopeglobalem1inet6fe80::46a8:42ff:fe17:3ca5/64scopelinkvalid_lftforeverpreferred_lftforever

接着验证下nginx做事故障，看看keepalived监控nginx状态的脚本是否正常？ 如下：手动关闭master机器上的nginx做事，最多2秒钟后就会自动起来（由于keepalive监控nginx状态的脚本实行间隔韶光为2秒）。
域名访问险些不受影响！

[root@master-node~]#/usr/local/nginx/sbin/nginx-sstop[root@master-node~]#ps-ef|grepnginxroot2840124826019:43pts/100:00:00grep--color=autonginx[root@master-node~]#ps-ef|grepnginxroot2887128870019:47?00:00:00/bin/sh/opt/chk_nginx.shroot2887524826019:47pts/100:00:00grep--color=autonginx[root@master-node~]#ps-ef|grepnginxroot284081019:43?00:00:00nginx:masterprocess/usr/local/nginx/sbin/nginxwww2841028408019:43?00:00:00nginx:workerprocesswww2841128408019:43?00:00:00nginx:workerprocesswww2841228408019:43?00:00:00nginx:workerprocesswww2841328408019:43?00:00:00nginx:workerprocess

末了可以查看两台做事器上的/var/log/messages，不雅观察VRRP日志信息的vip漂移情形~~~~

1）VIP绑定失落败 缘故原由可能有： -> iptables开启后，没有开放许可VRRP协议通信的策略（也有可能导致脑裂）；可以选择关闭iptables -> keepalived.conf文件配置有误导致，比如interface绑定的设备缺点

2）VIP绑定后，外部ping不通 可能的缘故原由是： -> 网络故障，可以检讨下网关是否正常； -> 网关的arp缓存导致，可以进行arp更新，命令是"arping -I 网卡名 -c 5 -s VIP 网关"

关注「 冰河技能 」微信公众年夜众号，后台回答 “设计模式” 关键字领取《深入浅出Java 23种设计模式》PDF文档。
回答“Java8”关键字领取《Java8新特性教程》PDF文档。
回答“限流”关键字获取《亿级流量下的分布式限流办理方案》PDF文档，三本PDF均是由冰河原创并整理的超硬核教程，口试必备！
！

好了，本日就聊到这儿吧！
别忘了点个赞，给个在看和转发，让更多的人看到，一起学习，一起进步！
！

如果你以为冰河写的还不错，请微信搜索并关注「 冰河技能 」微信公众年夜众号，跟冰河学习高并发、分布式、微做事、大数据、互联网和云原生技能，「 冰河技能 」微信公众年夜众号更新了大量技能专题，每一篇技能文章干货满满！
不少读者已经通过阅读「 冰河技能 」微信"大众年夜众号文章，吊打口试官，成功跳槽到大厂；也有不少读者实现了技能上的飞跃，成为公司的技能骨干！
如果你也想像他们一样提升自己的能力，实现技能能力的飞跃，进大厂，升职加薪，那就关注「 冰河技能 」微信"大众年夜众号吧，每天更新超硬核技能干货，让你对如何提升技能能力不再迷茫！