一种数据处理方法、电子设备及集群与流程

本申请涉及数据传输技术领域，特别涉及一种数据处理方法、电子设备及集群。

背景技术：

在当前主流的云基础设施集群中，通常存在一个或多个的中心控制器，用来调度集群的整体资源，例如：在创建虚拟业务时，控制器会根据当前的集群内部资源情况，选择一个资源占用率最低的主机，将新业务迁移上去，做到集群内部的资源均匀分布；或者，控制器启动一个定期，一旦超时则决定当前虚拟机的重新分配。

而在大规模无中心的集群中，由于没有一个统一的控制器或管理者，使得由控制器统一调度资源的方案无法适用，导致集群中无法实现资源调度，导致集群内资源失衡。

技术实现要素：

有鉴于此，本申请的目的是提供一种数据处理方法、电子设备及集群，用以解决现有技术中的大规模无中心的集群资源失衡的技术问题。

本申请提供了一种数据处理方法，应用于集群中的主机，所述方法包括：

读取集群的资源记录信息，所述资源记录信息包括所述集群中每台主机的资源信息；

基于所述资源信息，判断是否需要迁出虚拟机或迁入虚拟机。

上述方法，优选的，所述基于所述资源信息，判断是否需要迁出虚拟机或迁入虚拟机，包括：

在所述资源信息中所有主机的资源平均占用量小于当前主机的当前资源占用量时，标记所述当前主机为需要迁出虚拟机的状态；

在所述资源信息中所有主机的资源平均占用量大于当前主机的当前资源占用量时，标记所述当前主机为可迁入虚拟机的状态。

上述方法，优选的，在标记所述当前主机为需要迁出虚拟机的状态之后，还包括：

确定所述当前主机中需要迁出的第一虚拟机。

上述方法，优选的，在确定所述当前主机中需要迁出的第一虚拟机之后，所述方法还包括：

基于所述第一虚拟机所需要的资源占用量，在集群的其他主机中查找处于可迁入虚拟机的状态且资源可用量满足预设要求的第一主机，由所述第一主机或所述当前主机更新所述当前主机的资源信息、所述第一主机的资源信息及所述第一虚拟机的虚拟机信息，使得所述第一虚拟机迁出所述当前主机并迁入所述第一主机。

上述方法，优选的，在标记所述当前主机为可迁入虚拟机的状态之后，还包括：

在集群的其他主机中查找处于需要迁出虚拟机的状态的第二主机，所述第二主机中具有第二虚拟机需要迁出，由所述第二主机或所述当前主机修改所述当前主机的资源信息、所述第二主机的资源信息及所述第二虚拟机的虚拟机信息，使得所述第二虚拟机迁出所述第二主机并迁入所述当前主机。

上述方法，优选的，读取集群的资源记录信息，包括：

每隔预设的时间间隔，读取集群的资源记录信息。

上述方法，优选的，所述资源记录信息中各主机的资源信息由主机分别进行存储。

上述方法，优选的，还包括：

生成待创建的虚拟机的资源信息并存储到所述资源记录信息；

基于所述资源记录信息，在所述集群中查找处于可迁入虚拟机的状态且资源可用量满足预设要求的第三主机，由所述第三主机更新所述第三主机的资源信息及所述待创建的虚拟机的资源信息，使得所述待创建的虚拟机创建在所述第三主机上。

本申请还提供了一种电子设备，包括：

输入接口，用于读取集群的资源记录信息，所述资源记录信息包括所述集群中每台主机的资源信息；

处理器，用于基于所述资源信息，判断是否需要迁出虚拟机或迁入虚拟机。

本申请还提供了一种集群，包括数据库及多个主机，其中：

数据库，用于存储资源记录信息，所述资源记录信息包含集群中每台主机的资源信息；

主机，用于读取所述资源记录信息，并基于所述资源信息，判断是否需要迁出虚拟机或迁入虚拟机。

上述集群，优选的：

所述主机具体用于：在所述资源信息中所有主机的资源平均占用量小于当前主机的当前资源占用量时，标记所述当前主机为需要迁出虚拟机的状态；在所述资源信息中所有主机的资源平均占用量大于当前主机的当前资源占用量时，标记所述当前主机为可迁入虚拟机的状态。

