LVS简介
背景与功能
LVS全称为Linux Virtual Server,是国内常见的Load-Balance工具软件。除了能够在常见的UDP,TCP等OIS-4层协议上实现LB外,它也能为提供FTP、HTTP等典型应用层协议提供LB功能。
相比F5等硬件Load-Balance工具,它不需要专门的硬件工具;对比于Nginx等代理,LVS所有工作都在内核态运行,不涉及数据拷贝和内核态/用户态切换,性能是其最大的优势。
LVS的核心包括IPVS模块、KTCPVS模块以及一些其他集群管理模块:
- IPVS:一款基于IP、端口的报文转发工具,已经被集成至Linux内核之中。
- KTCPVS:提供应用层流量转发功能。
因为其性能的优异性,目前使用最多的便是基于IPVS构建的LVS系统。本文主要阐述IPVS系统的原理以及LVS系统基本搭建方式。
IPVS系统原理
netfilter/iptables简介
netfilter/iptables属于Linux内核的一部分,它提供了一整套API可供用户自定义对于IP报文的处理方式,用户可以通过这一模块自由组合IP报文的处理方式,实现Linux防火墙功能。
数据包在netfilter/iptables中的流转如上图所示,一共有6个阶段用户可以通过注册回调函数的方式对数据包进行处理。每一个阶段都有对应的链表用于存储所有规则,IP报文将根据链表顺序依次经过每一个规则。因此,在不丢弃数据包的情况下,一个用于转发的ip报文将根据上图依次流经PreRouting、Forward、PostRouting,经过所有规则处理后再流转出去。
随着业务的增加,iptables对于报文处理的链条可能会变得很长,为了便于组织,iptables根据规则的用途对其进行了聚类。所有规则都根据自身通途被放到了4个table中,这也就是名称中table的由来。
表名 | 功能 | 涉及阶段 |
---|---|---|
Filter(Default) | 过滤IP报文 | FORWARD、INPUT、OUTPUT |
Nat | 转发IP报文 | PREROUTING、POSTROUTING、OUTPUT |
Mangle | 对IP报文进行修改和处理 | PREROUTING、POSTROUTING、INPUT、OUTPUT、FORWARD |
Raw(后续加入) | 决定数据包是否被跟踪机制处理 | OUTPUT、PREROUTING |
IP报文在整个netfilter/iptables模块流转如下图
iptables的不足
随着路由规则的逐渐增多,iptables会慢慢显现出它的先天不足:由于iptables采用链表来组织规则列表,每个IP报文将流经链表中每一项的处理,即使对其产生作用的只有一项或很少的几项。最典型的例子便是用作网关路由转发,如果集群内部存在成千上万的服务端口需要在网关server的iptables上配置路由转发规则,那么网关server的iptables chain将到达数千甚至数万的长度,任何IP通过iptables时都会在每个规则处判断一次,但是其中只有一条规则是用来处理该IP报文的。因此,iptables在大规模集群的情况下转发IP报文的效率不够高
。
iptables引入了ipset来解决IP报文的匹配问题。简单来说,用户可以通过ipset创建一个包含ip或者端口的集合,然后以这个集合作为iptables规则链的判断条件,如果IP报文满足ipset条件,iptables则执行对应的操作。通过引入Set这一数据结构,iptables可以将match操作的时间复杂度从O(N)变为O(1)。但是ipset常用于Filter模块,无法用于Nat转发模块。
作为一个防火墙模块,iptables对于IP报文的处理相对简单,缺乏轮询,加权轮询,最短连接等负载均衡算法的支持。
IPVS
IPVS通过向INPUT阶段的规则链中注册回调函数,解决iptables/netfilter模块上述两个缺点,从而实现高效率、功能完备的LoadBalance功能。
- 当用户访问www.sina.com.cn时,DNS会将此域名解析为一个Virtual IP,指向LVS server
- 数据包进入Server后,通过物理层、数据链路层等层层递进,达到iptables模块中
- 进入PREROUTING后,Server发现报文中的VIP指向本机,于是将这个报文丢入INPUT chain中
- 当IP报文进入IPVS处理逻辑时,IPVS首先会根据VIP+Port判断此数据包是否需要进行转发,经过确认后将根据预设算法选出对该数据包进行实际处理的RealServer,随后将数据包进行修改,不经过应用程序以及OUTPUT链,直接丢入POSTROUTING中
- POSTROUTING收到数据包后将根据数据包的信息通过路由选路,最终将数据包发到选中的RealServer上。
根据路由转发规则的不同,开源LVS有三种工作模式,分别适用于不同场景:
- DirectRouting 模式
- NAT 模式
- Tunnel 模式
DR模式
如上图所示,lvs-DR模式工作原理如下
- 数据包从客户端处经过层层转发至LVS-Server处,此时数据包的源IP为客户端IP地址,目的IP为LVS-Server服务器IP地址,源MAC地址为路由器MAC地址,目的MAC地址为LVS-Server的MAC地址。
- LVS-Server对发向虚IP的数据包做一定处理:根据负载均衡算法得到一个真正负载请求的RealServer,并 将数据包的目标MAC地址变为RealServer的MAC地址,并将数据包发给RealServer。此时数据包的源IP地址与目的IP地址都未修改,源MAC地址变为LVS-Server与RealServer相通网卡的MAC地址,目的MAC地址变为RealServer的MAC地址。
- RealServer接收并处理请求,回应将被直接发送给Client。具体IP与MAC情况请见上图。
DR模式的核心原理便是通过修改IP报文MAC地址,使请求报文根据负载均衡算法将请求分摊至多个RealServer上。 DR模式最大的优点便是性能高:所有的响应数据由RealServer直接返回给Client,整个系统最大的瓶颈LVS-Server只需要处理请求数据,而且通常来说请求的数据是远小于响应数据的,使用DR模式的LVS系统整体性能最优。 由于数据转发是通过修改MAC地址实现,因此LVS-DR模式最大的缺点在于限制了LVS-Server必须与RealServer处于同一交换机环境中。
NAT模式
LVS的NAT模式可以简单认为就是iptables路有规则的增强版,其完全运行于ip层之上,通过修改源IP与目的IP的方式实现负载均衡转发。最关键的改进在于查找路由规则时将iptables原本O(n)的链式判断变为了Map O(1)级别,加快了转发的效率。
NAT 模式双向流量都经过 LVS,因此 NAT 模式性能会存在一定的瓶颈。不过与其它模式区别的是,NAT 支持端口映射,且支持 windows 操作系统。
Tunnel模式
Tunnel模式结合了NAT模式与DR模式的优点,通过在IP报文外面再包裹一层的方式使得转发突破了DR模式下只能同一物理网络部署的限制,同时可以实现NAT模式的端口转发功能;由于响应报文不会再次经过LVS服务器,因此Tunnel模式理论上可以达到接近DR的性能水平。
Tunnel 模式具备 DR 模式的高性能,又支持跨机房访问,听起来比较完美了。不过国内运营商有一定特色性,比如 RS 的响应数据包的源 IP 为 VIP,VIP 与后端服务器有可能存在跨运营商的情况,有可能被运营商的策略封掉。Tunnel 在生产环境确实没有使用过,在国内推行 Tunnel 可能会有一定的难度。
keepalived
作为与LVS搭配使用的组件,keepalived保证了LVS系统下的高可用性:
1.LVS 服务器本身的高可用性 2.后端多台RS的故障嗅探,实时从集群中移除无法正常工作的RS,待其正常后再次加入负载均衡集群
VRRP
keepalived服务器本身的高可用性是通过VRRP协议实现的:一组高可用服务器将被划分至同一个虚拟广播网段中,该网段可通过vrid
进行区分,且通过认证协议进行身份校验。一组高可用服务器中只会存在一个MASTER节点,其他都是冗余BACKUP节点,每个节点有两个关键值,分别是priority
以及state
,当多台服务器都处于正常工作状态时,总是priority
以MASTER身份工作,如果两台及以上服务器的priority
相同,则根据state预设值进行区分。集群中的Master节点会不断向所有节点发送广播表明自己存活,当BACKUP节点一段时间没有收到MASTER节点的广播时,则认为MASTER已经失效了,于是按照预设规则进行选举,另起一个新的Master。
当MASTER恢复后,又会通过广播接管整个集群,如下图所示
![keepavlived-master-recovery]
故障嗅探
keepalived的RS故障嗅探功能与其他网关基本一致,通过轮询的方式验证下游服务是否存活,并动态移除非活跃服务/增加活跃服务。它提供的嗅探方式包括:TCP
,HTTP
,SSL
,MISC
。