一种面向服务的快速透明故障转移装置及实现方法

摘要

本发明公开了一种面向服务的快速透明的故障转移装置及实现方法，本发明基于通用操作系统具有内核态和用户态的特征，从双层软件体系结构的角度建立了故障转移的装置，所述装置包括主、备服务器操作系统中的主控进程模块和通信控制进程模块。系统主控进程模块运行在操作系统用户态，负责控制服务软件状态切换，控制其它应用进程(其中包括通信控制进程)的转移顺序和数据同步；通信控制进程模块运行在操作系统的内核态，负责底层网络连接切换和通信链路上缓存的消息处理。本发明保证系统在出现故障时进行的故障转移对用户是透明的，同时具有较短的故障转移延时和较低的系统开销，能够在保证服务可用性前提下高效透明地进行故障转移。

说明书

技术领域

本发明涉及服务器故障转移领域，尤其涉及面向服务的快速透明故障转移装置及实现方法。

背景技术

随着网络通讯技术的不断发展，各种网络增值业务和应用服务也在迅猛增长，用户不仅需要开放完善的服务提供，更需要高质量不间断的服务交付。这就对面向服务环境下的容错技术提出了严格的要求，在关键网络服务中，如果系统设备出现故障或离线维修都会导致服务中断，从而造成严重的后果。

一个著名的例子是e-bay，1999年e-bay公司10个小时的网络服务中断造成了至少五百万美元的经济损失。由此可见，在面向服务的环境下，关键网络服务必须能够在恶劣条件下保证全天候的服务可用性。

传统应用中系统的可用性被定义为系统可为用户所使用时间和运行时间的百分比，即正常运行时间的百分比。面向服务环境中，服务的可用性定义为用户对服务的满意程度，即在传统的系统可用性基础上增加了服务连续性(High Availability+Service Continuity＝ServiceAvailability)。可用性是从系统的角度来看系统软硬件正常运行的时间比，而服务连续性则是从用户的角度来看服务是否能够不间断交付。

面向服务环境动态、开放的特点，以及服务本身的自治性，使得用户无法对底层服务资源有完全的了解和控制，为了向用户提供可靠连续的服务，用户数据和会话状态必须保存以防止系统故障或系统切换，这是一项复杂并具有挑战性的工作，但它也是提供服务可用性的关键。除了要求应用程序和系统状态要保存在可靠的冗余部件上，系统还要为有状态服务提供快速透明的故障转移方案。

目前，针对故障转移的研究不是很多，而且大多数故障转移方案并不能保证服务的可用性，在系统出现故障或故障转移期间都会或多或少造成服务中断，同时对用户也不是透明的，在故障转移和恢复过程中经常会涉及到客户端，客户端的参与可能是简单的超时重新请求，也可能直接参与服务器选择和连接状态迁移，尽管有客户端参与的解决方案会提供一定的灵活性，但对客户端透明的解决方法更有必要。

同时，主、备服务器之间的数据传输和信息交互通常采用TCP(Transmission ControlProtocol—传输层控制协议)完成，TCP协议处理复杂，效率不高，会增加了故障转移延时和系统开销。

最后，由于目前绝大多数操作系统内部均未提供故障转移机制，所以故障转移方案基本上都是在应用程序中实现的，这导致了较高的系统处理开销。

发明内容

为了实现现有技术中存在的问题，本发明提出一种面向服务的故障转移装置和利用该装置进行快速透明的系统故障转移方法。

本发明保证系统在出现故障时进行的故障转移对用户是透明的，同时具有较短的故障转移延时和较低的系统开销，能够在保证服务可用性前提下高效透明地进行故障转移。

一种面向服务的快速透明故障转移装置，包括，主、备服务器，客户端，其特征在于所述主、备服务器操作系统中还包括：

主控进程模块和通信控制进程模块；

所述主控进程模块，运行在操作系统的用户态，负责控制服务软件状态切换，控制包括通信控制进程在内的应用进程的转移和服务进程的状态数据同步；

