参考文稿分析

第27 建立多服务器本书的绝大部分是围绕着在单一服务器上的Wb应用程序的开发与优化，而多服务器的开发与优化同单一服务器上的情形有细微的差别。本章重点研究多服务器以及它们的工作方式。多服务器的定义，以及何时或者是否应当建立一个多服务器首先让我们看一下一个多服务器的构成。网络服务 数据库服务图27-1最典型的有一个单一的响应HTTP请求的网络服务器，这个服务器可能使用网络服务 数据库服务图27-1，。，。在各种各样的算法中清理出过于臃肿的内容网络服务器也可以通过增加CPU、额外的和更快的硬盘驱动器增强其性能。然而，最终可能无法再通过改进系统的性能使其达到可接受的水平。对于Internet应用程序，这种情况早已出现。改善系统性能的一种显而易见的方式就是通过多网络服务器分散或平衡负载。即使的用户数量不多，对于单个服务器配置，也存在一些其他的潜在问题。每一个IT经理的一个基本假设就是任何机器都会失败，如果这个失败的机器作为网络服务器，则用户无论如何也不能进入这个。对于商业站点来说这将带来许多麻烦。考虑一个经纪人例子，如果一个经纪人不能被，这个经纪人的顾客可能在等待恢复的时候损失大量的。此外，需要注意的是，也是管理生产环境时不可缺少的部分。有一些常规的安全性公告要求应用程序热修补和对系统或系统软件的服务补丁。这可能需要替换硬件。当仅有一个服务器时，即使是最一般的改变，也要将整个停下来。这将导致数小时的维修以及IT职员的抱怨。最后还有一个内容升级的问题。网络应用程序的发展趋向于不断改变的内容。在一个独立的服务器上展示新的内容或让内部用户验证的正确性是一个极好的方法。这样能避免许多令人烦恼的问题和咨询。图27-2展示了多服务器的配置网络服网络服数据库网络服网络服数据库网络服网络服围内，任何一部分出现故障将不影响的。此外，网络服务器多于数据库服务器个障（failover）配置，其原因是备用机。器了失败的现象在用户面前出现。总而言之，使用Web

