| 反向 代理 | 业务划分：
上传属于动态，需要开发的代码支持，也就是都需要PHP；静态只需要nginx即可。 | |||||||||||||||
| 反向代理的后方节点都是一个一个的服务器池，同一个池子里的节点内容完全相同，并且NginxLB具备健康检查功能，如果有节点损坏，NginxLB可以自我发现，因此不影响业务运行。但是NginxLB本身，仍旧是单点的。一旦坏了，业务就中断了。 NginxLB本身我们需要解决他的单点问题，一般是使用keepalived来解决的。 | ||||||||||||||||
|
用户获得数据的流程：
用户的请求数据包发送到公司的网关服务器，所以目标IP为网关IP；到了网关后，网关将数据包发送给外网交换机，然后有外网交换机将数据包交给反向代理，所以数据包再从网关出来时，他的目标IP为NginxLB的IP；代理收到数据包后，将其通过外网交换机发送给Web服务器，发送给哪个Web服务器，数据包的目标IP就是哪个Web的IP；再由Web服务器经过内网交换机从数据库或存储中调取数据，然后按原路返回给用户。 一但NginxLB出现故障，那么我们需要公司网关服务器将数据包转发给NginxLB-bakcup，这样就能保证业务不中断情况下继续服务的运行。高可用的关键问题就是解决NginxLB坏掉，然后自动将数据包发给NginxLB-backup的功能。 网关是自动根据NginxLB的IP地址转发的。利用ARP协议，已知LB的IP获取LB的MAC，然后封装MAC头部分发给外网交换机。 假设：如果坏掉的NginxLB的IP地址可以飘逸到NginxLB-backup上，那么网关转发 的数据包就可以到LB-backup上。 数据包再经过网关的时候，网关会对数据包进行重新打包的工作，将数据包（源IP：用户，目标IP：网关）封装成（源：网关，目标：NginxLB）。然后网关发起ARP协议，通过已知目标IP：NginxLB获取目标MAC：NginxLB-MAC，然后封装MAC头部，将数据包发给外网交换机。由外网交换机将数据包发给NginxLB。因此，如果NginxLB的IP地址能够出现在NginxLB-backup上，那么获取到的MAC地址就不是NginxLB的MAC地址，而是NginxLB-backup的MAC地址。如此一来，封装MAC头部，封装的就是NginxLB-backup，再通过外网交换机转发，就到了NginxLB-backup上。 结论：因此，一切关键问题就在于我们如何实现一旦NginxLB坏了，他IP出现在NginxLB-backup上。Keepalived就是解决这个问题的。 | ||||||||||||||||
| 概念 | NginxLB有两个IP地址，一个是本地IP地址，称作DIP，一个是临时IP地址，称作VIP 我们要向让NginxLB的IP地址可以到NginxLB-backup上，那么就需要使用他的VIP，也就是说我们要在NginxLB上临时设定一个叫做虚拟的临时IP，一旦NginxLB坏了，我们只需要让VIP出现在NginxLB-backup上。 | |||||||||||||||
| 环境 | 两台NginxLB都需要安装keepalived（yum即可） 安装后，配置keepalived的配置文件，然后双向启动keepalived服务。 NginxLB上就会出现一个VIP地址（此时backup上没有VIP） 一旦NginxLB损坏，NginxLB-backup就会立即启动争抢VIP机制，这样VIP会立即出现在NginxLB-backup上。这样就实现了高可用，也就是VIP的漂移。 （同网段下，每个IP只能有一台服务器占用） | |||||||||||||||
| keepalived | Keepalived是通过VRRP（虚拟路由冗余协议）来实现的。VRRP是为了解决静态路由单点故障问题，能够保证当个别节点宕机时，整个网络可以不间断运行。一方面具有配置管理LVS的功能，同时还具有对LVS下面节点进行健康检查功能，另一方面也可实现系统网络服务的高可用功能。 三大功能：
| |||||||||||||||
| 路由器高可用 VRRP | 在偏远的山区，我们要实现的就是路由器的无限高可用。一个路由器坏了，VIP就会漂移到其他好的路由器上，来防止网络瘫痪。这个功能就是VRRP实现的。 所有路由器在刚连接上交换机的时候，一旦启动，所有路由器都会群发一个广播包，广播包属于同网段群发，在同一个网段下的所有机器都会接收到。每个路由器都有一个优先值，有网络工程师设定，数字越大，优先级越高。 四号路由器在发广播包的时候，五号收到后，比对发现优先值低于自己，那么他就会继续发数据包；五号发出的数据包发出数据包，优先值大于四号路由器，那么四号就会进入等待状态，不会再发广播包，只要五号活着，四号就会一直等待（每一到两秒就会发送广播包，四号一直收到就会一直认为五号活着，那么他就不会去抢VIP）。所有路由器以此类推，最终优先级高的路由器，会压制优先级低的路由器，且优先值不可能相同，优先级最高的路由器会获得VIP。
一号如果不发广播包了，其余路由器就认为一号死了，那么所有路由器群发广播包，按照优先值进行压制，最终优先值最高的重新获得VIP。 一旦某个节点变动就会触发广播包的群发，从而对比选出VIP。 | |||||||||||||||
| Keepalived就是利用VRRP协议来实现的故障转移原理。
两个都会群发广播包，backup被master压制，从而待机。只要backup一直能收到master的广播包，就会认定master活着，一旦收不到了，就会认为master死了。Master每隔一秒发一次广播包。 ifconfig eth0 IP up/down 临时添加/删除一个IP地址
网关在进行ARP协议的时候，VIP在谁哪里，谁就会回应，从而网关对其发送数据。 广播包收完会自动清空。一旦主回来，就会重新压制，抢回VIP。 | ||||||||||||||||
| 问题 | backup什么情况下收不到广播包？
Keepalived只能解决物理服务器出现故障的切换。无法解决软件程序故障的切换。因此，我们需要在master上写一个联动脚本。一旦本地的NginxLB进程挂了，就立刻停止keepalived进程。强制VIP切换。每隔一分钟扫描本地的Nginx80端口，如果存在正常，不存在关闭keepalived。 广播包属于群发，同网段内都能收到，假如同网段内，有多个高可用keepalived，该怎么办？ 在keepalived上，不止一块儿网卡。用一条网线，让主和备之间直接连接在反向代理的主和备之间，让他们自成一个网段。
一根网线两两相连主备，中间没有任何设备，也不会影响其他服务器。 由于一根网线直接连接两个服务器，如同心脏连接心脏一样，因此，这条线我们也叫做心跳线。Keepalived广播包我们称之为心跳包。一旦backup收不到心跳，就会认为master死了。因此naginxLB上最少两块网卡，一般为三块。 解决了：
未解决：
| |||||||||||||||
| 脑裂 原因 |
| |||||||||||||||
| 脑裂预 防脚本 | 放在backup上 触发条件：backup上出现vip的时候，才会进入判断，判断是正常切换还是脑裂切换。 思路：
1).ping master的eht0的ip a.通了：网线网卡物理服务器无误 扫描（telnet,nmap）master的80端口，查看Nginx进程是否存在。若不存在，正常切换（联动脚本停止了keepalived） b.不通（物理服务器坏了（正常），网线坏了（脑裂），网卡坏了（脑裂），继续ping master的eth1网卡。痛了表示服务器正常，扫描目标的80端口，存在为脑裂，不存在为正常；不通，服务器坏了，正常切换。 | |||||||||||||||
| 面试问答 |
| |||||||||||||||
| 操作实例 | ||||||||||||||||
| 环境 |
[root@Nginx ~]# cat /etc/redhat-release CentOS release 6.5 (Final) //查看系统版本 [root@Nginx ~]# uname -r 2.6.32-431.el6.x86_64 //查看内核版本 [root@Nginx ~]# uname -m x86_64 //查看系统线程
| |||||||||||||||
| 1. | [root@Nginx ~]# yum -y install keepalived //yum安装keepalived服务 [root@Nginx2 ~]# yum -y install keepalived //yum安装keepalived服务 （两台代理都安装keepalived服务） | |||||||||||||||
| 2. | [root@Nginx ~]# /etc/init.d/keepalived start //启动keepalived
[root@Nginx ~]# ps -ef | grep keep | grep -v grep //查看服务启动进程
#启动后有三个keepalived进程表示安装正确 [root@Nginx ~]# ip add | grep 192.168 //查看默认启动的VIP都有那些，默认启动三个
[root@Nginx ~]# /etc/init.d/keepalived stop //关闭服务
在另一台服务器上，也如此进行keepalived的开启关闭测试。 | |||||||||||||||
| 3. | [root@Nginx ~]# cd /etc/keepalived //进入keepalived目录 [root@Nginx keepalived]# ls keepalived.conf //查看配置文件 [root@Nginx keepalived]# head -13 keepalived.conf | cat -n //带行号查看配置文件内容
第一行为注释 第二行空行 第三到八行为定义服务故障报警的Email地址。作用是当服务发生切换或RS节点等有故障时，发报警邮件。这几行是可选配置，notification_email指定在keepalived发生事件时，需要发送的Email地址，可以有多个，每行一个。 第九行时指定发送邮件的发送人，即发件人地址，也是可选的配置。 第十行smtp_server指定发送邮件的smtp服务器，如果本机开启了sendmail或postfix，就可以使用上面的默认配置实现邮件发送，也是可选值。 第十一行smtp_connect_timeout是连接smtp的超时事件，也是可选配置。 第四到十一所有和邮件报警相关的参数均可以不配，在实际工作中会将监控的任务交给更加擅长监控报警的Nagios或Zabbix软件。 第十二行是keepalived服务器的路由标识（router_id）在一个局域网内，这个标识应该是唯一的。大括号内{}用来分隔区块，成对出现，如果漏写半个大括号，Keepalived运行时，不会报错，但是也不会得到想要的结果。另外，由于区块间存在多层嵌套关系，因此很容易遗漏区块结尾的大括号，需要特备注意。 [root@Nginx keepalived]# sed -n '15,30{=;p}' keepalived.conf | xargs -L2 //VRRP实例定义区块部分
第十五行表示定义一个vrrp_instance实例，名字是VI_1，每个vrrp_instance实例可以认为是keepalived服务的一个实例或者作为一个业务服务，在keepalived服务配置中，这样的vrrp_instance实例可以有多个。注意，存在于主节点中的vrrp_instance实例在备节点中也要存在，这样才能实现故障切换接管。 第十六行state MASTER表示当前实例VI_1的角色状态，当前角色为MASTER，这个状态只能由MASTER和BACKUP两种状态，且需要大写这些字符。其中MASTER为正常的工作状态，BACKUP为备用的状态。当MASTER所在的服务器故障或失效时，BACKUP所在的服务器会接管故障的MASTER继续提供服务。 第十七行interface为网络通信接口，为对外提供服务得网络接口，如eth0，eth1。当前主流的服务器都有2~4个网络接口，在选择服务接口时，要搞清楚。 第十八行virtual_router_id为虚拟路由ID标识，这个标识最好是一个数字，并且要在keepalived.conf配置中是唯一的。但是MASTER和BAXKUP配置中相同实例的virtual_router_id又必须是一致的，否则将出现脑裂问题。 第十九行priority为优先级，其后面的数值也是一个数字，数字越大，表示实例优先级越高。在同一个vrrp_instance实例里，MASTER的优先级高于BACKUP的。若MASTER的priority的值为150，那么BACKUP的priority必须小于150，一般建议间隔50以上为，佳，如设置BACKUP的priority为100或更小的数值。 第二十行advert_int为同步通知间隔。MASTER与BACKUP之间通信检查的时间间隔，单位为秒，默认为1. 第二十一到二十四行authertication为默认权限认证配置。包含认证类型（auth_type）和认证密码（auth_pass）。认证类型又PASS，AH两种。官方推荐使用的类型为PASS。验证密码为明文方式，最好长度不要超过8个字符，建议用4位数字，同一vrrp实例的MASTER与BACKUP使用相同的密码才能正常通信。 第二十五到二十九行vritual_ipaddress为虚拟IP地址。可以配置多个IP地址，每个地址占一行，配置时最好指定子网掩码以及虚拟IP绑定的网络接口。否则，子网掩码默认32位，绑定的接口和前面的interface参数配置的一致。注意，这里的虚拟IP就是在工作中需要和域名绑定的IP，即和配置的高可用服务监听的IP要保持一致！ | |||||||||||||||
| 4. | [root@Nginx keepalived]# vim keepalived.conf //进入主配置文件，修改内容 例子：
配置：
（Ps：如果你只有一块网卡，那么interface就是你那块网卡的名称；服务器是哪个网段的，虚拟IP也要设置相应的网段） [root@Nginx keepalived]# /etc/init.d/keepalived start //启动keepalived服务 [root@Nginx keepalived]# ip a | grep 192.168.200.126 //查看是否有虚拟IP192.168.200.126
如果能检测出虚拟IP，那么配置成功 | |||||||||||||||
| 5. | [root@Nginx2 keepalived]# vim keepalived.conf //进入备份LB的keepalived主配置文件进行修改 例子：
配置：
[root@Nginx2 keepalived]# /etc/init.d/keepalived start //启动服务 [root@Nginx2 keepalived]# ip a | grep 192.168.200.126 //检测配置结果，查看是否存在虚拟IP，如果没有，那么是正确的，因为lb02为backup是备份，主节点存活时，他不会接管VIP192.168.200.126 排错思路： 出现上面无结果现象，表示lb02的keepalived服务单实例配置成功。如果出现配置过滤后有192.168.200.126的IP，则表示keepalived工作不正常，同一个IP地址同一时刻应该只能出现一台服务器。 如果查看BACKUP备节点VIP有如下信息，说明高可用脑裂了，脑裂是指两台服务器争抢同一资源导致的。例如：配置了同一个VIP地址。 出现脑裂问题，一般要排查：主备两台服务器对应的keepalived.conf配置文件是否错误，如同一实例的virtual_router_id配置不一致。 | |||||||||||||||
| 6. |
//在主LB上停止keepalived服务，查询不到VIP
//在备LB上查看VIP，发现备已经抢到主的VIP，此时如果有资源传输，将会直接由备进行代理执行。
//一旦主LB恢复正常后，他就会进行广播，由于优先级高于备，所以他就会将VIP抢回来。
//此时备上的VIP消失，被主抢走，他就会处于等待，等主挂了，就开始进行新的VIP抢夺。
对比配置文件，我们可以发现，主和备的区别就在于：router_id（唯一标识）、state（角色状态）、priority（竞选优先级）这三个参数上。 | |||||||||||||||
| 裂脑 | 由于某些原因，导致两台高可用服务器在指定时间内，无法检测到对方的心跳消息，各自取得的资源及服务的所有权，而此时的两台高可用服务器对都还活着并在正常运行，这样就会导致同一个IP或服务在两端同时存在而发生冲突，最严重的是两台主机占用同一个VIP地址，当用户写入数据时可能会分别写入到两端，这可能会导致服务器两端的数据不一致或造成数据丢失，这种情况就成为裂脑。 | |||||||||||||||
| 裂脑出现的原因 | ·高可用服务器之间心跳线链路发生故障，导致无法正常通信； ·心跳线坏了（包括断了，老化）； ·网卡及相关驱动坏了，IP配置及冲突问题（网卡直连）； ·心跳线间连接的设备故障（网卡及交换机）； ·仲裁的机器出问题（采用仲裁的方案）； ·高可用服务器上开启了iptables防火墙阻止了心跳消息传输； ·高可用服务器上心跳网卡地址等消息配置不正确，导致发送心跳失败； ·其他服务配置不当等原因，如心跳方式不同，心跳广播冲突，软件BUG等 （在keepalived配置里，同一VRRP实例如果virtual_router_id两端参数不一致，也会导致裂脑问题发生） | |||||||||||||||
| 解决方法 | ·同时使用串行电缆和以太网线缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳信息。 ·当检测到裂脑时，强行关闭一个心跳节点（这个功能需要特殊设备支持，如Stonith，fence）。相当于备节点接收不到心跳信息，通过单独的线路发送关机命令关闭主节点的电源。 ·多好对裂脑的监控警报（如邮件及手机短信等或值班），在问题发生时认为第一时间接入仲裁，降低损失。例如：百度的监控报警短信就有上行和下行的区别。报警信息发送到管理员手机上，管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器，让服务器根据指令自动处理相应故障，这样解决故障的时间更短。 ·当然，在实施高可用方案时，要根据业务实际需求确定是否能容忍这样的损失。对于一般的网站常规业务，这个损失是可容忍的。 | |||||||||||||||
| 解决 Keep alived 裂脑的常见方案 | ·如果开启防火墙，一定要让心跳消息通过，一般通过允许IP的形式解决。 ·可以拉一条以太网网线或串口线作为主节点心跳线路的冗余。 ·开发检测程序通过监控软件（如：Nagios）检测脑裂。
| |||||||||||||||
扫一扫
05-01
2812
2812
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
