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

[经验分享] lvs群集理论知识

[复制链接]

尚未签到

发表于 2019-1-3 09:35:56 | 显示全部楼层 |阅读模式
  1、什么是群集
  集群(Cluster):计算机集合为解决某个特定问题组合起来形成的单个系统。
  集群类型:
LB(Load Banlancing):负载均衡集群
HA(High Availability):高可用集群。提高服务可用性,避免出现单点故障
HP(High Performance):高性能集群
分布式存储与运算  2、什么是负载均衡集群(LB)
  在现实情况中当我们遇到了单台服务器性能不足的时候,这时我们有两种提升方案:
Scale Up:向上扩展、垂直扩展、纵向扩展;用性能好的主机替代性能差的主机,性价比差;
Scale Out: 向外扩展、水平扩展,即以新增服务器和现有服务器组成集群来应对性能不足的问题  在以上两种解决方案中我们一般选择向外扩展 因为:
向上扩展所付出的代价和得到性能的提升不成正比, 大多时候提升服务器一倍的性能需要花费三倍的价格
向外扩展也有很多问题, 例如:如何协调两台服务器提供一服务,用户在两台服务器进行轮调时如何保存其的session信息  负载均衡或者负载均衡集群的作用就是将:
向外扩张的服务器群组组成一个负载均衡集群,前端通过负载均衡调度器来对用户请求通过调度算法合理分发到后端服务器中, 来达到负载均衡的目的  LB集群常见的解决方案:

硬件:
F5 BIG-IP
    Citrix Netscaler
    A10 A10
    Array
    Redware
软件:
    lvs: Linux Virtual Server
    haproxy
    nginx
    ats (apache traffic server)
    perlbal  3、什么是(HA)高可用集群
在集群服务器架构中,当主服务器故障时,备份服务器能够自动接管主服务器的工作,并及时切换过去,以实现对用户的不间断服务  HA集群的实现:
keepalived:通过实现vrrp协议来实现地址漂移  4、LVS简介
LVS(Linux Virtual Server)是前阿里巴巴首席科学家章文嵩博士在大学期间的一款开源的负载均衡软件, 可实现四层的负载均衡。首先解释下下文中出现的各种术语:
    Director: 负载均衡调度器, 负责在前端接受用户请求根据特定的算法转发到后端Real Server
    Real Server: 后端提供服务的服务器
    VIP: Director接受用户请求的IP地址
    DIP: Director和Real Server联系的IP地址
    RIP: Real Server的IP地址
    CIP: Client IP, 客户端的IP地址  5、LVS在Linux上的工作过程
  工作流程图:
  

DSC0000.jpg

  LVS其实由两个组件组成, 在用户空间的ipvsadm和内核空间的ipvs, ipvs工作在INPUT链上, 如果有请求报文被ipvs事先定义,就会将请求报文直接截取下根据其特定的模型修改请求报文, 再转发到POSTROUTING链上送出TCP/IP协议栈
其报文流经过程如下:
1.当客户端的请求到达负载均衡器的内核空间时,首先会到达PREROUTING链;
2.当内核发现请求数据包的目的地址是本机时,将数据包送往INPUT链;
3.LVS由用户空间的ipvsadm和内核空间的IPVS组成,ipvsadm用来定义规则,IPVS利用ipvsadm定义的规则工作,IPVS工作在INPUT链上,当数据包到达INPUT链时,首先会被IPVS检查,如果数据包里面的目的地址及端口没有在规则里面,那么这条数据包将被放行至用户空间;
4.如果数据包里面的目的地址及端口在规则里面,那么这条数据报文将被修改目的地址为事先定义好的后端服务器,并送往POSTROUTING链;
5.最后经由POSTROUTING链发往后端服务器。  6、LVS的工作特点:

lvs具有以下特点:
1)ipvs工作于netfilter框架上;
2)规则:
        简单来说就是把ip加端口定义为ipvs集群服务,ipvs会为此请求定义一个或多个后端服务目标地址未必会改,但是报文
        会被强行转发给后端的服务器
3)ipvs组件: ipvsadm(用户空间,用来编写规则) + ipvs(内核空间);
4)ipvs工作在第四层:
       (1)四层交换、四层路由。 做第四层转发。(osi模型中的网络层)
       (2)只能基于ip和port转发,无法在应用层,session级别转发
       (3) 不用到达应用层空间,就能转发
            即工作在第四层不能进行7层负载均衡,但基于4层可以不要管上层协议进行负载均衡,只要支持tcp或udp就行。
5)lvs性能很好,但是由于工作于四层,不能到用户空间,因此不能进行更加精细的控制;在精细控制方面haproxy和Ngnix
   可以更好的实现;
6)lvs通常作为总入口,更精细化的切割可能使用haproxy或者Nginx实现  7、在负载均衡中,LVS的实现方式
lvs的类型:
    lvs-nat
    lvs-dr (direct routing)
    lvs-tun (ip tunneling)
    lvs-fullnat (同时改变请求报文的源IP和目标IP)
    注意:前三种为标准类型;fullnat为后来添加的类型,内核默认可能不支持;  下面详细介绍LVS几种类型的工作模式
  lvs-nat:多目标的DNAT:通过将请求报文的目标地址和目标端口修改为挑选出某RS的RIP和PORT来实现;
  工作流程图如下:
