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

[经验分享] LVS基础详解和NAT/DR模型的实现

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2015-7-9 08:29:05 | 显示全部楼层 |阅读模式
LVS:Linux Virtual Server
所谓虚拟的服务就是,当客户端请求服务时,将服务在前端调度器上,通过一定方式负载到后端多台服务器上,但对于客户端来说是不可见的,像在访问同一台服务器一样,这就是虚拟的意思

原理
  • ipvs:使用LVS服务时,在linux内核当中的一个过滤框架,作用在Input链上,通过解析用户请求的ip和端口号,判断是否是集群服务(若较老的版本内核中没有内置则需自行编译安装)

     当用户请求到达,进入调度器内核空间,由于请求的是本地地址,转发到Input链,通过请求的ip和端口,判断请求的服务是否是集群服务,若不是则根据端口号进入用户空间访问本地服务,是的话将请求报文在Input链上进行处理,转发到FORWARD链,最后到达POSTROUTING链,转发到相应的后端服务节点
     所以LVS和iptables不能同时使用
  • ipvsadm:是LVS在用户空间对集群服务进行管理的工具


调度算法实现负载
Scheduler Method(调度方法):当客户端请求到达时,调度器以什么标准选择后端较为合适的服务器节点进行请求分发
两种类型调度
静态调度:不考虑后台服务器的连接负载情况
  • rr(Round Robin ):轮询
  • wrr:weight 加权轮询,在轮询之前,计算各服务器权重的比例,再进行调度
  • sh:source hash 源地址哈希:记录客户端的哈希和对应服务器,下次来自同一主机的请求将根据之前的记录,分配相同的服务器节点处理

    cookie和session:客户端第一次发起访问时,服务端发送cookie给客户端,客户端保存cookie,之后每次请求都会附加cookie信息,服务端以此对客户端进行标识,并在服务器端的内存内部保存有用户浏览的记录、url等信息,这就是session
     session share:服务集群后端服务节点间session 共享(通过网络,或同步到共享存储当中),这样的话客户端的浏览记录等信息就实现了共享,即使客户请求被分配到不同的节点,即使服务器节点故障,浏览信息是同步的。若是session shared,则不需要这种调度算法,当服务器发生故障,session share也是很好的预防措施
  • dh:destination hash 目标地址哈希(针对缓存服务器,第一次请求获得的缓存可能其他的缓存服务器没有缓存,请求同样的内容时,分配到相同的缓存服务器,无需再次缓存)

动态调度
  • lc:最少连接
    比较后端realserver的 active*256+inactive,挑选值小的发送请求
  • wlc:加权最少连接(lpvs默认)
    比较后端realserver的 (active*256+inactive)/ 权重,挑选值小的发送请求
  • sed:shortest expect delay 最短期望延迟
    (active+1)*256/ weight
  • nq:never queue 永不排队

在sed基础上第一次无论如何每台服务器都发送一次请求
  • LBLC:Locality-Based lc 基于本地最少连接
    考虑 cache 连接数,但相同的请求尽可能发送给同一个缓存服务器,相当于动态的 dh
  • LBLCR:LBLC with Replication Scheduling 带缓存复制功能
    LBLC会考虑最小连接数,但还是会对相同用户请求分发到相同后端缓存服务器,而LBLCR直接对后端的缓存服务器动态调度,并且缓存共享(指部分共享,当请求的缓存服务器没有缓存时,而另外的服务器有,则同步请求的缓存内容)


LVS三种模式
  • NAT:地址转换
  • DR:直接路由
  • TUN:隧道模型


NAT模型
实现原理:客户端发起请求,请求到达Director负载均衡器后,根据调度算法,选择适当的后端服务节点进行请求分发,Director再利用返回结果对客户端做出响应,实现负载均衡
wKioL1WdPRXylHjuAABzzkEK7w4133.jpg
规则:
  • 集群节点跟director必须在同个网络中
  • RIP通常是私有地址,仅用于集群节点间通信
  • director处于client和Realserver之间,负责处理进出的所有通信
  • realserver必须将网关指向DIP

以下为一个简单的实验和注意的点
1:地址规划
wKioL1WdPT-iSgI7AACQ1MTKwzI115.jpg
2:安装ipvsadm
3:查看是否支持ipvs内核功能
wKiom1WdO2-BHjQXAAB96EGkKgM096.jpg

4:注意Director和Realserver间的时间同步
5:注意ipvsadm和iptables的使用不可以共存,因为使用的都是netfilter框架的过滤机制
6:地址配置:
  • Direct两个网卡分别面向内网和外部网络,虚拟机模式下,内部网络应使用host-only模式
  • Realserver网关因指向Direct的内网地址

