一种云集群的容灾管理方法以及相关装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种云集群的容灾管理方法以及相关装置。

背景技术

边缘计算是指靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台。网络边缘侧可以是从数据源到云计算中心之间的任意功能实体，这些实体搭载着融合网络、计算、存储、应用核心能力的边缘计算平台，为终端用户提供实时、动态和智能的服务计算，为了保证边缘计算的稳定性，需要设定容灾的处理过程。

一般，容灾的处理过程通过提前规划部署的节点，静态的方式部署k8s集群master的三个副本分散在三台不同的机器上，当某一台或几台机器故障，需要手动将该宕机机器上的服务重新在新的机器设备上部署起来，并重新加入原有的部署集群。

但是，手动进行节点数据迁移和部署的过程，部署流程繁琐，且效率低下并容易出现错误，影响网络集群中容灾进程的准确性。

发明内容

有鉴于此，本申请提供一种云集群的容灾管理方法，可以有效提高容灾进程的准确性。

本申请第一方面提供一种云集群的容灾管理方法，可以应用于计算机设备中包含云集群的容灾管理功能的系统或程序中，具体包括：

获取用于部署云集群中的元集群的N个机器设备群所对应的群标识，不同的所述机器设备群之间独立运行，N为大于1的正整数；

基于所述群标识将所述元集群对应的中控服务分散部署到M个不同的所述机器设备群中，并将托管集群中对应的托管服务分散部署到R个不同的所述机器设备群中，以得到容灾设备网络，所述托管集群基于所述元集群关联的节点单元设定，所述中控服务用于管理所述托管服务的业务执行，M＜N，R＜N，M、R为正整数；

若容灾进程被触发，则将所述容灾进程对应的故障服务调整至所述容灾设备网络中的未被部署的机器设备群中运行，所述容灾进程基于所述元集群和所述托管集群中至少一种所对应的运行过程设定，所述故障服务包括所述中控服务和所述托管服务中的至少一种。

可选的，在本申请一些可能的实现方式中，所述基于所述群标识将所述元集群对应的中控服务分散部署到M个不同的所述机器设备群中，并将托管集群中对应的托管服务分散部署到R个不同的所述机器设备群中，以得到容灾设备网络，包括：

基于所述群标识将所述元集群对应的中控服务分散部署到M个不同的所述机器设备群中，并对所述元集群关联的节点单元设定区域标签；

基于所述区域标签确定所述托管集群；

将所述托管集群中对应的所述托管服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述基于所述群标识将所述元集群对应的中控服务分散部署到M个不同的所述机器设备群中，包括：

确定所述中控服务对应的中控副本信息；

基于所述中控副本信息对应的副本数量将所述元集群对应的所述中控服务分散部署到M个不同的所述机器设备群中；

所述基于所述区域标签确定所述托管集群，并将所述托管集群中对应的所述托管服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络，包括：

确定所述托管服务对应的数据副本信息；

基于所述数据副本信息将所述托管集群中对应的所述托管服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述基于所述数据副本信息将所述托管集群中对应的所述托管服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络，包括：

确定所述托管服务对应的数据服务和控制服务，所述控制服务为所述中控服务的组件；

基于所述数据副本信息将所述托管集群中对应的所述数据服务分散部署到R个不同的所述机器设备群中；

基于所述数据副本信息将所述托管集群中对应的所述控制服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述基于所述数据副本信息将所述托管集群中对应的所述数据服务分散部署到R个不同的所述机器设备群中，包括：

调用所述数据服务对应的服务检测接口；

基于所述服务检测接口对所述数据服务进行健康检测，以得到服务检测结果；

若所述服务检测结果指示所述数据服务正常，则基于所述数据副本信息将所述托管集群中对应的所述数据服务分散部署到R个不同的所述机器设备群中。

可选的，在本申请一些可能的实现方式中，所述基于所述数据副本信息将所述托管集群中对应的所述控制服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络，包括：

将所述控制服务封装至服务容器中；

基于所述服务容器将所述控制服务配置在节点单元中，以基于所述数据副本信息将所述托管集群中对应的所述控制服务分散部署到R个不同的所述机器设备群中得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述获取用于部署云集群中的元集群的N个机器设备群所对应的群标识，包括：

获取搭载于所述云集群的目标业务；

确定所述目标业务需求的网络参数；

基于所述网络参数为所述元集群部署N个所述机器设备群所对应的所述群标识。

可选的，在本申请一些可能的实现方式中，所述基于所述网络参数为所述元集群的部署N个所述机器设备群所对应的所述群标识，包括：

确定所述目标业务对应的热点区域；

确定所述热点区域内的候选设备群；

基于所述网络参数为所述元集群从所述候选设备群中确定N个所述机器设备群对应的所述群标识以进行部署。

可选的，在本申请一些可能的实现方式中，所述若容灾进程被触发，则将所述容灾进程对应的故障服务调整至所述容灾设备网络中的未被部署的机器设备群中运行，包括：

若所述容灾进程被触发，则确定所述容灾进程对应的故障信息；

基于所述故障信息在所述容灾设备网络中的未被部署的机器设备群中进行检测，以得到容灾设备群；

将所述容灾进程对应的故障服务调整至所述容灾设备群中运行，并将所述容灾设备群与所述故障信息对应的容灾设备网络进行关联。

可选的，在本申请一些可能的实现方式中，其特征在于，所述方法还包括：

确定所述托管集群对应的访问地址；

调用集群健康检查接口，以基于所述访问地址进行健康检查得到集群健康检查结果；

根据所述集群健康检查结果对所述托管集群在所述云集群中进行注册。

可选的，在本申请一些可能的实现方式中，N＞3，M=3，R=3，所述元集群和所述托管集群通过kubernetes进行管理，所述容灾进程在基于所述云集群管理对边缘设备进行管理以执行目标业务时发生。

可选的，在本申请一些可能的实现方式中，所述云集群的容灾管理方法应用于区块链设备，所述区块链设备为区块链中的节点。

本申请第二方面提供一种云集群的容灾管理装置，包括：

获取单元，用于获取用于部署云集群中的元集群的N个机器设备群所对应的群标识，不同的所述机器设备群之间独立运行，N为大于1的正整数；

