CN101202658A - 多主机***的服务接管***及方法 - Google Patents

Abstract

一种多主机***的服务接管***及方法，多主机***包含有通过心跳机制监控互相之间运作状态的服务主机与至少一个待命主机。本发明在对外提供服务的服务主机发生故障时，首先接管服务主机的对外提供服务的对外网络协议地址至其中一待命主机；然后准备接管服务主机的服务至待命主机所需的服务环境；并且检测服务环境的准备状态，在未准备完全之前丢弃通过对外网络协议地址对此服务的访问请求数据包；以及在服务环境准备完全之后接管服务，接收对服务的访问请求数据包，以对外提供此服务。所述服务接管***及方法能够实现多主机***网络协议地址及服务的无间断及透明接管。

Description

多主机***的服务接管***及方法

技术领域

本发明涉及一种多主机***或丛集***的服务接管技术，特别涉及一种高可用性丛集***的服务接管***及方法。

背景技术

目前为了使运行重要业务的计算机***提供不间断的服务，最普通的做法是布置高可用(High Available)的丛集(Cluster)或多主机***。高可用丛集通常由至少两台主机构成，在对外提供服务的过程中，一台主机提供正常的服务，其它主机则处于“待命”状态。并且各个主机之间通过“心跳(Heartbeat)”机制实现运作状态的互相监控。

例如图1示出了一种典型的高可用性丛集的结构示意图，在该高可用性丛集中，整个***即主机***10由两台主机主机12与主机14构成，并分别具有一私有网络协议(Private Internet Protocol，Private IP)地址192.168.0.1及192.168.0.2，但主机***10对外提供服务则通过一可访问的公共网络协议地址，或称网络协议(Public Internet Protocol，Public IP)地址10.10.1.10。客户端通过公共网络协议地址访问主机***10，从客户端的角度来看，整个***就是一台提供一公共网络协议地址：10.10.1.10的主机***，所以整个***对客户端隐藏了具体的结构。两个主机12与14之间通过“心跳”机制互相检测对方的状态，当“待命”主机检测到目前提供服务的主机发生故障而不能提供服务或运作状态不稳定时，由“待命”主机接管公共网络协议地址及工作，对外提供服务。发生故障的主机则进行错误恢复，当恢复到正常状态后，则处于“待命”状态，随时准备接管发生故障主机的服务。

目前所有的丛集所提供的服务几乎都可以通过网络实现，并且通过网络提供服务才有可能实现服务在丛集***的多个主机之间进行无间断切换。但是，通过公共网络协议地址对外提供的服务性质是不同的，因此网络协议地址接管后服务是否可用也存在不同。例如，一些服务可以在网络协议地址接管后立刻提供，例如纯网络服务的动态主机配置协议(DHCP)、域名服务(DNS，Domain Name Service)、终端机仿真协议(Telnet)和静态网页网站浏览的超文本传输协议(HTTP)服务，这些服务只要有一个与原来故障主机一样的很小的配置文件就可以启动，即可以无间断的对外提供服务。

反之，文件传送协议(FTP)、超文本传输协议(HTTP)等文件服务就未必能够立刻提供服务，因为这些服务除提供网络连接外，还提供存放文件的空间，存放文件空间需要有准备的时间，需要保证目前提供服务的主机存放文件空间与原来提供服务主机的存放文件空间为同一位置。此外，如果通过网络提供对区块设备的访问服务，例如网络小型计算机***接口(iSCSI)，这种情况就更加复杂。主机不但需要提供对外连接服务，还需要保证故障切换前和切换后的磁盘为同一个，不能在切换过程中变更实体访问磁盘。在这种情况下，服务不能被立即接管，而需要等待磁盘***都准备好才可以执行。

