集群服务然设计的目的就是提高服务器性能，同时在出现故障时能及时进行放障转移，提高服务器的可用性。所以在集群服务器设计之初，必须充分考虑故障转移方案。

　　将应用程序或服务安装在发生故障时彼此能接管对方工作的多台服务器上，一台服务器接管发生故障服务器工作的过程就称为故障转移。如果一台服务器变为不可用，则另一台或多台服务器自动接管发生故障的服务器的工作并继续处理任务。集群中的每台服务器将集群中夺少一台其他服务器确定为其备用服务器，这可在集群服务程序中事先设定好。

　　故障转移解决方案考虑因素

　　集群服务器故障转移方案涉及许多重要方面，在设计集群服务器基础结构时，至少需要考虑下列影响因素。

　　1.用户希望在使用应用程序时这些应用程序可以使用， 并且能够做出响应。

　　2.不间断的连续运行日益成为普遍的业务要求。

　　3.应用程序故障可能会造成严重的经济损失。

　　4.应用程序基础结构中的所有系统都需要维护。各个系统必须既能适应硬件升级，又能适应软件升级， 而不会导致应用程序停止运行。例如，需要发布修补程序，以修复运行于某服务器(提供了应用程序〉上的组件的安全性。如果仅有此服务棒，则应用程序将停止运行。如果该服务器是一系列服务器之一，则仅该服务器将会停止运行，而应用程序不会停止运行。

　　5.回增加硬件可能会增加解决方案的成本和复杂程度。例如，对新硬件或功能更强的硬件需要提供开发和测试费用，才能使应用程序充分利用功能更强的环填。另外，管理更为复杂的环境也需要增加维护和培训成本。

　　故障转移原理

　　在明确了以上设计服务器集群之前需要考虑的事项后，再来了解服务器集群故障转移的原理。在整个故障转移过程中主要涉及以下几个方面。

　　1.检测故障

　　在充分考虑了以上影响因素后，还必须设计一套故障检测方案。要让备用服务器变成活动服务器，必须设法确定活动服务器是否不再正常工作。

　　通常，系统使用下列某个常规类型的心跳机制来做到这一点。

　　a.发送信号。对于发送信号，活动服务器以定义好的时间间隔将指定信号发送到备用服务器。如果备用服务器在某个时间间隔内未收到信号，则确定活动服务器发生了故障并担任活动角色。例如，活动服务器每隔30s 将状态消息发送到备用服务器，如果设定的备用服务器注意到在90s (3 个时间间隔〉内未收到任何状态消息，那么它会接管活动服务器的工作。

　　b.接收信号。对于接收信号， 备用服务器向活动服务器发送请求。如果活动服务器没有响应，则备用服务器按特定次数重复发送此请求。如泉活动服务吉普仍然没有响院，则备用服务器接管活动服务器的工作。例如，备用服务器可能每一分钟将Get Customer Details 消息发送给活动服务器。如果备用服务器发送Get Customer Details请求3次，但未收到响应，此时，备用服务器将接管活动服务缕的工作。

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

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

　　2.同步状态

　　在集群服务系统中，在正式接管活动服务器的工作前，首先要将备用服务器的状态与发生故障的服务器的状态进行同步，然后才能开始处理事务。主要有3种不同的问步方法。

　　1)事务日志

　　在事务日志方法中，活动服务器将对其状态的所有更改记录到日志中。同步实用工具定期处理此日志，以更新备用服务器的状态，使其与活动服务器的状态一致。当活动服务器发生故障时，备用服务器必须使用此同步实用工具处理自上次更新以来事务日态中的任何添加内容。同步之后，备用服务器就成为活动服务器， 并开始处理事务。这种同步方式所需的切换时间较长，服务器应用要停顿的时间也较长。

　　2)热备用

　　在热备用方法中，将把活动服务器内部状态的更新立即复制到备用服务器。因为备用服务器的状态是活动服务器状态的克隆，所以备用服务器可以立即成为活动服务器，并开始处理事五。很明显，这种阔步方式所需的切换时间较短，可用性较高。

　　3)共享存储

　　在共享有储方法中，两台服务器都在共享存储设备(如存储区域网络或双主机磁盘阵列)上记录其状态。这样，因为不需要进行状态同步，故障转移可以立即发生。这种同步方式所需的切换时间也较段，可用性也较高。

　　3.确定活动服务器

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

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

　　此外，大多数服务器使用IP地址进行通信。因此，为了使故障转移成功，基础结构必须能够支持将JP地址从一台服务器转移到另一台服务稽。比如，可以使用能够支持IP地址转移(把故障机的IP地址转移给接管服务器使用)的网络交换机。如果系统的基础结构不支持这一转移功能，则可能需要使用负载均衡集群， 而不是故障转移集群。

　　4.扩展故障转移集群服务器

　　故障转移集群中的可伸缩性通常是通过扩展集群内的单个服务器，或向其中添加更多功能来实现的，所以这种集群系统的可伸缩能力非常有限。