云平台切换控制方法、装置、系统及电子设备与流程

本申请涉及云技术领域，具体而言，涉及一种云平台切换控制方法、装置、系统及电子设备。

背景技术：

在云计算领域，云管理平台可以将一个或多个数据中心的硬件能力虚拟化后，提供给用户使用，用户则可以通过云管理平台来进行私有化云资源的管理和使用。然而目前，当有多个数据中心需要被统一管理时，通常仅会在其中一个数据中心中架设云管理平台，这就导致在突发情况或者停机准备不足但又需要停止该数据中心时，云平台会被关闭，从而导致云服务中断，会对用户造成损失。

技术实现要素：

本申请实施例的目的在于提供一种云平台切换控制方法、装置、系统及电子设备，用以解决相关技术中，当有多个数据中心需要被统一管理时，通常仅会在其中一个数据中心中架设云管理平台，导致在突发情况或者停机准备不足但又需要停止该数据中心时，云平台会被关闭，从而导致云服务中断，会对用户造成损失的问题。

本申请实施例提供了一种云平台切换控制方法，包括：第一云管理平台确定自身在云管理平台组中的当前状态；所述在云管理平台组中的状态包括主平台和从平台；所述云管理平台组中有至少两个云管理平台部署在不同的数据中心上；在状态切换条件被触发时，将自身的当前状态切换为与当前状态对应的目标状态；若所述目标状态为主平台，则切换为主平台，以对外提供云服务，并将自身数据实时同步到组内的从平台中；若所述目标状态为从平台，则切换为从平台并获取主平台的数据。

在上述实现过程中，会部署至少两个云管理平台，且这些云管理平台会分别部署在至少两个数据中心上。在整个实现过程中，管理平台组中的云管理平台中会确定自身的状态，并以状态为主平台的云管理平台来对外提供云服务，而其余云管理平台则作为从平台与主平台数据同步。在状态切换条件被触发时(如主平台宕机时)，即触发切换，将某一个从平台切换为新的主平台来继续对外提供云服务。这就使得云管理平台组中始终可以有一个主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

进一步地，所述第一云管理平台确定自身在云管理平台组中的当前状态包括：第一云管理平台根据自身的硬件性能和通信能力得到自身的性能评分；获取所述云管理平台组中其余云管理平台的性能评分；其中，所述其余云管理平台的性能评分为基于其余云管理平台自身的硬件性能和通信能力得到的分数；在自身的性能评分最高时，确定自身在云管理平台组中的当前状态为主平台；否则，确定自身在云管理平台组中的当前状态为从平台。

在上述实现过程中，云管理平台可以依据自身以及其余云管理平台所具有的硬件性能和通信能力来确定自身在云管理平台组中的状态，从而保证了为用户提供云服务的云管理平台是性能最优的云管理平台，保证了用户可以始终得到最好的服务体验。

进一步地，所述获取所述云管理平台组中其余云管理平台的性能评分包括：获取所述云管理平台组中其余云管理平台的硬件性能和通信能力，并根据其余云管理平台的硬件性能和通信能力分别计算出其余云管理平台的性能评分；或，获取由其余云管理平台计算得到的其余云管理平台自身的性能评分。

在上述实现过程中，两种方式都可以使得云管理平台很容易的确定自身在云管理平台组中的状态，保证了云管理平台可以对自身在云管理平台组中的状态很好地进行确定。

进一步地，所述硬件性能包括以下至少之一：云管理平台的主频数、核数、内存大小、宿主机的cpu利用率；所述通信能力包括：通信时数据到达预设ip地址的延迟。

在上述实现过程中，云管理平台是根据自身以及其余云管理平台所具有的主频数、核数、内存大小、宿主机的cpu利用率中的至少之一、以及与数据到达预设ip地址的延迟来实现的状态确定。这样结合考虑了云管理平台的硬件性能和数据到达预设ip地址的延迟，使得为用户提供云服务的云管理平台是性能最优的云管理平台，保证了为用户提供的服务质量。

进一步地，所述在状态切换条件被触发时，将自身的当前状态切换为目标状态包括：所述第一云管理平台在当前状态为从平台且当前主平台宕机时，或者所述第一云管理平台当前状态为从宕机中恢复时，将自身的当前状态切换为目标状态。

在上述实现过程中，第一云管理平台在当前状态为从平台且当前主平台宕机时，或者所述第一云管理平台当前状态为从宕机中恢复时会触发状态切换条件，更适应于实际应用场景，具有实用性。

进一步地，在所述第一管理云平台在处于主平台状态宕机后，还包括：在从宕机中恢复时，将自身当前状态从主平台切换为从平台；或，在从宕机中恢复时，通知当前的主平台切换为从平台，并在当前的主平台切换为从平台后，重新作为主平台对外提供云服务。

在上述实现过程中，主平台在宕机后，如果恢复过来，则可以将其降级为从平台，从而减少主平台切换次数，保证对外提供的云服务平稳。此外，主平台在宕机后，如果恢复过来，也可以将当前正作为主平台对外提供云服务的云管理平台降级为从平台，而将从宕机中恢复过来的这一个云管理平台重新作为主平台对外提供云服务。这样由于之前选中的主平台是所有云管理平台中相对最优的，那么当其从宕机中恢复过来后，仍旧以其作为主平台来对外提供云服务则可以保证为用户提供云服务的云管理平台始终是性能最优的云管理平台，保证了用户可以始终得到最好的服务体验。

进一步地，所述从平台状态包括待切换平台状态和隶从平台状态；所述方法还包括：若所述目标状态为待切换平台，则切换为待切换平台，并以实时同步的方式获取主平台的数据；若所述目标状态为隶从平台，则切换为隶从平台，并从待切换平台处获取主平台的数据。

在上述实现过程中，会确定出一个从平台为待切换平台，进而待切换平台以实时同步的方式与主平台的数据进行同步。这样，待切换平台通过实时同步的方式来与主平台进行数据同步，从而保证在切换待切换平台为主平台时，不会出现数据缺失的情况，使得整个切换过程可以十分的迅速、快捷，对主平台的切换可以平稳快速的过度，降低切换过程对用户体验的影响。而隶从平台从待切换平台处获取主平台的数据，可以降低对主平台的数据传输压力，使得主平台可以将更多地处理资源用到对外提供的云服务上，保证用户能够得到更优质的服务体验。

进一步地，所述状态切换条件包括所述第一云管理平台在当前状态为待切换平台且当前主平台宕机；在所述第一云管理平台在当前状态为待切换平台且当前主平台宕机时，所述将自身的当前状态切换为目标状态包括：所述第一云管理平台将自身切换为主平台。

在上述实现过程中，在主平台宕机后，直接将待切换平台切换为主平台，不需要临时确定哪一个从平台切换为主平台，整个切换过程可以十分的迅速、快捷，对主平台的切换可以平稳快速的过度，降低切换过程对用户体验的影响。

本申请实施例还提供了一种云平台切换控制方法，包括：从云管理平台组中确定一个云管理平台作为主平台，以通过所述主平台提供云服务，其余云管理平台作为从平台不提供云服务；所述云管理平台组中有至少两个云管理平台部署在不同的数据中心上；将所述主平台的数据实时同步到至少一个从平台中，并在所述主平台宕机时，向所述从平台中的一个具有所述主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务。

在上述实现过程中，会部署至少两个云管理平台，且这些云管理平台会分别部署在至少两个数据中心上。在整个实现过程中，会从这些云管理平台中确定出一个主平台来对外提供云服务，而其余云管理平台则作为从平台与主平台数据同步。在主平台宕机时，会以某一个从平台切换为新的主平台来继续对外提供云服务。这就使得无论因为何种原因导致的主平台宕机，都可以迅速切换到一个新的主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

进一步地，从云管理平台组中确定主平台和从平台的过程包括：获取所述云管理平台组中各云管理平台的性能评分；其中，所述性能评分为根据各云管理平台的硬件性能和通信能力计算得到的分数；比较各所述云管理平台的性能评分，确定性能评分最高的云管理平台为主平台来提供云服务，其余云管理平台作为从平台。

在上述实现过程中，依据各云管理平台所具有的硬件性能和通信能力来确定各个云管理平台在云管理平台组中的状态，从而保证了为用户提供云服务的云管理平台是性能最优的云管理平台，保证了用户可以始终得到最好的服务体验。

进一步地，在所述向所述从平台中的一个具有所述主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务之后，还包括：在检测到前次宕机的主平台从宕机中恢复时，将所述宕机的主平台降级为从平台；或，在检测到前次宕机的主平台从宕机中恢复时，将当前的主平台降级为从平台，并将该宕机的主平台重新作为主平台。

在上述实现过程中，主平台在宕机后，如果恢复过来，则可以将其降级为从平台，从而减少平台切换次数，保证对外提供的云服务平稳。此外，主平台在宕机后，如果恢复过来，也可以将当前正作为主平台对外提供云服务的云管理平台降级为从平台，而将从宕机中恢复过来的这一个云管理平台重新作为主平台对外提供云服务。这样由于之前选中的主平台是所有云管理平台中相对最优的，那么当其从宕机中恢复过来后，仍旧以其作为主平台来对外提供云服务则可以保证为用户提供云服务的云管理平台始终是性能最优的云管理平台，保证了用户可以始终得到最好的服务体验。

进一步地，所述将所述主平台的数据实时同步到至少一个从平台中，并在所述主平台宕机时，向所述从平台中的一个具有所述主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务包括：从所述从平台中确定一个从平台为待切换平台；将所述主平台的数据实时同步到所述待切换平台中；在所述主平台宕机时，向所述待切换平台发送主平台切换指令，以将所述待切换平台作为新的主平台继续提供云服务。