由上述方案可知，本申请提供的一种数据处理方法、电子设备及集群，由集群中的主机读取集群的资源记录信息，由此来读取到集群中包含每台主机的资源信息，进而再基于这些资源信息来判断当前的主机是否需要迁出虚拟机还是需要迁入虚拟机，实现虚拟机资源的调度。本申请中无需在集群中存在统一的控制器或管理者，而是将资源调度的工作分配到每个主机上，由每个主机通过判断集群中所有主机的资源信息来确定当前主机是否需要进行资源调度，如虚拟机迁出或虚拟机迁入等，从而实现资源调度，做到集群内整体的资源平衡，实现本申请目的。

附图说明

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

图1为本申请实施例一提供的一种数据处理方法的实现流程图；

图2与图3分别为本申请实施例的应用示例图；

图4～图7分别为本申请实施例一的部分流程图；

图8为本申请实施例二提供的一种电子设备的结构示意图；

图9为本申请实施例三提供的一种集群的结构示意图；

图10～图14分别为本申请实施例的其他应用示例图。

具体实施方式

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

参考图1，为本申请实施例一提供的一种数据处理方法的实现流程图，适用于大规模无中心的服务器集群的主机中，该集群中包含有多个主机，如图2中所示，每个主机均上能够运行虚拟机，为用户提供各种服务。

本实施例中的方法可以运行在集群中的每台主机上，包括以下步骤：

步骤101：读取集群的资源记录信息。

其中，资源记录信息可以包括有集群中每台主机的资源信息。资源信息可以包含有多个维度的信息，如虚拟中央处理器(centralprocessingunit，cpu)核数、虚拟内存大小、磁盘空间、出口带宽等信息，如图3中主机node1～node4各自的虚拟cpu核数、虚拟内存、磁盘空间及出口带宽的总数和当前资源占用量所示。

以主机node2为例，各维度信息的总数total为：

虚拟cpu核数vcpu：100；虚拟内存大小vmem：100g；磁盘空间disc：10t；出口带宽bandwidth：20000g；

各维度信息的当前资源占用量used为：

虚拟cpu核数vcpu：0；虚拟内存大小vmem：0；磁盘空间disc：0；出口带宽bandwidth：0。

需要说明的是，资源记录信息能够表征集群中每台主机的当前资源状态。

步骤102：基于资源信息，判断是否需要迁出虚拟机或迁入虚拟机。

也就是说，在集群中，每个主机均可以作为资源调度的主体，基于整个集群中的所有主机的当前资源状态来进行虚拟机资源的调度，例如，从别的主机中迁入虚拟机，或者迁出虚拟机到别的主机中，实现资源的平衡调度。

由上述方案可知，本申请实施例一提供的一种数据处理方法，由集群中的主机读取集群的资源记录信息，由此来读取到集群中包含每台主机的资源信息，进而再基于这些资源信息来判断当前的主机是否需要迁出虚拟机还是需要迁入虚拟机，实现虚拟机资源的调度。本实施例中无需在集群中存在统一的控制器或管理者，而是将资源调度的工作分配到每个主机上，由每个主机通过判断集群中所有主机的资源信息来确定当前主机是否需要进行资源调度，如虚拟机迁出或虚拟机迁入等，从而实现资源调度，做到集群内整体的资源平衡，实现实施例目的。

同时，本实施例中，虚拟机迁移的触发由集群中的主机发起，而不是统一调度触发，因此虚拟机迁移的时间可以很容易分散开，降低集群内部大规模虚拟机迁移的情况出现的概率。

在一种实现方式中，资源记录信息中各主机的资源信息是由主机自己来分别进行存储的。例如，图2中的每台主机在上线进入集群之后，主机将其资源信息写入到数据库中，集群中所有主机的资源信息构成了集群的资源记录信息，提供给进行资源均衡调度的主机进行读取。

而执行资源均衡调度的每台主机在读取集群的资源记录信息时，可以每隔预设的时间间隔，来读取集群的资源记录信息。

