LVS的VS/NAT及VS/DR类型实现

目录

1、虚拟服务VS/NAT类型实现

2、虚拟服务VS/DR类型实现

3、总结

1、虚拟服务VS/NAT类型实现

1.1、VS/NAT实验拓扑图：

1.2、director配置如下：

[root@vs ~] ipvsadm -A -t 192.168.0.200:80 -s rr #定义集群服务
[root@vs ~] ipvsadm -a -t 192.168.0.200:80 -r 10.0.0.10:80 -m -w 1 #向集群服务中添加rs
[root@vs ~] ipvsadm -a -t 192.168.0.200:80 -r 10.0.0.20:80 -m -w 1
[root@vs ~] echo "1" > /proc/sys/net/ipv4/ip_forward  #打开转发功能
[root@vs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.0.200:80 rr
  -> 10.0.0.10:80                 Masq    2      0          0        
  -> 10.0.0.20:80                 Masq    2      0          0

1.3、real server配置如下：

    在VS/NAT类型中，real server服务器不需要做特殊的配置处理，只要把应用部署好，保证网络能与director的dip连通，网关一定要配置成dip的地址即可。real server部署的应用就是之前部署的tomcat，在本地利用httpd反应代理到本地的tomcat，而部署的应用就是一测试文件，此文件能记录客户端的session信息，这样能验证之后的lvs的持久连接实验。httpd反向代理tomcat请点击http://zhaochj.blog.51cto.com/368705/1642199 。

1.4、测试：

不断刷新页面，会在TomcatA与TomcatB页面间切换，在理想状态下会是1:1的比例进行切换，因为在定义集群服务器采用了round robin算法。

1.5、小结：

    VS/NAT模型的实现是最容易实现的类型，后端的real server只需提供其应用，无需额外的配置，请求报文和响应报文都会通过director，对director的压力会比较大，后端的real server的数量不能太多（3-5节点较好），director易成为此负载均衡系统的瓶颈。

2、虚拟服务VS/DR类型实现

    VS/DR类型的拓扑大致有两种，在前边的博客中已有提到过，一是vip与rip是同一类ip地址范围，二是vip与rip不是同一类ip地址范围，为了实现的便捷性采用vip与rip在同一类ip地址范围的拓扑，两种拓扑在配置上几乎都是相同的，仅是在real server的网关指向上不同而已。

2.1、拓扑图：

2.2、director配置：

在eth0的子接口上配置vip及虚拟服务的规则：

[root@HAPROXY ~]# ifconfig eth0:0 192.168.0.222/24
[root@HAPROXY ~]# ipvsadm -A -t 192.168.0.222:80 -s rr
[root@HAPROXY ~]# ipvsadm -a -t 192.168.0.222:80 -r 192.168.0.201:80 -m -w 1
[root@HAPROXY ~]# ipvsadm -a -t 192.168.0.222:80 -r 192.168.0.202:80 -m -w 1
[root@HAPROXY ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.0.222:80 rr
  -> 192.168.0.201:80             Masq    1      0          0        
  -> 192.168.0.202:80             Masq    1      0          0

2.3、real server配置：

分两步完成，顺序一定不能错，第一步配置内核参数，改变网卡接口对arp的响应及通告本地网络机制：

[root@master ~]# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
[root@master ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
[root@master ~]# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
[root@master ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

内核参数说明：

arp_ignore：表示如何响应接收到的arp报文请求，默认值为“0”，表示只要收到arp报文就要给予响应；值“1”表示仅在arp请求报文中请求的地址是配置在请求报文进入接口的才进行响应。

arp_announce：表示如何通告本地地址，默认值“0”，表示只要系统上配置了相应的接口就会全部通告给网络；值“2”表示仅通告直接连接网络的接口的地址。

第二步配置vip地址及增加路由：

[root@master ~]# ifconfig lo:0 192.168.0.222 netmask 255.255.255.255 broadcast 192.168.0.222 #此地址仅做响应时使用
[root@master ~]# route add -host 192.168.0.222 dev lo:0

#增加这条路由表示只要是目标地址是192.168.0.222这个vip的报文直接送到lo:0这个接口，这样强制改变报文的流向，当报文要响应给客户端时就会让响应报文从lo:0接口流出到到达实际的eth0接口，这样响应报文的源地址就被修改成了vip的地址，这样客户端接收到的报文中源地址是vip，目标地址是cip，这个报文客户端才能接收，如此就达到了出站报文直接从real server直接响应给客户端，而客户端不知道响应报文到底是director返回的还是real server返回的，对用户是透明的。

2.4、测试:

    浏览器访问“http://192.168.0.222”时页面会在TomcatA与TomcatB间切换，与VS/NAT的测试结果是一样的，参照上边的测试结果。

2.5、小结：

    此VS/DR类型要求vip、dip、rip在同一个ip网络中，如果在实际生产环境下这些ip地址都应该使用公网地址，这样所需要的公网地址较多，在ip地址匮乏的今天建议采用vip与rip不在同一网络的架构（拓扑图见http://zhaochj.blog.51cto.com/368705/1643712），这样dip与rip都可以使用私有地址，只有vip使用公有地址对外提供服务，而响应报文real server通过其自己的路由到达互联网响应给客户端。

    在各real server中一定要先调整各内核参数（arp_ignore和arp_announce），再配置vip地址，最后的静态路由一定不要忘记添加。

    对director的转发功能这里是可以不用开启的，因为vip与dip都是在同一个ip网络的。

3、总结

    至此LVS的NAT及DR类型都已实现，至于VS/TUN的类型暂时不讨论。这两种类型的负载均衡是实现了，但此博文中演示的环境都有一个现象，那就是每次访问主页时都会在两个页面间切换，如果提供的站点是需要用户登陆的，第一次访问被调度到了rs1，一刷新页面又被director调度到了rs2，这样会要求用户再一次登陆的，所以需要把用户的访问在一定时间内都调度到同一个real server上，这就是我们接下来讨论的lvs连接持久性的话题，当然目前我们也可以采用基于源地址hash的算法（sh）来实现持久连接，让同一个cip访问虚拟服务时被调度到同一个real server，这样也有一个弊端，因lvs持久连接的粒度是基于虚拟服务的，如果real server上提供的服务器不仅有http，还有httpd，这两个服务又有一定的相关性，那我们在director就要定义两个虚拟服务，有两个虚拟服务意味着就会对同一个cip访问不同的服务会采用各自的调度策略进行调度，这样也不能保证来自同一cip的请求http和httpd的服务会被调度到同一real server，这就是我们接下来会讨论的话题。