设为首页 收藏本站
查看: 895|回复: 0

[经验分享] LVS的工作机制

[复制链接]

尚未签到

发表于 2019-1-2 13:36:01 | 显示全部楼层 |阅读模式
  LVS Linux Virtual ServerLinux虚拟服务器
  LVS是一台主机,将数据转发给其他的真正的主机的。LVS的应用只需要装在调度节点上,它的工作原理基本类似于DNAT。其实虚拟服务器可以看做是一个四层交换。通过套接字来完成的转发。这对于客户端来说几乎是透明的。
  LVS的特点:高吞吐能力、高并发能力,冗余能力,适用性。
  在LVS里IP地址有很多命名机制:

  1.VIP:(Virtual IP)虚拟地址,外网用户看到的那个地址。
  2.RIP:(Real IP)后端真正提供节点的那些些IP地址
  3.DIP:(Director’s IP)用于转发请求的转发器上的那个地址,一般是跟RIP相连的。
  4.CIP:客户端的IP地址
  LVS的三种工作模式/模型:
  1.LVS-NAT(地址转换):

  在这种机制下,我们的调度器Director通常有两块网卡,使用转发的机制把虚拟的IP转发给后台的真正主机,这样的机制下,真正主机可能是在一个私网之中的。但是这种架构的响应能力是非常有限的,扩展能力也有限。所以LVS-NAT有以下的几个特点:
  1.DIP和RIP必须在一个子网中,不能跨越网段。
  2.RIP地址通常是私有地址
  3.调度器Director将面临巨大的压力
  4.所有的RIP必须以DIP作为默认的网关。
  5.DNET可以做端口转换
  6.任何操作系统都可以架构LVS-NAT
  7.单调度器Director的节点过大的压力可能成为系统的瓶颈
  2.LVS-DR(直接路由):

  工作原理示意图中可以看出只有进来的请求经过目标地址转换。出去的请求不经过Director
  其实我们在每一个Real Server上配有两个网卡,一个是RIP,一个是VIP。而我们的数据到来的时候,它的目标地址一直是VIP,而返回的时候,也是又另一个相同的VIP基于响应。这就导致我们必须想办法获取到一种机制,能够让我们Cluster node上的VIP屏蔽接受CIP的响应。在这种机制下,我们的后端弄上百个节点也是没问题的,这就解决了NAT的模式下导致Director压力过大而成为系统瓶颈的缺憾。它的响应能力,超过了NET模型的数倍。也是网上用的最多的机制。
  LVS-DR的特点:
  1.DIP和RIP必须在同一个物理网络中,它的转发机制是基于Mac地址转发
  2.RIP可以使用公网地址(建议)
  3.Director仅处理请求而不处理响应
  4.集群节点(Real Server)的网关不能指向DIP。
  5.不支持端口转换
  6.绝大多数的操作系统都可以实现Real Server
  7.比NAT模型的Director能带动更多的RealServer
  但是因为是这样的模型,所以Director和各种Real Server必须在同一网络中,这就导致他们必须在一个机房内,而如果我们的服务器分布在全国各地,他们不可能处于同一物理网络(交换机),这时使用这个方式就显然不合适了。
  3.LVS-TUN(隧道):

  我们的数据包利用隧道的机制,不改变源IP和目标Ip的机制下,直接通过再次封装的隧道机制直接传输,跨互联网实现Real Server转发。所以也可以说TUN是更高级的一种DR
  LVS-TUN的特点:
  1.集群节点和Director节点不用在同一网络中。
  2.RIP必须使用公网地址
  3.Director只需要处理进来的请求,不需要处理出去的请求。
  4.Director不能做端口映射
  5.只能使用支持IP隧道协议的操作系统做Real Server
  调度算法
  对于Director的挑选机制,当director收到一个请求,发现访问的是一个集群,就选择一个集群中的匹配主机来响应这个请求,这就是调度。主要分为两个大类。
  1.静态调度方法:静态并不关心当前客户端的当前负载情况
  2.动态调度方法:将以检查背后的客户端的连接数以及连接状态作为调度标准
  静态调度类
  1.Round-robin(RR):轮询(论叫)算法
  2.Weighted round-robin(WRR):加权轮询(论叫)算法,根据后端服务器的响应能力的不同,定义其权重,权重越大,所能被分配的个数就越多。比如定义成400:200:100
  3.Destination hashing(DH):目标地址hash,实现针对目标地址的请求实现固定定向转发,当我们后台的服务器先经过的是缓存服务器的时候,将来自于同一个用户的同样请求始终转发到某一台特定的服务器上。这种算法主要是为了提高缓存的命中率的,在后台有缓存服务器的时候特别有用。
  4.Source hashing(SH):原地址hash,将来自于同一个用户的请求始终转发到同一个router或者firewall上去。这种场景主要用于公司里人员比较多的时候,当我们用两台路由/防火墙的时候,由Director负责保证这个用户出去的时候经过第一个防火墙,它的之后的请求也会通过第一个防火墙。这种算法主要是实现路由/防火墙平均负载通过特定路由/防火墙出去。
  动态调度类:
  1.real server 处于活动状态的连接,发送的所有数据包都是ESTABLISHED
  2.real server 处于非活动状态的连接,服务在线但是发送的数据包是非FIN状态的
  算法:
  1.LC(Least connection):最少连接算法:检测服务器上最少活动连接数,同时检测活动和非活动的连接数.用活动链接*256+非活动链接,作为overhead数,谁的数小,谁将接受下一次请求。不能区分服务器的响应能力。
          Overhead = 活动连接数x 256 + 非活动链接
  2.WLC(Weighted least connection):加权最少连接算法,将overhead的数除以定义的加权数。比如加权比为 2:1,则将算出来的overhead在权重大的上除以2,在小的上除以1。而WLC可以说是我们常用的最公平的算法了。
          WLC = Overhead/权重
  3.SED(Shortest Expected Delay):最短期望延迟,这种算法是对WLC的一种改进,不考虑非活动连接数,并且将正处于活动状态的值加1。此时,数最小的那个则优先接受下一次请求。加1的主要目的,是尽可能的把权重大的服务器尽可能的利用起来,增大权重大的服务器的倾向性……,但是这有另一种缺陷就是导致权重比大的服务器一直被响应而权重小的服务器一直空闲。
          SED = (活动连接数+1) x 256
  4.NQ(Never Queue):基于SED基础的算法,将权重低的空闲服务器分配进一个请求,然后再去不断的分配给高权重服务器。只有在不用考虑服务器压力,和非活动链接的时候NQ才能取代WLC
  5.LBLC(Locality-Based Least-Connection)基于本地的最少连接算法:它跟DH算法几乎相同,不过DH是静态的,而LBLC是动态的,考虑后台负载能力的一种DH算法。LBLC是从WLC的基础上做出来的,还支持权重。
  6.LBLCR(Locality-Based Least-Connection with Replication Scheduling)基于本地的带复制功能的最少连接数,是对LBLC的一种改进,能在LBLC的基础上对负载均衡机制实现真正的负载均衡。
  LVS是实现方式:ipvs
  LVS的机制其实是跟Iptables是相近的,有一段是专门定义在用户空间,命令叫ipvsadm,而工作在内核空间中的代码叫ipvs,2.4内核之后,ipvsadm已经被做进内核中,只需要将相应的功能开启即可。而我们就是通过用户空间中的ipvsadm来实现对内核中ipvs的控制的。
  ipvsadm命令:
  按作用来讲分为:
      1.定义集群服务
  ipvsadmin -A|E -t|u|f VIP:port -s 调度算法[默认WLC]
      ipvsadm -D -t|u VIP:port
  -A:添加一个新的定义
  -E:修改一个已定义的
  -D:删除一个已定义的
  -t : tcp的服务器
  -u:udp的服务
  -f:基于防火墙的服务
  -s:指定调度算法
      2.定义Realserver
      ipvsadm -a|e -t|u VIP:port -r REALSERVER[:port] [-g|i|m] [-w weight]
      ipvsadm -d -t|u VIP:port -r REALSERVER
  -a|e:添加或者修改readserver
  -w:指定权重
  -g|i|m:定义三种模型
  g:表示Gateway,DR模型
  i:通道模型
  m:表示NAT模型地址伪装
      3.查看定义信息
  -C:用于清空规则
  -S:保存规则到某个文件
  -R: 从某个文件恢复规则
  -L|l:用于实现查看
  -n:查看时用数字的方式显示地址
  --stats:显示统计的数据信息
  --rate:显示统计数据的速率
  -Z:清空计数器
  接下来,我们就开始准备通过实战,来演练一下对于ipvsadm的使用。




运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-658687-1-1.html 上篇帖子: LB lvs 下篇帖子: 我的lvs方案实现
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

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