因此，在运作主机及时接管了网络协议，如果在接管前没有做好充分的软硬件环境准备，尤其是需较长时间硬件准备之后才能安全接管网络服务的情况下，例如网络小型计算机***接口服务必须保证在网络协议地址和网络服务本身接管前，硬盘和相应的廉价磁盘冗余阵列(RAID，Redundant Arrayof Inexpensive Disks)、逻辑卷(LV)设置已经准备好，因为涉及到硬件准备通常需要较多的时间，通常至少需要30秒钟左右，在没有准备好前如果通过此网络协议地址访问这个服务，就会造成“服务拒绝”，进而发生拒绝访问错误。***会以此给出服务报告错误，因此公知技术无法实现服务的无间断及透明接管。

发明内容

为了解决上述公知技术中的问题与缺陷，本发明的目的是提供一种多主机***的服务接管***及方法，以在多主机***的提供服务的主机发生故障时，其它运作主机能够安全、无间断且透明地接管其网络协议地址及服务，以保证服务的正常运行及功能的正常使用。

为实现上述目的，本发明提供了一种服务接管***，应用于包含一服务主机及至少一个待命主机的多主机***中，服务主机通过一对外网络协议地址对外提供服务，待命主机处于待命状态，且服务主机与此至少一个待命主机之间通过心跳机制互相监控运作状态，其中此服务接管***包含有：一网络协议地址接管模块、一服务接管模块及一请求处理模块；其中，此网络协议地址接管模块通过心跳机制判断服务主机的运作状态，并当服务主机发生故障时发送一资源释放请求通知服务主机释放其占有的对外网络协议地址及服务，以接管服务主机的对外网络协议地址至其中一待命主机，服务接管模块用以准备接管服务主机的服务至此待命主机所需的服务环境，以及接管服务。请求处理模块系检测服务接管模块的服务环境准备状态，并且在服务环境未准备完全之前，丢弃通过对外网络协议地址对此服务访问的请求数据包。

根据本发明的技术构思，该请求处理模块还包含一资源准备模块，用以生成与硬件资源约定的服务接管所需的服务环境。

根据本发明的技术构思，其中该资源准备模块系提供接管该服务的网络连接，以及提供与该服务主机发生故障的前相同的访问空间。

根据本发明的技术构思，该接管服务为文件服务时，该资源准备模块提供与该服务主机发生故障之前相同位置的文件存放空间。

根据本发明的技术构思，该接管服务为区块设备访问服务时，该资源准备模块准备与该服务主机发生故障之前为同一访问服务区块设备的区块设备。

根据本发明的技术构思，该服务接管模块判断接管该服务是否需要环境准备，如果不需要准备，则立即接管该服务；否则，该服务接管模块执行接管该服务所需的服务环境准备。此外，为实现上述目的，本发明还公开了一种服务接管方法，应用于包含一服务主机及至少一个待命主机的多主机***中，服务主机与至少一个待命主机之间通过心跳机制互相监控运作状态，此方法包含以下步骤：通过心跳机制判断服务主机的运作状态，并当服务主机发生故障时发送一资源释放请求通知服务主机，以释放其占有的对外网络协议地址及服务；接管服务主机的对外提供服务的一对外网络协议地址至其中一待命主机；准备接管服务主机的服务至待命主机所需的服务环境；检测服务环境的准备状态，在服务环境未准备完全之前丢弃通过对外网络协议地址对此服务的访问请求数据包；以及在服务环境准备完全之后接管服务，并接收对此服务的访问请求数据包，以对外提供服务。

根据本发明的技术构思，还包含生成与硬件资源约定的服务接管所需的服务环境的步骤。

根据本发明的技术构思，该准备服务环境的步骤包含下列步骤：提供接管该服务的网络连接；以及提供与该服务主机发生故障之前相同的访问空间。

根据本发明的技术构思，该接管服务为文件服务时，提供与该服务主机发生故障之前相同位置的文件存放空间。

根据本发明的技术构思，该接管服务为区块设备访问服务时，准备与该服务主机发生故障之前为同一访问服务区块设备的区块设备。

根据本发明的技术构思，在该准备该服务环境的步骤之前，还包含判断接管的该服务是否需要环境准备的步骤，如果不需要准备，则立即接管该服务；否则，准备接管该服务所需的该服务环境。