在上述实现过程中，会先确定出一个从平台为待切换平台，进而待切换平台以实时同步的方式与主平台的数据进行同步。这样，在主平台宕机时，即可直接以待切换平台作为新的主平台来提供云服务，由于待切换平台是预先已经确定了的，这就使得整个切换过程可以十分的迅速、快捷，对主平台的切换可以平稳快速的过度，降低切换过程对用户体验的影响。

进一步地，所述从所述从平台中确定一个从平台为待切换平台包括：获取各从平台的性能评分；所述性能评分为根据各从平台的硬件性能和各从平台与主平台之间的数据通信能力计算得到；比较各所述从平台的性能评分，并确定性能评分最高的从平台为待切换平台。

在上述实现过程中，会依据各个从平台所具有的硬件性能和通信能力来确定出一个最优的待切换平台，从而保证了确定出的待切换平台在切换为主平台之后，是在所有从平台中能为用户提供性能最优的云服务的云管理平台，仍旧能为用户提供最优质的服务。

进一步地，在所述将所述主平台的数据实时同步到所述待切换平台中之后，还包括：将所述待切换平台中的数据同步到所有从平台中。

在上述实现过程中，待切换平台通过实时同步的方式来与主平台进行数据同步，从而保证在切换待切换平台为主平台时，不会出现数据缺失的情况。而其余从平台则可以从待切换平台处获取主平台的数据，通过降低数据同步的时间要求，从而降低对待切换平台的数据传输压力。

进一步地，所述将所述主平台的数据实时同步到至少一个从平台中，并在所述主平台宕机时，向所述从平台中的一个具有所述主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务包括：将所述主平台的数据实时同步到所有从平台中；在检测到所述主平台宕机时，获取各从平台的硬件性能和通信能力，并根据各所述从平台的硬件性能和通信能力得到各所述从平台的性能评分；向性能评分最高的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务。

在上述实现过程中，主平台的数据会实时同步到所有从平台中，这样在主平台宕机时，从从平台中选出一个进行切换即可，这就保证了对外提供的云服务不会随主平台的宕机而中断，用户可以一直享受到云服务，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

本申请实施例还提供了一种云平台切换控制装置，包括：第一状态确认模块和切换控制模块；所述第一状态确认模块用于确定自身在云管理平台组中的当前状态；所述在云管理平台组中的状态包括主平台和从平台；所述云管理平台组中有至少两个云管理平台部署在不同的数据中心上；所述切换控制模块用于，在状态切换条件被触发时，将自身的当前状态切换为与当前状态对应的目标状态；若所述目标状态为主平台，则切换为主平台，以对外提供云服务，并将自身数据实时同步到组内的从平台中；若所述目标状态为从平台，则切换为从平台并获取主平台的数据。

在上述实现结构中，部署有至少两个云管理平台，且这些云管理平台会分别部署在至少两个数据中心上。在整个实现过程中，管理平台组中的云管理平台中会确定自身的状态，并以状态为主平台的云管理平台来对外提供云服务，而其余云管理平台则作为从平台与主平台数据同步。在状态切换条件被触发时(如主平台宕机时)，即触发切换，将某一个从平台切换为新的主平台来继续对外提供云服务。这就使得云管理平台组中始终可以有一个主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

本申请实施例还提供了一种云平台切换控制装置，包括：第二状态确认模块和平台管控模块；所述第二状态确认模块用于从云管理平台组中确定一个云管理平台作为主平台，以通过所述主平台提供云服务，其余云管理平台作为从平台不提供云服务；所述云管理平台组中有至少两个云管理平台部署在不同的数据中心上；所述平台管控模块用于将所述主平台的数据实时同步到至少一个从平台中，并在所述主平台宕机时，向所述从平台中的一个具有所述主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务。

在上述实现结构中，部署有至少两个云管理平台，且这些云管理平台会分别部署在至少两个数据中心上。在整个实现过程中，会从这些云管理平台中确定出一个主平台来对外提供云服务，而其余云管理平台则作为从平台与主平台数据同步。在主平台宕机时，会以某一个从平台切换为新的主平台来继续对外提供云服务。这就使得无论因为何种原因导致的主平台宕机，都可以迅速切换到一个新的主平台来继续对外提供云服务。从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

本申请实施例还提供了一种分布式云平台系统，其特征在于，包括云管理平台组，所述云管理平台组中有至少两个云管理平台部署在不同的数据中心上；所述云管理平台组中的一个云管理平台为主平台来提供云服务，其余云管理平台为从平台不提供云服务；所述主平台的数据实时同步到至少一个从平台中，并在所述主平台宕机时，以所述从平台中的一个具有所述主平台数据的从平台作为新的主平台来继续提供云服务。

在上述实现结构中，会部署至少两个云管理平台，且这些云管理平台会分别部署在至少两个数据中心上。这些云管理平台中，一个云管理平台为主平台来提供云服务，其余云管理平台为从平台不提供云服务，但会与主平台数据同步。在主平台宕机时，会以某一个从平台切换为新的主平台来继续对外提供云服务。这就使得无论因为何种原因导致的主平台宕机，都可以迅速切换到一个新的主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

进一步地，所述分布式云平台系统还包括管理设备，所述管理设备与所述云管理平台组中的各云管理平台数据连接，并用于管理所述云管理平台组中的各云管理平台的状态；所述状态包括主平台和从平台。

在上述实现结构中，通过管理设备来确定各云管理平台的状态，使得各个云管理平台本身不需要进行状态确认，使得每一个云管理平台都需要进行的状态确认过程由一个管理设备来实现，节约了整个系统的资源。

本申请实施例还提供了一种电子设备，包括处理器、存储器及通信总线；所述通信总线用于实现处理器和存储器之间的连接通信；所述处理器用于执行存储器中存储的一个或者多个第一程序，以实现上述第一种云平台切换控制方法的步骤；

或，所述处理器用于执行存储器中存储的一个或者多个第二程序，以实现上述第二种云平台切换控制方法的步骤。

在上述实现过程中，通过电子设备的处理器来执行上述云平台切换控制方法，可以使得无论因为何种原因导致的主平台宕机，都可以迅速切换到一个新的主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

本申请实施例中还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述任意一种云平台切换控制方法的步骤。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种云平台切换控制方法的流程示意图；

图2为本申请实施例提供的一种带管理设备的分布式云平台系统的结构图；

图3为本申请实施例提供的另一种云平台切换控制方法的流程示意图；

图4为本申请实施例提供的一种分布式云平台系统的结构图；

图5为本申请实施例提供的一种云平台切换控制装置的结构框图；

图6为本申请实施例提供的另一种云平台切换控制装置的结构框图；

图7为本申请实施例提供的一种云平台切换的流程化示意图；

图8为本申请实施例提供的一种云平台切换的结构化示意图；

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

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

实施例一：

请参看图1，图1为本申请实施例提供的一种云平台切换控制方法的流程示意图，其可以应用于管理设备上，包括：

s101：从云管理平台组中确定一个云管理平台作为主平台，以通过该主平台提供云服务，其余云管理平台作为从平台不提供云服务；

需要说明的是，本实施例中所述的管理设备，其可以为某一个数据中心的实体设备，此时管理设备中可以有一个云管理平台，且有一个与该云管理平台独立的管理平台来执行本实施例的云平台切换控制方法的各个步骤，例如图2所示的结构。但是，需要注意的是，这种情况下，一旦管理设备中云管理平台为主平台，则管理设备故障时，则可能会导致主平台宕机且不能切换出新的主平台的情况，对用户造成不好的使用体验，并可能会为用户带来损失。对此，本申请实施例中管理设备也可以为第三方设备，例如可以是设置在客户公司或云管理平台运维中心的某一个专门的设备，该设备中即不会设置云管理平台，这样在管理设备故障时，不会导致主平台的宕机，而在主平台宕机时，只要管理设备不同时故障即可保证云服务可以始终有效的提供给用户，保证用户的实用体验。

还需要说明的是，本申请实施例中，云管理平台组中包含有至少两个云管理平台，而云管理平台组中有至少两个云管理平台部署在不同的数据中心上。即在本申请实施例中，记共有a个数据中心(a大于等于2)，有b个云管理平台(b大于等于2，a和b之间没有绝对的数值大小关系)，而在a个数据中心中，布置有云管理平台的数据中心至少有两个。例如，可以在每一个数据中心均分别布置一个云管理平台(此时a等于b)；又例如，可以在a个数据中心的其中a1(a1小于a大于等于2)个数据中心上布置分别布置一个云管理平台(此时b等于a1)。而在布置有云管理平台的数据中心上，其布置的云管理平台可以如上例中所示为1个，但也可以为多个，例如可以在一个数据中心布置两个云管理平台。

特别需要说明的是，本实施例中每个云管理平台可以使用独立的数据库，安装所有系统组件，具备可独立管理其余数据中心的能力，从而保证每个云管理平台都具有独立的对外提供云服务的能力。

在本申请实施例中，管理设备从云管理平台组中确定一个云管理平台作为主平台的方式可以是：获取云管理平台组中各云管理平台的性能评分，进而通过比较各云管理平台的性能评分，确定性能评分最高的云管理平台为主平台来提供云服务，其余云管理平台作为从平台。其中，性能评分为根据各云管理平台的硬件性能和通信能力计算得到的分数。

在本实施例中，性能评分可以是各个云管理平台根据自身的硬件性能和通信能力计算得到的，此时各云管理平台得到自身的性能评分后，将该性能评分发送给管理设备，管理设备即可进行性能评分的比较，确定出主平台和从平台。此外，本实施例中，也可以是由管理设备来获取各个云管理平台的硬件性能和通信能力，进而分别根据各个云管理平台的硬件性能和通信能力分别计算出各个云管理平台的性能评分，再进行性能评分的比较，确定出主平台和从平台。

可选的，上述云管理平台的硬件性能可以包括以下至少之一：云管理平台的主频数、核数、内存大小、宿主机的cpu利用率等，而云管理平台的通信能力则包括：通信时数据到达预设ip地址的延迟。