部署单元，用于基于所述群标识将所述元集群对应的中控服务分散部署到M个不同的所述机器设备群中，并将所述托管集群中对应的托管服务分散部署到R个不同的所述机器设备群中，以得到容灾设备网络，所述托管集群基于所述元集群关联的节点单元设定，所述中控服务用于管理所述托管服务的业务执行，M＜N，R＜N，M、R为正整数；

管理单元，用于若容灾进程被触发，则将所述容灾进程对应的故障服务调整至所述容灾设备网络中的未被部署的机器设备群中运行，所述容灾进程基于所述元集群和所述托管集群中至少一种所对应的运行过程设定，所述故障服务包括所述中控服务和所述托管服务中的至少一种。

可选的，在本申请一些可能的实现方式中，所述部署单元，具体用于基于所述群标识将所述元集群对应的中控服务分散部署到M个不同的所述机器设备群中，并对所述元集群关联的节点单元设定区域标签；

所述部署单元，具体用于基于所述区域标签确定所述托管集群；

所述部署单元，具体用于将所述托管集群中对应的所述托管服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述部署单元，具体用于确定所述中控服务对应的中控副本信息；

所述部署单元，具体用于基于所述中控副本信息对应的副本数量将所述元集群对应的所述中控服务分散部署到M个不同的所述机器设备群中；

所述部署单元，具体用于确定所述托管服务对应的数据副本信息；

所述部署单元，具体用于基于所述数据副本信息将所述托管集群中对应的所述托管服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述部署单元，具体用于确定所述托管服务对应的数据服务和控制服务，所述控制服务为所述中控服务的组件；

所述部署单元，具体用于基于所述数据副本信息将所述托管集群中对应的所述数据服务分散部署到R个不同的所述机器设备群中；

所述部署单元，具体用于基于所述数据副本信息将所述托管集群中对应的所述控制服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述部署单元，具体用于调用所述数据服务对应的服务检测接口；

所述部署单元，具体用于基于所述服务检测接口对所述数据服务进行健康检测，以得到服务检测结果；

所述部署单元，具体用于若所述服务检测结果指示所述数据服务正常，则基于所述数据副本信息将所述托管集群中对应的所述数据服务分散部署到R个不同的所述机器设备群中。

可选的，在本申请一些可能的实现方式中，所述部署单元，具体用于将所述控制服务封装至服务容器中；

所述部署单元，具体用于基于所述服务容器将所述控制服务配置在节点单元中，以基于所述数据副本信息将所述托管集群中对应的所述控制服务分散部署到R个不同的所述机器设备群中得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述获取单元，具体用于获取搭载于所述云集群的目标业务；

所述获取单元，具体用于确定所述目标业务需求的网络参数；

所述获取单元，具体用于基于所述网络参数为所述元集群部署N个所述机器设备群所对应的所述群标识。

可选的，在本申请一些可能的实现方式中，所述获取单元，具体用于确定所述目标业务对应的热点区域；

所述获取单元，具体用于确定所述热点区域内的候选设备群；

所述获取单元，具体用于基于所述网络参数为所述元集群从所述候选设备群中确定N个所述机器设备群对应的所述群标识以进行部署。

可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于若所述容灾进程被触发，则确定所述容灾进程对应的故障信息；

所述管理单元，具体用于基于所述故障信息在所述容灾设备网络中的未被部署的机器设备群中进行检测，以得到容灾设备群；

所述管理单元，具体用于将所述容灾进程对应的故障服务调整至所述容灾设备群中运行，并将所述容灾设备群与所述故障信息对应的容灾设备网络进行关联。

可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于确定所述托管集群对应的访问地址；

所述管理单元，具体用于调用集群健康检查接口，以基于所述访问地址进行健康检查得到集群健康检查结果；

所述管理单元，具体用于根据所述集群健康检查结果对所述托管集群在所述云集群中进行注册。

本申请第三方面提供一种计算机设备，包括：存储器、处理器以及总线系统；所述存储器用于存储程序代码；所述处理器用于根据所述程序代码中的指令执行上述第一方面或第一方面任一项所述的云集群的容灾管理方法。

本申请第四方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面任一项所述的云集群的容灾管理方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述第一方面或者第一方面的各种可选实现方式中提供的云集群的容灾管理方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

通过获取部署于所述云集群的元集群中N个机器设备群所对应的群标识，其中不同的机器设备群之间独立运行，N为大于1的正整数；然后基于群标识将元集群对应的中控服务分散部署到M个不同的机器设备群中，并将托管集群中对应的托管服务分散部署到R个不同的机器设备群中，以得到容灾设备网络，托管集群基于元集群关联的节点单元设定，中控服务用于管理托管服务的业务执行，M＜N，R＜N，M、R为正整数；若容灾进程被触发，则将容灾进程对应的故障服务调整至容灾设备网络中的未被部署的机器设备群中运行，该容灾进程基于元集群和托管集群中至少一种所对应的运行过程设定，该故障服务包括中控服务和托管服务中的至少一种。从而实现元集群与托管集群的层级框架中的自动容灾处理过程，由于机器设备群之间不会相互影响，保证了容灾切换之后设备的可用性，且整体过程无需人工干预，保证了容灾管理过程中的准确性。

附图说明

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

图1为本申请实施例提供的一种云集群的容灾管理系统运行的系统架构图；

图2为本申请实施例提供的一种云集群的容灾管理方法的流程图；

图3为本申请实施例提供的另一种云集群的容灾管理方法的流程图；

图4为本申请实施例提供的另一种云集群的容灾管理方法的流程图；

图5为本申请实施例提供的另一种云集群的容灾管理方法的流程图；

图6为本申请实施例提供的另一种云集群的容灾管理系统运行的系统架构图；

图7为本申请实施例提供的另一种云集群的容灾管理方法的流程图；

图8为本申请实施例提供的一种云集群的容灾管理装置的结构示意图；

图9为本申请实施例提供的一种服务器的结构示意图；

图10A为本申请实施例提供的一种数据共享系统；

图10B为本申请实施例提供的一种区块链的组成；

图10C为本申请实施例提供的一种区块链节点的输入信息示意图。

具体实施方式

