一、LVS-DR模型架构图
二、DR模型实现负载均衡的工作方式
说了NAT模型的实现方式,那么NAT模型有个缺陷,因为进出的每个数据包都要经过Director Server,当集群系统负载过大的时候Director Server将会成为整个集群系统的瓶颈,那么DR模型就避免了这样的情况发生,DR模型在只有请求的时候才会经过Director Server, 回应的数据包由Real Server 直接响应用户不需要经过Director Server,其实三种模型中最常用的也就是DR模型了,下面来说DR模型具体是怎么实现负载均衡的,根据上图,
1, 首先用户用CIP请求VIP,
2, 根据上图可以看到,不管是Director Server还是Real Server上都需要配置VIP,那么当用户请求到达我们的集群网络的前端路由器的时候,请求数据包的源地址为CIP目标地址为VIP,此时路由器会发广播问谁是VIP,那么我们集群中所有的节点都配置有VIP,此时谁先响应路由器那么路由器就会将用户请求发给谁,这样一来我们的集群系统是不是没有意义了,那我们可以在网关路由器上配置静态路由指定VIP就是Director Server,或者使用一种机制不让Real Server 接收来自网络中的ARP地址解析请求,这样一来用户的请求数据包都会经过Director Servre,
3,当Director Server收到用户的请求后根据此前设定好的调度算法结果来确定将请求负载到某台Real Server上去,假如说此时根据调度算法的结果,会将请求负载到Real Server 1上面去,此时Director Server 会将数据帧中的目标MAC地址修改为Real Server1的MAC地址,然后再将数据帧发送出去,
4,当Real Server1 收到一个源地址为CIP目标地址为VIP的数据包时,Real Server1发现目标地址为VIP,而VIP是自己,于是接受数据包并给予处理,当Real Server1处理完请求后,会将一个源地址为VIP目标地址为CIP的数据包发出去,此时的响应请求就不会再经过Director Server了,而是直接响应给用户
编辑DR有三种方式 第一种方式：在路由器上明显说明vip对应的地址一定是Director上的MAC，只要绑定，以后再跟vip通信也不用再请求了，这个绑定是静态的，所以它也不会失效，也不会再次发起请求，但是有个前提，我们的路由设备必须有操作权限能够绑定MAC地址，万一这个路由器是运行商操作的，我们没法操作怎么办？第一种方式固然很简便，但未必可行。 第二种方式：在给别主机上（例如：红帽）它们引进的有一种程序arptables,它有点类似于iptables,它肯定是基于arp或基于MAC做访问控制的，很显然我们只需要在每一个real server上定义arptables规则，如果用户arp广播请求的目标地址是本机的vip则不予相应，或者说相应的报文不让出去，很显然网关（gateway）是接受不到的，也就是director相应的报文才能到达gateway，这个也行。第二种方式我们可以基于arptables。 第三种方式：在相对较新的版本中新增了两个内核参数(kernelparameter)，第一个是arp_ignore定义接受到ARP请求时的相应级别;第二个是arp_announce定义将自己地址向外通告是的通告级别。【提示：很显然我们现在的系统一般在内核中都是支持这些参数的，我们用参数的方式进行调整更具有朴实性，它还不依赖于额外的条件，像arptables,也不依赖外在路由配置的设置，反而通常我们使用的是第三种配置】 arp_ignore:定义接受到ARP请求时的相应级别 0：只要本地配置的有相应地址，就给予响应。 1：仅在请求的目标地址配置请求到达的接口上的时候，才给予响应 2：只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内 3：不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应 4-7：保留未使用 8：不回应所有（本地地址）的arp查询 arp_ignore 设置为1，当别人的arp请求过来的时候，如果接收的设备上面没有这个ip，就不响应，默认是0，只要这台机器上面任何一个设备上面有这个ip，就响应arp请求，并发送MAC地址应答。 arp_announce：定义将自己地址向外通告是的通告级别; 0: 将本地任何接口上的任何地址向外通告 1：试图仅想目标网络通告与其网络匹配的地址 2：仅向与本地借口上地址匹配的网络进行通告
补充LVS-DR原理
所有的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地址的通告级别的。
三、配置集群服务
1、在Real Server1和Real Server2上做配置如下
# 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 以上命令需填加到/etc/rc.local文件中让其开机自动生效 # vim /etc/sysconfig/network-scripts/ifcfg-lo:0 内容如下 DEVICE=lo:0 IPADDR=10.19.166.88 NETMASK=255.255.255.255 BROADCAST=10.19.166.88 ONBOOT=yes NAME=loopback # ifdown lo:0 # ifup lo:0 # route add -host 10.19.166.88 dev lo:0 # echo "route add -host 10.19.166.88 dev lo:0" >> /etc/rc.local
2、在Director Server上做以下配置
# vim /etc/sysconfig/network-scripts/ifcfg-eth2:0 内容如下 DEVICE=eth2:0 IPADDR=10.19.166.88 NETMASK=255.255.255.255 BROADCAST=10.19.166.88 ONBOOT=yes # ifdown eth2:0 # ifup eth2:20 # route add -host 10.19.166.88 dev eth2:0 # echo "route add -host 10.19.166.88 dev eth2:0" >> /etc/rc.local # echo "1" > /proc/sys/net/ipv4/ip_forward # echo "echo "1" > /proc/sys/net/ipv4/ip_forward" >> /etc/rc.local # ipvsadm -A -t 10.19.166.88:80 -s wlc # ipvsadm -a -t 10.19.166.88:80 -r 10.19.166.119 -g -w 2 # ipvsadm -a -t 10.19.166.88 -r 10.19.166.84 -g -w 1