所述通信控制进程模块，运行在操作系统的内核态，负责底层网络连接切换和通信链路上缓存的消息处理；

所述主控进程模块和通信控制进程模块在故障转移的过程进行协调，完成应用进程的状态转移和底层网络连接切换。

一种面向服务的快速透明故障转移实现方法，其特征在于，包括如下步骤：

主服务器发生故障，主控进程向通信控制进程发起故障转移通知；

主控进程进行服务软件状态切换，应用进程的状态转移，并完成各服务进程的状态数据同步；

通信控制进程进行进程的状态转移，并完成底层链路的切换；

所述应用进程的状态转移和底层链路的切换是同时进行的。

所述应用进程的状态转移的具体步骤如下：

第1步，主服务器主控进程启动故障转移之前，确定故障转移的条件满足要求，开始进入故障转移；

第2步，主服务器主控进程通知通信控制进程故障转移开始，主服务器收到的客户消息不再向上层服务应用进程派发，直接转发到备用服务器缓存，停止向客户端发送服务数据，并将未传输完的服务数据转发到备用服务器缓存，等到故障转移结束后重新发送；

第3步，主服务器系统主控进程开始进行应用进程的故障转移，并通知备用服务器进行主备角色转换；

第4步，主备角色转换完成后，备用服务器通知主服务器角色转换已完成，备用服务器成为新主服务器，开始继续处理业务，原主服务器得知主备角色转换完成后，改变主备状态；

第5步，新主服务器主控进程将通知其通信控制进程应用进程转移完毕，通信控制进程将缓存的客户消息派发至服务应用进程进行，并通知客户端故障转移结束，恢复服务交付。

所述转移的条件是指：

(1)主服务器系统允许故障转移；

(2)备用服务器处于正常运行的状态；

(3)主备通信正常。

若主服务器失效，不能满足故障转移的条件，则执行如下步骤：

第1步，备用服务器主控进程向其通信控制进程通知故障转移开始，通信控制进程随即通知客户端缓存发往主服务器的链路消息；

第2步，在备用服务器通信控制进程处理底层链路切换的同时，备用服务器主控进程模块控制其它应用进程的主备角色转换，服务应用进程进行状态恢复；

第3步，当各应用进程主备角色转换完成之后，新主服务器主控进程通知通信控制进程向客户端发出链路切换命令，网络连接恢复正常。

所述底层链路切换的步骤如下：

第1步，通信控制进程先设置系统状态为故障转移状态，向相关的客户端发送故障转移消息，停止对接收到的客户请求向上层应用派发，开始向备用服务器同步传送已稳定的状态数据，在转移期间把收到的客户消息转发到备用服务器，备用服务器缓存所有转发的客户消息到相关的消息队列中；

第2步，与主服务器连接的各客户端收到故障转移消息之后，缓冲各自应用进程要求发送消息的请求，停止向主服务器发送消息，设置自己为等待状态，等待当前备用服务器的故障转移结束的应答；

第3步，通信控制进程将当前主服务器与客户端的网络连接状态发往备用服务器，备用服务器更新自己保存的网络连接状态，就绪之后，根据网络连接状态的信息向客户端发送故障转移结束消息，并作为新主服务器开始向应用进程派发消息，客户端收到转移结束的消息后，恢复自己的状态为正常状态，开始发送缓冲在自己发送队列中的消息。

所述主、备服务器之间采用UDP作为内部通信的协议，采用三次握手的方式，完成底层网络连接切换。

采用本发明所述的装置及实现方法，与现有技术相比，对用户是透明的，可以正确处理服务器故障期间所有的客户请求；本发明采用被动复制和消息日志结合的方式来保存服务状态，可以应用于开放动态的面向服务环境；基于操作系统具有内核态和用户态的特征，从双层软件体系结构的角度实现了故障转移，大大降低了基于用户层代理实现所产生的系统开销；同时采用可靠UDP作为主备数据传输协议，快速可靠地保证了数据同步和网络的正常运行。

附图说明

图1是本发明提出的故障转移装置总体模型图；