其中，时间间隔的大小可以根据主机自身的需求进行设置。

例如，在集群中的每台主机均设置一个定时器，在定时器记录到一个时间间隔即定时器超时后，主机读取一次集群的资源记录信息，进而进行一次资源的均衡调度。也就是说，本实施例中，集群的每台主机可以定期进行一次资源调度，进一步实现集群整体的资源平衡性。

在一种实现方式中，集群中进行资源均衡调度的主机在基于资源信息判断是否需要迁出虚拟机或嵌入虚拟机时，可以通过以下步骤实现，如图4中所示：

步骤121：判断资源信息中所有主机的资源平均占用量与当前主机的当前资源占用量之间的大小；

步骤122：在资源信息中所有主机的资源平均占用量小于当前主机的当前资源占用量时，标记当前主机为需要迁出虚拟机的状态，也就是说，当前主机需要向其他主机迁移虚拟机。

步骤123：在资源信息中所有主机的资源平均占用量大于当前主机的当前资源占用量时，标记当前主机为需要迁入虚拟机的状态，也就是说，其他主机可以向当前主机迁移虚拟机。

而在资源信息中所有主机的资源平均占用量等于当前主机的当前资源占用量时，当前主机可以不做任何动作，因为此时当前主机在集群中的资源占用是相对均衡的状态。

在当前主机为需要迁出虚拟机的状态时，本实施例中可以通过确定当前主机中需要迁出的第一虚拟机，进而将第一虚拟机迁入到相应的第一主机中，如图5中所示，在步骤122之后，该方法还可以包括以下步骤：

步骤103：确定当前主机中需要迁出的第一虚拟机。

其中，本实施例中，当前主机可以根据其当前资源占用量超过集群中所有主机的资源平均占用量的量来确定第一虚拟机。例如，当前主机所确定的第一虚拟机被迁出后，当前主机的当前资源占用量小于或等于集群中所有主机的资源平均占用量。

步骤104：基于第一虚拟机所需要的资源占用量，在集群的其他主机中查找处于可迁入虚拟机的状态且资源可用量满足预设要求的第一主机。

步骤105：更新当前主机的资源信息、第一主机的资源信息及第一虚拟机的虚拟机信息，使得第一虚拟机迁出当前主机并迁入第一主机，由此，完成第一虚拟机的迁移。

或者，当前主机的资源信息、第一主机的资源信息及第一虚拟机的虚拟机信息除了可以由当前主机自己来更新之外，还可以由第一主机来更新。

其中，预设要求是指：第一主机的资源可用量能够满足迁入第一主机的第一虚拟机所需要的资源，例如，第一主机的资源可用量大于或等于说是第一虚拟机所需要的资源占用量。

例如：当前主机的资源信息可以更新为不包含第一虚拟机的资源信息；第一主机的资源信息被更新后为包含第一虚拟机的资源信息；第一虚拟机的虚拟机信息被更新为属于第一主机的虚拟机信息，由此，完成第一虚拟机从当前主机迁入第一主机的过程，实现资源的均衡调度。

在当前主机为可迁入虚拟机的状态时，当前主机可以在集群的其他主机中迁入第二虚拟机，具体的，在步骤123之后，该方法还可以包括以下步骤，如图6中所示：

步骤106：在集群的其他主机中查找处于需要迁出虚拟机的状态的第二主机。

其中，第二主机中具有第二虚拟机需要迁出。

需要说明的是，第二主机中需要迁出的第二虚拟机，可以是第二主机在进行资源均衡调度时所确定的，例如，第二主机基于集群中每台主机的资源信息判断出第二主机的当前资源占用量大于集群中所有主机的资源平均占用量时，第二主机确定需要迁出的第二虚拟机。

步骤107：修改当前主机的资源信息、第二主机的资源信息及第二虚拟机的虚拟机信息，使得第二虚拟机迁出第二主机并迁入当前主机。

或者，当前主机的资源信息、第二主机的资源信息及第二虚拟机的虚拟机信息除了可以由当前主机自己来更新之外，还可以由第二主机来更新。

