CN115113800A - 多集群管理方法、装置、计算设备及存储介质 - Google Patents

Abstract

本申请提供了一种基于分布式存储系统的多集群管理方法、装置、计算设备及存储介质。该分布式存储系统包括多个存储集群、至少一个管理节点和至少一个代理集群，至少一个管理节点与至少一个代理集群是一一对应的，至少一个代理集群中的每个代理集群与多个存储集群可通信地耦合。该方法应用于每个代理集群并包括：接收来自对应管理节点的集群管理请求，集群管理请求用于请求针对存储集群执行管理操作；基于集群管理请求，在多个存储集群中确定目标存储集群；向目标存储集群发送操作请求，以请求对目标存储集群执行管理操作。该方法允许通过多个存储集群为一套云环境提供存储服务，例如块存储服务，同时保持该多个存储集群对用户透明。

Description

多集群管理方法、装置、计算设备及存储介质

技术领域

本申请涉及计算机技术领域，具体地，涉及一种基于分布式存储系统的多集群管理方法、多集群管理装置、计算设备及计算机可读存储介质。

背景技术

随着计算机技术的发展，分布式存储系统得到了越来越广泛的应用。例如，在云平台（诸如基于Openstack的云平台）中，通常使用诸如Ceph的分布式存储系统来提供存储服务。

Ceph是一种开源的分布式存储系统，可以提供对象、块、文件存储服务。在基于Openstack的云平台中，使用最多的是块存储服务。一般而言，一个Openstack云环境使用一个Ceph存储集群来提供块存储服务。然而，随着业务增多，块存储使用增加，Ceph存储集群随之需要扩容。而随着Ceph存储集群的增大，运维管理难度随之升高，存储的可靠性也随之降低。例如，在一个大存储集群中，当一个存储节点宕机时，会引发该存储集群内部大量的数据迁移，从而占用大量带宽，影响正常的业务IO（Input and Output，输入输出）。

发明内容

有鉴于此，本申请提供了一种基于分布式存储系统的多集群管理方法、用于分布式存储系统的多集群管理装置、计算设备及计算机可读存储介质，可以缓解、减轻或甚至消除上述问题。

根据本申请的一方面，提供了一种基于分布式存储系统的多集群管理方法，其中，所述分布式存储系统包括多个存储集群、至少一个管理节点和至少一个代理集群，所述至少一个管理节点与所述至少一个代理集群是一一对应的，所述至少一个代理集群中的每个代理集群与所述多个存储集群可通信地耦合，所述方法应用于所述每个代理集群并包括：接收来自对应管理节点的集群管理请求，所述集群管理请求用于请求针对存储集群执行管理操作；基于所述集群管理请求，在所述多个存储集群中确定目标存储集群；向所述目标存储集群发送操作请求，以请求对所述目标存储集群执行所述管理操作。

在一些实施例中，所述集群管理请求包括卷创建请求，所述卷创建请求包括待创建的目标卷的卷信息，并且其中，所述基于所述集群管理请求，在所述多个存储集群中确定目标存储集群包括：根据所述多个存储集群的容量信息和对应的预配置权重信息中的至少一种信息、所述卷创建请求中包括的目标卷的卷信息，在所述多个存储集群中选择目标存储集群，其中，预配置权重信息表征对应的存储集群被选中的概率。

在一些实施例中，所述集群管理请求包括以下中的相应一个请求：包括待删除的目标卷的卷信息的卷删除请求、包括待修改的目标卷的卷信息的卷修改请求、包括待查询的目标卷的卷信息的卷查询请求和包括待挂载的目标卷的卷信息的卷挂载请求，并且其中，所述基于所述集群管理请求，在所述多个存储集群中确定目标存储集群包括：根据所述相应一个请求中包括的目标卷的卷信息，获取所述目标卷与存储集群的映射关系；将所获取的映射关系中的存储集群确定为所述目标存储集群。

在一些实施例中，所述集群管理请求包括以下中的相应一个请求：用于将已挂载的卷卸载的卷卸载请求、用于从已挂载的卷读取数据的数据读取请求和用于向已挂载的卷写入数据的数据写入请求，并且其中，所述基于所述集群管理请求，在所述多个存储集群中确定目标存储集群包括：将当前已挂载的卷所处于的存储集群确定为目标存储集群。

在一些实施例中，所述分布式存储系统还包括映射存储集群，所述映射存储集群被配置为存储卷与存储集群的映射关系，并且其中，所述方法还包括以下中的至少一项：向所述映射存储集群发送所述集群管理请求所针对的目标卷与目标存储集群的映射关系；以及从所述映射存储集群接收所述集群管理请求所针对的目标卷与目标存储集群的映射关系。

在一些实施例中，所述至少一个管理节点中的每个管理节点包括管理客户端，所述管理客户端被配置为与对应代理集群通信，并且其中，所述接收来自对应管理节点的集群管理请求包括：接收来自对应管理节点的管理客户端的集群管理请求。

在一些实施例中，所述代理节点包括用于维护代理集群内的进程信息的集群管理进程和用于处理集群管理请求的请求管理进程，并且其中，所述接收来自对应管理节点的管理客户端的集群管理请求包括：基于所述管理客户端对与请求管理进程相关的信息的请求，由所述集群管理进程向所述管理客户端发送与所述请求管理进程相关的信息；接收定位指示，所述定位指示是由所述管理客户端基于与所述请求管理进程相关的信息生成的，并用于指示代理集群内部的用于接收所述集群管理请求的请求管理进程；由所指示的请求管理进程接收所述集群管理请求以进行处理。

在一些实施例中，所述基于所述集群管理请求，在所述多个存储集群中确定目标存储集群包括：将所接收的集群管理请求加入请求队列；从所述请求队列中依次获取各集群管理请求，并根据所获取的集群管理请求所包括的操作码对所述获取的集群管理请求的参数进行相应处理，以收集与所述管理操作有关的信息，并通过与所述操作码对应的方式确定所述目标存储集群。

在一些实施例中，所述至少一个代理集群中的每个代理集群位于对应管理节点上，并且其中，所述接收来自对应管理节点的集群管理请求包括：接收对应管理节点的本地的集群管理请求。

在一些实施例中，多集群管理方法还包括：接收来自所述目标存储集群的针对所述操作请求的反馈消息，所述反馈消息用于指示所述管理操作的执行结果；向对应管理节点转发所述反馈消息。

在一些实施例中，多集群管理方法还包括：向所述多个存储集群中的至少一个存储集群请求容量信息；接收由所述至少一个存储集群上报的容量信息。

根据本申请的另一方面，提供了一种用于分布式存储系统的多集群管理装置，其中，所述分布式存储系统包括多个存储集群、至少一个管理节点和至少一个多集群管理装置，所述至少一个管理节点与所述至少一个多集群管理装置是一一对应的，所述至少一个多集群管理装置中的每个多集群管理装置与所述多个存储集群可通信地耦合，所述多集群管理装置包括：接收模块，被配置为接收来自对应管理节点的集群管理请求，所述集群管理请求用于对存储集群执行管理操作；确定模块，被配置为基于所述集群管理请求，在所述多个存储集群中确定目标存储集群；发送模块，被配置为向所述目标存储集群发送与所述集群管理请求相对应的操作请求，以对所述目标存储集群执行所述管理操作。

根据本申请的又一方面，提供了一种计算设备，包括存储器，其被配置成存储计算机可执行指令；处理器，其被配置成当所述计算机可执行指令被处理器执行时执行前述方面中所描述的方法。

根据本申请的再一方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，当所述计算机可执行指令被执行时，执行前述方面中所描述的方法。

