1. 环境描述：本文在配置LVS时使用三台linux (Centos)，一台做Directorserver(192.168.200.72) ,两台做 realserver(192.168.200.70 , 192.168.200.71) ,对外虚拟VIP:192.168.200.73 

2.  软件列表：2.6内核已经集成IPVS内核补订了，所以不再需要重新编译内核.

3.  DS安装lvs的管理软件 ipvsadm 

              利用centos的yum命令， 能自动的从他的镜像网站搜索软件，下载并安装。

              yum install ipvsadm

              Setting up Install Process

Setting up repositories

update                    100% |=========================|  951 B    00:00    

base                      100% |=========================| 1.1 kB    00:00     

addons                    100% |=========================|  951 B    00:00    

extras                    100% |=========================| 1.1 kB    00:00    

Reading repository metadata in from local files

Parsing package install arguments

Resolving Dependencies

--> Populating transaction set with selected packages. Please wait.

---> Downloading header for ipvsadm to pack into transaction set.

ipvsadm-1.24-6.i386.rpm   100% |=========================| 5.8 kB    00:00    

---> Package ipvsadm.i386 0:1.24-6 set to be updated

--> Running transaction check

Dependencies Resolved

=============================================================================

 Package                 Arch       Version          Repository        Size

=============================================================================

Installing:

 ipvsadm                 i386       1.24-6           extras             30 k

Transaction Summary

=============================================================================

Install      1 Package(s)        

Update       0 Package(s)        

Remove       0 Package(s)        

Total download size: 30 k

Is this ok [y/N]: y  选择 Y

Downloading Packages:

(1/1): ipvsadm-1.24-6.i38 100% |=========================|  30 kB    00:01    

Running Transaction Test

Finished Transaction Test

Transaction Test Succeeded

Running Transaction

  Installing: ipvsadm                      ######################### [1/1]

Installed: ipvsadm.i386 0:1.24-6

4           前端调度器 在 DR 模式下的配置脚本

              #/bin/sh

#file: config_vs.sh 这里默认使用网卡eth0,如果想用其它网卡请自行替换即可。

VIP=192.168.200.73   #DR的虚拟服务IP

DIP=192.168.200.72   #DR的eth0真实地址

RS1=192.168.200.71   #real server1的真实地址

RS2=192.168.200.70   #real server2的真实地址

GW=192.168.200.1    #DR使用的网关或路由的地址

SERVICE=80            #web服务的端口

SERVICE_UDP= 800    #UDP 服务程序的端口

cat /proc/sys/net/ipv4/ip_forward   #脚本调试信息

echo "1" >/proc/sys/net/ipv4/ip_forward

echo "1" >/proc/sys/net/ipv4/conf/all/send_redirects   

cat /proc/sys/net/ipv4/conf/all/send_redirects        #脚本调试信息

echo "1" >/proc/sys/net/ipv4/conf/default/send_redirects

cat /proc/sys/net/ipv4/conf/default/send_redirects     #脚本调试信息

echo "1" >/proc/sys/net/ipv4/conf/eth0/send_redirects

cat /proc/sys/net/ipv4/conf/eth0/send_redirects       #脚本调试信息

/sbin/ifconfig eth0 ${DIP}     #配置所使用的网卡IP

#配置虚拟服务IP

/sbin/ifconfig eth0:0 ${VIP} broadcast ${VIP} netmask 255.255.255.255

/sbin/route add -host ${VIP} dev eth0:0   #添加虚拟IP的路由

/sbin/route add default gw ${GW}       #添加本地路由

/sbin/ifconfig eth0:0                  #脚本调试信息, 显示虚拟IP配置

#/bin/ping -b ${VIP}                 #脚本调试信息, 看看虚拟IP是否可以ping通

/sbin/route -n                        #脚本调试信息,显示路由信息

/sbin/ipvsadm –C                    #清除虚拟服务器表,也就是清除IPVS的原配置

#添加服务及轮调调度算法,-t:tcp服务,-A:添加服务; -s rr:指定调度算法为轮调

/sbin/ipvsadm -A -t ${VIP}:${SERVICE} -s rr  -p 600

#添加real server, -a:添加一台RS, -t:tcp服务,-r: RS的地址,-g:直接路由模式。

#这里语句个数随real server的个数而定

/sbin/ipvsadm -a -t ${VIP}:${SERVICE} -r ${RS1} -g

/sbin/ipvsadm -a -t ${VIP}:${SERVICE} -r ${RS2} –g

/sbin/ipvsadm -A –u  ${VIP}:${ SERVICE_UDP } -s rr  –p 600

