LVS-DR 集群

LVS-DR 集群

1LVS-DR工作原理

LVS-DR（Linux Virtual Server Director Server）工作模式，是生产环境中最常用的一种工作模式。

LVS-DR 模式，Director Server 作为群集的访问入口，不作为网关使用
节点 Director Server 与 Real Server 需要在同一个网络中，返回给客户端的数据不需要经过 Director Server。
为了响应对整个群集的访问，Director Server 与 Real Server 都需要配置 VIP 地址。

客户机发起请求，经过调度服务器（lvs），经过算法调度，去访问真实服务器（RS）由于不原路返回，客户机不知道真实主机的ip地址，所以只能通过调度服务器的外网ip（vip）去反回报文信息。

Director Server作为群集的访问入口，但不作为网关使用，后端服务器池中的Real Server与Director Server在同一个物理网络中，发送给客户机的数据包不需要经过Director Server。为了响应对整个群集的访问，DS（前端负载均衡节点服务器）与RS（后端真实服务器）都需要配置有VIP地址。

每个Real Server上都有两个IP：VIP（负载均衡对外提供访问的 IP 地址）和RIP（负载均衡后端的真实服务器 IP 地址），但是VIP是隐藏的，就是不能提供解析等功能，只是用来做请求回复的源IP的，Director上只需要一个网卡，然后利用别名来配置两个IP：VIP和DIP（负载均衡与后端服务器通信的 IP 地址），在DIR接收到客户端的请求后，DIR根据负载算法选择一台rs sever的网卡mac作为客户端请求包中的目标mac，通过arp转交给后端RS serve处理，后端再通过自己的路由网关回复给客户端

2LVS-DR数据流向

LVS-DR数据包流向分析
1、Clinent向目标VIP发出请求，Director（负载均衡器）接收

源ip：客户端ip，目标ip：虚拟ip，源MAC：客户端MAC地址，目标MAC：负载均衡器的MAC地址
2、Director根据负载均衡算法选择RealServer_1（真实服务器），不修改也不封装IP报文，而是将数据帧的MAC地址改为RealServer_1的MAC地址，然后在局域网上发送。

源ip：虚拟ip，目标ip：真实虚拟ip，源MAC：负载均衡器MAC，目标MAC：真实服务器MAC
3、RealServer_1收到这个帧，解封装后发现目标IP与本机匹配（RealSERVERS事先绑定了VIP），于是处理这个报文，随后重新封装报文，发送到局域网。

源ip：虚拟ip，目标ip：客户机ip，源MAC：真实ens33网卡MAC，目标MAC：客户端MAC
注意：如果跨网段，则报文通过路由器经由internet返回给用户
4、Client将收到回复报文，Client认为得到正常的服务，而不会知道是那一台服务器处理的。

2.1详细流程分析

①客户端通过路由器将访问请求发送到内网当中，需要通过APR将源地址解析为MAC地址进行访问，但是由于内网中DS(负载调度器)和RS(真实服务器)都配置了VIP，他们都可收到APR请求，并返回自己的MAC，这时候客户端的数据不知道往哪个上面发送，那就需要通过在真实服务器上配置 “路由紧固” + “只响应目标为本机ens33网卡信息的请求参数” ，因为DR上配置的是虚拟子接口，可以接收到信息，而RS，配置的是环回地址，无法收到ARP请求，那么这样就只有DS收到请求。收到请求后，客户端通过封装DS的MAC地址，进行二层转发。

DS收到请求后，通过调度算法选择需要转发的RS站点，因为都在局域网内此时转发只是二层的转发，那怎么发给RS站点呢？二层转发是局域MAC地址转发的，通过ARP获得RS的MAC地址，将获得的MAC地址封装为目标MAC地址，进行数据转发。

RS收到请求后，它可以直接请请求返回给客户端，不需要再经过DS，因为，它获取到数据包后，把数据包交个自己的ens33网卡，由ens33网卡将数据包转发出去，ens33进行APR广播，这里为了不修改ARP表的内容，在进行ARP广播，使用的源ip为RS的ens33接口ip。广播得到了客户机的MAC地址，再进行将数据转发，转发时，使用的源ip为：环回ip，源MAC为：ens33MAC，目标地址为：客户机地址，目标MAC为客户机MAC。

客户机收到数据包后，发现数据包的源地址为VIP，并不知道是哪一台服务器处理的，下次再发出请求时，直接根据ARP中的表项将数据再次转发到DS。

3LVS-DR的优缺点

优点：

做了2次负载均衡 第一次Director Server 对应2个人Real Server 第二次 只接受访问
负载均衡器只负责将请求包分发给物理服务器，而物理服务器将应答包直接发给用户。所以，负载均衡器能处理很巨大的请求量，这种方式，一台负载均衡能为 超过100台的物理服务器服务，负载均衡器不再是系统的瓶颈。使用VS-DR方式，如果你的负载均衡器拥有100M的全双工网卡的话，就能使得整个 Virtual Server能达到1G的吞吐量。甚至更高；

