CN103580883B - 一种业务容灾方法及系统 - Google Patents

Abstract

本发明公开了一种业务容灾方法及系统，检测到主机上有业务发生故障时，向该故障主机发起故障业务卸载请求；并根据维护的各主机的状态，寻找满足容灾条件的主机作为故障业务的目的主机，将故障业务加载到该目的主机上。采用本发明，可以最大限度的利用物理资源，减少运营商对业务的依赖，缩减成本，同时提高设备利用率和电信业务的稳定安全，减少故障率。

Description

一种业务容灾方法及系统

技术领域

本发明涉及通讯业务技术领域，更具体地，涉及一种业务容灾方法及系统。

背景技术

目前部分运营商规模较小，同时多业务运营；或者运营商规模很大，业务新推出处于成长期时，对于硬件需求很小，在满足需求的状况下，一台物理主机上可以加载多个业务节点，以使不同的用户运行多个业务。

由于此种情况下，上线业务的设备使用率都被大大提高，必然要求作为稳定性储备的热备容灾机器也能获得更高的利用率。

传统的安全模式是双机模式(即1+1)，通常用到的容灾模式采用N+m模式(1＜m＜＝N，N为该系统的增值业务数目，m为热备主机数目)。目前，平台的业务发生故障后，存在可靠性不够，恢复时过于依赖人为操作等问题。

综上所述，如果一台热备容灾主机可以对应多个业务进行容灾，则可以大大提升设备复用率，降低昂贵的设备投入，以有限的成本大大提升系统的可靠性。同时，需要屏蔽业务类型差异，在容灾机制上视为相同类型，对业务类型不做限制，减少机制的复杂性。

发明内容

本发明解决的技术问题是提供一种业务容灾方法及系统，可以最大限度的利用物理资源，减少运营商对业务的依赖，缩减成本，同时提高设备利用率和电信业务的稳定安全，减少故障率。

为解决上述技术问题，本发明提供了一种业务容灾方法，

检测到主机上有业务发生故障时，向该故障主机发起故障业务卸载请求；

并根据维护的各主机的状态，寻找满足容灾条件的主机作为所述故障业务的目的主机，将所述故障业务加载到所述目的主机上。

进一步地，通过主机状态链表维护所述各主机的状态，所述主机状态链表中保存的主机的状态包括：

空闲(free)，主机上无业务运行；

使用(used)，主机上有业务运行，但未达到主机上能支持的最大业务数；

锁定(locking)，主机上加载的业务已达到能支持的最大业务数，或者，主机上正在进行业务加载或者业务卸载操作。

进一步地，所述满足容灾条件，是指：

所述主机的状态为free或者used。

进一步地，所述满足容灾条件，还包括：

所述主机上不存在所述将要加载的所述故障业务。

进一步地，根据主机的资源及运算能力将主机上的资源划分多个业务资源位的最大业务数不超过该主机上的业务资源位。

进一步地，当所述故障主机上有多个业务发生故障时，进行多个故障业务串行容灾处理：对所述多个故障业务按既定规则进行排序，对所述序列中的故障业务逐个进行容灾；

当所述故障主机上所有业务均发生故障时，对所有故障业务进行多个故障业务串行容灾处理；或者，寻找free状态的、且业务资源位不少于所述故障业务数的目的主机，如果寻找到，则将所有故障业务并行容灾到该目的主机上，否则，对所有故障业务进行多个故障业务串行容灾处理。

进一步地，所述方法还包括：

根据容灾进行的结果对所述主机状态链表中所述故障主机及所述目的主机的状态进行更新。

进一步地，在容灾过程中，所述目的主机上加载业务时，

如果所述目的主机处于free链表，则在完成业务加载后，将所述目的主机的状态从free链表转移至used链表；

如果所述目的主机处于used链表且未达到能支持的最大业务数，则在完成业务加载后，当所述目的主机上加载的业务达到最大业务数时，则将所述目的主机的状态从used链表转移至locking链表。

进一步地，在容灾过程中，所述故障主机上卸载业务时，

卸载业务成功后，判断所述故障主机上是否还有业务，如果还有业务，则所述故障主机保持在used链表中；如果所述故障主机上没有其他业务，则将所述故障主机从used链表转移至free链表。

进一步地，所述方法还包括：