/sbin/ipvsadm -a –u  ${VIP}:${ SERVICE_UDP } -r ${RS1} -g

/sbin/ipvsadm -a –u   ${VIP}:${ SERVICE_UDP } -r ${RS2} –g

ping -c 1 ${RS1}    #脚本调试信息

ping -c 1 ${RS2}    #脚本调试信息

/sbin/ipvsadm       #脚本调试信息

#end of config_vs.sh

5           后台节点 在 DR 模式下的配置脚本

                      #/bin/sh

#file: config_rs.sh这里默认使用网卡eth0,如果想用其它网卡请自行替换即可。

VIP=192.168.200.73       #DR的虚拟服务IP

#DR的eth0真实地址，作用是在配置时测试DR的IP是否有效。但是DR切换后，DIP变了，所以这项取消了。

LOCALIP=192.168.200.71  #real server1的真实地址

GW=192.168.200.1         #real server使用的网关或路由的地址

/sbin/ifconfig eth0 ${LOCALIP} #配置eth0的本地IP

/sbin/route add default gw ${GW} #添加默认路由

/bin/netstat -rn #脚本调试信息

ping -c 1 ${GW} #脚本调试信息,是否可以ping通网关

echo "0" >/proc/sys/net/ipv4/ip_forward

cat /proc/sys/net/ipv4/ip_forward #脚本调试信息,ip_forward是否配置正确

ping -c 1 ${DIP} #脚本调试信息, 是否可以ping通DR的真实地址

ping –c 1 ${VIP} #是否可以ping通虚拟DR的IP

#按照real server的虚拟IP

/sbin/ifconfig lo:0 ${VIP} broadcast ${VIP} netmask 0xffffffff up

#配置出口

/sbin/ifconfig lo:0

#在lo:0上添加去虚拟IP的路由

/sbin/route add -host ${VIP} dev lo:0

/bin/netstat -rn #脚本调试信息

#使realserver不响应arp请求，

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 
sysctl -p

#end of config_rs.sh

6   测试：分别启动realserver上的httpd服务
在realserver1 执行  echo "This is realserver1"  /var/www/html/index.html
在realserver2 执行  echo "This is realserver2"  /var/www/html/index.html

打开IE浏览器输入http://192.168.200.73 应该可以分别看到:This is realserver1 和 This is realserver1.

　　负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

　　负载均衡有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。

　　本文所要介绍的负载均衡技术主要是指在均衡服务器群中所有服务器和应用程序之间流量负载的应用，目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。

负载均衡技术分类

　　目前有许多不同的负载均衡技术用以满足不同的应用需求，下面从负载均衡所采用的设备对象、应用的网络层次（指OSI参考模型）及应用的地理结构等来分类。

软/硬件负载均衡
　 　软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。

　　软件解决方案 缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为 服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。

　　硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

　　负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。

　　一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。

本地/全局负载均衡
　 　负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance，也叫地域负载均衡)，本地负载均衡是指对本地的服务器群做负载均衡，全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务 器群间作负载均衡。

　　本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题，并且不需花费昂贵开支购置性能卓越的服务器，充分利用 现有设备，避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充 升级，也只是简单地增加一个新的服务器到服务群中，而不需改变现有网络结构、停止现有的服务。

　　全局负载均衡主要用于在一个多区域拥有自己服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度，也可用于子公司分散站点分布广的大公司通过Intranet（企业内部互联网）来达到资源统一合理分配的目的。

　　全局负载均衡有以下的特点：

实现地理位置无关性，能够远距离为用户提供完全的透明服务。
除了能避免服务器、数据中心等的单点失效，也能避免由于ISP专线故障引起的单点失效。
解决网络拥塞问题，提高服务器响应速度，服务就近提供，达到更好的访问质量。
网络层次上的负载均衡
　　针对网络上负载过重的不同瓶颈所在，从网络的不同层次入手，我们可以采用相应的负载均衡技术来解决现有问题。

　　随着带宽增加，数据流量不断增大，网络核心部分的数据接口将面临瓶颈问题，原有的单一线路将很难满足需求，而且线路的升级又过于昂贵甚至难以实现，这时就可以考虑采用链路聚合（Trunking）技术。

　　链路聚合技术（第二层负载均衡）将多条物理链路当作一条单一的聚合逻辑链路使用，网络数据流量由聚合逻辑链路中所有物理链路共同承担，由此在逻辑上增大了链路的容量，使其能满足带宽增加的需求。