7:开始配置lvs(使用rr轮询调度
wKiom1WdPIDwqY25AACYv1qXhAI793.jpg
  • -t使用tcp协议的集群,-s指定调度算法,-r指定realserver,-m指定为nat模型

8:查看配置
wKioL1WdPlDy-MV4AADOskqSmME426.jpg

9:测试
  • RS1网页内容为:This is Realserver1
  • RS2网页内容为:This is Realserver2

wKiom1WdPICjYgSbAADHTo1eFlw396.jpg

  • 从结果看出已实现轮询调度功能
  • 若外部主机测试不成功,可能是网卡转发功能没有启动

wKioL1WdPm6DE1CFAABeA4_PAO0813.jpg
10:查看连接状态
wKioL1WdPm-TIgetAADiLCrRtus260.jpg

11:修改调度算法为(wrr加权轮询,并验证)
wKiom1WdPJ-BScRBAAFxR5E55Eg076.jpg

效果
wKiom1WdPMCAb_UyAAFej98IEfo453.jpg

DR模型
首先,DR模型相对于NAT模型的好处在于Director只接收请求并转发给 Real server,不响应请求,大大增强性能
实现原理:Director和Realserver都配有VIP地址和自身的网卡地址,客户端发起请求,ip报头的源目地址为CIP和VIP,Direct接收到报文后,发现请求的是集群服务,将不改变ip以上的报文数据,源目地址还是CIP和VIP,直接将MAC地址改为Direct MAC和RS MAC,将报文转发给Realserver,Realserver收到报文后,接收请求,生成响应报文,并直接做出响应
流程:
wKioL1WdPq-AW_-jAAC8-zaRavQ921.jpg
为了实现以上的解决方案,需要解决以下两个问题
1:Director和Realserver都配有VIP地址,若同个网络中有很多个相同的ip地址,将会造成ARP混乱,而我们只需要通告Director的VIP即可
  • 利用arp的通告响应级别机制

arp_announce
级别0:默认级别,本地任何接口地址全部通告
级别1:尽可能不通告和对方网络地址不相同的地址
级别2:不通告和对方网络地址不相同的地址,如:本地的eth0和lo口配的是不同的地址,lo口的地址将不会通告到eth0接口连接的网络中
arp_ignore
级别0:默认级别,本地有的,都给予响应
级别1:只有在请求的地址配置在请求到达的接口上时才给予响应
     可以将VIP设置在Realserver的Lookback口,不做通告和响应
     同时Director的VIP可设置在eth0:0上,正常的回复arp请求
  • 或者若对出口路由有控制权的时候,对于VIP直接指静态路由到Director即可

2:Realserver收到报文后,做出响应,此时源目ip为VIP和CIP,报文如何到达Client
一般情况下,CIP为公网ip,是网络上客户端的ip,VIP也为公网ip,当RIP和VIP不在同一个网段中时,为了让响应报文正常发送,须将Realserver的网关指向出口设备(可能是运营商设备),RIP可以是私网地址,也可以是公网地址
规则
  • 各集群节点和director必须在同一个物理网络中
  • RIP可以使用公网地址,实现便捷的网络管理
  • director只接收请求,通过real直接响应客户请求
  • 不支持端口映射
  • 要求能隐藏 vip 的操作系统作为realserver
  • 能比nat模型支持更多的节点

实验(利用内部网络做简单模拟,出口路由设备非运营商设备的情况下)
实验规划:
wKiom1WdPOCAw_rxAAELIovJZwE289.jpg
1:按照规划先配好地址,实验环境下地址都应为桥接模式
2:Realserver应先配置arp的响应级别再配置Lo口的VIP地址,还要设置
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

ifconfig lo:0 192.168.199.133 netmask 255.255.255.255 broadcast 192.168.199.133 up #广播地址为VIP地址,指网络中只有本身一个地址
route add -host 192.168.199.133 dev lo:0 #默认路由表示在当请求的是192.168.199.133这个VIP地址时,进行响应时应该通过lo:0出去,即响应时的ip为VIP而不是eth0的ip

3:在Director上的配置
ifconfig eth0:0 192.168.199.133 netmask 255.255.255.255 broadcast 192.168.199.133 up
router add -host 192.168.199.133 dev lo:0
wKioL1WdPt_QoSxKAAEL-1TRIuA407.jpg



运维网声明 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.iyunv.com/thread-84538-1-1.html 上篇帖子: LVS+KeepAlived,RabbitMQ高可用负载均衡 下篇帖子: LVS的nat模型和DR模型的配置管理 模型
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

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

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

扫描微信二维码查看详情

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


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


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


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



合作伙伴: 青云cloud

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