CN108052371A - 基于虚拟化技术的铁路tdcs/ctc系统及其应用 - Google Patents

Abstract

本发明涉及一种基于虚拟化技术的铁路TDCS/CTC系统及其应用，包括：物理层L1，包括服务器设备、网络设备以及相关网络设备；虚拟化层L2，用于对物理层的计算资源以及网络、存储资源进行整合；应用层L3，直接运行在物理层上；管理层L4，用于针对CTC/TDCS应用的需求对资源进行按需分配，并根据CTC/TDCS上层应用的运行情况以虚拟机或容器为单位进行调度和控制。与现有技术相比，本发明将减少同样功能需求下CTC/TDCS系统对物理设备的需求，提高计算资源利用率并且降低系统成本。

Description

基于虚拟化技术的铁路TDCS/CTC系统及其应用

技术领域

本发明涉及一种铁路TDCS/CTC系统及其应用，尤其是涉及一种基于虚拟化技术的铁路TDCS/CTC系统及其应用。

背景技术

CTC(调度集中系统)/TDCS(列车调度指挥系统)是铁路行车指挥的核心系统，已在各个铁路局和车站普遍使用。铁路局CTC/TDCS中心系统由生产子系统、应急备用子系统、维护子系统、查询子系统以及相应的网络子系统组成，每个子系统中都包含服务器、终端以及网络设备。各个服务器都按照既定的角色或功能进行硬件配置的选择。例如，数据库服务器负责系统运行图、调度命令等历史数据存储，按照要求采用PowerPC架构的小型机；应用服务器负责系统核心逻辑处理，也采用PowerPC的小型机；通信前置服务器、TDCS接口服务器、RBC接口服务器、TSRS接口服务器、分界口接口服务器等接口服务器负责与相应外部系统接口并处理相关信息，此类服务器一般采用x86架构的服务器。系统中所有的服务器均采用双机冗余结构。其中，通信前置服务器、RBC接口服务器、TSRS接口服务器等服务器一般按线路设置，每条线路各设置一套。在新的线路接入中心时，一般需要增设应用服务器、通信前置服务器以及根据需求增设RBC、TSRS等接口服务器，所以在管辖线路较多的CTC/TDCS中心系统中，服务器数量比较可观。

目前各个路局的CTC/TDCS中心系统基本都采用这种结构，结合CTC/TDCS系统的应用现状和未来铁路发展对CTC/TDCS系统的需求，该结构存在以下问题：

1)可扩展性差。新线接入需要在中心增设应用服务器、通信前置服务器，对于C2/C3线路还需增设与RBC、TSRS等系统的接口服务器以及相应的机柜等设备。中心机房须预留有足够的空间来安装新增的服务器及机柜。

2)服务器负载不均衡，造成资源浪费。中心系统部分服务器仅仅负责一些简单的接口信息交互，服务器计算资源存在浪费的情况。

3)故障管理的灵活性和响应度低。系统中某台服务器因故障或宕机需要更换时，需人工拆卸更换。更换过程需要进行软件数据的备份和还原以及更换后的相关功能测试，所以耗时比较长，一般需在天窗点内进行。且如果在该服务器的另一系也出现故障或者宕机情况的话，则整个系统都将丧失该服务器相关的功能，甚至可能影响到调度指挥。

4)灾备方案实现复杂且低效。当系统发生严重故障或短时无法恢复故障影响到调度指挥时，需要启用灾备系统或应急备用系统，在目前的结构实现下，从生产系统到灾备系统的切换过程也只能由人工进行切换，切换时间长，对执行切换人员的技能要求也很高。

5)维护系统成本较高。对于系统中服务器和网络设备的日常维护和监控一般需要在目前的系统基础上通过增加软硬件的方式设置一套独立的运营维护系统来实现相关功能，也一定程度增加了系统建设成本。

发明内容

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种基于虚拟化技术的铁路TDCS/CTC系统及其应用。