在进行业务加载或者业务卸载过程中，将主机切换到locking链表；

在完成业务加载或者业务卸载过程后，将主机从locking链表释放出来。

本发明还提供了一种业务容灾系统，所述系统包括：

配置管理数据库服务器，用于维护各主机的状态，及管理相关配置信息；

自动部署模块，用于对业务进行加载或者卸载；

调度中心，用于检测到主机上有业务发生故障时，通知所述自动部署模块向所述故障主机发起故障业务卸载请求；并根据各主机的状态，寻找满足设定的容灾条件的主机作为所述故障业务的目的主机，并通知所述自动部署模块将所述故障业务加载到所述目的主机上。

进一步地，所述系统还包括web运维管理中心，

所述web运维管理中心用于，用户界面化操作，连接并读写操作所述配置管理数据库服务器，展示各主机的状态，以及，当主机上有业务发生故障后进行相关告警。

进一步地，所述配置管理数据库服务器，用于通过主机状态链表维护所述各主机的状态。

所述主机状态链表中保存的主机的状态包括：空闲(free)，主机上无业务运行；使用(used)，主机上有业务运行，但未达到主机上能支持的最大业务数；锁定(locking)，主机上加载的业务已达到能支持的最大业务数，或者，主机上正在进行业务加载或者业务卸载操作；

所述调度中心设定的容灾条件，至少包括：所述主机的状态为free或者used；或者还包括：所述主机上不存在所述将要加载的所述故障业务。

进一步地，所述配置管理数据库服务器还用于，根据容灾进行的结果对所述主机状态链表中的所述故障主机及所述目的主机的状态进行更新。

采用本发明，至少具有如下有益效果：热备容灾主机/服务器可以划分多个逻辑意义上的业务资源位并提供给多个业务进行容灾，只需有限的物理主机数量，便可以实现在小业务量情况下的有效负荷分担，降低单点故障发生几率，有着较强的经济性和便利性；并且，通过多个业务资源位，屏蔽了不同类型主机的资源差异；其容灾模式与传统的N+m容灾模式相比较，可以在N值相同情况下使得m值控制的更小，比如m＝1即可对应解决N＝3的情况；同时，提升了容灾机制的健壮性，当由于网络、设备等因素造成业务容灾并发生容灾失败情况，该机制在一定时间内尝试进行多次容灾，直到容灾成功，在故障主机上，针对单业务故障和多业务故障都能有效运作实现容灾。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明实施例的业务容灾系统的示意图；

图2为本发明实施例的但主机多业务自动容灾方法的处理流程示意图。

具体实施方式

本实施方式提出一种在单物理主机上进行多业务自动容灾的方法，采用如下技术方案：

检测到主机上有业务发生故障时，向所述故障主机发起故障业务卸载请求；

并根据维护的各主机的状态，为所述故障业务寻找满足容灾条件的目的主机，将所述故障业务容灾到所述目的主机上。

其中，所述主机状态链表中保存有各主机的状态，所述主机的状态包括：

free(空闲)，主机上无业务运行；

used(使用)，主机上有业务运行，但未达到能支持的最大业务数；

locking(锁定)；主机上加载的业务达到能支持的最大业务数，或者，正在进行加载或者卸载操作。

其中，所述的能支持的最大业务数包括：运行、调度、容灾等的业务数。

其中，所述满足容灾条件，是指：

所述目的主机的状态为free，或者为used。

此外，在加载业务时，判断当前主机是否处于free或used链表，如果处于free链表、或者处于used链表且未达到能支持的最大业务数，则允许加载业务；否则，不允许加载业务。

进一步地，在加载业务时，如果主机处于free链表，则在完成业务加载后，将主机的状态从free链表转移至used链表；

如果处于used链表且未达到能支持的最大业务数，则在完成业务加载后，当主机上加载的业务达到最大业务数时，则将主机的状态从used链表转移至locking链表。

此外，上述方法，还包括：

卸载业务成功后，判断主机上是否还有业务，如果还有业务，则保持在used链表中；如果没有其他业务，则从used链表转移至free链表。

此外，上述方法，还包括：

在进行业务加载或者业务卸载过程中，将主机切换到locking链表；

在完成业务加载或者业务卸载过程后，将主机从locking链表释放出来。

本发明中，为描述的方便，首先定义几个名称：