基于上文所述的技术方案，在本申请中，可以在分布式存储系统中设置与各管理节点一一对应的代理集群，通过代理集群接收对应管理节点的集群管理请求，对集群管理请求进行处理和调度，并将对应的操作请求发送至后端的多个存储集群中的目标存储集群。通过这种代理过程，可以实现使用多个存储集群来为一个云环境提供块存储服务，从而避免对单个大存储集群的需要。同时，随着业务增多而带来的扩容需求可以通过增加存储集群的数量来满足，而无需对单个存储集群进行扩容，从而也可以避免存储集群随着使用而逐渐变大的问题。由此，当一个存储集群中的一个存储节点宕机时，所引发的数据迁移问题可以被限制在单个存储集群内部，而不会影响到其他提供服务的存储集群。这有助于提高存储服务的稳定性和可靠性。

此外，上述代理过程还使得能够保持后端的多个存储集群对用户而言是透明的，即，在用户看来，存储服务依然是由单个集群提供的。这有助于避免存在多个存储集群为用户操作带来的困扰，从而有助于在解决前述问题的同时保持良好的用户体验。

根据在下文中所描述的实施例，本申请的这些和其它方面将是清楚明白的，并且将参考在下文中所描述的实施例而被阐明。

附图说明

在下面结合附图对于示例性实施例的描述中，本申请的更多细节、特征和优点被公开，在附图中：

图1示意性示出了可以应用本申请提供的技术方案的示例场景；

图2示意性示出了根据本申请实施例提供的一种云平台管理系统的示例架构图；

图3示意性示出了相关技术提供的一种多集群管理方案的架构图；

图4示意性示出了根据相关技术提出的一种设想的多集群管理方案的示例架构图；

图5示意性示出了根据本申请实施例提供的多集群管理方法的示例流程图；

图6示意性示出了根据本申请实施例提供的多集群管理方案的示例架构图；

图7示意性示出了根据本申请实施例提供的多集群管理方案的另一示例架构图；

图8示意性示出了根据本申请实施例提供的代理集群的示例架构图；

图9示意性示出了根据本申请实施例的基于图8所示的代理集群处理卷创建请求的示例方案；

图10示意性示出了根据本申请实施例的基于图8所示的代理集群处理卷挂载请求的示例方案；

图11示意性示出了根据本申请实施例的基于图8所示的代理集群处理数据读写请求的示例方案；

图12示意性示出了根据本申请实施例的多集群管理装置的示例框图；

图13示意性示出了根据本申请实施例的计算设备的示例框图。

具体实施方式

在详细介绍本申请的实施例之前，首先对一些相关的概念进行解释。

云技术（Cloud technology）是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云计算（Cloud computing）是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池（简称云平台，一般称为IaaS（Infrastructure as a Service，基础设施即服务）平台）。在资源池中，可以部署多种类型的虚拟资源，以供外部使用者选择使用。云计算资源池中主要包括：计算设备（为包含操作系统的虚拟化机器）、存储设备、网络设备。

云存储（Cloud storage）是在云计算概念上延伸和发展出来的一个新的概念。云存储通常通过分布式存储系统来实现。分布式存储系统是指将数据分散存储在多台独立的存储设备（存储设备也称之为存储节点）上，存储设备通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能。其有助于提高系统的可靠性、可用性和存取效率，还可以提供易于扩展的优势。例如，前文提及的Ceph就是一种常用的分布式存储系统，其主要基于Ceph存储集群来提供存储服务。

目前，分布式存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识（ID，Identification) 等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。

OpenStack是一种开源的Iaas（Infrastructure as a Service，基础设施即服务）管理平台。Cinder是Openstack中提供块存储的组件，可以用于为虚拟机提供磁盘。

本申请提供的技术方案可以应用于区块链领域中。区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链（Blockchain），本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性（防伪）和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成（账户管理）、密钥管理以及用户真实身份和区块链地址对应关系维护（权限管理）等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置（风控审计）；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理（接口适配），然后通过共识算法将业务信息加密（共识管理），在加密之后完整一致的传输至共享账本上（网络通信），并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上（合约注册），根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

图1示意性示出了可以应用本申请提供的技术方案的示例场景100。

如图所示，场景100可以包括服务器110和存储服务器120。本申请所提供的基于分布式存储系统的多集群管理技术方案可以部署于服务器110，并用于管理部署于一个或多个存储服务器120的存储集群。这些服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。此外，可选地，这些服务器仅作为示例被示出，实际也可以替代地使用其他具有计算能力及存储能力的设备或设备的组合来提供相应服务。

可选地，用户140可以通过终端设备130经由网络访问服务器110，以获取服务器110所提供的服务。示例性地，终端设备130可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。

终端与服务器以及服务器之间可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

进一步地，图2示意性示出了一种可以应用本申请提供的技术方案的云平台管理系统的示例架构200。架构200包括业务层210、网关层220、基础云层230以及存储层240。在一些实施例中，架构200可以部署于类似于图1所示的应用场景中。示例性地，业务层210可以实现于终端设备130上，网关层220、基础云层230及代理集群可以实现于多个服务器110上，存储层240中的Ceph存储集群可以实现于多个存储服务器120上。

具体而言，业务层210包括用户可以直接进行操作的层级，其可以包括但不限于图2所示的自助平台、监控平台和运维平台。具体地，自助平台可以为用户提供申请资源的界面，用户可以使用终端设备访问该界面，并完成申请资源等流程；监控平台可以用于监控整个平台的资源使用情况；运维平台可以为管理员提供操作页面，使得管理员可以对平台进行管理操作，例如对一些宿主机进行迁移等。

云网关层220可以包括但不限于图2所示的Venus、IP系统以及RBAC（基于角色的访问控制，Role-Based Access Control）。具体地，venus可以用于提供统一的云平台资源接口，IP系统可以用于管理各个网络设备IP等网络资源，RBAC可以用于鉴权。可选地，可以通过其他方案实现上述功能。

基础云层230可以包括但不限于图2所示的虚拟机管理组件、镜像管理组件以及块存储管理组件。基础云层230可以基于前文提到的Openstack进行构建，以提供Iaas服务。在基于Openstack的基础云层中，通常通过Nova组件来管理虚拟机的生命周期，通过Glance组件来管理镜像的生命周期，以及通过Cinder组件来管理块存储（在本文中也称为“卷”）的生命周期。

存储层240可以包括若干个存储集群，例如图2所示的Ceph存储集群。根据本申请提供的技术方案，可以通过代理集群对来自块存储管理组件的请求进行管理调度，进而向与该请求对应的存储集群发送相关操作请求。

基于前文的分析，通过单个大存储集群提供块存储服务会带来运维难度增大、存储可靠性降低等诸多问题。根据相关技术，Cinder组件本身支持同时管理多套存储集群，每一套存储集群使用一个驱动器（driver）实例对接，从而可以实现将单个大存储集群拆分成多个小存储集群进行管理。示意性地，图3示出了这种多集群管理方案的架构300。

如图3所示，这种多集群管理架构包括三个控制节点321、322和323。这三个控制节点可以是完全对等的，即所接收的请求可以由VIP（Virtual IP，虚拟IP）模块310根据预设机制等概率地分发至各个控制节点，从而实现其所提供服务的高可用性。可以根据需要设定控制节点的数量，而非局限于图3所示出的三个控制节点。

