CN104657240B - 多内核操作系统的失效控制方法及装置 - Google Patents

Abstract

本发明实施例公开了一种多内核操作系统的失效控制方法及装置。其中，方法包括：确定操作系统内的重核心内核以及多个轻核心内核；在重核心内核和多个轻核心内核上运行相应的系统服务，重核心内核以及多个轻核心内核均保存有所有内核的状态信息；监测重核心内核和多个轻核心内核的状态；当重核心内核出现故障时，则在多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至新的重核心内核上，由新的重核心内核和多个轻核心内核更新相应内核的状态信息；当轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，由重核心内核和多个轻核心内核更新相应内核的状态信息。

Description

多内核操作系统的失效控制方法及装置

技术领域

本发明涉及计算机处理技术领域，特别是涉及一种多内核操作系统的失效控制方法及装置。

背景技术

随着计算机技术的发展，一个计算机系统中集成多种计算设备成为趋势。如何有效地管理这类系统，充分利用系统提供的丰富资源，同时保证系统的使用效率，提高系统的可用性，使得系统中在一部分部件发生失效时，整个系统仍能提供服务是一个关键问题。

操作系统是一个控制其他程序运行，管理系统资源并为用户提供操作界面的系统软件的集合。操作系统完成内存管理、进程管理、输入与输出设备管理、网络与文件系统管理等任务。

随着计算机技术的发展，一个计算机系统中集成多种计算设备成为趋势。针对多计算设备的计算机系统，多内核是一种流行的操作系统设计方法。内核是一个操作系统的核心。内核主要负责管理系统的进程、内存、设备驱动程序、文件和网络系统的基本管理操作，内核决定着系统的性能和稳定性。在多内核操作系统中，操作系统由多个内核构成，系统的每个CPU上部署一个内核，内核上面部署提供对外接口的系统服务，如：文件系统、通信系统，从而形成一个完整的操作系统。

现有技术中，针对多内核系统，一种管理方式是：采用主从核心的设计思想，即将内核分为主核心、从核心，主核心负责管理其他的从核心。该种管理方式下，主核心接收到应用程序，根据应用程序的目标指令集，以及主核心和各从核心中的当前负载量，从主核心和多个从核心中选择一个核心为应用程序的目标核心；由被选出的目标核心为从核心加载所述应用程序，并运行所述应用程序。

然而，该种管理方式下，如果主核心失效，整个系统无法使用。当主核心失效时，从核心无法通过主核心加载所述应用程序，导致整个系统无法加载应用程序。因此，主核心是整个系统的单一失效点，主核心的故障或主核心上计算设备的故障会导致整个系统的不可用。

另一种内核系统的管理方式是：采用多核心的设计思想，不将多内核进行分类，而是在每个CPU或CPU的处理核上部署一个核心，核心之间完全对等，需要进行资源协调时，通过协商协议实现管理功能。具体地，多个核心之间需要通过多阶段提交协议来保证状态一致性。然而，该种管理方式下，没有考虑某个核心失效后的故障处理和可用性问题。

可见，现有技术中，对于多内核系统，暂时缺乏相应的失效管理机制。

发明内容

本发明实施例中提供了一种多内核操作系统的失效控制方法及装置，实现在部分内核失效的情况下，整个多内核操作系统仍能维持正常工作状态。

为了解决上述技术问题，本发明实施例公开了如下技术方案：

第一方面，提供一种多内核操作系统的失效控制方法，包括：

确定操作系统内的重核心内核以及多个轻核心内核；

在所述重核心内核和多个轻核心内核上运行相应的系统服务，所述重核心内核以及多个轻核心内核均保存有所有内核的状态信息；

监测所述重核心内核和多个轻核心内核的状态；

当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上，由所述新的重核心内核和多个轻核心内核更新相应内核的状态信息；当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，由所述重核心内核和多个轻核心内核更新相应内核的状态信息。

结合上述第一方面，在第一种可能的实现方式中，所述确定操作系统内的重核心内核以及多个轻核心内核，包括：

将操作系统内第一个启动的内核确定为所述重核心内核，将其余内核确定为所述轻核心内核。

结合上述第一方面，在第二种可能的实现方式中，所述在所述重核心内核和多个轻核心内核上运行相应的系统服务，包括：

所述重核心内核接收系统服务发送的注册请求消息，并运行接收到的系统服务；

所述重核心内核向所述多个轻核心内核广播所接收的系统服务注册信息，指定运行系统服务的相应轻核心内核；

所述重核心内核接收所述多个轻核心内核发送的注册回应消息，通知所述系统服务至所述相应轻核心内核进行注册，以便所述相应轻核心内核运行所述系统服务。

