深入理解keepalived+lvs
2017-03-22 19:23
232 查看
深入理解keepalived+lvs
keepalived篇:
master和bakeup之间的通信(vrrp协议)
master : 172.25.88.1bakeup :172.25.88.21.在matser上抓vrrp的包
[root@server1 ~]# /etc/init.d/keepalived start Starting keepalived: [ OK ] [root@server1 ~]# tcpdump vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:07:23.710761 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20 15:07:24.711710 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20 15:07:25.712926 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20 15:07:26.713916 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20 15:07:27.714890 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20发现master在向224.0.0.18发送广播包,分析包文的值优先级为102,是我们的master
2.在bakeup上抓vrrp的包
[root@server2 ~]# /etc/init.d/keepalived start Starting keepalived: [ OK ] [root@server2 ~]# tcpdump vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:07:38.022848 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20 15:07:39.023899 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20 15:07:40.024861 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20 15:07:41.025770 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20 15:07:42.026831 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20由此发现,master工作时,bakeup不发送vrrp包,只是接受并返回master的包
3.将master的keepalived down了
[root@server1 ~]# /etc/init.d/keepalived stop Stopping keepalived: [ OK ]再次抓包
[root@server1 ~]# tcpdump vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:22:43.293115 IP 172.25.88.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 52, authtype simple, intvl 1s, length 20 15:22:44.293714 IP 172.25.88.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 52, authtype simple, intvl 1s, length 20 15:22:45.294471 IP 172.25.88.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 52, authtype simple, intvl 1s, length 20由优先级 prio 52可知,现在已经是bakeup在组播vrrp包。
总结:master只发不收,bakeup反之
其他主机也收不到vrrp包,因为有route_id限制
关于接管
BACKUP在确认没有收到MASTER的广播报文后,会主动发送组播报文,声明自己的keepalived状态,随后启用VIP。正式接管keepliaved。关于谁来当master
1.当两个state均为master时,prio大的为master2.当两个state均为master时且prio优先级相同时,双方都认为自己是master,双方会出现抢占ip的情况,导致地址冲突。特殊说明
1.实现不回切 bakeupvim /etc/keepalived/keepalived.conf29 no preempt 非抢占模式 30 priority 150 且proi要比master大,我的master的proi为1002.主备的virtual_router_id要相同,否则都会发组播报文
virtual_router_id 188
lvs篇
lvs-why
传统:DNS负载均衡缺点:
1.服务调度算法只支持WRR 2.攻击防御能力很弱,每次有攻击靠一台机器抗。 3.如果server宕了,运维就只能把server的ip从DNS中删除,但localDNS有大量的缓存,至于删除操作什么时候生效不可控.
工作机制
我们都知道netfilter加载iptables模块,实现了防火墙。其实lvs,就是netfilter加载ipvs模块实现的!lvs分为ipvs(内核)和ipvsadm(用户空间)两部分:用户用过ipvsadm编写策略,而内核加载ipvs在netfilter生效!ipvs 结合input链(钩子函数在链上)工作,发现用户请求的是一个集群服务,就转发至forward,转发至postrouting链,进入RS(后端服务器 )。类型
1.nat 地址转换定义:多目标的dnat(目标地址转换)
cip->vip->rip->vip->cip进出的连接都要经过DS,DR压力大,只能负载均衡10个rs左右。
rule:
)DR和RS必须在同一个网络中。 2)RS网关指向DIP,因为DR要修改目的地址由VIP->RIP 3)RIP为私有地址,仅用于集群通信。 4)DR位于client和real server之间,负责处理所有通信,亚历山大,成为瓶颈。 5)DR支持端口映射。 6)RS可以使用任意系统 7) NAT模式可以防DDOS
2.dr 直接路由
原理:DS在数据链路层直接修改mac地址,源IP和目标IP都没有改变
只有进入的连接经过DS,能负载均衡100个rs左右。DS:dip,vip
RS:rip,vip
vip是隐藏的,仅仅作为源地址不通信。可以配置在lo上,或者设置arp防火墙,
通信还是靠rip所在的网络设备
rule: 1)DR和RS必须在同一个物理网络中(同一网段) 2)RS一定网关不能指向DIP。 3)RIP不一定是私有地址,可以ssh上来管理,但有危险。 4)DR仅处理入栈请求,响应报文由RS发往client。 5)DR不支持端口映射,因为请求端口的时候,RS直接响应。 6)RS可以使用大多数操作系统,因为RS要隐藏vip。。
3.tun 隧道
基本同DR,但转发的时候,要封装隧道,再添加一个ip首部。rule:
1)DR和RS必须可以跨越互联网 2)RIP必须是公网地址 3)DR仅处理入栈请求,响应报文由RS发往client。 4)响应报文一定不能通过DR 5)不支持端口映射 6)RS必须支持隧道协议OS4.fullnat
调度算法(schedule method)
分为静态和动态:动态则考虑服务器的负载。静态调度算法(4个)
1.rr(轮叫调度) 2.wrr(加权轮叫) 3.sh(源地址哈希):基于session的会话绑定。一个用户访问过某个RS,下次访问就由这个RS给他提供服务。 4.dh(目的地址哈希):不同用户,相同的访问需求,就访问同一个RS。
活动链接(active):客户与服务器建立连接并且有数据传送非活动链接(inactive):只是建立连接,没有数据传送,没有断开连接
动态调度算法(6个)
1.lc(最少链接): 算法:active*256 + inactive 因为在实际生产环境中,inactive的数量是巨大的,所以不能忽略
2.wlc(加权最少链接) LVS的默认算法 算法:active*256+inactive)/weight 比lc多考虑了权重 3.sed(最短期望延迟) 基于wlc算法,避免wlc出现的问题。 算法:(active+1)*256/weight (活动的连接数+1)*256/除以权重 谁小发给谁
4.nq(用不排队) 谁的链接数为0,直接将请求发送给他,一般和sed结合使用,因为有些机器即使空着也调度不到他。
5.LBLC(基于本地的最少连接)类似于dh,目标地址hash 这个算法主要用于Cache集群系统,因为Cache集群的中客户请求报文的目标IP地址的变化,将相同的目标URL地址请求调度到同一台服务器,来提高服务器的访问的局部性和Cache命中率。从而调整整个集群的系统处理能力。但是,如果realserver的负载处于一半负载,就用最少链接算法,将请求发送给活动链接少的主机。
6.LBLCR(带复制的基于本地的最少链接) 该算法首先是基于最少链接的,当一个新请求收到后,一定会将请求发给最少连接的那台主机的。但这样又破坏了cache命中率。但这个算法中,集群服务是cache共享的,假设A的PHP跑了一遍,得到缓存。但其他realserver可以去A那里拿缓存,这是种缓存复制机制。
各种术语
DS:Director Server。前端负载均衡调度器。 RS:Real Server。后端真实工作的服务器。 VIP:向外部直接面向用户请求,作为用户请求的目标的IP地址。 DIP:Director Server IP,主要用于和服务器内部通讯的IP。 RIP:Real Server IP,后端真实服务器的IP地址。 CIP:Client IP,客户端的IP地址。 端口映射:如用户访问80,可在RS上服务实际工作在8080。(只有dnat支持)
相关文章推荐
- LVS原理深入理解
- lvs中ipvsadm的ActiveConn和InActConn的深入理解
- lvs中ipvsadm的ActiveConn和InActConn的深入理解
- 转载--LVS之原理篇--深入全面理解LVS工作原理
- lvs中ipvsadm的ActiveConn和InActConn的深入理解
- LVS之原理篇--深入全面理解LVS工作原理
- Linux keepalived与lvs的深入分析
- lvs中ipvsadm的ActiveConn和InActConn的深入理解
- 解读 LWUIT 之七:深入理解 LWUIT 框架的 MVC
- 深入理解DefaultMessageListenerContainer
- 深入理解Scroll Views
- 深入理解Java并发之synchronized实现原理
- 深入理解 Java 虚拟机(一)走近 Java
- 深入理解python之self
- 深入理解abstract class和interface
- (转)深入理解Flash Player的安全域(Security Domains)
- 深入理解Java内存模型 volatile
- 深入理解spring事务管理
- 深入理解打包和织网
- 深入理解JVM内幕:从基本结构到Java 7新特性