本发明在多主机***及类似环境下通过网络协议地址及服务接管提供高可用服务时，对于需要时间准备的服务接管，为了保证发生故障的主机服务在网络协议地址被接管后安全无误地提供对外服务，因此在服务接管之前准备接管服务所需的服务环境，并在准备完成之前丢弃对服务的请求数据包。进而不断地检测服务环境的准备状态，直至准备完成之后以执行服务的接管与对外提供服务。

因此，本发明具有以下优点：不仅保证了能够快速提供具有快速接管特性的服务，且保证不能快速提供服务的情况下客户端与服务主机端的连接不中断，实现多主机***网络协议地址及服务的无间断及透明接管。

附图说明

图1为一典型高可用性双主机丛集***的结构示意图；

图2为本发明的多主机服务接管***的方框图；

图3为本发明的多主机服务接管方法的步骤流程图；

图4为“保护”状态服务的访问请求处理流程图；以及

图5为“就绪”状态服务的访问请求处理流程图。

其中，附图标记说明如下：

10主机***       12主机

14主机              20网络协议地址接管模块

22服务接管模块      24资源准备模块

26请求处理模块

步骤                102设置***为保护状态

步骤                104设置所有服务为保护状态

步骤                106接管公共网络协议地址

步骤                108是否需要准备服务接管环境？

步骤                110立即接管此服务

步骤                112执行服务接管的资源环境准备

步骤                114接管此服务

步骤                116设置此服务为就绪状态

步骤                118是否仍存在保护状态的服务？

步骤                120提供对外服务

步骤                122设置***为就绪状态

步骤                202接收到服务访问请求

步骤                204服务是否处于就绪状态？

步骤                206丢弃服务的访问请求数据包

步骤                208发送至相应服务进行处理

步骤                302接收到服务访问请求

步骤                304发送至相应服务进行处理

具体实施方式

有关本发明的特征与实际有益效果，现配合附图对最佳实施例详细说明如下。

请参考图2，其示出了本发明的多主机服务接管***的方框图，所述多主机***包含一服务主机及至少一个待命主机，例如根据图1所示，多主机***10包含主机12及主机14，这里假设主机12为服务主机，主机14为一待命主机，且服务主机12与待命主机14之间通过心跳机制互相监控运作状态。因此，针对公知技术的上述问题，本发明的多主机服务接管***包含了一网络协议地址接管模块20、一服务接管模块22及一请求处理模块26。下文中将对上述各个模块作详细说明。

本发明的网络协议地址接管模块20用以在当前提供服务的服务主机12发生故障之后，使得其它待命状态的其中一主机将此服务主机12的对外网络协议地址10.10.1.10快速接管过去。当存在多个待命主机时，关于由哪个待命主机接管服务可以随机选择。任何一个或多个待命主机可能会检测到故障主机的故障，因此这些待命主机都会试图接管此故障主机的网络协议地址和服务，但为了防止多个待命主机同时接管网络协议地址和服务而造成冲突，目前广泛采用的技术大致有两种：令牌环或仲裁机制。令牌环的原理就是使用令牌在所有待命的主机之间移动循环，哪个待命主机拥有令牌就拥有网络协议地址和服务的接管义务；仲裁机制就是无论哪一个待命主机即将要接管网络协议地址和服务的前都要做两件事，即检查是不是有“锁定”，如果没有“锁定”，则执行“锁定”，然后接管网络协议地址和服务，反之如果已经有“锁定”，则结束，不进行接管。这两个技术用于防止多个待命主机同时接管网络协议地址和服务而造成的冲突。但是需要指出的是，本发明的待命主机接管服务的技术并不局限于上述两种。

之后，接管的待命主机发送指令要求此故障服务主机12将其对外提供服务的网络协议地址释放。由此，原来访问此对外网络协议地址10.10.1.10的客户端计算机或应用程序仍然通过此地址访问，但此时实际拥有此网络协议地址和提供服务的主机已经变化为另一主机。

