LVS专题-(3)虚拟ip理解
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
LVS专题-(3)虚拟ip理解
1.虚拟IP是什么?
要是单讲解虚拟 IP,理解起来很困难,所以⼲脆把
动态 IP 、固定 IP 、实体 IP 与虚拟 IP都讲解⼀下,加深理解和知识扩展
实体 IP:在⽹络的世界⾥,为了要辨识每⼀部计算机的位置,因此有了计算机 IP 位址的定义。
⼀个 IP 就好似⼀个门牌!例如,你要去微软的⽹站的话,就要去『
207.46.197.101 』这个 IP 位置!这些可以直接在⽹际⽹络上沟通的 IP 就被称为『实体 IP 』了。
虚拟 IP:不过,众所皆知的,IP 位址仅为 xxx.xxx.xxx.xxx 的资料型态,其中, xxx 为 1-255 间的整数,由于近来计算机的成长速度太快,实体的 IP 已经有点不⾜了,好在早在
规划 IP 时就已经预留了三个⽹段的 IP 做为内部⽹域的虚拟 IP 之⽤。
这三个预留的 IP 分别为:
A级:10.0.0.0 - 10.255.255.255
B级:172.16.0.0 - 172.31.255.255
C级:192.168.0.0 - 192.168.255.255
上述中最常⽤的是192.168.0.0这⼀组。
不过,由于是虚拟 IP ,所以当您使⽤这些地址的时候﹐当然是有所限制的,限制如下:
私有位址的路由信息不能对外散播
使⽤私有位址作为来源或⽬的地址的封包﹐不能透过Internet来转送
关于私有位址的参考纪录(如DNS)﹐只能限于内部⽹络使⽤
由于虚拟 IP 的计算机并不能直接连上 Internet ,因此需要特别的功能才能上⽹。
不过,这给我们架设IP⽹络做成很⼤的⽅便﹐⽐如﹕即使您⽬前的公司还没有连上Internet﹐但不
保证将来不会啊。
如果使⽤公共IP的话﹐如果没经过注册﹐等到以后真正要连上⽹络的时候﹐就很可能和别⼈冲突了。
也正如前⾯所分析的﹐到时候再重新规划IP的话﹐将是件
⾮常头痛的问题。
这时候﹐我们可以先利⽤私有位址来架设⽹络﹐等到真要连上intetnet的时候﹐我们可以使⽤IP转换协定﹐如 NAT (Network Addresss Translation)等技术﹐配
合新注册的IP就可以了。
固定 IP 与动态 IP:基本上,这两个东西是由于近来⽹络公司⼤量的成长下的产物,例如,你如果向中华电信申请⼀个商业型态的 ADSL 专线,那他会给你⼀个固定的实体 IP ,
这个实体 IP 就被称为『固定 IP 』了。
⽽若你是申请计时制的 ADSL ,那由于你的 IP 可能是由数⼗⼈共同使⽤,因此你每次重新开机上⽹时,你这部计算机的 IP 都不会是固定
的!于是就被称为『动态 IP』或者是『浮动式IP』。
基本上,这两个都是『实体IP』,只是⽹络公司⽤来分配给⽤户的⽅法不同⽽产⽣不同的名称⽽已。
⾃⼰的理解
我们⽤路由器时,每个⼿机或电脑都有⼀个ip地址,这个IP就是虚拟IP。
想象⼀下,如果世界上的每台设备(电脑⼿机都算)都有⼀个实际IP地址,IP地址肯定不够⽤。
但如果
每个实际的IP地址再对应⼏万个虚拟的IP地址(⽐如 192.168.0.0 - 192.168.255.255),那不就够了吗?
我们给⼀个路由器分配⼀个实体IP(只是举个例⼦),之后每个连接这个路由器的设备给他分配⼀个虚拟IP(⽐如 192.168.0.0 - 192.168.255.255 中随机给⼀个),路由器记下
这个虚拟IP和对应的设备,当某个设备访问⽹络数据时,先经过路由器,然后路由器与⽹络进⾏数据交换,因为路由器有实体IP,所以⽹络可以给路由器发送数据,然后路由器
再根据⾃⼰分配的虚拟IP发送到相应的设备。
2.虚拟IP与arp协议
⼀、虚拟IP
虚拟IP(Vrtual IP Address),是⼀种不与特定计算机或者特定计算机⽹卡相对应的IP地址。
所有发往这个IP地址的数据包最后都会经过真实的⽹卡到达⽬的主机的⽬的进程。
引⽤维基上⾯的定义:https:///wiki/Virtual_IP_address
A virtual IP address (VIP or VIPA) is an that doesn't correspond to an actual physical network interface (port). Uses for VIPs include (especially, ), fault-tolerance, and mobility.
虚拟IP主要是⽤来⽹络地址转换,⽹络容错和可移动性。
虚拟IP⽐较常见的⼀个⽤例就是在系统⾼可⽤性(High Availability HA)⽅⾯的应⽤,通常⼀个系统会因为⽇常维护或者⾮计划外的情况⽽发⽣宕机,为了提⾼系统对外服务的⾼可⽤性,就会采⽤
主备模式进⾏⾼可⽤性的配置。
当提供服务的主机M宕机后,服务会切换到备⽤主机S继续对外提供服务。
⽽这⼀切⽤户是感觉不到的,在这种情况下系统对客户端提供服务的IP地址就会是⼀个虚拟IP,
当主机M宕机后,虚拟IP便会漂浮到备机上,继续提供服务。
在这种情况下,虚拟IP就不是与特定计算主机或者特定某个物理⽹卡对应的了,⽽是⼀种虚拟或者是说逻辑的概念,它是可以⾃由移动⾃由漂浮的,这样⼀来既对外屏蔽了系统内部的细节,⼜为系
统内部的可维护性和扩展性提供了⽅便。
⼆、arp协议
arp协议属于TCP/IP协议族⾥⾯⼀种⽤户将IP地址解析为MAC地址的协议。
该协议是⽤户局域⽹内解析IP地址对应的物理地址。
通常⼀个主机A给另⼀个主机B通过⽹络发送⼀个IP数据报的时候,⾸先会发送到主机A所在的路由器上⾯ arp协议中⽐较重要的内容之⼀就是arp缓存,主机操作系统会将IP地址与MAC地址的映射关系存放在主机的⼀⽚⾼速缓存中。
缓存失效:该缓存会在⼀定时间内失效,失效后,请求该IP地址时需要⼴播arp请求重新获取IP地址对应的MAC地址
缓存更新:当收到ARP请求时,会将发送ARP请求的主机IP地址与MAC地址记录下来,然后去更新本机arp缓存中对应的记录。
三、虚拟IP与arp协议
虚拟IP和arp协议
虚拟IP常⽤于系统⾼可⽤性的场景,那么虚拟IP实现的原理是什么?虚拟能够⾃由漂浮的原理是什么?
从前⽂介绍arp协议⾥⾯来看,主机与主机的通信过程都会涉及到⼀个ip地址转换mac地址的过程,那么虚拟IP的通信也不会例外。
因此,IP地址在主机通信的过程中其实就是⼀个逻辑地址。
我们知
道,每⼀个主机都存放着⽹络内⼀些主机的逻辑地址与物理地址(MAC地址)的映射,问题来了,当虚拟IP VIP在主机A上时,主机A的MAC地址为MAC_A某主机M的arp缓存中存放着⼀个映射关系:
VIP ---à MAC_A;当主机A宕机后,虚拟IPVIP漂浮到了主机B,主机B的MAC地址为MAC_B,那么此时主机M想与虚拟IP通信时,是做不到,因为它的arp⾼速缓存中的虚拟IP VIP的映射还指向主机A的
MAC地址。
这个问题解决的思路就是当虚拟IP漂浮后,刷新所有其他主机的arp缓存。
那么虚拟IP是如何实现漂浮后,是如何刷新所有其他主机的arp缓存的呢?
这⾥就会引⼊另⼀个概念,garp()简称⽆端arp或者免费arp,主要是⽤来当某⼀个主机C开机时,⽤来确认⾃⼰的IP地址没有被⼈占⽤⽽做的⼀个检测。
⼴播发送这个arp,请求得到本机IP地址的
MAC地址,主机C并不希望此次arp请求会有arp应答,因为应答意味着IP地址冲突了。
当其他主机收到这个arp请求后,会刷新关于这个arp请求源的主机IP地址的映射。
Garp的作⽤主要有两个:
1. 检测IP地址是否有冲突
2. 刷新其他主机关于本次IP地址的映射关系
集群管理软件Pacemaker⾥⾯的资源代理ocf:heartbeat:IPaddr2中,在虚拟IP漂浮后,会向⽹络内⼴播发送garp请求,以此来刷新其他主机的arp缓存。
在配置OpenStack控制节点⾼可⽤性的时候,出现过虚拟IP切换时,某⼀个主机不能通信的问题,后来发现是arp缓存没有刷新,有时候由于⽹络的原因,某些主机没有接收到此garp请求,因此
ocf:heartbeat:IPaddr2资源代理中可以配置发送garp的次数,这⾥建议次数配置得多⼀点,这样可以保证其他主机成功刷新arp缓存。
3. 谈谈VIP漂移那点破事
⼀直以来都是⽤nginx的upstream模块做⽹站最前端的负载均衡,为了防⽌nginx本⾝宕机导致⽹站不能访问,通常都会做两套nginx反向代理,然后⽤keepalive之类的软件提供VIP。
常见的环境是nginx主节点和从节点各有⼀个公⽹IP,⼀个私有IP,VIP地址也使⽤公⽹IP来提供,正常情况下VIP只会在nginx主节点上⼯作,只有主节点宕机或者⽹络不可达等情况下,VIP才会漂移到nginx从节点上。
如果keepalive配置了⾮抢占模式,则主节点恢复后,VIP也不会漂移会主节点,⽽是继续在从节⼯作。
这种配置要求机房⽹络不做mac 地址绑定。
最近做的两套培训系统测试情况如下:
系统⼀:主从节点做双⽹卡绑定,都只有⼀个私有IP,VIP也为私有IP,通过防⽕墙的NAT转发⽤户的访问请求。
主节点宕机后,VIP可以漂移⾄从节点,但⽤户⽆法访问⽹
站,telnet防⽕墙公⽹IP的80端⼝提⽰⽆法连接。
系统⼆:主从节点各有两张⽹卡,分别配置⼀个公⽹IP和⼀个私有IP。
VIP地址也使⽤公⽹IP来提供。
主节点宕机后,VIP可以漂移⾄从节点,但⽤户⽆法ping通VIP,⾃然⽹站也就打不开。
于是分别对这两种情况进⾏排查:
系统⼆:属于⽐较常见的配置⽅案。
VIP漂移后⽆法ping通,第⼀反应询问机房⼯作⼈员,是否相应的设备做了mac地址绑定。
得知⽆绑定策略后继续排查。
发现配置net.ipv4.ip_nonlocal_bind = 1 参数并使其⽣效后重新测试正常。
系统⼀:情况有点特殊,按系统⼆的解决⽅法尝试⽆果后,怀疑端⼝路由器映射上出现问题。
于是继续测试VIP漂移,发现VIP漂移到从节点后,防⽕墙上的arp表中vip对应的mac地址依旧是主节点⽹卡的mac地址,原来防⽕墙才是罪魁祸⾸,坑爹的货。
机房使⽤的防⽕墙型号华为Quidway Eudemon1000E,据说默认配置下,这个arp地址表⾃动刷新需要20分钟!
好吧!于是⽤下⾯的命名⼿⼯刷新后,万事⼤吉,⽹站访问也很顺畅,⽐较郁闷的是当主节点重新抢占VIP后,依然需要⼿⼯刷新下,否则防⽕墙还是把请求转给从节点响应。
# arping -I ⽹卡地址 -c 3 -s VIP地址⽹关地址
后记:
要彻底解决系统⼀的问题,可以从两⽅⾯去着⼿,⾸先是考虑去调整防⽕墙的arp表的⾃动刷新时间;其次是考虑在从节点上部署⼀个⽆限循环的脚本,时时去检测是否抢占到了VIP,若抢占成功,则运⾏前⾯的刷新命令,命令成功运⾏后退出脚本,同时可以⽤nagios监控该脚本,了解最新的主从切换情况。
切记,循环运⾏⼀次接受后sleep 1秒,否则会死机的哦!
如果在主节点上也部署类似的脚本,则会对⽹络带来负担,因⽽主节点恢复后的刷新⼿⼯运⾏下就好了,如果忘记运⾏了,从节点依然可以⼯作,⽆伤⼤雅!
资料来源:
4.HA集群中的虚拟IP原理
⾼可⽤性HA(High Availability)指的是通过尽量缩短因⽇常维护操作(计划)和突发的系统崩溃(⾮计划)所导致的停机时间,以提⾼系统和应⽤的可⽤性。
HA系统是⽬前企业防⽌核⼼计算机系统因故障停机的最有效⼿段。
实现HA的⽅式,⼀般采⽤两台机器同时完成⼀项功能,⽐如数据库服务器,平常只有⼀台机器对外提供服务,另⼀台机器作为热备,当这台机器出现故障时,⾃动动态切换到另⼀台热备的机器。
怎么实现故障检测的那?
⼼跳,采⽤定时发送⼀个数据包,如果机器多长时间没响应,就认为是发⽣故障,⾃动切换到热备的机器上去。
怎么实现⾃动切换那?
虚IP。
何为虚IP那,就是⼀个未分配给真实主机的IP,也就是说对外提供数据库服务器的主机除了有⼀个真实IP外还有⼀个虚IP,使⽤这两个IP中的任意⼀个都可以连接到这台主机,所有项⽬中数据库链接⼀项配置的都是这个虚IP,当服务器发⽣故障⽆法对外提供服务时,动态将这个虚IP切换到备⽤主机。
开始我也不明⽩这是怎么实现的,以为是软件动态改IP地址,其实不是这样,其实现原理主要是靠TCP/IP的ARP协议。
因为ip地址只是⼀个逻辑地址,在以太⽹中MAC地址才是真正⽤来进⾏数据传输的物理地址,每台主机中都有⼀个ARP⾼速缓存,存储同⼀个⽹络内的IP地址与MAC地址的对应关系,以太⽹中的主机发送数据时会先从这个缓存中查询⽬标IP对应的MAC地址,会向这个MAC地址发送数据。
操作系统会⾃动维护这个缓存。
这就是整个实现的关键。
下边就是我电脑上的arp缓存的内容。
(192.168.1.219) at 00:21:5A:DB:68:E8 [ether] on bond0
(192.168.1.217) at 00:21:5A:DB:68:E8 [ether] on bond0
(192.168.1.218) at 00:21:5A:DB:7F:C2 [ether] on bond0
192.168.1.217、192.168.1.218是两台真实的电脑,
192.168.1.217为对外提供数据库服务的主机。
192.168.1.218为热备的机器。
192.168.1.219为虚IP。
⼤家注意红字部分,219、217的MAC地址是相同的。
再看看那217宕机后的arp缓存
(192.168.1.219) at 00:21:5A:DB:7F:C2 [ether] on bond0
(192.168.1.217) at 00:21:5A:DB:68:E8 [ether] on bond0
(192.168.1.218) at 00:21:5A:DB:7F:C2 [ether] on bond0
这就是奥妙所在。
当218 发现217宕机后会向⽹络发送⼀个ARP数据包,告诉所有主机192.168.1.219这个IP对应的MAC地址是00:21:5A:DB:7F:C2,这样所有发送到219的数据包都会发送到mac地址为00:21:5A:DB:7F:C2的机器,也就是218的机器。
5. 基于keepalived 实现VIP转移,lvs,nginx的⾼可⽤
⼀、Keepalived ⾼可⽤集群的解决⽅案
⼆、VRRP的有限状态机
三、利⽤keepalived 实现主从VIP的切换
四、
四、实现在状态转变的时候⾃定义进⾏通知,
实现在状态转变的时候⾃定义进⾏通知,
五、
五、实现负载均衡
实现负载均衡
六:实现nginx的⾼可⽤
⼀、Keepalived ⾼可⽤集群的解决⽅案
最初的诞⽣是为ipvs提供⾼可⽤的,在后端的realserver接收不到主节点的信息之后,keepalived能够⾃⼰调⽤ipvsadm命令⽣成规则,能够⾃动实现,将主节点的VIP以及ipvs规则“拿过来”,应⽤在从节点上,继续为⽤户服务。
还可以实现对后端realserver的健康状况做检测。
keepalived在⼀个节点上启动之后,会⽣成⼀个Master主进程,这个主进程⼜会⽣成两个⼦进程,分别是VRRP Stack(实现vrrp协议的) Checkers(检测ipvs后端realserver的健康状况检测)
⼆、VRRP的有限状态机
VRRP双⽅节点都启动以后,要实现状态转换的,刚开始启动的时候,初始状态都是BACKUP,⽽后向其它节点发送通告,以及⾃⼰的优先级信息,谁的优先级⾼,就转换为MASTER,否则就还是BACKUP,这时候服务就在状态为MASTER的节点上启动,为⽤户提供服务,如果,该节点挂掉了,则转换为BACKUP,优先级降低,另⼀个节点转换为MASTER,优先级上升,服务就在此节点启动,VIP,VMAC都会被转移到这个节点上,为⽤户提供服务,
实验环境:
虚拟主机版本:
CentOS6.4-i686
两个节点:
172.16.6.1
172.16.6.10
准备
1、节点⼀:
同步时间:
[root@node1 ~]# ntpdate 172.16.0.1
安装keepalived
[root@node1 ~]# yum -y install keepalived
2、节点⼆做同样的⼯作
三、利⽤keepalived 实现主从VIP的切换
3.1我们修改下keepalived的配置⽂件:
1 2 3[root@node1 ~]# cd /etc/keepalived/
[root@node1 keepalived]# cp keepalived.conf keepalived.conf.back //先给配置⽂件备份⼀下[root@node1 keepalived]# vim keepalived.conf
3.2全局阶段
1 2 3 4 5 6 7 8 9global_defs {
notification_email { //定义邮件服务的
root@localhost //定义收件⼈,这⾥改为本机,只是测试使⽤ }
notification_email_from kaadmin@localhost //定义发件⼈,
smtp_server 127.0.0.1//定义邮件服务器,⼀定不能使⽤外部地址 smtp_connect_timeout 30//超时时间
router_id LVS_DEVEL
}
3.3定义vrrp阶段
1 2 3 4 5 6 7 8 9 10 11 12 13 14vrrp_instance VI_1 { //定义虚拟路由,VI_1 为虚拟路由的标⽰符,⾃⼰定义名称
state MASTER //开启后,该节点的优先级⽐另⼀节点的优先级⾼,所以转化为MASTER状态
interface eth0 //所有的通告等信息都从eth0这个接⼝出去
virtual_router_id 7//虚拟路由的ID,⽽且这个ID也是虚拟MAC最后⼀段的来源,这个ID号⼀般不能⼤于255,且这个ID⼀定不能有冲突 priority 100//初始优先级
advert_int 1//通告的个数
authentication { //认证机制
auth_type PASS //认证类型
auth_pass 1111//密码,应该为随机的字符串
}
virtual_ipaddress { //虚拟地址,即VIP
172.16.6.100
}
}
这样我们主节点的配置⽂件就修改好了,需要复制到从节点上,再做适当的修改就可以使⽤了1[root@node1 keepalived]# scp keepalived.conf 172.16.6.1:/etc/keepalived/
3.4登录到从节点;
1
2 3 4 5 6 7 8 9 10 11 12[root@node2 ~]# cd /etc/keepalived/
[root@node2 keepalived]# vim keepalived.conf
vrrp_instance VI_1 {
state BACKUP //修改从节点的状态,主节点为MASTER,从节点就为BACKUP interface eth0
virtual_router_id 7
priority 99//修改优先级,注意从节点的优先级⼀定要⼩于主节点
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
13 14 15 16 172.16.6.100 }
}
3.5然后在主节点启动服务
1 2[root@node1 keepalived]# service keepalived start [root@node1 ~]# ip addr show //查看我们定义的VIP
3.6在从节点启动服务
[root@node2 keepalived]# service keepalived start 把主节点上的服务停掉,看VIP会不会到从节点上[root@node2 ~]# ip addr show
3.7在主节点上启动服务
1 2[root@node1 ~]# service keepalived start
[root@node1 ~]# ip addr show //检测结果发现VIP转移到了主节点
注:
默认情况下ARRP⼯作在“抢占模式”下,如果发现⼀个节点的服务停⽌了,另⼀个节点会⽴即把VIP和VMAC“抢过来”,如果在“⾮抢占模式”下,⽆论你的优先级过⾼,⼀个节点服务停⽌,另⼀个节点也不会“抢”VIP和VMAC,除⾮这个节点挂了,两⼀个节点才会“抢”。
四、实现在状态转变的时候⾃定义进⾏通知,
4.1这需要依赖于脚本来完成
主节点
1
2
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36[root@node1 ~]# cd /etc/keepalived/
[root@node1 keepalived]# vim notify.sh //编写脚本
#!/bin/bash
vip=172.16.6.100
contact='root@localhost'
thisip=`ifconfig eth0 | awk '/inet addr:/{print $2}'| awk -F: '{print $2}'`
Notify() {
mailsubject="$thisip is to bi $vip master"
mailbody="vrrp transaction, $vip floated to $thisip"
echo $mailbody | mail -s "$mailsubject"$contact
}
case"$1"in
master)
notify master
exit 0
;;
backup)
notify backup
exit 0
;;
fault)
notify fault
exit 0
;;
*)
echo 'Usage: `basename $0` {master|backup|fault}'
exit 1
;;
esac
[root@node1 keepalived]# chmod +x notify.sh
[root@node1 keepalived]# ./notify.sh master
[root@node1 keepalived]# mail //查看有没有收到通知
Heirloom Mail version 12.47/29/08. Type ? for help.
"/var/spool/mail/root": 1message 1new
>N 1root Wed Sep 2514:5418/668"172.16.6.10 is to bi 172.16.6.100 mas" &
转换状态查看是否会收到通知
1 2 3 4 5 6 7 8 9[root@node1 keepalived]# ./notify.sh backup
[root@node1 keepalived]# ./notify.sh fault
[root@node1 keepalived]# mail
Heirloom Mail version 12.47/29/08. Type ? for help.
"/var/spool/mail/root": 3messages 2new
1root Wed Sep 2514:5419/679"172.16.6.10 is to bi 172.16.6.100 mas" >N 2root Wed Sep 2514:5718/668"172.16.6.10 is to bi 172.16.6.100 mas" N 3root Wed Sep 2514:5718/668"172.16.6.10 is to bi 172.16.6.100 mas" &
说明脚本正常⼯作,那么去编辑配置⽂件1[root@node1 keepalived]# vim keepalived.conf 在全局阶段添加
1 2 3 4 5vrrp_script chk_mantaince_down{ //定义可以⼿动控制状态的脚本 script "[[ -f /etc/keepalived/down ]] && exit 1 || exit 0"
interval 1//检查时间间隔
weight -2//如果检测失败,优先级-2
}
在vrrp阶段添加如下⼏⾏
1 2 3 4 5 6track_script { //引⽤定义的脚本
chk_mantaince_down
}
notify_master"/etc/keepalived/notify.sh master" notify_backup"/etc/keepalived/notify.sh backup" notify_fault"/etc/keepalived/notify.sh fault"
4.2将该脚本复制到另⼀个节点,
1[root@node1 keepalived]# scp notify.sh 172.16.6.1:/etc/keepalived/并在配置⽂件中相应的位置添加相同内容
两个节点都重启服务
4.3让主节点变成从节点
1root@node1 keepalived]# touch down
通过监控,发现主节点⽴即变成从节点,并收到⼀封邮件
1 2[root@node1 keepalived]# tail -f /var/log/messages You have new mail in/var/spool/mail/root
五、实现负载均衡
5.1编辑配置⽂件
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34[root@node1 keepalived]# vim keepalived.conf
#####负载均衡阶段#################
virtual_server 172.16.6.10080{ //指定VIP和端⼝
delay_loop 6//延迟多少个周期再启动服务,做服务检测 lb_algo rr loadbalance 负载均衡调度算法
lb_kind DR 类型
nat_mask 255.255.0.0掩码
persistence_timeout 0持久连接时间
protocol TCP //协议
real_server 172.16.6.1180{ //定义后端realserver的属性 weight 1
HTTP_GET { //定义检测的⽅法
url { //检测的URL
path /
status_code 200//获取结果的状态码
}
connect_timeout 3//连接超时时间
nb_get_retry 3//尝试次数
delay_before_retry 3//每次尝试连接的等待时间 }
}
real_server 172.16.6.1280{ //定义后端realserver的属性 weight 1
HTTP_GET { //定义检测的⽅法
url { //检测的URL
path /
status_code 200//获取结果的状态码
}
connect_timeout 3//连接超时时间
nb_get_retry 3//尝试次数
delay_before_retry 3//每次尝试连接的等待时间
}
}
}
5.2、在从节点上做同样的修改
5.3重启服务并⽤ipvsadm命令检测是否会⽣成规则
1 2 3 4 5 6 7[root@node1 keepalived]# service keepalived restart
[root@node1 keepalived]# ipvsadm -L -n
IP Virtual Server version 1.2.1(size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.16.6.100:80rr
[root@node1 keepalived]#
但是为什么没有我们定义的两个realserver呢?那是因为没启动虚拟机呢,健康状况检测没通过,就不会显⽰了,我们去启动⼀个虚拟机,并启动服务即可。
并执⾏如下命令,做lvs负载均衡的DR模型
1 2 3 4 5 6#ifconfig lo:0172.16.6.11broadcast 172.16.6.11netmask 255.255.255.255up #route add -host 172.16.6.11dev lo:0
#echo 1> /proc/sys/net/ipv4/conf/lo/arp_ignore
#echo 1> /proc/sys/net/ipv4/conf/all/arp_ignore
#echo 2> /proc/sys/net/ipv4/conf/all/arp_announce
#echo 2> /proc/sys/net/ipv4/conf/lo/arp_announce
注:
1、后端的realserver的数量可以添加多台,但是需要在主节点的配置⽂件中给出相应的配置,并在添加的realserver上执⾏相关命令即可
2、尽管keepalived可以⾃⾏添加ipvs规则,实现负载均衡,但是⽆法实现动静分离,在⽣产环境中我们要根据场景选择最佳的⽅案。
六:实现nginx的⾼可⽤
6.1前提
两个节点上都装上nginx服务,并确保httpd没启⽤
# netstat -tunlp //确保80端⼝没占⽤
# service nginx start
6.2为每个节点的nginx编辑⼀个页⾯,以便于效果更直观⼀些
1 2 3 4[root@node1 ~]# vim /usr/share/nginx/html/index.html //节点1 172.16.6.10
[root@node2 ~]# vim /usr/share/nginx/html/index.html //节点2 172.16.6.1
6.3确保nginx可以正常访问6.4然后停掉服务,
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19[root@node1 keepalived]# vim notify.sh //修改脚本,让它可以监测nginx服务,并可以启动或关闭服务##################
case"$1"in
master)
notify master
/etc/rc.d/init.d/nginx start
exit 0
;;
backup)
notify backup
/etc/rc.d/init.d/nginx stop
exit 0
;;
fault)
notify fault
/etc/rc.d/init.d/nginx stop
exit 0
;;
######################################
6.5同步脚本到节点2
1[root@node1 keepalived]# scp notify.sh 172.16.6.1:/etc/keepalived/ 6.6在主节点上
1 2 3 4[root@node1 keepalived]# touch down
[root@node1 keepalived]#ss -tunl //发现80端⼝未被监听[root@node1 keepalived]# rm -f down
[root@node1 keepalived]#ss -tunl //发现80端⼝已经被监听。