每个控制节点的Cinder组件可以使用一个驱动器对接管理一个Ceph存储集群，并通过该驱动器来实现对相应Ceph存储集群中卷的生命周期管理。例如，在图3中，各Cinder组件可以通过驱动器1来管理Ceph存储集群331，通过驱动器2来管理Ceph存储集群332，以及通过驱动器3来管理Ceph存储集群333。当请求通过VIP模块被分发到一个控制节点上后，该控制节点的Cinder组件可以通过预设的驱动器管理机制选择相应的驱动器来处理该请求，以对相应存储集群上的目标卷进行管理。

对于一个控制节点而言，其中各个驱动器所管理的后端Ceph存储集群是相互隔离的，并且每个驱动器都具有各自的存储超分比，例如20。超分比是指用户可以使用的存储容量相对于真实物理容量的倍数，例如，在超分比设置为20的情况下，用户可以使用的存储容量是真实容量的20倍。由于Ceph的卷是精简配置，在创建卷的时候不会实际占用申请的大小，而只是生成一些元数据，实际占用空间会随着业务的增加而逐渐增大，因此，如果不设置超分比，一个存储集群没过多久就会被全部占用，但该存储集群的实际空闲容量可能还有很多。但是，在设置了超分比之后，后端每个存储集群可以分配的容量实际上超过了其真实的物理容量，因此，随着业务的增加，在实际占用空间逐渐增大的过程中，必然需要对存储集群进行扩容，这样，小存储集群又会慢慢的变成大存储集群，并进而导致前文所提到的诸多问题。

此外，每一个后端存储集群都需要创建一个与之对应的卷类型，从而，当用户创建卷时，可以通过选择卷类型来间接地指定后端存储集群。例如，卷类型可以用于区分不同的存储后端，比如Ceph存储集群或者Ipsan集中式存储，或者可以用于区分不同的存储介质，比如Ceph存储集群是SSD（固态驱动器）或者HDD（硬盘驱动器）。根据图3所示的多集群管理方案，后端存储集群对用户而言不是透明的，即，在用户看来，后端确实存在多套存储集群在提供存储服务。并且，这种由单个大集群拆分出的多个小集群的属性信息（比如卷类型）是相同的，这会为用户选择卷类型时带来无目的性，从而可能造成困扰，影响用户的使用体验。

图4示意性示出了基于相关技术提出的一种设想的多集群管理方案的示例架构400。总体而言，该方案通过设置代理网关420来截取所有请求，然后在网关内部对这些请求进行处理和调度，进而将其发送到后端的Ceph存储集群431、432和433。

具体地，架构400包括一个控制节点411和一个计算节点412。类似地，控制节点和计算节点的数量可以根据需要设定，而不局限于图中所示出的数量。如图所示，Cinder组件可以被部署在控制节点411上，并通过Ceph客户端发送控制流，虚拟机可以被部署在计算节点412上，并通过Ceph客户端发送数据流。Ceph客户端用于实现与图3中的驱动器类似的功能。可选地，不同的控制节点和计算节点可以被部署在不同的虚拟主机上。

基于架构400，所有的控制流和数据流均经过代理网关420，而后被调度发送到后端Ceph存储集群，Ceph存储集群的所有反馈也均经过代理网关420，而后被反馈至Ceph客户端。然而，Ceph在TCP协议上面自定义了客户端和服务端的网络通信协议，并且具有网络包的CRC校验，因此，代理网关420在中间拦截和篡改的TCP包将无法正确地被后端Ceph存储集群和Ceph客户端处理。因此，图4所示的基于代理网关的多集群管理方案实际上是不可行的。

为了更好地解决前文所提到的各种问题，同时弥补相关技术中的多集群管理方案的不足，本申请提出了一种新的多集群管理方法。

图5示意性示出了根据本申请实施例提供的多集群管理方法500的示例流程图。该多集群管理方法500可以用于分布式存储系统。该分布式存储系统可以包括多个存储集群、至少一个管理节点和至少一个代理集群，其中，至少一个管理节点与至少一个代理集群是一一对应的，并且至少一个代理集群中的每个代理集群与多个存储集群可通信地耦合。在本申请中，可通信地耦合意味着代理集群与后端的存储集群可以基于某种通信协议正确通信，由代理集群发送的消息可以被存储集群正确地解包和处理，而由存储集群反馈的消息也可以经由代理集群正确地反馈给管理节点，并被管理节点正确地解包和处理，而不会存在关于图4描述的由于协议冲突而出现的问题。多集群管理方法可以由各代理集群执行，并且包括图5所示的各个步骤。

在步骤510，接收来自对应管理节点的集群管理请求，该集群管理请求用于请求针对存储集群执行管理操作。在一些实施例中，管理节点可以包括控制节点和计算节点中的至少一种。不同的管理节点可以部署在相同或不同的服务器上。可选地，不同管理节点可以部署在不同的虚拟主机上。在一些实施例中，控制节点可以包括Cinder组件，并可以发送针对存储集群的控制流。针对存储集群的控制流可以涉及针对存储集群中的目标卷的控制操作，例如可以包括以下类型的请求中的至少一种：用于创建目标卷的卷创建请求、用于删除目标卷的卷删除请求、用于修改目标卷（诸如对目标卷进行扩容）的卷修改请求、用于查询目标卷的卷信息的卷查询请求、用于将目标卷挂载至虚拟机的卷挂载请求以及用于卸载已挂载的目标卷的卷卸载请求。计算节点可以包括虚拟机，并可以发送针对存储集群的数据流。针对存储集群的数据流可以涉及针对存储集群中的目标卷的读写操作，例如可以包括以下类型的请求中的至少一种：用于从已挂载的目标卷读取数据的数据读取请求以及用于向已挂载的目标卷写入数据的数据写入请求。

在步骤520，基于集群管理请求，在多个存储集群中确定目标存储集群。在一些实施例中，集群管理请求可以由操作码和对应的参数构成，其中，操作码可以指示针对对应参数所做的操作，并且可以表征集群管理请求的类型，例如前文述及的各种请求类型。集群管理请求的参数可以指示管理操作对应的对象，例如，针对卷创建请求，参数可以指示待创建的目标卷的卷名、ID、大小等；或者，例如，针对卷挂载请求，参数可以指示待挂载的目标卷的卷名、ID等；又或者，例如，针对卷写入请求，参数可以指示待写入的数据等。在一些实施例中，基于集群管理请求的不同类型，可以根据不同的方式在多个存储集群中确定目标存储集群，这将在下文中进一步详细描述。

在步骤530，向目标存储集群发送操作请求，以请求对目标存储集群执行前述管理操作。在一些实施例中，代理集群在处理和调度集群管理请求的过程中，可以对集群管理请求进行修改来得到相应的操作请求，或者，可以基于集群管理请求生成相应的操作请求，并进而将该操作请求发送至所确定的目标存储集群，该操作请求可以指示目标存储集群执行相应的管理操作。或者，在一些实施例中，也可以将集群管理请求作为操作请求转发至目标存储集群，以指示目标存储集群执行相应的管理操作。在一些实施例中，操作请求可以因代理集群的类型不同而有所不同。例如，针对卷创建请求，操作请求可以包括请求在目标存储集群上创建目标卷的指令以及该目标卷的各种信息（如卷名、ID、大小以及其他属性）等；针对卷挂载请求，操作请求可以包括请求挂载目标卷的指令以及该目标卷的诸如卷名、ID的信息等；针对数据写入请求，操作请求可以包括写入数据的指令以及待写入的数据等。

通过在分布式存储系统中设置代理集群并令各代理集群执行多集群管理方法500，可以实现通过代理集群接收对应管理节点的全部集群管理请求，并在进行处理和调度后指示相应的目标存储集群执行相应管理操作。从而允许通过多个存储集群为一个云环境提供块存储服务，以避免对单个大存储集群的需要。并且，后续扩容需求可以通过增加存储集群的数量来实现，从而也可以避免小存储集群随使用而逐渐变为大存储集群的问题。同时，还可以实现后端存储集群对用户的透明，使得在用户看来，只有一个集群在提供存储服务，从而有助于在解决前述问题的同时维持良好的用户体验。