在待命主机14接管原服务主机12的网络协议地址之后，对于例如纯网络服务及静态网页网站浏览服务等可通过服务接管模块22立即接管，并对外提供。但对于需要接管环境的服务，例如网络小型计算机***接口(iSCSI)、文件传送协议(FTP)、服务器信息区块/公用因特网文件***(SMB/CIFS)、网络文件***(NFS)等网络区块设备服务及文件服务，需要一定时间的软件准备(少数情况)及硬件准备(多数情况)，只有执行上述服务接管准备后才能通过所接管的网络协议地址及时、安全地提供服务。因此，服务接管模块22则需要在服务接管之前，准备接管此故障主机12的服务至待命主机14所需的软硬件环境。

服务接管模块22的接管环境准备随服务类型的不同而不同，有些接管服务需要提前准备好接管所需的软硬件环境，因而可能非常耗时，而有些服务则不需要准备接管环境，因此直接快速地接管。因此，服务接管模块22需要对接管服务是否需要环境准备进行判断。如果不需要准备，则立即接管此服务；否则，服务接管模块22执行接管服务所需的服务环境准备。关于接管是否需要环境准备，服务接管模块22可通过接管服务类型来判断，如果所提供的服务与储存空间或文件内容相关，例如网络小型计算机***接口(ISCSI)、文件传送协议(FTP)、超文本传输协议(HTTP)、网络文件***(NFS)、服务器信息区块/公用因特网文件***(SMB/CIFS)等等与存储空间或文件内容相关的服务，则需要时间准备服务环境；相反，对于纯网络服务，例如纯网络服务的动态主机配置协议(DHCP)、域名服务(DNS)等，服务接管模块22则不需要时间准备服务环境。

非常耗时的软硬件准备主要是与硬件或等待时间有关，例如磁盘、磁带等的准备非常耗时(如等待磁盘被其它设备释放，等待磁带绕到开头位置，创建廉价磁盘冗余阵列(RAID)、逻辑卷(LV)、快照等等)，而有些环境准备则需要等待一个超时时间。还有一些准备的服务可能只需要更改配置文件或者更改路径等。对于服务接管则比较容易，只需要重新启动或启动本主机上的服务程序即可。

多主机***的对外服务不但包含网络小型计算机***接口等区块设备访问功能，也提供了文件传送协议(FTP)、服务器信息区块/公用因特网文件***(SMB/CIFS)、网络文件***(NFS)等文件访问功能。另外，还提供了远程登入协议(SSH)、终端机仿真协议(Telnet)、用户接口(WebUI)等管理功能，同时提供了动态主机配置协议(DHCP)、域名服务(DNS)等网络功能。这些服务大致可以分为两类：第一类服务如网络小型计算机***接口、文件传送协议、服务器信息区块/公用因特网文件***、网络文件***等服务，这类服务需要与硬件资源约定，例如网络小型计算机***接口必须是对某个确定的磁盘的操作，而文件传送协议、服务器信息区块/公用因特网文件***、网络文件***等共享必须基于某个确定的磁盘上的某个目录。第二类服务如远程登入协议、终端机仿真协议等管理功能和动态主机配置协议、域名服务等网络功能。这类服务基本与硬件资源无关。只要计算器正常工作，网络协议地址正常提供就可以提供对外的服务，所以在以上双控制器故障接管过程中，这两类服务需要分别处理。

对于第一类服务，除保证故障后的连接性外，还需要保证访问的空间与发生故障前访问的空间是相同的。否则用户访问空间会发生变化，导致不能正常提供服务。所以第一类服务在故障切换前需要先将硬件准备好，然后才能提供真正的服务。