例如：当前主机的资源信息可以更新为包含第二虚拟机的资源信息；第二主机的资源信息被更新后为不包含第二虚拟机的资源信息；第二虚拟机的虚拟机信息被更新为属于当前主机的虚拟机信息，由此，完成第一虚拟机从第二主机迁入当前主机的过程，实现资源的均衡调度。

在一种实现方式中，集群中除了存在虚拟机迁移的情况，还会有新建虚拟机的情况，因此，为了实现新建虚拟机时也同样能够达到资源均衡，本实施例中提出以下方案，如图7中所示，步骤如下：

步骤701：生成待创建的虚拟机的资源信息并存储到资源记录信息。

步骤702：基于资源记录信息，在集群中查找处于可迁入虚拟机的状态且资源可用量满足预设要求的第三主机。

由此，由第三主机更新第三主机的资源信息以及待创建的虚拟机的资源信息，使得待创建的虚拟机创建在第三主机上。

其中，第三主机可以是当前主机，也可以是集群中的其他主机。

而第三主机的资源信息更新为包含该待创建的虚拟机的信息；待创建的虚拟机的资源信息更新为属于第三主机的资源信息。

也就是说，当前主机可以基于资源记录信息中集群所有主机的资源信息来确定第三虚拟机所创建的主机，可以是集群中处于可迁入虚拟机的状态且资源可用量能够满足待创建的虚拟机所需要的资源占用量的主机，即第三主机。

参考图8，为本申请实施例二提供的一种电子设备的结构示意图，该电子设备可以为云基础设备集群中的主机。

在本实施例中，该电子设备可以包括以下结构：

输入接口801，用于读取集群的资源记录信息。

其中，资源记录信息包括集群中每台主机的资源信息，具体内容可以参考图3所示及前文相应内容。

需要说明的是，输入接口801可以为能够读取数据库中资源信息的接口实现。

处理器802，用于基于资源信息，判断是否需要迁出虚拟机或者迁入虚拟机。

也就是说，在集群中，每个主机均可以作为资源调度的主体电子设备，基于整个集群中的所有主机的当前资源状态来进行虚拟机资源的调度，例如，从别的主机中迁入虚拟机，或者迁出虚拟机到别的主机中，实现资源的平衡调度。

由上述方案可知，本申请实施例二提供的一种电子设备，由集群中的主机读取集群的资源记录信息，由此来读取到集群中包含每台主机的资源信息，进而再基于这些资源信息来判断当前的主机是否需要迁出虚拟机还是需要迁入虚拟机，实现虚拟机资源的调度。本实施例中无需在集群中存在统一的控制器或管理者，而是将资源调度的工作分配到每个主机上，由每个主机通过判断集群中所有主机的资源信息来确定当前主机是否需要进行资源调度，如虚拟机迁出或虚拟机迁入等，从而实现资源调度，做到集群内整体的资源平衡，实现实施例目的。

同时，本实施例中，虚拟机迁移的触发由集群中的主机发起，而不是统一调度触发，因此虚拟机迁移的时间可以很容易分散开，降低集群内部大规模虚拟机迁移的情况出现的概率。

在一种实现方式中，输入接口801可以每隔预设的时间间隔，读取集群的资源记录信息。

而资源记录信息中各个主机的资源信息是有主机自己分别进行存储的，再由进行资源均衡调度的主机进行读取。

在一种实现方式中，处理器802在基于所述资源信息，判断是否需要迁出虚拟机或迁入虚拟机，可以通过以下方式实现：

在所述资源信息中所有主机的资源平均占用量小于当前主机的当前资源占用量时，标记所述当前主机为需要迁出虚拟机的状态，确定当前主机中需要迁出的第一虚拟机，并基于所述第一虚拟机所需要的资源占用量，在集群的其他主机中查找处于可迁入虚拟机的状态且资源可用量满足预设要求的第一主机，由所述第一主机或所述当前主机更新所述当前主机的资源信息、所述第一主机的资源信息及所述第一虚拟机的虚拟机信息，使得所述第一虚拟机迁出所述当前主机并迁入所述第一主机；

