下载第 27章 建立多服务器网站本书的绝大部分是围绕着在单一服务器网站上的 Web 应用程序的开发与优化，而多服务器网站的开发与优化同单一服务器上的情形有细微的差别。本章重点研究多服务器网站以及它们的工作方式。
主要讨论以下问题：
多服务器网站的定义，以及何时或者是否应当建立一个多服务器网站。
建立一个 We b阵的各种方法及其优势与不足。
从结构方面考虑实现在多台机器上运行的网络应用程序。
首先让我们看一下一个多服务器网站的构成。
27.1 多服务器网站最典型的网站有一个单一的响应 H T T P请求的网络服务器，这个服务器可能使用 A S P动态地产生 H T T P或者简单地提供静态内容。这个服务器也可能连接到本地或远程的数据库上，图
2 7 - 1就是这种配置。
随着用户数量的增加，性能开始下降。如何解决这个问题。正如在上一章所看到的，典型的做法是，每隔一定时间分析软件的结构，
在各种各样的算法中清理出过于臃肿的内容。
网络服务器也可以通过增加 C P U、额外的 R A M
和更快的硬盘驱动器增强其性能。然而，最终可能无法再通过改进系统的性能使其达到可接受的水平。对于 I n t e r n e t应用程序，这种情况早已出现。改善系统性能的一种显而易见的方式就是通过多网络服务器分散或平衡负载。
即使网站的用户数量不多，对于单个服务器配置，也存在一些其他的潜在问题。每一个
I T经理的一个基本假设就是任何机器都会失败，如果这个失败的机器作为网络服务器，则用户无论如何也不能进入这个网站。对于商业站点来说这将带来许多麻烦。考虑一个在线经纪人例子，如果一个在线经纪人不能被访问，这个在线经纪人的顾客可能在等待网站恢复的时候损失大量的资金。
此外，需要注意的是，维护也是管理生产环境时不可缺少的部分。有一些常规的安全性公告要求应用程序热修补和对系统或系统软件的服务补丁。这可能需要替换硬件。当网站仅有一个服务器时，即使是最一般的改变，也要将整个网站停下来。这将导致数小时的维修以及 I T职员的抱怨。
最后还有一个内容升级的问题。网络应用程序的发展趋向于不断改变网站的内容。在一个独立的服务器上展示新的内容或让内部用户验证网站的正确性是一个极好的方法。这样能避免许多令人烦恼的问题和咨询电话。
图 2 7 - 2展示了多服务器网站的配置。
网络服务器 数据库服务器图 27-1 网络服务器的配置
Internet
请求进入到几个网络服务器中的一个，这个服务器在处理请求的过程中从数据库服务器中读取数据，或者向其中写入数据。如果一台网络服务器出了故障，其他的网络服务器将会处理这些附加的请求。这种配置提供了负载平衡，负载将被分配或平衡到多个网络服务器上。这种配置也提供容错，在容错范围内，任何一部分出现故障将不影响网站的可用性。
此外，网络服务器多于数据库服务器。
通常，一个数据库服务器能够处理由多个网络服务器产生的负载，这样可以不必平衡数据库服务器负载。但是仍然需要防止任何单台机器的故障导致整个网站瘫痪，出于这一目的，要给数据库服务器一个冗余的后备配置。这将意味着将有一台额外的（备用）机器专门用于应付主要机器的故障，这称为故障屏蔽（ f a i l o v e r）配置，其原因是备用机器阻止了失败的现象在用户面前出现。
总而言之，使用 We b阵的优点是：
增强了事务性的吞吐量。
允许大量的用户同时工作。
增加了冗余度（容错） 。
增强了可用性，在例行维护时不用停机。
27.1.1 We b阵的不足在进一步深入研究之前，首先要问自己这样一个问题：增加一个 We b阵是否是一件好事。
当讨论多网络服务器网站的运行优点时，同样也需要讨论它的不足之处。
明显的缺点是增加了系统的复杂性，当请求通过多服务器时，需要某些模式来分配请求给这些服务器。最具有代表性的是需要增加网络硬件或软件组件。这不仅增加了相关的开发和管理工作，而且也增加了测试工作。为了确定系统按希望工作，必须测试系统的冗余、负载平衡和故障屏障等各个方面。
另一个缺点是这种变化可能影响系统结构，将在后面讨论这些问题。状态管理、用户管理和资源管理等模式，移植到多服务器系统时需要进行改变。一种简单的例子是管理上传的文件，如果这些文件当前是放在本地的目录结构中，需要修改系统使其指向中心的共享目录。
最后，当将原来使用一台机器的网站改为使用多台机器时，要增加管理的费用。 I T职员需要对多台机器进行追踪，监控每台机器的配置。内容、代码、热修补、补丁等等必须写入到每台服务器。尽管冗余使得管理能在运行期间执行，但是冗余和容错不能免除管理员的责任。此外，测试环境必须真实地（最大程度地）反映工作环境，也就是要测试更多机器。
总而言之，使用 We b阵列的不足之处是：
第 27章 建立多服务器网站 计计 811下载图 27-2 多服务器网站的配置网络服务器网络服务器网络服务器数据库服务器网络服务器
Internet
812计计 ASP 3 高级编程 下载
增加了复杂性。
影响系统的结构。
增加了管理工作。
不要轻视这些缺点的影响。快速交付软件的能力是 I n t e r n e t商务的强大竞争优势。建立一个 We b阵，同单个服务器网站相比，将会花费大量资金、较长的时间（对于第一次而言）和较高的经常性费用。如果站点的用户有限，没有重要的使命，能够承担由于例行维修和预料不到的错误引起的关机所产生的后果，那么就尽可能避免建立一个 We b阵。
但是，如果正在开发一个网络应用程序，而且将来可能面对大量的用户，最好考虑周到一些。一旦应用程序运行于多服务器配置（尽管实际上没有多个服务器）,那么增加附加的资源来应付负载增大的问题就非常容易。如果开始没有这样做，扩展服务器的工作会变慢（潜在有阻塞）,根据网站的条件，可能会是几天或者几周而不是几小时。
上面讨论了 We b阵的优点和缺点，就让我们看一下一个 We b阵到底是如何工作的。
27.1.2 We b阵基础
We b阵是如何工作的？考虑一个 H T T P请求的处理过程，如图 2 7 - 3所示。
图 27-3 一个 H T T P请求的处理过程用户将 U R L输入浏览器，在浏览器向服务器发送 T C P / T P请求之前，浏览器需要知道网站的 I P地址。浏览器根据用户输入的主机名通过询问域名系统（ D N S）服务器来查寻相应的 I P
地址。
D N S服务器包含主机名 / I P地址对的映射，如果需要的映射不在某个 D N S服务器上，则服务器就会向第二个 D N S服务器询问。最终，这个询问将被发送到主机网络的 D N S服务器，这个 D N S服务器把找到的 I P地址发送给头一个 D N S服务器，由这个服务器把数据返回浏览器。
应当注意的是，实际上 D N S服务器的操作要比这里简单解释的复杂得多，关于在 I n t e r n e t上使用域名系统的详细描述超出了本书的范围。
用户输入 URL
匹配 URL 到 IP
建立连接连接已建立发送 HTTP 请求接收页面浏览器 DNS 服务器 网络服务器一旦浏览器有了 I P机址，就会开始连接，在状态栏将会看到如,Connecting to site
1 2 7,0,0,0”之类的显示，一旦建立了连接，浏览器就向服务器发送 H T T P请求，服务器分析这些请求（如果服务器负载过重，就把这些请求放入队列中）,并把 H T T P响应发送回浏览器。
当涉及到单个的服务器时，总是由同样的机器响应 H T T P请求。所有负载平衡模式都涉及到可能把后续的 H T T P请求安排到不同的服务器这一问题，这会使状态管理变得困难。
27.2 负载平衡模式对于目前在 I n t e r n e t以及 i n t r a n e t网站上广泛使用的负载平衡有几种可行的方案，包括：
DNS循环复用法：使用 D N S服务器平衡负载。
硬件负载平衡：使用与路由器相似的硬件部件。
微软的 T C P / I P Network Load Balancing：这是一个解决负载分配的软件。
复合方式：硬件与软件组合的解决方式。
我们将逐个讨论这些解决方案，说明它们是如何工作的，分析一下它们在负载平衡与容错方面的性能。同时也将指出系统中的相关变化，例如对服务器的影响。最后还将简单地介绍一些相关的技术，例如微软的 High Availability Clustering以及 C O M＋ Dynamic Load Balancing。
27.2.1 DNS循环复用法
D N S循环复用法（ DNS Round Robin）是将 H T T P请求安排到多个服务器上的简单方法。
如前所述，一个 D N S服务器保持着位于某个特定域内的每台机器的主机名 / I P地址对的集合，
其列表如下：
每个 x x x代表 0 ~ 2 5 5的数（这里没有给出实际的数字，以避免由于无意而涉及任何人的服务器） 。
当建立一个 D N S服务器时（微软的 Windows 2000 Advanced Server中包含 D N S服务）,为每个附加的机器创建一个额外的 I P条目（在 D N S中称为记录或地址记录）,这个结果列表与下面类似：
当响应 D N S的请求时,D N S服务器将循环使用表中所有记录。这样，在上面的例子中，
对于第一个解析 w w w.wrox.com 的请求,D N S服务器将会返回 x x x,x x x,x x x,3，对于下一个解析相同主机名称的请求,D N S服务器将会返回 x x x,x x x,x x x,4，等等。结果所有的请求被分配到所有的网络服务器上。
1,负载平衡
H T T P请求被平衡到一系列网络服务器上，但是只是在每一个服务器收到相同数量的请求这一个方面达到了平衡。这是假设所有的服务器具有相同的资源（一种可行的假设）,而且所有的事务处理都要求相同数量的系统资源（这是一种没有意义的假设） 。这种解决方案根本没有注意到当前 We b阵中机器上的处理器负载。当负载分配达到某种程度时，这是一种效率极第 27章 建立多服务器网站 计计 813下载
814计计 ASP 3 高级编程 下载低的方式，不妨以一个有两个网络服务器的 We b阵为例，如图 2 7 - 4所示。
图 27-4 两个网络服务器组成的 We b阵如果由于服务器 A响应 H T T P请求而使它的处理器利用率饱和（ 1 0 0 %）,而服务器 B的处理器利用率很低（比如 1 0 % ~ 1 5 %）,D N S循环复用法仍会把 H T T P请求的一半发送给服务器 A，
而此时服务器 A已经过载了，这不仅效果很差而且会导致用户在看到站点的执行缓慢时去点击在浏览器上的 R e f r e s h按钮。这不仅是极坏的尝试，而且会使请求队列变长，直到浏览器上出现,Server too busy”消息。
2,容错对于 D N S循环复用法，另一个缺点是不能很好地处理系统的运行中断。仍以两个服务器组成的 We b阵为例。如果服务器 A崩溃，则所有 H T T P请求的一半被安排到一台无效的服务器上，结果就会是在用户的浏览器上显示,Server Unavailable”消息。可以停下来维修机器，
但需要更新 D N S表。这本身就有一个问题，许多 D N S服务器缓存了主机名 / I P地址对信息，可能在几天内都不更新。
3,管理从管理的立场来看,D N S循环复用法是一个管理者的梦想。管理 D N S记录很容易，而且花少许时间就可以为 D N S表添加记录，对于现有的网络配置根本没有任何影响。
4,DNS循环复用法小结总之,D N S循环复用法：
循环服务器列表将请求平均分配到各服务器。
不根据实际的负载情况来决定请求的分配。
无法发现没有响应的或不可利用的系统。
不影响网络服务器的硬件配置。
容易管理。
是负载平衡的一种廉价解决方案。
27.2.2 硬件负载平衡比 D N S循环复用法能力更强是硬件负载平衡。图 2 7 - 5就是一种网络配置的示意图。
有一种新的硬件，即硬件负载平衡器，其位于网络服务器和其他网络设备（防火墙、路由器等）之间。针对某个实际 U R L的用户请求被安排到负载平衡器，连接到负载平衡器上的是一组网络服务器，负载平衡器表现为单个服务器，这种配置方式就是所谓的“集群” 。根据服务器 A
服务器 B
数据库服务器
Internet
第 27章 建立多服务器网站 计计 815下载接收到的发送到集群的 T C P / I P包，负载平衡器执行如下动作：
图 27-5 硬件负载平衡网络配置示意图
决定集群中哪一个服务器将接受下一个 T C P / I P请求。
检查服务器和应用程序（ T C P / I P端口）的可用性。
在有些情况下，检查由服务器返回的数据的有效性。当服务器作出响应时，这是非常方便的，但由于某些问题，服务器的响应总是,HTTP Error 404” 。
转换 I P报头，以便包能指向选中的服务器，这项转化技术通常称为网络地址转换
（ N AT） 。
将包发送到服务器。
当服务器对客户做出响应时，负载平衡器就对返回到客户的包做出相似的转换，第二次
N AT的结果使得客户接收到的 T C P / I P包看起来就是来自代表此集群的 I P。
1,负载平衡负载平衡器如何决定由哪一个服务器响应发送来的请求呢？这因厂商不同而不同，但最基本的算法是相同的。负载平衡器通过监视网络活动性，采集了大量的信息。这些活动性包括进入和来自各个服务器的信息传输量、各个服务器响应 T C P / I P请求的速度、每个服务器目前连接的用户数量以及每个服务器对负载的反应的历史情况。负载平衡器为系统管理员提供了一种基于网络流量的算法，而且这种算法一般包括循环复用法和比率（加权循环复用法）
算法。
负载平衡器通过网络流量监控，能够智能地有效分配处理负载到多个服务器上，再看一下上面 D N S循环复用法中讨论的两个服务器的例子，如图 2 7 - 6所示。
如果由于服务器 A响应 H T T P请求，使其处理器利用率饱和（ 1 0 0 %）,而服务器 B的处理器利用率很低（如 1 0 % ~ 1 5 %）,硬件负载平衡器将注意到服务器 A的响应很慢，它将安排后续的请求到服务器 B。这将持续到在网络服务器 A上的负载回到一个可以接受的水平。其结果比使用 D N S循环复用法好得多。
2,容错再以两个服务器的 We b阵为例。如果服务器 A停机，硬件负载平衡器将不发送任何 T C P / I P
流到服务器 A。实际上，服务器本身可能正在运行，但是如果 Web 服务不能进行响应，负载平衡器就会将服务器 A从可用的服务器的名单上去掉，并将所有的流传送给服务器 B，这也比硬件负载平衡器热备用集群网络服务器
Internet
使用 D N S循环复用法的效果好。
图 27-6 由两个网络服务器组成的硬件负载平衡 We b阵关于硬件负载平衡方案还有一点应当注意：负载平衡器本身成为故障的中心点。为了解决这一点，典型的方案应包括第二个负载平衡器作为热备用，这种冗余故障屏蔽配置是相当可靠的。负载平衡器通常通过像 R S-2 3 2电缆这样的串行通信介质连接，每个单元都有“看门狗”处理器不断地彼此交流。在某个单元失败或不正常时,“看门狗”单元协商并决定由哪一个单元完成负载平衡。
通常，硬件负载平衡器是产品质量部件，其一般特性包括将单个 I P地址或介一个完整的 C
类地址空间与单个服务器关联起来的能力、遥控、基于网络的管理能力、在服务器故障的情况下的通知能力、实时的监视性能和统计信息的能力。
如果对硬件负载平衡系统感兴趣的话,C a b l e t r o n公司 ( w w w,c a b l e t r o n,c o m )和
Cisco Systems公司（ w w w,c i s c o,c o m）已经有了很好的负载平衡的解决方案，在他们网站上有大量有用的信息。
3,管理硬件负载平衡的管理比 D N S循环复用法的管理复杂得多，但是不必畏惧。建立负载平衡器并不比建立一个典型的路由器困难（实际上，这些装置基本上都是路由器的形式）,而且你的网络管理员对于路由器的技术应该很了解。对于网络负载平衡模式的管理是相当集中的，
而且不影响服务器机器本身。这在负责建立并监控服务器的管理员眼中就是一个巨大的成功。
4,局限性对于硬件负载平衡解决方案的实际能力有一些局限，最大的局限是带宽。由于在进入和输出的过程中都要将 T C P / I P报头转变为一个新的 I P地址，通过负载平衡器的，带宽往往被限制在 4 5? 5 0 M b p s。这对于一般数据而言是一个巨大的带宽，大的站点在其使用高峰期能够超过这种能力，额外的信息包被丢弃了。显而易见，这不是最优化的，而且对于大部分网站也是不可行的。
硬件负载平衡解决方案的另一不足之处就是费用太高。写本书时，使用一对硬件负载平衡器的冗余配置的费用在 2 0 0 0 0美元以上，并且在继续上涨。这就意味着必须在负载平衡器上花更多的钱而不是在额外的服务器上。
最后，基于硬件的负载平衡算法必须建立在来自于网络流量的可观测数据的基础上，对服务器的请求的特性可能使服务器的响应变慢，比如 H T T P请求包含要花费大量时间的数据库
816计计 ASP 3 高级编程 下载硬件负载平衡器服务器 A
服务器 B
数据库服务器热备用
Internet
第 27章 建立多服务器网站 计计 817下载操作，但并没有阻塞网络服务。在这种情况下，硬件负载平衡器会认为服务器很忙，但实际上这时服务器是可用的资源。
尽管有这些不足之处，但硬件负载平衡对于完成一个网站的负载平衡有着不容置疑的可靠性与实用性。
5,硬件负载平衡小结总之，硬件负载平衡：
通过将进入和输出的 T C P / I P流转换为服务器集群内的 I P地址，将负载分配到多个服务器上。
根据观察服务器集群内的网络流情况，决定请求如何分配。这从负载平衡的意义上看是高效的，但是在服务器资源方面，例如 C P U的利用率,H T T P请求的队列长度和线程数量等等，不一定高效。
监控每一个服务器和每一个应用程序的可用性。负载平衡器在将包送到服务器之前检查可用性。
不影响网络服务器的硬件配置。
管理相对容易。
对于负载平衡及容错而言，是一种“昂贵”的解决方案。
27.2.3 TCP/IP Network Load Balancing
微软开发了一个软件组件，称为 Network Load Balancing（ N L B）,是作为 Windows 2000
Advanced Server的一部分提供的。 N L B首次于 1 9 9 7年 1 0月以 Windows Load Balancing Serrice
（ W L B S）这个名字作为 Windows NT 4.0的一种插件发布，一个使用 N L B的网络配置示例如图
2 7 - 7所示。
图 27-7 使用 N L B的网络配置的示意图你会发现 N L B所需要的配置不同于标准的网络配置，也会发现来自于 I n t e r n e t的流在一个特定 I P地址上能够被集群中所有服务器识别。这里所说的 I P地址是集群的 I P地址，应当代表网集群 NIC驱动程序
NLB 服务 NLB 服务
TCP/IP 栈
TCP/IP 流单 NIC配置 双 NIC配置
TCP/IP 流 TCP/IP 流
TCP/IP 栈 TCP/IP 栈集群 NIC 驱动程序指定服务器的 NIC驱动程序 指定服务器的 NIC
驱动程序站服务器的 U R L。每一个服务器还有一个唯一的 I P地址用于非集群传输。图 2 7 - 7也暗示了对于每一台服务器存着两个相互独立的网络连接。 N L B不要求这样做，它可以一块网络接口卡
（ Network Interface Card,N I C）上工作，这样不影响服务器的硬件。但是，大多数情况应该使用一个额外的 N I C来实现，后面将更加详细地讨论这个问题。
每台服务器的配置是很简单的。一旦安装了 N L B软件，必须指定一个集群 I P地址、一个唯一的主机 I D（ 1 ~ 3 2，一个 N L B实现被限制在最多有 3 2个服务器）,权重（因为并不是所有系统都有同样的容量）和一系列规则。每一项规则决定了哪一个 T C P / I P应用程序要进行负载平衡及其亲和性（没有、单个 I P或者 C类许可，下面很快将讨论这个问题） 。对于基于网络的流的一条典型规则是,8 0端口（标准的 H T T P端口）没有亲和性。
1,负载平衡你可能会有这样的疑问，最多可以有 3 2个服务器收到同一 I P地址的信息包，为什么客户端没有收到 3 2个响应呢？秘密在于微软称之为的“并行过滤”的东西。当安装了 N L B服务以后，它将自己插入在 T C P / I P栈与 N I C驱动程序之间，所有传输到指定服务器的流直接通过，
对于指向集群的 I P的流,N L B软件决定由哪个主机处理请求，这个服务器让流通过它的集群
N I C驱动程序。集群中的其他服务器过滤掉这个 I P请求，所以只有被指定的服务器响应这个请求。
N L B使用分布算法来确定每一个 T C P / I P请求应该由哪个主机响应。这种算法使用的负载信息是通过各主机收集并通过广播向外传播共享的。由于这是一个软件工具，因此这个负载信息包括 C P U的利用率、可使用的内存和其他情况的详细内容。通过监测网络流，它可以提供一种更精确有效的负载平衡。因为这仅涉及过滤包而不涉及数据包的修改和再发送，所以
N L B不用面对硬件负载平衡模式中的那种吞吐量限制问题。
前面已经指出 N L B仅需一个 N I C，然而，用两个 N I C是一个好主意。图 2 7 - 7展示了两个可能方案。当用一个 N I C时，所有 T C P / I P流都通过 N L B服务。另外，非集群流和集群流通过同样的 N I C，宽带和处理时间被非集群流和集群流分享。增加另一块 N I C卡把集群流与指定服务器的流分离，允许管理流和其他指定服务器的流直接进入服务器，从而使它们对集群的吞吐量影响最小。
2,容错
N L B主机以一定周期交换广播消息，使它们能监视集群的状态。当一个主机进入或离开集群时,N L B软件开始一个称作“集中（ c o n v e rg e n c e）,的处理。在集中期间，主机确定新的集群状态并调整映射算法以反映新的状态，通常这种处理不超过 1 0秒钟。
N L B流的一部分是每个主机都参与的“心跳（ h e a r t b e a t）,消息，心跳消息的周期是可以配置的，缺省周期为一秒。如果主机在 5个心跳消息周期内还没参与服务（或服务失败）,则认为它不再可用，其余的 N L B的主机将开始“集中”过程。
3,管理和前面讨论的解决方案不同,N L B影响每台服务器。它的实现涉及到每台服务器上的软件安装和配置，以及安装附加的 N I C（还有集线器或交换机端口、电缆接头等） 。另外，根据主机名字和分配给每台服务器的权重，配置每台机器。
好消息是 N L B提供了对网上每台计算机的优秀的管理能力。一旦在主机上安装了这个软件，就可以在集群中远程控制主机的加入、移去和配置。
818计计 ASP 3 高级编程 下载第 27章 建立多服务器网站 计计 819下载
4,网络负载平衡小结简而言之，一个 N L B：
通过并行过滤处理，给多个服务器分配负载。
通过系统级负载观测，决定请求的分配。
通过广播“心跳”消息，实现的容错。
要求在每个服务器上安装和配置附加的软件和可选的附加硬件。
有强大的远程管理能力。
是一个廉价的提供负载平衡和容错的解决方案。
27.2.4 复合方式对于负载平衡的另一个可行方案就是硬件与软件技术结合的复合方式。网络配置如图 2 7 - 8
所示。
图 27-8 复合方式的网络配置图 2 7 - 8中有一套硬件负载平衡器和两个服务器集群，每一个集群都使用 N L B来实行负载平衡以及容错。硬件负载平衡器不关心这两个 I P地址与其对应的集群中的服务器地址的变换关系。同样，每个 We b阵也不关心其他 We b阵的存在。
网络服务器集群 IP
特定 IP
交换机 网络硬件负载平衡器集群 IP
热备用网络服务器特定 IP
交换机 网络
Internet
1,负载平衡对于负载平衡，现在服务器可以超过 N L B限制的 3 2个服务器。实际上，如果假设硬件负载平衡器能够在 2 5 6个节点上分配负载（一个完全合理的假设）,就能扩展站点达到不可想象的 8 1 9 2个服务器。
现在可以从网络监控和系统监控两个方面来决定负载分配。形成瓶颈的主要因素可能是网络的状况，而不是系统的处理能力。在这样的方案中，允许在硬件负载平衡器（网络）与使用 N L B的服务器集群（系统）之间协调负载平衡的负担。
2,容错由于增加了硬件负载平衡器，管理容错时有了更多的选择。现在完全能够将 We b阵在网络以及地理位置的意义上相互隔离。复合方式提供了额外的措施来对付环境方面的问题（如洪水、火灾等） 。也提供了最有力的措施去保护所有的服务器以避免危及其安全。后面将进一步地讨论安全问题，但是 N L B最难处理的安全隐患之一是集群中的所有机器彼此之间要保持不间断的通信。
3,管理正如在前面所提到的，硬件负载平衡解决方案并不大量增加管理量。因此，实现和维护一种复合方式负载平衡并不比实现一个 N L B解决方案困难。
4,复合方式小结总之，复合方式解决方案：
将硬件与软件负载平衡的方案相结合。通过 T C P / I P流转换到集群的 I P地址，将负载分配到多个 We b阵中。在服务器集群中通过并行过滤过程管理负载。
通过对网络流的观察和在每个服务器集群中对系统级负载的观察决定请求的分配。
通过监控集群的响应和可用性处理容错。在各集群内，通过广播的“心跳”消息处理容错。
要求在每一个服务器上安装与配置额外的软件及可选的额外硬件。
是提供容错与负载平衡的最贵的解决方案。
27.2.5 High Availability Clustering Service
微软首先推出的集群技术是 1 9 9 7年 1 0月发布的 Windows NT 4.0 Enterprise Edition中的
Microsoft Clustering Service（ M C C S） 。微软公司已经增强了 Windows 2000上的集群能力，并把这项服务更名为 High Availability Clustering Service（ H A C S） 。目前它不是一种负载平衡方法，而是改进可用性与容错的一种措施。
集群服务提供了两种防止像 SQL Server数据库这样的重要应用程序失败的方法。这不同于通过多网络服务器集群提供负载平衡的 N L B系统。看一下图 2 7 - 9所示的硬件负载平衡网络配置。
图 2 7 - 9是我们熟悉的由两个网络服务器处理来自于 I n t e r n e t或者其他网络的流的情况，在其中使用硬件负载平衡的方法实现负载平衡和容错。但是，这种方法仍有单一失败点。如果数据库服务器失灵了，来自于网络服务器的涉及数据库的请求（可能是大量的）将会全部失败。这就是微软的集群服务要解决的问题。考虑一下图 2 7 - 1 0所示的另一个利用集群的网络配置。
820计计 ASP 3 高级编程 下载第 27章 建立多服务器网站 计计 821下载图 27-9 硬件负载平衡网络配置图 27-10 利用集群的另一个网络配置图 2 7 - 1 0中的配置已经消除了单一失败点，现在有两个数据库服务器作为一个虚拟服务器。
这种集群技术对于每一个服务器要求有一个额外的 N I C，在这些 N I C之间形成一个专用网络，
而且要求有一个共享 S C S I总线（至少有一个磁盘） 。此外，这个共享的 S C S I磁盘阵列必须仅用于集群应用程序和其他资源，而系统文件必须单独放在一个独立的用于集群的服务器的
S C S I总线上。
1,负载平衡当前的微软集群技术并不支持负载平衡。微软说目前的集群解决方案是它的集群策略的第一阶段，第一阶段表现为给共享一套数据的两个节点提供故障屏蔽（ f a i l o v e r）功能的能力，
第 2阶段将通过允许最多 1 6个服务器实时共享数据、执行负载平衡以及提供对故障屏幕的支持来合并负载平衡和故障屏幕技术。
2,容错你会注意到集群中两个节点共享一个专用网络。所有与每台机器的“健康”相关的信息以“心跳”消息的形式在这个网络中传播。每一个服务器都有一个称为集群服务的软件组件，
用于监控系统的状态，并把这个信息传送到另一个节点的相应部位。集群准备（ c l u s t e r- r e a d y）
网络服务器硬件负载平衡器数据库服务器热备用集群的数据库服务器网络服务器硬件负载平衡器热备用专用网络
SCSI
Raid
阵列
Internet
Internet
应用程序将数据贮存在共享的 S C S I磁盘阵列上。如果一个应用程序失败，则另一个节点就启动这个应用程序，从磁盘阵列中恢复应用程序的状态，并继续服务于请求。
微软的集群技术对于网络应用程序的可用性提供了基本的保障：状态数据的容错。在多服务器站点上的网络服务器一般不局部地保持状态（在下一节讨论状态） 。这使得重新安排用户的请求到一个可用的服务器变得简单。另一方面，数据库负责管理对象的状态，这就是其目的。为了提供容错，对于高度可用的系统，其数据库服务器必需具有实时管理状态的故障屏蔽能力。
对于集群的唯一替代方案是镜像有故障屏蔽能力的数据库。但镜像数据库不能提供实时的数据同步，因此，一个系统瘫痪将可能导致数据丢失。应当注意到，集群服务能提供对许多资源的容错，而不仅仅是对数据库。这些资源包括文件共享、活动目录服务和一些指定的
D H C P信息。
3,管理
High Arailability Clustering Service 需要严格的硬件和精确的系统配置，因此这种解决方案的管理相对于前面讲过的任何一种负载平衡方案而言，考虑的问题要多。应当注意到集群解决方案通常涉及到大量的新硬件，这会产生额外花费。
4,High Arailability Clustering Service 小结总之,High Arailability Clustering Service 方案：
目前不提供负载平衡。
通过监控集群的响应和可用性处理容错。在各个集群内通过广播的“心跳”消息处理容错。捕获的状态信息被放置在共享的 S C S I磁盘阵列上。
要求每一个服务器都有固定的配置和附加的硬件。
是唯一可对状态数据进行实时恢复的方案。
27.2.6 COM＋ Dynamic Load Balancing
在前面，我们为负载平衡和容错而增加了额外的服务器，增加的服务器放在表现层（网络服务器）和数据库层。正如在第 1 3章所描述的，一个普通的应用程序结构如图 2 7 - 11所示，
还包括另一个组件层，即业务逻辑层。
图 2 7 - 11 应用程序的基本结构
822计计 ASP 3 高级编程 下载表现层 业务逻辑层 数据库层第 27章 建立多服务器网站 计计 823下载表现层包括网络服务器和一系列的 A S P文档。嵌入到 A S P文档中的服务器端脚本实例化一个 C O M＋组件，这个组件对某些业务逻辑和数据库访问的细节进行抽象，并通常在网络服务器上实例化。如果 C O M＋提供了本地 /远程的透明性，应将业务逻辑组件分离到一个独立的服务器上。
网络配置的结果如图 2 7 - 1 2所示。
图 27-12 采用分离的业务逻辑组件的负载平衡网络配置现在已把业务逻辑组件的处理负载分配到另一个服务器上，使网络服务器有更多的时间和资源来处理 H T T P请求。但是，现在又重新引入了一个单一失败点。如果业务逻辑服务器停机，负载平衡器仍然会将 H T T P请求发送到网络服务器，但是网络服务器将无法满足这些请求。
对于将业务层从表现层划分出来，安装在另一台机器上,C O M＋ Dynamic Load
B a l a n c i n g。这种能力原来是 Window 2000 Advanced Server的一个功能，在本书编写时，它随着 Windows 2000 AppCenter Server一同发布。图 2 7 - 1 3所示就是 C O M＋ Dynamic Load
B a l a n c i n g的一个简单实现。
图 27-13 使用 C O M＋ Dynamic Load Balancing的网络配置一个额外的服务器已经被添加到结构中，即组件负载平衡路由器。这个服务器（通过集群服务提供容错和高可用性）接收来自网络服务器的请求，并把这些请求安排到业务逻辑服务器阵中。请求的安排根据每个应用程序服务器的处理负载而定。开始时，业务逻辑服务器阵可以支持最多 8个服务器。
网络服务器数据库服务器热备用硬件负载平衡器业务逻辑服务器硬件负载平衡器热备用网络服务器 业务逻辑 服务器 数据库服务器组件负载平衡 路由器
Internet
Internet
27.3 状态管理到现在为止，已经讨论了一个多服务器网站的概念，而且研究了一系列分配 H T T P请求到
We b阵的方法。但是，分配请求只是任务的一部分，还必须研究状态管理。
H T T P协议原本是一种无状态协议。根据其本质，在 H T T P请求之间服务器不应该有状态这个概念。 A S P处理这个问题时几乎都是使用 S e s s i o n对象，但 S e s s i o n对象是“指定机器的” 。
有几个方法可以解决这个问题，其中包括避免使用状态、使用客户端的 c o o k i e代替状态、利用亲和性（ a ff i n i t y）来允许使用 S e s s i o n对象以及串行化状态数据并存入通用存储器中。
27.3.1 不管理状态不是所有的网络应用程序都需要管理页面与页面之间的状态。如果一开始时就能避免管理状态，就能为自己减少很多麻烦。很明显这并不是令人满意的答案，但却是不可忽略的。
状态管理增加了网络应用程序的复杂性，因此，能避免它是件好事。
27.3.2 客户端存储就像第 2章介绍的 R e s p o n s e和 R e q u e s t对象允许在客户机上存储和获取 c o o k i e。状态也可以在隐藏的窗体中存储，窗体在页面之间通过提交传递。在这种情况下，客户端存储是较好的方法，这把管理数据的任务从服务器上完全移走。若数据存储在服务器上，随着用户数量的增加，存储在服务器上的数据将影响服务器性能。举个例子，如果每个浏览网站的用户存储 4 K B有价值的信息，而同时有 1 0 0 0 0个用户的活动会话，系统必须拿出 4 0 M B的内存空间来存储这些不经常访问的数据。将这些信息存储到每个客户端，能有效地改善系统的性能。
另一方面,c o o k i e信息随同每个 H T T P请求一起传送。因此，客户端存储的方法增加了网络传输量，增加了传输时间，不如在服务器端管理状态数据安全，而且对存储到客户端的数据量有限制（依赖于浏览器）,用户随时可能删除 c o o k i e，而且 c o o k i e信息只能为特定机器上的用户服务。
27.3.3 亲和性如果想利用会话变量并使用多服务器网站，可以使用一个扩展的方法，允许“会话亲和性（ session aff i n i t y）,。,亲和性”是指网络浏览需要与单个服务器相关联，而且返回每一个后续的请求到这个服务器。一个浏览器首先连接到 We b阵中的某个的服务器上。从此开始，
在这个用户会话期间，所有后续的请求将安排到同一服务器上。如果在应用程序中使用
S e s s i o n对象，这是必需的。
硬件员载平衡器和 N L B解决方案都能在确定由哪一个服务器响应某个用户时，提供这种亲和性。然而，亲和性的使用部分抵消了使用这些方案而得到的负载平衡效果。负载平衡方案是在接收到请求时，根据各个服务器的负载情况，将请求分配到某个服务器上。在会话的存活期，服务器的负载特征可能会发生很大的变化。看一下下面这个例子，如图 2 7 -
1 4所示。
为了简单，图 2 7 - 1 4中省略了所有连网和负载平衡设备。
824计计 ASP 3 高级编程 下载图 27-14 利用亲和性的网络配置假设有 4个用户（ A ~ D）连接到网站，他们的请求平均分配给两个网络服务器。现在假设用户 C和用户 D立即断开连接，用户 A和用户 B长时间连接并执行许多复杂的运算。如果我们使用了“亲和性”,所有的来自于用户 A和用户 B的 H T T P请求将安排到网络服务器 A上，用户
A和用户 B将会看到服务器 A超载，而服务器 B却闲置着。
使用“亲和性”的另一个问题是容错。网络应用程序的容错目标是完全恢复任何单个的故障。如果严格限制一个用户只能连接到单个服务器，就将失去拥有冗余机器的好处。考虑与上面相同的情况，如果网络服务器 A瘫痪，用户 A和用户 B正在使用的所有事务数据和状态数据将丢失。
最后，即使你愿意牺牲性能和容错（这是 We b阵的两个主要目的）以便使用 S e s s i o n对象，
“亲和性”也不能在所有情况下工作。请看图 2 7 - 1 5所示的例子。
图 27-15 使用代理服务器的网络配置用户 A所在的网络有几个代理服务器平衡负载。当用户 A通过浏览器发出 H T T P请求时，
第 27章 建立多服务器网站 计计 825下载用户 A
用户 B
用户 C
用户 D
网络服务器 A
网络服务器 B
数据库服务器用户 A
负载平衡器代理服务器 A
代理服务器 B 网络服务器 B
网络服务器 A
数据库服务器浏览器就会将这个请求传递给代理服务器。在本例中，有两个代理服务器。由于本例使用单个机器的“亲和性”,每个来自代理服务器 A的请求被安排到同一个网络服务器，即网络服务器 A。所有通过代理服务器 B的请求被安排到网络服务器 B。尽管是单个用户访问我们的网络，
但我们的系统认为这些请求来自两个用户并用两个网络服务器来分担负载，这将导致试图访问会话数据时出现意想不到的情况。
大部分负载平衡硬件及 N L B都有解决这个问题的方案。它们允许“亲和性”针对于一个完整的 C类地址空间（ 2 5 6个唯一的 I P地址） 。其基本原理是大部分代理服务器集群应在同一个地址空间内。 C类地址“亲和力”会对员载平衡效率产生巨大的不利影响，因为它们一大批用户（而不是一个用户）绑定到一台服务器。对于大的用户组，代理服务器经常用于帮助传输或者缓存 H T T P流。美国在线（ A O L）就是这样一个用户组。当使用 C类“亲和性”时，就必须冒着突然关闭一个服务器，同时使一大批用户不能获得服务的风险。
27.3.4 在一个中心服务器上存储状态存储状态的首选方式是存储在一个中心服务器上。为了达到容错的目的，中心服务器通常是集群的两个服务器。当用户首次访问站点时，由一个定制的服务器端组件生成一个会话
I D，并且存储在浏览器中。用户会话期间的后续 H T T P请求都包含这个会话 I D。会话 I D作为键与一个文本字符串一起存储到数据库表中，通过这个缓存文本字符串可以存储和检索二进制大对象（ B L O B） 。尽管有这样的名称,B L O B S其实没有那么大。每个具有状态信息的 A S P
组件具有将自己写入这个缓存表中并从中读出的能力。
微软提供了一个解决扩展网络时出现的状态问题的很好方案。进一步而言，我们将尽力提供一种可持久的、机器独立的状态跟踪机制。现在已经有一种比较容易的方式。
Commerce Server（早期的 Site Server,Commerce Edition）的再利用。 Commerce Server提供的个人化服务能准确地解决这个问题。这些个人化服务将被写入数据库，但是这一麻烦的过程将会通过一组封装对象隐藏起来。此外，个人化及成员关系的管理由一个 M M C插件实现，
很容易使用。
但是,Commerce Server的解决方案也存在问题。 Commerce Server需要 8 0 0 M B的硬盘空间和许多你不需要或不用的东西。不幸地是除了全部装上别无选择。此外，对于个人化数据的访问是通过 L D A P连接进行的，这种连接比通过 A D O和编译的定制组件直接连到数据库上要慢得多。
27.4 安全在访问多服务器时必须解决的另一个问题就是安全。对于向 I n t e r n e t开放的多服务器网站，
正确的安全管理是一个要用一整本书来讨论的课题，我们仅用一节。这一节的目的是接触与多服务器站点安全相关的两个关键问题。我们将讨论一些用户管理的方式和当使用 N L B服务来平衡负载时在某些领域存在的潜在危险。
1,用户管理跟踪和控制用户访问的最简单的方式是通过本地的用户注册表。验证和用户管理利用
Wi n d o w s的管理工具进行处理。
本地的用户注册表对于多服务器网站来说是不够的。如果网站允许用户在任何地点登录，
826计计 ASP 3 高级编程 下载对于多服务器网站必然会带来问题。对于一个多服务器网站，有两个地方可存储用户的证书：
针对特定域的 Windows 用户注册表。
译成密码存储在一个中心数据存储中。
(1) Wi n d o w s用户注册表初看上去,N T域的用户注册表好象是理想的存储用户帐号信息的地方。验证是简单的。
用户的口令是自动地管理和存储的，不必为加密担心。
但是有一个问题：用户注册表也用于允许和禁止对系统上所有资源的访问。这意味着在系统内的每一个用户都有一个访问这个域内的所有机器的帐号，负责管理这些帐号的人有责任确保这些帐号的权限是合适。
此外，在 We b阵中的所有机器都必需是一个域内的成员。最低程度上，应当保证生产性机器在单独的、隔离的域中运行。即使这样，也可以从这个域内的一台机器上对所有服务器资源进行访问。安全系统的一个目标就是，任何机器在安全性受损害时都应该不影响这个站点内的其他机器。
(2) 中心数据存储另一种首选的存储域内用户信息的方式就是将用户的信息存储在数据库中。在 A S P页面或者 I S A P过滤器中检查用户信息非常简单，依据数据库进行验证也是一项相当轻松的任务。
这不需要依靠各种各样网络服务器之间的连接。也能够减少由于管理失误或者更糟的情况导致安全性下降的可能性，更糟的情况就是本被允许访问这个网站的用户进入网络应用程序中。
不过这比那些由于人们的失误而使某人在域内拥有最高特权的情况好得多。
另一个在数据库中存储口令信息的问题是，任何能对数据库进行读查询访问的人都能够检索出用户的口令。对于这个问题，最显而易见的解决方式就是，利用一种商业加密技术保证口令以不可用的形式存储。
我们又一次面对着与状态管理相同的难题。对于用户管理和验证有一个很好的解决方案。
用数据库加密实现我们自己的验证机制看起来有点难，但已有一个比较简单的方式。
还是用 Commerce Server。 Commerce Server提供用户管理功能，并允许网站的验证绑定到 Commerce Server的用户数据库。正如前面提到的,Commerce Server安装量巨大，并且依赖于 L D A P访问用户的数据。这比直接的数据库访问要慢的多。但是，它正好为这个问题提供了一种方便的解决方案。
2,负载平衡最后，让我们简单地对 N L B服务的安全性做出一个结论。 N L B服务通过在集群服务器中进行持续通信来管理负载平衡。这意味着某台机器的安全性受损害时，可能对整个 We b阵的安全产生不利影响。然而这并不是一种非常槽的情况，在任何时间都有很多机器在它们之间传递信息并使用这些信息调节系统的行为与操作，这涉及有限的风险。
27.5 小结本章介绍了多服务器网站的概念。将网络应用程序从单一的服务器上扩展到多服务器上的目的是：
增加站点的吞吐量和性能。
提供冗余和容错能力。
第 27章 建立多服务器网站 计计 827下载
增加站点的可用性。
我们介绍了许多实现多服务器站点的模式，阐述了每一种模式的优点和缺点。在本章的最后，简短分析了一个多服务器网站的状态管理和安全性。
建立一个稳固的可扩展的（即能够处理大量用户的）网站是一个深奥的课题。建立一个多服务器的网站增加了开发和测试的复杂性和难度。必须及时解决网络的状态与安全问题。
如果需要处理大量的用户或者需要提供高的可用性，那么从一开始建立系统时就要考虑系统的容量，这样会使问题变得更加简单。
828计计 ASP 3 高级编程 下载
主要讨论以下问题：
多服务器网站的定义，以及何时或者是否应当建立一个多服务器网站。
建立一个 We b阵的各种方法及其优势与不足。
从结构方面考虑实现在多台机器上运行的网络应用程序。
首先让我们看一下一个多服务器网站的构成。
27.1 多服务器网站最典型的网站有一个单一的响应 H T T P请求的网络服务器，这个服务器可能使用 A S P动态地产生 H T T P或者简单地提供静态内容。这个服务器也可能连接到本地或远程的数据库上，图
2 7 - 1就是这种配置。
随着用户数量的增加，性能开始下降。如何解决这个问题。正如在上一章所看到的，典型的做法是，每隔一定时间分析软件的结构，
在各种各样的算法中清理出过于臃肿的内容。
网络服务器也可以通过增加 C P U、额外的 R A M
和更快的硬盘驱动器增强其性能。然而，最终可能无法再通过改进系统的性能使其达到可接受的水平。对于 I n t e r n e t应用程序，这种情况早已出现。改善系统性能的一种显而易见的方式就是通过多网络服务器分散或平衡负载。
即使网站的用户数量不多，对于单个服务器配置，也存在一些其他的潜在问题。每一个
I T经理的一个基本假设就是任何机器都会失败，如果这个失败的机器作为网络服务器，则用户无论如何也不能进入这个网站。对于商业站点来说这将带来许多麻烦。考虑一个在线经纪人例子，如果一个在线经纪人不能被访问，这个在线经纪人的顾客可能在等待网站恢复的时候损失大量的资金。
此外，需要注意的是，维护也是管理生产环境时不可缺少的部分。有一些常规的安全性公告要求应用程序热修补和对系统或系统软件的服务补丁。这可能需要替换硬件。当网站仅有一个服务器时，即使是最一般的改变，也要将整个网站停下来。这将导致数小时的维修以及 I T职员的抱怨。
最后还有一个内容升级的问题。网络应用程序的发展趋向于不断改变网站的内容。在一个独立的服务器上展示新的内容或让内部用户验证网站的正确性是一个极好的方法。这样能避免许多令人烦恼的问题和咨询电话。
图 2 7 - 2展示了多服务器网站的配置。
网络服务器 数据库服务器图 27-1 网络服务器的配置
Internet
请求进入到几个网络服务器中的一个，这个服务器在处理请求的过程中从数据库服务器中读取数据，或者向其中写入数据。如果一台网络服务器出了故障，其他的网络服务器将会处理这些附加的请求。这种配置提供了负载平衡，负载将被分配或平衡到多个网络服务器上。这种配置也提供容错，在容错范围内，任何一部分出现故障将不影响网站的可用性。
此外，网络服务器多于数据库服务器。
通常，一个数据库服务器能够处理由多个网络服务器产生的负载，这样可以不必平衡数据库服务器负载。但是仍然需要防止任何单台机器的故障导致整个网站瘫痪，出于这一目的，要给数据库服务器一个冗余的后备配置。这将意味着将有一台额外的（备用）机器专门用于应付主要机器的故障，这称为故障屏蔽（ f a i l o v e r）配置，其原因是备用机器阻止了失败的现象在用户面前出现。
总而言之，使用 We b阵的优点是：
增强了事务性的吞吐量。
允许大量的用户同时工作。
增加了冗余度（容错） 。
增强了可用性，在例行维护时不用停机。
27.1.1 We b阵的不足在进一步深入研究之前，首先要问自己这样一个问题：增加一个 We b阵是否是一件好事。
当讨论多网络服务器网站的运行优点时，同样也需要讨论它的不足之处。
明显的缺点是增加了系统的复杂性，当请求通过多服务器时，需要某些模式来分配请求给这些服务器。最具有代表性的是需要增加网络硬件或软件组件。这不仅增加了相关的开发和管理工作，而且也增加了测试工作。为了确定系统按希望工作，必须测试系统的冗余、负载平衡和故障屏障等各个方面。
另一个缺点是这种变化可能影响系统结构，将在后面讨论这些问题。状态管理、用户管理和资源管理等模式，移植到多服务器系统时需要进行改变。一种简单的例子是管理上传的文件，如果这些文件当前是放在本地的目录结构中，需要修改系统使其指向中心的共享目录。
最后，当将原来使用一台机器的网站改为使用多台机器时，要增加管理的费用。 I T职员需要对多台机器进行追踪，监控每台机器的配置。内容、代码、热修补、补丁等等必须写入到每台服务器。尽管冗余使得管理能在运行期间执行，但是冗余和容错不能免除管理员的责任。此外，测试环境必须真实地（最大程度地）反映工作环境，也就是要测试更多机器。
总而言之，使用 We b阵列的不足之处是：
第 27章 建立多服务器网站 计计 811下载图 27-2 多服务器网站的配置网络服务器网络服务器网络服务器数据库服务器网络服务器
Internet
812计计 ASP 3 高级编程 下载
增加了复杂性。
影响系统的结构。
增加了管理工作。
不要轻视这些缺点的影响。快速交付软件的能力是 I n t e r n e t商务的强大竞争优势。建立一个 We b阵，同单个服务器网站相比，将会花费大量资金、较长的时间（对于第一次而言）和较高的经常性费用。如果站点的用户有限，没有重要的使命，能够承担由于例行维修和预料不到的错误引起的关机所产生的后果，那么就尽可能避免建立一个 We b阵。
但是，如果正在开发一个网络应用程序，而且将来可能面对大量的用户，最好考虑周到一些。一旦应用程序运行于多服务器配置（尽管实际上没有多个服务器）,那么增加附加的资源来应付负载增大的问题就非常容易。如果开始没有这样做，扩展服务器的工作会变慢（潜在有阻塞）,根据网站的条件，可能会是几天或者几周而不是几小时。
上面讨论了 We b阵的优点和缺点，就让我们看一下一个 We b阵到底是如何工作的。
27.1.2 We b阵基础
We b阵是如何工作的？考虑一个 H T T P请求的处理过程，如图 2 7 - 3所示。
图 27-3 一个 H T T P请求的处理过程用户将 U R L输入浏览器，在浏览器向服务器发送 T C P / T P请求之前，浏览器需要知道网站的 I P地址。浏览器根据用户输入的主机名通过询问域名系统（ D N S）服务器来查寻相应的 I P
地址。
D N S服务器包含主机名 / I P地址对的映射，如果需要的映射不在某个 D N S服务器上，则服务器就会向第二个 D N S服务器询问。最终，这个询问将被发送到主机网络的 D N S服务器，这个 D N S服务器把找到的 I P地址发送给头一个 D N S服务器，由这个服务器把数据返回浏览器。
应当注意的是，实际上 D N S服务器的操作要比这里简单解释的复杂得多，关于在 I n t e r n e t上使用域名系统的详细描述超出了本书的范围。
用户输入 URL
匹配 URL 到 IP
建立连接连接已建立发送 HTTP 请求接收页面浏览器 DNS 服务器 网络服务器一旦浏览器有了 I P机址，就会开始连接，在状态栏将会看到如,Connecting to site
1 2 7,0,0,0”之类的显示，一旦建立了连接，浏览器就向服务器发送 H T T P请求，服务器分析这些请求（如果服务器负载过重，就把这些请求放入队列中）,并把 H T T P响应发送回浏览器。
当涉及到单个的服务器时，总是由同样的机器响应 H T T P请求。所有负载平衡模式都涉及到可能把后续的 H T T P请求安排到不同的服务器这一问题，这会使状态管理变得困难。
27.2 负载平衡模式对于目前在 I n t e r n e t以及 i n t r a n e t网站上广泛使用的负载平衡有几种可行的方案，包括：
DNS循环复用法：使用 D N S服务器平衡负载。
硬件负载平衡：使用与路由器相似的硬件部件。
微软的 T C P / I P Network Load Balancing：这是一个解决负载分配的软件。
复合方式：硬件与软件组合的解决方式。
我们将逐个讨论这些解决方案，说明它们是如何工作的，分析一下它们在负载平衡与容错方面的性能。同时也将指出系统中的相关变化，例如对服务器的影响。最后还将简单地介绍一些相关的技术，例如微软的 High Availability Clustering以及 C O M＋ Dynamic Load Balancing。
27.2.1 DNS循环复用法
D N S循环复用法（ DNS Round Robin）是将 H T T P请求安排到多个服务器上的简单方法。
如前所述，一个 D N S服务器保持着位于某个特定域内的每台机器的主机名 / I P地址对的集合，
其列表如下：
每个 x x x代表 0 ~ 2 5 5的数（这里没有给出实际的数字，以避免由于无意而涉及任何人的服务器） 。
当建立一个 D N S服务器时（微软的 Windows 2000 Advanced Server中包含 D N S服务）,为每个附加的机器创建一个额外的 I P条目（在 D N S中称为记录或地址记录）,这个结果列表与下面类似：
当响应 D N S的请求时,D N S服务器将循环使用表中所有记录。这样，在上面的例子中，
对于第一个解析 w w w.wrox.com 的请求,D N S服务器将会返回 x x x,x x x,x x x,3，对于下一个解析相同主机名称的请求,D N S服务器将会返回 x x x,x x x,x x x,4，等等。结果所有的请求被分配到所有的网络服务器上。
1,负载平衡
H T T P请求被平衡到一系列网络服务器上，但是只是在每一个服务器收到相同数量的请求这一个方面达到了平衡。这是假设所有的服务器具有相同的资源（一种可行的假设）,而且所有的事务处理都要求相同数量的系统资源（这是一种没有意义的假设） 。这种解决方案根本没有注意到当前 We b阵中机器上的处理器负载。当负载分配达到某种程度时，这是一种效率极第 27章 建立多服务器网站 计计 813下载
814计计 ASP 3 高级编程 下载低的方式，不妨以一个有两个网络服务器的 We b阵为例，如图 2 7 - 4所示。
图 27-4 两个网络服务器组成的 We b阵如果由于服务器 A响应 H T T P请求而使它的处理器利用率饱和（ 1 0 0 %）,而服务器 B的处理器利用率很低（比如 1 0 % ~ 1 5 %）,D N S循环复用法仍会把 H T T P请求的一半发送给服务器 A，
而此时服务器 A已经过载了，这不仅效果很差而且会导致用户在看到站点的执行缓慢时去点击在浏览器上的 R e f r e s h按钮。这不仅是极坏的尝试，而且会使请求队列变长，直到浏览器上出现,Server too busy”消息。
2,容错对于 D N S循环复用法，另一个缺点是不能很好地处理系统的运行中断。仍以两个服务器组成的 We b阵为例。如果服务器 A崩溃，则所有 H T T P请求的一半被安排到一台无效的服务器上，结果就会是在用户的浏览器上显示,Server Unavailable”消息。可以停下来维修机器，
但需要更新 D N S表。这本身就有一个问题，许多 D N S服务器缓存了主机名 / I P地址对信息，可能在几天内都不更新。
3,管理从管理的立场来看,D N S循环复用法是一个管理者的梦想。管理 D N S记录很容易，而且花少许时间就可以为 D N S表添加记录，对于现有的网络配置根本没有任何影响。
4,DNS循环复用法小结总之,D N S循环复用法：
循环服务器列表将请求平均分配到各服务器。
不根据实际的负载情况来决定请求的分配。
无法发现没有响应的或不可利用的系统。
不影响网络服务器的硬件配置。
容易管理。
是负载平衡的一种廉价解决方案。
27.2.2 硬件负载平衡比 D N S循环复用法能力更强是硬件负载平衡。图 2 7 - 5就是一种网络配置的示意图。
有一种新的硬件，即硬件负载平衡器，其位于网络服务器和其他网络设备（防火墙、路由器等）之间。针对某个实际 U R L的用户请求被安排到负载平衡器，连接到负载平衡器上的是一组网络服务器，负载平衡器表现为单个服务器，这种配置方式就是所谓的“集群” 。根据服务器 A
服务器 B
数据库服务器
Internet
第 27章 建立多服务器网站 计计 815下载接收到的发送到集群的 T C P / I P包，负载平衡器执行如下动作：
图 27-5 硬件负载平衡网络配置示意图
决定集群中哪一个服务器将接受下一个 T C P / I P请求。
检查服务器和应用程序（ T C P / I P端口）的可用性。
在有些情况下，检查由服务器返回的数据的有效性。当服务器作出响应时，这是非常方便的，但由于某些问题，服务器的响应总是,HTTP Error 404” 。
转换 I P报头，以便包能指向选中的服务器，这项转化技术通常称为网络地址转换
（ N AT） 。
将包发送到服务器。
当服务器对客户做出响应时，负载平衡器就对返回到客户的包做出相似的转换，第二次
N AT的结果使得客户接收到的 T C P / I P包看起来就是来自代表此集群的 I P。
1,负载平衡负载平衡器如何决定由哪一个服务器响应发送来的请求呢？这因厂商不同而不同，但最基本的算法是相同的。负载平衡器通过监视网络活动性，采集了大量的信息。这些活动性包括进入和来自各个服务器的信息传输量、各个服务器响应 T C P / I P请求的速度、每个服务器目前连接的用户数量以及每个服务器对负载的反应的历史情况。负载平衡器为系统管理员提供了一种基于网络流量的算法，而且这种算法一般包括循环复用法和比率（加权循环复用法）
算法。
负载平衡器通过网络流量监控，能够智能地有效分配处理负载到多个服务器上，再看一下上面 D N S循环复用法中讨论的两个服务器的例子，如图 2 7 - 6所示。
如果由于服务器 A响应 H T T P请求，使其处理器利用率饱和（ 1 0 0 %）,而服务器 B的处理器利用率很低（如 1 0 % ~ 1 5 %）,硬件负载平衡器将注意到服务器 A的响应很慢，它将安排后续的请求到服务器 B。这将持续到在网络服务器 A上的负载回到一个可以接受的水平。其结果比使用 D N S循环复用法好得多。
2,容错再以两个服务器的 We b阵为例。如果服务器 A停机，硬件负载平衡器将不发送任何 T C P / I P
流到服务器 A。实际上，服务器本身可能正在运行，但是如果 Web 服务不能进行响应，负载平衡器就会将服务器 A从可用的服务器的名单上去掉，并将所有的流传送给服务器 B，这也比硬件负载平衡器热备用集群网络服务器
Internet
使用 D N S循环复用法的效果好。
图 27-6 由两个网络服务器组成的硬件负载平衡 We b阵关于硬件负载平衡方案还有一点应当注意：负载平衡器本身成为故障的中心点。为了解决这一点，典型的方案应包括第二个负载平衡器作为热备用，这种冗余故障屏蔽配置是相当可靠的。负载平衡器通常通过像 R S-2 3 2电缆这样的串行通信介质连接，每个单元都有“看门狗”处理器不断地彼此交流。在某个单元失败或不正常时,“看门狗”单元协商并决定由哪一个单元完成负载平衡。
通常，硬件负载平衡器是产品质量部件，其一般特性包括将单个 I P地址或介一个完整的 C
类地址空间与单个服务器关联起来的能力、遥控、基于网络的管理能力、在服务器故障的情况下的通知能力、实时的监视性能和统计信息的能力。
如果对硬件负载平衡系统感兴趣的话,C a b l e t r o n公司 ( w w w,c a b l e t r o n,c o m )和
Cisco Systems公司（ w w w,c i s c o,c o m）已经有了很好的负载平衡的解决方案，在他们网站上有大量有用的信息。
3,管理硬件负载平衡的管理比 D N S循环复用法的管理复杂得多，但是不必畏惧。建立负载平衡器并不比建立一个典型的路由器困难（实际上，这些装置基本上都是路由器的形式）,而且你的网络管理员对于路由器的技术应该很了解。对于网络负载平衡模式的管理是相当集中的，
而且不影响服务器机器本身。这在负责建立并监控服务器的管理员眼中就是一个巨大的成功。
4,局限性对于硬件负载平衡解决方案的实际能力有一些局限，最大的局限是带宽。由于在进入和输出的过程中都要将 T C P / I P报头转变为一个新的 I P地址，通过负载平衡器的，带宽往往被限制在 4 5? 5 0 M b p s。这对于一般数据而言是一个巨大的带宽，大的站点在其使用高峰期能够超过这种能力，额外的信息包被丢弃了。显而易见，这不是最优化的，而且对于大部分网站也是不可行的。
硬件负载平衡解决方案的另一不足之处就是费用太高。写本书时，使用一对硬件负载平衡器的冗余配置的费用在 2 0 0 0 0美元以上，并且在继续上涨。这就意味着必须在负载平衡器上花更多的钱而不是在额外的服务器上。
最后，基于硬件的负载平衡算法必须建立在来自于网络流量的可观测数据的基础上，对服务器的请求的特性可能使服务器的响应变慢，比如 H T T P请求包含要花费大量时间的数据库
816计计 ASP 3 高级编程 下载硬件负载平衡器服务器 A
服务器 B
数据库服务器热备用
Internet
第 27章 建立多服务器网站 计计 817下载操作，但并没有阻塞网络服务。在这种情况下，硬件负载平衡器会认为服务器很忙，但实际上这时服务器是可用的资源。
尽管有这些不足之处，但硬件负载平衡对于完成一个网站的负载平衡有着不容置疑的可靠性与实用性。
5,硬件负载平衡小结总之，硬件负载平衡：
通过将进入和输出的 T C P / I P流转换为服务器集群内的 I P地址，将负载分配到多个服务器上。
根据观察服务器集群内的网络流情况，决定请求如何分配。这从负载平衡的意义上看是高效的，但是在服务器资源方面，例如 C P U的利用率,H T T P请求的队列长度和线程数量等等，不一定高效。
监控每一个服务器和每一个应用程序的可用性。负载平衡器在将包送到服务器之前检查可用性。
不影响网络服务器的硬件配置。
管理相对容易。
对于负载平衡及容错而言，是一种“昂贵”的解决方案。
27.2.3 TCP/IP Network Load Balancing
微软开发了一个软件组件，称为 Network Load Balancing（ N L B）,是作为 Windows 2000
Advanced Server的一部分提供的。 N L B首次于 1 9 9 7年 1 0月以 Windows Load Balancing Serrice
（ W L B S）这个名字作为 Windows NT 4.0的一种插件发布，一个使用 N L B的网络配置示例如图
2 7 - 7所示。
图 27-7 使用 N L B的网络配置的示意图你会发现 N L B所需要的配置不同于标准的网络配置，也会发现来自于 I n t e r n e t的流在一个特定 I P地址上能够被集群中所有服务器识别。这里所说的 I P地址是集群的 I P地址，应当代表网集群 NIC驱动程序
NLB 服务 NLB 服务
TCP/IP 栈
TCP/IP 流单 NIC配置 双 NIC配置
TCP/IP 流 TCP/IP 流
TCP/IP 栈 TCP/IP 栈集群 NIC 驱动程序指定服务器的 NIC驱动程序 指定服务器的 NIC
驱动程序站服务器的 U R L。每一个服务器还有一个唯一的 I P地址用于非集群传输。图 2 7 - 7也暗示了对于每一台服务器存着两个相互独立的网络连接。 N L B不要求这样做，它可以一块网络接口卡
（ Network Interface Card,N I C）上工作，这样不影响服务器的硬件。但是，大多数情况应该使用一个额外的 N I C来实现，后面将更加详细地讨论这个问题。
每台服务器的配置是很简单的。一旦安装了 N L B软件，必须指定一个集群 I P地址、一个唯一的主机 I D（ 1 ~ 3 2，一个 N L B实现被限制在最多有 3 2个服务器）,权重（因为并不是所有系统都有同样的容量）和一系列规则。每一项规则决定了哪一个 T C P / I P应用程序要进行负载平衡及其亲和性（没有、单个 I P或者 C类许可，下面很快将讨论这个问题） 。对于基于网络的流的一条典型规则是,8 0端口（标准的 H T T P端口）没有亲和性。
1,负载平衡你可能会有这样的疑问，最多可以有 3 2个服务器收到同一 I P地址的信息包，为什么客户端没有收到 3 2个响应呢？秘密在于微软称之为的“并行过滤”的东西。当安装了 N L B服务以后，它将自己插入在 T C P / I P栈与 N I C驱动程序之间，所有传输到指定服务器的流直接通过，
对于指向集群的 I P的流,N L B软件决定由哪个主机处理请求，这个服务器让流通过它的集群
N I C驱动程序。集群中的其他服务器过滤掉这个 I P请求，所以只有被指定的服务器响应这个请求。
N L B使用分布算法来确定每一个 T C P / I P请求应该由哪个主机响应。这种算法使用的负载信息是通过各主机收集并通过广播向外传播共享的。由于这是一个软件工具，因此这个负载信息包括 C P U的利用率、可使用的内存和其他情况的详细内容。通过监测网络流，它可以提供一种更精确有效的负载平衡。因为这仅涉及过滤包而不涉及数据包的修改和再发送，所以
N L B不用面对硬件负载平衡模式中的那种吞吐量限制问题。
前面已经指出 N L B仅需一个 N I C，然而，用两个 N I C是一个好主意。图 2 7 - 7展示了两个可能方案。当用一个 N I C时，所有 T C P / I P流都通过 N L B服务。另外，非集群流和集群流通过同样的 N I C，宽带和处理时间被非集群流和集群流分享。增加另一块 N I C卡把集群流与指定服务器的流分离，允许管理流和其他指定服务器的流直接进入服务器，从而使它们对集群的吞吐量影响最小。
2,容错
N L B主机以一定周期交换广播消息，使它们能监视集群的状态。当一个主机进入或离开集群时,N L B软件开始一个称作“集中（ c o n v e rg e n c e）,的处理。在集中期间，主机确定新的集群状态并调整映射算法以反映新的状态，通常这种处理不超过 1 0秒钟。
N L B流的一部分是每个主机都参与的“心跳（ h e a r t b e a t）,消息，心跳消息的周期是可以配置的，缺省周期为一秒。如果主机在 5个心跳消息周期内还没参与服务（或服务失败）,则认为它不再可用，其余的 N L B的主机将开始“集中”过程。
3,管理和前面讨论的解决方案不同,N L B影响每台服务器。它的实现涉及到每台服务器上的软件安装和配置，以及安装附加的 N I C（还有集线器或交换机端口、电缆接头等） 。另外，根据主机名字和分配给每台服务器的权重，配置每台机器。
好消息是 N L B提供了对网上每台计算机的优秀的管理能力。一旦在主机上安装了这个软件，就可以在集群中远程控制主机的加入、移去和配置。
818计计 ASP 3 高级编程 下载第 27章 建立多服务器网站 计计 819下载
4,网络负载平衡小结简而言之，一个 N L B：
通过并行过滤处理，给多个服务器分配负载。
通过系统级负载观测，决定请求的分配。
通过广播“心跳”消息，实现的容错。
要求在每个服务器上安装和配置附加的软件和可选的附加硬件。
有强大的远程管理能力。
是一个廉价的提供负载平衡和容错的解决方案。
27.2.4 复合方式对于负载平衡的另一个可行方案就是硬件与软件技术结合的复合方式。网络配置如图 2 7 - 8
所示。
图 27-8 复合方式的网络配置图 2 7 - 8中有一套硬件负载平衡器和两个服务器集群，每一个集群都使用 N L B来实行负载平衡以及容错。硬件负载平衡器不关心这两个 I P地址与其对应的集群中的服务器地址的变换关系。同样，每个 We b阵也不关心其他 We b阵的存在。
网络服务器集群 IP
特定 IP
交换机 网络硬件负载平衡器集群 IP
热备用网络服务器特定 IP
交换机 网络
Internet
1,负载平衡对于负载平衡，现在服务器可以超过 N L B限制的 3 2个服务器。实际上，如果假设硬件负载平衡器能够在 2 5 6个节点上分配负载（一个完全合理的假设）,就能扩展站点达到不可想象的 8 1 9 2个服务器。
现在可以从网络监控和系统监控两个方面来决定负载分配。形成瓶颈的主要因素可能是网络的状况，而不是系统的处理能力。在这样的方案中，允许在硬件负载平衡器（网络）与使用 N L B的服务器集群（系统）之间协调负载平衡的负担。
2,容错由于增加了硬件负载平衡器，管理容错时有了更多的选择。现在完全能够将 We b阵在网络以及地理位置的意义上相互隔离。复合方式提供了额外的措施来对付环境方面的问题（如洪水、火灾等） 。也提供了最有力的措施去保护所有的服务器以避免危及其安全。后面将进一步地讨论安全问题，但是 N L B最难处理的安全隐患之一是集群中的所有机器彼此之间要保持不间断的通信。
3,管理正如在前面所提到的，硬件负载平衡解决方案并不大量增加管理量。因此，实现和维护一种复合方式负载平衡并不比实现一个 N L B解决方案困难。
4,复合方式小结总之，复合方式解决方案：
将硬件与软件负载平衡的方案相结合。通过 T C P / I P流转换到集群的 I P地址，将负载分配到多个 We b阵中。在服务器集群中通过并行过滤过程管理负载。
通过对网络流的观察和在每个服务器集群中对系统级负载的观察决定请求的分配。
通过监控集群的响应和可用性处理容错。在各集群内，通过广播的“心跳”消息处理容错。
要求在每一个服务器上安装与配置额外的软件及可选的额外硬件。
是提供容错与负载平衡的最贵的解决方案。
27.2.5 High Availability Clustering Service
微软首先推出的集群技术是 1 9 9 7年 1 0月发布的 Windows NT 4.0 Enterprise Edition中的
Microsoft Clustering Service（ M C C S） 。微软公司已经增强了 Windows 2000上的集群能力，并把这项服务更名为 High Availability Clustering Service（ H A C S） 。目前它不是一种负载平衡方法，而是改进可用性与容错的一种措施。
集群服务提供了两种防止像 SQL Server数据库这样的重要应用程序失败的方法。这不同于通过多网络服务器集群提供负载平衡的 N L B系统。看一下图 2 7 - 9所示的硬件负载平衡网络配置。
图 2 7 - 9是我们熟悉的由两个网络服务器处理来自于 I n t e r n e t或者其他网络的流的情况，在其中使用硬件负载平衡的方法实现负载平衡和容错。但是，这种方法仍有单一失败点。如果数据库服务器失灵了，来自于网络服务器的涉及数据库的请求（可能是大量的）将会全部失败。这就是微软的集群服务要解决的问题。考虑一下图 2 7 - 1 0所示的另一个利用集群的网络配置。
820计计 ASP 3 高级编程 下载第 27章 建立多服务器网站 计计 821下载图 27-9 硬件负载平衡网络配置图 27-10 利用集群的另一个网络配置图 2 7 - 1 0中的配置已经消除了单一失败点，现在有两个数据库服务器作为一个虚拟服务器。
这种集群技术对于每一个服务器要求有一个额外的 N I C，在这些 N I C之间形成一个专用网络，
而且要求有一个共享 S C S I总线（至少有一个磁盘） 。此外，这个共享的 S C S I磁盘阵列必须仅用于集群应用程序和其他资源，而系统文件必须单独放在一个独立的用于集群的服务器的
S C S I总线上。
1,负载平衡当前的微软集群技术并不支持负载平衡。微软说目前的集群解决方案是它的集群策略的第一阶段，第一阶段表现为给共享一套数据的两个节点提供故障屏蔽（ f a i l o v e r）功能的能力，
第 2阶段将通过允许最多 1 6个服务器实时共享数据、执行负载平衡以及提供对故障屏幕的支持来合并负载平衡和故障屏幕技术。
2,容错你会注意到集群中两个节点共享一个专用网络。所有与每台机器的“健康”相关的信息以“心跳”消息的形式在这个网络中传播。每一个服务器都有一个称为集群服务的软件组件，
用于监控系统的状态，并把这个信息传送到另一个节点的相应部位。集群准备（ c l u s t e r- r e a d y）
网络服务器硬件负载平衡器数据库服务器热备用集群的数据库服务器网络服务器硬件负载平衡器热备用专用网络
SCSI
Raid
阵列
Internet
Internet
应用程序将数据贮存在共享的 S C S I磁盘阵列上。如果一个应用程序失败，则另一个节点就启动这个应用程序，从磁盘阵列中恢复应用程序的状态，并继续服务于请求。
微软的集群技术对于网络应用程序的可用性提供了基本的保障：状态数据的容错。在多服务器站点上的网络服务器一般不局部地保持状态（在下一节讨论状态） 。这使得重新安排用户的请求到一个可用的服务器变得简单。另一方面，数据库负责管理对象的状态，这就是其目的。为了提供容错，对于高度可用的系统，其数据库服务器必需具有实时管理状态的故障屏蔽能力。
对于集群的唯一替代方案是镜像有故障屏蔽能力的数据库。但镜像数据库不能提供实时的数据同步，因此，一个系统瘫痪将可能导致数据丢失。应当注意到，集群服务能提供对许多资源的容错，而不仅仅是对数据库。这些资源包括文件共享、活动目录服务和一些指定的
D H C P信息。
3,管理
High Arailability Clustering Service 需要严格的硬件和精确的系统配置，因此这种解决方案的管理相对于前面讲过的任何一种负载平衡方案而言，考虑的问题要多。应当注意到集群解决方案通常涉及到大量的新硬件，这会产生额外花费。
4,High Arailability Clustering Service 小结总之,High Arailability Clustering Service 方案：
目前不提供负载平衡。
通过监控集群的响应和可用性处理容错。在各个集群内通过广播的“心跳”消息处理容错。捕获的状态信息被放置在共享的 S C S I磁盘阵列上。
要求每一个服务器都有固定的配置和附加的硬件。
是唯一可对状态数据进行实时恢复的方案。
27.2.6 COM＋ Dynamic Load Balancing
在前面，我们为负载平衡和容错而增加了额外的服务器，增加的服务器放在表现层（网络服务器）和数据库层。正如在第 1 3章所描述的，一个普通的应用程序结构如图 2 7 - 11所示，
还包括另一个组件层，即业务逻辑层。
图 2 7 - 11 应用程序的基本结构
822计计 ASP 3 高级编程 下载表现层 业务逻辑层 数据库层第 27章 建立多服务器网站 计计 823下载表现层包括网络服务器和一系列的 A S P文档。嵌入到 A S P文档中的服务器端脚本实例化一个 C O M＋组件，这个组件对某些业务逻辑和数据库访问的细节进行抽象，并通常在网络服务器上实例化。如果 C O M＋提供了本地 /远程的透明性，应将业务逻辑组件分离到一个独立的服务器上。
网络配置的结果如图 2 7 - 1 2所示。
图 27-12 采用分离的业务逻辑组件的负载平衡网络配置现在已把业务逻辑组件的处理负载分配到另一个服务器上，使网络服务器有更多的时间和资源来处理 H T T P请求。但是，现在又重新引入了一个单一失败点。如果业务逻辑服务器停机，负载平衡器仍然会将 H T T P请求发送到网络服务器，但是网络服务器将无法满足这些请求。
对于将业务层从表现层划分出来，安装在另一台机器上,C O M＋ Dynamic Load
B a l a n c i n g。这种能力原来是 Window 2000 Advanced Server的一个功能，在本书编写时，它随着 Windows 2000 AppCenter Server一同发布。图 2 7 - 1 3所示就是 C O M＋ Dynamic Load
B a l a n c i n g的一个简单实现。
图 27-13 使用 C O M＋ Dynamic Load Balancing的网络配置一个额外的服务器已经被添加到结构中，即组件负载平衡路由器。这个服务器（通过集群服务提供容错和高可用性）接收来自网络服务器的请求，并把这些请求安排到业务逻辑服务器阵中。请求的安排根据每个应用程序服务器的处理负载而定。开始时，业务逻辑服务器阵可以支持最多 8个服务器。
网络服务器数据库服务器热备用硬件负载平衡器业务逻辑服务器硬件负载平衡器热备用网络服务器 业务逻辑 服务器 数据库服务器组件负载平衡 路由器
Internet
Internet
27.3 状态管理到现在为止，已经讨论了一个多服务器网站的概念，而且研究了一系列分配 H T T P请求到
We b阵的方法。但是，分配请求只是任务的一部分，还必须研究状态管理。
H T T P协议原本是一种无状态协议。根据其本质，在 H T T P请求之间服务器不应该有状态这个概念。 A S P处理这个问题时几乎都是使用 S e s s i o n对象，但 S e s s i o n对象是“指定机器的” 。
有几个方法可以解决这个问题，其中包括避免使用状态、使用客户端的 c o o k i e代替状态、利用亲和性（ a ff i n i t y）来允许使用 S e s s i o n对象以及串行化状态数据并存入通用存储器中。
27.3.1 不管理状态不是所有的网络应用程序都需要管理页面与页面之间的状态。如果一开始时就能避免管理状态，就能为自己减少很多麻烦。很明显这并不是令人满意的答案，但却是不可忽略的。
状态管理增加了网络应用程序的复杂性，因此，能避免它是件好事。
27.3.2 客户端存储就像第 2章介绍的 R e s p o n s e和 R e q u e s t对象允许在客户机上存储和获取 c o o k i e。状态也可以在隐藏的窗体中存储，窗体在页面之间通过提交传递。在这种情况下，客户端存储是较好的方法，这把管理数据的任务从服务器上完全移走。若数据存储在服务器上，随着用户数量的增加，存储在服务器上的数据将影响服务器性能。举个例子，如果每个浏览网站的用户存储 4 K B有价值的信息，而同时有 1 0 0 0 0个用户的活动会话，系统必须拿出 4 0 M B的内存空间来存储这些不经常访问的数据。将这些信息存储到每个客户端，能有效地改善系统的性能。
另一方面,c o o k i e信息随同每个 H T T P请求一起传送。因此，客户端存储的方法增加了网络传输量，增加了传输时间，不如在服务器端管理状态数据安全，而且对存储到客户端的数据量有限制（依赖于浏览器）,用户随时可能删除 c o o k i e，而且 c o o k i e信息只能为特定机器上的用户服务。
27.3.3 亲和性如果想利用会话变量并使用多服务器网站，可以使用一个扩展的方法，允许“会话亲和性（ session aff i n i t y）,。,亲和性”是指网络浏览需要与单个服务器相关联，而且返回每一个后续的请求到这个服务器。一个浏览器首先连接到 We b阵中的某个的服务器上。从此开始，
在这个用户会话期间，所有后续的请求将安排到同一服务器上。如果在应用程序中使用
S e s s i o n对象，这是必需的。
硬件员载平衡器和 N L B解决方案都能在确定由哪一个服务器响应某个用户时，提供这种亲和性。然而，亲和性的使用部分抵消了使用这些方案而得到的负载平衡效果。负载平衡方案是在接收到请求时，根据各个服务器的负载情况，将请求分配到某个服务器上。在会话的存活期，服务器的负载特征可能会发生很大的变化。看一下下面这个例子，如图 2 7 -
1 4所示。
为了简单，图 2 7 - 1 4中省略了所有连网和负载平衡设备。
824计计 ASP 3 高级编程 下载图 27-14 利用亲和性的网络配置假设有 4个用户（ A ~ D）连接到网站，他们的请求平均分配给两个网络服务器。现在假设用户 C和用户 D立即断开连接，用户 A和用户 B长时间连接并执行许多复杂的运算。如果我们使用了“亲和性”,所有的来自于用户 A和用户 B的 H T T P请求将安排到网络服务器 A上，用户
A和用户 B将会看到服务器 A超载，而服务器 B却闲置着。
使用“亲和性”的另一个问题是容错。网络应用程序的容错目标是完全恢复任何单个的故障。如果严格限制一个用户只能连接到单个服务器，就将失去拥有冗余机器的好处。考虑与上面相同的情况，如果网络服务器 A瘫痪，用户 A和用户 B正在使用的所有事务数据和状态数据将丢失。
最后，即使你愿意牺牲性能和容错（这是 We b阵的两个主要目的）以便使用 S e s s i o n对象，
“亲和性”也不能在所有情况下工作。请看图 2 7 - 1 5所示的例子。
图 27-15 使用代理服务器的网络配置用户 A所在的网络有几个代理服务器平衡负载。当用户 A通过浏览器发出 H T T P请求时，
第 27章 建立多服务器网站 计计 825下载用户 A
用户 B
用户 C
用户 D
网络服务器 A
网络服务器 B
数据库服务器用户 A
负载平衡器代理服务器 A
代理服务器 B 网络服务器 B
网络服务器 A
数据库服务器浏览器就会将这个请求传递给代理服务器。在本例中，有两个代理服务器。由于本例使用单个机器的“亲和性”,每个来自代理服务器 A的请求被安排到同一个网络服务器，即网络服务器 A。所有通过代理服务器 B的请求被安排到网络服务器 B。尽管是单个用户访问我们的网络，
但我们的系统认为这些请求来自两个用户并用两个网络服务器来分担负载，这将导致试图访问会话数据时出现意想不到的情况。
大部分负载平衡硬件及 N L B都有解决这个问题的方案。它们允许“亲和性”针对于一个完整的 C类地址空间（ 2 5 6个唯一的 I P地址） 。其基本原理是大部分代理服务器集群应在同一个地址空间内。 C类地址“亲和力”会对员载平衡效率产生巨大的不利影响，因为它们一大批用户（而不是一个用户）绑定到一台服务器。对于大的用户组，代理服务器经常用于帮助传输或者缓存 H T T P流。美国在线（ A O L）就是这样一个用户组。当使用 C类“亲和性”时，就必须冒着突然关闭一个服务器，同时使一大批用户不能获得服务的风险。
27.3.4 在一个中心服务器上存储状态存储状态的首选方式是存储在一个中心服务器上。为了达到容错的目的，中心服务器通常是集群的两个服务器。当用户首次访问站点时，由一个定制的服务器端组件生成一个会话
I D，并且存储在浏览器中。用户会话期间的后续 H T T P请求都包含这个会话 I D。会话 I D作为键与一个文本字符串一起存储到数据库表中，通过这个缓存文本字符串可以存储和检索二进制大对象（ B L O B） 。尽管有这样的名称,B L O B S其实没有那么大。每个具有状态信息的 A S P
组件具有将自己写入这个缓存表中并从中读出的能力。
微软提供了一个解决扩展网络时出现的状态问题的很好方案。进一步而言，我们将尽力提供一种可持久的、机器独立的状态跟踪机制。现在已经有一种比较容易的方式。
Commerce Server（早期的 Site Server,Commerce Edition）的再利用。 Commerce Server提供的个人化服务能准确地解决这个问题。这些个人化服务将被写入数据库，但是这一麻烦的过程将会通过一组封装对象隐藏起来。此外，个人化及成员关系的管理由一个 M M C插件实现，
很容易使用。
但是,Commerce Server的解决方案也存在问题。 Commerce Server需要 8 0 0 M B的硬盘空间和许多你不需要或不用的东西。不幸地是除了全部装上别无选择。此外，对于个人化数据的访问是通过 L D A P连接进行的，这种连接比通过 A D O和编译的定制组件直接连到数据库上要慢得多。
27.4 安全在访问多服务器时必须解决的另一个问题就是安全。对于向 I n t e r n e t开放的多服务器网站，
正确的安全管理是一个要用一整本书来讨论的课题，我们仅用一节。这一节的目的是接触与多服务器站点安全相关的两个关键问题。我们将讨论一些用户管理的方式和当使用 N L B服务来平衡负载时在某些领域存在的潜在危险。
1,用户管理跟踪和控制用户访问的最简单的方式是通过本地的用户注册表。验证和用户管理利用
Wi n d o w s的管理工具进行处理。
本地的用户注册表对于多服务器网站来说是不够的。如果网站允许用户在任何地点登录，
826计计 ASP 3 高级编程 下载对于多服务器网站必然会带来问题。对于一个多服务器网站，有两个地方可存储用户的证书：
针对特定域的 Windows 用户注册表。
译成密码存储在一个中心数据存储中。
(1) Wi n d o w s用户注册表初看上去,N T域的用户注册表好象是理想的存储用户帐号信息的地方。验证是简单的。
用户的口令是自动地管理和存储的，不必为加密担心。
但是有一个问题：用户注册表也用于允许和禁止对系统上所有资源的访问。这意味着在系统内的每一个用户都有一个访问这个域内的所有机器的帐号，负责管理这些帐号的人有责任确保这些帐号的权限是合适。
此外，在 We b阵中的所有机器都必需是一个域内的成员。最低程度上，应当保证生产性机器在单独的、隔离的域中运行。即使这样，也可以从这个域内的一台机器上对所有服务器资源进行访问。安全系统的一个目标就是，任何机器在安全性受损害时都应该不影响这个站点内的其他机器。
(2) 中心数据存储另一种首选的存储域内用户信息的方式就是将用户的信息存储在数据库中。在 A S P页面或者 I S A P过滤器中检查用户信息非常简单，依据数据库进行验证也是一项相当轻松的任务。
这不需要依靠各种各样网络服务器之间的连接。也能够减少由于管理失误或者更糟的情况导致安全性下降的可能性，更糟的情况就是本被允许访问这个网站的用户进入网络应用程序中。
不过这比那些由于人们的失误而使某人在域内拥有最高特权的情况好得多。
另一个在数据库中存储口令信息的问题是，任何能对数据库进行读查询访问的人都能够检索出用户的口令。对于这个问题，最显而易见的解决方式就是，利用一种商业加密技术保证口令以不可用的形式存储。
我们又一次面对着与状态管理相同的难题。对于用户管理和验证有一个很好的解决方案。
用数据库加密实现我们自己的验证机制看起来有点难，但已有一个比较简单的方式。
还是用 Commerce Server。 Commerce Server提供用户管理功能，并允许网站的验证绑定到 Commerce Server的用户数据库。正如前面提到的,Commerce Server安装量巨大，并且依赖于 L D A P访问用户的数据。这比直接的数据库访问要慢的多。但是，它正好为这个问题提供了一种方便的解决方案。
2,负载平衡最后，让我们简单地对 N L B服务的安全性做出一个结论。 N L B服务通过在集群服务器中进行持续通信来管理负载平衡。这意味着某台机器的安全性受损害时，可能对整个 We b阵的安全产生不利影响。然而这并不是一种非常槽的情况，在任何时间都有很多机器在它们之间传递信息并使用这些信息调节系统的行为与操作，这涉及有限的风险。
27.5 小结本章介绍了多服务器网站的概念。将网络应用程序从单一的服务器上扩展到多服务器上的目的是：
增加站点的吞吐量和性能。
提供冗余和容错能力。
第 27章 建立多服务器网站 计计 827下载
增加站点的可用性。
我们介绍了许多实现多服务器站点的模式，阐述了每一种模式的优点和缺点。在本章的最后，简短分析了一个多服务器网站的状态管理和安全性。
建立一个稳固的可扩展的（即能够处理大量用户的）网站是一个深奥的课题。建立一个多服务器的网站增加了开发和测试的复杂性和难度。必须及时解决网络的状态与安全问题。
如果需要处理大量的用户或者需要提供高的可用性，那么从一开始建立系统时就要考虑系统的容量，这样会使问题变得更加简单。
828计计 ASP 3 高级编程 下载