业务资源位：在不影响业务性能情况下，一个物理主机上最多可运行的业务数量即定义为该主机上逻辑意义的业务资源位。

一般根据物理主机的资源和运算能力等估算可同时运行的业务节点数目，其中决定因素是主机各资源的短板。目前pc server/blade server单个物理主机建议不超过3个业务节点。

容灾也是针对物理主机上的逻辑资源位来进行，最多容灾业务数目不能超过该主机上的业务资源位。

另外，不建议在同一物理主机上加载重复的业务。

卸载：针对业务进行，包括停止业务、删除版本、删除用户、删除模块运行IP。

加载：针对业务进行，包括增加模块运行IP、增加用户、上传版本、启动业务。

下电：针对物理主机服务器进行，即断电操作power off。下电重启后可以清除加载业务时增加的浮动IP，使得业务主机回到初始状态。

上电：针对物理主机服务器进行，即启动操作power on。

本发明的自动容灾模式是在物理主机可以运行几个业务的前提下，针对物理主机上的逻辑资源位来进行，最多容灾业务数目不能超过该主机上的业务资源位。另外不建议在同一物理主机上加载重复的业务。具体包括以下几个关键点：

关键点1：

设置若干关于物理主机状态的链表：free/used/locking，且物理主机的状态会根据容灾进行的结果进行更新。

1、加载业务时，判断物理主机是否处于free或used链表，如果处于free链表允许加载业务，如果处于used链表且未达到能支持的最大业务数允许加载业务，若不满足以上条件不允许加载业务。

2、卸载业务成功后，判断物理主机上是否还有业务，如果还有业务则保持在used链表中，如果没有其他业务则从used转移至free链表。

也即，物理主机上只要存在业务就保持在used链表。

3、为防止在同一个物理主机上同时进行操作导致操作异常(如多个管理员同时加载业务)，要求手动加载和手动卸载操作过程中，都需要先将物理节点切换到locking链表，处于locking状态的主机不允许做其他操作。同时，要求针对一个物理主机在某个时间只能做一种操作；多个业务的加载也是按顺序进行。操作完后可以从locking状态释放出来。

此外，如果该物理主机上加载的业务达到最大业务节点数目，也加入locking链表，不能操作。

关键点2：

增加关于主机的状态标志位参数ifServDisaMode，1表明正在容灾，业务不可用，0表示正常状态；参数DisaStatus表明业务在容灾中所处的流程，在容灾过程中，业务的状态随时变更。具体示例见下表1所示：

表1主机及业务状态参数示例表

关键点3：

业务的具体部署内容通过业务部署脚本完成，剥离业务和自动部署的耦合性。业务部署脚本负责处理业务加载/卸载的所有步骤。加载包括增加IP、增加用户、解压业务包并启动；卸载包括停止业务、删除用户和删除IP。

业务的加载/卸载都是通过调用业务部署脚本实现，不同业务类型可以屏蔽业务区别。

更具体地，本实施方式所述的单个物理主机上对多个增值业务进行自动容灾的处理方法，主要包括以下步骤：

步骤1：设备主机上电，安装好操作系统、数据库等系统软件，基础网络配置完毕，每台主机配置好管理IP和管理账号密码；调度管理中心模块，自动部署模块、web运维管理中心模块运行正常。

步骤2：当前有空闲资源的主机若干，并且已经在调度管理中心注册成功。这些主机注册后会在调度管理中心初始化设置，加入free链表，并且记录业务资源位个数。

步骤3：调度管理中心设置为自动容灾模式。

步骤4：调度管理中心通过和各个主机之间固定周期内的心跳消息进行交互，一次心跳信息可以获取该主机上各个业务状态。

步骤5：假定某服务器类型最大有m个业务资源位，目前其中某物理主机有n个业务(1＝＜n＜＝m)，如果至少一个业务节点发生问题，意味着故障出现。典型情况下某主机上有多个业务，此处以典型情况n＞1说明。

步骤6：调度管理中心通过心跳检测到某物理主机上发生故障，故障业务数目x有如下组合：

Status1：x=1，一个业务出现故障，还有其他业务正常运行；

Status2：1＜x＜n，多个业务出现故障，还有其他业务正常运行；

Status3：x＝n，该物理主机上所有业务发生故障。