对于第二类服务，需要保证故障发生后的快速连通性，需要保证在故障发生后不能有明显的延迟。因为这些服务尤其是远程登入协议、终端机仿真协议、用户接口的管理服务都与用户体验密切相关，明显的延迟会降低用户的体验质量。其中对于第一类服务的故障接管环境，由服务接管模块22的资源准备模块24完成。资源准备模块24提供接管该服务的网络连接，以及提供与该服务主机发生故障之前相同的访问空间。其中当接管服务为文件服务时，该资源准备模块提供与该服务主机发生故障之前相同位置的文件存放空间；当接管服务为区块设备访问服务时，该资源准备模块系准备与服务主机发生故障之前为同一访问服务区块设备的区块设备。

例如，对于磁盘阵列(Disk Array)的储存空间准备，资源准备模块24可执行步骤如下：发送指令要求故障主机释放所占用的磁盘设备；如果故障主机还可以活动，则释放这些硬盘设备，否则因为已经挡掉，也就不需要释放硬盘设备；重新起始化这些硬盘的公共磁盘空间，同时读取廉价磁盘冗余阵列、逻辑卷的组装数据；根据廉价磁盘冗余阵列的组装数据将这些硬盘分组组装成廉价磁盘冗余阵列，此时廉价磁盘冗余阵列还原；根据逻辑卷的组装数据将廉价磁盘冗余阵列划分或启动为不同的逻辑卷，此时逻辑卷还原。对于网络小型计算机***接口服务，需要将设备输出给相应的启动器(Initiator)，对于文件传送协议、服务器信息区块/公用因特网文件***、网络文件***服务，将这些设备挂载(mount)到指定的目录，根据组装数据分不同的廉价磁盘冗余阵列、逻辑卷全部组装完成，直到所有设备都准备好为止，此时所有的硬件资源才准备完毕。

上文中，对网络协议地址接管模块20及服务接管模块22对故障主机的地址接管以及服务接管前的环境准备进行了说明。在上述服务接管过程中，服务接管模块22依照故障主机通过网络协议地址提供给客户端的服务来确定所有要接管的服务，并依照这些服务属性的不同而执行相应快速接管或者接管环境准备。但是在服务接管的准备过程中，对应服务的端口被关闭，这时如果通过上述网络协议地址访问此服务端口，则会造成服务被拒绝错误，导致客户端的访问出现问题，进而客户端会放弃此服务访问请求。因此，为了保证服务接管环境准备时，实现服务的无间断及透明接管，本发明的多主机服务接管***包含一请求处理模块26，以及时检测及了解某一待接管服务的环境准备是否完成。请求处理模块26可以通过命令调用或函数调用来实现服务环境或接管服务的准备完成判断，并当完成时给出一个返回值，以代表操作成功与否。或者，请求处理模块26通过在这些命令结束时在某个磁盘上写文件或标志，然后再去检测那个标志是否已经存在。即如果标志或文件存在，则服务需要的环境已经准备好，否则代表环境尚未准备好。但对于环境准备完成的判断本发明并不局限于上述方法，多种能达到这个目的的方法均可以使用。

请求处理模块26在某一待接管服务的环境准备过程中，不断检测服务环境准备的状态，判断服务是否已经正常接管，并对通过接管的多主机***的对外网络协议地址访问对应服务端口的请求进行处理。在服务环境准备未准备完全之前，请求处理模块26丢弃对此服务的访问请求数据包。由于访问请求在送达至相应服务端口之前被丢弃，***不会产生服务被拒绝的响应至客户端，客户端则因为没有收到响应而继续重新发送请求重试。

并且在服务接管模块22服务接管环境准备完全之后，接管服务后，打开对应服务端口。请求处理模块26同时停止对此服务端口的访问请求数据包的丢弃，开始接收发送此端口的访问请求数据包，进而实现了服务的对外正常提供。对于其它需要准备时间的待接管服务的访问，均通过上述方案实现服务的正常运行及功能的正常使用。

因此，在访问服务的客户端看来，服务实现了无间断、透明的接管，虽然访问服务的时间会暂时延缓，但最终服务并没有中断，数据没有丢失而保证了安全性及可靠性。

