服务器群集、负载平衡、故障转移

企业解决方案中性能和可靠性设计

作者：微软架构与模式小组
相关技术：服务器群集、负载平衡、鼓掌转移
难度级别：★★★★☆
读者类型：项目经理、系统架构师、基础架构师

    [摘要]企业解决方案中必须确保满足不可预知数量的用户的要求，并且能够每周工作七天、每天工作24小时提供服务，尽管可通过多种方法来提高性能和可靠性，但是本文重点介绍了如何将为任意数量的应用程序或用户提供服务的系统组合起来，以获得更好的可伸缩性和可用性。文章介绍了服务器集群，负载平衡，故障转移这三个技术用来保证基础架构能够最大程度的实现可伸缩性和可用性。

    在企业解决方案中，Server Clustering（服务器群集）强调使用服务器群集来设计基础结构级以满足特定的可用性和可伸缩性要求。服务器群集是通过互连以形成统一虚拟计算资源的两台或更多台服务器。

    服务器群集通过以下方式提高了系统的可用性：确保在一个服务器因故障或计划的关机而变得不可用时，群集中的另一个服务器可以负担工作负载，从而确保应用程序仍对用户可用。群集还通过以下方式来增强可伸缩性：在维持当前性能级别的同时支持更多的用户，或者改善当前用户的应用程序性能。通过服务器群集来增强可伸缩性的同时还可以增加服务器的冗余，从而有助于提高系统可用性，如上所述。

    Server Clustering模式强调群集是通用性设计技术，该技术将应用于另外两种设计模式:Load-Balanced Cluster（负载平衡群集）和Failover Cluster（故障转移群集）。图1显示了性能和可靠性模式群集。

图1 性能和可靠性模式群集

    Load-Balanced Cluster模式解决如何通过设计和实现可伸缩的基础结构级来维护可接受的性能。此模式描述实现以下功能的常用方法：通过一组只读或应用程序服务器或这些服务器场来平衡传入的Internet协议(IP)通信量。负载平衡功能将请求分布到服务器场中的所有正常工作的服务器上，从而增强了包含Web服务器、流媒体服务器和虚拟专用网(VPN)服务器等服务器的基础结构级的性能、可用性和可伸缩性。当负载平衡群集中的某台服务器失败时，负载平衡服务器还通过将负载重新分布到其余服务器上来提供故障转移功能。

    Failover Cluster模式有助于设计高可用的应用程序基础结构级，以防在单台服务器出现故障或者以它为宿主的软件出现故障时丧失服务。此模式描述故障转移群集以及它们如何为读/写存储（如数据库、消息传递系统以及文件和打印服务）提供高可用性。在故障转移群集中，如果某台服务器变得不可用，另一台服务器会接管其任务并继续为最终用户提供服务，该过程被称为故障转移。进行故障转移时，用户可以继续使用应用程序，并且不会意识到是另一台服务器在提供服务。

Server Clustering（服务器群集）

    对应用程序基础结构进行相应设计，使服务器对用户和应用程序表现为虚拟统一计算资源。实现这种虚拟效果的方法之一是使用服务器群集。服务器群集是相互连接的两个或多个服务器，这些服务器表现为一个服务器，因而创建了能增强可用性和（或）可伸缩性的虚拟资源。在某个服务器由于故障或计划停机而无法使用时，通过确保群集中其他服务器可以承担工作负载，群集服务器可以实现提高可用性的目标。此类群集可避免向访问该群集的用户或应用程序所提供服务的损失，还可透明进行服务器转移而不为用户所知。还可以使用群集增强可伸缩性。服务器群集可以在当前性能级别支持更多用户，或通过向多个服务器分散工作负载来提高当前数量的用户的应用程序性能。另外，如前所述，可伸缩群集服务器还有一附带作用，即多个服务器的额外冗余性有助于提高系统可用性。图2显示了服务器群集如何使两个或多个服务器（服务器1到服务器n）对独立应用程序表现为一个虚拟资源。

图2 群集基本概念

    服务器集群技术分为不对称集群和对称集群两种：

    在“不对称群集”中，备用服务器仅是为了在其他服务器发生故障时接替其工作。此类群集通常用于为读/写存储（如数据库、邮件系统以及文件和打印服务）提供高可用性和高可伸缩性。如果由于维护需要而出现计划停机，或因故障导致未计划停机，群集中某节点因而无法使用，其他节点则会接替该故障节点的功能。备用服务器不执行其他有用工作，且其功能不强于主服务器。在将主服务器与多个冗余子系统配置一起以获得高可用性和高容错性时，通常使用功能较差、成本较低的备用服务器。不对称群集的一个常见类型是Failover Cluster。图3显示了不对称群集如何向应用程序显示虚拟资源。正常情况下，主服务器处理所有请求。发生故障时，备用服务器将接替处理所有请求。