步骤7：卸载故障业务。

Status1：自动部署模块由向故障主机发起请求卸载该业务，卸载内容包括停止业务、删除IP和删除用户；如果卸载失败，则不会进行下一步容灾，直接跳到步骤10。

Status2：多个业务出现故障，依序发起多个卸载业务请求；业务1成功卸载，则跳到步骤8，其他业务继续卸载；业务1如若卸载失败，则给出告警，等待其他业务卸载信息报告。

Status3：具体操作同Status2；二者的差异主要在于，如果有一个业务卸载失败，则调度管理中心直接发起物理主机下电请求，恢复到原始状态，并加入free列表。

步骤8：容灾中心在free状态和used状态列表中的物理主机寻找足够的并且合适的业务资源位。

寻找资源位的实现策略可变，效率优先还是资源优先。此处以效率优先原则为例，优先寻找在链表查询当前是否有物理主机为free状态的主机；如果没有free状态的物理主机，查询used状态主机有没有空闲业务资源位。

Status1：查询到有free状态主机，则跳到下一步骤；如果没有free状态主机，查询到used状态的主机有空闲业务资源位，并且不存在将要容灾的这个业务，则跳到下一步骤。如果存在该业务，则转向下一个used主机查询；如果最终无法找到可以容灾的主机，则向运维中心告警，要求人工干预。

Status2：查询到有free状态主机，并发进行多业务容灾；

没有free状态主机，对于业务1，在used链表中依序查询主机，主机1不存在将要容灾的业务的主机，则对业务1进行容灾；如果存在相同业务，则转向下一个used主机2，依序查询；如果所有used主机都不符合容灾条件，则向运维中心告警，要求人工干预。其他业务依次进行。

另，查询业务资源位时，是先使用free主机还是used主机，可以根据实际情况制定策略，优化查询，合理利用有效资源。

如果存在至少一个业务没有足够的业务资源位，不能容灾的业务向运维中心进行告警，告警内容为当前没有可以容灾用的业务资源位，要求人工干预；

多个业务的容灾过程此处简化为单线程串行进行；实际可以制定策略多线程并发进行，提高效率。

Status3：某物理主机上所有业务发生故障，则进行整体容灾；查询存在free状态主机，按顺序进行并发多业务容灾；没有free状态主机，规则沿用status2。

步骤9：对满足条件的业务在目的主机上进行容灾。如果容灾成功，改变目的容灾主机和故障主机的状态。

1)如果故障物理主机有业务遗留，则保持used链表不变；如果没有业务，则从used链表移到free列表；如果出现网络故障，则由调度中心重启并加入free链表，进入热备机器序列。

2)如果目的容灾主机是在free链表，则移到used链表；如果是已有业务主机，则保持used链表不变；如果容灾后主机业务资源位用完，则移到locking链表。

3)如果业务容灾失败，转到步骤8，寻找下一个业务资源位进行容灾。具体容灾失败尝试次数可以设定。

步骤10：容灾结束。

为了便于阐述本发明，以下将结合附图及具体实施例对本发明技术方案的实施作进一步详细描述。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

图1中示出了了本发明实施例的业务容灾系统，该自动容灾系统主要由以下四个模块构成：

web运维管理中心：运行web服务器，连接配置管理数据库，以web页面登录，进行设备管理、版本管理、参数配置、界面展示，并可显示各个主机以及业务的状态，当设备发生故障后有相关告警等功能。以下也简称运维中心。

配置管理数据库服务器：负责储存主机设备的状态信息、业务资源位信息、业务状态信息及其他相关配置信息。

调度管理模块：与web运维管理中心子系统交互，完成页面操作显示和业务流程的转换；同时负责服务器的上下电。调度管理模块内部可进一步划分为多个功能子模块，比如：调度控制模块、检测模块、上下电模块等。调度中心和web运维管理中心采用内部消息接口交互。

自动部署模块：负责调用自动部署脚本进行具体的业务加载，卸载，启动，暂停操作。自动部署模块和调度管理模块采用内部消息接口交互。

图2以某物理主机上一个业务故障为例，描述了本发明实施例的业务容灾的流具体程，多个业务故障时的处理除对主机处理有差异外，与单个业务容灾流程基本一致。如图2所示，该流程具体描述如下：