下面将结合图3对本发明的多主机***的服务接管方法作出说明，此图为本发明多主机***的服务接管方法的步骤流程图。本发明应用于包含一服务主机及至少一个待命主机的多主机***中，其中服务主机与至少一个待命主机之间通过心跳机制互相监控运作状态。在当前提供服务的服务主机发生故障时，其它待命主机通过心跳的方式检测到此故障主机的状态，因此其中一待命主机则执行对此故障主机的网络协议地址及提供服务的接管。由于有些类型的服务在接管时需要于接管主机提供所需的服务环境，在准备服务接管环境需花费一定的时间，因此多主机***的所有服务在服务接管/切换过程中没有或没有完全进入到正常工作的状态。

这里可以定义***的所有服务均完全进入到正常工作状态为“就绪”状态，即所有类型的服务已接收至上述接管故障主机的网络协议地址即服务的主机中，并能够对外提供完整、正常的服务，则称作整个多主机***进入了“就绪”状态。反之，如果***处于“保护”状态，则表示整个***在网络协议地址接管/服务接管过程中或其它故障切换过程中没有或没有完全进入到“就绪”状态。此外，定义服务“保护”状态是对于某些需要准备接管软硬件环境才能接管的服务，所采取的保护状态，即在服务环境准备未完成之前，服务不能接管而不能正常提供对外服务的状态。由于服务不能正常对外提供，因此在客户端访问此服务的请求到达对应服务端口之前，将此访问请求数据包丢弃。直至服务为“就绪”状态，即在完成服务接管环境准备之后接管服务，并能够正常对外提供服务时的状态。这时停止对相应服务端口的访问请求数据包的丢弃，开始接收发送此端口的访问请求数据包，实现服务的对外正常提供。

现在请参考图3，首先设置待命主机***的状态为保护状态(步骤102)，记录标志，同时设置待命主机***的所有服务为保护状态(步骤104)。所有服务为″保护″状态则可以通过简单的默认丢弃所有服务请求的方式达到访问请求处理的结果。上述状态步骤为本发明的重要部分，下面结合图4详细说明“保护”状态的***及服务的请求处理步骤。

图4为“保护”状态服务的访问请求处理流程示意图，当客户端访问此待命主机***时，处理客户端服务访问请求的流程如图所示。接收客户端发送对某一服务的访问请求至“保护”状态***(步骤202)，判断此服务是否处于“就绪”状态(步骤204)。如果服务没有处于“就绪”状态，即当前为″保护″状态则丢弃对此服务的访问请求数据包(步骤206)；否则，发送至相应服务进行处理(步骤208)。

对于“保护”状态的服务访问请求包丢弃具有多种实现方式，在Unix/Linux平台最简单的方法是使用iptables/netfilter实现，例如下面的指令可以丢弃所有发往“网络小型计算机***接口”服务的请求。

#iptables-A INPUT-p tcp--dport 3260-j DROP，其中3260是iSCSI的服务埠。

对于非“保护”状态服务，即服务处于“就绪”状态时，则取消对此服务的访问请求丢弃操作，即取消对服务的保护，而是要求服务处理此访问请求。例如取消访问请求包丢弃的指令为：

#iptables-D INPUT-p tcp--dport 3260-j DROP

#iptables-A INPUT-p tcp--dport 3260-j ACCEPT

上面两个过程将服务的“保护”状态去除，使***可以接收并处理上个步骤丢弃的发往“网络微型计算机***接口”的服务请求。

需要指出的是，这里只是给出实现上述操作的一概括实例，并非用以限定本发明的保护范围，能够实现上述操作的公知技术均可以应用于本发明中。

在设置***及服务为″保护″状态之后，接管故障主机对外提供服务的公共网络协议地址(步骤106)。关于网络协议地址的接管为公知技术，例如可参见开源项目(LVS，Linux Virtual Server)中网络协定接管的实现代码。然后，则可以接管各个服务。***提供了多个对外服务，对于不需要进行软硬件准备或准备时间极短的服务，***立刻可以提供。因此，判断需接管的服务是否需要执行服务接管环境准备(步骤108)，若不需要，则立即接管此服务(步骤110)。例如提供管理功能及提供网络功能的服务，这些服务基本与硬件资源无关，在网络协议地址正常提供后即能够对外提供。

