模式之性能和可靠性(二 故障转移群集)

故障转移群集

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

检测故障

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

•	发送信号。 对于发送信号，活动服务器以定义好的时间间隔将指定信号发送到备用服务器。 如果备用服务器在某个时间间隔内未收到信号，则确定活动服务器发生了故障并取得活动角色。 例如，活动服务器每隔 30 秒将状态消息发送到备用服务器。 由于内存泄漏，活动服务器最终用尽内存，然后崩溃。 备用服务器注意到在 90 秒（三个时间间隔）内未收到任何状态消息，因此它会接管活动服务器的工作。
•	接收信号。 对于接收信号，备用服务器向活动服务器发送请求。 如果活动服务器没有响应，则备用服务器按特定次数重复发送此请求。 如果活动服务器仍然没有响应，则备用服务器接管活动服务器的工作。 例如，备用服务器可能每隔一分钟将 getCustomerDetails 消息发送到活动服务器。 由于内存泄漏，活动服务器最终崩溃。 备用服务器发送 getCustomerDetails 请求三次，但未收到响应。 此时，备用服务器将接管活动服务器的工作。

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

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

同步状态

备用服务器必须首先将其状态与发生故障的服务器的状态进行同步，然后才能开始处理事务。 主要有三种不同的同步方法：

•	事务日志。在事务日志方法中，活动服务器将其状态的所有更改记录到日志中。 一个同步实用工具定期处理此日志，以更新备用服务器的状态，使其与活动服务器的状态一致。 当活动服务器发生故障时，备用服务器必须使用此同步实用工具处理自上次更新以来事务日志中的任何添加内容。 在对状态进行同步之后，备用服务器就成为活动服务器，并开始处理事务。
•	热备用。在热备用方法中，将把活动服务器内部状态的更新立即复制到备用服务器。 因为备用服务器的状态是活动服务器状态的克隆，所以备用服务器可以立即成为活动服务器，并开始处理事务。
•	共享存储。 在共享存储方法中，两台服务器都在共享存储设备（如存储区域网络或双主机磁盘阵列）上记录其状态。 这样，因为不需要进行状态同步，故障转移可以立即发生。

确定活动服务器

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

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

此外，大多数服务器使用 Internet 协议 (IP) 地址进行通信，因此，为了使故障转移成功，基础结构必须能够支持将 IP 地址从一台服务器转移到另一台服务器。 比如，可以使用能够支持 IP 地址转移的网络交换机。 如果系统基础结构不支持这一转移功能，则您可能需要使用负载平衡群集，而不是故障转移群集。 有关详细信息，请参阅Load-Balanced Cluster 模式。

扩展故障转移群集服务器

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

返回页首

示例

为了帮助您更好地了解如何使用故障转移群集来实现高可用性，下面的讨论分步演示了如何将已经实现的基本解决方案（它包含单个系统，即故障单点）重构为高度可用的解决方案。

非故障转移解决方案

一开始，组织可能只有基本解决方案体系结构（例如，图 1 中略述的体系结构）。虽然该解决方案可能满足最初的可用性要求，但是某些因素（如用户数的增长或需要应用程序停机时间更短）可能迫使您对设计进行更改。

图 1:具有故障单点的非故障转移解决方案

在图 1 中，数据层仅包含一台为应用程序层提供服务的数据库服务器 (Database10)。 如果数据库服务器或它运行的软件发生故障，则应用程序服务器将不再能够访问用来为客户端提供服务的数据。 这将使应用程序对客户端不可用。

故障转移群集解决方案

为了提高解决方案的可用性，组织可能决定消除数据层中的单个数据库服务器造成的潜在故障单点。 为此，可以将服务器添加到数据层，并利用现有数据库服务器、新服务器和共享存储设备创建故障转移群集。 在说明该更改的图 2 中，群集由连接到共享存储阵列的两台服务器组成。

图 2:具有故障转移数据层的解决方案

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

注意：您可以将此设计扩展为包括多台活动服务器（除了所示的服务器外），要么使它们共享单个备用服务器，要么将每个活动服务器配置为另一个活动服务器的备用服务器。