示例性的，在计算性能评分时，可以仅采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的一种来结合云管理平台的通信能力计算得到云管理平台的性能评分；也可以采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的其中两种(如主频数+核数、主频数+内存大小、主频数+宿主机的cpu利用率、核数+内存大小、核数+宿主机的cpu利用率、宿主机的cpu利用率+内存大小)来结合云管理平台的通信能力计算得到云管理平台的性能评分；也可以采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的其中三种(如主频数+核数+内存大小、主频数+核数+宿主机的cpu利用率、主频数+内存大小+宿主机的cpu利用率)来结合云管理平台的通信能力计算得到云管理平台的性能评分；还可以同时采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率共同来结合云管理平台的通信能力计算得到云管理平台的性能评分。应当理解的是，在采用来进行性能评分计算的硬件性能越多时，计算出的性能评分对于云管理平台的综合性能的体现就更完善，最终确定下来的主平台就越可能是综合性最好的、可以提供最优质云服务的云管理平台。

示例性的，通信能力为通信时数据到达预设ip地址的延迟时，预设ip地址可以为用户的ip地址(如用户的企业ip地址)，这时得到的延迟即可反应出云管理平台为用户提供数据服务的通信能力强弱。延迟越大则表明该云管理平台为用户提供数据服务的通信能力越弱，在计算性能评分时，该延迟为负向考虑值。需要理解的是，预设ip可以由工程师根据实际需要设定，本实施例不作具体限定。

特别需要注意的是，在本申请实施例中，各个云管理平台的性能评分计算公式应当是一致的。以同时采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率共同来结合云管理平台的通信能力计算得到云管理平台的性能评分的情况为例，可以设定按照以下计算式来计算性能评分：(主频(ghz)*核数*a1+内存(gb)*a2+宿主机繁忙度*a3)/(√相对延迟)*a4)，其中宿主机繁忙度为(a5/当前承载云平台的宿主机cpu利用率)，相对延迟为通信时数据到达预设ip地址的延迟。前述a1-a5为权重系数，具体指可以由工程师根据实际需要设定，如可以设定a1、a2、a5为1000，a3为1，a4为10。需要说明的是，前述公式为本实施例说示例的一种可选公式，但不代表本申请实施例仅可采用这一种公式来计算性能评分，具体的计算公式可以由工程师根据实际需要而设定。

应当理解的是，本申请实施例并不限定只能依据性能评分来确定主平台和从平台。事实上，本申请实施例中也可以不依据性能评分来确定主平台和从平台，而是按照其他方式来实现主平台和从平台的确定。例如，可以由管理设备随机指定一个平台作为主平台；又例如可以由管理设备按照与各云管理平台的连接先后顺序，确定最先与管理设备建立连接的云管理平台来作为主平台。事实上，只要管理设备能从云管理平台组中确定出主平台和从平台的任何方式都应在本申请的保护范围内。

在本申请实施例中，管理设备可以通过通知消息等形式，通知各云管理平台其为主平台还是从平台。

s102：将主平台的数据实时同步到至少一个从平台中，并在主平台宕机时，向从平台中的一个具有主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务。

在本申请实施例中，管理设备至少可以通过以下方式来实现将主平台的数据实时同步到至少一个从平台中：

方式一：管理设备可以发送控制指令来控制主平台将数据实时同步到至少一个从平台中。特别的，控制指令可以携带在通知其为主平台的通知消息中，这样管理设备通过一次信息发送即可实现对云管理平台身份或状态(即自身为主平台还是从平台)的通知以及对数据实时同步的控制，主平台在接收到该信息时，即可建立与至少一个从平台的数据通信，进行数据的实时同步。

方式二：管理设备可以不发送控制指令，而是在各个云管理平台中写入在自身作为主平台时自动与至少一个从平台建立数据通信，进行数据的实时同步的指令，从而在云管理平台在收到管理设备发来的通知自身为主平台的通知消息后，即可自动实现与至少一个从平台的数据实时同步。

方式三：管理设备可以作为数据中转设备，从主平台处实时获取主平台的数据并实时传输到至少一个从平台中。此时，管理设备在获取到主平台的数据时还可以进行数据备份，从而有效保证主平台数据的完整性。

在本申请实施例中，管理设备可以对云管理平台组中各云管理平台的运行情况进行监控，从而监测到云管理平台的宕机和恢复情况，并对应的进行管控。例如，在本申请实施例中，管理设备在向从平台中的一个具有主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务之后，如果检测到宕机前次宕机的主平台从宕机中恢复了，此时则可以将该前次宕机的主平台降级为从平台，从而减少云管理平台的切换次数，保证对外提供的云服务平稳。此外，也可以在检测到前次宕机的主平台从宕机中恢复时，将当前的主平台降级为从平台，并将该宕机的主平台重新作为主平台。

需要说明的是，在本申请实施例中，管理设备可以向相关云管理平台发出状态变更指令，而云管理平台接收到该指令后即根据该指令进行状态变更。例如，管理设备可以向当前状态为主平台的云管理平台a发送降级为从平台的状态变更指令，云管理平台a接收到指令后，即变更自己状态为从平台，停止对外提供云服务。

在本实施例中，从平台可以进一步细分为两类，分别为待切换平台和隶从平台。其中，待切换平台为从平台中预备切换为主平台的从平台，而从平台中除待切换平台外的从平台即为隶从平台。

在本申请实施例中，可以先从平台中确定一个从平台为待切换平台，再将主平台的数据实时同步到待切换平台中。这样，在主平台宕机时，管理平台直接向待切换平台发送主平台切换指令，以将待切换平台作为新的主平台继续提供云服务。

在本申请实施例中，从所有从平台中确定出一个待切换平台的过程可以通过以下方式来实现：

方式一：可以在从云管理平台组中确定出主平台的同时，确定出待切换平台和隶从平台。例如，管理设备在比较各云管理平台的性能评分后，将性能评分最高的云管理平台作为主平台，而将性能评分第二高的云管理平台作为从平台中的待切换平台，其余的则作为隶从平台，这样只需要一次比较即可实现对各云管理平台状态(本实施例中云管理平台在云管理平台组中的状态包括主平台和从平台，而从平台状态则包括待切换平台和隶从平台)的确定，节约了资源。

方式二：可以在从云管理平台组中确定出主平台后，再次获取所有从平台的性能评分来进行比对，将性能评分最高的从平台确定为待切换平台。需要说明的是，从平台的性能评分也是根据各从平台的硬件性能和数据通信能力计算得到的，但是其所选取的硬件性能、数据通信能力、计算公式等可以和从云管理平台组中确定出主平台时所选用的不同(可以是部分不同，如硬件性能、计算公式相同，数据通信能力不同，也可以是三者都不同)。在本实施例的一种可行实施方式中，在从云管理平台组中确定出主平台时，数据通信能力可以为各云管理平台与用户ip的通信能力，例如各云管理平台通信时数据到达用户ip的延迟；而确定待切换平台时的通信能力可以为从平台与主平台之间的数据通信能力，例如为各从平台通信时数据到达主平台的延迟。

方式二中，获取所有从平台的性能评分的方式至少包括以下两种：

其一：可以由管理设备来获取各从平台的硬件性能和各从平台与主平台之间的数据通信能力；进而根据各从平台的硬件性能和各从平台与主平台之间的数据通信能力计算各从平台的性能评分。

其二：可以由各从平台根据自身的硬件性能和与主平台之间的数据通信能力计算得到自身的性能评分，再发送给管理设备汇总。

需要说明的是，由于待切换平台是在主平台宕机后会立刻切换为新的主平台以保证对外提供的云服务不会出现断档，那么为了保证后面切换的有效性，避免出现切换后服务断层的问题，待切换平台需要实时同步主平台的数据。而对于隶从平台而言，其对于主平台的数据需求的时限要求则没有待切换平台那么高，因此可以采用异步传输的方式来获取主平台的数据。此外，由于主平台需要对外提供云服务，所以为了保证其具有充足的资源来提供云服务，可以设置隶从平台从待切换平台处获取主平台数据，从而降低对于主平台的数据传输压力。

特别需要说明的是，在将待切换平台切换为主平台之后，管理设备可以重新在当前状态为从平台的云管理平台中确定出一个新的待切换平台来与主平台进行主平台数据的实时同步。

应到了解的是，除了上述先确定出一个待切换平台，再由待切换平台来实现与主平台的数据同步的方式以外，还可以先进行数据同步，进而在需要进行主平台切换时再进行从从平台中确定出一个待切换平台来切换为主平台。示例性的，管理设备可以先控制将主平台的数据实时同步到所有从平台中；进而在检测到主平台宕机时，获取各从平台的性能评分，并向性能评分最高的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务。需要说明的是，此时获取的性能评分可以是之前在确定主平台时获取到的各云管理平台的性能评分，但也可以是针对从平台重新获取到的性能评分。关于如何针对从平台重新获取到性能评分在上述先确定出一个待切换平台，再由待切换平台来实现与主平台的数据同步的方式中已有相关描述，在此不再赘述。

还需要说明的是，在本申请实施例中，管理设备可以通过判断是否n(n大于0，具体值可以有工程师根据实际需求设定)分钟内无法与云管理平台通讯来判定各云管理平台是否宕机(n分钟内无法与某一云管理平台通讯，即可以认为该云管理平台宕机)。进一步的，为了防止误判，在监测到n分钟内无法与某一云管理平台通讯时，可以进一步判断自身是否还可以与其他其他云管理平台通讯，如果可以即表明自身设备没有问题，无法通讯的原因在于该云管理平台，可以认为该云管理平台宕机。此外，为了防止误判，在监测到n分钟内无法与某一云管理平台通讯时，还可以进一步判断其余云管理平台是否可以与预设ip(可以为用户的ip，如用户公司ip地址等)进行通讯，如果可以，则可以认为该云管理平台宕机。事实上，为了最大限度防止误判，可以同时进行以上三个条件的判断，在三者均满足时，可以认定该n分钟内无法进行通信的云管理平台宕机。

