51学通信论坛2017新版

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 2679|回复: 0
打印 上一主题 下一主题

你真的掌握lvs工作原理吗?

[复制链接]

 成长值: 15613

  • TA的每日心情
    开心
    2022-7-17 17:50
  • 2444

    主题

    2544

    帖子

    7万

    积分

    管理员

    Rank: 9Rank: 9Rank: 9

    积分
    74104
    跳转到指定楼层
    楼主
    发表于 2017-11-15 21:42:33 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
    lvs介绍
    LVS(Linux Virtual Server 虚拟服务器):是一个虚拟的四层路由交换器集群系统,根据目标地址和目标端口实现用户请求转发。
    lvs工作原理


    1、当用户向负载均衡调度器(Director Server)发起请求,调度器将请求发往至内核空间
    2、PREROUTING链首先会接收到用户请求,判断目标IP确定是本机IP,将数据包发往INPUT链
    3、IPVS是工作在INPUT链上的,当用户请求到达INPUT时,IPVS会将用户请求和自己已定义好的集群服务进行比对,如果用户请求的就是定义的集群服务,那么此时IPVS会强行修改数据包里的目标IP地址及端口,并将新的数据包发往POSTROUTING链
    4、POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器,那么此时通过选路,将数据包最终发送给后端的服务器
    lvs的组成
    lvs有两段代码组成,ipvsadm和ipvs

      ipvs(ip virtual server):一段代码工作在内核空间,叫ipvs,是真正生效实现调度的代码。
      ipvsadm:另外一段是工作在用户空间,叫ipvsadm,负责为ipvs内核框架编写规则,定义谁是集群服务,而谁是后端真实的服务器(Real Server)。

    lvs的术语

      Direstor Server(DS)
      Real Server(RS)

    lvs关于IP的术语

      VIP:virtual IP 向外部直接面向用户请求,作为用户请求的目标的IP地址。
      DIP:Director Server IP,主要用于和内部主机通讯的IP地址
      RIP:Real Server IP
      CIP:Client IP,客户端IP

    lvs的类型
    根据架构有3种不同的模型
    1、lvs-nat (Network Address Translation)

    建议小规模使用

    2、lvs-dr (Direct Routing 直接路由)

    建议大规模使用,也是现在较多使用场景的方法

    3、lvs-tun (Tunneling 隧道)

    lvs-tun模型比较少用,因为他不能实现全局负载均衡,不能根据用户区域的距离来挑选最近的机房。这个最多为了实现异地容灾来实现的。比方说日本的机房地震了,而此时美国的机房仍然可使用,那么只要将指向到美国机房即可。而一般只有这种场景下才会用到隧道机制

    LVS-NAT模型

    重点:修改目标IP地址为挑选出的RS的IP地址。


    ①、当用户请求到达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模型的特性
    1、RS应该使用私有地址,RS的网关必须指向DIP
    2、DIP和RIP必须在同一个网段内
    3、请求和响应报文都需要经过Director Server,高负载场景中,Director Server易成为性能瓶颈
    4、支持端口映射
    5、RS可以使用任意操作系统

    缺陷:对Director Server压力会比较大,请求和响应都需经过director server

    LVS-DR模型

    重点:将请求报文的目标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模型的特性
    1、保证前端路由将目标地址为VIP报文统统发给Director Server,而不是RS
    解决方案:

      在前端路由器做静态地址路由绑定,将对于VIP的地址仅路由到Director Server
      存在问题:用户未必有路由操作权限,因为有可能是运营商提供的,所以这个方法未必实用
      arptables:在arp的层次上实现在ARP解析时做防火墙规则,过滤RS响应ARP请求。这是由iptables提供的
      修改RS上内核参数(arp_ignore和arp_announce)将RS上的VIP配置在lo接口的别名上,并限制其不能响应对VIP地址解析请求。(最容易实现)

    2、RS可以使用私有地址;也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问
    3、RS跟Director Server必须在同一个物理网络中
    4、所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
    5、不支持地址转换,也不支持端口映射
    6、RS可以是大多数常见的操作系统
    7、RS的网关绝不允许指向DIP(因为我们不允许他经过director)
    8、RS上的lo接口配置VIP的IP地址

    缺陷:RS和DS必须在同一机房中

    LVS-Tun模型

    重点:在原有的IP报文外再次封装多一层IP首部,内部IP首部(源地址为CIP,目标IIP为VIP),外层IP首部(源地址为DIP,目标IP为RIP)

    ①、当用户请求到达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模型特性
    1、RIP、VIP、DIP全是公网地址
    2、RS的网关不会也不可能指向DIP
    3、所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
    4、不支持端口映射
    5、RS的系统必须支持隧道
    LVS算法调度
    LVS算法分为静态方法和动态方法
    静态方法
    仅根据调度算法本身,不考虑背后服务器的负载

      rr:round robin,轮流,轮询
      调度器通过“轮询”的调度算法,按照顺序将请求分配到后端的真实服务器上,无论后端服务器的负载状态如何,都会平均“轮询”调度。
      WRR:weightd round robin,带权重的轮序
      指的是能者多劳,服务器性能强的,就会分配的比较多。所以根据后端真实服务器的性能来进行调度,根据后端真实服务器负载情况,修改权重值来实现动态的调度
      sh:source hashing 源地址hash
      将来自于同一个源IP的请求将始终被定向至同一个RS,这个目的是为了session持久功能,仅实现session的绑定.
      dh:destination hashing,目标地址hash,主要用于实现当你的内部主机上有多个防火墙出口时有用。 (仅作了解)
      动态方法
      根据算法及各RS当前的负载状况进行调度
      lc:least connection,最少连接,通过监控后端RS的连接数,根据TCP协议中的某些计数器来判断。将请求调度到已建立的连接数最少后端的真实服务器上。
      计算方法:Overhead=Active*256+Inactive

    Overhead:负载状态
    Overhead越小,表示负载越低


      wlc:weight lc,加权的lc
      在集群系统中的服务器,如果性能差异较大的情况下,调度器可以根据采用“加权的最少连接”调度算法来提高负载均衡性能,如果权重值较高的RS,将会承接更大比例的连接负载,所以调度器可以根据“加权的最少连接”来判断服务器的负载情况,并动态调整期权重值。
      计算方法:Overhead=(Active*256+Inactive)/weight
      sed:shortest expertion delay最短期望延迟,
      基于WLC算法,Overhead = (ACTIVE+1)*256/加权,不再考虑非活动状态,把当前处于活动状态的数目+1来实现,数目最小的,接受下次请求,+1的目的是为了考虑加权的时候,非活动连接过多缺陷:当权限过大的时候,会倒置空闲服务器一直处于无连接状态。
      计算方法:Overhead=((Active+1)*256)/weight
      让权重大的优先接收请求
      nq:Never Queue,永不排队
      可以理解第一个请求上来先轮一圈,就是每个都先响应一次,然后在接着使用上面那种方法计算让谁响应。如果有台Real Server的连接数=0就直接分配过去,不需要在进行sed运算。
      lblc:Locality-Based Least connection基于本地的最小连接
      基于局部性的最少连接算法是针对请求报文的目标IP地址的负载均衡调度。主要用于Cache集群系统,因为Cache中客户请求报文的目标IP会不断发生改变。所以该算法根据请求的目标IP地址找出该目标IP地址最近使用的Real Server,若该服务器是可用的且没有超载,就会使用“最少链接”来挑选一台可用的服务器,将请求发送到该服务器
      lblcr:Replicated lblc带复制功能的lblc,是dh算法的一种改进
      带复制功能的lblc也是针对目标IP地址做负载均衡。主要是根据请求的目标IP找到目标IP对应的服务器组,根据“最小连接”原则,从服务器组中挑选一台服务器。若服务器没有超载,将请求发送到该服务器;若服务器超载,则按“最小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。

    总结
    本文主要介绍了LVS的工作原理、LVS的三种工作模型(LVS-NAT, LVS-DR, LVS-Tun)及LVS的调度算法(rr, wrr, sh, dh, lc, wlc ,sed, nq, lblc, lblcr)。这篇文章在学习马哥课程中整理汇总出来,由于本人能力有限,其中有些地方写的不足还待完善如果您有好的建议,欢迎您的指教。谢谢。

    声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。
    扫描并关注51学通信微信公众号,获取更多精彩通信课程分享。

    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?立即注册

    x
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    Archiver|手机版|小黑屋|51学通信技术论坛

    GMT+8, 2025-1-31 20:43 , Processed in 0.072023 second(s), 33 queries .

    Powered by Discuz! X3

    © 2001-2013 Comsenz Inc.

    快速回复 返回顶部 返回列表