图3 不对称群集

    在“对称群集”中，群集中每个服务器都执行有用工作。通常情况下，每个服务器都是一组特定应用程序的主服务器。如果一个服务器出现故障，其余服务器则会继续处理其分配应用程序组，同时处理发生故障的服务器上的应用程序。因为更为充分利用了群集资源，对称群集的成本效率更高；但在发生故障时，剩余各服务器的附加负载可能导致这些服务器也出现故障。

图4 对称集群

    图4显示了对称群集如何向应用程序显示虚拟资源。请求被分散至各个正常运行的服务器，以分散负载并增加可伸缩性。对称群集的一个常见类型是负载平衡群集（请参阅Load-Balanced Cluster模式）。通过向服务器群集中所有正常运行的服务器分布请求，负载平衡群集可以提高Web服务器、介质服务器、VPN服务器和只读存储等服务的性能、可用性和可伸缩性。

Load-Balanced Cluster（负载平衡群集）

    将服务或应用程序安装到多台服务器上，并将这些服务器配置为共享工作负荷。这种类型的配置就是Load-Balanced Cluster。负载平衡通过将客户端请求分散在多台服务器上，从而提高了基于服务器的程序（如Web服务器）的性能。负载平衡技术（通常称为“负载平衡器”）可以接收传入请求，并根据需要将它们重定向到特定主机。有负载平衡功能的主机能够同时响应不同客户端请求，甚至是来自同一客户端的多个请求。例如，Web浏览器有可能从群集中的不同主机获得单个Web页所包含的多个图像。这就分散了负载，加快了处理速度，并缩短了对客户端的响应时间。

    负载平衡器使用不同的算法控制通信流量。这些算法用于以智能方式分散负载，并/或最大限度地利用群集内的所有服务器。这些算法中的一部分示例包括：

• 循环法。循环算法将负载均衡地分配给每台服务器，而不考虑当前的连接数或响应时间。循环法适合于群集中的服务器具有相同处理能力的情况；否则，一些服务器收到的请求可能会超过它们的处理能力，而其他服务器的处理能力则有富余。
• 加权循环法。加权循环算法适合于每台服务器具有不同处理能力的情况。管理员将性能权值手动分配给每台服务器，而且按照服务器权值自动生成调度序列。然后，系统按照循环调度序列将请求定向到不同的服务器。
• 最少连接。最少连接算法根据群集中哪台服务器当前正在处理的连接数最少，从而将请求发送给该服务器。
• 基于负载。基于负载算法先判断群集中哪台服务器当前的负载最低，然后将请求发送给该服务器。

    此外，一些负载平衡器还具有故障检测功能。平衡器可以跟踪服务器或在服务器上运行的应用程序，并在出现服务器故障后停止向该服务器发送请求。图5显示负载平衡的基本组件。

图5 负载平衡组件

    当负载平衡器收到来自客户端的请求时，群集组中的一台服务器将处理该请求。每台服务器都能够独立地处理请求。如果任何服务器因出现错误或正在维护而不可用，其他服务器仍然可以为请求提供服务而不会受到影响。因此，服务的总体可用性比由单台服务器处理所有请求的方案要高得多。但是，如果在一组软件负载平衡服务器前面使用单个物理负载平衡器或单个网络交换机，将会引入另一个故障单点。可以使用冗余负载平衡设备和/或交换机来减少这类风险。

    分布式应用程序通常通过网络连接调用远程服务器上的软件组件。应用程序必须跟踪在各步骤之间会话状态发生的更改，以提供它们之间的连续性。应用程序设计人员通常在以下三个基本位置中的某一个维护会话状态：