本申请实施例提供了一种云集群的容灾管理方法以及相关装置，可以应用于终端设备中包含云集群的容灾管理功能的系统或程序中，通过获取部署于所述云集群的元集群中N个机器设备群所对应的群标识，其中不同的机器设备群之间独立运行，N为大于1的正整数；然后基于群标识将元集群对应的中控服务分散部署到M个不同的机器设备群中，并将托管集群中对应的托管服务分散部署到R个不同的机器设备群中，以得到容灾设备网络，托管集群基于元集群关联的节点单元设定，中控服务用于管理托管服务的业务执行，M＜N，R＜N，M、R为正整数；若容灾进程被触发，则将容灾进程对应的故障服务调整至容灾设备网络中的未被部署的机器设备群中运行，该容灾进程基于元集群和托管集群中至少一种所对应的运行过程设定，该故障服务包括中控服务和托管服务中的至少一种。从而实现元集群与托管集群的层级框架中的自动容灾处理过程，由于机器设备群之间不会相互影响，保证了容灾切换之后设备的可用性，且整体过程无需人工干预，保证了容灾管理过程中的准确性。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，对本申请实施例中可能出现的一些名词进行解释。

云集群：也称为云端平台、云端等，用于通过集群应用、网格技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个集群系统。

kubernetes ：也称为k8s，是一个分布式的集群管理系统，在每个节点（node）上都要运行一个执行程序（worker）对容器进行生命周期的管理。

Pod：kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个微服务进程，且一个微服务进程封装一个提供微服务应用的边缘容器（也可以有多个边缘容器）、存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。

Docker: 一种容器运行时技术，提供资源限制与隔离的虚拟化功能。

可用区机房：不同的机房。单个可用区机房断电或故障不影响其他可用区机房的设备。

节点单元：也称为Node节点，可以是一台物理机设备，该设备上运行通过k8s集群部署的服务。

k8s master服务：k8s master服务包括kube-apiserver、kube-controller-manager、kube-scheduler三个服务，一个k8s集群中，每个服务一般运行三个副本。

etcd集群：etcd集群是一种key-value数据存储服务，k8s集群用etcd来做数据存储，一般一个etcd集群运行三个etcd副本服务。

元集群：一个完整独立的k8s集群，包括k8s master节点和k8s node节点。k8s的node节点可以横向快速扩展添加。其中node节点上运行托管k8s集群的master组件。

托管集群：托管的k8s集群用来注册和管理边缘设备节点，托管的k8s集群主要部署master部分的组件，其中包括kube-apiserver、kube-controller-manager、kube-scheduler、etcd等组件。托管集群的master以pod的方式运行在元集群的node节点上。

kube-apiserver：用于提供资源操作的入口，并提供认证、授权、访问控制、API注册和发现等机制。

kube-controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。

kube-scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。

负载均衡（CLB）:提供安全快捷的流量分发服务，访问流量经由负载均衡可以自动分配到云中的多台云服务器上，扩展系统的服务能力并消除单点故障。

边缘计算是指靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台。网络边缘侧可以是从数据源到云计算中心之间的任意功能实体，这些实体搭载着融合网络、计算、存储、应用核心能力的边缘计算平台，为终端用户提供实时、动态和智能的服务计算，为了保证边缘计算的稳定性，需要设定容灾的处理过程。

一般，容灾的处理过程通过提前规划部署的节点，静态的方式部署k8s集群master的三个副本分散在三台不同的机器上，当某一台或几台机器故障，需要手动将该宕机机器上的服务重新在新的机器设备上部署起来，并重新加入原有的部署集群。

但是，手动进行节点数据迁移和部署的过程，部署流程繁琐，且效率低下并容易出现错误，影响网络集群中容灾进程的准确性。

为了解决上述问题，本申请提出了一种云集群的容灾管理方法，该方法应用于图1所示的云集群的容灾管理的系统框架中，如图1所示，为本申请实施例提供的一种云集群的容灾管理的系统架构图，具体的，该系统架构分为云端的控制面组件（中控设备master）对集群的划分管理过程和边缘端的边缘设备的接入部署过程。本申请主要使用了容器技术docker，结合k8s on k8s的层级结构部署方式，将实际运行业务的k8s集群通过一个k8s元集群部署和托管起来，并且元集群的服务及托管集群的服务都分散在三个及以上的可互相通信的可用区机房机器设备上。从而实现k8s集群的自动容灾及跨可用区机房容灾。

可以理解的是，本申请可以应用于各种需要部署和使用k8s集群的产品和场景中，例如各种基于k8s技术建设的容器云平台（云集群），边缘容器平台等。

具体的，元集群一个完整独立的k8s集群，包括k8s master节点和k8s node节点。k8s的node节点可以横向快速扩展添加。其中node节点上运行托管k8s集群的master组件，其中，node节点可以是一台物理主机，也可以是一台虚拟机。

托管集群则是托管的k8s集群用来注册和管理边缘设备的节点，托管的k8s集群主要部署master部分的组件，其中包括kube-apiserver、kube-controller-manager、kube-scheduler、etcd等组件。托管集群的master以容器（pod）的方式运行在元集群的node节点上，通过Pod间反亲和的特性（即同一个托管集群的相同副本不会运行在同一个可用区机房中，来保证同一个托管集群的相同服务强制分散到不同可用区机房），强制将同一个托管集群下的master服务分散运行在k8s元集群不同可用区机房的Node节点上，实现自动部署的过程。

通过云端的中控设备下达指令，使得通过k8s元集群来创建和管理托管k8s业务集群（即 kube on kube的方式），从而可以快速增加托管k8s业务集群的数量来增加云端控制节点，并将边缘设备注册到托管的业务集群控制节点中，实现云端对云集群的容灾管理。

可以理解的是，一个托管集群控制节点可以管理一定规模的边缘设备，当增加托管集群控制节点时，可以快速管理更大规模的边缘设备。

本实施例中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，终端以及服务器可以连接组成区块链网络，本申请在此不做限制。