　 　现代负载均衡技术通常操作于网络的第四层或第七层。第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址，对每次 TCP连接请求动态使用其中一个内部IP地址，达到负载均衡的目的。在第四层交换机中，此种均衡技术得到广泛的应用，一个目标地址是服务器群VIP（虚拟 IP，Virtual IP address）连接请求的数据包流经交换机，交换机根据源端和目的IP地址、TCP或UDP端口号和一定的负载均衡策略，在服务器IP和VIP间进行映 射，选取服务器群中最好的服务器来处理连接请求。

　　第七层负载均衡控制应用层服务的内容，提供了一种对访问流量的高层控制方式，适合对HTTP服务器群的应用。第七层负载均衡技术通过检查流经的HTTP报头，根据报头内的信息来执行负载均衡任务。

　　第七层负载均衡优点表现在如下几个方面：

通过对HTTP报头的检查，可以检测出HTTP400、500和600系列的错误信息，因而能透明地将连接请求重新定向到另一台服务器，避免应用层故障。
可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等），把数据流量引向相应内容的服务器来处理，增加系统性能。
能根据连接请求的类型，如是普通文本、图象等静态文档请求，还是asp、cgi等的动态文档请求，把相应的请求引向相应的服务器来处理，提高系统的性能及安全性。
　　第七层负载均衡受到其所支持的协议限制（一般只有HTTP），这样就限制了它应用的广泛性，并且检查HTTP报头会占用大量的系统资源，势必会影响到系统的性能，在大量连接请求的情况下，负载均衡设备自身容易成为网络整体性能的瓶颈。

负载均衡策略

　 　在实际应用中，我们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器，而不管服务器是否宕机。而是想使Pentium III服务器比Pentium II能接受更多的服务请求，一台处理服务请求较少的服务器能分配到更多的服务请求，出现故障的服务器将不再接受服务请求直至故障恢复等等。

　　选择合适的负载均衡策略，使多个设备能很好的共同完成任务，消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中，针对不同的应用需求，在OSI参考模型的第二、三、四、七层的负载均衡都有相应的负载均衡策略。

　　负载均衡策略的优劣及其实现的难易程度有两个关键因素：一、负载均衡算法，二、对网络系统状况的检测方式和能力。

　　考虑到服务请求的不同类型、服务器的不同处理能力以及随机选择造成的负载分配不均匀等问题，为了更加合理的把负载分配给内部的多个服务器，就需要应用相应的能够正确反映各个服务器处理能力及网络状态的负载均衡算法：

轮循均衡（Round Robin）：每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

权 重轮循均衡（Weighted Round Robin）：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是 3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的 服务器负载过重。

随机均衡（Random）：把来自网络的请求随机分配给内部中的多个服务器。

权重随机均衡（Weighted Random）：此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

响 应速度均衡（Response Time）：负载均衡设备对内部各服务器发出一个探测请求（例如Ping），然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客 户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务 器间的最快响应时间。

最少连接数均衡（Least Connection）：客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服 务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器 正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理 的请求服务，如FTP。

处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大 小及当前连接数等换算而成）最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七 层（应用层）负载均衡的情况下。

DNS响应均衡（Flash DNS）：在Internet上，无论是HTTP、FTP或是其它的服务请求，客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法 下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的IP地址（即与此负载均衡设备在 同一位地理位置的服务器的IP地址）并返回给客户端，则客户端将以最先收到的域名解析IP地址来继续请求服务，而忽略其它的IP地址响应。在种均衡策略适 合应用在全局负载均衡的情况下，对本地负载均衡是没有意义的。

尽管有多种的负载均衡算法可以较好的把数据流量分配给服务器去负载，但如 果负载均衡策略没有对网络系统状况的检测方式和能力，一旦在某台服务器或某段负载均衡设备与服务器网络间出现故障的情况下，负载均衡设备依然把一部分数据 流量引向那台服务器，这势必造成大量的服务请求被丢失，达不到不间断可用性的要求。所以良好的负载均衡策略应有对网络故障、服务器系统故障、应用服务故障 的检测方式和能力：

Ping侦测：通过ping的方式检测服务器及网络系统状况，此种方式简单快速，但只能大致检测出网络及服务器上的操作系统是否正常，对服务器上的应用服务检测就无能为力了。

TCP Open侦测：每个服务都会开放某个通过TCP连接，检测服务器上某个TCP端口（如Telnet的23口，HTTP的80口等）是否开放来判断服务是否正常。

