LVS之DR模型架构

yanqiufang

所有的Director和RealServer都在同一个物理网络中(交换机)并且都只有一块网卡，交换机前面有个路由器，这个路由器可能是我们机房内部的，也有可能是网络运行商的。　　

　　
当客户端的请求被送到R2和Switch之间的时候，这个时候源ip是cip，目标地址是vip。vip一定在Director上是毋庸置疑的，所以这个报文就背送到Director的vip网卡上。
　　
当客户端的请求被送到Switch和Director之间的时候，这个时候源ip仍然是cip，目标地址是vip。Director发现当前本机配置的有vip地址，所以请求的一定是当前主机
　　
所以报文经过Prerouting链到达Input链，而监控在Input链上的ipvs规则发现请求的是一个集群服务，比如监听在80端口的web集群服务。这个时候lvs要根据ipvs规则
　　
等等要修改报文了，在LVS-DR模型下报文送到Director上的时候，Director不会拆它的IP首部，也不会拆它的TCP首部，Director只要将MAC地址或者帧首部拆掉了。
　　
为什么Director要拆开帧首部MAC地址呢？因为报文的目的地址就是Director本地主机，只要到达目的主机，网卡就会拆开帧首部的。因为目标MAC就是本地主机。
　　
拆掉帧首部以后，查看IP首部和TCP首部，它发现请求的报文访问的是一个集群服务。
　　
因此为了实现LVS-DR模型的效果，在源有的IP首部之上(切记源IP、目标IP、源端口、目标端口等等没有动)，仅仅是在原有的报文外面又重新封装了一个MAC地址帧首部
　　
帧首部有源MAC和目标MAC，这个时候发送的主机是Director。于是Director把本地网卡的MAC地址作为整个报文的源MAC地址，而目的MAC就是选择的后端某台RealServer
　　
[选择后端的某台RealServe是Director根据它的一些调度算法(rr,wrr...)选择的]。假如选择的是RealServer2，那么会找到RealServer2 IP对应的MAC地址，于是找到了
　　
RealServer2网卡对应的MAC地址，它是通过ARP地址解析找到的RealServer2对应的MAC地址。
　　
那么Director到RealServer2之间的报文传送是源MAC地址是Director网卡对应的MAC地址，目标MAC地址是RealServer2网卡对应的MAC地址。
　　
RealServer2接收到报文以后，发现请求的报文真的是自已，于是拆掉了MAC的帧首部，拆掉后发现请求的报文源地址是cip，目标地址是VIP。如果RealServer2上没有VIP
　　
，那么RealServer2是不会接受这个报文的，因此必须在每个RealServer上配置VIP地址。因为RealServer2上有VIP地址，报文被接收下来，拆掉了IP首部，发现了报文
　　
请求的是一个服务，比如80 因为传输层没有做任何修改，用户请求的是80服务，那么RealServer2接收到的报文也是请求的80服务。如果RealServer2上有80服务，于是
　　
RealServer2把这个请求转交给用户空间的进程，由用户空间处理完成后，向外响应的。而请求报文的源地址是CIP，目标地址是VIP。那么尽可能让它使用CIP是目标地址
　　
VIP是源地址，于是这个响应报文直接被发送到了交换机上。
　　

　　
当RealServer2响应报文到达Switch的时候，这个时候源地址是VIP，目标地址是CIP。
　　
因为目标地址是CIP，假如VIP和CIP不在同一个网段当中，这个时候要根据目标地址CIP做路由选择，比如默认路由，网关才能响应CIP的报文请求
　　
大家都知道目标地址CIP是互联网地址，那么每个RealServer的网关要指向哪呢？？？？？？
　　
要指向能够访问互联网的设备，不应该指向Director的DIP地址。而是直接指向了能够访问互联网的路由设备。所有(很有可能)指向的是R2路由的私有地址做网关。
　　
为什么是很有可能而不是说一定呢？？？？
　　

　　

　　
当报文被送到Switch和R2的时候，这个时候的源地址是VIP，目标地址是CIP。那么这个时候报文被送到R2网关的时候，R2发现目标地址是互联网的地址CIP，它会通过
　　
路由NAT然后被送到CIP上的。
　　

　　

　　

　　
这里要考虑一个问题，为了实现每台RealServer在向外发送响应报文的时候，可以把VIP作为源地址，因此我们在每台RealServer上配置了VIP地址。
　　

　　
假如客户端发送请求报文被送到R2路由器的时候，那么R2路由器会拆开客户端的请求报文发现源地址是CIP，目标地址是VIP；无论是将请求送给Director还是RealServer，必须要根据
　　
MAC地址向内转发，因为在同一网段，那么它怎么知道VIP对应的MAC地址是什么呢？？？？
　　
那么将进行广播说：‘我知道有一个家伙的VIP地址，那么请告诉我它对应的MAC地址’，那么它发送的广播请求，同一网段的所有主机都能收到，于是配置有VIP地址的所有主机都进行相应并告诉自已的MAC地址，那么如果所有的主机都进行相应，那么前端的路由设备就混乱了，它就无法分辨谁才是VIP对应的MAC地址。
　　
默认情况下，谁相应的快，就会把客户端的请求报文发送给那台主机，如果被送到RealServer2 那么就不符合我们负载均衡的条件了。
　　
那么我们在这里需要做一个非常重要的事情，就是每台配置有RealServer的VIP地址不给予ARP响应。那么我们如果屏蔽它不能响应呢？
　　
那么所有的RealServer上都要关闭对ARP广播的响应。
　　
要达到的目的：让我们的前端路由或者网关，实现报文发送的时候，仅仅能够将报文对目标IP为VIP发送给Director？
　　
实现的方式有以下三种：
　　
1、在R2路由器的内部接口上手动绑定一个静态的解析地址，明确指明目标是VIP的MAC一定是Director的MAC
　　
   那么以后发送报文的时候就不用再次请求了，可以由指定的静态解析地址直接发送给Director
　　
   这个绑定是静态的也不会失效
　　
   缺点：
　　
   R2路由是内部路由器，那么VIP是私有地址；如果R2是网络运营商提供的路由设备，也就是VIP是公网地址，我们就无法再R2上进行静态绑定了。
　　
2、arptables：
　　
   基于MAC地址做访问控制的，我们只需要在每台RealServer上定义arptables规则，如果用户的arp广播请求的目标地址是本机的VIP则不给予响应或者响应的报文不出去。
　　
   那么这个情况所有的RealServer上不响应arp广播请求，只有Director响应给路由则报文就必然被发送给Director。
　　
3、kernel paramter:
　　
    arp_ignore
　　
    arp_announce
　　
    作用：限定我们的Linux主机对arp广播请求的响应级别，以及向外通告自已ip地址的通告级别的。