前言
负载均衡技术Load Balance简称LB是构建大型网站必不可少的架构策略之一。它的目的是把用户的请求分发到多台后端的设备上,用以均衡服务器的负载。我们可以把负载均衡器划分为两大类:硬件负载均衡器和软件负载均衡器,这里重点介绍软件实现方法中的LVS。
LVS原理介绍和配置实践
更新历史
2019年09月03日 - 拆分LVS-Keepalived中LVS
2019年08月23日 - 更新LVS/NAT、LVS/DR、LVS/TUN三种模式的原理和配置实践
2018年12月03日 - 精简和更新配置步骤
2018年07月31日 - 初稿
阅读原文 - https://wsgzao.github.io/post...
扩展阅读
LVS - http://www.linuxvirtualserver...
Keepalived - http://www.keepalived.org/
ReadMe
参考文章
LVS - http://www.linuxvirtualserver...
How virtual server works? - http://www.linuxvirtualserver...
LVS和Keepalived官方中文手册PDF - https://pan.baidu.com/s/1s0P6...
相关术语
以下术语涉及LVS三种工作模式的原理
- LB (Load Balancer 负载均衡)
- HA (High Available 高可用)
- Failover (失败切换)
- Cluster (集群)
- LVS (Linux Virtual Server Linux 虚拟服务器)
- DS (Director Server),指的是前端负载均衡器节点
- RS (Real Server),后端真实的工作服务器
- VIP (Virtual IP),虚拟的IP地址,向外部直接面向用户请求,作为用户请求的目标的 IP 地址
- DIP (Director IP),主要用于和内部主机通讯的 IP 地址
- RIP (Real Server IP),后端服务器的 IP 地址
- CIP (Client IP),访问客户端的 IP 地址
负载均衡(LB)
负载均衡实现方法有两种:硬件实现和软件实现
硬件比较常见的有:
- F5 Big-IP
- Citrix Netscaler
软件比较常见的有:
- LVS(Linux Virtual Server)
- HAProxy
- Nginx
LVS特点是:
- 首先它是基于4层的网络协议的,抗负载能力强,对于服务器的硬件要求除了网卡外,其他没有太多要求;
- 配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,大大减少了人为出错的几率;
- 应用范围比较广,不仅仅对web服务做负载均衡,还可以对其他应用(mysql)做负载均衡;
- LVS架构中存在一个虚拟IP的概念,需要向IDC多申请一个IP来做虚拟IP。
Nginx负载均衡器的特点是:
- 工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构;
- Nginx安装和配置比较简单,测试起来比较方便;
- 也可以承担高的负载压力且稳定,一般能支撑超过上万次的并发;
- Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测;
- Nginx对请求的异步处理可以帮助节点服务器减轻负载;
- Nginx能支持http和Email,这样就在适用范围上面小很多;
- 默认有三种调度算法: 轮询、weight以及ip_hash(可以解决会话保持的问题),还可以支持第三方的fair和url_hash等调度算法;
HAProxy的特点是:
- HAProxy是工作在网络7层之上;
- 支持Session的保持,Cookie的引导等;
- 支持url检测后端的服务器出问题的检测会有很好的帮助;
- 支持的负载均衡算法:动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash);
- 单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度;
- HAProxy可以对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡。
LVS简介
LVS是一个开源的软件,可以实现LINUX平台下的简单负载均衡。LVS是Linux Virtual Server的缩写,意思是Linux虚拟服务器。
LB 集群的架构和原理很简单,就是当用户的请求过来时,会直接分发到 Director Server 上,然后它把用户的请求根据设置好的调度算法,智能均衡地分发到后端真正服务器 (real server) 上。为了避免不同机器上用户请求得到的数据不一样,需要用到了共享存储,这样保证所有用户请求的数据是一样的。
LVS 是 Linux Virtual Server 的简称,也就是 Linux 虚拟服务器。这是一个由章文嵩博士发起的一个开源项目,它的官方网站是 http://www.linuxvirtualserver... 现在 LVS 已经是 Linux 内核标准的一部分。使用 LVS 可以达到的技术目标是:通过 LVS 达到的负载均衡技术和 Linux 操作系统实现一个高性能高可用的 Linux 服务器集群,它具有良好的可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的性能。LVS 是一个实现负载均衡集群的开源软件项目,LVS 架构从逻辑上可分为调度层、Server 集群层和共享存储。
目前有三种IP负载均衡技术(VS/NAT,VS/TUN,VS/DR)
Virtual Server via Network Address Translation(VS/NAT)
通过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文通过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。
Virtual Server via IP Tunneling(VS/TUN)
采用NAT技术时,由于请求和响应报文都必须经过调度器地址重写,当客户请求越来越多时,调度器的处理能力将成为瓶颈。为了解决这个问题,调度器把请求报 文通过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多,采用 VS/TUN技术后,集群系统的最大吞吐量可以提高10倍。
Virtual Server via Direct Routing(VS/DR)
VS/DR通过改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。同VS/TUN技术一样,VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。
三种模式的主要区别
VS/NAT | VS/TUN | VS/DR | |
---|---|---|---|
server | any | tunneling | non-arp device |
server network | private | LAN/WAN | LAN |
server number | low (10~20) | high | high |
server gateway | load balancer | own router | own router |
模式与特点 | NAT 模式 | IPIP 模式 | DR 模式 |
---|---|---|---|
对服务器的要求 | 服务节点可以使任何操作系统 | 必须支持 IP 隧道,目前只有 Linux 系统支持 | 服务器节点支持虚拟网卡设备,能够禁用设备的 ARP 响应 |
网络要求 | 拥有私有 IP 地址的局域网络 | 拥有合法 IP 地址的局域,网或广域网 | 拥有合法 IP 地址的局域,服务器节点与负载均衡器必须在同一个网段 |
通常支持节点数量 | 10 到 20 个,根据负载均衡器的处理能力而定 | 较高,可以支持 100 个服务节点 | 较高,可以支持 100 个服务节点 |
网关 | 负载均衡器为服务器节点网关 | 服务器的节点同自己的网关或者路由器连接,不经过负载均衡器 | 服务节点同自己的网关或者路由器连接,不经过负载均衡器 |
服务节点安全性 | 较好,采用内部 IP,服务节点隐蔽 | 较差,采用公用 IP 地址,节点安全暴露 | 较差,采用公用 IP 地址,节点安全暴露 |
IP 要求 | 仅需要一个合法的 IP 地址作为 VIP 地址 | 除了 VIPO 地址外,每个服务器界定啊需要拥有合法的 IP 地址,可以直接从路由到客户端 | 除了 VIP 外,每个服务节点需拥有合法的 IP 地址,可以直接从路由到客户端 |
特点 | 地址转换 | 封装 IP | 修改 MAC 地址 |
配置复杂度 | 简单 | 复杂 | 复杂 |
基本工作原理
- 当用户向负载均衡调度器(Director Server)发起请求,调度器将请求发往至内核空间
- PREROUTING链首先会接收到用户请求,判断目标IP确定是本机IP,将数据包发往INPUT链
- IPVS是工作在INPUT链上的,当用户请求到达INPUT时,IPVS会将用户请求和自己已定义好的集群服务进行比对,如果用户请求的就是定义的集群服务,那么此时IPVS会强行修改数据包里的目标IP地址及端口,并将新的数据包发往POSTROUTING链
- POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器,那么此时通过选路,将数据包最终发送给后端的服务器
LVS的组成
LVS 由2部分程序组成,包括 ipvs 和 ipvsadm。
- ipvs(ip virtual server):一段代码工作在内核空间,叫ipvs,是真正生效实现调度的代码。
- ipvsadm:另外一段是工作在用户空间,叫ipvsadm,负责为ipvs内核框架编写规则,定义谁是集群服务,而谁是后端真实的服务器(Real Server)
LVS的3种工作模式
原生只有3种模式(NAT,TUN,DR), fullnat工作模式默认不支持
LVS是四层负载均衡,也就是说建立在OSI模型的第四层——传输层之上,传输层上有我们熟悉的TCP/UDP,LVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡,因此它相对于其它高层负载均衡的解决办法,比如DNS域名轮流解析、应用层负载的调度、客户端的调度等,它的效率是非常高的。
LVS的IP负载均衡技术是通过IPVS模块来实现的,IPVS是LVS集群系统的核心软件,它的主要作用是:安装在Director Server上,同时在Director Server上虚拟出一个IP地址,用户必须通过这个虚拟的IP地址访问服务。这个虚拟IP一般称为LVS的VIP,即Virtual IP。访问的请求首先经过VIP到达负载调度器,然后由负载调度器从Real Server列表中选取一个服务节点响应用户的请求。 当用户的请求到达负载调度器后,调度器如何将请求发送到提供服务的Real Server节点,而Real Server节点如何返回数据给用户,是IPVS实现的重点技术,IPVS实现负载均衡机制有几种,分别是NAT、DR、TUN及FULLNAT。
LVS/NAT
重点理解NAT方式的实现原理和数据包的改变。
(1). 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP
(2). PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
(3). IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP
(4). POSTROUTING链通过选路,将数据包发送给Real Server
(5). Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。 此时报文的源IP为RIP,目标IP为CIP
(6). Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP
LVS/NAT模型的特性
- RS应该使用私有地址,RS的网关必须指向DIP
- DIP和RIP必须在同一个网段内
- 请求和响应报文都需要经过Director Server,高负载场景中,Director Server易成为性能瓶颈
- 支持端口映射
- RS可以使用任意操作系统
- 缺陷:对Director Server压力会比较大,请求和响应都需经过director server
NAT(Network Address Translation 网络地址转换)是一种外网和内外地址映射的技术,内网可以是私有网址,外网可以使用NAT方法修改数据报头,让外网与内网能够互相通信。NAT模式下,网络数据报的进出都要经过LVS的处理。LVS需作为RS(真实服务器)的网关。当包到达LVS时,LVS做目标地址转换(DNAT),将目标IP改为RS的IP。RS接收到包以后,仿佛是客户端直接发给它的一样。RS处理完,返回响应时,源IP是RS IP,目标IP是客户端的IP。这时RS的包通过网(LVS)中转,LVS会做源地址转换(SNAT),将包的源地址改为VIP,这样,这个包对客户端看起来就仿佛是LVS直接返回给它的。客户端无法感知到后端RS的存在。
(1)RIP和DIP必须在同一个IP网络,且应该使用私网地址;RS的网关要指向DIP;
(2)请求报文和响应报文都必须经由Director转发;Director易于成为系统瓶颈;
(3)支持端口映射,可修改请求报文的目标PORT;
(4)vs必须是Linux系统,rs可以是任意系统;
缺点:在整个过程中,所有输入输出的流量都要经过LVS 调度服务器。显然,LVS 调度服务器的网络I/O压力将会非常大,因此很容易成为瓶颈,特别是对于请求流量很小,而响应流量很大的Web类应用来说尤为如此。
优点:NAT模式的优点在于配置及管理简单,由于了使用NAT技术,LVS 调度器及应用服务器可以在不同网段中,网络架构更灵活,应用服务器只需要进行简单的网络设定即可加入集群。
LVS/DR
重点将请求报文的目标MAC地址设定为挑选出的RS的MAC地址
(1) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP
(2) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
(3) IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址,然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址
(4) 由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,那么此时数据包将会发至Real Server。
(5) RS发现请求报文的MAC地址是自己的MAC地址,就接收此报文。处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP,目标IP为CIP
(6) 响应报文最终送达至客户端
LVS/DR模型的特性
- 特点1:保证前端路由将目标地址为VIP报文统统发给Director Server,而不是RS
- RS可以使用私有地址;也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问
- RS跟Director Server必须在同一个物理网络中
- 所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
- 不支持地址转换,也不支持端口映射
- RS可以是大多数常见的操作系统
- RS的网关绝不允许指向DIP(因为我们不允许他经过director)
- RS上的lo接口配置VIP的IP地址
- 缺陷:RS和DS必须在同一机房中
特点1的解决方案:
- 在前端路由器做静态地址路由绑定,将对于VIP的地址仅路由到Director Server
- 存在问题:用户未必有路由操作权限,因为有可能是运营商提供的,所以这个方法未必实用
- arptables:在arp的层次上实现在ARP解析时做防火墙规则,过滤RS响应ARP请求。这是由iptables提供的
- 修改RS上内核参数(arp_ignore和arp_announce)将RS上的VIP配置在lo接口的别名上,并限制其不能响应对VIP地址解析请求。
DR(Direct Routing 直接路由模式)此模式时LVS 调度器只接收客户发来的请求并将请求转发给后端服务器,后端服务器处理请求后直接把内容直接响应给客户,而不用再次经过LVS调度器。LVS只需要将网络帧的MAC地址修改为某一台后端服务器RS的MAC,该包就会被转发到相应的RS处理,注意此时的源IP和目标IP都没变。RS收到LVS转发来的包时,链路层发现MAC是自己的,到上面的网络层,发现IP也是自己的,于是这个包被合法地接受,RS感知不到前面有LVS的存在。而当RS返回响应时,只要直接向源IP(即用户的IP)返回即可,不再经过LVS。
注意:
(1) 确保前端路由器将目标IP为VIP的请求报文发往Director:
(a) 在前端网关做静态绑定;
(b) 在RS上使用arptables;
(c) 在RS上修改内核参数以限制arp通告及应答级别;
arp_announce
arp_ignore
(2) RS的RIP可以使用私网地址,也可以是公网地址;RIP与DIP在同一IP网络;RIP的网关不能指向DIP,以确保响应报文不会经由Director;
(3) RS跟Director要在同一个物理网络;
(4) 请求报文要经由Director,但响应不能经由Director,而是由RS直接发往Client;
(5) 此模式不支持端口映射;
缺点:唯一的缺陷在于它要求LVS 调度器及所有应用服务器在同一个网段中,因此不能实现集群的跨网段应用。
优点:可见在处理过程中LVS Route只处理请求的直接路由转发,所有响应结果由各个应用服务器自行处理,并对用户进行回复,网络流量将集中在LVS调度器之上。
LVS/TUN
在原有的IP报文外再次封装多一层IP首部,内部IP首部(源地址为CIP,目标IIP为VIP),外层IP首部(源地址为DIP,目标IP为RIP)
(1) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。
(2) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
(3) IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP
(4) POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。 此时源IP为DIP,目标IP为RIP
(5) RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。 此时的源IP地址为VIP,目标IP为CIP
(6) 响应报文最终送达至客户端
LVS/TUN模型特性
- RIP、VIP、DIP全是公网地址
- RS的网关不会也不可能指向DIP
- 所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
- 不支持端口映射
- RS的系统必须支持隧道
其实企业中最常用的是 DR 实现方式,而 NAT 配置上比较简单和方便,后边实践中会总结 DR 和 NAT 具体使用配置过程。
TUN(virtual server via ip tunneling IP 隧道)调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文。此转发方式不修改请求报文的IP首部(源IP为CIP,目标IP为VIP),而在原IP报文之外再封装一个IP首部(源IP是DIP,目标IP是RIP),将报文发往挑选出的目标RS;RS直接响应给客户端(源IP是VIP,目标IP是CIP),由于一般网络服务应答数据比请求报文大很多,采用lvs-tun模式后,集群系统的最大吞吐量可以提高10倍
注意:
(1) DIP, VIP, RIP都应该是公网地址;
(2) RS的网关不能,也不可能指向DIP;
(3) 请求报文要经由Director,但响应不能经由Director;
(4) 此模式不支持端口映射;
(5) RS的操作系统得支持隧道功能
缺点:由于后端服务器RS处理数据后响应发送给用户,此时需要租借大量IP(特别是后端服务器使用较多的情况下)。
优点:实现lvs-tun模式时,LVS 调度器将TCP/IP请求进行重新封装并转发给后端服务器,由目标应用服务器直接回复用户。应用服务器之间是通过IP 隧道来进行转发,故两者可以存在于不同的网段中。
LVS/FULLNAT
lvs-fullnat工作模式默认不支持
此模式类似DNAT,它通过同时修改请求报文的源IP地址和目标IP地址进行转发
注意:
(1) VIP是公网地址,RIP和DIP是私网地址,且通常不在同一IP网络;因此,RIP的网关一般不会指向DIP;
(2) RS收到的请求报文源地址是DIP,因此,只需响应给DIP;但Director还要将其发往Client;
(3) 请求和响应报文都经由Director;
(4) 支持端口映射;
LVS的8种调度算法
八种调度算法(rr,wrr,lc,wlc,lblc,lblcr,dh,sh)
针对不同的网络服务需求和服务器配置,IPVS调度器实现了如下八种负载调度算法:
轮叫调度rr(Round Robin)
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。
加权轮叫wrr(Weighted Round Robin)
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
最少链接lc(Least Connections)
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用"最小连接"调度算法可以较好地均衡负载。
加权最少链接wlc(Weighted Least Connections)
在集群系统中的服务器性能差异较大的情况下,调度器采用"加权最少链接"调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
基于局部性的最少链接lblc(Locality-Based Least Connections)
"基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器 是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用"最少链接"的原则选出一个可用的服务 器,将请求发送到该服务器。
带复制的基于局部性最少链接lblcr(Locality-Based Least Connections with Replication)
"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组,按"最小连接"原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按"最小连接"原则从这个集群中选出一 台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的 程度。
目标地址散列dh(Destination Hashing)
"目标地址散列"调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
源地址散列sh(Source Hashing)
"源地址散列"调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
LVS 部署之细枝末节
原作者写得很详细,我这边做下引用在此表示感谢,LVS 部署之细枝末节
简介
本文总结了在 LVS 部署过程中需要注意的一些小细节。这些内容比较杂,并且没有规律和内在联系;它们分散在 LVS 部署过程中的各个小环节中,不是系统性的知识,也没有主线对它们进行连接。你可以通过此文对他们进行一个大概的了解,在实践过程中如果遇到可以再过来进行详细的查阅,以解决实际问题。
开启 Linux 的路由转发功能
LVS 在 VS/NAT 方式下需要开启数据包转发 (ip_forward) 功能。因为在 LVS 的 VS/NAT 模式下,对 IP 数据进行负载均衡时,需要把多台真实服务器节点中的专网 IP 映射到同一个虚拟服务器的公网 IP 上;这就需要通过 NAT 技术对 IP 数据包进行转发,从而将 IP 数据包发送到真实服务器上进行处理。LVS 在 VS/DR 模式下,因为 director 的 DIP 与真实服务器节点的 RIP 在同一网段,所以不需要开启路由转发功能。LVS 在 VS/TUN 模式下,IP 数据包是通过 IP 隧道技术进行封包后再分发的方式到达真实服务器节点的,也不需要开启路由转发功能。
开启 Linux 的路由转发功能的方法很多,具体细节请参阅文章 Linux ip_forward 数据包转发。
配置真实服务器的 ARP 请求与响应策略
在 ARP 协议中,为了减少 arp 请求的次数,当主机接收到询问自己的 arp 请求的时候,就会把源 ip 和源 Mac 放入自 己的 arp 表里面,方便接下来的通讯。如果收到不是询问自己的包(arp 是广播的,所有人都收到),就会丢掉,这样不会造成 arp 表里面无用数据太多导致 有用的记录被删除。
在 LVS 的 VS/DR 模式下,当内网的真实服务器(Linux 主机)要发送一个到外部网络的 ip 包(LVS 负载器分配置过来的作业的处理结果),那么它就会请求路由器的 Mac 地址,发送一个 arp 请求,这个 arp 请求里面包括了自己的 ip 地址和 Mac 地址。而 linux 主机默认是使用 ip 数据包的源 ip 地址作为 arp 里面的源 ip 地址,而不是使用发送设备上面网络接口卡的 ip 地址。这样在 LVS 的 VS/DR 架构下,所有真实服务器在响应外部请求时的 IP 数据包的源地址都是同一个 VIP 地址,那么 arp 请求就会包括 VIP 地址和设备 Mac。而路由器收到这个 arp 请求就会更新自己的 arp 缓存,这样就会造成 ip 欺骗了,VIP 被抢夺,所以就会有问题。
所以当 LVS 运行在 VS/DR 模式下时,需要在所有真实服务器上修改 ARP 请求与响应策略,以保证以上问题不会发生。
因为在 lo(本地环回网络接口)上配置了 VIP,所以需要对真实服务器中的 ARP 请求与响应策略配置如下:
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.lo.arp_announce=2
将以上代码段追加到 /etc/sysctl.conf 文件中,然后执行 sysctl -p
指令就可以。以上配置的具体含义请参阅 Linux 内核参数 arp_ignore & arp_announce 详解。
在 VS/DR 模式下 VIP 、DIP 和 RIP 必须在同一网段吗?
在 VS/DR 模式下 VIP 、DIP 和 RIP 不需要在同一网段!
其中 VIP 必须是公网 IP;而 DIP 和 RIP 必须在同一网段(可以是任意网段的 IP,也可以是私网 IP),且需要节点主机的 RIP 可以把 IP 数据包发送到一个能把 IP 数据包路由到公网的路由器上。
其实 LVS 在 VS/DR 模式下的要求是 DIP 和 RIP 必须处于同一网段中。在实际的部署过程中发现如果在 Director 上 VIP 和 DIP 在同一网段、或在 RealServer 上 VIP 与 RIP 在同一网段,LVS 集群工作会很不稳定。因为当一个 IP 数据包需要发到默认网关时(在 RealServer 或 Director 上),Linux 主机不知道应该使用哪个接口(在同一子网中的 VIP 和 DIP/RIP),他可能会随机选一个,但这个不一定能成功。我感觉可以通过在 Linux 中配置路由表来解决,但没有验证(哪位同学如果有兴趣可以实践验证一下,如果能把验证结果反馈给我那是再好不过了)。
配置真实服务器的 反向路由过滤 策略
在 Linux 中用于对 网卡的反向路由过滤策略进行配置的内核参数是 rp_filter,有关此参数的详细介绍以及配置方式请参见 Linux 内核参数 rp_filter。
LVS 在 VS/TUN 模式下,需要对 tunl0 虚拟网卡的反向路由过滤策略进行配置。最直接的办法是把其值设置为 0。
net.ipv4.conf.tunl0.rp_filter=0
net.ipv4.conf.all.rp_filter=0
因为 Linux 系统在对网卡应用反向路由过滤策略时,除了检查本网卡的 rp_filter 参数外,还会检查 all 配置项上的 rp_filter 参数,并使用这两个值中较大的值作为应用到当前网卡的反向路由过滤策略。所以需要同时把 net.ipv4.conf.all.rp_filter
参数设置为 0。
配置 tunl0 网卡
LVS 在 VS/TUN 模式下,需要在每个真实服务器上开启 tunl0 网卡,并把 VIP 配置到 tunl0 网卡上。有关 tunl0 网卡的说明可以参考一下 Linux 中 IP 隧道模块浅析。
LVS 在 VS/TUN 模式下 RealServer 上的防火墙配置
LVS 在 VS/TUN 模式下 因为 Director 主机需要通过 ipip 协议向 RealServer 分发数据包;所以需要在 RealServer 上配置防火墙,允许 ipip 协议的数据包通过。
iptables -I INPUT 1 -p 4 -j ACCEPT
ipvsadm
一般建议和Keepalived配置文件搭配使用
命令
[root@d126009 wangao]# ipvsadm -h
ipvsadm v1.27 2008/5/15 (compiled with popt and IPVS v1.2.1)
Usage:
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] [--pe persistence_engine] [-b sched-flags]
ipvsadm -D -t|u|f service-address
ipvsadm -C
ipvsadm -R
ipvsadm -S [-n]
ipvsadm -a|e -t|u|f service-address -r server-address [options]
ipvsadm -d -t|u|f service-address -r server-address
ipvsadm -L|l [options]
ipvsadm -Z [-t|u|f service-address]
ipvsadm --set tcp tcpfin udp
ipvsadm --start-daemon state [--mcast-interface interface] [--syncid sid]
ipvsadm --stop-daemon state
ipvsadm -h
Commands:
Either long or short options are allowed.
--add-service -A add virtual service with options
--edit-service -E edit virtual service with options
--delete-service -D delete virtual service
--clear -C clear the whole table
--restore -R restore rules from stdin
--save -S save rules to stdout
--add-server -a add real server with options
--edit-server -e edit real server with options
--delete-server -d delete real server
--list -L|-l list the table
--zero -Z zero counters in a service or all services
--set tcp tcpfin udp set connection timeout values
--start-daemon start connection sync daemon
--stop-daemon stop connection sync daemon
--help -h display this help message
Options:
--tcp-service -t service-address service-address is host[:port]
--udp-service -u service-address service-address is host[:port]
--fwmark-service -f fwmark fwmark is an integer greater than zero
--ipv6 -6 fwmark entry uses IPv6
--scheduler -s scheduler one of rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,
the default scheduler is wlc.
--pe engine alternate persistence engine may be sip,
not set by default.
--persistent -p [timeout] persistent service
--netmask -M netmask persistent granularity mask
--real-server -r server-address server-address is host (and port)
--gatewaying -g gatewaying (direct routing) (default)
--ipip -i ipip encapsulation (tunneling)
--masquerading -m masquerading (NAT)
--weight -w weight capacity of real server
--u-threshold -x uthreshold upper threshold of connections
--l-threshold -y lthreshold lower threshold of connections
--mcast-interface interface multicast interface for connection sync
--syncid sid syncid for connection sync (default=255)
--connection -c output of current IPVS connections
--timeout output of timeout (tcp tcpfin udp)
--daemon output of daemon information
--stats output of statistics information
--rate output of rate information
--exact expand numbers (display exact values)
--thresholds output of thresholds information
--persistent-conn output of persistent connection info
--nosort disable sorting output of service/server entries
--sort does nothing, for backwards compatibility
--ops -o one-packet scheduling
--numeric -n numeric output of addresses and ports
--sched-flags -b flags scheduler flags (comma-separated)
测试
# 每台realserver index.html文件内容为ip 地址,例如httpd:
echo "172.27.233.43" > /var/www/html/index.html
echo "172.27.233.44" > /var/www/html/index.html
# Nginx test
echo "rs1" > /usr/share/nginx/html/index.html
echo "rs2" > /usr/share/nginx/html/index.html
# 启动http服务
/etc/init.d/httpd start
# 客户端模拟请求
for((i=1;i<=10;i++));do curl http://172.27.233.45/; done
172.27.233.44
172.27.233.43
172.27.233.44
172.27.233.43
172.27.233.44
172.27.233.43
172.27.233.44
172.27.233.43
172.27.233.44
172.27.233.43
# 请求分配结果
ipvsadm -Ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 172.27.233.45:80 10 50 0 4330 0
-> 172.27.233.43:80 5 25 0 2165 0
-> 172.27.233.44:80 5 25 0 2165 0
参数含义
--stats 显示统计信息
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
连接数 输入包 输出包 输入流量 输出流量
# 实时观察
watch ipvsadm -Ln --stats
LVS和Keepalived系列
LVS和Keepalived的原理介绍和配置实践
LVS原理介绍和配置实践
Keepalived原理介绍和配置实践
LVS-NAT原理介绍和配置实践
LVS-DR原理介绍和配置实践
LVS-TUN原理介绍和配置实践
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。