值得注意的是，在本申请实施例中上述宕机检测过程可以针对每一个云管理平台都执行，但也可以仅针对特定的云管理平台执行，如仅针对主平台和/或待切换平台执行，以降低管理设备的资源消耗。

在实际应用中，云管理平台的某些硬件性能和通信能力可能会有一定的变动，如宿主机的cpu利用率、通信时数据到达预设ip地址的延迟等在不同时间检测得到的数值可能会不同。因此本申请实施例中还可以由管理设备周期性的对各云管理平台进行性能评分的获取比对，再按照最新的性能评分的结果重新确定主平台和或待切换平台，从而保证为用户提供云服务的云管理平台的性能是最优的，保证用户可以得到最好的使用体验。

综上所述，本申请实施例提供一种云平台切换控制方法，会部署至少两个云管理平台，且这些云管理平台会分别部署在至少两个数据中心上。在整个实现过程中，会从这些云管理平台中确定出一个主平台来对外提供云服务，而其余云管理平台则作为从平台与主平台数据同步。在主平台宕机时，会以某一个从平台切换为新的主平台来继续对外提供云服务。这就使得无论因为何种原因导致的主平台宕机，都可以迅速切换到一个新的主平台来继续对外提供云服务。从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

实施例二：

请参看图3，图3为本申请实施例提供的一种云平台切换控制方法的流程示意图，其可以应用于云管理平台组中的任意一个云管理平台上，包括：

s301：第一云管理平台确定自身在云管理平台组中的当前状态；

需要说明的是，本申请实施例中，云管理平台组中包含有至少两个云管理平台，而云管理平台组中有至少两个云管理平台部署在不同的数据中心上。即在本申请实施例中，记共有a个数据中心(a大于等于2)，有b个云管理平台(b大于等于2，a和b之间没有绝对的数值大小关系)，而在a个数据中心中，布置有云管理平台的数据中心至少有两个。而在布置有云管理平台的数据中心上，其布置的云管理平台可以为1个，但也可以为多个。本实施例中云管理平台组的组间结构可以参见图4所示，组内各个云管理平台通过通信总线实现组间通信。

还需要说明的是，本实施例中第一云管理平台是云管理平台组中的任意一个云管理平台，其在云管理平台组中的状态包括主平台和从平台。

特别需要说明的是，本实施例中每个云管理平台可以使用独立的数据库，安装所有系统组件，具备可独立管理其余数据中心的能力，从而保证每个云管理平台都具有独立的对外提供云服务的能力。

在本实施例中，云管理平台组中的每一个云管理平台均可单独进行云管理平台组中各云管理平台的当前状态的确定，具体的，以第一云管理平台为例，其可以根据自身的硬件性能和通信能力得到自身的性能评分，同时可以获取云管理平台组中其余云管理平台的性能评分，在自身的性能评分最高时，确定自身在云管理平台组中的当前状态为主平台；否则，确定自身在云管理平台组中的当前状态为从平台。其中，其余云管理平台的性能评分为基于其余云管理平台自身的硬件性能和通信能力得到的分数。

为了便于表述，本申请中记处于主平台状态的云管理平台为主平台，处于从平台状态的云管理平台为从平台。

在本实施例中，云管理平台可以获取其余云管理平台的硬件性能和通信能力，进而分别根据其余云管理平台的硬件性能和通信能力分别计算出其余云管理平台的性能评分，再结合自身的性能评分进行性能评分的比较，即可确定出自身在云管理平台组内的状态是主平台还是从平台。但应当理解的是，这种方式每一个云管理平台都需要计算组内所有的云管理平台的性能评分，即假设组内有x个云管理平台，那么每一个云管理平台都需要计算出x个性能评分，对于各云管理平台而言计算资源的消耗都较大。对此，本实施例中云管理平台的性能评分可以是云管理平台分别根据自身的硬件性能和通信能力计算得到的，云管理平台在得到自身的性能评分后，可以将该性能评分在组间进行通告，从而使得组内的所有云管理平台都能获取到该性能评分。通过这种方式，每一个云管理平台都会自己计算自己的性能评分，并组内通告，使得每一个云管理平台都能获取到组内所有云管理平台的性能评分，降低了各云管理平台的计算消耗。

可选的，上述云管理平台的硬件性能可以包括以下至少之一：云管理平台的主频数、核数、内存大小、宿主机的cpu利用率等，而云管理平台的通信能力则包括：通信时数据到达预设ip地址的延迟。

示例性的，在计算性能评分时，可以仅采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的一种来结合云管理平台的通信能力计算得到云管理平台的性能评分；也可以采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的其中两种(如主频数+核数、主频数+内存大小、主频数+宿主机的cpu利用率、核数+内存大小、核数+宿主机的cpu利用率、宿主机的cpu利用率+内存大小)来结合云管理平台的通信能力计算得到云管理平台的性能评分；也可以采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的其中三种(如主频数+核数+内存大小、主频数+核数+宿主机的cpu利用率、主频数+内存大小+宿主机的cpu利用率)来结合云管理平台的通信能力计算得到云管理平台的性能评分；还可以同时采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率共同来结合云管理平台的通信能力计算得到云管理平台的性能评分。应当理解的是，在采用来进行性能评分计算的硬件性能越多时，计算出的性能评分对于云管理平台的综合性能的体现就更完善，这样组间最终确定下来的作为主平台的云管理平台就越可能是综合性最好的、可以提供最优质云服务的云管理平台。

示例性的，通信能力为通信时数据到达预设ip地址的延迟时，预设ip地址可以为用户的ip地址(如用户的企业ip地址)，这时得到的延迟即可反应出云管理平台为用户提供数据服务的通信能力强弱。延迟越大则表明该云管理平台为用户提供数据服务的通信能力越弱，在计算性能评分时，该延迟为负向考虑值。需要理解的是，预设ip可以由工程师根据实际需要设定，本实施例不作具体限定。

特别需要注意的是，在本申请实施例中，各个云管理平台的性能评分计算公式应当是一致的。以同时采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率共同来结合云管理平台的通信能力计算得到云管理平台的性能评分的情况为例，可以设定按照以下计算式来计算性能评分：(主频(ghz)*核数*a1+内存(gb)*a2+宿主机繁忙度*a3)/(√相对延迟)*a4)，其中宿主机繁忙度为(a5/当前承载云平台的宿主机cpu利用率)，相对延迟为通信时数据到达预设ip地址的延迟。前述a1-a5为权重系数，具体指可以由工程师根据实际需要设定，如可以设定a1、a2、a5为1000，a3为1，a4为10。需要说明的是，前述公式为本实施例说示例的一种可选公式，但不代表本申请实施例仅可采用这一种公式来计算性能评分，具体的计算公式可以由工程师根据实际需要而设定。

应当理解的是，本实施例中，还可以指定某一个或某几个云管理平台进行云管理平台组内各云管理平台的性能评分的计算，进而在计算出性能评分确定出各云管理平台的当前状态并进行组内通告，从而使得组内各云管理平台得以确定自身在云管理平台组中的当前状态。

还应当理解的是，本实施例中，还可以通告第三方设备来进行云管理平台组内各云管理平台的性能评分的计算，以及各云管理平台的当前状态的确定(例如可以采用如实施例一中的管理设备来实现对各云管理平台的当前状态的确定)，在第三方设备确定出各云管理平台的当前状态后将各云管理平台的当前状态发送给各云管理平台，即可使得各云管理平台确定出自身在云管理平台组中的当前状态。

应当理解的是，本申请实施例并不限定只能依据性能评分来确定第一云管理平台在云管理平台组中的当前状态是主平台还是从平台。事实上，本申请实施例中也可以不依据性能评分来确定自身的当前状态是主平台还是从平台，而是按照其他方式来实现自身当前状态的确定。例如，可以以产生随机数的方式，组间产生的随机数最大的云管理平台即确定自身为主平台。事实上，只要云管理平台中可以确定出自身在云管理平台组中的当前状态的任何方式都应在本申请的保护范围内。

s302：在状态切换条件被触发时，将自身的当前状态切换为与当前状态对应的目标状态。

示例性的，在目标状态为主平台时，则将自身的当前状态切换为主平台，以对外提供云服务，并将自身数据实时同步到组内的从平台中；在目标状态为从平台时，则将自身的当前状态切换为从平台并获取主平台的数据。

需要说明的是，本申请实施例中状态切换条件包括但不限于以下之一：第一云管理平台当前状态为从平台且当前主平台宕机；第一云管理平台当前状态为从宕机中恢复；第一云管理平台重新确定的最新状态和当前状态不一致。上述状态切换条件满足时即可以认为状态切换条件被触发，需要将自身的当前状态切换为目标状态。需要说明的是，目标状态是与当前状态相对应的，例如在当前状态为主平台，而第一云管理平台重新确定的最新状态为从平台时，最新状态从平台即是当前状态对应的目标状态，第一云管理平台需要将自身从主平台切换为从平台。

在本实施例的一种可行实施方式中，在第一管理云平台处于主平台状态时宕机后，在第一管理云平台从宕机中恢复时，此时至少可以有以下两种执行方式：

其一：可以在从宕机中恢复时，将自身当前状态从主平台切换为从平台，从而减少云管理平台组内对于主平台的切换次数，保证对外提供的云服务平稳。

其二：也可以在从宕机中恢复时，通知当前的主平台切换为从平台，并在当前的主平台切换为从平台后，重新作为主平台对外提供云服务。

需要说明的是，在本申请实施例中，各云管理平台可以记录自身的当前状态以供组内的其余云管理平台获取、知晓其当前状态。