本发明的目的可以通过以下技术方案来实现：

一种基于虚拟化技术的铁路TDCS/CTC系统，包括：

物理层L1，包括服务器设备、网络设备以及相关网络设备；

虚拟化层L2，用于对物理层的计算资源以及网络、存储资源进行整合；

应用层L3，直接运行在物理层上；

管理层L4，用于针对CTC/TDCS应用的需求对资源进行按需分配，并根据CTC/TDCS上层应用的运行情况以虚拟机或容器为单位进行调度和控制。

优选地，所述的管理层L4还集成灾备应急切换功能；同时，管理层L4还集成对监控和运维的支持，对上层应用和底层物理设备的运行情况和实时状态进行监控和跟踪。

优选地，所述的物理层L1设置独立的存储分组，存储分组被虚拟化之后由管理层L4统一进行管理和分配，供虚拟机或虚拟容器使用，实现了对应用层L3中各个CTC/TDCS应用的软件、数据和日志的集中存储和管理，有利于实现应急灾备方案和系统关键数据的备份。

优选地，所述的管理层L4包括：

虚拟机或容器管理模块a，用于实现对虚拟机或容器运行状态的监视，并在需要时执行资源控制调度模块d的命令来实现虚拟机或容器的启动、关闭、重启、迁移、复制的控制功能

应用监控模块b，用于实现对各个CTC/TDCS应用运行状态的监视，并在需要时执行资源控制调度模块d的命令来实现对CTC/TDCS应用的启动、关闭、软件数据更新的操作；

物理层监控模块c，用于实现对物理层服务器、存储以及网络的设备运行状态的监控，为资源调度模块d进行故障响应处理进行支撑；

资源控制调度模块d，用于负责根据应用需求对服务器、存储和网络的资源进行统一分配和管理，并根据虚拟机或容器管理模块a、应用监控模块b、物理层监控模块c的相关监视信息进行判断是否存在故障，按照设定的策略对故障进行自动处理或上报进行人工处理；

应用软件数据管理模块e，用于实现对各个CTC/TDCS应用软件数据的修改、更新、版本管理的功能；

维护支持模块f，用于实现对虚拟机或容器管理模块a、应用监控模块b、物理层监控模块c三个模块监视信息的处理和逻辑报警功能；

灾备控制模块g，该模块在设置灾备中心时使用，用于实现生产中心与灾备中心的信息交换功能，保持生产中心和灾备中心关键数据的一致性；

备份模块h，用于实现对整个系统包括物理层、虚拟化层、应用层、管理层的配置信息的定时备份，或接受人工命令进行人工备份。

优选地，所述的资源控制调度的对象是物理资源、虚拟机或虚拟容器以及CTC/TDCS应用，对资源进行控制和调度时要考虑物理设备分组的策略

一种基于虚拟化技术的铁路TDCS/CTC系统的应用，包括在TDCS/CTC系统中进行扩展新增应用、基于服务器负载平衡的虚拟机和容器调度、服务器故障响应、以及灾备应急响应。

优选地，所述的在TDCS/CTC系统中进行扩展新增应用具体包括：

步骤1，关于新增CTC/TDCS应用，对其CPU、内存和存储的需求进行评估；

步骤2，确认新增应用所在的服务器和存储分组，确认过程需新增应用的重要程度或者所属的CTC/TDCS运营指挥区域，需和物理设备分组的依据保持一致；

步骤3，按照步骤1和步骤2确定的应用需求和分组，在相应物理设备分组基础上通过虚拟化层以固定模板创建虚拟机或虚拟容器；

步骤4，在新建的虚拟机或虚拟容器中导入应用软件及数据，完成相关安装和调试工作。

优选地，所述的基于服务器负载平衡的虚拟机和容器调度具体过程如下：

步骤1，对物理服务器运行状态进行周期监视，包括服务器是否在线、服务器CPU和内存利用率；