结合上述第一方面，和第二种可能的实现方式，在第三种可能的实现方式中，所述在所述重核心内核和多个轻核心内核上运行相应的系统服务，还包括：

所述重核心内核接收系统服务发送的退出请求消息，并将本地保存的系统服务进行删除；

所述重核心内核向所述多个轻核心内核广播所接收的系统服务退出信息；

所述重核心内核接收所述多个轻核心内核发送的退出回应消息，由所述多个轻核心内核在将本地保存的系统服务进行删除；

所述重核心内核通知所述系统服务进行退出。

结合上述第一方面，在第四种可能的实现方式中，所述监测所述重核心内核和多个轻核心内核的状态，包括：

所述重核心内核或多个轻核心内核向各自的前继节点内核发送心跳信息；

当所述重核心内核或多个轻核心内核的前继节点内核在预置时间内未接收到所述心跳信息，则确定所述重核心内核或轻核心内核出现故障。

结合上述第一方面，在第五种可能的实现方式中，所述当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，包括：

当所述重核心内核出现故障时，由所述多个轻核心内核选择出负载最小的轻核心内核，由所述负载最小的轻核心内核作为所述新的重核心内核。

结合上述第一方面，和第一至第五种可能的实现方式，在第六种可能的实现方式中，所述将原重核心内核上运行的系统服务转移至所述新的重核心内核上，包括：

所述新的重核心内核根据自身保存的所有内核的状态信息，获知所述原重核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

结合上述第一方面，和第一至第五种可能的实现方式，在第七种可能的实现方式中，所述当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，包括：

所述重核心内核确定出接收所述故障轻核心内核上运行的系统服务的正常轻核心内核；所述正常轻核心内核根据自身保存的所有内核的状态信息，获知所述故障轻核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

第二方面，提供一种多内核操作系统的失效控制装置，包括：

核心确定模块，用于确定操作系统内的重核心内核以及多个轻核心内核；

服务运行模块，用于在所述重核心内核和多个轻核心内核上运行相应的系统服务，所述重核心内核以及多个轻核心内核均保存有所有内核的状态信息；

状态监测模块，用于监测所述重核心内核和多个轻核心内核的状态；

第一故障处理模块，用于当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上，由所述新的重核心内核和多个轻核心内核更新相应内核的状态信息；

第二故障处理模块，用于当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，由所述重核心内核和多个轻核心内核更新相应内核的状态信息。

结合上述第二方面，在第一种可能的实现方式中，所述核心确定模块，包括：

重核心内核确定单元，用于将操作系统内第一个启动的内核确定为所述重核心内核；

轻核心内核确定单元，用于将其余内核确定为所述轻核心内核。

结合上述第二方面，在第二种可能的实现方式中，所述服务运行模块，包括：

第一运行单元，用于所述重核心内核接收系统服务发送的注册请求消息，并运行接收到的系统服务；

轻核心内核指定单元，用于所述重核心内核向所述多个轻核心内核广播所接收的系统服务注册信息，指定运行系统服务的相应轻核心内核；

第二运行单元，用于所述重核心内核接收所述多个轻核心内核发送的注册回应消息，通知所述系统服务至所述相应轻核心内核进行注册，以便所述相应轻核心内核运行所述系统服务。

结合上述第二方面，和第二种可能的实现方式，在第三种可能的实现方式中，所述服务运行模块，还包括：

第一服务删除单元，用于所述重核心内核接收系统服务发送的退出请求消息，并将本地保存的系统服务进行删除；

服务退出信息广播单元，用于所述重核心内核向所述多个轻核心内核广播所接收的系统服务退出信息；

第二服务删除单元，用于所述重核心内核接收所述多个轻核心内核发送的退出回应消息，由所述多个轻核心内核在将本地保存的系统服务进行删除；

退出通知单元，用于所述重核心内核通知所述系统服务进行退出。

结合上述第二方面，在第四种可能的实现方式中，所述状态监测模块，包括：

心跳信息发送单元，用于所述重核心内核或多个轻核心内核向各自的前继节点内核发送心跳信息；

故障确定单元，用于当所述重核心内核或多个轻核心内核的前继节点内核在预置时间内未接收到所述心跳信息，则确定所述重核心内核或轻核心内核出现故障。

结合上述第二方面，在第五种可能的实现方式中，当所述重核心内核出现故障时，所述第一故障处理模块确定出新的重核心内核，具体为：由所述多个轻核心内核选择出负载最小的轻核心内核。

结合上述第二方面，和第一至第五种可能的实现方式，在第六种可能的实现方式中，所述第一故障处理模块触发时，所述新的重核心内核根据自身保存的所有内核的状态信息，获知所述原重核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