在所述资源信息中所有主机的资源平均占用量大于当前主机的当前资源占用量时，标记所述当前主机为可迁入虚拟机的状态，并在集群的其他主机中查找处于需要迁出虚拟机的状态的第二主机，所述第二主机中具有第二虚拟机需要迁出，由所述第二主机或所述当前主机修改所述当前主机的资源信息、所述第二主机的资源信息及所述第二虚拟机的虚拟机信息，使得所述第二虚拟机迁出所述第二主机并迁入所述当前主机。

而处理器802在创建新的虚拟机时，可以通过以下方式实现：

生成待创建的虚拟机的资源信息并存储到所述资源记录信息，基于所述资源记录信息，在所述集群中查找处于可迁入虚拟机的状态且资源可用量满足预设要求的第三主机，由所述第三主机更新所述第三主机的资源信息及所述待创建的虚拟机的资源信息，使得所述待创建的虚拟机创建在所述第三主机上。

而第三主机可以是当前的电子设备即当前主机，也可以为集群中除了当前主机之外的其他主机。

参考图9，为本申请实施例三提供的一种集群的结构示意图，在集群中可以包括数据库901和多个主机902，每个主机902均与数据库901相连接，其中：

数据库901，用于存储资源记录信息。

其中，资源记录信息包含集群中每台主机的资源信息。每台主机的资源信息由主机自己各自上传存储。

集群中还可以包含另一数据库，来对数据库901中的信息进行备份存储。

主机902，用于读取所述资源记录信息，并基于所述资源信息，判断是否需要迁出虚拟机或迁入虚拟机。

在具体实现中，主机902具体用于：在所述资源信息中所有主机的资源平均占用量小于当前主机902的当前资源占用量时，标记所述当前主机为需要迁出虚拟机的状态；在所述资源信息中所有主机的资源平均占用量大于当前主机902的当前资源占用量时，标记所述当前主机902为可迁入虚拟机的状态。

在主机902标记自己为需要迁出虚拟机的状态之后，还可以确定该主机中需要迁出的第一虚拟机，并基于所述第一虚拟机所需要的资源占用量，在集群的其他主机中查找处于可迁入虚拟机的状态且资源可用量满足预设要求的主机，如第一主机，由所述第一主机或所述当前主机902更新所述当前主机902的资源信息、所述第一主机的资源信息及所述第一虚拟机的虚拟机信息，使得所述第一虚拟机迁出所述当前主机902并迁入所述第一主机。

而主机902在标记所述当前主机为可迁入虚拟机的状态之后，还可以在集群的其他主机中查找处于需要迁出虚拟机的状态的第二主机，所述第二主机中具有第二虚拟机需要迁出，由所述第二主机或所述当前主机902修改所述当前主机902的资源信息、所述第二主机的资源信息及所述第二虚拟机的虚拟机信息，使得所述第二虚拟机迁出所述第二主机并迁入所述当前主机902。

需要说明的是，主机902可以每隔预设的时间间隔，读取集群的资源记录信息，从而进行资源调度。也就是说，在集群中每台主机可以定期进行资源均衡调度，进一步实现资源均衡性。

以下以图9中所示的集群为例，对本实施例中的资源均衡调度进行举例说明：

对于集群中的主机可以设定两种角色：

卖家：需要迁出虚拟机的主机；

买家：可以迁入虚拟机的主机。

在虚拟机的信息中，包括一个交易状态dealstate，用来描述主机之间的虚拟机交易状态，其中：

forsale：出售状态，表明该虚拟机处于待售状态，即该虚拟机处于需要从当前所在主机迁出到其他主机的状态；

deal：交易结束，说明卖家和买家之间已经完成交易约定，可以开始进行虚拟机迁移或创建的实际操作。

而还可以有location表明虚拟机所属的主机。

在集群的数据库中，记录每台主机的资源信息和交易信息，通过数据库的资源记录信息来完成数据交易，如图10中的集群整体的部署拓扑图所示。

集群中的数据库可以为cassandra数据库，也可使用集中式数据库，数据库作为无中心云基础设施的数据存储服务，保存主机的资源信息和虚拟机信息，如资源被占用数量、虚拟机数量、每个虚拟机所占的资源等。