步骤2，判断是否存在或者服务器负载过高的情况，当服务器CPU利用率持续3个监视周期大于80％时，或当服务器内存利用率连续3个监视周期大于90％时，判断为服务器负载过高；

步骤3，将判断结果发送给维护支持模块，维护支持模块进行报警通知维护人员；

步骤4，依据负载平衡调度策略判断是组内调度还是组外调度，然后再相应分组内寻找服务器负载较低的服务器；

步骤5，控制虚拟机或容器管理模块将负载较高服务器中运行的虚拟机或容器无缝迁移至已经确定的负载较低的服务器中；

步骤6，虚拟机或容器迁移完成，负载平衡调度完成。

优选地，所述的服务器故障响应具体为：

步骤1，对物理服务器运行状态进行周期监视，包括服务器是否在线；

步骤2，判断是否存在或者服务器故障的情况，当物理层监视模块连续3个周期以上获取不到服务器运行的相关状态信息时，判断服务器故障，并标记服务器为离线状态，离线状态服务器将不会被资源调度和控制模块使用；

步骤3，将判断结果发送给维护支持模块，维护支持模块进行报警通知维护人员；

步骤4，依据负载平衡调度策略判断是组内调度还是组外调度，然后再相应分组内寻找服务器负载较低的服务器，确定为目标服务器；

步骤5，控制虚拟机或容器管理模块在目标服务器中根据系统备份创建故障服务器中虚拟机或容器的副本，并启动运行；

步骤6，至此故障恢复完成，但故障服务器仍在离线状态，需人工根据实际故障情况维修或更换；

步骤7，人工维修或更换故障服务器；

步骤8，将维修或更换后的服务器加入虚拟化层，并标记为在线状态，资源调度和控制模块可再次使用该服务器进行资源调度。

优选地，所述的灾备应急响应具体为：

步骤1，生产系统和灾备系统的灾备控制模块进行通信，并将生产系统的系统配置和数据周期同步至灾备系统；

步骤2，是否需要启动灾备切换由人工进行判断，并需在灾备系统中输入相关命令，命令执行需要权限验证；

步骤3，灾备系统中的灾备控制模块启动灾备系统管理层；

步骤4，灾备系统根据同步来的系统配置和数据启动所有虚拟机或容器以及其中附带的CTC/TDCS应用；

步骤5，人工测试和确认灾备系统中硬件层、虚拟化层、CTC/TDCS应用层以及管理层运行正常；

步骤6，灾备系统正式对外提供调度指挥服务。

与现有技术相比，本发明具有以下优点：

1、本发明按照CTC/TDCS系统对计算资源的需求确定物理设备数量，与现有技术方案根据功能确定物理设备数量相比，将减少同样功能需求下CTC/TDCS系统对物理设备的需求，提高计算资源利用率并且降低系统成本；

2、本发明对服务器和存储等计算资源进行虚拟化及统一管理的设计使得当CTC/TDCS系统需要接入新的线路或增加新的CTC/TDCS应用时，可直接在现有计算资源基础上创建新的虚拟机或虚拟容器来完成相关任务，不用新增物理设备，提高了CTC/TDCS系统的可扩展性；

3、本发明对服务器和存储等计算资源进行虚拟化及统一管理的设计使得当某个物理设备发生故障时，可通过虚拟机或虚拟容器复制和迁移技术将相应的虚拟机或虚拟容器和CTC/TDCS应用复制或迁移到未发生故障的物理服务器上，提高了故障处理的灵活性和响应度；

4、本发明在管理层中集成对灾备控制的支持，利用虚拟机或虚拟容器可复制和可迁移的特性实现生产系统向灾备系统的切换，简化了灾备方案的设计；

5、本发明在管理层中集成对维护支持的支持，简化了CTC/TDCS维护支持子系统的设计降低了成本。

附图说明

图1为引入虚拟化技术后的系统分层结构示意图；

图2为物理层L1的结构示意图；

图3为管理层L4的结构示意图；