结合上述第二方面，和第一至第五种可能的实现方式，在第七种可能的实现方式中，所述第二故障处理模块触发时，所述重核心内核确定出接收所述故障轻核心内核上运行的系统服务的正常轻核心内核；所述正常轻核心内核根据自身保存的所有内核的状态信息，获知所述故障轻核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

本发明实施例中，将操作系统内的内核划分为一个重核心内核和多个轻核心内核，在所述重核心内核和多个轻核心内核上运行相应的系统服务，并监测所述重核心内核和多个轻核心内核的状态，当监测结果发现有内核出现故障时，则进行相应的故障处理，包括：当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上；当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他轻核心内核。使得在部分内核失效的情况下，整个多内核操作系统仍能维持正常工作状态，因此，大大提高操作系统的可用性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明提供的一个多内核操作系统的失效控制方法实施例的流程；

图2为本发明实施例中的内核部署示意图；

图3为本发明提供的一个构建核心组的实施例流程图；

图4为图1中步骤102的实现流程示意图；

图5为本发明提供的一个系统服务退出内核的实施例流程图；

图6为图1中步骤103的实现流程示意图；

图7为本发明提供的心跳信息传输示意图；

图8为本发明提供的一个应用场景示意图；

图9为本发明提供的另一个应用场景示意图；

图10为本发明提供的一种多内核操作系统的失效控制装置的实施例结构图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例中的技术方案，并使本发明实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本发明实施例中技术方案作进一步详细的说明。

参见图1，为本发明提供的一个多内核操作系统的失效控制方法实施例的流程，具体可以包括：

步骤101、确定操作系统内的重核心内核以及多个轻核心内核。

如图2所示，为本发明实施例中的内核部署示意图。在每个CPU上部署一个OS（Operating System，操作系统）核心内核（以下简称为“核心”），在OS核心的基础上部署系统服务，即OS服务。OS核心监控本地的OS服务状态，OS核心可以组成一个组---核心组，该核心组成员包括：重核心内核（以下简称为“重核心”）以及轻核心内核（以下简称为“轻核心”），在一个核心组中重核心只有一个，轻核心可以有多个；轻核心负责本地资源的管理，即其上运行的进程的管理，和其对应的CPU、内存的管理，以及需要全局资源访问时的管理，如访问全局磁盘；重核心除了具有轻核心的功能外，还具有组管理的功能，即管理整个核心组，主要包括：更新成员状态信息和仲裁轻核心是否失效。

步骤102、在所述重核心内核和多个轻核心内核上运行相应的系统服务，所述重核心内核以及多个轻核心内核均保存有所有内核的状态信息。

本发明实施例中，重核心和多个轻核心上分别运行相应的OS服务，OS服务为提供对外接口的系统服务，如：文件系统、通信系统等。OS服务可以以进程的方式运行在OS核心之上，OS服务通过注册的方式实现在OS核心之上的运行，OS服务在各个核心上的分配可以采用轮训的分配方式，例如：按照Round Robin的方式在多个核心上循环分配。

此外，重核心和多个轻核心上均保存有所有内核的状态信息。具体实现中，OS核心组成员维护一致视图，该视图内容可以包括：1）成员信息；2）系统服务信息；3）系统关键事件信息。

其中，成员信息具体可以包括：成员的编号、成员所处的CPU编号、当前的状态、角色信息、重核心ID信息；成员编号可以是从0开始的整数；成员所处的CPU编号记录成员运行在哪一个CPU上，它是成员之间互相通信的判断标志；当前状态可以包括：运行、离开；角色信息记录当前内核为轻核心还是重核心；重核心ID信息包括重核心的ID；OS服务信息具体可以包括：服务名称、服务ID、所处内核的ID、当前服务的状态；系统关键事件信息，例如：系统异常事件信息，包括：系统服务在一定时间间隔内被频繁重启，通常，系统关键事件信息可以以字符串的形式进行记录。

步骤103、监测所述重核心内核和多个轻核心内核的状态。

本发明实施例中，在多内核操作系统中引入失效管理机制，其中，失效监测是失效管理机制中的一个关键环节，通过失效监测，监测重核心和多个轻核心的状态，以便在重核心或轻核心发生故障时，及时进行有效的故障恢复。

步骤104、当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上，由所述新的重核心内核和多个轻核心内核更新相应内核的状态信息；当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，由所述重核心内核和多个轻核心内核更新相应内核的状态信息。

该步骤中，当监测结果发现重核心或轻核心发生故障时，及时进行有效的故障恢复。故障恢复原则基本为：将故障核心上运行的系统服务转移至其他非故障核心之上。