可以理解的是，本申请所提供的方法可以为一种程序的写入，以作为硬件系统中的一种处理逻辑，也可以作为一种云集群的容灾管理装置，采用集成或外接的方式实现上述处理逻辑。作为一种实现方式，该云集群的容灾管理装置通过获取部署于所述云集群的元集群中N个机器设备群所对应的群标识，其中不同的机器设备群之间独立运行，N为大于1的正整数；然后基于群标识将元集群对应的中控服务分散部署到M个不同的机器设备群中，并将托管集群中对应的托管服务分散部署到R个不同的机器设备群中，以得到容灾设备网络，托管集群基于元集群关联的节点单元设定，中控服务用于管理托管服务的业务执行，M＜N，R＜N，M、R为正整数；若容灾进程被触发，则将容灾进程对应的故障服务调整至容灾设备网络中的未被部署的机器设备群中运行，该容灾进程基于元集群和托管集群中至少一种所对应的运行过程设定，该故障服务包括中控服务和托管服务中的至少一种。从而实现元集群与托管集群的层级框架中的自动容灾处理过程，由于机器设备群之间不会相互影响，保证了容灾切换之后设备的可用性，且整体过程无需人工干预，保证了容灾管理过程中的准确性。

本申请实施例提供的方案涉及云技术，具体通过如下实施例进行说明：

结合上述流程架构，下面将对本申请中云集群的容灾管理方法进行介绍，请参阅图2，图2为本申请实施例提供的一种云集群的容灾管理方法的流程图，该管理方法可以是由计算机设备执行的，该计算机可以是终端设备，也可以是服务器，还可以是任何可以在云端作为容器的设备，本申请实施例至少包括以下步骤：

201、获取部署于云集群的元集群中N个机器设备群所对应的群标识。

本实施例中，对机器设备群进行管理的过程是基于机器设备群对应的群标识进行的，该群标识可以是数字、文字、置信标记等具有指向性的字符，通过对于群标识的管理即可以对相应的机器设备群进行逻辑划分。具体的，不同的机器设备群之间独立运行，即不同的机器设备群之间不会相互影响，即保证了容灾切换后的可行性，故N至少为2。

另外，对于机器设备群的部署，是为了为元集群在容灾处理过程中提供不同的可用区机房，具体的，在业务处理场景中，还可以参考业务需求进行部署，即首先获取搭载于云集群的目标业务；然后确定目标业务需求的网络参数，例如网络延时、处理能力等；进而基于网络参数为元集群部署机器设备群，从而提高了机器设备群与业务的适配性。

进一步的，在目标业务中，还可能存在热点区域，例如主要用户所处的区域，为了减少业务之间的距离，可以确定目标业务对应的热点区域；然后确定热点区域内的候选设备群；进而基于网络参数为元集群从候选设备群中确定机器设备群以进行部署，从而保障了机器设备群中设备的可行性。

202、基于群标识将元集群对应的中控服务分散部署到M个不同的机器设备群中，并将托管集群对应的托管服务分散部署到R个不同的机器设备群中，以得到容灾设备网络。

本实施例中，托管集群基于元集群关联的节点单元设定，具体的，托管集群用来注册和管理边缘设备节点，托管集群主要部署master得部分组件，其中包括kube-apiserver、kube-controller-manager、kube-scheduler、etcd等组件。而托管集群的master以pod的方式运行在元集群的node节点上。另外，中控服务用于管理托管服务的业务执行，即元集群为托管集群的上层集群，可以通过中控服务对托管集群的具体业务进行管理；对于分散部署的过程，即将不同的服务副本进行分布式部署的过程，保证数据的可信度。

可以理解的是，对于M、N、R的数值关系，存在M＜N，R＜N，M、N、R为正整数；即在机器设备群中部署了元集群和对应的托管集群后，依然存在备份的设备群，用于容灾处理过程中进行切换，例如在k8s场景中，k8s master服务包括kube-apiserver、kube-controller-manager、kube-scheduler三个服务，一个k8s集群中的每个master服务（中控服务）一般运行三个副本，故需要将三个副本分散部署到3个不同的机器设备群中，对于元集群关联的节点单元进行相应的部署，并设置对应的托管集群，对于托管集群，其托管服务中包含了etcd服务（数据服务）是一种key-value数据存储服务，k8s集群用etcd来做数据存储，一个etcd集群运行三个etcd副本服务，即将托管集群中对应的托管服务分散部署到3个不同的机器设备群中，对于按照机器设备群进行元集群与托管集群部署后的网络结构，即为容灾设备网络。

具体的，对于托管集群的部署过程可以是首先将元集群对应的中控服务分散部署到M个不同的机器设备群中，并对元集群关联的节点单元设定区域标签；然后基于区域标签确定托管集群；进而将托管集群中对应的托管服务分散部署到R个不同的机器设备群中，以得到容灾设备网络，从而保证了元集群与托管集群的对应性。

可选的，由于分散部署的过程是为了将不同的服务副本进行分布式部署，故可以首先确定中控服务对应的中控副本信息；然后基于中控副本信息对应的副本数量将元集群对应的中控服务分散部署到M个不同的机器设备群中；并确定托管服务对应的数据副本信息；进而基于数据副本信息将托管集群中对应的托管服务分散部署到R个不同的机器设备群中，以得到容灾设备网络。

可以理解的是，对于实际场景中，中控服务、托管服务对应的副本数量可以为3，即采用三副本机制进行数据存储，这是为了保证数据的一致性，即存储系统中的3个数据副本必须一致。当业务无论通过哪个副本再次读取这些数据时，该副本上的数据和之前写入的数据都是一致的。例如对于节点A的物理磁盘A上的数据块P1，系统将它的数据备份为节点B的物理磁盘B上的P1''和节点C的物理磁盘C上的P1'，P1、P1'和P1''共同构成了同一个数据块的三个副本。若P1所在的物理磁盘发生故障，则P1'和P1''可以继续提供存储服务，并通过比对保证数据的一致性，确保业务不受影响，进而进行本申请中的容灾处理过程。具体的数量因实际场景而定，此处不做限定。

另外，对于托管集群的部署包含了数据服务（etcd服务）和控制服务（master组件）的部署过程，控制服务为中控服务的组件；然后基于数据副本信息将托管集群中对应的数据服务分散部署到R个不同的机器设备群中；进而基于数据副本信息将托管集群中对应的控制服务分散部署到R个不同的机器设备群中，以得到容灾设备网络。

