本文共 4170 字，大约阅读时间需要 13 分钟。

LVS有四种工作模型

NAT:本质上就是iptable的DNAT（把内网的主机发布到互联网上，让用户访问，使用的技术是把目标地址做了转换，如果请求报文对应目标地址转换的就叫DNAT，DNAT的场景适用于互联网的用户访问内网的服务器）

（对应的SNAT，是把源地址做为转换，适用于内网访问互联网，出去访问就需要把源地址换成一个公网地址，只看请求报文）但是iptable中能转一个主机，起不到一个调度的效果

LVS，不仅可以转发到内部，还可以起到调度的效果

DR

TUN

FULLNAT

**DR模型的特点和NAT的特点不一样

NAT：（互联网用户发的请求报文）替换的是目标地址，替换成成其中的一个RS地址，请求报文和响应报文都是经跟LVS服务器的，这样LVS服务器有可能成为性能瓶颈，支持端口映射（lvs服务器发布到互联网上的端口号，和后端用到的real server用到的端口号，可以是不一样的。 lvs服务器可能有两个地址，一个是VIP,一个是DIP，DIP是连接内网的，VIP是公网的，所以在NAT模式下，配置看起来有点像路由器，因为两个网卡一个连外网一个连内网，NAT模式下你能否配一个网卡（可以，一个网卡上配置两个地址） ** DR模型的特点，数据报文到达LVS服务器，会把数据报文中的mac地址加以修改，修改的是目标mac地址，源目标mac地址也会变

只是改数据链路层的mac地址，应用层的tcp端口，IP地址不变，既然是数据链路层就不能跨路由，也就是LVS服务器和RS是不能隔路由器的，只能加交换机

（在这个过程，如何获取对方mac地址，如何到达rs，就是通过广播找，事先在LVS服务器上配置了RS的ip地址，知道要往哪个机器上去调度，但是仅仅知道ip，但不知道在哪里，就需要用到arp广播找到mac地址，mac地址找到后才能去修改数据报文中的目标mac，把这个目标mac填充为rs的mac地址）所以中间是不能用路由器隔开的，必须在一个网段里

由于修改的是mac地址，rs和lvs都是拥有同样的VIP的的，客户端的请求，rs在回应的时候因为本身就有VIP，就可以直接回应，就不需要在经过LVS服务器，减少了LVS服务器的负担

缺点是，只修改数据链路层，ip应用层和传输层都不动，端口就改不了，所以LVS是80端口，你RS也必须是80端口，不支持端口映射，要确保RS和LVS的IP地址都要是同一个IP，

这时候就需要有一种手段避免冲突

（可以在路由器上做mac地址绑定，也可以用arptable，但是用的不是很多

更多的时候修改内核参数，arp_ignore arp_announce，一个是不响应，一个是不发布，这样拥有同一个地址就不会产生冲突的提示了） **tun（隧道），在转发数据的时候，把数据报文拿过来，然后在数据报文的ip的地方（ip报文头部，网络层源地址本是CIP） （应用层报文头部如http，里面是传输层头部，如tcp，再往里ip报文头部 ** tun模式会在里面继续封装一个报文头部，这个头部是新的报文头部，会加源地址CIP，目标是RIP

成为了一个新的ip报文头部了，就经过层层转发，到达了rs服务器，rs服务器收到后，接收数据报文，然后把报文拆开，拆开以后发现有一个新的IP报文，新的报文发现是CIP发送过来的，vip是目标，就需要在RS上配置VIP，不然就抛弃了，这一点和DR模式类似 但是并不会产生地址冲突的问题，因为中间往往用路由器隔开

DIP和RIP不仅可以隔路由器，甚至可以隔一个互联网，dip在北京，vip在深圳都是可以做到的

跨机房的调度 rs看到是CIP发过来的请求，实际收到的报文已经变成如下 给cip回应没有必要原路返回，就可以经过别的路由器回来 这样就可以实现跨机房的远程调度，

tun模式在rs上需要做一些相关设置，因为收到了两个报文头部，正常的ip报文头部是一个，收到之后，先要把IP报文头部去了拿到一个新的里面藏着的原来的IP报文头部，不做设置，否则认为是一个奇怪的数据报文 1.RIP和DIP可以是私网地址，虽然是一个北京，一个上海，但是中间是专线，专线就可以是内网地址，走互联网就有可能使公网地址了

2.rs的网关指向DIP就必须响应的时候也走LVS，就没有TUN的含义了，tun本身就是跨地区，中间隔了很多路由器的

3.director 就是指LVS服务器

4.不支持端口映射，因为修改的只是IP头部，TCP的报文头部没有修改

5.RS的OS服务器需要支持隧道功能，收到两个IP头部，需要做一些配置，不是所有系统都支持的

tun模式可以实现跨异地机房，可以容灾 fullnat模式和nat模式很像，nat模式，替换的是请求报文的目标地址，源地址不替换 fullnat模式就有些变化了，DIP是源地址，RIP是目标地址，cip被替换成DIP ,VIP替换成RIP的某一个