在本实施例中，从平台状态可以包括待切换平台状态和隶从平台状态，其中，待切换平台状态的云管理平台即为从平台状态中预备切换为主平台状态的云管理平台，而从平台中除待切换平台外的即为隶从平台。此时在步骤s302中，若目标状态为待切换平台，则第一云管理平台需要将自身状态切换为待切换平台，并以实时同步的方式获取主平台的数据，从而保证在主平台宕机时，待切换平台可以迅速切换为新的主平台继续提供云服务。

若目标状态为隶从平台，则切换为隶从平台，并从待切换平台处获取主平台的数据。隶从平台从待切换平台处获取主平台数据，可以降低对于主平台的数据传输压力。此外，隶从平台可以以异步传输的方式从待切换平台处获取主平台数据，从而降低待切换平台数据迸发量。

为了便于表述，本申请中记处于待切换平台状态的从平台为待切换平台，处于隶从台状态的从平台为隶从平台。

需要说明的是，在存在待切换平台状态时，云管理平台组中各云管理平台在确定自身当前状态时，即可确定出待切换平台。在本实施例中，云管理平台可以通过以下两种方式确定自身是否为待切换平台。

方式一：与上述确定自身为主平台还是从平台时类似，可以通过比较自身与其余云管理平台的性能评分后，在自身的性能评分最高时确定自身为主平台，在自身的性能评分第二高时确定自身为从平台中的待切换平台，其余情况即确定自身为隶从平台。

方式二：可以如上述根据性能评分确定自身为从平台后，再次获取组内的所有从平台的性能评分来进行比对，在自身的性能评分最高时确定自身为待切换平台。需要说明的是，本次获取的性能评分也是根据各从平台的硬件性能和数据通信能力计算得到的，但是其所选取的硬件性能、数据通信能力、计算公式等可以和从前一次确定出自身为从平台时所选用的不同(可以是部分不同，如硬件性能、计算公式相同，数据通信能力不同，也可以是三者都不同)。在本实施例的一种可行实施方式中，在前一次确定出自身为从平台时，所选用的数据通信能力可以为各云管理平台与用户ip的通信能力，例如各云管理平台通信时数据到达用户ip的延迟；而本次确定自身是否为待切换平台时的通信能力则可以为从平台与主平台之间的数据通信能力，例如为各从平台通信时数据到达主平台的延迟。

方式二中，获取所有从平台的性能评分的方式至少包括以下两种：

其一：可以根据自己的硬件性能和与主平台之间的数据通信能力计算出自己的性能评分，同时获取其余各从平台的硬件性能和其余各从平台与主平台之间的数据通信能力，进而根据其余各从平台的硬件性能和各从平台与主平台之间的数据通信能力计算其余各从平台的性能评分。

其二：可以根据自己的硬件性能和与主平台之间的数据通信能力计算出自己的性能评分并进行组内通告，同时获取其余各从平台通告的性能评分。

需要说明的是，在组内一旦发生了待切换平台切换为主平台的情况，为了保证本实施例的方案可以不断实行下去，隶从平台可以再次进行自身在云管理平台组中的当前状态的确定，从而确定出一个待切换平台。

此外，需要说明的是本实施例的一种可行实施方式中，从平台状态可以不区分为待切换平台和隶从平台。此时主平台可以实时将数据同步给所有从平台，而在主平台宕机时，各从平台即重新确定自身在云管理平台组中的当前状态，例如根据性能评分进行比较，如自身的性能评分最高者确定为主平台，对外提供云服务。

还需要说明的是，在本申请实施例中，组内各云管理平台可以通过判断是否n(n大于0，具体值可以有工程师根据实际需求设定)分钟内无法与主平台通讯来判定主平台是否宕机(n分钟内无法与主平台通讯，即可以认为该主平台宕机)。进一步的，为了防止误判，在监测到n分钟内无法与主平台通讯时，可以进一步判断自身是否还可以与其他其他云管理平台通讯，如果可以即表明自身设备没有问题，无法通讯的原因在于主平台，可以认为主平台宕机。此外，为了防止误判，在监测到n分钟内无法与主平台通讯时，还可以进一步判断自己是否可以与预设ip(可以为用户的ip，如用户公司ip地址等)进行通讯，如果可以，则可以认为主平台宕机。事实上，为了最大限度防止误判，可以同时进行以上三个条件的判断，在三者均满足时，可以认定主平台宕机。

值得注意的是，在本申请实施例中上述对主平台的宕机检测过程每一个云管理平台都可以执行，但也可以仅由特定的云管理平台执行，如仅由待切换平台执行。

在实际应用中，云管理平台的某些硬件性能和通信能力可能会有一定的变动，如宿主机的cpu利用率、通信时数据到达预设ip地址的延迟等在不同时间检测得到的数值可能会不同。因此本申请实施例中组内各云管理平台还可以周期性的进行性能评分的获取比对，再按照最新的性能评分的结果重新确定自身的当前状态应该为何，从而保证为用户提供云服务的云管理平台的性能是最优的，保证用户可以得到最好的使用体验。

综上所述，本申请实施例提供一种云平台切换控制方法，会部署至少两个云管理平台，且这些云管理平台会分别部署在至少两个数据中心上。在整个实现过程中，管理平台组中的云管理平台中会确定自身的状态，并以状态为主平台的云管理平台来对外提供云服务，而其余云管理平台则作为从平台与主平台数据同步。在状态切换条件被触发时(如主平台宕机时)，即触发切换，将某一个从平台切换为新的主平台来继续对外提供云服务。这就使得云管理平台组中始终可以有一个主平台来继续对外提供云服务。从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

实施例三：

本实施例中提供了一种分布式云平台系统，可以参见图4所示，包括云管理平台组，云管理平台组中有至少两个云管理平台部署在不同的数据中心上。即云管理平台组中包含有至少两个云管理平台，而云管理平台组中有至少两个云管理平台部署在不同的数据中心上。即在本申请实施例中，记共有a个数据中心(a大于等于2)，有b个云管理平台(b大于等于2，a和b之间没有绝对的数值大小关系)，而在a个数据中心中，布置有云管理平台的数据中心至少有两个。而在布置有云管理平台的数据中心上，其布置的云管理平台可以为1个，也可以为多个。

此外，云管理平台组中的每个云管理平台可以使用独立的数据库，安装所有系统组件，具备可独立管理其余数据中心的能力，从而保证每个云管理平台都具有独立的对外提供云服务的能力。

本实施例中，云管理平台组中的一个云管理平台为主平台来提供云服务，其余云管理平台为从平台不提供云服务；主平台的数据实时同步到至少一个从平台中，并在主平台宕机时，以从平台中的一个具有主平台数据的从平台作为新的主平台来继续提供云服务。

可选的，参见图2所示，分布式云平台系统还可以包括管理设备，管理设备与云管理平台组中的各云管理平台数据连接，并用于管理云管理平台组中的各云管理平台的状态；云管理平台的状态包括主平台和从平台。而从平台中可以进一步分为待切换平台和隶从平台。

需要说明的是，在上述图4的结构中，可以采用上述实施例二所述的云平台切换控制方法来实现主平台的切换管控；而在上述图2的结构中，则可以采用上述实施例一或实施例二所述的云平台切换控制方法来实现主平台的切换管控，在此不再赘述。

本实施例提供的分布式云平台系统中，会部署至少两个云管理平台，且这些云管理平台会分别部署在至少两个数据中心上。这些云管理平台中，一个云管理平台为主平台来提供云服务，其余云管理平台为从平台不提供云服务，但会与主平台数据同步。在主平台宕机时，会以某一个从平台切换为新的主平台来继续对外提供云服务。这就使得无论因为何种原因导致的主平台宕机，都可以迅速切换到一个新的主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

实施例四：

本实施例提供了一种分布式云平台系统和云平台切换控制方法，适用于具有两个或两个以上的数据中心的云服务应用场景中。

本实施例中，在每个数据中心中部署至少一个云管理平台，并且每个云管理平台使用独立的数据库，安装所有系统组件，具备可独立管理其余数据中心的能力。

云管理平台通过计算，选举出一位响应速度最快的云管理平台作为master(主平台)，其余的云管理平台作为从平台。

在从平台中选择与master通讯速度最快的云管理平台作为foreman(待切换平台)，foreman与slave(隶从平台，除foreman之外的从平台)进行数据同步。

master与foreman数据库实时同步，master一旦停机，foreman立刻成为master，同时在现有slave中选举出新的foreman与新master实时同步数据库。原master恢复后角色变为salve，通过该模型循环往复。

正常情况下，仅master提供服务，foreman与slave不对外提供服务。

特别需要说明的是，本实施例中允许slave数量为0的情况，即只有两个云管理平台分别设置在不同数据中心的场景，在该场景下只触发master选举机制，剩余的则为foreman。

以下描述master的选举机制、master的宕机判定机制和恢复后原master的降级机制：

master的选举机制：

master：计算性能评分：(主频(ghz)*核数*1000+内存(gb)*1000+宿主机繁忙度)/(√相对延迟)*10*)，得分最高的作为master。

相对延迟：为各云平台到某指定ip地址(例如用户公司总部的ip地址)的延迟。允许用户根据实际情况自己定义。其中：

宿主机繁忙度＝(1000/当前承载云平台的宿主机cpu利用率)。

foreman：在从平台中，同样利用公式进行计算性能评分：(主频(ghz)*核数*1000+内存(gb)*1000+当前宿主机繁忙度)/(√相对延迟)*10。得分最高的作为foreman。其中：

相对延迟为：各从平台到master数据中心的延迟。

slave：剩余的从平台均为slave。

master的宕机判定机制：

1.foreman在1分钟内无法与master通讯；

2.foreman能够与其他其他salve通讯；

3.foreman能够与指定ip进行通讯；

以上三点同时满足即可认定master宕机。

恢复后原master的降级机制：

原master恢复后，检查分布式云平台系统中是否存在有master，若有则原master自动降级为slave。同时会与foreman通过异步传输的方式同步数据。