在一些实施例中，方法500还可以包括：接收来自目标存储集群的针对操作请求的反馈消息，该反馈消息用于指示管理操作的执行结果；以及，向对应管理节点转发该反馈消息。这可以允许管理节点及时获知针对集群管理请求的执行结果。在一些实施例中，目标存储集群在接收到来自代理集群的操作请求时，可以对操作请求进行处理，并根据请求中的指令执行相应操作，然后向代理集群发送反馈消息，以指示针对该操作请求的执行结果，以及可选地反馈其他需要告知代理集群或管理节点的信息，该过程可以根据相关技术中存储集群的常规机制来进行，为简洁起见，本申请对此不再赘述。然而，可选地，本领域技术人员也可以设想涉及对后端存储集群进行修改的实施例，这种实施例也应被认为涵盖在本申请所提出的技术方案的范围内。在接收到来自目标存储集群的反馈消息后，代理集群可以将其直接转发至对应管理节点，以将执行结果以及可选的相关信息告知管理节点。或者，可选地，代理节点向对应管理节点转发反馈消息也可以通过以下方式实现：代理集群可以对所接收的反馈消息进行一定处理，并将处理后的反馈消息反馈至对应管理节点。

在一些实施例中，方法500还可以包括：向多个存储集群中的至少一个存储集群请求容量信息；接收由至少一个存储集群上报的容量信息。在代理集群针对后端存储集群进行调度的过程中，可能需要获知各存储集群的容量信息，例如，在针对卷创建请求进行调度时，代理集群需要选择当前容量能够满足需求的存储集群作为目标存储集群。代理集群可以通过存储集群的上报来获知这种容量信息。在一些实施例中，代理集群可以周期性地向各存储集群请求容量信息（例如，每隔5s请求一次），存储集群可以相应于该请求而将容量信息上报给代理集群。

在一些实施例中，针对不同类型的集群管理请求，可以通过不同的方式在多个存储集群中确定目标存储集群。

具体而言，在集群管理请求包括卷创建请求（包括目标卷的卷信息）的情况下，可以通过以下方式在多个存储集群中确定目标存储集群：根据多个存储集群的容量信息和对应的预配置权重信息中的至少一种信息、卷创建请求中包括的目标卷的卷信息，在多个存储集群中选择目标存储集群。目标卷与目标存储集群的映射关系可以被储存以供后续查询使用。预配置权重信息可以表征对应的存储集群被选中的概率，可以通过预先配置该信息来调整各个存储集群被选中的概率大小。容量信息可以是由存储集群上报至代理集群的，可选地，这种上报可以主动或被动地完成。

在集群管理请求包括以下中的相应一个请求的情况下：包括待删除的目标卷的卷信息的卷删除请求、包括待修改的目标卷的卷信息的卷修改请求、包括待查询的目标卷的卷信息的卷查询请求和包括待挂载的目标卷的卷信息的卷挂载请求，可以通过以下方式在多个存储集群中确定目标存储集群：根据相应一个请求中包括的目标卷的卷信息，获取目标卷与存储集群的映射关系；将所获取的映射关系中的存储集群确定为目标存储集群。目标卷与存储集群的映射关系可以是先前存储的，例如在该目标卷被创建时被存储的。

在集群管理请求包括以下中的相应一个请求的情况下：用于将已挂载的卷卸载的卷卸载请求、用于从已挂载的卷读取数据的数据读取请求和用于向已挂载的卷写入数据的数据写入请求，可以通过以下方式在多个存储集群中确定目标存储集群：将当前已挂载的卷所处于的存储集群确定为目标存储集群。

上述各种方式将在下文中借助具体示例来详细描述，在此不再赘述。

在一些实施例中，图5所示的多集群管理方法500可以基于图6所示的示例架构600来实现。

如图所示，架构600包括两个管理节点（即，控制节点611和计算节点612）、与两个管理节点一一对应的两个代理集群（即，迷你Ceph集群621和622）以及三个存储集群（即，Ceph存储集群631、632和633）。每个迷你Ceph集群与三个Ceph存储集群中的每一个Ceph存储集群可通信地耦合，这种通信可以通过部署于迷你Ceph集群上的Ceph客户端来实现。应理解，本申请中所述及的Ceph客户端可以涉及能够完成客户端功能的一个或多个实体、模块或者进程等，客户端功能可以包括例如与相应的服务端进行通信以及实现其他相关处理功能，比如，针对Cinder组件或虚拟机中的Ceph客户端而言，其服务端由对应的迷你Ceph集群提供，而针对迷你Ceph集群中的Ceph客户端而言，其服务端由后端的Ceph存储集群提供。并且，类似前文所述及的，各种节点以及集群的具体数量可以根据需要设定。图5所示的多集群管理方法500可以由图6所示的迷你Ceph集群621和622执行。

在一些实施例中，至少一个管理节点中的每个管理节点可以包括管理客户端，管理客户端可以被配置为与对应代理集群通信。在这种情况下，每个代理集群可以接收来自对应管理节点的管理客户端的集群管理请求。例如，在图6所示的架构600中，控制节点611及计算节点612均可以包括管理客户端，即图中所示的由Cinder组件及虚拟机包括的Ceph客户端。如前文所述及的，控制节点611及计算节点612可以通过相应的Ceph客户端向对应的迷你Ceph集群发送各种集群管理请求。

示例性的，用户可以通过图2所示的业务层210中的各种平台所提供的界面来发起针对后端存储集群（例如Ceph存储集群）的各种操作请求。例如，用户可以经由网关层220中的Venus提供的云平台资源接口来访问部署在云平台上的虚拟机，并通过对虚拟机进行操作来发起针对后端存储集群的各种操作请求。示例性地，基于用户的具体操作，虚拟机可以直接通过所包括的Ceph客户端发起图6所示的数据流，例如针对已挂载于该虚拟机上的目标卷发起数据读取请求或数据写入请求；或者，虚拟机可以指示Cinder组件通过其所包括的Ceph客户端发起图6所示的控制流，例如发起卷创建请求以在后端存储集群上创建目标卷、发起卷挂载请求以将后端存储集群上的目标卷挂载至虚拟机以供使用等。然而，也可以通过其他方式发图6所示的数据流和控制流，本申请在此方面并不加以限制。

在一些实施例中，图5所示的多集群管理方法500也可以基于图7所示的示例架构700来实现。

如图所示，架构700包括三个管理节点（即，控制节点711和计算节点712、713）、与三个管理节点一一对应的三个代理集群（即，迷你Ceph集群721、722及723）以及三个存储集群（即，Ceph存储集群731、732和733）。每个迷你Ceph集群与三个Ceph存储集群中的每一个Ceph存储集群可通信地耦合，这种通信可以通过部署于迷你Ceph集群上的Ceph客户端来实现。

在一些实施例中，至少一个代理集群中的每个代理集群可以位于对应管理节点上。在这种情况下，每个代理集群可以接收对应管理节点的本地的集群管理请求。例如，在图7所示的架构700中，迷你Ceph集群721可以位于控制节点711上，迷你Ceph集群722可以位于计算节点712上，以及迷你Ceph集群723可以位于计算节点713上。进一步地，迷你Ceph集群721、722及723中的各种进程可以绑定本地地址，例如常用的127.0.0.1，由此，迷你Ceph集群721、722及723中的各种进程可以被相应控制节点或计算节点本地调用，从而使得调用过程更为简洁，并且避免对单独的通信链路和/或用于存放迷你Ceph集群的单独主机的维护，进而有助于提高控制流及数据流的处理效率并提高整个架构的稳定性和安全性。

