1、LVS-DR模型架构图前端
2、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了,而是直接响应给用户web
编辑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? 实现的方式有如下三种: 一、在R2路由器的内部接口上手动绑定一个静态的解析地址,明确指明目标是VIP的MAC必定是Director的MAC 那么之后发送报文的时候就不用再次请求了,能够由指定的静态解析地址直接发送给Director 这个绑定是静态的也不会失效 缺点: R2路由是内部路由器,那么VIP是私有地址;若是R2是网络运营商提供的路由设备,也就是VIP是公网地址,咱们就没法再R2上进行静态绑定了。 二、arptables: 基于MAC地址作访问控制的,咱们只须要在每台RealServer上定义arptables规则,若是用户的arp广播请求的目标地址是本机的VIP则不给予响应或者响应的报文不出去。 那么这个状况全部的RealServer上不响应arp广播请求,只有Director响应给路由则报文就必然被发送给Director。 三、kernel paramter: arp_ignore arp_announce 做用:限定咱们的Linux主机对arp广播请求的响应级别,以及向外通告自已ip地址的通告级别的。
3、配置集群服务
vim
一、在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
二、在Director Server上作如下配置bash
# 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