1. 客户端。应用程序设计人员将每个用户的会话状态存储在用户的计算机上。
2. 中间服务器。应用程序设计人员将会话状态存储在一台在客户端计算机与永久存储用户信息的数据库服务器之间作为中介的计算机上。
3. 数据库服务器。应用程序设计人员将会话状态与其他长期应用程序和用户数据一起存储在数据库服务器中。

    如果所有服务器都是无状态的（就是说，在服务器处理请求后，服务器的状态将还原为默认值），一个简单的解决方案（如图5中所示的解决方案）就足够了。在两种情况下服务器可以是无状态的。其一，客户端不需要会话；也就是说，每个请求都是单独的工作单元，并且在请求之间没有持续存在的临时值。其二（称为“客户端会话管理”），客户端本身将保存会话的状态，并在请求内发送会话状态信息，以便任何服务器都可以检查到请求，并继续处理它。在服务器会话管理方案中，服务器负责维护用户会话的状态。服务器会话管理要求负载平衡器将同一个用户会话内来自一个客户端的所有请求定向到同一个服务器实例。此机制通常称为“服务器关系”。会话管理本身的一个问题是：如果服务器因出现错误或进行维护而脱机，则可能会丢失客户端的工作，而且客户端必须重新发送丢失的会话中已经发送的所有请求。在某些情况下，偶然丢失会话对用户来说不是大问题。例如，在联机地图搜索应用程序中，如果服务器丢失用户刚键入的地址，用户重新键入该地址不会是一件太麻烦的事情。但是，在其他情况下，会话丢失可能是极其不便的。例如，在具有无状态客户端的联机租用应用程序中，用户可能要花费10分钟的时间才能将几页有价值的信息键入到合约表格中。如果负载平衡组中的一台服务器脱机，您当然不希望用户再花费10分钟重新键入所有信息。为避免因负载平衡组中的服务器出现故障而导致的会话丢失，可以使用以下两种方法：集中式状态管理和异步会话状态管理。图6显示集中式状态管理。

图6 负载平衡和集中式状态管理

    集中式状态管理方法将会话状态信息存储在一台与应用程序服务器处于不同层的集中式服务器上。应用程序服务器每次收到作为会话一部分的请求时，它先从会话管理服务器提取会话状态，然后处理该请求。会话管理服务可以是运行在存储了共享资源并且具有高可靠性配置的服务器上的数据库或另一类型的应用程序。

图7 负载平衡和异步会话状态管理

    使用异步会话状态管理方法时，每台服务器只要发生会话状态更改，就会将其会话状态广播给所有其他服务器；因此，每台服务器都包含所有会话的状态信息，而且任何服务器都可以处理包含在会话中的请求。会话状态还会在单独的服务器出现故障之后继续存在。因为不需要额外的设备，所以此解决方案更经济；但是，因为它涉及异步调用，所以其配置和维护更困难。在每台服务器上存储所有会话的状态还会导致效率更低。

    负载平衡实现的两种主要类别是：

    1) 基于软件的负载平衡。基于软件的负载平衡包括在负载平衡群集中安装在服务器上的特殊软件。软件根据不同的算法分派或接受客户端向服务器发出的请求。算法可以是简单的循环算法，也可以是考虑服务器关系的更复杂的算法。例如，Microsoft® Network Load Balancing是用于Web场的负载平衡软件，而Microsoft Component Load Balancing是用于应用程序场的负载平衡软件。

    2) 基于硬件的负载平衡。基于硬件的负载平衡是由以软件为其提供负载平衡功能的专用交换机或路由器组成的。此解决方案将交换功能和负载平衡功能集成到单个设备中，从而减少了实现负载平衡所需的额外硬件数量。但是，将这两项功能组合在一起，也会使设备的故障排除工作变得更困难。