关于步骤108中是否需要准备服务接管环境，可依据接管服务类型来判断，如果所提供的服务与储存空间或文件内容相关，例如网络小型计算机***接口(ISCSI)、文件传送协议(FTP)、超文本传输协议(HTTP)、网络文件***(NFS)、服务器信息区块/公用因特网文件***(SMB/CIFS)等等与存储空间或文件内容相关的服务，则需要时间准备服务环境；相反，对于纯网络服务，例如纯网络服务的动态主机配置协议(DHCP)、域名服务(DNS)等则不需要时间准备服务环境。

如上文所述，对于某些与硬件资源约定的服务，例如网络小型计算机***接口、文件传送协议等，由于需要服务接管环境准备因而不能立即提供，因此前进至步骤112，执行服务接管的资源环境准备步骤(步骤112)。关于环境准备的具体步骤下面将给出详细说明。

在执行服务接管的环境准备时，接管环境准备随服务类型的不同而不同，非常耗时的软硬件准备主要是与硬件或等待时间有关，而有些环境准备则需要等待一个超时时间。有些需准备的服务可能只需要更改配置文件或者更改路径等。对于服务接管则比较容易，只需要重新启动或启动本主机上的服务程序即可。

对于需要与硬件资源约定的服务，除保证故障后的接管服务的网络连接性外，还需要保证访问的空间与发生故障前访问的故障主机空间是相同的。否则用户访问空间会发生变化，导致不能正常提供服务。所以此类服务在故障切换前需要先将硬件准备好，然后才能提供真正的服务。当与硬件资源约定的接管服务为文件服务时，需提供与服务主机发生故障之前相同位置的文件存放空间；当接管服务为区块设备访问服务时，则准备与服务主机发生故障之前为同一访问服务区块设备的区块设备。

在接管服务的资源环境准备完成之后接管这个服务(步骤114)，然后此服务才进入“就绪”状态(步骤116)，并正常提供对外服务(步骤120)。这些接管耗时的服务在进行资源准备时的时间虽然很长，但因为一直处于***及服务的双重“保护”状态下，***对通过网络协议地址访问这个服务的所有请求，即网络协议数据包都会被丢弃掉，所以不会产生服务拒绝的消息，而客户端也会不断重试这种服务。参见图4的“保护”状态服务请求处理流程示意图。在这种情况下，无论是否需要时间准备的服务都将得到很好的接管。

在任一服务进入“就绪”状态(步骤116)后，会同时判断是否还有处于“保护”状态的服务(步骤118)，若没有，则整个***设置为“就绪”状态(步骤122)；否则，前进至步骤108，对其它处于“保护”状态的接管服务执行步骤108至步骤122。重复上述步骤，直至完成所有服务的接管，使其均处于“就绪”状态，即整个***处于“就绪”状态，因此这时对服务的访问请求将按照图5的“就绪”状态服务请求处理流程示意图的流程进行处理。

如图5所示，主机***接收对服务端口的访问请求(步骤302)，并直接发送至相应服务对此访问请求进行处理(步骤304)。这也是正常状态的处理流程，***在大部分时间处于这个状态，此时没有请求数据包被丢弃的处理。一旦整个***设置为“就绪”状态，上述网络协议接管步骤、服务接管及访问请求数据包丢弃的步骤则不再使用，而是由接管主机自动处理，直到再次发生故障切换时由上述步骤互相作用完成安全的故障切换。

通过上述说明可知，本发明不仅保证了具有快速切换特性的服务能够快速提供，同时保证了不能快速提供服务情况下客户端和服务器的连接不中断。此外，不仅保证了不能快速提供服务情况下等服务就绪后及时提供服务，且保证了将多种类型的服务集中于一个高可用性主机***上时多种服务的可靠性。在以上情况下执行服务故障接管时，能够带给用户真正的无间断、透明切换的多服务***及良好的用户体验。