步骤101：各个业务主机配置好FTP/SSH等相关网络服务。

步骤102：在运维中心模块上，进行热备业务主机注册，配置相关业务主机信息(管理IP，用户名和密码)，对热备业务主机进行信息初始化。

步骤103：调度管理模块的子模块-检测模块通过SSH方式与各个业务主机进行心跳检测，心跳周期具体可设置(一般设置为s秒)。

当检测模块接收到业务主机正常连通的响应后，会在设置的间隔时间内发送heartbeat查询该主机上所有业务的状态，返回值包括所有业务normal/fault状态。有一个业务状态失败，则返回失败。当查询返回失败后，根据间隔时间会再次进行查询，查询n次后(可设置，一般为3次)认为存在业务状态异常。调度中心通知自动部署模块向故障物理主机发送卸载业务请求。有几个故障业务发送几个业务卸载请求。

如果检测对方主机无法连通，则认为主机故障，所有业务认定为故障，需要整体容灾，并对故障主机做下电处理。这种方式相对简单，此处不详细描述。

步骤104：故障物理主机收到卸载业务请求后，执行脚本进行卸载业务uninstall操作。

如果当前的业务主机，只是该业务有问题，主机状态正常，则正常卸载。卸载失败则发出告警，跳出。

如果所有业务均有问题，收到所有业务的卸载请求，并且其中一个业务卸载失败，自动部署模块获取信息后会要求变更主机状态，发出下电请求，并且等待物理主机重启后再次注册成为容灾热备主机。

步骤105：自动部署模块收到卸载成功响应后，会进行数据库操作，将相关业务信息删除(如业务节点，模块号等)，并且通知web运维管理中心模块在页面展示上面将业务停止；

web运维管理中心模块在收到自动部署模块消息后，则会在页面展示上将业务状态变为停止。

步骤106：在进行完以上步骤后，自动部署模块按照给定策略进行目的业务资源位状态检测。

此处是以最简单的排序算法为例。优先寻找当前空闲的free链表主机，没有则会继续查找合适的used链表主机的业务资源位。如果没有合适的资源，则会向web运维管理中心模块发出告警信息。如果有多台used主机有合适业务资源位，自动部署模块则进行最优判断，查看所有主机中哪种方式排列组合作为被容灾主机最为合适，尤其存在多业务容灾的时刻。

需要说明的是，业务资源位寻找可以应用不同策略进行算法优化。比如有几个业务故障，优先寻找对应有几个业务资源位的主机进行并发容灾；比如目的主机上已经存在某故障业务类型，需要优化只针对其他不同业务进行容灾。

步骤107：选定好空闲业务资源位后，调度管理中心向自动部署模块发起业务加载请求，将目的业务资源位相关信息及业务加载请求(管理IP，逻辑IP，模块号，业务类型，版本包和用户名等)发送给自动部署模块。

注意：容灾加载的业务逻辑IP和模块号等信息与卸载的故障业务信息相同，才能达成无缝切换目的；差异在于加载的目的主机管理IP不同。

步骤108：自动部署模块根据请求加载业务。具体步骤包括向目的业务资源位所在主机上传自动部署脚本和版本包，执行安装脚本创建用户、增加IP，解压版本包并启动业务进程，成功后回部署成功响应。

如果主机原因造成部署某步骤或整体失败，会在该目的主机上删除用户及业务相关文件，恢复主机原样，同时返回部署失败响应。

步骤109：如果调度管理模块收到目的主机返回部署成功响应，会将逻辑设备和物理设备信息入库。同时发送加载业务结果通知请求给运维模块。运维模块在收到加载业务结果通知请求后，会在页面上进行相关展示。同时回加载业务结果响应给调度管理模块。容灾流程结束。

步骤110：如果调度管理模块收到目的主机返回部署失败响应，会进行下一轮尝试，从步骤106循环开始。尝试次数可预先设定。

以上仅为本发明的优选实施案例而已，并不用于限制本发明，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员可根据本发明做出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

Claims (12)

1.一种业务容灾方法，其特征在于，根据主机的资源及运算能力将主机上的资源划分的最大业务数不超过该主机上的业务资源位；所述业务资源位是指在不影响业务性能情况下，一个物理主机上最多可运行的业务数量；

检测到主机上有业务发生故障时，向故障主机发起故障业务卸载请求；