图4为在新技术方案中进行扩展新增应用的流程图；

图5为基于服务器负载平衡的虚拟机和容器调度的流程图；

图6为服务器故障响应的流程图；

图7为灾备应急响应的流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。

本发明的目的是在CTC/TDCS系统中引入虚拟化技术来设计一种新的系统架构和技术方案，针对性的解决上述问题。

本发明的目的可以通过以下技术方案来实现：

传统CTC/TDCS系统中，应用层直接运行在物理设备层上，引进虚拟化技术之后，将在应用层和物理设备层面引入新的虚拟化层以及管理层。引入虚拟化技术后的系统技术方案分层结构如图1所示。

在系统整体方案中，物理层L1主要由服务器设备、网络设备以及相关网络设备组成，虚拟化层L2主要实现对物理层服务器CPU、内存等计算资源以及网络、存储等资源的整合，管理层L4主要针对CTC/TDCS应用的需求对这些资源进行按需分配，并根据CTC/TDCS上层应用的运行情况以虚拟机或容器为单位进行调度和控制。管理层L4还集成灾备应急切换功能。同时，管理层也可集成对监控和运维的支持，对上层应用和底层物理设备的运行情况和实时状态进行监控和跟踪。

物理层L1的结构和配置相比现有方案有变化，如图2所示。为了便于虚拟化技术的应用，所有服务器设备都采用x86架构，而现有方案中根据服务器角色和功能的不同采用了不同架构的服务器，常见的有PowerPC和x86等。采用统一CPU架构的服务器提升了整个系统的可维护性。

本技术方案在物理层L1中设置独立的存储分组，存储分组被虚拟化之后由管理层L4统一进行管理和分配，供虚拟机或虚拟容器使用，实现了对应用层L3中各个CTC/TDCS应用的软件、数据和日志的集中存储和管理，有利于实现应急灾备方案和系统关键数据的备份。

管理层L4模块图如图3所示。分模块说明如下：

1)虚拟机或容器管理模块a，主要实现对虚拟机或容器运行状态的监视，并在需要时执行资源控制调度模块d的命令来实现虚拟机或容器的启动、关闭、重启、迁移、复制等控制功能；

2)应用监控模块b，主要实现对各个CTC/TDCS应用运行状态的监视，并在需要时执行资源控制调度模块d的命令来实现对CTC/TDCS应用的启动、关闭、软件数据更新等操作；

3)物理层监控模块c，主要实现对物理层服务器、存储以及网络等设备运行状态的监控，为资源调度模块d进行故障响应处理进行支撑；

4)资源控制调度模块d，负责根据应用需求对服务器、存储和网络等资源进行统一分配和管理，并根据模块a、b、c的相关监视信息进行判断是否存在故障，按照设定的策略对故障进行自动处理或上报进行人工处理；资源控制调度的对象是物理资源、虚拟机或虚拟容器以及CTC/TDCS应用，对资源进行控制和调度时要考虑物理设备分组的策略；

5)应用软件数据管理模块e，主要实现对各个CTC/TDCS应用软件数据的修改、更新、版本管理等功能；

6)维护支持模块f，主要实现对模块a、b、c三个模块监视信息的处理和逻辑报警功能；

7)灾备控制模块g，该模块在设置灾备中心时使用，主要实现生产中心与灾备中心的信息交换功能，保持生产中心和灾备中心关键数据的一致性；

8)备份模块h，主要实现对整个系统包括物理层、虚拟化层、应用层、管理层的配置信息的定时备份，也可接受人工命令进行人工备份。

新的技术方案有如下特点和功能：

1)物理设备层面，设置服务器、存储设备及交换机等相关网络设备，物理设备的数量根据CTC/TDCS系统当前和未来一段时间内对计算资源的需求进行确定；

