LVS是Linux Virtual Server的简写, 意思是Linux虚拟服务器, 是一个虚拟的服务器集群系统.
LVS的宗旨:
1. 使用集群技术和Linux操作系统实现一个高性能, 高可用的服务器;
2. 很好的可伸缩性(Scalability);
3. 很好的可靠性(Reliability);
4. 很好的可管理性(Manageability).
LVS的集群组成
LVS采用三层结构, 主要组成部分有:
(1) 负载调度器(load balancer), 它是整个集群对外的前端机, 负责将客户的请求发送到一组服务器上执行, 而客户端认为服务使来自一个IP地址上的. 负责调度器有许多称呼, 例如Virtual Server, Director, Dispatcher, Balancer等.
(2) 服务器池(server pool), 是一组真正执行客户请求的服务器, 执行的服务有WEB,MAIL,FTP和DNS等.
(3) 共享存储(shared storage), 它为服务器池提供一个共享存储区, 这样很容易使得服务器池拥有相同的内容, 提供相同的服务.
lvs集群的类型
1. lvs-nat:
多目标IP的DNAT, 通过将请求报文中的目标地址和目标端口修改为某挑选出的RS的RID和PORT实现转发.
要点:
(1) RIP和DIP必须在同一个IP网络, 且应该使用私网地址; RS的网关要指向DIP;
(2) 请求报文和响应报文都必须经由Director转发; Director易于成为系统瓶颈;
(3) 支持端口映射, 可修改请求报文的目标PORT;
(4) vs必须是linux系统, rs可以是任意系统;
2. lvs-dr:
通过为请求报文重新封装一个MAC首部进行转发, 源MAC是DIP所在的接口的MAC, 目标MAC是某挑选出的RS的RIP所在接口的MAC地址; 源IP/PORT以及目标IP/PORT均保持不变; 并且Director和各RS都要配置使用VIP
要点:
(1) 确保前段路由器将目标IP为VIP的请求报文发往Director;
解决方法:
(a) 在前端网关做静态绑定;
(b) 在RS上使用arptables;
(c) 在RS上修改内核参数以限制arp通告及应答级别;
(2) RS的RIP可以使用私网地址, 也可以是公网地址; RIP与DIP在同一IP网络; RIP的网关不能指向DIP, 以确保响应报文不会经由Director;
(3) RS跟Director要在同一个物理网络;
(4) 请求报文要经由Director,但响应不能经由Director,而是由RS直接发往Client;
(5) 不支持端口映射;
3. lvs-tun:
转发方式: 不修改请求报文的IP首部(源IP为CIP, 目标IP为VIP), 而在源IP报文之外再封装一个IP首部(源IP是DIP, 目标IP是RIP), 将报文发往挑选出的目标RS;
要点:
(1) DIP, VIP, RIP都应该是公网地址;
(2) RS的网关不能, 也不可能指向DIP;
(3) 请求报文要经由Director, 但响应不能经由Director;
(4) 不支持端口映射;
(5) RS的OS得支持隧道功能;
4. lvs-fullnat:
通过同时修改请求报文的源IP地址和目标IP地址进行转发;
要点:
(1) VIP是公网地址,RIP和DIP是私网地址,且通常不在同一IP网络;因此,RIP的网关一般不会指向DIP;
(2) RS收到的请求报文源地址是DIP,因此,只需响应给DIP;但Director还要将其发往Client;
(3) 请求和响应报文都经由Director;
(4) 支持端口映射;
ipvs scheduler,调度方法
根据其调度时是否考虑各RS当前的负载状态, 可分为静态方法和动态方法两种;
1. 静态方法: 仅根据算法本身进行调度;
RR: 轮询调度;
轮询调度算法的原理是每一次把来自用户的请求轮流分配内部中的服务器, 从1开始, 直到N(内部服务器个数), 然后重新开始循环. 算法的优点是其简洁性, 它无需记录当前所有连接的状态, 所以是一种无状态调度.
WRR: weight RR,加权轮询, 以权重之间的比例实现各主机之间进行调度.
由于每台服务器的配置, 安装的也业务应用等不同, 其处理能力会不一样. 所以, 我们根据服务器的不同处理能力, 给每个服务器分配不同的权值, 使其能够接受相应权值数的服务请求.
SH: source hashing, 源地址散列. 主要实现session sticky(会话绑定)
源地址散列调度算法正好与目标地址散列调度算法相反, 它根据请求的源IP地址, 作为散列键(Hash Key)从静态分配的散列表找出对应的服务器, 若该服务器是可用的并且没有超负荷, 将请求发送到该服务器, 否则返回空. 它采用的散列函数与目标地址散列调度算法的相同. 它的算法流程与目标地址散列调度算法的基本相似, 除了将请求的目标IP地址换成请求的源IP地址.
DH: Destination Hashing, 目标地址散列,把同一个IP地址的请求, 发送给同一个server.
源地址散列调度算法是针对目标IP地址的负载均衡, 它是一种静态映射算法, 通过一个散列(hash)函数将一个目标IP地址映射到一台服务器. 目标地址散列调度算法先根据请求的目标IP地址, 所谓散列键(Hash Key)从静态分配的散列表找出对应的服务器, 若该服务器是可用的且未超载, 将请求发送到该服务器, 否则返回空.
2. 动态算法
LC: Least Connection, 最少连接
最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器, 最小连接调度是一种动态调度短算法, 它通过服务器当前所活跃的连接数来估计服务器的负载均衡, 调度器需要记录各个服务器已建立连接的数目, 当一个请求调度到某台服务器, 其连接数加1, 当连接中止或超时, 其连接数减一, 在系统实现时, 我们也引入当服务器的权值为0时, 表示该服务器不可用而不被调度.
算法 Overhead=activeconns*256+inactiveconns, 挑小的调度
WLC: Weight LC, 加权最小连接
加权最小连接调度算法时最小连接调度的超集, 各个服务器用相应权值表示其处理性能. 服务器的缺省权值为1, 系统管理员可以动态的设置服务器的权值, WLC在调度新的连接时可能使服务器的已建立连接数和其权值成比例.
算法: overhead=(activeconns*256+inactiveconns)/weight, 挑选小的调度.
SED: Shortest Expected Delay, 最短期望延迟
基于WLC的算法
算法: overhead=(activeconns+1+*256/weight, 挑选小的调度.
NQ: never queue, 永不排队, 改进的sed
无须队列, 如果有台real server的连接数=0, 就直接分配过去, 不需要进行sed运算.
LBLC: (Locality-Based Least Connections with Replication), 带复制的基于局部性最少链接.
带复制的基于局部性最少链接调度算法也是针对目标IP地址的负载均衡, 该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组, 按"最小连接"原则从服务器组中选出一台服务器, 若服务器没有超载, 将请求发送到该服务器; 若服务器超载, 则按"最小连接"原则从这个集群中选出一台服务器, 将该服务器加入到服务器组中, 将请求发送到该服务器. 同时, 当该服务器组有一段时间没有被修改, 将最忙的服务器从服务器组中删除, 以降低复制的程度.
ipvsadm常用命令
总览:
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]
1. 集群管理服务
添加:
ipvsadm -A -t|u|f service-address [-s scheduler] [-p [timeout]]
-t : tcp协议的集群服务
-u : udp协议的集群服务
-f : FWM防火墙标记
[-s scheduler] : 指定集群的调度算法, 默认wlc
修改
ipvsadm -E -t|u|f service-address [-s scheduler] [-p [timeout]]
删除
ipvsadm -D -t|u|f service-address
2. 管理集群上的RS
增加, 修改
ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
删除
ipvsadm -d -t|u|f service-address -r server-address
service-address : rip:port
lvs类型:
-g : gateway, dr类型
-i : ipip, tun类型
-m : masquerade, nat类型
-w weight : 权重
3. 清空定义的所有内容
ipvsadm -C
4. 查看
ipvsadm -L|l [options]
–numeric, -n:numeric output of addresses and ports
–exact:expand numbers (display exact values)
–connection, -c:output of current IPVS connections
–stats:output of statistics information
–rate :output of rate information
FWM :
Firewall Mark, 借助防火墙标记来分类报文, 而后基于标记定义集群服务, 可将多个不同的应用使用同一个集群服务进行调度.
打标记方法(在Director主机):
iptables -t mangle -A PREROUTING -d $vip -p $proto –dport $port -j MARK –set-mark NUMBER
基于标记定义集群服务:
ipvsadm -A -f NUMBER [options]
lvs persistence:持久连接
持久连接模板:实现无论使用任何算法,在一段时间内,实现将来自同一个地址的请求始终发往同一个RS;
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]
port Affinity:
每端口持久:每集群服务单独定义,并定义其持久性;
每防火墙标记持久:基于防火墙标记定义持久的集群服务;可实现将多个端口上的应用统一调度,即所谓的port Affinity;
每客户端持久:基于0端口定义集群服务,即将客户端对所有应用的请求统统调度至后端主机,而且可使用持久连接进行绑定;
lvs-nat和lvs-dr模型的详细阐述
1. lvs-nat模型
客户端的地址为CIP, Director的外网地址为VIP, 内网地址为DIP, RS的地址为RIP
流程: 客户端发送请求报文, 报文首部的目标地址为VIP, 源地址为CIP, 请求报文地址指向VIP; 当报文到达Director后, 经过算法选择出RS, 将请求报文首部的目标地址重新封装为RIP, 经由DIP转发给RS. 当RS生成响应报文的时, 报文的首部封装的源地址为RIP, 目标地址为CIP, 将响应报文发送给Director, 经过DIP之后, 将响应报文的源地址更改为VIP后, 发送给VIP, 完成一次负载均衡.
2. lvs-dr模型
客户端地址为CIP, Director地址为VIP, RS地址为RIP;
流程:
(1) 客户端通过路由交换的公网与Director和RS相连接, 并且Director和RS连接在同一个交换机上. 当客户端发送给Director请求报文之后, Director通过算法选择出RS, 将请求报文发送给挑选出的RS, RS生成响应报文之后, 直接将响应报文发送给客户端, 不再经过Director, 从而降低了Director的负载, 提高了负载均衡的能力.
(2) 那么, 问题来了, Director和RS都在同一个网络, 怎么保证, 客户端发送的请求报文发给Director, 不会发给RS呢, 并且所有的RS生成的响应报文能直接发送给客户端呢?
一般将Director的网卡上绑定两个IP, 一个VIP, 用以接收客户端的请求报文; 一个DIP, 用以向RS转发报文; 在RS的外网网卡上绑定RIP, 用以接收转发报文, 同时在loopback网卡上绑定VIP, 用以发送响应报文时封装报文首部的源地址使用, 那么, 怎么保证, Director和RS的VIP不会产生网络冲突呢, 并且客户端发送的响应报文不会发送给RS呢? 一般有三种方式解决:
(I) 在前端网关做静态绑定;
(II) 在RS上使用arp-tables, 配合(I) 使用;
(III) 在RS上修改内核参数, 以限制arp的响应和应答级别.
一般使用第三种方式.
限制响应级别: arp_ignore
0 : 默认值, 表示可使用本地任意接口上配置的任意地址进行响应
1 : 仅在请求的目标IP配置在本地主机的接口收到请求报文接口上时, 才给与响应; 1是我们的期望值;
限制通告级别: arp_announce
0 : 默认值, 把本机上的所有接口的所有信息向每个接口上的网络进行通告;
1 : 尽量避免向非直接连接网络进行通告;
2 : 期望值; 尽量避免向非本网络通告;
原创文章,作者:black_fish,如若转载,请注明出处:http://www.178linux.com/54980