对于数据服务部署后，可以调用数据服务对应的服务检测接口；然后基于服务检测接口对数据服务进行健康检测，以得到服务检测结果；若服务检测结果指示数据服务正常，则基于数据副本信息将托管集群中对应的数据服务分散部署到R个不同的机器设备群中。

对于控制服务的部署过程，即将控制服务封装至服务容器中；然后基于服务容器将控制服务配置在节点单元中，以基于数据副本信息将托管集群中对应的控制服务分散部署到R个不同的机器设备群中得到容灾设备网络。从而通过Pod间反亲和的特性（即同一个托管集群的相同副本不会运行在同一个可用区机房中，来保证同一个托管集群的相同服务强制分散到不同可用区机房），强制将同一个托管集群下的master服务分散运行在k8s元集群不同可用区机房的Node节点上，故任一一个可用区机房故障都不会导致该托管集群的master服务不可用，从而实现自动部署容灾设备的过程。

可选的，在托管集群部署完成后，可以确定托管集群对应的访问地址；然后调用集群健康检查接口，以基于访问地址进行健康检查得到集群健康检查结果；进而根据集群健康检查结果对托管集群在云集群中进行注册，以保证托管集群的可用性。

203、若容灾进程被触发，则将容灾进程对应的故障服务调整至容灾设备网络中未被部署的机器设备群中运行。

本实施例中，容灾进程基于元集群和托管集群中至少一种所对应的运行过程设定，该故障服务包括中控服务和托管服务中的至少一种，即当托管集群或元集群所运行的单个可用区机房、单台机器、单个master服务中的一处或多处发生故障的情况下，元集群的k8s会通过自愈逻辑自动在另一个不同的可用区机房的设备（容灾设备网络中未被部署的机器设备群）上将该故障的服务运行起来，从而达到自动容灾的效果。

具体的，对于未被部署的机器设备群的确定，可以是识别群标识中未被标记为使用的机器设备群，或识别群标识中标记为备用设备的机器设备群，具体方式因实际场景而定。

故在容灾处理过程中，若容灾进程被触发，则确定容灾进程对应的故障信息；然后基于故障信息在容灾设备网络中的未被部署的机器设备群中进行检测，以得到容灾设备群，即单个可用区机房、单台机器或单个master服务发生了故障；进而将容灾进程对应的故障服务调整至容灾设备群中运行，并将容灾设备群与故障信息对应的容灾设备网络进行关联，从而实现自动容灾处理的过程。

可以理解的是，创建托管k8s集群的技术实现会存在不同的技术代码实现，但都属于本发明专利中表明的以托管的方式来快速创建和管理集群。另外，创建托管etcd集群会存在不同的技术方案实现，但都属于本发明专利中表明的以服务化的形式来创建etcd托管集群。进一步的，通过元集群来部署和维护托管集群的形式，从而通过k8s元集群的自愈功能实现托管集群的高可用及自动容灾。其他类似的过程和方法仍属于本专利中表述的方法核心。

结合上述实施例可知，通过获取部署于所述云集群的元集群中N个机器设备群所对应的群标识，其中不同的机器设备群之间独立运行，N为大于1的正整数；然后基于群标识将元集群对应的中控服务分散部署到M个不同的机器设备群中，并将托管集群中对应的托管服务分散部署到R个不同的机器设备群中，以得到容灾设备网络，托管集群基于元集群关联的节点单元设定，中控服务用于管理托管服务的业务执行，M＜N，R＜N，M、R为正整数；若容灾进程被触发，则将容灾进程对应的故障服务调整至容灾设备网络中的未被部署的机器设备群中运行，该容灾进程基于元集群和托管集群中至少一种所对应的运行过程设定，该故障服务包括中控服务和托管服务中的至少一种。从而实现元集群与托管集群的层级框架中的自动容灾处理过程，由于机器设备群之间不会相互影响，保证了容灾切换之后设备的可用性，且整体过程无需人工干预，保证了容灾管理过程中的准确性。

下面，以k8s场景中，master服务（中控服务）以及etcd服务（托管服务中的）的副本采用三副本机制的场景进行说明，如图3所示，图3为本申请实施例提供的另一种云集群的容灾管理方法的流程图；具体包括：

301、准备三个以上可用区机房的机器设备群。

本实施例中，即准备三个以上不同可用区机房的机器设备群，不同可用区机房设备之间可直接通信。

302、将元集群分散部署在三个可用区机房。

本实施例中，即基于元集群维度的备份部署过程，从而直到关联的节点单元的部署。

303、为元集群对应的节点单元标记区域标签。

本实施例中，即为部署k8s元集群的过程。具体将k8s元集群的master分散部署在三个不同的可用区机房，同时将元集群的Node节点分散在三个以上不同的可用区机房，并给元集群的Node打区域等标签。

304、创建托管集群的数据服务，并将副本分散部署在三个可用区机房。

本实施例中，部署托管k8s的etcd服务，将etcd集群的三个副本分散到不同的可用区机房设备上，并调用etcd查询集群健康的接口，检查服务是否正常。从而任一可用区机房故障都不会导致整个etcd集群服务不可用。

305、在元集群的节点单元上创建托管集群的控制服务，并将副本分散部署在三个可用区机房。

本实施例中，通过调用部署托管集群的接口，部署k8s托管集群master服务，master的服务通过pod的方式运行在元集群的Node节点上。

可以理解的是，通过Pod间反亲和的特性（即同一个托管集群的相同副本不会运行在同一个可用区机房中，来保证同一个托管集群的相同服务强制分散到不同可用区机房），强制将同一个托管集群下的master服务分散运行在k8s元集群不同可用区机房的Node节点上。故任一一个可用区机房故障都不会导致该托管集群的master服务不可用。

306、配置托管集群的接口访问地址。

本实施例中，即配置托管k8s api的访问地址。

307、检查托管集群是否可用。

本实施例中，通过调用集群健康检查接口，检查托管集群是否健康可用。

308、返回服务部署失败并报错。

309、创建托管集群完成。

本实施例中，若创建托管集群完成，则将运行节点注册到k8s托管集群中，即可在运行节点上部署服务。