这样LVS和Rs中间可以隔网段，可以加路由 NAT下只替代目标地址，源地址不替代，源地址不替代，中间也可以加路由，但RS发送的数据报文需要原路回来，这时候的区别就是web服务器的日志认为是LVS在进行访问 fullnat默认不支持，需要重新编译 nat模式和DR模式用的比较多

fullnat和nat的区别

nat 只替换目标地址， （中间也可以隔路由器）

fullnat 源地址和目标地址都进行替换 tun模式工作原理是新封装了一个IP头部，新的头部里面放了DIP,RIP，RIP可以是公网地址也可以是私网地址，私网地址就需要拉专线

DR模型，RS的地址用公网和私网都可以， 不管哪个往RS和LVS都需要在一个网段，不能跨路由

NAT,fullnat都需要经过原路返回， 支持的后端RS比较有限（达到10，20个

tun，封装新的报文头部，DR，都不需要经过原路返回，这样对LVS服务器的性能要求不是很高，就可以支持更多的RS（可以达到100台 调度的问题，静态调度算法和动态调度算法，无非就是考虑不考虑后端RS的压力 静态的就是设定了固定的算法调度，不管后面的RS的负载情况如何

静态4种算法，动态6种算法，总共10种算法，面试 1.轮询 2.WRR加权调度，相对来讲要考虑后端服务器的性能

定义一个权重，按比例分配，测试的时候测的量大一些就能显示了 **3.源哈希，就是实行的session sticky(绑定)，调度掉第一台机器，那么会话信息就是保存在第一台机器上的（下次如果调度到第2台机器，那么会话信息就丢了，比如一些购物车信息，之前的解决方案是根据IP地址和调度到哪个RS的地址，记录在调度器上) 为什么叫哈希，是因为并不是把源地址真的记录下来，而是进行哈希运算，就意味着要把源地址做一个哈希运算，得出一个摘要，MD5对于任何数据算出来都是128位的二进制，只要ip地址一样哈希值就一样 ** 目标地址哈希，看的是，上次往哪里调度，这次还是往哪里调度，是把目标地址做了一个调度 准确的画法是

小区的代理服务器先去缓存服务器上找数据，没有数据，缓存服务器再去youku上去找 缓存的服务器如何确保数据都缓存在里面，事实上命中率越高越好，怎么去调度到有数据的缓存服务器上去

如果优酷数据先缓存到第一台机器上去，，用户看了，再去访问，应该继续往缓存1服务器上去调度，

所以代理服务就会有一个根据目标地址进行转发，只要是youku，就应该固定的往缓存1服务器上调度

如果是腾讯的信息缓存到了第二台服务器上，用户访问腾讯，代理服务器就会往第二台缓存服务器上调度

DH模型一般是正向代理，proxy是正向代理服务器

一般电信的管带运营商用这种方式 动态地需要根据RS的负载情况，根据后端服务器的负载情况调度 1.最少连接调度，哪台服务器负载比较小，就优先往哪里调度

活动链接数acticeconns*256+inactiveconns不活动的链接数（握手了没有数据交换，什么事情也不敢，叫非活动连接）

谁的值越小就往谁上面调度 机器是有老旧问题的，所以有个权重问题 但是这样，如果首次访问，哪台机器在前面（LVS命令加在第一个就是第一了，权重是2，但是性能不好）就先调度到哪台机器上，但是如果这台机器性能差的话，就不合理 所以有了第三种,SED shortest 最短 expection期望 delay延迟 ，解决的就是初始的时候让连接权重高的优先

只要活动链接+1，那就是没有链接数也不会算出等于0了，这样权重为5的主机，得出的数就小，就优先调度

但是如果权重差距太大，也会导致，其他机器不干活，n能干的累死 **never queue 第一次不按照什么权重的算法。第一次均匀分配，后续第二次的时候才按照SED按权重 ** LC最短链接，动态的DH算法

当第一个缓存服务器负载过大的时候，可以将请求进行调度，调度到第二台机器上去，即使访问优酷也往这里调度，这样优酷视频在两个缓存服务器上调度了，这样就实现了一个负载均衡，而不会导致一个机器累死的情况 LBLCR witch replication带复制功能 ,之前的根据负载来调度的话，终究不是很严谨

现在发现youku访问量很大，就把缓存每个缓存服务器上都去复制一份，这样都有缓存，用户的请求转发到每个机器上都可以进行访问，这样就可以实现更加均衡的负载 这样的算法电信运营商用的比较多，更多的是用的下面这种 3.SNAT原理都知道，有可能大家都是从一个局域网出来的，所以可以用session，每个电脑都有session，这样范围就小一些 WLC是比较推荐的算法，而且是默认推荐的，面试问你，就说是WLC

config定义了一些内核配置情况 就有一些调度算法 schedular 预订计划 以模块方式编译进去的，所以内核级就有这个功能 进行调度时候是基于某个协议来进行调度的，如果调度的是http服务但走的是ping那么icmp协议根本调度不了，需要用curl测试 对应的软件包 没有提到fullnat，内核默认不支持

安装程序包 服务名，用ipvsadm来调用规则

跟iptables类似

配置文件但是里面没有什么内容 还没有定义任何LVS规则

转载地址：http://bfkgn.baihongyu.com/