上下文
您已经决定在设计或修改基础结构层时使用群集以提供高度可用的服务。
问题
您应该如何设计一个高度可用的基础结构层，来防止因单台服务器或它所运行的软件出现故障而导致的服务丢失？
影响因素
在设计高度可用的基础结构层时，请考虑下列影响因素：
- 硬件组件、应用程序或服务出现故障可以使应用程序无法使用或不可用。 例如，设想一台正在提供应用程序的服务器出现了电源故障。 如果这是唯一的服务器或服务器中的唯一电源，则存在故障单点，并且应用程序将不可用。
- 计划内的服务器停机时间可以影响应用程序的可用性。 例如，如果要更新无备用服务器的一台数据库服务器上的操作系统，您可能必须停止应用程序运行才能在服务器上安装修补程序。
- 监视和维护多服务器层增加了对系统和网络资源的要求。
- 使用故障转移群集的应用程序可能需要特殊的编码，以确保发生故障时故障转移过程对用户是透明的，并且应用程序仍然可用。 例如，如果在用来将数据保存到数据库的代码中放置超时和重试，则可确保在发生故障转移时事务将会完成。
解决方案
将 应用程序或服务安装在配置为发生故障时彼此接管对方工作的多台服务器上。 一台服务器接管发生故障的服务器的过程通常称为"故障转移"。 故障转移群集是一组这样配置的服务器：如果一台服务器变为不可用，则另一台服务器自动接管发生故障的服务器并继续处理任务。 群集中的每台服务器将群集中至少一台其他服务器确定为其备用服务器。
检测故障
要让备用服务器变成活动服务器，它必须设法确定活动服务器不再正常工作。 通常，系统使用下列某个常规类型的心跳机制来做到这一点：
- 发送信号。 对于发送信号，活动服务器以定义好的时间间隔将指定信号发送到备用服务器。 如果备用服务器在某个时间间隔内未收到信号，则确定活动服务器发生了故障并取得活动角色。 例如，活动服务器每隔 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) 在客户端和应用程序所使用的网络上公开。
注意：您可以将此设计扩展为包括多台活动服务器（除了所示的服务器外），要么使它们共享单个备用服务器，要么将每个活动服务器配置为另一个活动服务器的备用服务器。
结果上下文
Failover Cluster 模式具有的优缺点：
优点
- 适应计划内的停机时间。 故障转移群集可以允许系统有停机时间，而不会影响可用性。 这样，就适应了日常的维护和升级需要。
- 减少计划外停机时间。 故障转移群集通过消除系统和应用程序级别上的故障单点，减少了与服务器和软件故障有关的应用程序停机时间。
缺点
- 会增加响应时间。 对于故障转移群集设计来说，由于备用服务器上的负载增长，或需要更新多台服务器的状态信息，因此会增加响应时间。
增加设备成本。 故障转移群集所要求的额外硬件很容易使基础结构层的成本加倍。