图2是主动故障转移系统主控模块流程图；

图3是通信链路故障转移的三次握手过程图；

图4是被动故障转移流程图。

具体实施方式

下面结合附图对本发明所述装置及方法进行详细说明。

基于通用操作系统具有内核态和用户态的特征，本发明从双层软件体系结构的角度建立了故障转移的装置，所述装置包括主、备服务器操作系统中的系统主控进程模块和通信控制进程模块。

系统主控进程模块运行在操作系统用户态，负责控制服务软件状态切换，控制其它应用进程(其中包括通信控制进程)的转移顺序和数据同步；通信控制进程模块运行在操作系统的内核态，负责底层网络连接切换和通信链路上缓存的消息处理。

本发明所述的故障转移装置基于服务器备份，当系统正常运行时，主、备服务器均接收客户连接和服务请求，主服务器对大多数客户请求进行处理和回复，备用服务器只响应一些非关键无状态的客户请求。主服务器周期性地将服务状态保存在备用服务器上，使得备用服务器有足够的信息可以接管主服务器。

如果主服务器出现异常，客户端与服务器的网络连接将被透明地转移到备用服务器上，正在被主服务器处理的服务也转移至备用服务器继续处理，在此期间备用服务器仍然接收新的客户请求。

服务状态通常由两个重要部分组成：网络连接状态和服务应用程序状态。为了在服务器发生故障时能够正确地处理正在进行的客户请求，故障转移需要正确地处理服务器出现故障前已经接收的部分客户请求和已经传输的部分答复，部分已接收的请求和部分已传输的回复是服务器连接状态的组成部分。对于客户端透明的容错策略，如果主服务器出现故障，在没有客户端帮助的情况下，连接状态必须在备用服务器上可用且可传递。如果正确处理新的客户请求需要依赖于先前的请求，则服务应用程序是有状态的，在这种情况下，故障转移需要一个能在新服务器上可用的最新服务应用程序状态版本。

本发明所述的故障转移装置结合被动复制和消息日志来保存服务状态，主服务进程定期地将服务状态以检查点的形式发送给备份服务进程，同时将与服务进程有关的日志信息保存在备用服务器内存中。当主服务器出现故障，备用服务器会根据保存的信息恢复故障前的服务状态。由于被动复制保存服务状态所需的系统负载比较低，备用服务器有能力处理一些非关键无状态的客户请求，这样大大增加了系统整体吞吐量。

下面结合附图，以本发明在Linux操作系统上的实现为例做进一步地详细说明：

本发明基于Linux实现，其工作涉及到的两个方面，分别由服务器软件系统中的系统主控进程(System operation Main Process，OMP)和通信控制进程(Communication ControlProcess，CCP)完成。系统主控模块运行在Linux操作系统用户态，负责控制服务软件状态切换，控制其它应用进程(其中包括通信控制进程)的转移顺序和数据同步；通信控制模块运行在Linux操作系统的内核态，负责底层网络连接切换和通信链路上缓存的消息处理。

总体软件设计模型如图1所示。故障转移开始时，对于系统主控进程来说，包括通信控制进程在内的所有进程都是一样的，要通知它们进行转移。在转移过程中，系统主控进程和通信控制进程进行协调，按照分工分别完成进程的状态转移和网络连接切换。同时，为了缩短故障转移延时，进程状态和网络连接的切换是并发进行的。

图2描述了故障转移的总的流程，根据故障转移模型，系统主控模块控制着整个转移的进行，其过程描述如下：

主服务器主控进程启动故障转移之前，首先判断转移的条件是否满足，即：

(1)主服务器系统允许故障转移；

(2)备用服务器处于正常运行的状态；

(3)主备通信正常。

如果三个条件均满足，则开始进入主动故障转移过程。

主服务器主控进程通知通信控制进程故障转移开始，主服务器收到的客户消息不再向上层服务应用进程派发，而是直接转发到备用服务器缓存；同时，停止向客户端发送服务数据，并将未传输完的服务数据转发到备用服务器缓存，等到故障转移结束后重新发送。