虽然本发明以前述的较佳实施方式公开如上，然其并非用以限定本发明。本领域的普通技术人员应当意识到在不脱离本发明所附的权利要求书所公开的本发明的范围和精神的情况下，所作的更动与润饰，均包含在本发明的专利保护范围之内。关于本发明所界定的保护范围请参考所附的权利要求书。

Claims (12)

1.一种多主机***的服务接管***，应用于包含一服务主机及至少一个待命主机的多主机***中，该服务主机通过一对外网络协议地址对外提供服务，该待命主机处于待命状态，且该服务主机与该至少一个待命主机之间通过心跳机制互相监控运作状态，其中该服务接管***包含有：

一网络协议地址接管模块，其通过该心跳机制判断该服务主机的运作状态，并在该服务主机发生故障时发送一资源释放请求通知该服务主机释放其占有的该对外网络协议地址及服务，以接管该对外网络协议地址至其中一待命主机；

一服务接管模块，其用以准备接管该服务主机的服务至该待命主机所需的服务环境，以及接管该服务；以及

一请求处理模块，其检测该服务接管模块的服务环境准备状态，并且在该服务环境未准备完全之前，丢弃通过该对外网络协议地址对该服务的访问请求数据包。

2.如权利要求1所述的多主机***的服务接管***，其中该请求处理模块还包含一资源准备模块，用以生成与硬件资源约定的服务接管所需的服务环境。

3.如权利要求2所述的多主机***的服务接管***，其中该资源准备模块系提供接管该服务的网络连接，以及提供与该服务主机发生故障的前相同的访问空间。

4.如权利要求3所述的多主机***的服务接管***，其中该接管服务为文件服务时，该资源准备模块提供与该服务主机发生故障之前相同位置的文件存放空间。

5.如权利要求3所述的多主机***的服务接管***，其中该接管服务为区块设备访问服务时，该资源准备模块准备与该服务主机发生故障之前为同一访问服务区块设备的区块设备。

6.如权利要求1所述的多主机***的服务接管***，其中该服务接管模块判断接管该服务是否需要环境准备，如果不需要准备，则立即接管该服务；否则，该服务接管模块执行接管该服务所需的服务环境准备。

7.一种多主机***的服务接管方法，应用于包含一服务主机及至少一个待命主机的多主机***中，该服务主机与该至少一个待命主机之间通过心跳机制互相监控运作状态，该方法包含以下步骤：

通过该心跳机制判断该服务主机的故障状态，并当该服务主机发生故障时发送一资源释放请求通知该服务主机释放其占有的该对外网络协议地址及服务；

接管该服务主机释放的该对外网络协议地址至其中一待命主机；

准备接管该服务主机的服务至该待命主机所需的服务环境；

检测该服务环境的准备状态，在该服务环境未准备完全之前丢弃通过该对外网络协议地址对该服务的访问请求数据包；以及

在该服务环境准备完全之后接管该服务，并接收对该服务的访问请求数据包，以对外提供该服务。

8.如权利要求7所述的多主机***的服务接管方法，还包含生成与硬件资源约定的服务接管所需的服务环境的步骤。

9.如权利要求8所述的多主机***的服务接管方法，其中该准备服务环境的步骤包含下列步骤：

提供接管该服务的网络连接；以及

提供与该服务主机发生故障之前相同的访问空间。

10.如权利要求9所述的多主机***的服务接管方法，其中该接管服务为文件服务时，提供与该服务主机发生故障之前相同位置的文件存放空间。

11.如权利要求9所述的多主机***的服务接管方法，其中该接管服务为区块设备访问服务时，准备与该服务主机发生故障之前为同一访问服务区块设备的区块设备。

12.如权利要求7所述的多主机***的服务接管方法，其中在该准备该服务环境的步骤之前，还包含判断接管的该服务是否需要环境准备的步骤，如果不需要准备，则立即接管该服务；否则，准备接管该服务所需的该服务环境。

Images