缺点：
这种方式需要所有的DIP和RIP都在同一广播域（局域网）；不支持异地容灾。

3.1DR模式特点

①Director Server 和 Real Server 必须在同一个物理网络中。
②Real Server 可以使用私有地址，也可以使用公网地址。如果使用公网地址，可以通过互联网对 RIP 进行直接访问。
③Director Server作为群集的访问入口，但不作为网关使用。
④所有的请求报文经由 Director Server，但回复响应报文不能经过 Director Server。
⑤Real Server 的网关不允许指向 Director Server IP，即Real Server发送的数据包不允许经过Director Server。
⑥Real Server 上的 lo 接口配置 VIP 的 IP 地址。

4LVS-DR问题总结

4.1LVS/DR如何处理请求报文的，会修改IP包内容吗？

vs/dr 本身不会关心IP层以上的信息，即使是端口号也是 tcp/ip 协议栈去判断是否正确，vs/dr本身主要做这么几个事：

接收client的请求，根据你设定的负载均衡算法选取一台 real server 的 ip；
以选取的这个 ip 对应的 mac 地址作为目标 mac，然后重新将IP包封装成帧转发给这台RS；
在hash table 中记录连接信息。
vs/dr 做的事情很少，也很简单，所以它的效率很高，不比硬件负载均衡设备差多少，数据包、数据帧的大致流向是这样的：client –> VS –> RS –> client。

4.2RealServer为什么要在lo接口上配置VIP？在出口网卡上配置VIP可以吗？

既然要让 RS 能够处理目标地址为vip 的IP包，首先必须要让 RS能接收到这个包。在lo上配置vip能够完成接收包并将结果返回 client。不可以将VIP设置在出口网卡上,否则会响应客户端的 arp request,造成 client/gateway arp table 紊乱，以至于整个 load balance 都不能正常工作。

4.3RealServer为什么要抑制arp帧？

我们知道仰制arp 帧需要在server上执行以下命令，如下：

echo “1” >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/lo/arp_announce
echo “1” >/proc/sys/net/ipv4/conf/all/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/all/arp_announce

因为arp对逻辑口没有意义。实际上起作用的只有以下两条:

echo “1” >/proc/sys/net/ipv4/conf/all/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/all/arp_announce

即对所有的物理网卡设置arp仰制。对仰制所有的物理网卡设置arp仰制是为了让CIP发送的请求顺利转交给DIR以及防止整个LVS环境arp表混乱，不然容易导致整个lvs不能工作。

4.4LVS/DR load balancer（director）与RS为什么要在同一网段中？

lvs/dr 它是在数据链路层来实现的，即RIP必须能够接受到DIR的arp请求，如果不在同一网段则会隔离 arp，这样arp请求就不能转发到指定的RIP上，所以director必须和RS在同一网段里面。

4.5为什么director上eth0接口除了VIP另外还要配一个ip（即DIP）？

如果是用了keepalived等工具做 HA或者Load Balance,则在健康检查时需要用到DIP。 没有健康检查机制的HA或者Load Balance则没有存在的实际意义。

4.6director的vip的netmask一定要是255.255.255.255吗？

lvs/dr 里，director 的vip的 netmask 没必要设置为255.255.255.255，director的vip本来就是要像正常的ip地址一样对外通告的,不要搞得这么特殊。

4.7RS设置 lo:0而不设置ens33:0的原因

因为“负载调度机”转发时并不会改写数据包的目的IP，所以“节点服务器”收到的数据包的目的IP仍是“负载调度器”的虚拟服务IP。为了保证“节点服务器”能够正确处理该数据包，而不是丢弃，必须在“节点服务器”的环回网卡上绑定“负载调度器”的虚拟服务IP。这样“节点服务器”会认为这个虚拟服务IP是自己的IP，自己是能够处理这个数据包的。否则“节点服务器”会直接丢弃该数据包！

“节点服务器”上的业务进程必须监听在环回网卡的虚拟服务IP上，且端口必须和“负载调度机”上的虚拟服务端口一致。因为“负载调度机”不会改写数据包的目的端口，所以“节点服务器”服务的监听端口必须和虚拟服务端口一致，否则“节点服务器”会直接拒绝该数据包。

“节点服务器”处理完请求后，响应直接回给客户端，不再经过“负载调度机”。因为“节点服务器”收到的请求数据包的源IP是客户端的IP，所以理所当然“节点服务器”的响应会直接回给客户端，而不会再经过“负载调度机”。这时候要求“节点服务器”和客户端之间的网络是可达的。

“负载调度机”和“节点服务器”须位于同一个子网。因为“负载调度机”在转发过程中需要改写数据包的MAC为“节点服务器”的MAC地址，所以要能够查询到“节点服务器”的MAC。而要获取到“节点服务器”的MAC，则需要保证二者位于一个子网，否则“负载调度机”只能获取到“节点服务器”网关的MAC地址。