一，部分概念
服务器集群系统：
通过高性能网络或局域网互联的服务器集群正成为实现高可伸缩的、高可用网络服务的有效结构，这种松耦合结构的服务器集群系统有下列优点：
-
性能 网络服务的工作负载通常是大量相互独立的任务，通过一组服务器分而治之，可以获得很高的整体性能。
-
性能/价格比 组成集群系统的PC服务器或RISC服务器和标准网络设备因为大规模生产降低成本，价格低，具有最高的性能/价格比。若整体性能随着结点数的增长而接近线性增加，该系统的性能/价格比接近于PC服务器。所以，这种松耦合结构比紧耦合的多处理器系统具有更好的性能/价格比。
-
可伸缩性 集群系统中的结点数目可以增长到几千个，乃至上万个，其伸缩性远超过单台超级计算机。
-
高可用性 在硬件和软件上都有冗余，通过检测软硬件的故障，将故障屏蔽，由存活结点提供服务，可实现高可用性
用服务器集群系统实现可伸缩网络服务也存在很多挑战性的工作：
-
透明性（Transparency） 如何高效地使得由多个独立计算机组成的松藕合的集群系统构成一个虚拟服务器；客户端应用程序与集群系统交互时，就像与一台高性能、高可用的服务器交互一样，客户端无须作任何修改。部分服务器的切入和切出不会中断服务，这对用户也是透明的。
-
性能（Performance） 性能要接近线性加速，这需要设计很好的软硬件的体系结构，消除系统可能存在的瓶颈。将负载较均衡地调度到各台服务器上。
-
高可用性（Availability） 需要设计和实现很好的系统资源和故障的监测和处理系统。当发现一个模块失败时，要这模块上提供的服务迁移到其他模块上。在理想状况下，这种迁移是即时的、自动的。
-
可管理性（Manageability） 要使集群系统变得易管理，就像管理一个单一映像系统一样。在理想状况下，软硬件模块的插入能做到即插即用（Plug & Play）。
-
可编程性（Programmability） 在集群系统上，容易开发应用程序
二，linux virtual server
lvs:基于IP层和基于内容请求分发的负载平衡调度解决方法，并在Linux内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器.
体系结构：
一组服务器通过高速的局域网或者地理分布的广域网相互连接，在它们的前端有一个负载调度器（Load Balancer）。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访 问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到，通过检 测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的，我们称之为Linux虚拟服务器（Linux Virtual Server）。
1,IP虚拟服务器软件IPVS
在调度器的实现技术中，IP负载均衡技术是效率最高的.
IPVS 实现三种负载均衡技术：
-
Virtual Server via Network Address Translation（VS/NAT） 通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
-
Virtual Server via IP Tunneling（VS/TUN） 采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报 文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。
-
Virtual Server via Direct Routing（VS/DR） VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。
调度算法：
-
轮叫（Round Robin） rr 调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
-
加权轮叫（Weighted Round Robin） wrr 调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
-
最少链接（Least Connections） lc 调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
-
加权最少链接（Weighted Least Connections） wlc 在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
-
基于局部性的最少链接（Locality-Based Least Connections）lblc "基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。
-
带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）lblcr "带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。
-
目标地址散列（Destination Hashing）dh "目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
-
源地址散列（Source Hashing）sh "源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
2，体系结构
采用三层结构：
-
负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。
当主调度器失效时，主调度器上所有已建立连接的状态信息将丢失，已有的连接会中断。客户需要向重新连接，从调度器才会将新连接调 度到各个服务器上，这对客户会造成一定的不便。
为此，IPVS调度器在Linux 内核中实现一种高效状态同步机制，将主调度器的状态信息及时地同步到从调度器。当从调度器接管时，绝大部分已建立的连接会持续下去。
-
服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。
-
共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。
3，负载均衡技术
基于RR-DNS
基于IP层负载均衡调度
NAT实现虚拟服务器（VS/NAT）
NAT的工作原理是报文头（目标地址、源地址和端口等）被正确改写后，客户相信 它们连接一个IP地址，而不同IP地址的服务器组也认为它们是与客户直接相连的。由此，可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址 上的一个虚拟服务(内部网络地址访问Internet 或被Internet访问)
通过IP隧道实现虚拟服务器（VS/TUN）
IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技 术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。
VS/TUN 的工作流程：它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器， 将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发 现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。
根据缺省的TCP/IP协议栈处理，请求报文的目标地址为VIP，响应报文的源地址肯定也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道究竟是哪一台服务器处理的。
直接路由实现虚拟服务器（VS/DR）
VS/DR 的工作流程：它的连接调度和管理与VS/NAT和VS/TUN中的一样，它的报文转发方法又有不同，将报文直接路由给目标服务器。在VS/DR 中，调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后 的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报文。当服务器发现 报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。
在VS/DR中，根据缺省的TCP/IP协议栈处理，请求报文的目标地址为VIP，响应报文的源地址肯定也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。
VS/DR负载调度器跟VS/TUN一样只处于从客户到服务器的半连接中，按照半连接的TCP有限状态机进行状态迁移
三种方法优缺点：
Virtual Server via NAT
优点:运行在任何tcp/ip 系统，服务器可以使用私有ip地址。
缺点：伸缩能力有限，负载调度器本身会成为系统瓶颈，
解决方法：
混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中，有若干个VS/NAT负载调度器，每个负载调度器带自己的服务器集群，同时这些负载调度器又通过RR-DNS组成简 单的域名。但VS/TUN和VS/DR是提高系统吞吐量的更好方法。
NAT模式：
集群节点跟Direcator 必须在同一个IP网络中;
RIP通常是私有地址，仅仅用于个集群之间通信;
director位于Client和real server之间，并负责处理进出的所有通信; realservet必须将网关指向DIP,同时也支持端口影射; Realserver可以使用任意OS; 在较大应用规模当中，单个Director会出现瓶颈; 大概可以带10个左右的SERVER就会出现瓶颈
Virtual Server via IP Tunneling
只会处理大量请求，不会成为系统瓶颈，极大增加负载调度器调度的服务器数量。
要求：服务器支持“IP tunneling”或“IP encapsulation”
Virtual Server via Direct Routing
VS/DR调度器只处理客户到服务器端的连接，响应数据可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。
跟VS/TUN相比，这种方法没有IP隧道的开销，但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上
工作模式：
NAT和TUN种模式基本上都是工作在网络层上(三层)，直接路由模式则应该是工作在数据链路
原理 ：DR和REALSERVER都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有REALSERVER对本身这个IP的ARP请求保持静 默，网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的REALSERVER,把目的MAC地址改为 REALSERVER的MAC并发给这台REALSERVER，REALSERVER收到这个数据包,则等于直接从客户端收到这个数据包无异,处理后 直接返回给客户端。DR要对二层包头进行改换,所以DR和REALSERVER之间必须在一个广播域
4，持久连接
参考博客：
持久连接是指无论使用什么算法，LVS持久都能实现在一定时间内，将来自同一个客户端请求派发至此前选定的RS。
当使用LVS持久性的时候，Director在内部使用一个连接根据记录称之为“持久连接模板”来确保所有来自同一个客户端的请求被分发到同一台Real Server上。
说明：持久连接模板是指每一个客户端 及分配给它的RS的映射关系；
1）PPC（Persistent Port Connections）将来自于同一个客户端对同一个集群服务的请求，始终定向至此前选定的RS；（持久端口连接）
client---->LVS(80)---->RS1 或 client---->LVS(23)---->RS2
缺陷：期望访问不同的端口到同一台RS上，无法实现。
配置：
ipvsadm -A -t 172.16.100.1:80 -s rr -p 3600
ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.10 -g -w 2
ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.11 -g -w 2
2）PCC（Persistent Client Connections）：将来自于同一个客户端对所有端口的请求，始终定向至此前选定的RS；（持久客户端连接）
说明：PCC是一个虚拟服务没有端口号（或者端口号为0），以"-p" 来标识服务。
缺陷：定向所有服务，期望访问不同的Real Server无法实现。
配置：
ipvsadm -A -t 172.16.100.1:0 -s rr -p 3600
ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.10 -g -w 2
ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.11 -g -w 2
3）PNMPP（Persistent Netfilter Marked Packet Persistence）：持久防火墙标记连接，根据iptables 的规则，将对于某类服务几个不同端口的访问定义为一类。
先对某一特定类型的数据包打上标记，然后再将基于某一类标记的服务送到后台的Real Server上去，后台的Real Server 并不识别这些标记。将持久和防火墙标记结合起来就能够实现端口姻亲功能，只要是来自某一客户端的对某一特定服务（需要不同的端口）的访问都定义到同一台 Real Server上去。
案例：一个用户在访问购物网站时同时使用HTTP（80）和HTTPS（443）两种协议，我们需要将其定义到同一台Real Server上，而其他的服务不受限制。
配置：
iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 80 -j MARK --set-mark 8
iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 443 -j MARK --set-mark 8
ipvsadm -A -f 8 -s rr -p 600
ipvsadm -a -f 8 -r 172.16.100.10 -g -w 2
ipvsadm -a -f 8 -r 172.16.100.11 -g -w 1
三，知识点
1,考察点
lvs-nat 与lvs-fullnat ：请求和响应报文都经由Director
lvs-nat ：RIP 的网关要指向DIP
lvs-fullnat ：RIP 和DIP 未必在同一IP 网络，但要能通信
lvs-dr 与lvs-tun ：请求报文要经由Director，但响应报文由RS直接发往Client
lvs-dr ：通过封装新的MAC 首部实现，通过MAC 网络转发
lvs-tun ：通过在原IP 报文外封装新IP头实现转发，支持远距离通信
lvs-nat ：修改请求报文的目标IP, 多目标IP的DNAT（目标地址转换）
lvs-dr ：操纵封装新的MAC地址 lvs-tun ：在原请求IP报文之外新加一个IP首部
lvs-fullnat ：修改请求报文的源和目标IP
lvs-nat
1）RIP 和DIP可以在也可以不在同一个IP网络，且应该使用私网地址，RS的网关要指向DIP
2）请求报文和响应报文都必须经由Director 转发，Director易于成为系统瓶颈
3）支持端口映射，可修改请求报文的目标PORT
4）VS 必须是Linux系统，RS可以是任意OS
5）nat工作模式的Director有两个ip是vip和dip，vip用户客户端通信提供服务，dip用于真实服务器通信。
lvs-tun
转发方式： 不修改请求报文的IP首部（源IP为CIP，目标IP为VIP），而在源IP报文之外再封装一个IP首部（源IP是DIP，目标IP是RIP），将报文发往挑选出的目标RS ，RS直接响应给客户端（源IP是VIP ，目标IP是CIP）
1）DIP, VIP, RIP 都应该是公网地址
2）RS的网关不能也不可能指向DIP
3）请求报文要经由Director ，但响应不能经由Director
4）不支持端口映射
5）RS的OS须支持隧道功能
lvs-dr
lvs-dr
注意： Director和各RS都配置有VIP
1）确保前端路由器将目标IP 为VIP 的请求报文发往Director
在前端网关做静态绑定VIP 和Director的MAC 地址
在RS上使用arptables工具
arptables -A IN -d $VIP -j DROP
arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
在RS上修改内核参数以限制arp通告及应答级别
arp_announce
arp_ignore
2）RS的RIP可以使用私网地址，也可以是公网地址，RIP与DIP在同一IP网络，RIP的网关不能指向DIP，以确保响应报文不会经由Director
3）RS和Director要在同一个物理网络
4）请求报文要经由Director，但响应报文不经由Director，而由RS直接发往Client
5）不支持端口映射（端口不能修败）
6）RS可使用大多数OS
负载均衡实现：
负载均衡集群设计时要注意的问题
(1)是否需要会话保持
(2)是否需要共享存储
共享存储：NAS，SAN，DS （分布式存储）
数据同步：
lvs-nat：
设计要点：
(1) RIP 与DIP 在同一IP 网络, RIP 的网关要指向DIP
(2) 支持端口映射
(3) Director要打开核心转发功能
lvs-dr：
dr模型中，各主机上均需要配置VIP，解决地址冲突的方式有三种：
(1)在前端网关做静态绑定
(2)在各RS 使用arptables
(3)在各RS 修改内核参数，来限制arp响应和通告的级别
三种方法中只有第三种方法修改RS的内核参数最实用
限制响应级别：arp_ignore
0：默认值，表示可使用本地任意接口上配置的任意地址进行响应
1: 仅在请求的目标IP 配置在本地主机的接收到请求报文的接口上时，才给予响应
限制通告级别：arp_announce
0 ：默认值，把本机所有接口的所有信息向每个接口的网络进行通告
1 ：尽量避免将接口信息向非直接连接网络进行通告
2 ：必须避免将接口信息向非本网络进行通告
实现LVS-DR的配置脚本（未测试） RS 的预配置脚本 #!/bin/bash vip=192.168.0.100 mask='255.255.255.255‘ dev=lo:1 case $1 in start) echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce ifconfig $dev $vip netmask $mask broadcast $vip up route add -host $vip dev $dev ;; stop) ifconfig $dev down echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce ;; *) echo "Usage: $(basename $0) start|stop" exit 1 ;; esac VS的配置脚本 #!/bin/bash vip='192.168.0.100' iface='eth0:1' mask='255.255.255.255' port='80' rs1='192.168.0.101' rs2='192.168.0.102' scheduler='wrr' type='-g' case $1 in start) ifconfig $iface $vip netmask $mask broadcast $vip up iptables -F ipvsadm -A -t ${vip}:${port} -s $scheduler ipvsadm -a -t ${vip}:${port} -r ${rs1} $type -w 1 ipvsadm -a -t ${vip}:${port} -r ${rs2} $type -w 1 ;; stop) ipvsadm -C ifconfig $iface down ;; *) echo "Usage $(basename $0) start|stop“;exit 1 ;; esac
2，安装
是否支持ipvs
modprobe -l | grep ipvs 或 lsmod | grep ipvs
安装
yum -y install ipvsadm
命令
ipvs -A -t|u|f service-address [-s scheduler]
-t: TCP协议的集群 -u: UDP协议的集群 service-address: IP:PORT -f: FWM: 防火墙标记 service-address: Mark Number
例： ipvsadm -A -t 172.16.1.253:80 -s wlc
修改集群
ipvs -E -t|u|f service-address [-s scheduler]
例：ipvsadm -E -t 172.16.1.253:80 -s wrr
删除集群：
ipvsadm -D -t|u|f service-address
例： ipvsadm -D -t 172.16.1.253:80
管理集群中RealServer
添加RS :ipvsadm -a -t|u|f service-address -r server-address [-g|i|m] [-w weight]
-t|u|f service-address：事先定义好的某集群服务 -r server-address: 某RS的地址，在NAT模型中，可使用IP：PORT实现端口映射；
[ -g|i|m] LVS类型-g: DR -i: TUN -m: NAT
[ -w weight] 定义服务器权例：
[root@lvs ~]# ipvsadm -a -t 172.16.1.253:80 -r 172.16.1.101 –g -w 5
[root@lvs ~]# ipvsadm -a -t 172.16.1.253:80 -r 172.16.1.102 –g -w 10
修改RS：
ipvsadm -e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
例：
ipvsadm -e -t 172.16.1.253:80 -r 172.16.1.101 –g -w 3
删除：
ipvsadm -d -t|u|f service-address -r server-address
例：
ipvsadm -d -t 172.16.1.253:80 -r 172.16.1.101
查看： ipvsadm -L|l [options]
-n: 数字格式显示主机地址和端口 --stats：统计数据 --rate: 速率 --timeout: 显示tcp、tcpfin和udp的会话超时时长 -c: 显示当前的ipvs连接状况
删除所有集群服务： ipvsadm -C
保存规则至默认配置文件：service ipvsadm save
至指定文件：ipvsadm -S > /path/to/somefile
载入保存的文件： ipvsadm -R < /path/form/somefile
注意项：
关于时间同步：各节点间的时间偏差不大于1s，建议使用统一的ntp服务器进行更新时间
DR模型中的VIP的MAC广播问题：
在DR模型中，由于每个节点均要配置VIP，因此存在VIP的MAC广播问题，在现在的linux内核中，都提供了相应kernel 参数对MAC广播进行管理，具体如下：
arp_ignore: 定义接收到ARP请求时的响应级别；
0：只要本地配置的有相应地址，就给予响应；
1：仅在请求的目标地址配置在到达的接口上的时候，才给予响应；DR模型使用
arp_announce：定义将自己地址向外通告时的通告级别；
0：将本地任何接口上的任何地址向外通告；
1：试图仅向目标网络通告与其网络匹配的地址；
2：仅向与本地接口上地址匹配的网络进行通告；DR模型使用
四，配置测试
1,LVS-NAT
DS配置:
VIP: 172.22.144.164
DIP: 192.168.36.74
1，开启路由转发功能，清除所有的iptables限制
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
2,配置ipvsadm
ipvsadm -A -t 172.22.144.164:80 -s rr
ipvsadm -a -t 172.22.144.164:80 -r 192.168.36.72 -m
ipvsadm -a -t 172.22.144.164:80 -r 192.168.36.73 -m
# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.22.144.164:80 rr
-> 192.168.36.72:80 Masq 1 0 0
-> 192.168.36.73:80 Masq 1 0 0
RS配置：
RIP1:192.168.36.72
RIP2:192.168.36.73
1,配置RS的网关指向DS的DIP
[root@test73 ~] $ route -n
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.36.74 0.0.0.0 UG 100 0 0 eth1
2，配置httpd,并生成网页
测试（一定要检测是否iptables限制了访问）：
[root@74 ~] $ curl http://172.22.144.164/index.html
test72.example.com
[root@74 ~] $ curl http://172.22.144.164/index.html
test73.example.com
操，复制过来乱码了