具体地，当重核心出现故障时，则在多个轻核心中确定出新的重核心，将原重核心上运行的系统服务转移至新的重核心上，并且，由新的重核心和多个轻核心更新各自保存的所有内核的状态信息中发生变化的内核的状态信息。

而当轻核心出现故障时，则将故障轻核心上运行的系统服务转移至其他正常轻核心，并且，由重核心和多个轻核心内核更新各自保存的所有内核的状态信息中发生变化的内核的状态信息。

本发明实施例中，将操作系统内的内核划分为一个重核心内核和多个轻核心内核，在所述重核心内核和多个轻核心内核上运行相应的系统服务，并监测所述重核心内核和多个轻核心内核的状态，当监测结果发现有内核出现故障时，则进行相应的故障处理，包括：当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上；当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他轻核心内核。使得在部分内核失效的情况下，整个多内核操作系统仍能维持正常工作状态，因此，大大提高操作系统的可用性。

为了便于对本发明技术方案的理解，下面通过具体实施方式，对本发明技术方案进行详细说明。

本发明实施例中，上述步骤101中，可以将操作系统内第一个启动的内核确定为重核心，将其余内核确定为轻核心。确定出的重核心和其余轻核心可以组成一个核心组。

参见图3，为本发明提供的一个构建核心组的实施例，具体可以包括以下流程：

步骤301、将操作系统内第一个启动的内核确定为重核心，将其余内核确定为轻核心；

步骤302、轻核心向重核心发送加入核心组的加入请求；

步骤303、重核心根据加入请求，将相应轻核心增加至核心组，并向相应的轻核心发送成功加入核心组的指示信息；

步骤304、轻核心根据接收到的成功加入核心组的指示信息，向重核心发送应答消息，表示得知已加入核心组；

步骤305、当重核心收到所有发送加入请求的轻核心发送的应答消息，则更新当前的组成员信息，核心组初始化成功。

在图4所示的一个优选实施例中，描述了上述步骤102的具体实现流程，具体可以包括以下执行步骤：

步骤401、重核心接收系统服务发送的注册请求消息，并运行接收到的系统服务；

该步骤中，系统服务向重核心发送注册请求消息，以便该系统服务能够在重核心上运行，重核心根据收到系统服务发送的该注册请求消息，可以为该系统服务分配服务ID。

步骤402、重核心向多个轻核心内核广播所接收的系统服务注册信息，指定运行系统服务的相应轻核心内核；

步骤403、接收多个轻核心内核发送的注册回应消息，通知系统服务至相应轻核心内核进行注册，以便相应轻核心内核运行所述系统服务。

该步骤中，通常，轻核心接收到重核心广播的系统服务注册信息，需要向重核心发送注册回应消息，从而，重核心可以根据该轻核心发送的注册回应消息，获知该轻核心已做好运行系统服务的准备，则重核心可以通知系统服务至该轻核心进行注册，实现在该轻核心上运行系统服务。对于接收到重核心广播的系统服务注册信息、却未向重核心发送注册回应消息的轻核心，则被重核心确定为发生故障，进而执行故障恢复操作。对于具体故障恢复操作，后面再做详细说明。

此外，在系统服务运行的过程中，每个核心可以监测本地运行的系统服务的状态，例如：定期查看操作系统服务进程的状态，如果在系统服务未申请退出的情况下进程消失，则该内核自动恢复该系统服务进程。

上面实施例描述的是在内核上注册系统服务的流程，图5所示，为本发明提供的一个系统服务退出内核的实施例，具体可以包括以下流程：

步骤501、重核心接收系统服务发送的退出请求消息，并将本地保存的系统服务进行删除；

当系统服务需要退出时，系统服务向重核心发送退出请求消息，重核心收到该退出请求消息，将本地保存的该系统进行删除，此外，重核心还可以将本地保存的该系统服务的服务信息进行删除。

步骤502、重核心向多个轻核心广播所接收的系统服务退出信息；

重核心删除本地保存的该系统服务之后，向多个轻核心广播所接收的系统服务退出信息。

步骤503、重核心接收多个轻核心发送的退出回应消息，由多个轻核心在将本地保存的系统服务进行删除。

轻核心接收到系统服务退出消息之后，将本地保存的该系统服务进行删除，并向重核心发送退出回应消息。

步骤504、重核心通知所述系统服务进行退出。

当重核心接收到所有轻核心发送的退出回应消息，获知所有轻核心已成功将各自本地保存的系统服务进行删除，重核心通知该系统服务可以进行退出，则该系统服务退出。

需要说明的是，本发明实施例中，核心组成员之间的通信采用基于PCIE或HT总线标准的通信链路的广播机制。任意2个核心之间可以利用基于PCIE或HT的通信链路实现互相的点对点通信，在点对点通信的基础上，封装广播接口，接口的形式可以为Kernel_Broadcast(MSG),通过该接口，重核心可以实现向核心组内的所有成员发送消息，并通过该接口接收轻核心发送的回应消息。