而在每个主机上线即加入集群之后，将本机的资源信息写入到数据库中。资源信息可能有多个维度，如虚拟cpu核数，虚拟内存大小，磁盘空间，出口带宽等。

本实施例的集群在超融合基础设施云场景中，虚拟机的创建可以在每个主机发起，在主机创建虚拟机或者资源占用过多时，主机从资源列表中查找合适的买家主机，遵循以下规则：

1、卖家总是选择资源可有量或资源保有量最多的，且状态处于空闲状态的买家(空闲状态是指没有处于交易状态)；

2、若交易过程中，买家出现故障，卖家需要重新选择买家，并重新触发交易；

3、若交易过程中，卖家出现故障，则需要重新触发虚拟机的加入。

以host1和host2之间的交易为例，对卖家触发交易的示例进行说明，如图11和图12中所示：

1、外部触发host1创建/迁移虚机；

2、host1创建一个虚拟机4的数据条目，如虚拟机的占用资源的信息，dealstate为forsale，location为空，虚拟机state为tobuild(待创建，而running表示已经创建正在运行)，同时从数据库中查询集群资源使用情况，选择一个资源保有量最多，且处于交易空闲状态的主机host2(host2可能是host1，也可能是其他主机)；

3、host1发起向host2的通讯，告知有虚拟机资源需要交易，host2可以回复接受，若host2回复拒绝，则host1从主机列表中重新选择一个主机，重新触发交易，若此时无主机可用返回创建失败；

4、host2接受交易后，改写之前host1创建的数据条目，如占用资源的所属主机，将dealstate修改为deal，location修改为host2自己的标识；

5、host2完成虚拟机的创建，若是迁移的情况，则和host1完成迁移的动作。此时虚拟机条目为host2维护，并依创建状态修改虚机的数据条目。

其中，本实施例中还可以在卖家一方销毁虚拟机并启动虚拟机等。

需要说明的是，集群中每个主机的虚拟机管理模型都会存在一个优化定时器，在定时器超时之后，会触发一次资源的均衡调度操作。

以上为卖家触发交易模型，当优化定时器超时后，卖家主机会将多余虚拟机的dealstate状态修改为forsale，并从主机列表中查找合适的买家主机，并重复上面创建虚机的流程。

还有一种为买家触发交易模型，即当卖家优化定时器超时后，只将自己多余的虚拟机修改交易状态，相当于在市场中挂牌销售，等待买家交易。而当买家主机的优化定时器超时后，会在虚拟机列表中查找待售的虚拟机，由买家主动向卖家发起交易。

以host1和host2之间的交易为例，对买家触发交易的示例进行说明，如图13和图14中所示：

1、host1优化定时器超时；

2、host1查询全局资源使用情况，确认自己为卖家，需要出售虚拟机；

3、host1将自己多余的虚拟机的交易状态修改为forsale；

4、host2的优化定时器超时；

5、host1查询全局资源使用情况，确认自己为买家，需要收购虚拟机；

6、host2查询虚机出售信息，并选择了host1的虚机作为收购对象；

7、host2发起和host1的通讯，交易虚拟机，若交易失败则重新选择虚拟机交易对象；

8、host2将虚拟机的location修改为host2，将交易状态修改给deal；

9、交易双方完成虚拟机的迁移工作；

10、host2开始维护虚拟机状态和数据库条目。

其中，本实施例中还可以在卖家一方销毁虚拟机并启动虚拟机等。

由上述方案可知，本实施例中适用于超融合云基础设施场景中，无中心调度的情况，而虚拟机迁移的触发由主机发起，而不是由统一调度触发，因此迁移时间可以很容易分散开，较少概率出现集群内部大规模迁移的情况；另外，交易模型很容易记录虚拟机的迁移记录，而主机之间的点对点迁移，即使发生了故障影响也很小，且有较多的手段进行修复；而交易模型动态的展现了集群内部的资源利用，可以提供更加丰富的资源利用数据及资源流动数据。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种数据处理方法、电子设备及集群进行了详细介绍，对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。