HTTP URL侦测：比如向HTTP服务器发出一个对main.html文件的访问请求，如果收到错误信息，则认为服务器出现故障。
　 　负载均衡策略的优劣除受上面所讲的两个因素影响外，在有些应用情况下，我们需要将来自同一客户端的所有请求都分配给同一台服务器去负担，例如服务器将客 户端注册、购物等服务请求信息保存的本地数据库的情况下，把客户端的子请求分配给同一台服务器来处理就显的至关重要了。有两种方式可以解决此问题，一是根 据IP地址把来自同一客户端的多次请求分配给同一台服务器处理，客户端IP地址与服务器的对应信息是保存在负载均衡设备上的；二是在客户端浏览器 cookie内做独一无二的标识来把多次请求分配给同一台服务器处理，适合通过代理服务器上网的客户端。

　　还有一种路径外返回模式 （Out of Path Return），当客户端连接请求发送给负载均衡设备的时候，中心负载均衡设备将请求引向某个服务器，服务器的回应请求不再返回给中心负载均衡设备，即绕 过流量分配器，直接返回给客户端，因此中心负载均衡设备只负责接受并转发请求，其网络负担就减少了很多，并且给客户端提供了更快的响应时间。此种模式一般 用于HTTP服务器群，在各服务器上要安装一块虚拟网络适配器，并将其IP地址设为服务器群的VIP，这样才能在服务器直接回应客户端请求时顺利的达成三 次握手。



负载均衡实施要素

　　负载均衡方案应是在网站建设初期就应考虑的问题，不过有时随着访问流量 的爆炸性增长，超出决策者的意料，这也就成为不得不面对的问题。当我们在引入某种负载均衡方案乃至具体实施时，像其他的许多方案一样，首先是确定当前及将 来的应用需求，然后在代价与收效之间做出权衡。

　　针对当前及将来的应用需求，分析网络瓶颈的不同所在，我们就需要确立是采用哪一类的负载均衡技术，采用什么样的均衡策略，在可用性、兼容性、安全性等等方面要满足多大的需求，如此等等。

　　不管负载均衡方案是采用花费较少的软件方式，还是购买代价高昂在性能功能上更强的第四层交换机、负载均衡器等硬件方式来实现，亦或其他种类不同的均衡技术，下面这几项都是我们在引入均衡方案时可能要考虑的问题：

性 能：性能是我们在引入均衡方案时需要重点考虑的问题，但也是一个最难把握的问题。衡量性能时可将每秒钟通过网络的数据包数目做为一个参数，另一个参数是均 衡方案中服务器群所能处理的最大并发连接数目，但是，假设一个均衡系统能处理百万计的并发连接数，可是却只能以每秒2个包的速率转发，这显然是没有任何作 用的。 性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关，并且有两点需要注意：一、均衡方案对服务器群整体的性能，这是响应客户端连接请求速度的关 键；二、负载均衡设备自身的性能，避免有大量连接请求时自身性能不足而成为服务瓶颈。 有时我们也可以考虑采用混合型负载均衡策略来提升服务器群的总体性能，如DNS负载均衡与NAT负载均衡相结合。另外，针对有大量静态文档请求的站点，也 可以考虑采用高速缓存技术，相对来说更节省费用，更能提高响应性能；对有大量ssl/xml内容传输的站点，更应考虑采用ssl/xml加速技术。


可 扩展性：IT技术日新月异，一年以前最新的产品，现在或许已是网络中性能最低的产品；业务量的急速上升，一年前的网络，现在需要新一轮的扩展。合适的均衡 解决方案应能满足这些需求，能均衡不同操作系统和硬件平台之间的负载，能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不同服务器的负载，并且能以对客户端完全透明的方式动态增加或删除某些资源。


灵活性：均衡解决方案应能灵活地提供不同的应用需求，满足应用需求的不断变化。在不同的服务器群有不同的应用需求时，应有多样的均衡策略提供更广泛的选择。


可 靠性：在对服务质量要求较高的站点，负载均衡解决方案应能为服务器群提供完全的容错性和高可用性。但在负载均衡设备自身出现故障时，应该有良好的冗余解决 方案，提高可靠性。使用冗余时，处于同一个冗余单元的多个负载均衡设备必须具有有效的方式以便互相进行监控，保护系统尽可能地避免遭受到重大故障的损失。


易管理性：不管是通过软件还是硬件方式的均衡解决方案，我们都希望它有灵活、直观和安全的管理方式，这样便于安装、配置、维护和 监控，提高工作效率，避免差错。在硬件负载均衡设备上，目前主要有三种管理方式可供选择：一、命令行接口（CLI：Command Line Interface），可通过超级终端连接负载均衡设备串行接口来管理，也能telnet远程登录管理，在初始化配置时，往往要用到前者；二、图形用户接 口（GUI：Graphical User Interfaces），有基于普通web页的管理，也有通过Java Applet 进行安全管理，一般都需要管理端安装有某个版本的浏览器；三、SNMP（Simple Network Management Protocol，简单网络管理协议）支持，通过第三方网络管理软件对符合SNMP标准的设备进行管理。
负载均衡配置实例