2)服务器和存储设备可按照不同CTC/TDCS应用的重要性不同或用户对CTC/TDCS指挥运营区域的划分进行分组，分组间采用软件手段和网络手段进行一定的隔离和防护，增强系统的健壮性。分组的另一个作用是可以灵活的制定资源调度和控制策略，提升方案的灵活性；

3)引入虚拟化层，对服务器、存储等计算资源进行虚拟化，按照CTC/TDCS应用需求在物理计算资源基础上建立多个虚拟机或虚拟容器；

4)引入虚拟化管理层，对所有虚拟机或虚拟容器进行统一管理，负责虚拟机或虚拟容器以及相关计算资源的统一调度和控制。

5)在虚拟化管理层中集成灾备控制的支持，发生灾害后，虚拟化管理层可按照预先设定进行整个或者部分CTC/TDCS系统向灾备中心的迁移；

6)在虚拟化管理层中集成维护支持功能的支持。维护支持功能向下可采集到各个物理设备的运行状态，向上可获取到各个CTC/TDCS系统应用的运行状态。

实施例1，在新技术方案中新增CTC/TDCS应用：

如图4所示，在新技术方案中进行扩展新增应用包括以下步骤：

步骤401，对新增CTC/TDCS应用对CPU、内存和存储的需求进行评估。评估过程考虑应用的操作系统要求、工作负载、数据量以及应用日志占用的存储空间等因素。还应留有余量，余量应在评估基础上加10％左右；

步骤402，确认新增应用所在的服务器和存储分组，确认过程需新增应用的重要程度或者所属的CTC/TDCS运营指挥区域，需和物理设备分组的依据保持一致；

步骤403，按照步骤401和步骤402确定的应用需求和分组，在相应物理设备分组基础上通过虚拟化层以固定模板创建虚拟机或虚拟容器；

步骤404，在新建的虚拟机或虚拟容器中导入应用软件及数据，完成相关安装和调试工作。

实施例2，基于服务器负载平衡的虚拟机和容器调度：

如图5所示，基于服务器负载平衡的虚拟机和容器调度包括如下步骤：

步骤501，对物理服务器运行状态进行周期监视，包括服务器是否在线、服务器CPU和内存利用率，监视周期为30秒～5分钟。

步骤502，判断是否存在或者服务器负载过高的情况，当服务器CPU利用率持续3个监视周期大于80％时，或当服务器内存利用率连续3个监视周期大于90％时，判断为服务器负载过高；

步骤503，将判断结果发送给维护支持模块，维护支持模块进行报警通知维护人员；

步骤504，依据负载平衡调度策略判断是组内调度还是组外调度，然后再相应分组内寻找服务器负载较低(CPU、内存负载均小于50％)的服务器；

步骤505，控制虚拟机或容器管理模块将负载较高服务器中运行的虚拟机或容器无缝迁移至已经确定的负载较低的服务器中；

步骤506，虚拟机或容器迁移完成，负载平衡调度完成。

实施例3，服务器故障响应：

如图6所示，服务器故障响应包括如下步骤：

步骤601，对物理服务器运行状态进行周期监视，包括服务器是否在线，监视周期为30秒～5分钟。

步骤602，判断是否存在或者服务器故障的情况，当物理层监视模块连续3个周期以上获取不到服务器运行的相关状态信息时，判断服务器故障，并标记服务器为离线状态，离线状态服务器将不会被资源调度和控制模块使用；

步骤603，将判断结果发送给维护支持模块，维护支持模块进行报警通知维护人员；

步骤604，依据负载平衡调度策略判断是组内调度还是组外调度，然后再相应分组内寻找服务器负载较低(CPU、内存负载均小于50％)的服务器，确定为目标服务器；

步骤605，控制虚拟机或容器管理模块在目标服务器中根据系统备份创建故障服务器中虚拟机或容器的副本，并启动运行；

步骤606，至此故障恢复完成。但故障服务器仍在离线状态，需人工根据实际故障情况维修或更换；

步骤607，人工维修或更换故障服务器；