上述实施例通过k8s on k8s的方式来管理k8s集群，同时将元集群的分散部署在三个以上不同可用区机房的机器设备上，来保证元集群的可用区机房容灾，任一一个可用区机房故障都不会导致元集群服务故障。另外将托管集群的master服务也以pod的方式分散运行在三个以上可用区机房的机器设备上，通过可用区机房标签来实现pod间的强制反亲和（即同一个托管集群的相同副本不会运行在同一个可用区机房中，来保证同一个托管集群的相同服务强制分散到不同可用区机房）。

当托管集群的所运行的单个可用区机房、单台机器、单个master服务故障的情况下，元集群的k8s会通过自愈逻辑自动在另一个不c同的可用区机房的设备上将该故障的服务运行起来，从而达到自动容灾的效果。

可以理解的是，在原有技术下，k8s集群的master副本故障，需要人工干预恢复，且恢复时间按小时或天计算，且可能存在单个可用区机房故障导致整个集群不可用的情况。本发明专利下k8s集群的master副本故障，无需人工干预，即可自动恢复。单个可用区机房故障，也不影响k8s集群服务，且可自动恢复，自动恢复时间按秒级计算，大大提升了容灾处理过程的效率。

在完成托管集群的创建后，可以进行注册并检查边缘节点的过程，或，在容灾处理确定备份机器群后，可以对其中对应的业务进行注册并关联边缘节点。对于注册并检查边缘节点的过程，如图4所示，图4为本申请实施例提供的另一种云集群的容灾管理方法的流程图，包括如下步骤：

401、注册一个或多个边缘设备。

本实施例中，为了保证边缘设备的可信度，对于接入托管集群的边缘设备需要在云集群进行注册。

402、填写边缘设备注册参数。

本实施例中，边缘设备的注册参数包括边缘设备的标识信息（设备号、认证号等）、位置信息（IP地址、归属地等）以及功能信息（负载能力、可用状态等）。

403、检查节点是否满足注册条件。

本实施例中，注册条件的判断可以是根据注册参数进行的，即对于标识信息、位置信息或功能信息中的一种或多种进行核验，例如检查认证号的可信度；归属地的更换频率；是否为最佳负载状态等。

404、返回注册失败及报错。

本实施例中，若边缘设备的注册信息不满足步骤403中的注册条件，则会向云集群反馈注册失败，以及具体的失败原因，即报错的过程。

可以理解的是，在报错之后可以进行相应边缘设备的记录，在该设备再次进行注册时进行提醒，以针对报错指示的维度进行进一步的检查。

405、自动选择托管集群。

本实施例中，若满足注册条件则自动选择托管集群，具体的，自动选择的过程可以是基于位置信息进行的，例如自动选择与边缘设备属于同一区域的托管集群；自动选择的过程可以是基于业务进行的，例如自动选择与边缘设备属于业务A的托管集群，从而节省了后续的边缘设备分组的过程。

406、判断托管集群的节点数目是否到达上限。

本实施例中，考虑到托管集群的容量以及管理边缘设备的效率，可以对托管集群中管理的节点数目（边缘设备）进行上限设备，具体的，该上限可以是负载上限，即最多接入的节点数目；上限也可以是由不同托管集群实时的资源负载情况所设定的数值，例如忙时阈值为负载上限的80%，闲时阈值为负载上限的60%，具体的数值设定因实际场景而定，从而保证了托管集群对边缘设备进行管理的稳定性。

407、创建托管集群。

本实施例中，若达到上限则创建托管集群，具体的，该创建的托管集群可以是重复图3所示实施例的步骤，也可以是选用图3所示实施例的步骤中未接入边缘设备的托管集群或未达到上限的托管集群。

可以理解的是，对于新的托管集群的创建，在创建过程中即与该注册的边缘设备进行关联，即在托管集群创建完毕后立即与边缘设备进行关联，从而提高边缘设备的接入效率。

408、检查节点是否注册成功。

本实施例中，将边缘设备对应的节点与托管集群相关联后，需要进行再次的节点核验，即保证边缘设备与托管集群之间联系的可信度。具体的可以通过标识信息发送的过程进行检查，即托管集群向关联的边缘设备发送检查指令，边缘设备会对该检查指令进行响应，根据响应的情况确定检查节点是否注册成功。

409、返回节点注册失败及报错。

本实施例中，根据步骤408中的检查指令响应，若托管集群未接收到边缘设备的响应，则说明该边缘设备注册失败，并生成该边缘设备的相关信息，以便于查验。

410、边缘节点注册成功。

本实施例中，根据步骤408中的检查指令响应，若托管集群接收到边缘设备的响应，则说明该边缘设备注册成功，边缘设备已部署为托管集群中的边缘节点。

进一步的，对于部署并检查边缘服务的过程，参见图5，图5为本申请实施例提供的另一种云集群的容灾管理方法的流程图，包括如下步骤：

501、上传边缘服务镜像到镜像仓库。

本实施例中，边缘服务的过程为通过云集群进行服务下发的过程，为保证服务的一致性，可以首先上传边缘服务镜像到镜像仓库。具体的，在镜像仓库中可以包含多个命名空间，即对于不同的边缘服务配置在不同的命名空间中，以实现多服务的并行。

502、部署边缘镜像服务。

本实施例中，部署边缘镜像服务的过程即调用边缘服务部署接口，通过服务镜像部署边缘服务。

503、填写边缘服务的部署参数。

本实施例中，部署参数可以包括需求的资源参数以及地域参数，具体的，资源参数为用于指示边缘服务运行过程所需要的硬件或软件资源的相关参数，例如：占用资源量、需求设备数等；而地域参数则用于指示边缘服务针对的对象，进而选择距离这些对象较近的边缘设备。

504、选择满足部署参数条件的边缘设备。

本实施例中，部署参数条件的满足即资源参数或地域参数维度的条件满足，例如选择运存达到1G的边缘设备，或选择范围A内的边缘设备。

505、云集群自动部署边缘服务到对应边缘设备。

本实施例中，通过托管集群对于边缘设备的选择并确定对应的接口，使得边缘服务可以快速的部署到对应边缘设备。

506、检查边缘服务是否部署成功。

本实施例中，检查边缘服务的部署情况可以通过调用边缘服务健康检查接口，以检查边缘服务是否部署成功。

507、返回服务部署失败及报错。