DNS负载均衡
　 　DNS负载均衡技术是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地 址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。

　　DNS负载均衡的优点是经济简单易行，并且服务器可以位于internet上任意的位置。但它也存在不少缺点：

为了使本DNS服务器和其他DNS服务器及时交互，保证DNS数据及时更新，使地址能随机分配，一般都要将DNS的刷新时间设置的较小，但太小将会使DNS流量大增造成额外的网络问题。


一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间（刷新时间）才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器。


DNS负载均衡采用的是简单的轮循负载算法，不能区分服务器的差异，不能反映服务器的当前运行状态，不能做到为性能较好的服务器多分配请求，甚至会出现客户请求集中在某一台服务器上的情况。


要给每台服务器分配一个internet上的IP地址，这势必会占用过多的IP地址。
　 　判断一个站点是否采用了DNS负载均衡的最简单方式就是连续的ping这个域名，如果多次解析返回的IP地址不相同的话，那么这个站点就很可能采用的就 是较为普遍的DNS负载均衡。但也不一定，因为如果采用的是DNS响应均衡，多次解析返回的IP地址也可能会不相同。不妨试试Ping一下 www.yesky.com，www.sohu.com，www.yahoo.com

　　现假设有三台服务器来应对www.test.com的请求。在采用BIND 8.x DNS服务器的unix系统上实现起来比较简单，只需在该域的数据记录中添加类似下面的结果：

　　www1 IN A 192.1.1.1
　　www2 IN A 192.1.1.2
　　www3 IN A 192.1.1.3
　　www IN CNAME www1
　　www IN CNAME www2
　　www IN CNAME www3

　　在NT下的实现也很简单，下面详细介绍在win2000 server下实现DNS负载均衡的过程，NT4.0类似：

打开“管理工具”下的“DNS”，进入DNS服务配置控制台。


打 开相应DNS 服务器的“属性”，在“高级”选项卡的“服务器选项”中，选中“启用循环”复选框。此步相当于在注册表记录HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\DNS\Parameters中添加一个双字节制值（dword值） RoundRobin，值为1。


打开正向搜索区域的相应区域（如test.com），新建主机添加主机 (A) 资源记录，记录如下：

www IN A 192.1.1.1
www IN A 192.1.1.2
www IN A 192.1.1.3

在这里可以看到的区别是在NT下一个主机名对应多个IP地址记录，但在unix下，是先添加多个不同的主机名分别对应个自的IP地址，然后再把这些主机赋同一个别名（CNAME）来实现的。

在此需要注意的是，NT下本地子网优先级会取代多宿主名称的循环复用，所以在测试时，如果做测试用的客户机IP地址与主机资源记录的IP在同一有类掩码范围内，就需要清除在“高级”选项卡“服务器选项”中的“启用netmask排序”。
NAT负载均衡
　 　NAT（Network Address Translation 网络地址转换）简单地说就是将一个IP地址转换为另一个IP地址，一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。每次NAT转换势必会增加NAT设备的开销，但这种额外的开销对于大多数网络来说都是微不足道 的，除非在高带宽有大量NAT请求的网络上。

　　NAT负载均衡将一个外部IP地址映射为多个内部IP地址，对每次连接请求动态地转换为一个内部服务器的地址，将外部连接请求引到转换得到地址的那个服务器上，从而达到负载均衡的目的。

　　NAT负载均衡是一种比较完善的负载均衡技术，起着NAT负载均衡功能的设备一般处于内部服务器到外部网间的网关位置，如路由器、防火墙、四层交换机、专用负载均衡器等，均衡算法也较灵活，如随机选择、最少连接数及响应时间等来分配负载。

　 　NAT负载均衡可以通过软硬件方式来实现。通过软件方式来实现NAT负载均衡的设备往往受到带宽及系统本身处理能力的限制，由于NAT比较接近网络的低 层，因此就可以将它集成在硬件设备中，通常这样的硬件设备是第四层交换机和专用负载均衡器，第四层交换机的一项重要功能就是NAT负载均衡。

　　下面以实例介绍一下Cisco路由器NAT负载均衡的配置：