在一些实施例中，分布式存储系统还可以包括映射存储集群，映射存储集群可以被配置为存储卷与存储集群的映射关系。在这种情况下，每个代理集群可以与映射存储集群通信，从而执行以下操作中的至少一项：向映射存储集群发送集群管理请求所针对的目标卷与目标存储集群的映射关系；以及从映射存储集群接收集群管理请求所针对的目标卷与目标存储集群的映射关系。例如，在针对卷创建请求的处理过程中，迷你Ceph集群可以将卷创建请求针对的目标卷和所选择的目标存储集群的映射关系存储至映射存储集群；在针对诸如卷挂载请求等的集群管理请求的处理过程中，迷你Ceph集群可以从映射存储集群获取要操作的目标卷与存储集群的映射关系。通过使用映射存储集群存储卷与存储集群的映射关系以及各代理集群与映射存储集群的通信机制，可以保证各代理集群能够访问相同的准确且完整的与卷和存储集群的映射关系相关的映射数据，从而保证映射数据的高可靠性。并且，映射存储集群也可以使用分布式存储的策略来存储映射数据，从而进一步保证映射数据的安全性、可用性及存取效率。

示例性地，在图7所示的架构700中，可以包括ETCD集群，该ETCD集群可以用作各迷你Ceph集群的共享存储集群，用于存放卷到后端存储集群的映射关系。ETCD集群可以用于提供高可用的分布式键值（key-value）数据库，有助于提供强一致性、高可用的服务存储目录，从而有助于保证映射数据的高可靠性。可选地，也可以根据实际需要应用其他类型的集群来作为映射存储集群，诸如Zookeeper等。

如图6和图7所示，在一些实施例中，代理集群可以通过迷你Ceph集群来实现。迷你Ceph集群可以是基于常规Ceph存储集群改造而实现的，其主要功能不再是存储数据，而是对集群管理请求进行代理。如此，在Ceph客户端和Ceph存储集群之间设置这种代理集群，相当于在其间插入一个新的Ceph集群，可以保持Ceph自定义的网络协议，而不需要额外的解包流程。图8示意性示出了这种代理集群（即，迷你Ceph集群）的示例架构800。

在架构800中，示出了迷你Ceph集群810和与其对应的Ceph客户端820，Ceph客户端820可以部署在图6或图7中示出的Cinder组件或虚拟机上。具体地，迷你Ceph集群810可以包括三个进程，即图8所示的Mgr进程811、Mon进程812和OSD进程813。如前文所述及的，可选地，Mgr进程811、Mon进程812和OSD进程813可以均绑定本地IP地址，以便以更为简洁可靠的方式实现对相应管理节点上的所有数据流或控制流的代理。在一些实施例中，Mgr进程811可以用作代理集群的监控接入进程，用于接入外部监控系统，比如Prometheus（普罗米修斯）、Dashboard（仪表盘）等；OSD进程813可以用作代理集群的请求管理进程，用于接收并处理各种集群管理请求；mon进程812可以用作代理集群的集群管理进程，用于存储与代理集群相关的各种信息，诸如代理集群的状态信息、与代理集群中的监控接入进程、集群管理进程以及请求管理进程相关的信息等。迷你Ceph集群中的Mgr进程、Mon进程可以与常规Ceph存储集群中的Mgr进程、Mon进程相似或相同，而OSD进程相对于常规Ceph存储集群中的OSD进程具有较多改变。在常规Ceph存储集群中，OSD（Object Storage Device，对象存储设备）主要用于在诸如物理磁盘的存储装置上存储数据，而在本申请所提出的迷你Ceph集群中，OSD进程主要用于代理集群管理请求，其在处理集群管理请求的过程中无需在磁盘上存储数据。因此，在本申请所提出的迷你Ceph集群中，OSD进程所提供的服务可以视为一种无状态服务。

在一些实施例中，代理集群可以通过如下步骤来接收来自对应管理客户端的集群管理请求：基于管理客户端对与请求管理进程相关的信息的请求，由集群管理进程向管理客户端发送与请求管理进程相关的信息；接收定位指示，该定位指示是由管理客户端基于与请求管理进程相关的信息确定的，并用于指示代理集群内部的用于接收集群管理请求的请求管理进程；由所指示的请求管理进程接收集群管理请求以进行处理。

示例性地，在图8所示的架构800中，上述步骤可以由迷你Ceph集群810实施。具体而言，Ceph客户端820可以向迷你Ceph集群810中的Mon进程812请求OSDmap（OSD表），并接收Mon进程812所发送的OSDmap。示例性地，Ceph客户端820可以根据本地配置文件中的默认Mon地址向对应Mon进程请求Monmap（Mon表），然后通过Monmap中所包括的Mon进程812的地址来建立与Mon进程812的连接，以从其获取OSDmap。在获取到OSDmap后，Ceph客户端820可以基于OSDmap生成定位指示，并将该定位指示发送至迷你Ceph集群810，以指示由迷你Ceph集群中的OSD进程813接收集群管理请求。可选地，定位指示可以通过Ceph客户端820向OSD进程813发送相应消息来实现，也可以通过Ceph客户端820直接建立与OSD进程813之间的连接来实现。可选地，Ceph客户端可以通过分布算法来基于OSDmap定位至某个OSD进程，诸如crush（Controlled Replication Under Scalable Hashing，可扩展哈希下的受控复制）算法，该算法是一种伪随机数据分布算法。随后，Ceph客户端820可以向OSD进程813发送集群管理请求，并且OSD进程813将对所接收的集群管理请求进行处理。

通过由代理集群执行上述步骤，可以允许维持当前管理客户端（诸如Ceph客户端）管理集群管理请求的流程，从而最小化对现有分布式存储系统的修改，从而允许以更小的成本在现有分布式存储系统中实现本申请所提供的多集群管理技术方案。

在一些实施例中，如前文所提及的，集群管理请求可以包括操作码和对应的参数。在接收到集群管理请求后，代理集群可以将所接收的集群管理请求加入请求队列；随后，可以从请求队列中依次获取各集群管理请求，并根据所获取的集群管理请求所包括的操作码对所获取的集群管理请求的参数进行相应处理，以收集与管理操作有关的信息，并通过与操作码对应的方式确定目标存储集群。示例性地，该过程可以通过图8中的OSD进程813实现。

如图8所示，OSD进程813可以包括OSDServer（OSD服务端）模块、PrimaryPG（主PG）模块、ProxyManager（代理管理器）模块、ProxyStore（代理存储器）模块、ProxyScheduler（代理调度器）模块和ProxyClient（代理客户端）模块。示例性地，OSD进程813可以是在常规OSD进程的基础上