参见图7所示，图7即为上述过程的流程化示意图，同时参见图8所示，图8示意了数据中心1上的cmp(云管理平台)为master时的数据中心管理和云管理平台组间数据同步的过程，以及数据中心1上的cmp宕机后，切换为数据中心2上的cmp为master时的数据中心管理和云管理平台组间数据同步的过程。

通过上述方案，可以在主平台宕机时迅速切换到一个新的主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

实施例五：

请参看图5，图5为本申请实施例提供的一种云平台切换控制装置5的结构示意图，包括：第一确认模块51和切换控制模块52。需要说明的是，云平台切换控制装置5可以用在云管理平台组的云管理平台中，在本实施例中可以以云平台切换控制装置5来实现云管理平台组中云管理平台的功能，因此本实施例中可以将云平台切换控制装置5视为云管理平台进行理解。其中：

第一确认模块51用于确定自身在云管理平台组中的当前状态；

需要说明的是，本申请实施例中，云管理平台组中包含有至少两个云管理平台，而云管理平台组中有至少两个云管理平台部署在不同的数据中心上。即在本申请实施例中，记共有a个数据中心(a大于等于2)，有b个云管理平台(b大于等于2，a和b之间没有绝对的数值大小关系)，而在a个数据中心中，布置有云管理平台的数据中心至少有两个。而在布置有云管理平台的数据中心上，其布置的云管理平台可以为1个，但也可以为多个。

需要说明的是，上述状态包括主平台和从平台。

特别需要说明的是，本实施例中每个云平台切换控制装置5可以使用独立的数据库，安装所有系统组件，具备可独立管理其余数据中心的能力，从而保证每个云平台切换控制装置5都具有独立的对外提供云服务的能力。

在本实施例中，云管理平台组中的每一个云管理平台通过云平台切换控制装置5均可单独进行云管理平台组中各云管理平台的当前状态的确定，具体的，以第一云管理平台(第一云管理平台为云管理平台组中的任意云管理平台)为例，其通过第一确认模块51可以根据自身的硬件性能和通信能力得到自身的性能评分，同时可以获取云管理平台组中其余云管理平台的性能评分，在自身的性能评分最高时，确定自身在云管理平台组中的当前状态为主平台；否则，确定自身在云管理平台组中的当前状态为从平台。其中，其余云管理平台的性能评分为基于其余云管理平台自身的硬件性能和通信能力得到的分数。

为了便于表述，本申请中记处于主平台状态的云管理平台为主平台，处于从平台状态的云管理平台为从平台。

在本实施例中，第一确认模块51可以获取其余云管理平台的硬件性能和通信能力，进而分别根据其余云管理平台的硬件性能和通信能力分别计算出其余云管理平台的性能评分，再结合自身的性能评分进行性能评分的比较，即可确定出自身在云管理平台组内的状态是主平台还是从平台。但应当理解的是，这种方式每一个云平台切换控制装置5都需要计算组内所有的云管理平台的性能评分，即假设组内有x个云管理平台，那么每一个云管理平台都需要计算出x个性能评分，对于各云平台切换控制装置5而言计算资源的消耗都较大。对此，本实施例中云管理平台的性能评分可以是云管理平台通过云平台切换控制装置5分别根据自身的硬件性能和通信能力计算得到的，云管理平台在得到自身的性能评分后，可以通过云平台切换控制装置5将该性能评分在组间进行通告，从而使得组内的所有云管理平台都能获取到该性能评分。通过这种方式，每一个云管理平台的云平台切换控制装置5都会自己计算自己的性能评分，并组内通告，使得每一个云管理平台都能获取到组内所有云管理平台的性能评分，降低了各云管理平台的计算消耗。

可选的，上述云管理平台的硬件性能可以包括以下至少之一：云管理平台的主频数、核数、内存大小、宿主机的cpu利用率等，而云管理平台的通信能力则包括：通信时数据到达预设ip地址的延迟。

示例性的，在计算性能评分时，可以仅采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的一种来结合云管理平台的通信能力计算得到云管理平台的性能评分；也可以采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的其中两种(如主频数+核数、主频数+内存大小、主频数+宿主机的cpu利用率、核数+内存大小、核数+宿主机的cpu利用率、宿主机的cpu利用率+内存大小)来结合云管理平台的通信能力计算得到云管理平台的性能评分；也可以采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的其中三种(如主频数+核数+内存大小、主频数+核数+宿主机的cpu利用率、主频数+内存大小+宿主机的cpu利用率)来结合云管理平台的通信能力计算得到云管理平台的性能评分；还可以同时采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率共同来结合云管理平台的通信能力计算得到云管理平台的性能评分。应当理解的是，在采用来进行性能评分计算的硬件性能越多时，计算出的性能评分对于云管理平台的综合性能的体现就更完善，这样组间最终确定下来的作为主平台的云管理平台就越可能是综合性最好的、可以提供最优质云服务的云管理平台。

示例性的，通信能力为通信时数据到达预设ip地址的延迟时，预设ip地址可以为用户的ip地址(如用户的企业ip地址)，这时得到的延迟即可反应出云管理平台为用户提供数据服务的通信能力强弱。延迟越大则表明该云管理平台为用户提供数据服务的通信能力越弱，在计算性能评分时，该延迟为负向考虑值。需要理解的是，预设ip可以由工程师根据实际需要设定，本实施例不作具体限定。

特别需要注意的是，在本申请实施例中，各个云管理平台中的性能评分计算公式应当是一致的。以同时采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率共同来结合云管理平台的通信能力计算得到云管理平台的性能评分的情况为例，可以设定按照以下计算式来计算性能评分：(主频(ghz)*核数*a1+内存(gb)*a2+宿主机繁忙度*a3)/(√相对延迟)*a4)，其中宿主机繁忙度为(a5/当前承载云平台的宿主机cpu利用率)，相对延迟为通信时数据到达预设ip地址的延迟。前述a1-a5为权重系数，具体指可以由工程师根据实际需要设定，如可以设定a1、a2、a5为1000，a3为1，a4为10。需要说明的是，前述公式为本实施例说示例的一种可选公式，但不代表本申请实施例仅可采用这一种公式来计算性能评分，具体的计算公式可以由工程师根据实际需要而设定。

应当理解的是，本实施例中，还可以指定某一个或某几个云平台切换控制装置5进行云管理平台组内各云管理平台的性能评分的计算，进而在计算出性能评分确定出各云管理平台的当前状态并进行组内通告，从而使得组内各云管理平台得以确定自身在云管理平台组中的当前状态。

还应当理解的是，本实施例中，还可以通告第三方设备来进行云管理平台组内各云管理平台的性能评分的计算，以及各云管理平台的当前状态的确定(例如可以采用如实施例一中的管理设备来实现对各云管理平台的当前状态的确定)，在第三方设备确定出各云管理平台的当前状态后将各云管理平台的当前状态发送给各云平台切换控制装置5，即可使得各云平台切换控制装置5确定出自身的当前状态。

应当理解的是，本申请实施例并不限定只能依据性能评分来确定云管理平台在云管理平台组中的当前状态是主平台还是从平台。事实上，本申请实施例中也可以不依据性能评分来确定自身的当前状态是主平台还是从平台，而是按照其他方式来实现自身当前状态的确定。例如，可以以产生随机数的方式，组间产生的随机数最大的云管理平台即确定自身为主平台。事实上，只要云管理平台中可以确定出自身在云管理平台组中的当前状态的任何方式都应在本申请的保护范围内。

切换控制模块52用于，在状态切换条件被触发时，将自身的当前状态切换为与当前状态对应的目标状态；若目标状态为主平台，则切换为主平台，以对外提供云服务，并将自身数据实时同步到组内的从平台中；若目标状态为从平台，则切换为从平台并获取主平台的数据。

需要说明的是，本申请实施例中状态切换条件包括但不限于以下之一：云平台切换控制装置5当前状态为从平台且当前主平台宕机；云平台切换控制装置5当前状态为从宕机中恢复；云平台切换控制装置5重新确定的最新状态和当前状态不一致。上述状态切换条件满足时即可以认为状态切换条件被触发，需要将自身的当前状态切换为目标状态。需要说明的是，目标状态是与当前状态相对应的，例如在当前状态为主平台，而云平台切换控制装置5重新确定的最新状态为从平台时，最新状态从平台即是当前状态对应的目标状态，云平台切换控制装置5需要将自身从主平台切换为从平台。

在本实施例的一种可行实施方式中，在云平台切换控制装置5处于主平台状态时宕机后，在云平台切换控制装置5从宕机中恢复时，此时至少可以有以下两种执行方式：

其一：可以在从宕机中恢复时，将自身当前状态从主平台切换为从平台，从而减少云管理平台组内对于主平台的切换次数，保证对外提供的云服务平稳。

其二：也可以在从宕机中恢复时，通知当前的主平台切换为从平台，并在当前的主平台切换为从平台后，重新作为主平台对外提供云服务。

需要说明的是，在本申请实施例中，各云平台切换控制装置5可以记录自身的当前状态以供组内的其余云管理平台的云平台切换控制装置5获取、知晓其当前状态。

在本实施例中，从平台状态可以包括待切换平台状态和隶从平台状态，其中，待切换平台状态的云平台切换控制装置5即为从平台状态中预备切换为主平台状态的云平台切换控制装置5，而从平台中除待切换平台外的即为隶从平台。此时若目标状态为待切换平台，则切换控制模块52需要将自身状态切换为待切换平台，并以实时同步的方式获取主平台的数据，从而保证在主平台宕机时，待切换平台可以迅速切换为新的主平台继续提供云服务。若目标状态为隶从平台，则切换为隶从平台，并从待切换平台处获取主平台的数据。隶从平台从待切换平台处获取主平台数据，可以降低对于主平台的数据传输压力。此外，隶从平台可以以异步传输的方式从待切换平台处获取主平台数据，从而降低待切换平台数据迸发量。