步骤608，将维修或更换后的服务器加入虚拟化层，并标记为在线状态，资源调度和控制模块可再次使用该服务器进行资源调度。

实施例4，灾备应急响应：

如图7所示，灾备应急响应包括如下步骤：

步骤701，生产系统和灾备系统的灾备控制模块进行通信，并将生产系统系统配置和数据周期同步至灾备系统，同步周期需根据配置和数据的重要性进行确定，关键数据如运行图、调度命令等可实时进行同步，非关键数据如日志等可每1～5天同步一次，如生产系统系统配置和数据进行了修改或更新则可立即同步；

步骤702，是否需要启动灾备切换由人工进行判断，并需在灾备系统中输入相关命令，命令执行需要权限验证；

步骤703，灾备系统中的灾备控制模块启动灾备系统管理层；

步骤704，灾备系统根据同步来的系统配置和数据启动所有虚拟机或容器以及其中附带的CTC/TDCS应用；

步骤705，人工测试和确认灾备系统中硬件层、虚拟化层、CTC/TDCS应用层以及管理层运行正常；

步骤706，灾备系统正式对外提供调度指挥服务。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种基于虚拟化技术的铁路TDCS/CTC系统，其特征在于，包括：

物理层L1，包括服务器设备、网络设备以及相关网络设备；

虚拟化层L2，用于对物理层的计算资源以及网络、存储资源进行整合；

应用层L3，直接运行在物理层上；

管理层L4，用于针对CTC/TDCS应用的需求对资源进行按需分配，并根据CTC/TDCS上层应用的运行情况以虚拟机或容器为单位进行调度和控制。

2.根据权利要求1所述的系统，其特征在于，所述的管理层L4还集成灾备应急切换功能；同时，管理层L4还集成对监控和运维的支持，对上层应用和底层物理设备的运行情况和实时状态进行监控和跟踪。

3.根据权利要求1所述的系统，其特征在于，所述的物理层L1设置独立的存储分组，存储分组被虚拟化之后由管理层L4统一进行管理和分配，供虚拟机或虚拟容器使用，实现了对应用层L3中各个CTC/TDCS应用的软件、数据和日志的集中存储和管理，有利于实现应急灾备方案和系统关键数据的备份。

4.根据权利要求1所述的系统，其特征在于，所述的管理层L4包括：

虚拟机或容器管理模块a，用于实现对虚拟机或容器运行状态的监视，并在需要时执行资源控制调度模块d的命令来实现虚拟机或容器的启动、关闭、重启、迁移、复制的控制功能

应用监控模块b，用于实现对各个CTC/TDCS应用运行状态的监视，并在需要时执行资源控制调度模块d的命令来实现对CTC/TDCS应用的启动、关闭、软件数据更新的操作；

物理层监控模块c，用于实现对物理层服务器、存储以及网络的设备运行状态的监控，为资源调度模块d进行故障响应处理进行支撑；

资源控制调度模块d，用于负责根据应用需求对服务器、存储和网络的资源进行统一分配和管理，并根据虚拟机或容器管理模块a、应用监控模块b、物理层监控模块c的相关监视信息进行判断是否存在故障，按照设定的策略对故障进行自动处理或上报进行人工处理；

应用软件数据管理模块e，用于实现对各个CTC/TDCS应用软件数据的修改、更新、版本管理的功能；

维护支持模块f，用于实现对虚拟机或容器管理模块a、应用监控模块b、物理层监控模块c三个模块监视信息的处理和逻辑报警功能；

灾备控制模块g，该模块在设置灾备中心时使用，用于实现生产中心与灾备中心的信息交换功能，保持生产中心和灾备中心关键数据的一致性；

备份模块h，用于实现对整个系统包括物理层、虚拟化层、应用层、管理层的配置信息的定时备份，或接受人工命令进行人工备份。

5.根据权利要求4所述的系统，其特征在于，所述的资源控制调度的对象是物理资源、虚拟机或虚拟容器以及CTC/TDCS应用，对资源进行控制和调度时要考虑物理设备分组的策略。