具体而言，OSDServer模块可以接收来自Ceph客户端的集群管理请求，即，OSD进程813可以通过所包括的OSDServer模块从Ceph客户端820接收集群管理请求。随后，OSDServer模块可以将所接收的集群管理请求加入到队列中。PrimaryPG模块可以根据请求所涉及的数据对象所在的PG（Placement Group，放置组），把请求从队列中取出，并基于相应的PG上下文进行处理。PG是一种逻辑单元组，每一个集群管理请求的数据对象都会被包含在一个PG中。示例性地，针对用于创建目标卷的卷创建请求，可以生成与目标卷对应的元数据对象，该元数据对象可以被包含在一个PG上，从而，对应的PrimaryPG模块（OSD进程813可以包括多个PrimaryPG模块，这将在后续附图中示出）可以将该卷创建请求从队列中取出，并基于相应的PG上下文对该卷创建请求进行处理。PG上下文可以包括处理该集群管理请求所需要的信息和/或资源，例如该PG中的数据对象所涉及的内部函数、变量等。基于相应的PG上下文对集群管理请求进行处理可以包括使用这些信息和/或资源来对集群管理请求进行处理。进而，PrimaryPG模块可以将取得的集群管理请求交由ProxyManager模块进行处理。ProxyManager模块可以根据集群管理请求的操作码来进行不同的处理。例如，针对创建卷请求，ProxyManager模块可以通过ProxyScheduler模块在多个后端存储集群中选择一个存储集群作为创建目标卷的目标存储集群，并可选地将该目标卷和目标存储集群的映射关系通过ProxyStore模块存入到诸如ETCD集群的映射存储集群中；针对数据读取请求或数据写入请求，则将当前挂载的卷所在的存储集群确定为目标存储集群，然后将相应操作请求发送到目标存储集群。ProxyStore模块可以用于诸如ETCD集群的映射存储集群进行交互，以读取或写入卷与存储集群的映射关系。ProxyScheduler模块可以用于卷创建请求的处理，其可以在多个存储集群中选择一个存储集群作为目标存储集群。示例性地，如前文所述及的，这种选择可以基于多个存储集群的容量信息和权重信息中的至少一种信息以及待创建的目标卷的卷信息来完成。ProxyClient模块可以作为代理集群和后端存储集群的通信模块，例如用于向后端存储集群发送操作请求、接收来自后端存储集群发送的反馈消息、向后端存储集群请求容量信息等。

下面将参考图9-图11并分别以卷创建请求、卷挂载请求、数据读写请求为例来详细描述代理集群对集群管理请求的具体处理过程。为便于描述，将基于图8所提供的迷你Ceph集群来描述这些处理过程。

图9示意性示出了基于图8所示的迷你Ceph集群处理卷创建请求的示例方案的架构900。

具体地，卷创建请求可以由Cinder组件发起。如图9所示，Cinder组件920可以调用其Ceph客户端921发起卷创建请求。首先，Ceph客户端921可以通过其内部的monc模块与迷你Ceph集群910的Mon进程911进行通信，以获取Monmap和OSDmap。示例性地，monc模块可以表示用于与Mon模块建立连接以获取Monmap和OSDmap的模块。随后，Ceph客户端921中的Objector模块可以通过诸如crush的算法定位到迷你Ceph集群中的OSD进程912，并向其发起卷创建请求。示例性地，发起卷创建请求可以包括向OSD进程912发送8个请求消息，这些请求消息包括例如创建卷头元数据、设置卷大小、设置卷特征（feature）等。OSD进程912的OSDserver模块在接收到请求之后，可以把请求加入到队列中。随后，OSD进程912中的PrimaryPG模块可以从队列中取出请求，然后交给ProxyManager模块进行处理。该过程已在前文中予以描述，在此不再赘述。在收到卷创建请求后，ProxyManager模块可以通过该请求中的8个请求消息收集待创建的目标卷的卷信息，卷信息可以包括卷的ID、名字、大小、特征等。当第8个请求消息被处理完毕时，可以准备向后端的Ceph存储集群发送相应的用于执行创建卷的管理操作的操作请求。此时，ProxyManager模块可以调用ProxyScheduler模块来在多个Ceph存储集群（例如图中所示的Ceph存储集群931、932及933）中选择一个目标Ceph存储集群，这种选择可以如前文所述地基于各Ceph存储集群的容量和/或权重信息来完成。在选出目标Ceph存储集群之后，可选地，ProxyManager可以调用ProxyStore模块来将目标卷和目标Ceph存储集群的映射关系存储到etcd集群中。最后，ProxyManager模块可以调用通过ProxyClient模块来向目标Ceph存储集群发送操作请求以及收集到的卷信息，以例如经由librbd模块指示在该目标Ceph存储集群（例如Ceph集群932）上创建目标卷。librbd模块用于提供RBD接口，以允许Ceph客户端对Ceph集群上的卷进行访问。可选地，可以经由其他模块来实现这种访问。

图10示意性示出了基于图8所示的迷你Ceph集群处理卷挂载请求的示例方案的架构1000。

具体地，卷挂载请求可以由Nova组件发起。如图10所示，计算节点1020上的Nova组件1021可以调用控制节点1010上的Cinder组件1011获取Monmap。Cinder组件1011可以通过其所包括Monc模块从对应的迷你Ceph集群1012的Mon进程获取Monmap，并随后将所获取的Monmap发送至Nova组件1021。在接收到Monmap后，Nova组件1021可以通过指示虚拟机1022使用该Monmap中的地址与相应Mon进程连接，以获取相应迷你Ceph集群的OSDmap。示例性地，Nova组件1021可以通过libvirt向虚拟机1022发送上述指示。libvirt是目前广泛使用的针对虚拟机进行管理的工具和API（应用程序接口），可以通过libvirt提供的API对虚拟机进行管理操作。可选地，也可以通过其他方式来发送上述指示。在如图所示的布置中，迷你Ceph集群1012、1023分别位于控制节点1010、计算节点1020上，其内部进程可以均绑定本地地址。因此，Cinder组件1011获取的Monmap中的Mon进程的地址可以为本地地址，而当虚拟机基于该Monmap中的Mon进程的地址访问Mon进程时，其将访问计算节点1020本地的迷你Ceph集群1023中的Mon进程。随后，虚拟机1022的Ceph客户端的Objector模块可以基于OSDmap定位至迷你Ceph集群1023中的OSD进程，并向其发送用于将目标卷挂载至虚拟机1022的卷挂载请求。示例性地，卷挂载请求可以包括13个请求消息。在接收到卷挂载请求后，迷你Ceph集群1023的OSD进程可以基于与关于图9描述的流程相似的流程处理卷挂载请求，区别主要在于在多个Ceph存储集群（例如图中所示的Ceph存储集群1031、1032及1033）中确定目标Ceph存储集群的方式。针对卷挂载请求，不需要调度ProxyScheduler模块来在多个Ceph存储集群中选择目标存储集群，而是需要调度ProxyStore模块读取之前存储的目标卷和Ceph存储集群的映射关系，并基于该映射关系确定目标Ceph存储集群。可选地，ProxyStore模块可以从诸如ETCD集群的映射存储集群获取该映射关系。最后，可以通过ProxyClient模块经由例如librbd模块从目标Ceph存储集群（例如Ceph存储集群1032）挂载目标卷。

图11示意性示出了基于图8所示的迷你Ceph集群处理数据读写请求的示例方案的架构1100。

具体地，卷挂载请求可以由虚拟机针对已挂载至该虚拟机的目标卷发起。虚拟机1110内部的Ceph客户端1111可以通过Monc模块以与关于图9描述的流程类似的流程从迷你Ceph集群1120中的Mon模块1121获取OSDmap，并定位至迷你Ceph集群1120中的OSD模块1122。随后，Ceph客户端1111可以通过objecter模块向OSD模块1122发送数据读写请求，即数据读取请求或数据写入请求。在接收到数据读写请求后，迷你Ceph集群1120的OSD进程1122可以基于与关于图9描述的流程相似的流程处理数据读写请求，区别主要在于在多个Ceph存储集群（例如图中所示的Ceph存储集群1131、1132及1133）中确定目标Ceph存储集群的方式。针对数据读写请求，既不需要调度ProxyScheduler模块来在多个Ceph存储集群中选择目标存储集群，也不需要调度ProxyStore模块读取之前存储的目标卷和Ceph存储集群的映射关系，而是可以将当前挂载的目标卷所在的Ceph存储集群确定为目标Ceph存储集群，然后将ProxyManager模块收集的读写数据信息发送至目标Ceph存储集群（例如Ceph存储集群1132）以进行读写操作。