Failover Cluster（故障转移群集）

    将应用程序或服务安装在配置为发生故障时彼此接管对方工作的多台服务器上。一台服务器接管发生故障的服务器的过程通常称为“故障转移”。故障转移群集是一组这样配置的服务器：如果一台服务器变为不可用，则另一台服务器自动接管发生故障的服务器并继续处理任务。群集中的每台服务器将群集中至少一台其他服务器确定为其备用服务器。

    要让备用服务器变成活动服务器，它必须设法确定活动服务器不再正常工作。通常，系统使用下列某个常规类型的心跳机制来做到这一点：

    1) 发送信号。对于发送信号，活动服务器以定义好的时间间隔将指定信号发送到备用服务器。如果备用服务器在某个时间间隔内未收到信号，则确定活动服务器发生了故障并取得活动角色。例如，活动服务器每隔30秒将状态消息发送到备用服务器。由于内存泄漏，活动服务器最终用尽内存，然后崩溃。备用服务器注意到在90秒（三个时间间隔）内未收到任何状态消息，因此它会接管活动服务器的工作。

    2) 接收信号。对于接收信号，备用服务器向活动服务器发送请求。如果活动服务器没有响应，则备用服务器按特定次数重复发送此请求。如果活动服务器仍然没有响应，则备用服务器接管活动服务器的工作。例如，备用服务器可能每隔一分钟将getCustomerDetails消息发送到活动服务器。由于内存泄漏，活动服务器最终崩溃。备用服务器发送getCustomerDetails请求三次，但未收到响应。此时，备用服务器将接管活动服务器的工作。

    群集可以使用多个级别的信号。例如，群集可以在服务器级别使用发送信号，并在应用程序级别使用一组接收信号。在此配置中，每当活动服务器启动并连接到网络时它都将心跳消息发送到备用服务器。这些心跳消息是按比较频繁的时间间隔（例如每隔5秒）发送的，而备用服务器可能通过编程设置为如果仅仅未收到两个心跳消息，它就接管活动服务器的工作。也就是说，在活动服务器发生故障后不超过10秒的时间内，备用服务器将检测到这一故障并启动备用进程。

    相当常见的情况是，信号是通过专用通信通道发送的，以便网络拥塞和一般网络问题不会导致假的故障转移。此外，备用服务器可能将查询消息发送到运行在活动服务器上的一个或多个关键应用程序，并在指定的超时间隔内等待响应。如果备用服务器收到正确的响应，则它不采取任何进一步行动。为了将对活动服务器的性能影响减少到最小，应用程序级别的查询通常要经过比较长的时段，如每隔一分钟或更长。备用服务器可能通过编程设置为：一直等到至少已经发送五次请求但未收到响应，然后才接管活动服务器。这意味着，可能在长达5分钟之后，备用服务器才会启动故障转移进程。

    备用服务器必须首先将其状态与发生故障的服务器的状态进行同步，然后才能开始处理事务。可以通过事务日子、热备份和共享存储这三种方法达到状态同步。

    对于指定的一组应用程序，只存在一台活动服务器，这是极其重要的。如果多台服务器都像是活动服务器，则通常会导致数据损坏和死锁。解决此问题的常见方法是使用“活动令牌”概念的某个变体。令牌在其最简单级别上是一个标志，用来将服务器标识为某个应用程序的活动服务器。对于每组应用程序来说，只存在一个活动令牌；因此，只有一台服务器可以拥有令牌。当服务器启动时，它会验证其合作伙伴是否拥有活动令牌。如果拥有，则该服务器将作为备用服务器启动。如果它未检测到活动令牌，则它会取得活动令牌的所有权，并作为活动服务器启动。当备用服务器成为活动服务器时，故障转移进程将把活动令牌交给备用服务器。

    在大多数情况下，当备用服务器成为活动服务器时，对于它正在支持的应用程序或用户来说，它是透明的。如果在事务过程中发生了故障，则可能必须重试该事务以使其成功完成。这就使编写应用程序代码时使故障转移进程保持透明显得更为重要。这样做的一个示例是，在将数据提交到数据库时，包括重试和超时。

    故障转移群集中的可伸缩性通常是通过扩展群集内的单个服务器，或向其中添加更多功能来实现的。了解以下两点是很重要的：故障转移群集必须设计为处理预期负载，各个服务器的大小应当能够适应CPU、内存和磁盘使用的预期增长。Failover Cluster服务器通常是高端多处理器服务器，并且它们被配置为使用多个冗余子系统来获得高可用性。如果解决方案的资源要求超过了群集中服务器的限制条件，则扩展群集将是极其困难的。

    为了帮助您更好地了解如何使用故障转移群集来实现高可用性，下图是一个故障转移集群的一个用例：

    第一台服务器(Database01)是处理所有事务的活动服务器。仅当Database01发生故障时，处于空闲状态的第二台服务器(Database02)才会处理事务。群集将一个虚拟IP地址和主机名(Database10)在客户端和应用程序所使用的网络上公开。

    自此，我们已经完整介绍了在企业解决方案中性能和可靠性的三个重要模式，下表列出了这三个模式的核心问题。

模式	问题
Server Clustering	如何为应用程序提供基础结构以满足特定的运行要求（如可用性和可伸缩性）？
Load-Balanced Cluster	应该如何设计可伸缩的基础结构级才能在维持可接受的性能级别的同时适应负载变化？
Failover Cluster	应该如何设计高可用的基础结构级才能防止在单台服务器出现故障或以它为宿主的软件出现故障时丧失服务？

posted on 2004年12月30日 3:13 PM