　 　现有一台有一个串行接口和一个Ethernet接口的路由器，Ethernet口连接到内部网络，内部网络上有三台web服务器，但都只是低端配置，为 了处理好来自Internet上大量的web连接请求，因此需要在此路由器上做NAT负载均衡配置，把发送到web服务器合法Internet IP地址的报文转换成这三台服务器的内部本地地址。 其具体配置过程如下：

做好路由器的基本配置，并定义各个接口在做NAT时是内部还是外部接口。

然后定义一个标准访问列表（standard access list），用来标识要转换的合法IP地址。

再定义NAT地址池来标识内部web服务器的本地地址，注意要用到关键字rotary，表明我们要使用轮循（Round Robin）的方式从NAT地址池中取出相应IP地址来转换合法IP报文。


最后，把目标地址为访问表中IP的报文转换成地址池中定义的IP地址。
　　相应配置文件如下：

interface Ethernet0/0
ip address 192.168.1.4 255.255.255.248
ip nat inside
!
interface Serial0/0
ip address 200.200.1.1 255.255.255.248
ip nat outside
!
ip access-list 1 permit 200.200.1.2
!
ip nat pool websrv 192.168.1.1 192.168.1.3 netmask 255.255.255.248 type rotary
ip nat inside destination list 1 pool websrv





反向代理负载均衡
　　普通代理方式是代理内部网络用户访问internet上服务器的连接请求，客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。

　　反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

　　反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。

　 　反向代理负载均衡能以软件方式来实现，如apache mod_proxy、netscape proxy等，也可以在高速缓存器、负载均衡器等硬件设备上实现。 反向代理负载均衡可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起，提升静态网页的访问速度，提供有益的性能；由于网络外部用户不能直接访 问真实的服务器，具备额外的安全性（同理，NAT负载均衡技术也有此优点）。

　　其缺点主要表现在以下两个方面：

反向代理是处于OSI参考模型第七层应用的，所以就必须为每一种应用服务专门开发一个反向代理服务器，这样就限制了反向代理负载均衡技术的应用范围，现在一般都用于对web服务器的负载均衡。

针对每一次代理，代理服务器就必须打开两个连接，一个对外，一个对内，因此在并发连接请求数量非常大的时候，代理服务器的负载也就非常大了，在最后代理服务器本身会成为服务的瓶颈。
　　一般来讲，可以用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，如search。

　 　下面以在apache mod_proxy下做的反向代理负载均衡为配置实例：在站点www.test.com，我们按提供的内容进行分类，不同的服务器用于提供不同的内容服 务，将对http://www.test.com/news的访问转到IP地址为192.168.1.1的内部服务器上处理，对http: //www.test.com/it的访问转到服务器192.168.1.2上，对http://www.test.com/life的访问转到服务器 192.168.1.3上，对http://www.test.com/love的访问转到合作站点http://www.love.com上，从而减轻 本apache服务器的负担，达到负载均衡的目的。

　　首先要确定域名www.test.com在DNS上的记录对应apache服务器接口上具有internet合法注册的IP地址，这样才能使internet上对www.test.com的所有连接请求发送给本台apache服务器。

　　在本台服务器的apache配置文件httpd.conf中添加如下设置：

　　proxypass /news http://192.168.1.1
　　proxypass /it http://192.168.1.2
　　proxypass /life http://192.168.1.3
　　proxypass /love http://www.love.com

　　注意，此项设置最好添加在httpd.conf文件“Section 2”以后的位置，服务器192.168.1.1-3也应是具有相应功能的www服务器，在重启服务时，最好用apachectl configtest命令检查一下配置是否有误.


混合型负载均衡
　 　在有些大型网络，由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异，我们可以考虑给每个服务器群采用最合适的负载均衡方式，然后又在这多个 服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务（即把这多个服务器群当做一个新的服务器群），从而达到最佳的性能。我们将这种方式称之为混 合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。

　　下图展示了一个应用示例，三个服务器群针对各自的特点，分别采用了不同的负载均衡方式。当客户端发出域名解析请求时，DNS服务器依次把它解析成三个服务器群的VIP，如此把客户端的连接请求分别引向三个服务器群，从而达到了再一次负载均衡的目的。

　　在图中大家可能注意到，负载均衡设备在网络拓朴上，可以处于外部网和内部网络间网关的位置，也可以和内部服务器群处于并行的位置，甚至可以处于内部网络或internet上的任意位置，特别是在采用群集负载均衡时，根本就没有单独的负载均衡设备。

　　服务器群内各服务器只有提供相同内容的服务才有负载均衡的意义，特别是在DNS负载均衡时。要不然，这样会造成大量连接请求的丢失或由于多次返回内容的不同给客户造成混乱。