为了便于表述，本申请中记处于待切换平台状态的从平台为待切换平台，处于隶从台状态的从平台为隶从平台。

需要说明的是，在存在待切换平台状态时，云管理平台组中各云管理平台通过第一确认模块51在确定自身当前状态时，即可确定出待切换平台。在本实施例中，第一确认模块51可以通过以下两种方式确定自身是否为待切换平台。

方式一：与上述确定自身为主平台还是从平台时类似，通过比较自身与其余云管理平台的性能评分后，在自身的性能评分最高时确定自身为主平台，在自身的性能评分第二高时确定自身为从平台中的待切换平台，其余情况即确定自身为隶从平台。

方式二：可以如上述根据性能评分确定自身为从平台后，再次获取组内的所有从平台的性能评分来进行比对，在自身的性能评分最高时确定自身为待切换平台。需要说明的是，本次获取的性能评分也是根据各从平台的硬件性能和数据通信能力计算得到的，但是其所选取的硬件性能、数据通信能力、计算公式等可以和从前一次确定出自身为从平台时所选用的不同(可以是部分不同，如硬件性能、计算公式相同，数据通信能力不同，也可以是三者都不同)。在本实施例的一种可行实施方式中，在前一次确定出自身为从平台时，所选用的数据通信能力可以为各云管理平台与用户ip的通信能力，例如各云管理平台通信时数据到达用户ip的延迟；而本次确定自身是否为待切换平台时的通信能力则可以为从平台与主平台之间的数据通信能力，例如为各从平台通信时数据到达主平台的延迟。

方式二中，第一确认模块51获取所有从平台的性能评分的方式至少包括以下两种：

其一：可以根据自身云管理平台的硬件性能和与主平台之间的数据通信能力计算出自己的性能评分，同时获取其余各从平台的硬件性能和其余各从平台与主平台之间的数据通信能力，进而根据其余各从平台的硬件性能和各从平台与主平台之间的数据通信能力计算其余各从平台的性能评分。

其二：可以根据自身云管理平台的硬件性能和与主平台之间的数据通信能力计算出自己的性能评分并进行组内通告，同时获取其余各从平台通告的性能评分。

需要说明的是，在组内一旦发生了待切换平台切换为主平台的情况，为了保证本实施例的方案可以不断实行下去，隶从平台可以再次进行自身在云管理平台组中的当前状态的确定，从而确定出一个待切换平台。

此外，需要说明的是本实施例的一种可行实施方式中，从平台状态可以不区分为待切换平台和隶从平台。此时主平台可以通过云平台切换控制装置5中的通信模块实时将数据同步给所有从平台，而在主平台宕机时，各从平台即重新确定自身在云管理平台组中的当前状态，例如根据性能评分进行比较，如自身的性能评分最高者确定为主平台，对外提供云服务。

还需要说明的是，在本申请实施例中，云平台切换控制装置5可以通过判断是否n(n大于0，具体值可以有工程师根据实际需求设定)分钟内无法与主平台通讯来判定主平台是否宕机(n分钟内无法与主平台通讯，即可以认为该主平台宕机)。进一步的，为了防止误判，在监测到n分钟内无法与主平台通讯时，可以进一步判断自身是否还可以与其他其他云管理平台通讯，如果可以即表明自身设备没有问题，无法通讯的原因在于主平台，可以认为主平台宕机。此外，为了防止误判，在监测到n分钟内无法与主平台通讯时，还可以进一步判断自己是否可以与预设ip(可以为用户的ip，如用户公司ip地址等)进行通讯，如果可以，则可以认为主平台宕机。事实上，为了最大限度防止误判，可以同时进行以上三个条件的判断，在三者均满足时，可以认定主平台宕机。

值得注意的是，在本申请实施例中上述对主平台的宕机检测过程每一个云管理平台都可以通过云平台切换控制装置5执行，但也可以仅由特定的云管理平台通过云平台切换控制装置5执行，如仅由待切换平台执行。

在实际应用中，云管理平台的某些硬件性能和通信能力可能会有一定的变动，如宿主机的cpu利用率、通信时数据到达预设ip地址的延迟等在不同时间检测得到的数值可能会不同。因此本申请实施例中组内各云管理平台还可以通过云平台切换控制装置5周期性的进行性能评分的获取比对，再按照最新的性能评分的结果重新确定自身的当前状态应该为何，从而保证为用户提供云服务的云管理平台的性能是最优的，保证用户可以得到最好的使用体验。

综上所述，本申请实施例提供的云平台切换控制装置，云管理平台组中始终可以有一个主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验。

实施例六：

请参看图6，图6为本申请实施例提供的一种云平台切换控制装置6的结构示意图，其可以应用于管理设备上，包括：第二确认模块61和平台管控模块62；

第二确认模块61用于从云管理平台组中确定一个云管理平台作为主平台，以通过所述主平台提供云服务，其余云管理平台作为从平台不提供云服务；

需要说明的是，本申请实施例中，云管理平台组中包含有至少两个云管理平台，而云管理平台组中有至少两个云管理平台部署在不同的数据中心上。即在本申请实施例中，记共有a个数据中心(a大于等于2)，有b个云管理平台(b大于等于2，a和b之间没有绝对的数值大小关系)，而在a个数据中心中，布置有云管理平台的数据中心至少有两个。例如，可以在每一个数据中心均分别布置一个云管理平台(此时a等于b)；又例如，可以在a个数据中心的其中a1(a1小于a大于等于2)个数据中心上布置分别布置一个云管理平台(此时b等于a1)。而在布置有云管理平台的数据中心上，其布置的云管理平台可以如上例中所示为1个，但也可以为多个，例如可以在一个数据中心布置两个云管理平台。

需要说明的是，本实施例中每个云管理平台可以使用独立的数据库，安装所有系统组件，具备可独立管理其余数据中心的能力，从而保证每个云管理平台都具有独立的对外提供云服务的能力。

在本申请实施例中，第二确认模块61从云管理平台组中确定一个云管理平台作为主平台的方式可以是：获取云管理平台组中各云管理平台的性能评分，进而通过比较各云管理平台的性能评分，确定性能评分最高的云管理平台为主平台来提供云服务，其余云管理平台作为从平台。其中，性能评分为根据各云管理平台的硬件性能和通信能力计算得到的分数。

在本实施例中，性能评分可以是各个云管理平台根据自身的硬件性能和通信能力计算得到的，此时各云管理平台得到自身的性能评分后，将该性能评分发送给云平台切换控制装置6，第二确认模块61即可进行性能评分的比较，确定出主平台和从平台。此外，本实施例中，也可以是由第二确认模块61来获取各个云管理平台的硬件性能和通信能力，进而分别根据各个云管理平台的硬件性能和通信能力分别计算出各个云管理平台的性能评分，再进行性能评分的比较，确定出主平台和从平台。

可选的，上述云管理平台的硬件性能可以包括以下至少之一：云管理平台的主频数、核数、内存大小、宿主机的cpu利用率等，而云管理平台的通信能力则包括：通信时数据到达预设ip地址的延迟。

示例性的，在计算性能评分时，可以仅采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的一种来结合云管理平台的通信能力计算得到云管理平台的性能评分；也可以采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的其中两种(如主频数+核数、主频数+内存大小、主频数+宿主机的cpu利用率、核数+内存大小、核数+宿主机的cpu利用率、宿主机的cpu利用率+内存大小)来结合云管理平台的通信能力计算得到云管理平台的性能评分；也可以采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率中的其中三种(如主频数+核数+内存大小、主频数+核数+宿主机的cpu利用率、主频数+内存大小+宿主机的cpu利用率)来结合云管理平台的通信能力计算得到云管理平台的性能评分；还可以同时采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率共同来结合云管理平台的通信能力计算得到云管理平台的性能评分。应当理解的是，在采用来进行性能评分计算的硬件性能越多时，计算出的性能评分对于云管理平台的综合性能的体现就更完善，最终确定下来的主平台就越可能是综合性最好的、可以提供最优质云服务的云管理平台。

示例性的，通信能力为通信时数据到达预设ip地址的延迟时，预设ip地址可以为用户的ip地址(如用户的企业ip地址)，这时得到的延迟即可反应出云管理平台为用户提供数据服务的通信能力强弱。延迟越大则表明该云管理平台为用户提供数据服务的通信能力越弱，在计算性能评分时，该延迟为负向考虑值。需要理解的是，预设ip可以由工程师根据实际需要设定，本实施例不作具体限定。

特别需要注意的是，在本申请实施例中，各个云管理平台的性能评分计算公式应当是一致的。以同时采用云管理平台的主频数、核数、内存大小、宿主机的cpu利用率共同来结合云管理平台的通信能力计算得到云管理平台的性能评分的情况为例，可以设定按照以下计算式来计算性能评分：(主频(ghz)*核数*a1+内存(gb)*a2+宿主机繁忙度*a3)/(√相对延迟)*a4)，其中宿主机繁忙度为(a5/当前承载云平台的宿主机cpu利用率)，相对延迟为通信时数据到达预设ip地址的延迟。前述a1-a5为权重系数，具体指可以由工程师根据实际需要设定，如可以设定a1、a2、a5为1000，a3为1，a4为10。需要说明的是，前述公式为本实施例说示例的一种可选公式，但不代表本申请实施例仅可采用这一种公式来计算性能评分，具体的计算公式可以由工程师根据实际需要而设定。

应当理解的是，本申请实施例并不限定只能依据性能评分来确定主平台和从平台。事实上，本申请实施例中也可以不依据性能评分来确定主平台和从平台，而是按照其他方式来实现主平台和从平台的确定。例如，可以由第二确认模块61随机指定一个平台作为主平台；又例如可以由第二确认模块61按照与各云管理平台的连接先后顺序，确定最先与云平台切换控制装置6建立连接的云管理平台来作为主平台。事实上，只要第二确认模块61能从云管理平台组中确定出主平台和从平台的任何方式都应在本申请的保护范围内。