需要广播的消息具体可以包括：内核的状态信息，例如：成员信息、系统服务信息以及系统关键事件信息。

本发明实施例中，如图6所示，描述了上述步骤103的具体实现流程，具体可以包括：

步骤601、重核心或多个轻核心向各自的前继节点内核发送心跳信息。

如图7所示，在核心组中，重核心和多个轻核心组成一个逻辑环，每个内核成员向各自的前继节点内核（例如：顺时针方向的下一个节点）发送心跳消息，发送心跳消息的介质采用基于PCIE或HT的通信链路，同时，每个内核接收逻辑环上后续节点（顺时针方向的上一个节点）成员的心跳消息。

步骤602、当重核心或多个轻核心的前继节点内核在预置时间内未接收到所述心跳信息，则确定重核心或轻核心出现故障。

该步骤中，如果在预置时间内，重核心或多个轻核心的前继节点内核未能接收到重核心或多个轻核心发送的心跳信息，则可确定重核心或轻核心出现故障。

本发明实施例中，当出现故障的是重核心，则由多个轻核心选择出作为新的重核心的轻核心。具体地，由多个轻核心进行投票协商，选择出负载最小的轻核心作为新的重核心。本发明实施例中，当重核心出现故障后，由发现故障的轻核心发起投票，即发现故障的轻核心发起一次广播，指示其他所有的轻核心通过广播报告自己的负载；所有的轻核心接收到广播消息，判断自己的负载状态，并通过广播消息向其他轻核心报告自己的负载。最终，由负载最小的轻核心发起投票，并向其他轻核心进行广播，申请成为重核心，由其他轻核心确认当前发起投票申请成为重核心的轻核心负载是否为最小。若负载确实为最小，则其他轻核心返回投票通过的消息；否则，其他轻核心返回投票不通过的消息，继续选择负载最小的轻核心。若投票通过，则该负载最小的轻核心升级为新的重核心，由该新的重核心加载原重核心的功能，然后由该新的重核心向所有的轻核心发送更新的组内成员信息，如果该新的重核心接收到所有的轻核心回应的应答消息，则故障处理成功；否则，新的重核心对没有进行回应的轻核心进行故障处理。

当出现故障的是轻核心，则由重核心对该轻核心进行故障处理。具体地，重核心将该故障轻核心从核心组中剔除，删除该故障轻核心的状态信息，在剩余轻核心中确定出可以替代该故障轻核心的轻核心，保存该轻核心的状态信息，并通过广播向所有轻核心发送已发生变化的内核的状态信息，由各个轻核心更新自身保存的内核的状态信息。通常，可以设置接收广播的轻核心需要向重核心发送应答消息，当重核心接收到所有轻核心的应答消息，则故障处理成功；否则，重核心需要对未发送应答消息的轻核心进行故障处理。

需要说明的是，当出现故障的是重核心时，则新的重核心根据自身保存的所有内核的状态信息，获知原重核心上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。如果多次加载不成功，则进行报错。

而当出现故障的是轻核心时，则重核心确定出接收故障轻核心上运行的系统服务的正常轻核心；该正常轻核心根据自身保存的所有内核的状态信息，获知故障轻核心上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。如果多次加载不成功，则进行报错。

下面通过图8所示的应用场景，描述本发明的相关技术方案。

如图8所示，系统内有4个型号相同类型的CPU（如Xeon），每个CPU上部署一个内核，每个CPU都有自己本地的内存（Memory），各个CPU的内存之间相互独立，正常状态下不能相互访问。CPU间通过PCIE总线互连。PCIE的连接是建立在一个双向的序列的点对点连接基础之上，每个PCIE设备都有自己独立的数据连接，在要求传输数据的时候各自建立自己的传输通道，各个设备之间并发的数据传输互不影响。设计基于PCIE的广播机制，在两个核心可以互相通信的基础上，封装广播接口使得一个核心可以调用接口实现对于组内所有成员的广播。

内核的状态信息采用基于PCIE的机制在各个核心之间进行传输，系统服务部署在核心上，由核心来管理本地资源。每个核心监控自己本地的系统服务，若发现出现异常，则重新载入系统服务，如果多次载入失败，则进行报错，报错信息在内核间同步。当有核心失效时，重核心可以进行授权，使得迁移目标核心可以访问失效核心的内存。