　　所以，如图的这个示例在实际中可能没有多大的意义，因为如此大的服务内容相同但各服务器群存在大量差异的网站并不多见。 但做为一个示例，相信还是很有参考意义的.

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=273385

　　提笔注：扫地只是偶的表面工作，偶的真实身份是作MMORPG。^_^

　　之前，我分析过QQ游戏（特指QQ休闲平台，并非QQ堂，下同）的通信架构（http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx），分析过魔兽世界的通信架构（http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx）， 似乎网络游戏的通信架构也就是这些了，其实不然，在网络游戏大家庭中，还有一种类型的游戏我认为有必要把它的通信架构专门作个介绍，这便是如泡泡堂、QQ 堂类的休闲类竞技游戏。曾经很多次，被网友们要求能抽时间看看泡泡堂之类游戏的通信架构，这次由于被逼交作业，所以今晚抽了一点的时间截了一下泡泡堂的 包，正巧昨日与网友就泡泡堂类游戏的通信架构有过一番讨论，于是，将这两天的讨论、截包及思考总结于本文中，希望能对关心或者正在开发此类游戏的朋友有所 帮助，如果要讨论具体的技术细节，请到我的BLOG（http://blog.csdn.net/sodme）加我的MSN讨论..

　　总体来说，泡泡堂类游戏（此下简称泡泡堂）在大厅到房间这一层的通信架构，其结构与QQ游戏相当，甚至要比QQ游戏来得简单。所以，在房间这一层的通信架构上，我不想过多讨论，不清楚的朋友请参看我对QQ游戏通信架构的分析文章（http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx）。可以这么说，如果采用与QQ游戏相同的房间和大厅架构，是完全可以组建起一套可扩展的支持百万人在线的游戏系统的。也就是说，通过负载均衡＋大厅＋游戏房间对游戏逻辑的分摊，完全可以实现一个可扩展的百万人在线泡泡堂。

　　但是，泡泡堂与斗地主的最大不同点在于：泡泡堂对于实时性要求特别高。那么，泡泡堂是如何解决实时性与网络延迟以及大用户量之间矛盾的呢？

　　阅读以下文字前，请确认你已经完全理解TCP与UDP之间的不同点。

　 　我们知道，TCP与UDP之间的最大不同点在于：TCP是可靠连接的，而UDP是无连接的。如果通信双方使用TCP协议，那么他们之前必须事先通过监听 ＋连接的方式将双方的通信管道建立起来；而如果通信双方使用的是UDP通信，则双方不用事先建立连接，发送方只管向目标地址上的目标端口发送UDP包即 可，不用管对方到底收没收到。如果要说形象点，可以用这样一句话概括：TCP是打电话，UDP是发电报。TCP通信，为了保持这样的可靠连接，在可靠性上 下了很多功夫，所以导致了它的通信效率要比UDP差很多，所以，一般地，在地实时性要求非常高的场合，会选择使用UDP协议，比如常见的动作射击类游戏。

　　通过载包，我们发现泡泡堂中同时采用了TCP和UDP两种通信协议。并且，具有以下特点：
　　1.当玩家未进入具体的游戏地图时，仅有TCP通信存在，而没有UDP通信；
　　2.进入游戏地图后，TCP的通信量远远小于UDP的通信量
　　3.UDP的通信IP个数，与房间内的玩家成一一对应关系(这一点，应网友疑惑而加，此前已经证实)

　　以上是几个表面现象，下面我们来分析它的本质和内在。^&^

　　泡泡堂的游戏逻辑，简单地可以归纳为以下几个方面：
　　1.玩家移动
　　2.玩家埋地雷（如果你觉得这种叫法比较土，你也可以叫它：下泡泡，呵呵）
　　3.地雷爆炸出道具或者地雷爆炸困住另一玩家
　　4.玩家捡道具或者玩家消灭/解救一被困的玩家

　　与MMORPG一样，在上面的几个逻辑中，广播量最大的其实是玩家移动。为了保持玩家画面同步，其他玩家的每一步移动消息都要即时地发给其它玩家。

　 　通常，网络游戏的逻辑控制，绝大多数是在服务器端的。有时，为了保证画面的流畅性，我们会有意识地减少服务器端的逻辑判断量和广播量，当然，这个减少， 是以“不危及游戏的安全运行”为前提的。到底如何在效率、流畅性和安全性之间作取舍，很多时候是需要经验积累的，效率提高的过程，就是逻辑不断优化的过 程。不过，有一个原则是可以说的，那就是：“关键逻辑”一定要放在服务器上来判断。那么，什么是“关键逻辑”呢？