本实施例中，若健康检查指示异常，则返回服务部署失败，并对相应的边缘服务进行记录，以便于查验。

508、返回部署成功。

本实施例中，若健康检查正常，则所述边缘服务部署成功。

在进行上述云集群与边缘节点的配置过程后，可以得到如图6所示的系统架构图，图6为本申请实施例提供的另一种云集群的容灾管理方法的系统架构图。主要分为云集群（cloud）中控设备（meta k8s master）和边缘端（edge）的边缘设备（node）。其中，元集群被部署在了三个不同的可用区机房（区域）中，各个元集群对应的托管集群亦进行了对应的分布式部署，由于可用区机房的数量大于3，从而可以在容灾进程触发时进行自动的切换，以保证业务的正常进行，具体的设备数量因实际场景而定，此处仅为示例。

下面对容灾处理的过程进行说明。请参阅图7，图7为本申请实施例提供的另一种云集群的容灾管理方法的流程图，本申请实施例至少包括以下步骤：

701、确定容灾进程对应的故障设备。

本实施例中，故障设备可以是可用区机房、单台机器或单个master服务等在容灾设备网络中出现的设备。

702、将故障设备对应的服务数据迁移至容灾设备网络中未被部署的目标机器群。

本实施例中，将故障设备对应的服务数据迁移至容灾设备网络中未被部署的目标机器群的过程即元集群的k8s进行自愈的过程，从而保证业务的正常进行。

703、将目标机器群与故障设备对应的副本机器进行关联，并进行数据一致性核验。

本实施例中，在迁移部署数据之后还可以和故障设备对应的副本机器进行关联，例如故障设备为数据服务的第二副本所在的设备（数据服务包含三个副本，即第一副本、第二副本和第三副本），故将第二副本的内容迁移至目标机器群后，还可以将目标机器群与第一副本和第三副本对应的机器群进行关联。

在机器群关联后，由于业务数据是动态变化的，故可以将目标机器群与第一副本和第三副本中的数据进行一致性核验。

704、若核验通过，则基于目标机器群执行业务。

本实施例中，通过三副本机制的一致性核验，保证了容灾切换后数据的一致性，提高了业务执行的准确性。

上述实施例通过k8s集群上部署k8s集群的方式，并且将元集群和托管集群服务都强制分散在三个及以上可用区机房的设备上。利用k8s本身的容灾自愈功能来使其管理的k8s集群的自动容灾，当单个可用区机房、机器设备或master副本故障的情况下，可以将该故障机器上运行的服务自动调度新的满足部署条件的机器上运行，同时自动加入到原来部署的k8s集群中，无需人工干预和迁移，即可实现自动跨可用区机房容灾，并保证了容灾处理后数据的一致性。

为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关装置。请参阅图8，图8为本申请实施例提供的一种云集群的容灾管理装置的结构示意图，管理装置800包括：

获取单元801，用于获取用于部署云集群中的元集群的N个机器设备群所对应的群标识，不同的所述机器设备群之间独立运行，N为大于1的正整数；

部署单元802，用于基于所述群标识将所述元集群对应的中控服务分散部署到M个不同的所述机器设备群中，并将所述托管集群中对应的托管服务分散部署到R个不同的所述机器设备群中，以得到容灾设备网络，所述托管集群基于所述元集群关联的节点单元设定，所述中控服务用于管理所述托管服务的业务执行，M＜N，R＜N，M、R为正整数；

管理单元803，用于若容灾进程被触发，则将所述容灾进程对应的故障服务调整至所述容灾设备网络中的未被部署的机器设备群中运行，所述容灾进程基于所述元集群和所述托管集群中至少一种所对应的运行过程设定，所述故障服务包括所述中控服务和所述托管服务中的至少一种。

可选的，在本申请一些可能的实现方式中，所述部署单元802，具体用于基于所述群标识将所述元集群对应的中控服务分散部署到M个不同的所述机器设备群中，并对所述元集群关联的节点单元设定区域标签；

所述部署单元802，具体用于基于所述区域标签确定所述托管集群；

所述部署单元802，具体用于将所述托管集群中对应的所述托管服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述部署单元802，具体用于确定所述中控服务对应的中控副本信息；

所述部署单元802，具体用于基于所述中控副本信息对应的副本数量将所述元集群对应的所述中控服务分散部署到M个不同的所述机器设备群中；

所述部署单元802，具体用于确定所述托管服务对应的数据副本信息；

所述部署单元802，具体用于基于所述数据副本信息将所述托管集群中对应的所述托管服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述部署单元802，具体用于确定所述托管服务对应的数据服务和控制服务，所述控制服务为所述中控服务的组件；

所述部署单元802，具体用于基于所述数据副本信息将所述托管集群中对应的所述数据服务分散部署到R个不同的所述机器设备群中；

所述部署单元802，具体用于基于所述数据副本信息将所述托管集群中对应的所述控制服务分散部署到R个不同的所述机器设备群中，以得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述部署单元802，具体用于调用所述数据服务对应的服务检测接口；

所述部署单元802，具体用于基于所述服务检测接口对所述数据服务进行健康检测，以得到服务检测结果；

所述部署单元802，具体用于若所述服务检测结果指示所述数据服务正常，则基于所述数据副本信息将所述托管集群中对应的所述数据服务分散部署到R个不同的所述机器设备群中。

可选的，在本申请一些可能的实现方式中，所述部署单元802，具体用于将所述控制服务封装至服务容器中；

所述部署单元802，具体用于基于所述服务容器将所述控制服务配置在节点单元中，以基于所述数据副本信息将所述托管集群中对应的所述控制服务分散部署到R个不同的所述机器设备群中得到所述容灾设备网络。

可选的，在本申请一些可能的实现方式中，所述获取单元801，具体用于获取搭载于所述云集群的目标业务；

所述获取单元801，具体用于确定所述目标业务需求的网络参数；

所述获取单元801，具体用于基于所述网络参数为所述元集群部署N个所述机器设备群。

可选的，在本申请一些可能的实现方式中，所述获取单元801，具体用于确定所述目标业务对应的热点区域；

所述获取单元801，具体用于确定所述热点区域内的候选设备群；

所述获取单元801，具体用于基于所述网络参数为所述元集群从所述候选设备群中确定N个所述机器设备群对应的所述群标识以进行部署。