图27- 多服务器的配Web阵是否是一件好事。当讨论多网络服务器的运行优点时，同样也需要讨论它的不足之处。明显的缺点是增加了系统的复杂性，当请求通过多服务器时，需要某些模式来分配请求给这些服务器。最具有代表性的是需要增加网络硬件或软件组件。这不仅增加了相关的开发和管理工作，而且也增加了测试工作。为了确定系统按希望工作，必须测试系统的冗余、负载平衡和故障屏障等各个方面。另一个缺点是这种变化可能影响系统结构，将在后面讨论这些问题。状态管理、用户管理和资源管理等模式，移植到多服务器系统时需要进行改变。一种简单的例子是管理上传的文件，如果这些文件当前是放在本地的 结构中，需要修改系统使其指向中心的共享 最后，当将原来使用一台机器的改为使用多台机器时，要增加管理的费用。IT需要对多台机器进行追踪，每台机器的配置。内容、代码、热修补、补丁等等必须写入到每台服务器。尽管冗余使得管理能在运行期间执行，但是冗余和容错不能免除管理员的责任。此外，测试环境必须（最大程度地）反映工作环境，也就是要测试机器。不要轻视这些缺点的影响。快速交付软件的能力是Internet商务的强大竞争优势。建立一个Web阵，同单个服务器相比，将会花费大量、较长的时间（对于第一次而言）和较高的经常性费用。如果站点的用户有限，没有重要的使命，能够承担由于例行维修和预料不到的误起的关所生的，么就尽能免建立个eb阵。但是，如果正在开发一个网络应用程序，而且将来可能面对大量的用户，最好考虑周到一些。一旦应用程序运行于多服务器配置（尽管实际上没有多个服务器，那么增加附加的资源来应付负载增大的问题就非常容易。如果开始没有这样做，扩展服务器的工作会变慢（潜在有阻塞，根据的条件，可能会是几天或者几周而不是几小时。上面讨论了Web阵的优点和缺点，就让我们看一下一个WebWeb阵是如何工作的？考虑一个HTTP请求的处理过程，如图27-3用用浏览DNS服务网络服输入匹配URL到 建立连 连接已建 发送HTTP请 接收页 图27- 一个HTTP请求的处理过用户将URL输入浏览器，在浏览器向服务器发送TCP/TP请求之前，浏览器需要知道的IP地址。浏览器根据用户输入的主机名通过询问系统（DNS）服务器来查寻相应的IPDNS服务器包含主机名/IPDNS服务器上，则服务器就会向第二个DNS服务器询问。最终，这个询问将被发送到主机网络的DNS服务器，这个DNSIPDNS服务器，由这个服务器把数据返回浏览器。应当注意的是，实际上DNS服务器的操作要比这里简单解释的复杂得多，关于在Internet上使用系统的详细描述超出了本书的范围。一旦浏览器有了IP机址，就会开始连接，在状态栏将会看到如“ConnectingtositeHTTP请求，服务器分析这些当涉及到单个的服务器时，总是由同样的机器响应HTTP请求。所有负载平衡模式都涉及到可能把后续的HTTP请求安排到不同的服务器这一问题，这会使状态管理变得。 循环复用法：使用DNS服务器平衡负载微软的TCP/IPNetworkLoadBalancing逐个讨论这些解决方案，说明它们是如何工作的，分析一下它们在负载平衡与容错方面的性能。同时也将系统中的相关变化，例如对服务器的影响。最后还将简单地介绍一些相关的技术，例如微软的HighAvailability 以及＋DynamicLoadBalancing。DNS循环复DNS循环复用法（DNSRoundRobin）是将HTTP请求安排到多个服务器上的简单方法。如前所述，一个DNS服务器保持着位于某个特定域内的每台机器的主机名/IP地址对的集合，其每个xxx代表0~255的数（这里没有给出实际的数字，以避免由于无意而涉及任何人的服务器。当建立一个DNS服务器时（微软的Windows2000AdvancedServer中包含DNS服务），为每个附加的机器创建一个额外的IP条目（在DNS中称为记录或地址记录），这个结果列表与下当响应DNS，DNS服务器将循环使用表中所有记录。这样，在上面的例子中，对于第一个解析 ，DNS服务器将会返回xxx.xxx.xxx.3，对于下一个解析，DNS服务器将会返回xxx.xxx.xxx.4，等等。结果所有的请求被分配到所有的网络服务器上。HTTP请求被平衡到一系列网络服务器上，但是只是在每一个服务器收到相同数量的请求这一个方面达到了平衡。这是假设所有的服务器具有相同的资源（一种可行的假设有的事务处理都要求相同数量的系统资源（这是一种没有意义的假设。这种解决方案根本没有注意到当前eb阵中机器上的处理器负载。当负载分配达到某种程度时，这是一种效率极Web阵为例，如图27-4服务器数据库服务器图27-4两个网络服务器组成的Web如果由于服务器A响应HTTP请求而使它的处理器利用率饱和（100%，而服务器B的处理器利用率很低（10%~15%，DNSHTTPA，而此时服务器A已经过载了，这不仅效果很差而且会导致用户在看到站点的执行缓慢时去点击在浏览器上的Refresh按钮。这不仅是极坏的尝试，而且会使请求队列变长，直到浏览器上出现“Servertoobusy对于DNS循环复用法，另一个缺点是不能很好地处理系统的运行中断。仍以两个服务器组成的eb阵为例。如果服务器A，则所有HTTP请求的一半被安排到一台无效的服务器上，结果就会是在用户的浏览器上显示“ServerUnavailable”消息。可以停下来维修机器，但需要更新DNSDNS服务器缓存了主机名/IP地址对信息，可能在几天内都不更新。DNS循环复用法是一个管理者的梦想。管理DNS记录很容易，而且DNS循环复总之，DNS循环复用法比DNS循环复用法能力更强是硬件负载平衡。图27-5就是一种网络配置的示意图有一种新的硬件，即硬件负载平衡器，其位于网络服务器和其他网络设备（、路由器等）URL的用户请求被安排到负载平衡器，连接到负载平衡器上的接收到的发送到集群的TCP/IP包，负载平衡器执行如下动作网网络服热备集硬件负载平衡图27-5决定集群中哪一个服务器将接受下一个TCP/IP请求检查服务器和应用程序 TCP/IP端口）的可用性在有些情况下，检查由服务器返回的数据的有效性。当服务器作出响应时，这是非常方HTTPError404转换I 报头，以便包能指向选中的服务器，这项转化技术通常称为网络地址转（NTNAT的结果使得客户接收到的TCP/IP包看起来就是来自代表此集群的IP负载平衡器如何决定由哪一个服务器响应发送来的请求呢？这因厂商不同而不同，但最基本的算法是相同的。负载平衡器通过监视网络活动性，了大量的信息。这些活动性包括进入和来自各个服务器的信息传输量、各个服务器响应TCP/IP请求的速度、每个服务器目前连接的用户数量以及每个服务器对负载的反应的历史情况。负载平衡器为系统管理员提供了一种基于网络流量的算法，而且这种算法一般包括循环复用法和比率（循环复用法）算法。负载平衡器通过网络流量，能够智能地有效分配处理负载到多个服务器上，再看一下上面DNS27-6如果由于服务器A响应HTTP请求，使其处理器利用率饱和（100%，而服务器B的处理器利用率很低（如10%~15%A的响应很慢，它将安排后续的请求到服务器B。这将持续到在网络服务器A上的负载回到一个可以接受的水平。其结果比使再以两个服务器的Web阵为例。如果服务器A停机，硬件负载平衡器将不发送任何TCP/IP流到服务器AWeb服务不能进行响应，负载平衡器就会将服务器A从可用的服务器的上去掉，并将所有的流传送给服务器B，这也比使用DNS循环复用法的效果