　　拿泡泡堂来说，下面的这个逻辑，我认为就是关键逻辑：玩家在某处埋下一颗地雷，地雷爆炸后到底能不能炸出道具以及炸出了哪些道具，这个信息，需要服务器来给。那么，什么又是“非关键逻辑”呢？

　 　“非关键逻辑”，在不同的游戏中，会有不同的概念。在通常的MMORPG中，玩家移动逻辑的判断，是算作关键逻辑的，否则，如果服务器端不对客户端发过 来的移动包进行判断那就很容易造成玩家的瞬移以及其它毁灭性的灾难。而在泡泡堂中，玩家移动逻辑到底应不应该算作关键逻辑还是值得考虑的。泡泡堂中的玩家 可以取胜的方法，通常是确实因为打得好而赢得胜利，不会因为瞬移而赢得胜利，因为如果外挂要作泡泡堂的瞬移，它需要考虑的因素和判断的逻辑太多了，由于比 赛进程的瞬息万变，外挂的瞬移点判断不一定就比真正的玩家来得准确，所在，在玩家移动这个逻辑上使用外挂，在泡泡堂这样的游戏中通常是得不偿失的（当然， 那种特别变态的高智能的外挂除外）。从目前我查到的消息来看，泡泡堂的外挂多数是一些按键精灵脚本，它的本质还不是完全的游戏机器人，并不是通过纯粹的协 议接管实现的外挂功能。这也从反面验证了我以上的想法。

　　说到这里，也许你已经明白了。是的！TCP通信负责“关键逻辑”，而UDP通信 负责“非关键逻辑”，这里的“非关键逻辑”中就包含了玩家移动。在泡泡堂中，TCP通信用于本地玩家与服务器之间的通信，而UDP则用于本地玩家与同一地 图中的其他各玩家的通信。当本地玩家要移动时，它会同时向同一地图内的所有玩家广播自己的移动消息，其他玩家收到这个消息后会更新自己的游戏画面以实现画 面同步。而当本地玩家要在地图上放置一个炸弹时，本地玩家需要将此消息同时通知同一地图内的其他玩家以及服务器，甚至这里，可以不把放置炸弹的消息通知给 服务器，而仅仅通知其他玩家。当炸弹爆炸后，要拾取物品时才向服务器提交拾取物品的消息。

　　那么，你可能会问，“地图上某一点是否存在道具”这个消息，服务器是什么时候通知给客户端的呢？这个问题，可以有两种解决方案：
　　1.客户端如果在放置炸弹时，将放置炸弹的消息通知给服务器，服务器可以在收到这个消息后，告诉客户端炸弹爆炸后会有哪些道具。但我觉得这种方案不好，因为这样作会增加游戏运行过程中的数据流量。
　 　2.而这第2种方案就是，客户端进入地图后，游戏刚开始时，就由服务器将本地图内的各道具所在点的信息传给各客户端，这样，可以省去两方面的开销：a. 客户端放炸弹时，可以不通知服务器而只通知其它玩家；b.服务器也不用在游戏运行过程中再向客户端传递有关某点有道具的信息。
　　
　　但是，不管采用哪种方案，服务器上都应该保留一份本地图内道具所在点的信息。因为服务器要用它来验证一个关键逻辑：玩家拾取道具。当玩家要在某点拾取道具时，服务器必须要判定此点是否有道具，否则，外挂可以通过频繁地发拾取道具的包而不断取得道具。

　 　至于泡泡堂其它游戏逻辑的实现方法，我想，还是要依靠这个原则：首先判断这个逻辑是关键逻辑吗？如果不全是，那其中的哪部分是非关键逻辑呢？对于非关键 逻辑，都可以交由客户端之间（UDP）去自行完成。而对于关键逻辑，则必须要有服务器(TCP)的校验和认证。这便是我要说的。

　　以上仅 仅是在理论上探讨关于泡泡堂类游戏在通信架构上的可能作法，这些想法是没有事实依据的，所有结论皆来源于对封包的分析以及个人经验，文章的内容和观点可能 跟真实的泡泡堂通信架构实现有相当大的差异，但我想，这并不是主要的，因为我的目的是向大家介绍这样的TCP和UDP通信并存情况下，如何对游戏逻辑的进 行取舍和划分。无论是“关键逻辑”的定性，还是“玩家移动”的具体实施，都需要开发者在具体的实践中进行总结和优化。此文全当是一个引子罢，如有疑问，请 加Msn讨论。