初始化时，假设按CPU的加电顺序，核心1首先启动成为重核心，其他核心加入成为轻核心。每个核心保存组内一致性状态视图，视图内容包括组成员信息、系统服务信息、系统关键事件信息。当有成员退出系统OS服务信息需要同步时，重核心通过广播机制实现同步，如果某个轻核心没有回应同步消息，则重核心进行仲裁，重核心会重发消息，如果获得该轻核心的回应，则同步成功，否则进行故障处理，将故障的核心剔除出当前核心组；如果是重核心没有回应，则轻核心在核心组内发起投票，进一步判断核心1（当前的重核心）是否故障，若投票通过，则核心2、核心3或核心4中选择一个升级为重核心，然后将核心1上运行的服务加载过来，由新的重核心更新状态视图并发给其他核心；若投票不通过，则不对核心1进行处理。可见，对于断定为故障的重核心，新的重核心需要在核心组内更新成员视图，同时，新的重核心将失效核心上的系统服务加载至本地。

一般地，当核心发生故障时，原在故障核心上加载的系统服务需要加载在相同类型的CPU上部署的内核上，如图9所示的应用场景。图9中，系统结构与图8相同，区别在于，四个CPU由两种不同型号的CPU构成，例如：2个Xeon和2个Atom。其中，核心1为重核心，其他为轻核心。该系统初始化与正常工作流程也都与图8所示应用场景相同。当发生核心故障时，系统服务只能在相同类型的CPU间互相加载。例如：当核心3失效时，核心3上的系统服务将加载到核心1上；若核心2失效，则核心2上面的服务将加载到核心4上。

与本发明提供的多内核操作系统的失效控制方法实施例相对应，本发明还提供了一种多内核操作系统的失效控制装置。

如图10所示，为本发明提供的一种多内核操作系统的失效控制装置的实施例，该装置具体可以包括：

核心确定模块1001，用于确定操作系统内的重核心内核以及多个轻核心内核；

服务运行模块1002，用于在所述重核心内核和多个轻核心内核上运行相应的系统服务，所述重核心内核以及多个轻核心内核均保存有所有内核的状态信息；

状态监测模块1003，用于监测所述重核心内核和多个轻核心内核的状态；

第一故障处理模块1004，用于当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上，由所述新的重核心内核和多个轻核心内核更新相应内核的状态信息；

第二故障处理模块1005，用于当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，由所述重核心内核和多个轻核心内核更新相应内核的状态信息。

本发明实施例中，将操作系统内的内核划分为一个重核心内核和多个轻核心内核，在所述重核心内核和多个轻核心内核上运行相应的系统服务，并监测所述重核心内核和多个轻核心内核的状态，当监测结果发现有内核出现故障时，则进行相应的故障处理，包括：当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上；当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他轻核心内核。使得在部分内核失效的情况下，整个多内核操作系统仍能维持正常工作状态，因此，大大提高操作系统的可用性。

具体实施过程中，所述核心确定模块1001，具体可以包括：

重核心内核确定单元，用于将操作系统内第一个启动的内核确定为所述重核心内核；

轻核心内核确定单元，用于将其余内核确定为所述轻核心内核。

该实现方式中，可以将操作系统内第一个启动的内核确定为重核心，将其余内核确定为轻核心。确定出的重核心和其余轻核心可以组成一个核心组。

一个优选实施例中，所述服务运行模块1002，可以包括：

第一运行单元，用于所述重核心内核接收系统服务发送的注册请求消息，并运行接收到的系统服务；

轻核心内核指定单元，用于所述重核心内核向所述多个轻核心内核广播所接收的系统服务注册信息，指定运行系统服务的相应轻核心内核；

第二运行单元，用于所述重核心内核接收所述多个轻核心内核发送的注册回应消息，通知所述系统服务至所述相应轻核心内核进行注册，以便所述相应轻核心内核运行所述系统服务。

另一个优选实施例中，所述服务运行模块，还可以包括：

第一服务删除单元，用于所述重核心内核接收系统服务发送的退出请求消息，并将本地保存的系统服务进行删除；

服务退出信息广播单元，用于所述重核心内核向所述多个轻核心内核广播所接收的系统服务退出信息；

第二服务删除单元，用于所述重核心内核接收所述多个轻核心内核发送的退出回应消息，由所述多个轻核心内核在将本地保存的系统服务进行删除；

退出通知单元，用于所述重核心内核通知所述系统服务进行退出。

该实施例中，当系统服务需要退出时，系统服务向重核心发送退出请求消息，重核心收到该退出请求消息，将本地保存的该系统进行删除，此外，重核心还可以将本地保存的该系统服务的服务信息进行删除。重核心删除本地保存的该系统服务之后，向多个轻核心广播所接收的系统服务退出信息。轻核心接收到系统服务退出消息之后，将本地保存的该系统服务进行删除，并向重核心发送退出回应消息。当重核心接收到所有轻核心发送的退出回应消息，获知所有轻核心已成功将各自本地保存的系统服务进行删除，重核心通知该系统服务可以进行退出，则该系统服务退出。