根据关于图9-图11所描述的流程，本领域技术人员可以理解，其他类型的集群管理请求也可以类似地实现。

图12示意性示出了根据本申请实施例的多集群管理装置1200的示例框图。

多集群管理装置1200可以用于分布式存储系统。该分布式存储系统可以包括多个存储集群、至少一个管理节点和至少一个多集群管理装置1200，其中，至少一个管理节点与至少一个多集群管理装置1200是一一对应的，至少一个多集群管理装置1200中的每个多集群管理装置1200与多个存储集群可通信地耦合。每个多集群管理装置1200可以包括接收模块1210、确定模块1220以及发送模块1230。

具体而言，接收模块1210可以被配置为接收来自对应管理节点的集群管理请求，集群管理请求用于对存储集群执行管理操作；确定模块1220可以被配置为基于集群管理请求，在多个存储集群中确定目标存储集群；发送模块1230可以被配置为向目标存储集群发送与集群管理请求相对应的操作请求，以对目标存储集群执行上述管理操作。

多集群管理装置1200可以部署在图1所示的服务器110上。应理解，多集群管理装置1200可以以软件、硬件或软硬件相结合的方式实现。多个不同模块可以在同一软件或硬件结构中实现，或者一个模块可以由多个不同的软件或硬件结构实现。

此外，多集群管理装置1200可以用于实施前文所描述的多集群管理方法，其相关细节已经在前文中详细描述，为简洁起见，在此不再重复。多集群管理装置1200可以具有与关于前述多集群管理方法描述的相同的特征和优势。

图13示意性示出了根据本申请实施例的计算设备1300的示例框图，例如其可以代表图1中的服务器110或可以用于部署本申请提供的多集群管理装置的其他类型的计算设备。

如图所示，示例计算设备1300包括彼此通信耦合的处理系统1301、一个或多个计算机可读介质1302以及一个或多个I/O接口1303。尽管未示出，但是计算设备1300还可以包括将各种组件彼此耦合的系统总线或其他数据和命令传送系统。系统总线可以包括不同总线结构的任何一个或组合，所述总线结构可以是诸如存储器总线或存储器控制器、外围总线、通用串行总线和/或利用各种总线架构中的任何一种的处理器或局部总线，或者还可以包括诸如控制和数据线。

处理系统1301代表使用硬件执行一个或多个操作的功能。因此，处理系统1301被图示为包括可被配置为处理器、功能块等的硬件元件1304。这可以包括在硬件中实现专用集成电路或使用一个或多个半导体形成的其它逻辑器件。硬件元件1304不受其形成材料或其中采用的处理机构的限制。例如，处理器可以由（多个）半导体和/或晶体管（例如，电子集成电路（IC））组成。在这样的上下文中，处理器可执行指令可以是电子可执行指令。

计算机可读介质1302被图示为包括存储器/存储装置1305。存储器/存储装置1305表示与一个或多个计算机可读介质相关联的存储器/存储装置。存储器/存储装置1305可以包括易失性存储介质（诸如随机存取存储器（RAM））和/或非易失性存储介质（诸如只读存储器（ROM）、闪存、光盘、磁盘等）。存储器/存储装置1305可以包括固定介质（例如，RAM、ROM、固定硬盘驱动器等）以及可移动介质（例如，闪存、可移动硬盘驱动器、光盘等）。示例性地，存储器/存储装置1305可以用于存储上文实施例中提及的各种集群管理请求以及所涉及的数据对象等。计算机可读介质1302可以以下面进一步描述的各种其他方式进行配置。

一个或多个输入/输出接口1303代表允许用户向计算设备1300键入命令和信息并且还允许使用各种输入/输出设备将信息呈现给用户和/或发送给其他组件或设备的功能。输入设备的示例包括键盘、光标控制设备（例如，鼠标）、麦克风（例如，用于语音输入）、扫描仪、触摸功能（例如，被配置为检测物理触摸的容性或其他传感器）、相机（例如，可以采用可见或不可见的波长（诸如红外频率）将不涉及触摸的运动检测为手势）、网卡、接收机等等。输出设备的示例包括显示设备（例如，监视器或投影仪）、扬声器、打印机、触觉响应设备、网卡、发射机等。示例性地，在上文描述的实施例中，可以通过输入设备接收用户输入、原始图像或初始控制点等，可以通过输出设备呈现期望控制点等。

计算设备1300还包括多集群管理应用1306。多集群管理应用1306可以作为计算程序指令存储在存储器/存储装置1305中。多集群管理应用1306可以连同处理系统1301等一起实现关于图12描述的多集群管理装置1200的各个模块的全部功能。

本文可以在软件、硬件、元件或程序模块的一般上下文中描述各种技术。一般地，这些模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、元素、组件、数据结构等。本文所使用的术语“模块”、“功能”等一般表示软件、固件、硬件或其组合。本文描述的技术的特征是与平台无关的，意味着这些技术可以在具有各种处理器的各种计算平台上实现。

所描述的模块和技术的实现可以存储在某种形式的计算机可读介质上或者跨某种形式的计算机可读介质传输。计算机可读介质可以包括可由计算设备1300访问的各种介质。作为示例而非限制，计算机可读介质可以包括“计算机可读存储介质”和“计算机可读信号介质”。

与单纯的信号传输、载波或信号本身相反，“计算机可读存储介质”是指能够持久存储信息的介质和/或设备，和/或有形的存储装置。因此，计算机可读存储介质是指非信号承载介质。计算机可读存储介质包括诸如易失性和非易失性、可移动和不可移动介质和/或以适用于存储信息（诸如计算机可读指令、数据结构、程序模块、逻辑元件/电路或其他数据）的方法或技术实现的存储设备之类的硬件。计算机可读存储介质的示例可以包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字通用盘（DVD）或其他光学存储装置、硬盘、盒式磁带、磁带，磁盘存储装置或其他磁存储设备，或其他存储设备、有形介质或适于存储期望信息并可以由计算机访问的制品。

“计算机可读信号介质”是指被配置为诸如经由网络将指令发送到计算设备1300的硬件的信号承载介质。信号介质典型地可以将计算机可读指令、数据结构、程序模块或其他数据体现在诸如载波、数据信号或其它传输机制的调制数据信号中。信号介质还包括任何信息传递介质。作为示例而非限制，信号介质包括诸如有线网络或直接连线的有线介质以及诸如声、RF、红外和其它无线介质的无线介质。

如前所述，硬件元件1301和计算机可读介质1302代表以硬件形式实现的指令、模块、可编程器件逻辑和/或固定器件逻辑，其在一些实施例中可以用于实现本文描述的技术的至少一些方面。硬件元件可以包括集成电路或片上系统、专用集成电路（ASIC）、现场可编程门阵列（FPGA）、复杂可编程逻辑器件（CPLD）以及硅中的其它实现或其他硬件设备的组件。在这种上下文中，硬件元件可以作为执行由硬件元件所体现的指令、模块和/或逻辑所定义的程序任务的处理设备，以及用于存储用于执行的指令的硬件设备，例如，先前描述的计算机可读存储介质。