硬件负载平衡热备

服务器服务器

数据库图27-6由两个网络服务器组成的硬件负载平衡Web关于硬件负载平衡方案还有一点应当注意：负载平衡器本身成为故障的中心点。为了解决这一点，典型的方案应包括第二个负载平衡器作为热备用，这种冗余故障配置是相当RS-232电缆这样的串行通信介质连接，每个单元都有“看门狗”处理器不断地彼此交流。在某个单元失败或不正常时，“看门狗”单元协商并决定由哪一个单元完成负载平衡。通常，硬件负载平衡器是产品质量部件，其一般特性包括将单个IP地址或介一个完整的C类地址空间与单个服务器关联起来的能力、、基于网络的管理能力、在服务器故障的情况下能力、实时的监视性能和统计信息的能力。如果对硬件负载平衡系统感的话，Cabletron公司()和CiscoSystems公司（ DNS循环复用法的管理复杂得多，但是不必畏惧。建立负载平衡器并不比建立一个典型的路由器（实际上，这些装置基本上都是路由器的形式，且你的网络管理员对于路由器的技术应该很了解。对于网络负载平衡模式的管理是相当集中的，而且不影响服务器机器本身。这在负责建立并服务器的管理员眼中就是一个巨大的成功。对于硬件负载平衡解决方案的实际能力有一些局限，最大的局限是带宽。由于在进入和输出的过程中都要将TCP/IP报头转变为一个新的IP地址，通过负载平衡器的，带宽往往被限制在45～50Mbps。这对于一般数据而言是一个巨大的带宽，大的站点在其使用期能够超过这种能力，额外的信息包被丢弃了。显而易见，这不是最优化的，而且对于大部分也是不可行的。硬件负载平衡解决方案的另一不足之处就是费用太高。写本书时，使用一对硬件负载平在20000以上，并且在继续上涨。这就意味着必须在负载平衡器上花的钱而不是在额外的服务器上。最后，基于硬件的负载平衡算法必须建立在来自于网络流量的可观测数据的基础上，对HTTP请求包含要花费大量时间的数据库操作，但并没有阻塞网络服务。在这种情况下，硬件负载平衡器会认为服务器很忙，但实际上这时服务器是可用的资源。尽管有这些不足之处，但硬件负载平衡对于完成一个的负载平衡有着不容置疑的可靠性与实用性。通过将进入和输出的TCP/IP流转换为服务器集群内的IP地址，将负载分配到多个服务器上。根据观察服务器集群内的网络流情况，决定请求如何分配。这从负载平衡的意义上看是高效的，但是在服务器资源方面，例如CPU的利用率、HTTP请求的队列长度和线程数量等等，不一定高效。每一个服务器和每一个应用程序的可用性。负载平衡器在将包送到服务器之前检查可用性。TCP/IPNetworkLoad微软开发了一个软件组件，称为NetworkLoadBalancing（NLB，是作为Windows2000AdvancedServer的一部分提供的。NLB首次于1997年10月以WindowsLoadBalancingSerrice（WLBS）这个名字作为WindowsNT4.0的一种插件发布，一个使用NLB的网络配置示例如图集群集群NIC驱动程指定服务器的集群NIC驱动程指定服务器的NLB服 NLB服TCP/IPTCP/IPTCP/IPTCP/IPTCP/IPTCP/IP单NIC配双NIC配图27- 你会发现NLB所需要的配置不同于标准的网络配置，也会发现来自于Internet的流在一个 IP地址是集群的IP地址，应当代表网站服务器的URL。每一个服务器还有一个唯一的IP地址用于非集群传输。图27-7也暗示了对于每一台服务器存着两个相互独立的网络连接。NLB不要求这样做，它可以一块网络接口卡（NetworkInterfaceCard，NIC）上工作，这样不影响服务器的硬件。但是，大多数情况应该每台服务器的配置是很简单的。一旦安装了NLBIP地址、一个唯一的主机ID（1~32，一个NLB实现被限制在最多有32个服务器、权重（因为并不是所有系统都有同样的容量）和一系列规则。每一项规则决定了哪一个TCP/IP应用程序要进行负载平衡及其亲和性（个IP或者C类，下面很快将讨论这个问题。对于基于网络的流80端口（标准的HTTP端口）没有亲和性。你可能会有这样的疑问，最多可以有32个服务器收到同一IP地址的信息包，为什么客户端没有收到32个响应呢？在于微软称之为的“并行过滤”的东西。当安装了NLB务以TCP/IP栈与NIC驱动程序之间，所有传输到指定服务器的流直接通过，对于指向集群的IPNLB软件决定由哪个主机处理请求，这个服务器让流通过它的集群NICIP请求，所以只有被指定的服务器响应这个请求。NLBTCP/IP请求应该由哪个主机响应。这种算法使用的负载信息是通过各主机收集并通过广播向外共享的。由于这是一个软件工具，因此这个负载信息包括CPU的利用率、可使用的内存和其他情况的详细内容。通过监测网络流，它可以提供一种更精确有效的负载平衡。因为这仅涉及过滤包而不涉及数据包的修改和再发送，所以NLB不用面对硬件负载平衡模式中的那种吞吐量限制问题。前面已经NLB仅需一个NIC，然而，用两个NIC是一个好主意。图27-7展示了两个可能方案。当用一个NIC时，所有TCP/IP流都通过NLB服务。另外，非集群流和集群流通过同样的NIC，宽带和处理时间被非集群流和集群流。增加另一块N把集群流与指定服务器的流分离，允许管理流和其他指定服务器的流直接进入服务器，从而使它们对集群的吞吐量影响最小。NLB主机以一定周期交换广播消息，使它们能监视集群的状态。当一个主机进入或离开NLB软件开始一个称作“集中（convergence”的处理。在集中期间，主机确定新的10秒钟。NLB流的一部分是每个主机都参与的“心跳（heartbeat”消息，心跳消息的周期是可以配置的，缺省周期为一秒。如果主机在5个心跳消息周期内还没参与服务（或服务失败），则和前面讨论的解决方案不同，NLB影响每台服务器。它的实现涉及到每台服务器上的软件安装和配置，以及安装附加的NIC（还有集线器或交换机端口、电缆接头等。另外，根据好消息是NLB提供了对网上每台计算机的优秀的管理能力。一旦在主机上安装了这个软件，就可以在集群中控制主机的加入、移去和配置。简而言之，一个有强大的管理能力对于负载平衡的另一个可行方案就是硬件与软件技术结合的复合方式。网络配置如图27- 交换网硬件负载网络服务 集群热备特定交换网图27-8图27-8中有一套硬件负载平衡器和两个服务器集群，每一个集群都使用NLB来实行负载平衡以及容错。硬件负载平衡器不关心这两个IP地址与其对应的集群中的服务器地址的变换关系。对于负载平衡，现在服务器可以超过NLB限制的32个服务器。实际上，如果假设硬件负载平衡器能够在256个节点上分配负载（一个完全合理的假设，就能扩展站点达到不可想象的8192现在可以从网络和系统两个方面来决定负载分配。形成瓶颈的主要因素可能是网络的状况，而不是系统的处理能力。在这样的方案中，允许在硬件负载平衡器（网络）与使用NLB的服务器集群（系统）之间协调负载平衡的负担。由于增加了硬件负载平衡器，管理容错时有了的选择。现在完全能够将eb阵在络以及地理位置的意义上相互。复合方式提供了额外的措施来对付环境方面的问题（如洪水、火灾等。也提供了最有力的措施去保护所有的服务器以避免危及其安全。后面将进一NLB最难处理的安全隐患之一是集群中的所有机器彼此之间要保持不间断的通信。正如面所提到的，硬件负载平衡解决方案并不大量增加管理量。因此，实现和一种复合方式负载平衡并不比实现一个NLB解决方案。TCP/IP流转换到集群的IP地址，将负载分配通过集群的响应和可用性处理容错。在各集群内，通过广播的“心跳”消息处理容HighAvailabilityClustering微软首先推出的集群技术是1997年10月发布的WindowsNT4.0EnterpriseEdition中的ClusteringService（MCCS。微软公司已经增强了Windows2000把这项服务更名为HighAvailabilityClusteringService（HACS。目前它不是一种负载平衡方集群服务提供了两种防止像SQLServer数据库这样的重要应用程序失败的方法。这不同于通过多网络服务器集群提供负载平衡的NLB系统。看一下图27-9所示的硬件负载平衡网络图27-9是我们熟悉的由两个网络服务器处理来自于Internet或者其他网络的流的情况，在其中使用硬件负载平衡的方法实现负载平衡和容错。但是，这种方法仍有单一失败点。如果数据库服务器失灵了，来自于网络服务器的涉及数据库的请求（可能是大量的）将会全部失败。这就是微软的集群服务要解决的问题。考虑一下图27-1所示的另一个利用集群的网络配置。 热备 图27- 网络网热备阵硬件负载平衡集群的数据库服图27- 图27-10中的配置已经消除了单一失败点，现在有两个数据库服务器作为一个虚拟服务器。这种集群技术对于每一个服务器要求有一个额外的NIC，在这些NIC之间形成一个网络，SCSI总线（至少有一个磁盘SCSI磁盘阵列必须仅用于集群应用程序和其他资源，而系统文件必须单独放在一个独立的用于集群的服务器的SCSI当前的微软集群技术并不支持负载平衡。微软说目前的集群解决方案是它的集群策略的第一阶段，第一阶段表现为给共套数据的两个节点提供故障（failover）功能的能力，第2阶段将通过允许最多16个服务器实时共享数据、执行负载平衡以及提供对故障屏幕的支持来合并负载平衡和故障屏幕技术。你会注意到集群中两个节点共个网络。所有与每台机器的“健康”相关的信息以“心跳”消息的形式在这个网络中。每一个服务器都有一个称为集群服务的软件组件，用于系统的状态，并把这个信息传送到另一个节点的相应部位。集群准备（cluste-ready）应用程序将数据在共享的SCSI磁盘阵列上。如果一个应用程序失败，则另一个节点就启微软的集群技术对于网络应用程序的可用性提供了基本的保障：状态数据的容错。在多服务器站点上的网络服务器一般不局部地保持状态（在下一节讨论状态。这使得重新安排用户的请求到一个可用的服务器变得简单。另一方面，数据库负责管理对象的状态，这就是其目的。为了提供容错，对于高度可用的系统，其数据库服务器必需具有实时管理状态的故障能力。对于集群的唯一替代方案是镜像有故障能力的数据库。但镜像数据库不能提供实时的数据同步，因此，一个系统瘫痪将可能导致数据丢失。应当注意到，集群服务能提供对许多资源的容错，而不仅仅是对数据库。这些资源包括文件共享、活动 服务和一些指定的DHCP信息。HighArailabilityClusteringService需要严格的硬件和精确的系统配置，因此这种解决方案的管理相对于前面讲过的任何一种负载平衡方案而言，考虑的问题要多。应当注意到集群解决方案通常涉及到大量的新硬件，这会产生额外花费。HighArailabilityClusteringService总之，HighArailabilityClusteringService通过集群的响应和可用性处理容错。在各个集群内通过广播的“心跳”消息处理容COM＋DynamicLoad业务逻表现面，我们为负载平衡和容错而增加了额外的服务器，增加的服务器放在表现层（网络服务器）13章所描述的，一个普通的应用程序结构如图业务逻表现图27-11表现层包括网络服务器和一系列的ASP文档。嵌入到ASP文档中的服务器端实例化一个COM＋组件，这个组件对某些业务逻辑和数据库的细节进行抽象，并通常在网络服务器上实例化。如果COM＋提供了本地/的透明性，应将业务逻辑组件分离到一个独立的服务器上。网络配置的结果如图27-12网络服务服务 热备 硬件负载平衡数据库图27- 现在已把业务逻辑组件的处理负载分配到另一个服务器上，使网络服务器有的时间和资源来处理HTTP请求。但是，现在又重新引入了一个单一失败点。如果业务逻辑服务器停机，负载平衡器仍然会将HTTP请求发送到网络服务器，但是网络服务器将这些请求。对于将业务层从表现层划分出来，安装在另一台机器上，COM＋DynamicLoadBalancing。这种能力原来是Window2000AdvancedServer的一个功能，在本书编写时，它随着Windows2000AppCenterServer一同发布。图2713所示就是COM＋DynamicLoad服务热备硬件负载平衡图27- 使用COM＋DynamicLoadBalancing的网络配一个额外的服务器已经被添加到结构中，即组件负载平衡路由器。这个服务器（通过集群服务提供容错和高可用性）接收来自网络服务器的请求，并把这些请求安排到业务逻辑服务器阵中。请求的安排根据每个应用程序服务器的处理负载而定。开始时，业务逻辑服务器阵可以支持最多8到现在为止，已经讨论了一个多服务器的概念，而且研究了一系列分配HTTP请求到HTTP协议原本是一种无状态协议。根据其本质，在HTTP请求之间服务器不应该有状态这个概念。ASP处理这个问题时几乎都是使用Session对象，但Session对象是“指定机器的”。有几个方法可以解决这个问题，其中包括避免使用状态、使用客户端的代替状态、利用亲和性（affinity）来允许使用Session对象以及串行化状态数据并存入通用器中。不是所有的网络应用程序都需要管理页面与页面之间的状态。如果一开始时就能避免管理状态，就能为自己减少很多麻烦。很明显这并不是令人满意的答案，但却是不可忽略的。状态管理增加了网络应用程序的复杂性，因此，能避免它是件好事。就像第2章介绍的Response和Request对象允许在客户机上和获取。状态也可以在隐藏的窗体中，窗体在页面之间通过提交传递。在这种情况下，客户端是较好的方法，这把管理数据的任务从服务器上完全移走。若数据在服务器上，随着用户数量的增加，在服务器上的数据将影响服务器性能。举个例子，如果每个浏览的用户4KB有价值的信息，而同时有10000个用户的活动会话，系统必须拿出40MB的内存空间来这些不经常的数据。将这些信息到每个客户端，能有效地改善系统，信息随同每个HTTP请求一起传送。因此，客户端的方法增加了网络传输量，增加了传输时间，不如在服务器端管理状态数据安全，而且对到客户端的数据量有限制（依赖于浏览器除，而且信息只能为特定机器上的用户服务。如果想利用会话变量并使用多服务器，可以使用一个扩展的方法，允许“会话亲和性（sessionaffinity续的请求到这个服务器。一个浏览器首先连接到eb阵中的某个的服务器上。从此开始，在这个用户会话期间，所有后续的请求将安排到同一服务器上。如果在应用程序中使用Session对象，这是必需的。硬件员载平衡器和NLB解决方案都能在确定由哪一个服务器响应某个用户时，提供这种亲和性。然而，亲和性的使用部分抵消了使用这些方案而得到的负载平衡效果。负载平衡方案是在接收到请求时，根据各个服务器的负载情况，将请求分配到某个服务器上。在会话的存活期，服务器的负载特征可能会发生很大的变化。看一下下面这个例子，如图27-14用户用户 网络服务器用户 用户 用户 网络服务器图27- 假设有4个用户（A~D）连接到，他们的请求平均分配给两个网络服务器。现在假设用户C和用户D立即断开连接，用户A和用户B长时间连接并执行许多复杂的运算。如果我们使用了“亲和性”，所有的来自于用户A和用户B的HTTP请求将安排到网络服务器A上，用户使用“亲和性”的另一个问题是容错。网络应用程序的容错目标是完全恢复任何单个的故障。如果严格限制一个用户只能连接到单个服务器，就将失去拥有冗余机器的好处。考虑A瘫痪，用户A和用户B正在使用的所有事务数据和状态数据将丢失。最后，即使你愿意牺牲性能和容错（这是Web阵的两个主要目的）以便Session对象，“亲和性”也不能在所有情况下工作。请看图27-15所示的例子。 服务器网络服务器数据库服务用户 负载平 服务器网络服务器图27- 用户A所在的网络有几个服务器平衡负载。当用户A通过浏览器发出HTTP请求时浏览器就会将这个请求传递给服务器。在本例中，有两个服务器。由于本例使用单器A的请求被安排到同一个网络服务器，即网络服务器A。所有通过服务器B的请求被安排到网络服务器B。尽管是单个用户我们的网络，但我们的系统认为这些请求来自两个用户并用两个网络服务器来分担负载，这将导致试图访问会话数据时出现意想不到的情况。NLB都有解决这个问题的方案。它们允许“亲和性”针对于一个完整的C类地址空间（256个唯一的IP地址。其基本原理是大部分服务器集群应在同一个地址空间内。C类地址“亲和力”会对员载平衡效率产生巨大的不利影响，因为它们一大批用户（而不是一个用户）绑定到一台服务器。对于大的用户组，服务器经常用于帮助传输或者缓存HTTP流。（AOL）用C类“亲和性”时，就必须冒着突然关闭一个服务器，同时使一大批用户不能获得服务的风险。状态的首选方式是在一个中心服务器上。为了达到容错的目的，中心服务器通常是集群的两个服务器。当用户首次站点时，由一个定制的服务器端组件生成一个会话ID，并且在浏览器中。用户会话期间的后续HTTP话ID。会话ID键与一个文本字符串一起到数据库表中，通过这个缓存文本字符串可以和检索二进制大对象（BLOBBLOBSASP组件具有将自己写入这个缓存表中并从中读出的能力。微软提供了一个解决扩展网络时出现的状态问题的很好方案。进一步而言，尽力提供一种可持久的、机器独立的状态机制。现在已经有一种比较容易的方式。CommerceServer早期的SiteServer,CommerceEdition）的再利用。CommerceServer提供的个人化服务能准确地解决这个问题。这些个人化服务将被写入数据库，但是这一麻烦的隐个MMC插件实，很容易使用。CommerceServerCommerceServer需要800MB的硬盘空间和许多你不需要或不用的东西。不幸地是除了全部装上别无选择。此外，对于个人化数据的是通过LDAP连进行的，这种连接比通过ADO和