在另一个优选实现方式中，所述状态监测模块，可以包括：

心跳信息发送单元，用于所述重核心内核或多个轻核心内核向各自的前继节点内核发送心跳信息；

故障确定单元，用于当所述重核心内核或多个轻核心内核的前继节点内核在预置时间内未接收到所述心跳信息，则确定所述重核心内核或轻核心内核出现故障。

该实现方式中，如果在预置时间内，重核心或多个轻核心的前继节点内核未能接收到重核心或多个轻核心发送的心跳信息，则可确定重核心或轻核心出现故障。

当出现故障的是重核心，则由多个轻核心选择出作为新的重核心的轻核心。具体地，由多个轻核心进行投票协商，选择出负载最小的轻核心作为新的重核心。本发明实施例中，当重核心出现故障后，由发现故障的轻核心发起投票，即发现故障的轻核心发起一次广播，指示其他所有的轻核心通过广播报告自己的负载；所有的轻核心接收到广播消息，判断自己的负载状态，并通过广播消息向其他轻核心报告自己的负载。最终，由负载最小的轻核心发起投票，并向其他轻核心进行广播，申请成为重核心，由其他轻核心确认当前发起投票申请成为重核心的轻核心负载是否为最小。若负载确实为最小，则其他轻核心返回投票通过的消息；否则，其他轻核心返回投票不通过的消息，继续选择负载最小的轻核心。若投票通过，则该负载最小的轻核心升级为新的重核心，由该新的重核心加载原重核心的功能，然后由该新的重核心向所有的轻核心发送更新的组内成员信息，如果该新的重核心接收到所有的轻核心回应的应答消息，则故障处理成功；否则，新的重核心对没有进行回应的轻核心进行故障处理。

所述第一故障处理模块触发时，即：当出现故障的是重核心时，所述新的重核心内核根据自身保存的所有内核的状态信息，获知所述原重核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

所述第二故障处理模块触发时，即：当出现故障的是轻核心时，所述重核心内核确定出接收所述故障轻核心内核上运行的系统服务的正常轻核心内核；所述正常轻核心内核根据自身保存的所有内核的状态信息，获知所述故障轻核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-OnlyMemory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (16)

1.一种多内核操作系统的失效控制方法，其特征在于，包括：

确定操作系统内的重核心内核以及多个轻核心内核,所述轻核心用于本地资源管理和全局资源访问管理，所述重核心用于本地资源管理、全局资源访问管理和对多个轻核心的管理，所述重核心内核以及多个轻核心内核均保存有所有内核的状态信息；

在所述重核心内核和多个轻核心内核上运行相应的系统服务，所述重核心内核和所述多个轻核心内核上运行的系统服务根据重核心确定；

监测所述重核心内核和多个轻核心内核的状态；

当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上，由所述新的重核心内核和多个轻核心内核更新相应内核的状态信息；当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，由所述重核心内核和多个轻核心内核更新相应内核的状态信息。

2.根据权利要求1所述的方法，其特征在于，所述确定操作系统内的重核心内核以及多个轻核心内核，包括：

将操作系统内第一个启动的内核确定为所述重核心内核，将其余内核确定为所述轻核心内核。

3.根据权利要求1所述的方法，其特征在于，所述在所述重核心内核和多个轻核心内核上运行相应的系统服务，包括：

所述重核心内核接收系统服务发送的注册请求消息，并运行接收到的系统服务；

所述重核心内核向所述多个轻核心内核广播所接收的系统服务注册信息，指定运行系统服务的相应轻核心内核；

所述重核心内核接收所述多个轻核心内核发送的注册回应消息，通知所述系统服务至所述相应轻核心内核进行注册，以便所述相应轻核心内核运行所述系统服务。

4.根据权利要求3所述的方法，其特征在于，所述在所述重核心内核和多个轻核心内核上运行相应的系统服务，还包括：

所述重核心内核接收系统服务发送的退出请求消息，并将本地保存的系统服务进行删除；

所述重核心内核向所述多个轻核心内核广播所接收的系统服务退出信息；

所述重核心内核接收所述多个轻核心内核发送的退出回应消息，由所述多个轻核心内核在将本地保存的系统服务进行删除；

所述重核心内核通知所述系统服务进行退出。

5.根据权利要求1所述的方法，其特征在于，所述监测所述重核心内核和多个轻核心内核的状态，包括：

所述重核心内核或多个轻核心内核向各自的前继节点内核发送心跳信息；