DSC0001.jpg

  实现过程说明:
1.客户端将请求发往前端的负载均衡器,请求报文源地址是CIP(客户端IP),后面统称为CIP),目标地址为VIP(负载均衡器前端地址,后面统称为VIP);
2.负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去;
3.报文送到Real Server后,由于报文的目标地址是自己,所以会响应该请求,并将响应报文返还给LVS。
4.然后lvs将此报文的源地址修改为本机并发送给客户端。注意:在NAT模式中,Real Server的网关必须指向LVS,否则报文无法送达客户端;
5.NAT模型其实就是一个多路的DNAT,客户端对VIP进行请求,Director通过事先指定好的调度算法计算出应该转发到哪台RS上, 并修改请求报文的目标地址为RIP,通过DIP送往RS. 当RS响应客户端报文给CIP,经过Director时;
Director又会修改源地址为VIP并将响应报文发给客户端. 这段过程对于用户来说是透明的。  配置注意事项:
(1) RIP和DIP应该使用私网地址,RS的网关应该指向DIP;
(2) 请求和响应报文都要经由director转发;极高负载的场景中,Director可能会成为系统瓶颈;
(3) 支持端口映射;
(4) VS必须为Linux,RS可以是任意的OS;
(5) RS的RIP与Director的DIP必须在同一IP网络;  

  lvs-dr:direct routing
  通过修改请求报文的MAC地址进行转发;IP首部不会发生变化(源IP为CIP,目标IP始终为VIP);
  流程图如下:
DSC0002.jpg

  

  过程说明:
1、客户端将请求发往前端的负载均衡器,请求报文源地址是CIP,目标地址为VIP。
2、负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址,目标MAC改为了RIP的MAC地址,并将此包发送给RS。
3、RS发现请求报文中的目的MAC是自己,就会将次报文接收下来,处理完请求报文后,将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意:需要设置lo接口的VIP不能响应本地网络内的arp请求。
DR模型是一个较为复杂的模型. DR模型比较诡异, 因为VIP在Director和每一个RS上都存在,客户端对VIP(Director)请求时,Director接收到请求会将请求报文的源MAC地址和目标MAC地址修改为本机DIP所在网卡的MAC地址和指定的RS的RIP所在网卡的MAC地址, RS接收到请求报文后直接对CIP发出响应报文, 而不需要通过Director  配置注意事项:
  (1) 由于Real Server和Director都要设置相同的VIP,确保前端路由器将目标IP为VIP的请求报文一定会发送给Director;
  解决方案:
  静态绑定:在硬件设备(交换机)上设置MAC和IP绑定;
  禁止RS响应VIP的ARP请求;
      (a) arptables;
      (b) 修改各RS的内核参数,并把VIP配置在特定的接口上实现禁止其响应;
  (2) RS的RIP可以使用私有地址,也可以使用公网地址;
  (3) RS跟Director必须在同一物理网络中;
  (4) 请求报文必须由Director调度,但响应报文必须不能经由Director;
  (5) 不支持端口映射;
  (6) 各RS可以使用大多数的OS;
  

  lvs-tun:ip tunneling,ip隧道
  工作流程图:
DSC0003.jpg 工作流程说明:

1、客户端将请求发往前端的负载均衡器,请求报文源地址是CIP,目标地址为VIP。
2、负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP,目标地址改为RIP,并将此包发送给RS。
3、RS收到请求报文后,会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP,所以会处理次请求报文,并将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意:需要设置lo接口的VIP不能在公网上出现。
tun模型原理如下:
TUN模型通过隧道的方式在公网中实现请求报文的转发,客户端请求VIP(Director),Director不修改,请求报文的源IP和目标IP,而是在IP首部前附加DIP和对应RIP的地址并转发到RIP上,RS收到请求报文,本地的接口上也有VIP,遂直接响应报文给CIP。  注意事项:
  (1) RIP,DIP,VIP全得是公网地址;
  (2) RS的网关不能也不可能指向DIP;
  (3) 请求报文经由Director调度,但响应报文将直接发给CIP;
  (4) 不支持端口映射;
  (5) RS的OS必须支持IP隧道功能;
  

  lvs-fullnat:同时改变请求报文的源IP和目标IP
  工作流程图:
DSC0004.png 说明:

FULLNAT实现原理:
   FULLNAT是近几年才出现的,客户端请求VIP(Director),Director修改请求报文的源地址(DIP)和目标地址(RIP)并转发给
   RS, FULLNAT模型一般是Director和RS处在复杂的内网环境中的实现。
实现FULLNAT模型需要注意的:
    1、VIP是公网地址, DIP和RIP是内网地址, 但是无需在同一网络中
    2、请求报文需要经过Director, 响应报文也要通过Director
    3、RIP接收到的请求报文的源地址为DIP,目标地址为RIP
    4、支持端口映射
    5、RS可以是任意的操作系统  




运维网声明 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-658855-1-1.html 上篇帖子: corosync/openais + ldirectord 实现LVS中的Direcor高可用 下篇帖子: LVS负载均衡集
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

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

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

扫描微信二维码查看详情

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


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


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


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



合作伙伴: 青云cloud

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