可选的，在本申请一些可能的实现方式中，所述管理单元803，具体用于若所述容灾进程被触发，则确定所述容灾进程对应的故障信息；

所述管理单元803，具体用于基于所述故障信息在所述容灾设备网络中的未被部署的机器设备群中进行检测，以得到容灾设备群；

所述管理单元803，具体用于将所述容灾进程对应的故障服务调整至所述容灾设备群中运行，并将所述容灾设备群与所述故障信息对应的容灾设备网络进行关联。

可选的，在本申请一些可能的实现方式中，所述管理单元803，具体用于确定所述托管集群对应的访问地址；

所述管理单元803，具体用于调用集群健康检查接口，以基于所述访问地址进行健康检查得到集群健康检查结果；

所述管理单元803，具体用于根据所述集群健康检查结果对所述托管集群在所述云集群中进行注册。

通过获取部署于所述云集群的元集群中N个机器设备群所对应的群标识，其中不同的机器设备群之间独立运行，N为大于1的正整数；然后基于群标识将元集群对应的中控服务分散部署到M个不同的机器设备群中，并将托管集群中对应的托管服务分散部署到R个不同的机器设备群中，以得到容灾设备网络，托管集群基于元集群关联的节点单元设定，中控服务用于管理托管服务的业务执行，M＜N，R＜N，M、R为正整数；若容灾进程被触发，则将容灾进程对应的故障服务调整至容灾设备网络中的未被部署的机器设备群中运行，该容灾进程基于元集群和托管集群中至少一种所对应的运行过程设定，该故障服务包括中控服务和托管服务中的至少一种。从而实现元集群与托管集群的层级框架中的自动容灾处理过程，由于机器设备群之间不会相互影响，保证了容灾切换之后设备的可用性，且整体过程无需人工干预，保证了容灾管理过程中的准确性。

本申请实施例还提供了一种服务器，请参阅图9，图9是本申请实施例提供的一种服务器的结构示意图，该服务器900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器（central processing units，CPU）922（例如，一个或一个以上处理器）和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930（例如一个或一个以上海量存储设备）。其中，存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块（图示没标出），每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器922可以设置为与存储介质930通信，在服务器900上执行存储介质930中的一系列指令操作。

服务器900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，和/或，一个或一个以上操作系统941，例如Windows ServerTM，Mac OS XTM，UnixTM, LinuxTM，FreeBSDTM等等。

上述实施例中由管理装置所执行的步骤可以基于该图9所示的服务器结构。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有云集群的容灾管理指令，当其在计算机上运行时，使得计算机执行如前述图1至图7所示实施例描述的方法中云集群的容灾管理装置所执行的步骤。

本申请实施例中还提供一种包括云集群的容灾管理指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如前述图1至图7所示实施例描述的方法中云集群的容灾管理装置所执行的步骤。

本申请实施例还提供了一种云集群的容灾管理系统，所述云集群的容灾管理系统可以包含图8所描述实施例中的云集群的容灾管理装置，或者图9所描述的服务器。

在一种可能的场景中，本申请中的网络资源管理的方法应用于区块链设备中，即权威DNS、LDNS或终端为区块链设备，且该区块链设备为区块链中的节点，下面结合附图进行说明；参见图10A所示的数据共享系统，数据共享系统1000是指用于进行节点与节点之间数据共享的系统，该数据共享系统中可以包括多个节点1001，多个节点1001可以是指数据共享系统中各个客户端。每个节点1001在进行正常工作可以接收到输入信息，并基于接收到的输入信息维护该数据共享系统内的共享数据。为了保证数据共享系统内的信息互通，数据共享系统中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。例如，当数据共享系统中的任意节点接收到输入信息时，数据共享系统中的其他节点便根据共识算法获取该输入信息，将该输入信息作为共享数据中的数据进行存储，使得数据共享系统中全部节点上存储的数据均一致。

对于数据共享系统中的每个节点，均具有与其对应的节点标识，而且数据共享系统中的每个节点均可以存储有数据共享系统中其他节点的节点标识，以便后续根据其他节点的节点标识，将生成的区块广播至数据共享系统中的其他节点。每个节点中可维护一个如下表所示的节点标识列表，将节点名称和节点标识对应存储至该节点标识列表中。其中，节点标识可为IP（Internet Protocol，网络之间互联的协议）地址以及其他任一种能够用于标识该节点的信息，表1中仅以IP地址为例进行说明。

表1节点名称与节点标识的对应关系

数据共享系统中的每个节点均存储一条相同的区块链。区块链由多个区块组成，参见图10B，区块链由多个区块组成，创始块中包括区块头和区块主体，区块头中存储有输入信息特征值、版本号、时间戳和难度值，区块主体中存储有输入信息；创始块的下一区块以创始块为父区块，下一区块中同样包括区块头和区块主体，区块头中存储有当前区块的输入信息特征值、父区块的区块头特征值、版本号、时间戳和难度值，并以此类推，使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，保证了区块中输入信息的安全性。

在生成区块链中的各个区块时，参见图10C，区块链所在的节点在接收到输入信息时，对输入信息进行校验，完成校验后，将输入信息存储至内存池中，并更新其用于记录输入信息的哈希树；之后，将更新时间戳更新为接收到输入信息的时间，并尝试不同的随机数，多次进行特征值计算，使得计算得到的特征值可以满足下述公式：

其中，SHA256为计算特征值所用的特征值算法；version（版本号）为区块链中相关区块协议的版本信息；prev_hash为当前区块的父区块的区块头特征值；merkle_root为输入信息的特征值；ntime为更新时间戳的更新时间；nbits为当前难度，在一段时间内为定值，并在超出固定时间段后再次进行确定；x为随机数；TARGET为特征值阈值，该特征值阈值可以根据nbits确定得到。

这样，当计算得到满足上述公式的随机数时，便可将信息对应存储，生成区块头和区块主体，得到当前区块。随后，区块链所在节点根据数据共享系统中其他节点的节点标识，将新生成的区块分别发送给其所在的数据共享系统中的其他节点，由其他节点对新生成的区块进行校验，并在完成校验后将新生成的区块添加至其存储的区块链中。

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

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。