当所述重核心内核或多个轻核心内核的前继节点内核在预置时间内未接收到所述心跳信息，则确定所述重核心内核或轻核心内核出现故障。

6.根据权利要求1所述的方法，其特征在于，所述当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，包括：

当所述重核心内核出现故障时，由所述多个轻核心内核选择出负载最小的轻核心内核，由所述负载最小的轻核心内核作为所述新的重核心内核。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述将原重核心内核上运行的系统服务转移至所述新的重核心内核上，包括：

所述新的重核心内核根据自身保存的所有内核的状态信息，获知所述原重核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

8.根据权利要求1-6中任一项所述的方法，其特征在于，所述当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，包括：

所述重核心内核确定出接收所述故障轻核心内核上运行的系统服务的正常轻核心内核；所述正常轻核心内核根据自身保存的所有内核的状态信息，获知所述故障轻核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

9.一种多内核操作系统的失效控制装置，其特征在于，包括：

核心确定模块，用于确定操作系统内的重核心内核以及多个轻核心内核,所述轻核心用于本地资源管理和全局资源访问管理，所述重核心用于本地资源管理、全局资源访问管理和对多个轻核心的管理，所述重核心内核以及多个轻核心内核均保存有所有内核的状态信息；

服务运行模块，用于在所述重核心内核和多个轻核心内核上运行相应的系统服务，所述重核心内核和所述多个轻核心内核上运行的系统服务根据重核心确定；

状态监测模块，用于监测所述重核心内核和多个轻核心内核的状态；

第一故障处理模块，用于当所述重核心内核出现故障时，则在所述多个轻核心内核中确定出新的重核心内核，将原重核心内核上运行的系统服务转移至所述新的重核心内核上，由所述新的重核心内核和多个轻核心内核更新相应内核的状态信息；

第二故障处理模块，用于当所述轻核心内核出现故障时，则将故障轻核心内核上运行的系统服务转移至其他正常轻核心内核，由所述重核心内核和多个轻核心内核更新相应内核的状态信息。

10.根据权利要求9所述的装置，其特征在于，所述核心确定模块，包括：

重核心内核确定单元，用于将操作系统内第一个启动的内核确定为所述重核心内核；

轻核心内核确定单元，用于将其余内核确定为所述轻核心内核。

11.根据权利要求9所述的装置，其特征在于，所述服务运行模块，包括：

第一运行单元，用于所述重核心内核接收系统服务发送的注册请求消息，并运行接收到的系统服务；

轻核心内核指定单元，用于所述重核心内核向所述多个轻核心内核广播所接收的系统服务注册信息，指定运行系统服务的相应轻核心内核；

第二运行单元，用于所述重核心内核接收所述多个轻核心内核发送的注册回应消息，通知所述系统服务至所述相应轻核心内核进行注册，以便所述相应轻核心内核运行所述系统服务。

12.根据权利要求11所述的装置，其特征在于，所述服务运行模块，还包括：

第一服务删除单元，用于所述重核心内核接收系统服务发送的退出请求消息，并将本地保存的系统服务进行删除；

服务退出信息广播单元，用于所述重核心内核向所述多个轻核心内核广播所接收的系统服务退出信息；

第二服务删除单元，用于所述重核心内核接收所述多个轻核心内核发送的退出回应消息，由所述多个轻核心内核在将本地保存的系统服务进行删除；

退出通知单元，用于所述重核心内核通知所述系统服务进行退出。

13.根据权利要求9所述的装置，其特征在于，所述状态监测模块，包括：

心跳信息发送单元，用于所述重核心内核或多个轻核心内核向各自的前继节点内核发送心跳信息；

故障确定单元，用于当所述重核心内核或多个轻核心内核的前继节点内核在预置时间内未接收到所述心跳信息，则确定所述重核心内核或轻核心内核出现故障。

14.根据权利要求9所述的装置，其特征在于，当所述重核心内核出现故障时，所述第一故障处理模块确定出新的重核心内核，具体为：由所述多个轻核心内核选择出负载最小的轻核心内核。

15.根据权利要求9-14中任一项所述的装置，其特征在于，所述第一故障处理模块触发时，所述新的重核心内核根据自身保存的所有内核的状态信息，获知所述原重核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。

16.根据权利要求9-14中任一项所述的装置，其特征在于，所述第二故障处理模块触发时，所述重核心内核确定出接收所述故障轻核心内核上运行的系统服务的正常轻核心内核；所述正常轻核心内核根据自身保存的所有内核的状态信息，获知所述故障轻核心内核上运行的系统服务的进程信息，根据所述进程信息得到对应的物理地址，根据所述物理地址获取对应的内存映像，将所述内存映像中的系统服务加载至本地，在本地进行系统服务进程的重构。