6.一种采用权利要求1所述的基于虚拟化技术的铁路TDCS/CTC系统的应用，其特征在于，包括在TDCS/CTC系统中进行扩展新增应用、基于服务器负载平衡的虚拟机和容器调度、服务器故障响应、以及灾备应急响应。

7.根据权利要求6所述的应用，其特征在于，所述的在TDCS/CTC系统中进行扩展新增应用具体包括：

步骤1，关于新增CTC/TDCS应用，对其CPU、内存和存储的需求进行评估；

步骤2，确认新增应用所在的服务器和存储分组，确认过程需新增应用的重要程度或者所属的CTC/TDCS运营指挥区域，需和物理设备分组的依据保持一致；

步骤3，按照步骤1和步骤2确定的应用需求和分组，在相应物理设备分组基础上通过虚拟化层以固定模板创建虚拟机或虚拟容器；

步骤4，在新建的虚拟机或虚拟容器中导入应用软件及数据，完成相关安装和调试工作。

8.根据权利要求6所述的应用，其特征在于，所述的基于服务器负载平衡的虚拟机和容器调度具体过程如下：

步骤1，对物理服务器运行状态进行周期监视，包括服务器是否在线、服务器CPU和内存利用率；

步骤2，判断是否存在或者服务器负载过高的情况，当服务器CPU利用率持续3个监视周期大于80％时，或当服务器内存利用率连续3个监视周期大于90％时，判断为服务器负载过高；

步骤3，将判断结果发送给维护支持模块，维护支持模块进行报警通知维护人员；

步骤4，依据负载平衡调度策略判断是组内调度还是组外调度，然后再相应分组内寻找服务器负载较低的服务器；

步骤5，控制虚拟机或容器管理模块将负载较高服务器中运行的虚拟机或容器无缝迁移至已经确定的负载较低的服务器中；

步骤6，虚拟机或容器迁移完成，负载平衡调度完成。

9.根据权利要求6所述的应用，其特征在于，所述的服务器故障响应具体为：

步骤1，对物理服务器运行状态进行周期监视，包括服务器是否在线；

步骤2，判断是否存在或者服务器故障的情况，当物理层监视模块连续3个周期以上获取不到服务器运行的相关状态信息时，判断服务器故障，并标记服务器为离线状态，离线状态服务器将不会被资源调度和控制模块使用；

步骤3，将判断结果发送给维护支持模块，维护支持模块进行报警通知维护人员；

步骤4，依据负载平衡调度策略判断是组内调度还是组外调度，然后再相应分组内寻找服务器负载较低的服务器，确定为目标服务器；

步骤5，控制虚拟机或容器管理模块在目标服务器中根据系统备份创建故障服务器中虚拟机或容器的副本，并启动运行；

步骤6，至此故障恢复完成，但故障服务器仍在离线状态，需人工根据实际故障情况维修或更换；

步骤7，人工维修或更换故障服务器；

步骤8，将维修或更换后的服务器加入虚拟化层，并标记为在线状态，资源调度和控制模块可再次使用该服务器进行资源调度。

10.根据权利要求6所述的应用，其特征在于，所述的灾备应急响应具体为：

步骤1，生产系统和灾备系统的灾备控制模块进行通信，并将生产系统的系统配置和数据周期同步至灾备系统；

步骤2，是否需要启动灾备切换由人工进行判断，并需在灾备系统中输入相关命令，命令执行需要权限验证；

步骤3，灾备系统中的灾备控制模块启动灾备系统管理层；

步骤4，灾备系统根据同步来的系统配置和数据启动所有虚拟机或容器以及其中附带的CTC/TDCS应用；

步骤5，人工测试和确认灾备系统中硬件层、虚拟化层、CTC/TDCS应用层以及管理层运行正常；

步骤6，灾备系统正式对外提供调度指挥服务。