在本申请实施例中，云平台切换控制装置6可以通过通知消息等形式，通知各云管理平台其为主平台还是从平台。

平台管控模块62用于将主平台的数据实时同步到至少一个从平台中，并在主平台宕机时，向从平台中的一个具有主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务。

在本申请实施例中，平台管控模块62至少可以通过以下方式来实现将主平台的数据实时同步到至少一个从平台中：

方式一：平台管控模块62可以发送控制指令来控制主平台将数据实时同步到至少一个从平台中。特别的，控制指令可以放在通知其为主平台的通知消息中，这样云平台切换控制装置6通过一次信息发送即可实现对云管理平台身份或状态(即自身为主平台还是从平台)的通知以及对数据实时同步的控制，主平台在接收到该信息时，即可建立与至少一个从平台的数据通信，进行数据的实时同步。

方式二：平台管控模块62可以不发送控制指令，而是在各个云管理平台中写入在自身作为主平台时自动与至少一个从平台建立数据通信，进行数据的实时同步的指令，从而在云管理平台在收到平台管控模块62发来的通知自身为主平台的通知消息后，即可自动实现与至少一个从平台的数据实时同步。

方式三：平台管控模块62可以作为数据中转设备，从主平台处实时获取主平台的数据并实时传输到至少一个从平台中。此时，云平台切换控制装置6在获取到主平台的数据时还可以进行数据备份，从而有效保证主平台数据的完整性。

在本申请实施例中，平台管控模块62可以对云管理平台组中各云管理平台的运行情况进行监控，从而监测到云管理平台的宕机和恢复情况，并对应的进行管控。例如，在本申请实施例中，平台管控模块62在向从平台中的一个具有主平台数据的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务之后，如果检测到宕机前次宕机的主平台从宕机中恢复了，此时则可以将该前次宕机的主平台降级为从平台，从而减少云管理平台的切换次数，保证对外提供的云服务平稳。此外，也可以在检测到前次宕机的主平台从宕机中恢复时，将当前的主平台降级为从平台，并将该宕机的主平台重新作为主平台。

需要说明的是，在本申请实施例中，平台管控模块62可以向相关云管理平台发出状态变更指令，而云管理平台接收到该指令后即根据该指令进行状态变更。例如，平台管控模块62可以向当前状态为主平台的云管理平台a发送降级为从平台的状态变更指令，云管理平台a接收到指令后，即变更自己状态为从平台，停止对外提供云服务。

在本实施例中，从平台可以进一步细分为两类，分别为待切换平台和隶从平台。其中，待切换平台为从平台中预备切换为主平台的从平台，而从平台中除待切换平台外的从平台即为隶从平台。

在本申请实施例中，可以先从平台中确定一个从平台为待切换平台，再将主平台的数据实时同步到待切换平台中。这样，在主平台宕机时，管理平台直接向待切换平台发送主平台切换指令，以将待切换平台作为新的主平台继续提供云服务。

在本申请实施例中，从所有从平台中确定出一个待切换平台的过程可以通过以下方式来实现：

方式一：可以在从云管理平台组中确定出主平台的同时，确定出待切换平台和隶从平台。例如，云平台切换控制装置6在比较各云管理平台的性能评分后，将性能评分最高的云管理平台作为主平台，而将性能评分第二高的云管理平台作为从平台中的待切换平台，其余的则作为隶从平台，这样只需要一次比较即可实现对各云管理平台状态(本实施例中云管理平台在云管理平台组中的状态包括主平台和从平台，而从平台状态则包括待切换平台和隶从平台)的确定，节约了资源。

方式二：可以在从云管理平台组中确定出主平台后，再次获取所有从平台的性能评分来进行比对，将性能评分最高的从平台确定为待切换平台。需要说明的是，从平台的性能评分也是根据各从平台的硬件性能和数据通信能力计算得到的，但是其所选取的硬件性能、数据通信能力、计算公式等可以和从云管理平台组中确定出主平台时所选用的不同(可以是部分不同，如硬件性能、计算公式相同，数据通信能力不同，也可以是三者都不同)。在本实施例的一种可行实施方式中，在从云管理平台组中确定出主平台时，数据通信能力可以为各云管理平台与用户ip的通信能力，例如各云管理平台通信时数据到达用户ip的延迟；而确定待切换平台时的通信能力可以为从平台与主平台之间的数据通信能力，例如为各从平台通信时数据到达主平台的延迟。

方式二中，获取所有从平台的性能评分的方式至少包括以下两种：其一：可以由云平台切换控制装置6来获取各从平台的硬件性能和各从平台与主平台之间的数据通信能力；进而根据各从平台的硬件性能和各从平台与主平台之间的数据通信能力计算各从平台的性能评分。其二：可以由各从平台根据自身的硬件性能和与主平台之间的数据通信能力计算得到自身的性能评分，再发送给云平台切换控制装置6汇总。

需要说明的是，由于待切换平台是在主平台宕机后会立刻切换为新的主平台以保证对外提供的云服务不会出现断档，那么为了保证后面切换的有效性，避免出现切换后服务断层的问题，待切换平台需要实时同步主平台的数据。而对于隶从平台而言，其对于主平台的数据需求的时限要求则没有待切换平台那么高，因此可以采用异步传输的方式来获取主平台的数据。此外，由于主平台时对外提供云服务的，那么为了保证其具有充足的资源来提供云服务，可以设置隶从平台从待切换平台处获取主平台数据，从而降低对于主平台的数据传输压力。

特别需要说明的是，在将待切换平台切换为主平台之后，云平台切换控制装置6可以重新在当前状态为从平台的云管理平台中确定出一个新的待切换平台来与主平台进行主平台数据的实时同步。

应到了解的是，除了上述先确定出一个待切换平台，再由待切换平台来实现与主平台的数据同步的方式以外，还可以先进行数据同步，进而在需要进行主平台切换时再进行从从平台中确定出一个待切换平台来切换为主平台。示例性的，云平台切换控制装置6可以先控制将主平台的数据实时同步到所有从平台中；进而在检测到主平台宕机时，获取各从平台的性能评分，并向性能评分最高的从平台发送主平台切换指令，以使该从平台作为新的主平台继续提供云服务。需要说明的是，此时获取的性能评分可以是之前在确定主平台时获取到的各云管理平台的性能评分，但也可以是针对从平台重新获取到的性能评分。关于如何针对从平台重新获取到性能评分在上述先确定出一个待切换平台，再由待切换平台来实现与主平台的数据同步的方式中已有相关描述，在此不再赘述。

还需要说明的是，在本申请实施例中，云平台切换控制装置6可以通过判断是否n(n大于0，具体值可以有工程师根据实际需求设定)分钟内无法与云管理平台通讯来判定各云管理平台是否宕机(n分钟内无法与某一云管理平台通讯，即可以认为该云管理平台宕机)。进一步的，为了防止误判，在监测到n分钟内无法与某一云管理平台通讯时，可以进一步判断自身是否还可以与其他其他云管理平台通讯，如果可以即表明自身设备没有问题，无法通讯的原因在于该云管理平台，可以认为该云管理平台宕机。此外，为了防止误判，在监测到n分钟内无法与某一云管理平台通讯时，还可以进一步判断其余云管理平台是否可以与预设ip(可以为用户的ip，如用户公司ip地址等)进行通讯，如果可以，则可以认为该云管理平台宕机。事实上，为了最大限度防止误判，可以同时进行以上三个条件的判断，在三者均满足时，可以认定该n分钟内无法进行通信的云管理平台宕机。

值得注意的是，在本申请实施例中上述宕机检测过程可以针对每一个云管理平台都执行，但也可以仅针对特定的云管理平台执行，如仅针对主平台和/或待切换平台执行，以降低云平台切换控制装置6的资源消耗。

在实际应用中，云管理平台的某些硬件性能和通信能力可能会有一定的变动，如宿主机的cpu利用率、通信时数据到达预设ip地址的延迟等在不同时间检测得到的数值可能会不同。因此本申请实施例中还可以由云平台切换控制装置6周期性的对各云管理平台进行性能评分的获取比对，再按照最新的性能评分的结果重新确定主平台和或待切换平台，从而保证为用户提供云服务的云管理平台的性能是最优的，保证用户可以得到最好的使用体验。

综上所述，本申请实施例提供的云平台切换控制装置，在主平台宕机时，会以某一个从平台切换为新的主平台来继续对外提供云服务。这就使得无论因为何种原因导致的主平台宕机，都可以迅速切换到一个新的主平台来继续对外提供云服务，从用户的角度而言，云服务未中断，提升了用户的使用体验，同时也避免了由于主平台宕机导致对用户造成损失的情况的出现。

实施例七：

本实施例提供了一种电子设备，参见图9所示，其包括处理器901、存储器902以及通信总线903。其中：

通信总线903用于实现处理器901和存储器902之间的连接通信。

处理器901用于执行存储器902中存储的一个或多个第一程序，以实现上述第二实施例中云平台切换控制方法的各步骤。

此时，电子设备可以为云管理平台的宿主机。

或，处理器901用于执行存储器902中存储的一个或多个第二程序，以实现上述第一实施例中云平台切换控制方法的各步骤。

此时，电子设备可以为云管理平台的宿主机，也可以为其他第三方设备，如企业服务器、终端等。

可以理解，图9所示的结构仅为示意，电子设备还可包括比图9中所示更多或者更少的组件，或者具有与图9所示不同的配置。

本实施例还提供了一种计算机可读存储介质，如软盘、光盘、硬盘、闪存、u盘、cf卡、sd卡、mmc卡等，在该计算机可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述第一实施例和/或第二实施例中云平台切换控制方法的各步骤。在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

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