前述的组合也可以用于实现本文所述的各种技术和模块。因此，可以将软件、硬件或程序模块和其它程序模块实现为在某种形式的计算机可读存储介质上和/或由一个或多个硬件元件1301体现的一个或多个指令和/或逻辑。计算设备1300可以被配置为实现与软件和/或硬件模块相对应的特定指令和/或功能。因此，例如通过使用处理系统的计算机可读存储介质和/或硬件元件1301，可以至少部分地以硬件来实现将模块实现为可由计算设备1300作为软件执行的模块。指令和/或功能可以由例如一个或多个计算设备1300和/或处理系统1301执行/可操作以实现本文所述的技术、模块和示例。

本文描述的技术可以由计算设备1300的这些各种配置来支持，并且不限于本文所描述的技术的具体示例。

应当理解，为清楚起见，参考不同的功能单元对本公开的实施例进行了描述。然而，将明显的是，在不偏离本公开的情况下，每个功能单元的功能性可以被实施在单个单元中、实施在多个单元中或作为其它功能单元的一部分被实施。例如，被说明成由单个单元执行的功能性可以由多个不同的单元来执行。因此，对特定功能单元的参考仅被视为对用于提供所描述的功能性的适当单元的参考，而不是表明严格的逻辑或物理结构或组织。因此，本公开可以被实施在单个单元中，或者可以在物理上和功能上被分布在不同的单元和电路之间。

本申请提供了一种计算机可读存储介质，其上存储有计算机可读指令，计算机可读指令在被执行时实现上述的多集群管理方法。

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

通过研究附图、公开内容和所附的权利要求书，本领域技术人员在实践所要求保护的主题时，能够理解和实现对于所公开的实施例的变型。在权利要求书中，词语“包括”不排除其他元件或步骤，并且“一”或“一个”不排除多个。在相互不同的从属权利要求中记载某些措施的纯粹事实并不表明这些措施的组合不能用来获利。

Claims (14)

1.一种基于分布式存储系统的多集群管理方法，其中，所述分布式存储系统包括多个存储集群、至少一个管理节点和至少一个代理集群，所述至少一个管理节点与所述至少一个代理集群是一一对应的，所述至少一个代理集群中的每个代理集群与所述多个存储集群可通信地耦合，所述方法应用于所述每个代理集群并包括：

接收来自对应管理节点的集群管理请求，所述集群管理请求用于请求针对存储集群执行管理操作；

基于所述集群管理请求，在所述多个存储集群中确定目标存储集群；

向所述目标存储集群发送操作请求，以请求对所述目标存储集群执行所述管理操作。

2.根据权利要求1所述的方法，其中，所述集群管理请求包括卷创建请求，所述卷创建请求包括待创建的目标卷的卷信息，并且其中，

所述基于所述集群管理请求，在所述多个存储集群中确定目标存储集群包括：

根据所述多个存储集群的容量信息和对应的预配置权重信息中的至少一种信息、所述卷创建请求中包括的目标卷的卷信息，在所述多个存储集群中选择目标存储集群，其中，预配置权重信息表征对应的存储集群被选中的概率。

3.根据权利要求1所述的方法，其中，所述集群管理请求包括以下中的相应一个请求：包括待删除的目标卷的卷信息的卷删除请求、包括待修改的目标卷的卷信息的卷修改请求、包括待查询的目标卷的卷信息的卷查询请求和包括待挂载的目标卷的卷信息的卷挂载请求，并且其中，

所述基于所述集群管理请求，在所述多个存储集群中确定目标存储集群包括：

根据所述相应一个请求中包括的目标卷的卷信息，获取所述目标卷与存储集群的映射关系；

将所获取的映射关系中的存储集群确定为所述目标存储集群。

4.根据权利要求1所述的方法，其中，所述集群管理请求包括以下中的相应一个请求：用于将已挂载的卷卸载的卷卸载请求、用于从已挂载的卷读取数据的数据读取请求和用于向已挂载的卷写入数据的数据写入请求，并且其中，

所述基于所述集群管理请求，在所述多个存储集群中确定目标存储集群包括：

将当前已挂载的卷所处于的存储集群确定为目标存储集群。

5. 根据权利要求1-3中任一项所述的方法，其中，所述分布式存储系统还包括映射存储集群，所述映射存储集群被配置为存储卷与存储集群的映射关系，并且其中，所述方法还包括以下中的至少一项：

向所述映射存储集群发送所述集群管理请求所针对的目标卷与目标存储集群的映射关系；以及

从所述映射存储集群接收所述集群管理请求所针对的目标卷与目标存储集群的映射关系。

6.根据权利要求1-4中任一项所述的方法，其中，所述至少一个管理节点中的每个管理节点包括管理客户端，所述管理客户端被配置为与对应代理集群通信，并且其中，

所述接收来自对应管理节点的集群管理请求包括：

接收来自对应管理节点的管理客户端的集群管理请求。

7.根据权利要求6所述的方法，其中，所述代理节点包括用于维护代理集群内的进程信息的集群管理进程和用于处理集群管理请求的请求管理进程，并且其中，所述接收来自对应管理节点的管理客户端的集群管理请求包括：

基于所述管理客户端对与请求管理进程相关的信息的请求，由所述集群管理进程向所述管理客户端发送与所述请求管理进程相关的信息；

接收定位指示，所述定位指示是由所述管理客户端基于与所述请求管理进程相关的信息生成的，并用于指示代理集群内部的用于接收所述集群管理请求的请求管理进程；

由所指示的请求管理进程接收所述集群管理请求以进行处理。

8.根据权利要求1所述的方法，其中，所述基于所述集群管理请求，在所述多个存储集群中确定目标存储集群包括：

将所接收的集群管理请求加入请求队列；

从所述请求队列中依次获取各集群管理请求，并根据所获取的集群管理请求所包括的操作码对所述获取的集群管理请求的参数进行相应处理，以收集与所述管理操作有关的信息，并通过与所述操作码对应的方式确定所述目标存储集群。

9.根据权利要求1-4中任一项所述的方法，其中，所述至少一个代理集群中的每个代理集群位于对应管理节点上，并且其中，所述接收来自对应管理节点的集群管理请求包括：

接收对应管理节点的本地的集群管理请求。

10.根据权利要求1-4中任一项所述的方法，还包括：

接收来自所述目标存储集群的针对所述操作请求的反馈消息，所述反馈消息用于指示所述管理操作的执行结果；

向对应管理节点转发所述反馈消息。

11.根据权利要求1-4中任一项所述的方法，还包括：

向所述多个存储集群中的至少一个存储集群请求容量信息；

接收由所述至少一个存储集群上报的容量信息。

12.一种用于分布式存储系统的多集群管理装置，其中，所述分布式存储系统包括多个存储集群、至少一个管理节点和至少一个多集群管理装置，所述至少一个管理节点与所述至少一个多集群管理装置是一一对应的，所述至少一个多集群管理装置中的每个多集群管理装置与所述多个存储集群可通信地耦合，所述多集群管理装置包括：

接收模块，被配置为接收来自对应管理节点的集群管理请求，所述集群管理请求用于对存储集群执行管理操作；

确定模块，被配置为基于所述集群管理请求，在所述多个存储集群中确定目标存储集群；

发送模块，被配置为向所述目标存储集群发送与所述集群管理请求相对应的操作请求，以对所述目标存储集群执行所述管理操作。

13.一种计算设备，包括

存储器，其被配置成存储计算机可执行指令；

处理器，其被配置成当所述计算机可执行指令被处理器执行时执行如权利要求1-11中的任一项所述的方法。

14.一种计算机可读存储介质，其存储有计算机可执行指令，当所述计算机可执行指令被执行时，执行如权利要求1-11中的任一项所述的方法。

Images