前言
负载均衡技术 Load Balance 简称 LB 是构建大型网站必不可少的架构策略之一。它的目的是把用户的请求分发到多台后端的设备上,用以均衡服务器的负载。我们可以把负载均衡器划分为两大类:硬件负载均衡器和软件负载均衡器,这里重点介绍软件实现方法中的 LVS。
负载均衡(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 三种工作模式的原理
- 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 地址
LVS 简介
LVS 是一个开源的软件,可以实现 LINUX 平台下的简单负载均衡。LVS 是 Linux Virtual Server 的缩写,意思是 Linux 虚拟服务器。
LB 集群的架构和原理很简单,就是当用户的请求过来时,会直接分发到 Director Server 上,然后它把用户的请求根据设置好的调度算法,智能均衡地分发到后端真正服务器 (real server) 上。为了避免不同机器上用户请求得到的数据不一样,需要用到了共享存储,这样保证所有用户请求的数据是一样的。
LVS 是 Linux Virtual Server 的简称,也就是 Linux 虚拟服务器。这是一个由章文嵩博士发起的一个开源项目,它的官方网站是 http://www.linuxvirtualserver.org 现在 LVS 已经是 Linux 内核标准的一部分。使用 LVS 可以达到的技术目标是:通过 LVS 达到的负载均衡技术和 Linux 操作系统实现一个高性能高可用的 Linux 服务器集群,它具有良好的可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的性能。LVS 是一个实现负载均衡集群的开源软件项目,LVS 架构从逻辑上可分为调度层、Server 集群层和共享存储。
LVS 的组成
LVS 由 2 部分程序组成,包括 ipvs 和 ipvsadm。
- ipvs(ip virtual server):一段代码工作在内核空间,叫 ipvs,是真正生效实现调度的代码。
- ipvsadm:另外一段是工作在用户空间,叫 ipvsadm,负责为 ipvs 内核框架编写规则,定义谁是集群服务,而谁是后端真实的服务器 (Real Server)
LVS 和 Keepalived
在 lvs+keepalived 环境里面,lvs 主要的工作是提供调度算法,把客户端请求按照需求调度在 real 服务器,keepalived 主要的工作是提供 lvs 控制器的一个冗余,并且对 real 服务器做健康检查,发现不健康的 real 服务器,就把它从 lvs 集群中剔除,real 服务器只负责提供服务。
LVS的工作模型
LVS/NAT
Virtual Server via Network Address Translation(VS/NAT)
LVS-NAT 模型类似于 DNAT,工作机制与 DNAT 一样,当客户端请求的是集群服务时,LVS 修改请求报文的目标地址为 RIP,转发至后端的 RealServer,并修改后端响应报文的源地址为 VIP,响应至客户端。
过程:重点理解 NAT 方式的实现原理和数据包的改变。
- 当用户请求到达 Director Server,此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源 IP 为 CIP,目标 IP 为 VIP
- PREROUTING 检查发现数据包的目标 IP 是本机,将数据包送至 INPUT 链
- IPVS 比对数据包请求的服务是否为集群服务,若是,修改数据包的目标 IP 地址为后端服务器 IP,然后将数据包发至 POSTROUTING 链。 此时报文的源 IP 为 CIP,目标 IP 为 RIP
- POSTROUTING 链通过选路,将数据包发送给 Real Server
- Real Server 比对发现目标为自己的 IP,开始构建响应报文发回给 Director Server。 此时报文的源 IP 为 RIP,目标 IP 为 CIP
- 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 的存在。
- RIP 和 DIP 必须在同一个 IP 网络,且应该使用私网地址;RS 的网关要指向 DIP;
- 请求报文和响应报文都必须经由 Director 转发;Director 易于成为系统瓶颈;
- 支持端口映射,可修改请求报文的目标 PORT;
- vs 必须是 Linux 系统,rs 可以是任意系统;
缺点:在整个过程中,所有输入输出的流量都要经过 LVS 调度服务器。显然,LVS 调度服务器的网络 I/O 压力将会非常大,因此很容易成为瓶颈,特别是对于请求流量很小,而响应流量很大的 Web 类应用来说尤为如此。
优点:NAT 模式的优点在于配置及管理简单,由于了使用 NAT 技术,LVS 调度器及应用服务器可以在不同网段中,网络架构更灵活,应用服务器只需要进行简单的网络设定即可加入集群。
LVS-DR
DR 值 Direct Routing,直接路由,DR 模型中,Director 和 Realserver 处在同一网络中,对于 Director,VIP 用于接受客户端请求,DIP 用于和 Realserver 通信。对于 Realserver,每个 Realserver 都配有和 Director 相同的 VIP(此 VIP 隐藏,关闭对 ARP 请求的响应),仅用户响应客户端的请求,RIP 用于和 Director 通信。
当客户端请求集群服务时,请求报文发送至 Director 的 VIP(Realserver的 VIP 不会响应 ARP 请求),Director 将客户端报文的源和目标 MAC 地址进行重新封装,将报文转发至 Realserver,Realserver 接收转发的报文。此时报文的源 IP 和目标 IP 都没有被修改,因此 Realserver 接受到的请求报文的目标 IP 地址为本机配置的 VIP,它将使用自己的 VIP 直接响应客户端。
LVS-DR 模型中,客户端的响应报文不会经过 Director,因此 Director 的并发能力有很大提升。
过程:重点将请求报文的目标 MAC 地址设定为挑选出的 RS 的 MAC 地址
- 当用户请求到达 Director Server,此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源 IP 为 CIP,目标 IP 为 VIP
- PREROUTING 检查发现数据包的目标 IP 是本机,将数据包送至 INPUT 链
- IPVS 比对数据包请求的服务是否为集群服务,若是,将请求报文中的源 MAC 地址修改为 DIP 的 MAC 地址,将目标 MAC 地址修改 RIP 的 MAC 地址,然后将数据包发至 POSTROUTING 链。 此时的源 IP 和目的 IP 均未修改,仅修改了源 MAC 地址为 DIP 的 MAC 地址,目标 MAC 地址为 RIP 的 MAC 地址
- 由于 DS 和 RS 在同一个网络中,所以是通过二层来传输。POSTROUTING 链检查目标 MAC 地址为 RIP 的 MAC 地址,那么此时数据包将会发至 Real Server。
- RS 发现请求报文的 MAC 地址是自己的 MAC 地址,就接收此报文。处理完成之后,将响应报文通过 lo 接口传送给 eth0 网卡然后向外发出。 此时的源 IP 地址为 VIP,目标 IP 为 CIP
- 响应报文最终送达至客户端
LVS-DR 模型的特性:
- 保证前端路由器将目标地址为 VIP 的报文通过 ARP 解析后送往 Director。
- 静态绑定:在前端路由将 VIP 对应的目标 MAC 地址静态配置为Director VIP 接口的 MAC 地址。
- arptables:在各 Realserver 上,通过 arptables 规则拒绝其响应对 VIP 的 ARP 广播请求
- 修改内核参数:在 Realserver 上修改内核参数,并结合地址的配置方式实现拒绝响应对 VIP 的 ARP 广播请求
- 各RIP 必须与 DIP 在同一个物理网络中
- RS 的 RIP 可以使用私有地址,也可以使用公网地址,以方便配置
- Director 仅负责处理入站请求,响应报文由 Realserver 直接发往客户端
- Realserver 不能将网关指向 DIP,而直接使用前端网关
- 不支持端口映射 由于数据返回不走director ,而是直接由 realserver返回给用户。所认其承载能力比较强,单台lvs dr模式下后端负载的realserver 数量可以达到100台。不过也因为其比较简单,只有四层处理能力,所以其无法对后端server 的健康状态做检查。
LVS-TUN
和 DR 模型类似,Realserver 都配有不可见的 VIP,Realserver 的 RIP 是公网地址,且可能和 DIP 不再同一网络中。当请求到达 Director 后,Director 不修改请求报文的源 IP 和目标 IP 地址,而是使用 IP 隧道技术,使用 DIP 作为源 IP,RIP 作为目标 IP 再次封装此请求报文,转发至 RIP 的 Realserver 上,Realserver 解析报文后仍然使用 VIP 作为源地址响应客户端。
过程
- 当用户请求到达 Director Server,此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源 IP 为 CIP,目标 IP 为 VIP 。
- PREROUTING 检查发现数据包的目标 IP 是本机,将数据包送至 INPUT 链
- IPVS 比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层 IP 报文,封装源 IP 为 DIP,目标 IP 为 RIP。然后发至 POSTROUTING 链。 此时源 IP 为 DIP,目标 IP 为 RIP
- POSTROUTING 链根据最新封装的 IP 报文,将数据包发至 RS(因为在外层封装多了一层 IP 首部,所以可以理解为此时通过隧道传输)。 此时源 IP 为 DIP,目标 IP 为 RIP
- RS 接收到报文后发现是自己的 IP 地址,就将报文接收下来,拆除掉最外层的 IP 后,会发现里面还有一层 IP 首部,而且目标是自己的 lo 接口 VIP,那么此时 RS 开始处理此请求,处理完成之后,通过 lo 接口送给 eth0 网卡,然后向外传递。 此时的源 IP 地址为 VIP,目标 IP 为 CIP
- 响应报文最终送达至客户端
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 倍
注意:
- DIP, VIP, RIP 都应该是公网地址;
- RS 的网关不能,也不可能指向 DIP;
- 请求报文要经由 Director,但响应不能经由 Director;
- 此模式不支持端口映射;
- RS 的操作系统得支持隧道功能
缺点: 由于后端服务器 RS 处理数据后响应发送给用户,此时需要租借大量 IP(特别是后端服务器使用较多的情况下)。
优点: 实现 lvs-tun 模式时,LVS 调度器将 TCP/IP 请求进行重新封装并转发给后端服务器,由目标应用服务器直接回复用户。应用服务器之间是通过 IP 隧道来进行转发,故两者可以存在于不同的网段中。
LVS 的调度算法
八种调度算法(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
ipvsadm 用于配置 LVS 的调度规则,管理集群服务和 Realserver
管理集群服务
添加:-A -t|u|f service-address [-s scheduler]
-t: TCP协议的集群
-u: UDP协议的集群
service-address: IP:PORT
-f: FWM: 防火墙标记
service-address: Mark Number
修改:-E
删除:-D -t|u|f service-address
例如:
ipvsadm -A -t 10.10.0.1:80 -s rr
管理集群服务中的 RS
添加:-a -t|u|f service-address -r server-address [-g|i|m] [-w weight]
-t|u|f service-address:事先定义好的某集群服务
-r server-address: 某RS的地址,在NAT模型中,可使用IP:PORT实现端口映射;
[-g|i|m]: LVS类型
-g: DR
-i: TUN
-m: NAT
[-w weight]: 定义服务器权重
修改:-e
删除:-d -t|u|f service-address -r server-address
例如:
ipvsadm -a -t 10.10.0.2:80 -r 192.168.10.8 -m
ipvsadm -a -t 10.10.0.3:80 -r 192.168.10.9 -m
查看规则
-L|-l
-n:数字格式显式主机地址和端口
--stats:统计数据
--rate: 速率
--timeout: 显示tcp、tcpfin和udp的会话超时时长
-c: 显示当前的ipvs连接状况
删除所有集群服务
-C:清空 ipvs 规则
保存规则
ipvsadm -S > /path/to/somefile
载入保存的规则
ipvsadm -R < /path/from/somefile
http://www.361way.com/lvs-nat/5187.html
http://www.361way.com/lvs-dr/5192.html
http://www.361way.com/lvs-persistent-healthy-check/5204.html
http://liaoph.com/lvs/