在通信控制进程处理网络连接切换的同时，主控进程控制着其它应用进程进行故障转移。

首先进行主服务器应用进程的故障转移，即通知各服务进程停止处理业务，保存当前状态。

然后，主服务器主控进程通知备用服务器进行主备角色转换，在这一过程中主服务器将各服务进程的状态数据同步到备用服务器。

主备角色转换完成后，备用服务器通知主服务器角色转换已完成，此时备用服务器成为新主服务器，开始继续处理业务。主服务器得知主备角色转换完成后，改变主备状态。

新主服务器主控进程将通知其通信控制进程应用进程已转移完毕，通信控制进程将缓存的客户消息派发至服务应用进程进行，并通知客户端故障转移结束，恢复服务交付。

将故障转移过程进一步细化，表现出在转移过程中主控进程与通信控制进程的工作细节，并且体现出主、备服务器通信控制进程与客户端，主控进程与其它应用进程的交互关系，如图2所示。

图3描述了主、备服务器故障转移的底层链路切换流程。网络连接状态切换在通信控制进程的支持下完成，主、备服务器间通信不同于其它业务通信，需要提供单独的接口，通信地址分别使用主备双方的逻辑地址，本发明所述故障转移装置及实现方法以可靠UDP作为内部通信的协议，采用三次握手的方式，在链路层上完成故障转移的网络连接切换。基于RUDP通信的可靠性，这里认为每一条消息都不会丢失。图中黑色粗线表示故障转移过程中控制消息的交互，细线表示正常的携带数据的消息。

底层链路切换流程如下：故障转移开始，通信控制进程先设置系统状态为故障转移状态，向相关的客户端发送故障转移消息，停止对接收到的客户请求向上层应用派发，开始向备用服务器同步传送已经稳定了的状态数据，在转移期间把收到的客户消息转发到备用服务器，备用服务器缓存所有转发的客户消息到相关的消息队列中。

与主服务器连接的各客户端收到故障转移消息之后，缓冲各自应用进程要求发送消息的请求，停止向主服务器发送消息，设置自己为等待状态，等待当前备用服务器的故障转移结束的应答。

接着是网络链路切换，通信控制进程将当前主服务器与客户端的网络连接状态发往备用服务器，备用服务器收到后，更新自己保存的网络连接状态，等到自己就绪之后，根据网络连接状态的信息向客户端发送故障转移结束消息，并作为新主服务器开始向应用进程派发消息，客户端收到故障转移结束的消息后，恢复自己的状态为正常状态，开始发送缓冲在自己发送队列中的消息。

主、备服务器对外界客户端只提供一个IP(Internet Protocol—网际协议)地址，绑定在主服务器上，当故障转移时，原主服务器解除对该IP地址的绑定，由新的主服务器将该地址与自己的物理地址——MAC(MediaAccess Control—介质访问控制)地址绑定起来。建立IP地址与MAC地址的映射关系是为了集群内部结点能够正确地区别主、备服务器。

图4介绍了失败停止情况下故障转移的流程。在系统正常运行过程中，备用服务器扫描任务监视主服务器的运行状况，一旦发现主服务器发生异常，即向主服务器主控进程发出主服务器异常消息，请求故障转移。如果主服务器系统已经崩溃，备用服务器立刻启动失败停止故障转移流程，承担主服务器的角色。

失败停止故障转移步骤如下：备用服务器主控进程向其通信控制进程发出故障转移开始通知。其通信控制进程随即通知客户端缓存发往主服务器的链路消息，等待备转主非正常倒换结束后，再将链路消息发往新主服务器；在备用服务器通信控制进程处理链路切换的同时，备用服务器主控进程控制其它应用进程的备转主倒换，服务应用进程通过保存的检查点和消息日志进行状态恢复，在此情况下，服务进程不进行主备之间的数据同步缓存及转发；当各应用进程备转主倒换过程完成之后，新主服务器主控进程通知通信控制进程应用进程主备倒换完成。通信控制进程向客户端发出链路切换命令，网络连接恢复正常。