LVS原理深入理解
2014-03-11 13:12
281 查看
一:简介 LVS(Linux Virtual Server)是淘宝的一个开源项目,该项目主要用于服务器的负载均衡,Lvs工作在内核态基于四层进行负载均衡,又因为是基于四层的负载均衡,故无法解析上层协议,不能做一些基于七层协议的过滤。但是因为工作在四层所以可以对所有的基于TCP/UDP的服务都可以进行负载均衡,常见的有mail,http,mysql等的负载均衡。Lvs工作在内核态可以在内核态进行报文的封装和解析无需进入用户空间,故转发效率很高,其转发速度优于nginx和haproxy,LVS本身没有提供后端RealServer的健康检查,但是可以配合keepalived或者ldirectory来进行后端RealServer的健康检查.
二:LVS的三种模型1.NAT模型
192.168.0.1会访问LVS服务器的192.168.0.2地址,172.16.0.1连接着内网的web服务器,并作为其默认网关,首先LVS服务器会监听在192.168.0.2这个地址的80端口上,192.168.0.1这台Client会去访问LVS服务器上的80端口,此时LVS服务器会根据其内部设置的调度算法在其后端选择一台服务器,假设此时选中了172.16.0.2,那么LVS服务器会修改其报文的目的地址为172.16.0.2,并将报文转发给了172.16.0.2这台服务器,这台服务器根据请求报文来够建响应报文,其目标地址为192.168.0.1 源地址为172.16.0.2,这个报文会首先发给网关也就是lVS服务器,此时LVS服务器将其源地址修改为192.168.0.2再将报文发送给客户端.至此一个报文的请求过程结束.总结:
2.DR模型
LVS WEB1 WEB2 这三台服务器都配置了VIP但是WEB1 WEB2这两台服务器的VIP是不向外广播自己的VIP mac地址,也就是说实际上只有LVS这台服务器上的VIP才可以进行向外通信,当192.168.0.5访问VIP的时候,报文就会到达LVS这台机器,LVS服务器根据lvs调度算法从后端服务器中选出一台web服务器,假设这里选中了WEB1这台服务器,那么LVS服务器就会修改报文的目标mac地址改为WEB1的mac地址,报文就被送往WEB1这台服务器,WEB1响应报文请求后,将响应结果封装成报文,目标地址为192.168.0.5源地址为将报文发送出去的接口地址,所以必须让响应报文从配置了VIP地址的接口发送出去,所系需要在WEB1设置路由条目让所有的含有VIP的报文都从配置VIP地址的接口出去,那么响应报文的源地址就成了VIP总结:
3.TUN隧道模型 隧道模型和DR模型本质是相同的,只是DR模型要求LVS服务器和后端的web服务器是同一个网段的(通过MAC地址进行通信),但是隧道模型可以不局限于让LVS服务器和后端web服务器在一个网段,可以分布不在不同的地方,通过给IP报文外再封装一层IP,来讲报文发送到远端的web服务器,这也要求问网卡支持.总结:
三:LVS的十种调度算法
四:lvs的安装和使用 2.6内核以后LVS基本都集成在内核当中,只需要安装其用户空间的程序ipvsadm利用其生产规则并应用与内核空间的LVS模块
安装使用:
二:LVS的三种模型1.NAT模型
192.168.0.1会访问LVS服务器的192.168.0.2地址,172.16.0.1连接着内网的web服务器,并作为其默认网关,首先LVS服务器会监听在192.168.0.2这个地址的80端口上,192.168.0.1这台Client会去访问LVS服务器上的80端口,此时LVS服务器会根据其内部设置的调度算法在其后端选择一台服务器,假设此时选中了172.16.0.2,那么LVS服务器会修改其报文的目的地址为172.16.0.2,并将报文转发给了172.16.0.2这台服务器,这台服务器根据请求报文来够建响应报文,其目标地址为192.168.0.1 源地址为172.16.0.2,这个报文会首先发给网关也就是lVS服务器,此时LVS服务器将其源地址修改为192.168.0.2再将报文发送给客户端.至此一个报文的请求过程结束.总结:
NAT:地址转换和DNAT原理相同,性能一般,LVS Server要频繁处理数据包。 1.集群节点根director必须在同一个IP网段中 2.RIP通常是私有地址仅用于各集群节点通信 3.directory位于client和real server之间,并负责出来进出的所有通信 4.real server的必须将网关指向DIP 5.支持端口映射 6.real server可以使用任意OS 7较大规模应用场景中director易成为系统瓶颈
2.DR模型
LVS WEB1 WEB2 这三台服务器都配置了VIP但是WEB1 WEB2这两台服务器的VIP是不向外广播自己的VIP mac地址,也就是说实际上只有LVS这台服务器上的VIP才可以进行向外通信,当192.168.0.5访问VIP的时候,报文就会到达LVS这台机器,LVS服务器根据lvs调度算法从后端服务器中选出一台web服务器,假设这里选中了WEB1这台服务器,那么LVS服务器就会修改报文的目标mac地址改为WEB1的mac地址,报文就被送往WEB1这台服务器,WEB1响应报文请求后,将响应结果封装成报文,目标地址为192.168.0.5源地址为将报文发送出去的接口地址,所以必须让响应报文从配置了VIP地址的接口发送出去,所系需要在WEB1设置路由条目让所有的含有VIP的报文都从配置VIP地址的接口出去,那么响应报文的源地址就成了VIP总结:
DR:直接路由 1.各集群节点根directory必须在同一个物理网络中 2.RIP地址可以不是私有地址,实现便捷的远程管理 3.directory进负责入站请求,响应报文由realserver直接发给客户端 4.realserver不能将网关指向DIP 5.不支持端口映射 6.大多数操作系统都可以使用在real server上 7.可以处理比NAT模型更多的处理请求
3.TUN隧道模型 隧道模型和DR模型本质是相同的,只是DR模型要求LVS服务器和后端的web服务器是同一个网段的(通过MAC地址进行通信),但是隧道模型可以不局限于让LVS服务器和后端web服务器在一个网段,可以分布不在不同的地方,通过给IP报文外再封装一层IP,来讲报文发送到远端的web服务器,这也要求问网卡支持.总结:
TUN:隧道 机制跟DR一样,只是转发请求的时候会修改报文,双IP报文, 需要realserver和directory必须支持隧道机制 1.集群结点可以跨越互联网 2.RIP必须是公网地址 3.directory进负责入站请求,响应报文由realserver直接发给客户端 4.realserver网关不能指向directory 5.只有支持隧道功能的OS才能用于realserver
三:LVS的十种调度算法
1.Round Robin rr算法 无需记录每一个连接的状态,对于客户端的请求轮流分配至各个realserver,适用于服务器性能相同的场合 2.Weighted round robin wrr算法 根据权重的比例情况分配请求,权重大的按照比例情况多分配用户连接请求,适用于服务器性能不相同的情况 3.least connected lc算法 active活动连接:已经建立的连接正在数据传输 inactive非活动连接:已经建立的连接,使用了长连接机制,该连接空闲着 连接数=active*256+inactive 需要记录每一个realserver的连接数情况,连接终止或超时连接数减一,新的用户连接将会分配给当前连接数最小的realserver 4.weighted least connection wlc算法 lvs的默认算法 连接数=(active*256+inactive)/weight 新的用户连接请求将会分配给当前连接数最小的realserver 5.Locality-Based Least connection lblc算法 lblc调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器, 若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在, 或者该服务器超载且有服务器处于其一半的工作负载,则用“最少链接”的 原则选出一个可用的服务器,将请求发送到该服务器。 非常适用于cache服务器的场景,将会大大提高cache服务器的缓存命中率 6.Locality-Based Least Connections with Replication Scheduling lblcr算法 也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。 它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射, 而 LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门” 站点的服务请求,一台Cache 服务器可能会忙不过来处理这些请求。 这时,LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台 Cache服务器,映射该“热门”站点到这台Cache服务器,很快这台Cache服务器 也会超载,就会重复上述过程选出新的Cache服务器。这样,可能会导致该“热门”站点的映像会出现在所有的Cache服务器上,降低了Cache服务器的使用效 率。LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合),当 该“热门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断 增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache服务 器数目。这样,该“热门”站点的映像不太可能出现在所有的Cache服务器上, 从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP地址找出该 目标IP地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务 器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按“最小连 接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求 发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器 从服务器组中删除,以降低复制的程度。 7.source hash 源地址hash,来自同一个客户端的请求都会发往到同一台realserver,可以实现session affinity 8.destination hash 目标地址hash 适用缓存服务器场景.对于访问相同地址的请求都被发往相同的服务器 9.sed 最短期望延迟 连接数=(active+1)*256/weight 每次讲请求发往连接数最少的服务器 10.never queue 分发请求+sed的结合
四:lvs的安装和使用 2.6内核以后LVS基本都集成在内核当中,只需要安装其用户空间的程序ipvsadm利用其生产规则并应用与内核空间的LVS模块
安装使用:
安装: yum install ipvsadm -y 使用: ipvsadm: 管理集群服务 添加 -A -t|u|f(tcp/udp/FWM防火墙标记) service-address:[port|Mark Number] [-s scheduler] 修改 -E Same to -A 删除 -D -t|u|f service-address example:ipvsadm -A -t 192.168.0.1:80 -s rr 管理集群服务中的RS 添加 -a -t|u|f service-address -r server-address [-g|i|m] [-w weight] service-address:实现定义好的某集群服务 -r server-address:某RS地址,在NAT模型中可使用IP:PORT实现端口映射 -g:DR -i:TUN -m:NAT -w weight 定义权重 修改 -e Same to -a 删除 -d -t|u|f service-address -r server-address 查看 -L|l -n 以数字形式显示不反解IP地址和端口 --stats 显示统计信息 --rate 输出速率信息 --timeout 会话超时时间长度 -c 显示当前ipvs的连接状况 -Z 清空统计数据 -C 删除所有集群服务,清空规则 -S 使用输出重定向对规则进行保存 service ipvs save -R 使用输入重定向读入规则 service ipvs restore
相关文章推荐
- 转载--LVS之原理篇--深入全面理解LVS工作原理
- LVS之原理篇--深入全面理解LVS工作原理
- 深入理解Redis主键失效原理及实现机制
- 深入理解 Spring 事务原理
- 深入理解Spark 2.1 Core (六):资源调度的原理与源码分析
- 深入理解机器学习:从原理到算法 学习笔记-第1周 02简易入门
- 【深入理解java集合系列】LinkedHashMap实现原理
- 深入理解PHP Opcode缓存原理
- 深入理解HTTP协议、HTTP协议原理分析
- 深入理解Spark 2.1 Core (十一):Shuffle Reduce 端的原理与源码分析
- 深入理解React Native页面构建渲染原理
- 深入理解PHP原理之变量作用域(Scope in PHP)
- 深入理解FFM原理与实践
- 深入理解MapReduce的架构及其原理
- 【软件开发知识积累】深入理解HTTP 原理基础与变迁
- struts2原理-深入理解(转)
- 深入理解PHP传参原理(PHP5.2)
- 深入理解逆序数+八数码原理
- 深入理解PHP原理之变量生命期(一)
- lvs中ipvsadm的ActiveConn和InActConn的深入理解