并根据维护的各主机的状态，寻找满足容灾条件的主机作为所述故障业务的目的主机，将所述故障业务加载到所述目的主机上；

通过主机状态链表维护所述各主机的状态，所述主机状态链表中保存的主机的状态包括：

空闲free，主机上无业务运行；

使用used，主机上有业务运行，但未达到主机上能支持的最大业务数；

锁定locking，主机上加载的业务已达到能支持的最大业务数，或者，主机上正在进行业务加载或者业务卸载操作。

2.如权利要求1所述的方法，其特征在于，所述满足容灾条件，是指：

所述主机的状态为free或者used。

3.如权利要求2所述的方法，其特征在于，

所述满足容灾条件，还包括：

所述主机上不存在将要加载的所述故障业务。

4.如权利要求1所述的方法，其特征在于，

当所述故障主机上有多个业务发生故障时，进行多个故障业务串行容灾处理：对所述多个故障业务按既定规则进行排序，对序列中的故障业务逐个进行容灾；

当所述故障主机上所有业务均发生故障时，对所有故障业务进行多个故障业务串行容灾处理；或者，寻找free状态的、且业务资源位不少于故障业务数的目的主机，如果寻找到，则将所有故障业务并行容灾到该目的主机上，否则，对所有故障业务进行多个故障业务串行容灾处理。

5.如权利要求1所述的方法，其特征在于，所述方法还包括：

根据容灾进行的结果对所述主机状态链表中所述故障主机及所述目的主机的状态进行更新。

6.如权利要求1或5所述的方法，其特征在于，在容灾过程中，所述目的主机上加载业务时，

如果所述目的主机处于free链表，则在完成业务加载后，将所述目的主机的状态从free链表转移至used链表；

如果所述目的主机处于used链表且未达到能支持的最大业务数，则在完成业务加载后，当所述目的主机上加载的业务达到最大业务数时，则将所述目的主机的状态从used链表转移至locking链表。

7.如权利要求1或5所述的方法，其特征在于，在容灾过程中，所述故障主机上卸载业务时，

卸载业务成功后，判断所述故障主机上是否还有业务，如果还有业务，则所述故障主机保持在used链表中；如果所述故障主机上没有其他业务，则将所述故障主机从used链表转移至free链表。

8.如权利要求1所述的方法，其特征在于，所述方法还包括：

在进行业务加载或者业务卸载过程中，将主机切换到locking链表；

在完成业务加载或者业务卸载过程后，将主机从locking链表释放出来。

9.一种业务容灾系统，其特征在于，所述系统包括：

配置管理数据库服务器，用于维护各主机的状态，及管理相关配置信息；

所述配置管理数据库服务器，用于通过主机状态链表维护所述各主机的状态；

所述主机状态链表中保存的主机的状态包括：空闲free，主机上无业务运行；使用used，主机上有业务运行，但未达到主机上能支持的最大业务数；锁定locking，主机上加载的业务已达到能支持的最大业务数，或者，主机上正在进行业务加载或者业务卸载操作；

自动部署模块，用于对业务进行加载或者卸载；

调度中心，用于检测到主机上有业务发生故障时，通知所述自动部署模块向故障主机发起故障业务卸载请求；并根据各主机的状态，寻找满足设定的容灾条件的主机作为所述故障业务的目的主机，并通知所述自动部署模块将所述故障业务加载到所述目的主机上；

主机上的根据主机的资源及运算能力划分的最大业务数不超过该主机上的业务资源位；所述业务资源位是指在不影响业务性能情况下，一个物理主机上最多可运行的业务数量。

10.如权利要求9所述的系统，其特征在于，所述系统还包括web运维管理中心，

所述web运维管理中心用于，用户界面化操作，连接并读写操作所述配置管理数据库服务器，展示各主机的状态，以及，当主机上有业务发生故障后进行相关告警。

11.如权利要求9或10所述的系统，其特征在于，

所述调度中心设定的容灾条件，至少包括：所述主机的状态为free或者used；或者还包括：所述主机上不存在将要加载的所述故障业务。

12.如权利要求11所述的系统，其特征在于，

所述配置管理数据库服务器还用于，根据容灾进行的结果对所述主机状态链表中的所述故障主机及所述目的主机的状态进行更新。