运维管控方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，具体涉及一种运维管控方法、装置、电子设备及存储介质。

背景技术

在分布式存储系统中，因为上层应用业务场景的不断变化以及底层硬件的不断更替，造成对于分布式存储系统的新需求层出不穷，在解决新需求的时候，一种常见的方式是通过新增加角色(server role)以解决新增的需求，但是这对分布式存储管控系统造成了绝大的挑战。因为之前管控节点是根据服务角色的逻辑特化指定的，例如对于chunkserver来说，下线的时候需要将其设置为“SHUTDOWN”来触发数据复制，在这种场景下，对于新增加的角色，管控节点需要知道其内部的逻辑以及状态变化关系，这种方式在角色不断暴增的场景下是不可持续的，会给管控节点造成大量的开发工作量。

发明内容

本公开实施例提供一种运维管控方法、装置、电子设备及计算机可读存储介质。

第一方面，本公开实施例中提供了一种运维管控方法，包括：

获取待执行的运维任务；其中，所述运维任务为目标管控角色上待执行的运维任务；

调用目标审批接口对所述运维任务进行审批；其中，所述目标审批接口用于负责审批所述运维任务这一类型的任务；

将所述目标审批接口的审批结果输出至运维管控中心，以便由所述运维管控中心根据所述审批结果执行所述运维任务。

进一步地，还包括：

接收添加目标管控角色的配置文件；其中，所述配置文件包括所述目标管控角色的设备信息；

将所述目标管控角色加入管控角色列表中。

进一步地，获取待执行的运维任务，包括：

从所述运维管控中心获取所述管控角色列表中至少一个管控角色上待执行的运维任务。

进一步地，调用目标审批接口对所述运维任务进行审批，包括：

确定所述运维任务的任务类型；

根据所述任务类型从多个预设审批接口中匹配得到所述目标审批接口。

第二方面，本公开实施例中提供了一种运维管控方法，包括：

接收待审批的运维任务；其中，所述运维任务为目标管控角色上待执行的运维任务；

获取所述运维任务对应的所述目标管控角色的审批信息；

根据所述审批信息对所述运维任务进行审批。

进一步地，获取所述运维任务对应的所述目标管控角色的审批信息，包括：

从所述目标管控角色的主角色获取所述目标管控角色的审批信息。

进一步地，从所述目标管控角色的主角色获取所述目标管控角色的审批信息，包括：

根据所述目标管控角色的配置文件确定所述主角色；

获取所述主角色对应的服务机器列表；

从所述服务机器列表中选择当前响应操作的目标服务机器；

从所述目标服务机器获取所述目标管控角色的审批信息。

进一步地，获取所述主角色对应的服务机器列表，包括以下至少之一：

从所述本地缓存获取所述服务机器列表；

从运维管控中心获取所述服务机器列表。

进一步地，从所述服务机器列表中选择当前响应操作的目标服务机器，包括：

按照所述服务机器列表中的记录顺序依次给服务机器发送询问请求；

根据所述询问请求确定所述目标服务机器。

第三方面，本公开实施例中提供了一种运维管控装置，包括：

第一获取模块，被配置为获取待执行的运维任务；其中，所述运维任务为目标管控角色上待执行的运维任务；

调用模块，被配置为调用目标审批接口对所述运维任务进行审批；其中，所述目标审批接口用于负责审批所述运维任务这一类型的任务；

输出模块，被配置为将所述目标审批接口的审批结果输出至运维管控中心，以便由所述运维管控中心根据所述审批结果执行所述运维任务。

进一步地，还包括：

第一接收模块，被配置为接收添加目标管控角色的配置文件；其中，所述配置文件包括所述目标管控角色的设备信息；

加入模块，被配置为将所述目标管控角色加入管控角色列表中。

进一步地，所述第一获取模块，包括：

第一获取子模块，被配置为从所述运维管控中心获取所述管控角色列表中至少一个管控角色上待执行的运维任务。

进一步地，所述调用模块，包括：

第一确定子模块，被配置为确定所述运维任务的任务类型；

匹配子模块，被配置为根据所述任务类型从多个预设审批接口中匹配得到所述目标审批接口。

第四方面，本公开实施例中提供了一种运维管控装置，包括：

第二接收模块，被配置为接收待审批的运维任务；其中，所述运维任务为目标管控角色上待执行的运维任务；

第二获取模块，被配置为获取所述运维任务对应的所述目标管控角色的审批信息；

审批模块，被配置为根据所述审批信息对所述运维任务进行审批。

进一步地，所述第二获取模块，包括：

第二获取子模块，被配置为从所述目标管控角色的主角色获取所述目标管控角色的审批信息。

进一步地，所述第二获取子模块，包括：

第二确定子模块，被配置为根据所述目标管控角色的配置文件确定所述主角色；

第三获取子模块，被配置为获取所述主角色对应的服务机器列表；

选择子模块，被配置为从所述服务机器列表中选择当前响应操作的目标服务机器；

第四获取子模块，被配置为从所述目标服务机器获取所述目标管控角色的审批信息。

进一步地，所述第三获取子模块，包括以下至少之一：

第五获取子模块，被配置为从所述本地缓存获取所述服务机器列表；

第六获取子模块，被配置为从运维管控中心获取所述服务机器列表。

进一步地，所述选择子模块，包括：

发送子模块，被配置为按照所述服务机器列表中的记录顺序依次给服务机器发送询问请求；

第二确定子模块，被配置为根据所述询问请求确定所述目标服务机器。

所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

在一个可能的设计中，运维管控装置的结构中包括存储器和处理器，所述存储器用于存储一条或多条支持运维管控装置执行上述第一方面或第二方面中所述方法的计算机指令，所述处理器被配置为用于执行所述存储器中存储的计算机指令。所述运维管控装置还可以包括通信接口，用于运维管控装置与其他设备或通信网络通信。

第五方面，本公开实施例提供了一种电子设备，包括存储器和处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现第一方面或第二方面所述的方法。

第六方面，本公开实施例提供了一种计算机可读存储介质，用于存储企业账户的安全认证装置所用的计算机指令，其包含用于执行上述第一方面或第二方面所述方法所涉及的计算机指令。

本公开实施例提供的技术方案可以包括以下有益效果：

本公开实施例，针对目标管控角色获取运维人员设置的运维任务，并调用与该运维任务相对应的目标审批接口对该运维任务进行审批，并将审批结果输出给运维管控中心，以便运维管控中心根据该审批结果执行该运维任务。通过本公开实施例的这种方式，可以预先将不同类型的运维任务的审批流程抽象成不同的通用审批接口，并在获取到待执行的运维任务之后，根据该运维任务的任务类型调用相对应的通用审批接口进行审批，运维中心根据通用审批接口的审批结果执行运维任务，因此运维管控中心无需感知目标管控角色内部逻辑以及状态信息，而是由通用审批接口与目标管控角色之间的交互来确定审批所需的信息，进而审批待执行运维任务，因此在角色内部逻辑发生变化时，管控节点无需进行适应性改变，减少了管控节点的开发工作量。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

结合附图，通过以下非限制性实施方式的详细描述，本公开的其它特征、目的和优点将变得更加明显。在附图中：

图1(a)-(c)示出根据本公开一实施方式的一种可配置扩展的分布式存储运维管控系统的结构框图；

图2示出根据本公开一实施方式的运维管控方法的流程图；

图3示出根据图2所示实施方式中添加新角色部分的流程图；

图4示出根据图2所示实施方式的步骤S202的流程图；

图5示出根据本公开另一实施方式的运维管控方法的流程图；

图6示出根据图5所示实施方式的审批信息获取部分的流程图；

图7示出根据图6所示实施方式的步骤S603的流程图；

图8示出根据本公开一实施方式的运维管控装置的结构框图；

图9示出根据图8所示实施方式中添加新角色部分的结构框图；

图10示出根据图8所示实施方式的调用模块802的结构框图；

图11示出根据本公开另一实施方式的运维管控装置的结构框图；

图12示出根据图11所示实施方式的审批信息获取部分的结构框图；

图13示出根据图12所示实施方式的选择子模块1203的结构框图；

图14是适于用来实现根据本公开一实施方式的运维管控方法的电子设备的结构示意图。

具体实施方式

下文中，将参考附图详细描述本公开的示例性实施方式，以使本领域技术人员可容易地实现它们。此外，为了清楚起见，在附图中省略了与描述示例性实施方式无关的部分。

在本公开中，应理解，诸如“包括”或“具有”等的术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在，并且不欲排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在或被添加的可能性。

另外还需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。

图1(a)-(c)示出根据本公开一实施方式的一种可配置扩展的分布式存储运维管控系统的结构框图。如图1(a)所示，该分布式存储运维管控系统包括：任务决策模块101、通用的审批接口102、管控角色管理模块103、任务监控模块104以及运维管控中心105。其中，

任务决策模块101、通用的审批接口102、管控角色管理模块103、任务监控模块104为部署在管控节点上的模块。

任务决策模块101从运维管控中心105获取运维任务，该运维任务可以由相关人员如运维人员通过运维管控中心105配置，用于在被管控节点所管控的角色上执行的相应的运维动作，该运维动作包括但不限于配置更新、磁盘上下线、机器上下线、软件版本热升级等。

在分布式存储运维管控系统中，被管控的不同角色在整个系统中所实现的功能不同，例如角色A用于对系统中相关数据进行快照存储，角色B用于对系统中相关数据进行备份等。一个角色可以通过主从设备(master-slave)模式来实现，也即同一个角色可以对应一个master设备和多个slave设备，主从设备同时并行运行组成了集群，Master作为任务调度者，给多个Slave分配计算任务，当所有的Slave将任务完成之后,最后由Master汇集结果。

通用的审批接口102可以包括多个，不同的审批接口102对应审批不同类型的运维任务。因此，任务决策模块101在获取到对应任何一个被管控角色的运维任务之后，可以根据该运维任务的类型将该角色的该运维任务分发给对应的审批接口102，由该对应的审批接口102进行审批。审批接口102在接收到运维任务的审批请求之后，可以根据审批所需的信息例如该角色当前的状态信息对该运维任务进行审批。由于不同运维任务的审批流程不同，因此不同审批接口的审批方式也不同，具体可以根据实际情况而定，本公开实施例对此不做限制。

审批接口102可以通过管控角色管理模块103从管控角色获取审批所需的信息。管控角色管理模块103在接收到审批接口102的信息获取请求之后，可以与对应的管控角色进行交互，并将审批所需的信息返回给审批接口。由于审批接口102包括多个，而每个审批接口102均需要从管控角色获取审批需要的信息，因此可以将与管控角色交互的执行逻辑抽象出来，形成管控角色管理模块103，使得每个审批接口102直接调用管控角色管理模块103与管控角色进行交互，而不需要在每个审批接口均中写入与管控角色交互的执行逻辑。

审批接口102根据审批所需的信息审批完成后，将审批结果返回给任务决策模块101，任务决策模块101则将该审批结果返回给运维管控中心105，运维管控中心105可以根据审批结果执行运维任务，例如审批结果为管控角色中对应的第一部分机器上可以执行运维任务，而剩余第二部分机器上不可以执行运维任务，则运维管控中心105则可以在第一部分机器上执行该运维任务。

任务监控模块104监控已经在审批的运维任务的审批过程；如果在审批过程中有超过预期的情况发生，则可以取消该任务的审批。

下面以一个salve角色“chunkserver”(简称cs)为例，介绍本公开实施例中的运维管控流程，其中，“chunkserver”对应的master角色为rootserver。

(一)运维任务为热升级，如图1(b)所示：

1、“task decider”(即任务决策模块101)将热升级任务分配给进行热升级的“common approver”(即通用审批接口102)；

2、“common approver”(即通用审批接口102)向“chunkserver”的master角色“root server”发送“QueryUpgradeableList”，期望获取角色“chunkserver”对应的所有可升级机器列表；

3、“root server”根据“chunkserver”的版本以及其他检查(例如“chunkserver”的状态信息等)选择可以安全升级的机器列表(如cs2和cs3)；

4、“common approver”(即通用审批接口102)向“task decider”(即任务决策模块101)返回可升级机器列表；

5、“task decider”(即任务决策模块)根据可升级机器列表控制运维管控中心每批升级的机器个数。

(二)运维任务为机器下线，如图1(c)所示：

1、“task decider”(即任务决策模块101)将机器下线任务分配给“commonapprover”(即通用审批接口102)；

2、“common approver”(即通用审批接口102)向“chunkserver”的master角色“root server”设置“SetDataBackup RPC”，以将对应“chunkserver”进行数据备份；

3、“root server”通过心跳获取“chunkserver”数据备份状态；

4、“common approver”(即通用审批接口102)通过“QueryDataBackupStatus”向“root server”查询“chunkserver”的数据备份情况；

5、数据备份完成后，“common approver”(即通用审批接口102)将审批结果返回“task decider”(即任务决策模块)。

图2示出根据本公开一实施方式的运维管控方法的流程图。如图2所示，所述运维管控方法用于在分布式存储管控系统中对多个管控角色进行运维管控，其包括以下步骤：

在步骤S201中，获取待执行的运维任务；其中，所述运维任务为分布式存储管控系统中针对目标管控角色待执行的运维任务；

在步骤S202中，调用目标审批接口对所述运维任务进行审批；其中，所述目标审批接口用于负责审批所述运维任务这一类型的任务；

在步骤S203中，将所述目标审批接口的审批结果输出至运维管控中心，以便由所述运维管控中心根据所述审批结果执行所述运维任务。

目前常见的分布式存储管控系统是基于角色的特定逻辑处理的，这种方法常见的缺点有以下几点：

1、管控节点的代码会随着管理角色的增多而不断增多，因为在新增加角色的时候，特化的管控系统必定需要加入特定的管控逻辑；

2、当被管控角色的逻辑发生变化的时候，管控系统也要同步的改变，例如原来角色甲需要通过设置状态A将数据进行复制，如果角色甲的逻辑发生变化，改变为设置状态B才能进行数据复制，这时候管控系统势必要进行改动。

上述两个缺点都限制了已有分布式存储管控系统的可扩展性。

因此，本实施例提出的运维管控方法中，通过一套通用的管控逻辑实现对被管控角色的运维管控。该运维管控方法中，管控节点可以实时或者定期从运维管控中心获取待执行的运维任务；根据该运维任务的任务类型调用相应的目标审批接口进行审批，其中目标审批接口为通用的、专门负责所有管控角色上同一类型的运维任务，例如通用的升级审批接口负责所配置的管控角色的软件升级任务。

本实施例中，可以预先配置多个目标审批接口，具体根据实际运维管控系统能够支持的运维任务的类型而定，不同类型的运维任务，其审批逻辑不同，因此可以对应不同的审批接口，而同一类型的运维任务其审批逻辑相同，则可以对应同一个审批接口。

目标审批接口可以根据运维任务对应的目标管控角色涉及的审批所需的信息对该运维任务进行审批，审批结果可以包括对应目标管控角色的哪些机器可以执行运维任务，哪些机器不可以执行等。由于不同类型的运维任务的审批逻辑有所不同，因此对应的审批结果也有所不同，具体可以根据实际情况而设定，本公开实施例的创新不在于运维任务的审批逻辑上，因此在此不做限制。

在目标审批接口审批结束之后，可以将目标审批接口的审批结果输出给运维管控中心，以便运维管控中心根据该审批结果执行运维任务。例如，运维管控中心可以根据审批结果对目标管控角色对应的一部分机器执行软件升级，而对另一部分机器不执行软件升级。

本公开实施例，针对目标管控角色获取运维人员设置的运维任务，并调用与该运维任务相对应的目标审批接口对该运维任务进行审批，并将审批结果输出给运维管控中心，以便运维管控中心根据该审批结果执行该运维任务。通过本公开实施例的这种方式，可以预先将不同类型的运维任务的审批流程抽象成不同的通用审批接口，并在获取到待执行的运维任务之后，根据该运维任务的任务类型调用相对应的通用审批接口进行审批，运维中心根据通用审批接口的审批结果执行运维任务，因此运维管控中心无需感知目标管控角色内部逻辑以及状态信息，而是由通用审批接口与目标管控角色之间的交互来确定审批所需的信息，进而审批待执行运维任务，因此在角色内部逻辑发生变化时，管控节点无需进行适应性改变，减少了管控节点的开发工作量。

在本实施例的一个可选实现方式中，如图3所示，所述方法进一步包括以下步骤：

在步骤S301中，接收添加目标管控角色的配置文件；其中，所述配置文件包括所述目标管控角色的设备信息；

在步骤S302中，将所述目标管控角色加入管控角色列表中。

该可选的实现方式中，运维人员在本实施例的管控节点中添加新角色时，只需要提供该新角色的配置文件，该配置文件中可以包括新添加角色的角色信息，该角色信息可以包括但不限于新添加角色的名称、通信端口以及对应的主角色等。在接收到该配置文件之后，可以将该新添加的管控角色添加到管控节点当前所管控的管控角色列表中，以便管控节点能够对该新添加的管控角色进行管控。管控节点实时或者定期从运维管控中心获取运维任务时，也将获取该新添加的管控角色上待执行的运维任务。

配置文件可以是运维人员配置并提供的，在接收到包括目标管控角色的名称、通信端口、主设备等信息的配置文件之后，意味着该目标管控角色归当前管控节点所管控，因此针对该目标管控角色所配置的运维任务也由当前管控节点审批处理。因此，运维管控中心中配置了针对该目标管控角色的运维任务之后，由管控节点从运维管控中心获取该运维任务，并将该运维任务分发到相应的审批接口进行审批，然后将审批结果返回给运维管控中心。通过本公开这种方式，运维人员只需要更新配置文件(对于新添加角色提供新添加角色配置文件)即可将需要添加的角色纳入通用的运维管控流程中，因此新角色加入不会增加管控节点的开发工作量。

在本实施例的一个可选实现方式中，所述步骤S201，即获取待执行的运维任务的步骤，进一步包括以下步骤：

从所述运维管控中心获取所述管控角色列表中至少一个管控角色上待执行的运维任务。

该可选的实现方式中，可以定期从运维管控中心获取管控角色列表中所有管控角色上待执行的运维任务，也可以在产生了要在管控角色列表中任意一个管控角色上待执行的运维任务之后，从运维管控中心获取该运维任务，具体可以根据实际情况进行设置，在此不做限制。通过这种方式，可以针对管控角色列表中所管控的所有角色定期或者实时审批待执行的运维任务，能够做到对所有被管控角色的及时管控。

在本实施例的一个可选实现方式中，如图4所示，所述步骤S202中，即调用目标审批接口对所述运维任务进行审批的步骤，进一步包括以下步骤：

在步骤S401中，确定所述运维任务的任务类型；

在步骤S402中，根据所述任务类型从多个预设审批接口中匹配得到所述目标审批接口。

该可选的实现方式中，在获取到被管控角色上待执行的运维任务之后，可以根据该运维任务的类型与预先设置好的多个审批接口进行匹配，并将调用与该运维任务相匹配的审批接口对该运维任务进行审批处理。如前所述，不同审批接口用于审批不同类型的运维任务，可以预先将预设审批接口与相对应的任务类型关联存储，之后可以根据该关联关系匹配得到与当前运维任务相匹配的目标审批接口。

图5示出根据本公开另一实施方式的运维管控方法的流程图。如图5所示，所述运维管控方法用于使用多个不同的审批接口对不同类型的运维任务进行审批，其中每个审批接口的审批过程包括以下步骤：

在步骤S501中，接收待审批的运维任务；其中，所述运维任务为目标管控角色上待执行的运维任务；

在步骤S502中，获取所述运维任务对应的所述目标管控角色的审批信息；

在步骤S503中，根据所述审批信息对所述运维任务进行审批。

本实施例中，审批接口可以是通过将不同类型的运维任务的审批逻辑进行抽象而得到的通用审批接口。一个审批接口实现一种审批逻辑，而由于不同类型的运维任务的审批逻辑不同，因此一种审批逻辑针对一种类型的运维任务。实际应用中，审批接口的数量与运维管控所支持的任务类型的数量相关，在此不做限制。在对管控角色进行管控的过程中，可以由图1所示的任务决策模块从运维管控中心获取待执行的运维任务，并发送给相应的审批接口。审批接口在接收到运维任务的审批请求之后，可以根据审批所需的信息例如该角色当前的状态信息审批该运维任务。

审批接口可以通过管控角色管理模块从管控角色获取审批所需的信息。管控角色管理模块通过与对应的管控角色进行交互获得审批所需的信息，并返回给审批接口。

审批接口根据审批所需的信息完成审批后，将审批结果返回给任务决策模块，并由任务决策模块返回给运维管控中心。运维管控中心可以根据审批结果执行运维任务。

本实施例中的运维管控细节还可以参见上述图1所示实施例中运维管控系统、图2所示实施例以及相关实施例中运维管控方法的描述，在此不再赘述。

本公开实施例在运维管控过程中，利用通用的审批接口对运维任务进行审批，并且在审批完成后将审批结果返回给运维管控中心，由运维管控中心执行运维任务。这种方式使得管控节点无需感知目标管控角色内部逻辑以及状态信息，而是由通用的目标审批接口负责从目标管控角色获取审批所需的信息，进而审批待执行运维任务，因此在角色内部逻辑发生变化时，管控节点无需进行适应性改变，减少了管控侧的开发工作量。

在本实施例的一个可选实现方式中，所述步骤S502中，即获取所述运维任务对应的所述目标管控角色的审批信息的步骤，进一步包括以下步骤：

从所述目标管控角色的主角色获取所述目标管控角色的审批信息。

该可选的实现方式中，由于在主从模式下，从角色的所有信息都可以从主角色获取，而且主角色上的信息更加全面，且主角色的服务更稳定，因此审批接口在审批目标管控角色上待执行的运维任务时，可以从该目标管控角色的主角色获取审批所需要的信息，如目标管控角色的状态信息。可以理解的是，目标管控角色本身就是主角色的情况下，可以直接从目标管控角色获取审批所需的信息。

在本实施例的一个可选实现方式中，如图6所示，从所述目标管控角色的主角色获取所述目标管控角色的审批信息的步骤，进一步包括以下步骤：

在步骤S601中，根据所述目标管控角色的配置文件确定所述主角色；

在步骤S602中，获取所述主角色对应的服务机器列表；

在步骤S603中，从所述服务机器列表中选择当前响应操作的目标服务机器；

在步骤S604中，从所述目标服务机器获取所述目标管控角色的审批信息。

该可选的实现方式中，配置文件为用户添加目标管控角色时所配置的文件，所述配置文件中包括目标管控角色的信息，可以包括但不限于角色名称、通信端口以及对应的主角色，如果配置文件中主角色为空，则该目标管控角色本身就是主角色，而不是从角色。

为了防止主角色发生故障而不能响应操作，主角色可以对应多个服务机器，并且每一时刻只有其中一个服务机器响应对主角色的操作，而其他服务机器为冗余机器，只有在响应操作的服务机器出现故障，无法正常运行时，从该当前响应操作的服务机器切换到另一个服务机器。因此，在确定了主角色之后，可以从主角色对应的服务机器列表中找到当前响应操作的服务机器，并从该当前响应操作的服务机器获取目标管控角色的审批信息。

在本实施例的一个可选实现方式中，所述步骤S602中，即获取所述主角色对应的服务机器列表的步骤，进一步包括以下步骤中的至少之一：

从所述本地缓存获取所述服务机器列表；

从运维管控中心获取所述服务机器列表。

该可选的实现方式中，每个机器都可以在本地缓存各个不同角色对应的机器列表；而运维管控中心也可以保存各个不同角色对应的机器列表。因此，为了能够准确定位当前响应对主角色操作的目标服务机器，可以从本地缓存也即管控节点的本地缓存获取主角色对应的服务机器列表。该服务机器列表中按顺序记录了所有服务机器的设备信息。通常情况下，服务机器列表中的第一个为当前响应操作的目标服务机器。如果本地缓存中没有该服务机器列表，还可以从运维管控中心获取该服务机器列表。本公开实施例的这种方式，通过本地缓存或者运维管控中心，能够确保在正常的运维环境下，始终都能够找到当前响应操作的主角色的目标服务机器。

在本实施例的一个可选实现方式中，如图7所示，所述步骤S603中，即从所述服务机器列表中选择当前响应操作的目标服务机器的步骤，进一步包括以下步骤：

在步骤S701中，按照所述服务机器列表中的记录顺序依次给服务机器发送询问请求；

在步骤S702中，根据所述询问请求确定所述目标服务机器。

该可选的实现方式中，如上所述，服务机器列表中按顺序记录了相应角色对应的当前响应操作的服务机器和其他备用的服务机器的设备信息。通常情况下服务机器列表中记录的第一个设备信息就是当前响应操作的服务机器，但是在发生了故障或其他意外的情况下，如果进行过机器切换，则第一个可能不是当前响应操作的服务机器。因此，本实施例中可以按照服务机器列表中的记录顺序依次给其中的服务机器发送询问请求，只有当前响应操作的服务机器才能够响应该询问请求，因此在接收到回复消息时，可以将回复消息的服务机器确定位目标服务机器。

在一些实施例中，在确定了目标服务机器的情况下，还可以从目标服务机器获取新的服务机器列表(该服务机器列表中第一条记录为该目标服务机器)，并且将该新的服务机器列表缓存起来，同时还可以同步到其他机器和运维管控中心。

在一些实施例中，依次询问了机器服务列表中所有服务机器的情况下，依然没有收到目标服务机器的回复消息时，则还可以进行重试，直到收到目标服务机器的回复为止。

下述为本公开装置实施例，可以用于执行本公开方法实施例。

图8示出根据本公开一实施方式的运维管控装置的结构框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图8所示，所述运维管控装置包括：

第一获取模块801，被配置为获取待执行的运维任务；其中，所述运维任务为目标管控角色上待执行的运维任务；

调用模块802，被配置为调用目标审批接口对所述运维任务进行审批；其中，所述目标审批接口用于负责审批所述运维任务这一类型的任务；

输出模块803，被配置为将所述目标审批接口的审批结果输出至运维管控中心，以便由所述运维管控中心根据所述审批结果执行所述运维任务。

目前常见的分布式存储管控系统是基于角色的特定逻辑处理的，这种方法常见的缺点有以下几点：

1、管控节点的代码会随着管理角色的增多而不断增多，因为在新增加角色的时候，特化的管控系统必定需要加入特定的管控逻辑；

2、当被管控角色的逻辑发生变化的时候，管控系统也要同步的改变，例如原来角色甲需要通过设置状态A将数据进行复制，如果角色甲的逻辑发生变化，改变为设置状态B才能进行数据复制，这时候管控系统势必要进行改动。

上述两个缺点都限制了已有分布式存储管控系统的可扩展性。

因此，本实施例提出的运维管控装置中，通过一套通用的管控逻辑实现对被管控角色的运维管控。该运维管控装置中，管控节点可以实时或者定期从运维管控中心获取待执行的运维任务；根据该运维任务的任务类型调用相应的目标审批接口进行审批，其中目标审批接口为通用的、专门负责所有管控角色上同一类型的运维任务，例如通用的升级审批接口负责所配置的管控角色的软件升级任务。

本实施例中，可以预先配置多个目标审批接口，具体根据实际运维管控系统能够支持的运维任务的类型而定，不同类型的运维任务，其审批逻辑不同，因此可以对应不同的审批接口，而同一类型的运维任务其审批逻辑相同，则可以对应同一个审批接口。

目标审批接口可以根据运维任务对应的目标管控角色涉及的审批所需的信息对该运维任务进行审批，审批结果可以包括对应目标管控角色的哪些机器可以执行运维任务，哪些机器不可以执行等。由于不同类型的运维任务的审批逻辑有所不同，因此对应的审批结果也有所不同，具体可以根据实际情况而设定，本公开实施例的创新不在于运维任务的审批逻辑上，因此在此不做限制。

在目标审批接口审批结束之后，可以将目标审批接口的审批结果输出给运维管控中心，以便运维管控中心根据该审批结果执行运维任务。例如，运维管控中心可以根据审批结果对目标管控角色对应的一部分机器执行软件升级，而对另一部分机器不执行软件升级。

本公开实施例，针对目标管控角色获取运维人员设置的运维任务，并调用与该运维任务相对应的目标审批接口对该运维任务进行审批，并将审批结果输出给运维管控中心，以便运维管控中心根据该审批结果执行该运维任务。通过本公开实施例的这种方式，可以预先将不同类型的运维任务的审批流程抽象成不同的通用审批接口，并在获取到待执行的运维任务之后，根据该运维任务的任务类型调用相对应的通用审批接口进行审批，运维中心根据通用审批接口的审批结果执行运维任务，因此运维管控中心无需感知目标管控角色内部逻辑以及状态信息，而是由通用审批接口与目标管控角色之间的交互来确定审批所需的信息，进而审批待执行运维任务，因此在角色内部逻辑发生变化时，管控节点无需进行适应性改变，减少了管控节点的开发工作量。

在本实施例的一个可选实现方式中，如图9所示，所述装置进一步包括：

第一接收模块901，被配置为接收添加目标管控角色的配置文件；其中，所述配置文件包括所述目标管控角色的设备信息；

加入模块902，被配置为将所述目标管控角色加入管控角色列表中。

该可选的实现方式中，运维人员在本实施例的管控节点中添加新角色时，只需要提供该新角色的配置文件，该配置文件中可以包括新添加角色的角色信息，该角色信息可以包括但不限于新添加角色的名称、通信端口以及对应的主角色等。在接收到该配置文件之后，可以将该新添加的管控角色添加到管控节点当前所管控的管控角色列表中，以便管控节点能够对该新添加的管控角色进行管控。管控节点实时或者定期从运维管控中心获取运维任务时，也将获取该新添加的管控角色上待执行的运维任务。

配置文件可以是运维人员配置并提供的，在接收到包括目标管控角色的名称、通信端口、主设备等信息的配置文件之后，意味着该目标管控角色归当前管控节点所管控，因此针对该目标管控角色所配置的运维任务也由当前管控节点审批处理。因此，运维管控中心中配置了针对该目标管控角色的运维任务之后，由管控节点从运维管控中心获取该运维任务，并将该运维任务分发到相应的审批接口进行审批，然后将审批结果返回给运维管控中心。通过本公开这种方式，运维人员只需要更新配置文件(对于新添加角色提供新添加角色配置文件)即可将需要添加的角色纳入通用的运维管控流程中，因此新角色加入不会增加管控节点的开发工作量。

在本实施例的一个可选实现方式中，所述第一获取模块801，包括：

第一获取子模块，被配置为从所述运维管控中心获取所述管控角色列表中至少一个管控角色上待执行的运维任务。

该可选的实现方式中，可以定期从运维管控中心获取管控角色列表中所有管控角色上待执行的运维任务，也可以在产生了要在管控角色列表中任意一个管控角色上待执行的运维任务之后，从运维管控中心获取该运维任务，具体可以根据实际情况进行设置，在此不做限制。通过这种方式，可以针对管控角色列表中所管控的所有角色定期或者实时审批待执行的运维任务，能够做到对所有被管控角色的及时管控。

在本实施例的一个可选实现方式中，如图10所示，所述调用模块802，包括：

第一确定子模块1001，被配置为确定所述运维任务的任务类型；

匹配子模块1002，被配置为根据所述任务类型从多个预设审批接口中匹配得到所述目标审批接口。

该可选的实现方式中，在获取到被管控角色上待执行的运维任务之后，可以根据该运维任务的类型与预先设置好的多个审批接口进行匹配，并将调用与该运维任务相匹配的审批接口对该运维任务进行审批处理。如前所述，不同审批接口用于审批不同类型的运维任务，可以预先将预设审批接口与相对应的任务类型关联存储，之后可以根据该关联关系匹配得到与当前运维任务相匹配的目标审批接口。

图11示出根据本公开一实施方式的运维管控装置的结构框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图11所示，所述运维管控装置包括：

第二接收模块1101，被配置为接收待审批的运维任务；其中，所述运维任务为目标管控角色上待执行的运维任务；

第二获取模块1102，被配置为获取所述运维任务对应的所述目标管控角色的审批信息；

审批模块1103，被配置为根据所述审批信息对所述运维任务进行审批。

本实施例中，审批接口可以是通过将不同类型的运维任务的审批逻辑进行抽象而得到的通用审批接口。一个审批接口实现一种审批逻辑，而由于不同类型的运维任务的审批逻辑不同，因此一种审批逻辑针对一种类型的运维任务。实际应用中，审批接口的数量与运维管控所支持的任务类型的数量相关，在此不做限制。在对管控角色进行管控的过程中，可以由图1所示的任务决策模块从运维管控中心获取待执行的运维任务，并发送给相应的审批接口。审批接口在接收到运维任务的审批请求之后，可以根据审批所需的信息例如该角色当前的状态信息审批该运维任务。

审批接口可以通过管控角色管理模块从管控角色获取审批所需的信息。管控角色管理模块通过与对应的管控角色进行交互获得审批所需的信息，并返回给审批接口。

审批接口根据审批所需的信息完成审批后，将审批结果返回给任务决策模块，并由任务决策模块返回给运维管控中心。运维管控中心可以根据审批结果执行运维任务。

本实施例中的运维管控细节还可以参见上述图1所示实施例中运维管控系统、图8所示实施例以及相关实施例中运维管控装置的描述，在此不再赘述。

本公开实施例在运维管控过程中，利用通用的审批接口对运维任务进行审批，并且在审批完成后将审批结果返回给运维管控中心，由运维管控中心执行运维任务。这种方式使得管控节点无需感知目标管控角色内部逻辑以及状态信息，而是由通用的目标审批接口负责从目标管控角色获取审批所需的信息，进而审批待执行运维任务，因此在角色内部逻辑发生变化时，管控节点无需进行适应性改变，减少了管控侧的开发工作量。

在本实施例的一个可选实现方式中，所述第二获取模块1102，包括：

第二获取子模块，被配置为从所述目标管控角色的主角色获取所述目标管控角色的审批信息。

该可选的实现方式中，由于在主从模式下，从角色的所有信息都可以从主角色获取，而且主角色上的信息更加全面，且主角色的服务更稳定，因此审批接口在审批目标管控角色上待执行的运维任务时，可以从该目标管控角色的主角色获取审批所需要的信息，如目标管控角色的状态信息。可以理解的是，目标管控角色本身就是主角色的情况下，可以直接从目标管控角色获取审批所需的信息。

在本实施例的一个可选实现方式中，如图12所示，所述第二获取子模块，包括：

第二确定子模块1201，被配置为根据所述目标管控角色的配置文件确定所述主角色；

第三获取子模块1202，被配置为获取所述主角色对应的服务机器列表；

选择子模块1203，被配置为从所述服务机器列表中选择当前响应操作的目标服务机器；

第四获取子模块1204，被配置为从所述目标服务机器获取所述目标管控角色的审批信息。

该可选的实现方式中，配置文件为用户添加目标管控角色时所配置的文件，所述配置文件中包括目标管控角色的信息，可以包括但不限于角色名称、通信端口以及对应的主角色，如果配置文件中主角色为空，则该目标管控角色本身就是主角色，而不是从角色。

为了防止主角色发生故障而不能响应操作，主角色可以对应多个服务机器，并且每一时刻只有其中一个服务机器响应对主角色的操作，而其他服务机器为冗余机器，只有在响应操作的服务机器出现故障，无法正常运行时，从该当前响应操作的服务机器切换到另一个服务机器。因此，在确定了主角色之后，可以从主角色对应的服务机器列表中找到当前响应操作的服务机器，并从该当前响应操作的服务机器获取目标管控角色的审批信息。

在本实施例的一个可选实现方式中，所述第三获取子模块1202，包括以下至少之一：

第五获取子模块，被配置为从所述本地缓存获取所述服务机器列表；

第六获取子模块，被配置为从运维管控中心获取所述服务机器列表。

该可选的实现方式中，每个机器都可以在本地缓存各个不同角色对应的机器列表；而运维管控中心也可以保存各个不同角色对应的机器列表。因此，为了能够准确定位当前响应对主角色操作的目标服务机器，可以从本地缓存也即管控节点的本地缓存获取主角色对应的服务机器列表。该服务机器列表中按顺序记录了所有服务机器的设备信息。通常情况下，服务机器列表中的第一个为当前响应操作的目标服务机器。如果本地缓存中没有该服务机器列表，还可以从运维管控中心获取该服务机器列表。本公开实施例的这种方式，通过本地缓存或者运维管控中心，能够确保在正常的运维环境下，始终都能够找到当前响应操作的主角色的目标服务机器。

在本实施例的一个可选实现方式中，如图13所示，所述选择子模块1203，包括：

发送子模块1301，被配置为按照所述服务机器列表中的记录顺序依次给服务机器发送询问请求；

第二确定子模块1302，被配置为根据所述询问请求确定所述目标服务机器。

该可选的实现方式中，如上所述，服务机器列表中按顺序记录了相应角色对应的当前响应操作的服务机器和其他备用的服务机器的设备信息。通常情况下服务机器列表中记录的第一个设备信息就是当前响应操作的服务机器，但是在发生了故障或其他意外的情况下，如果进行过机器切换，则第一个可能不是当前响应操作的服务机器。因此，本实施例中可以按照服务机器列表中的记录顺序依次给其中的服务机器发送询问请求，只有当前响应操作的服务机器才能够响应该询问请求，因此在接收到回复消息时，可以将回复消息的服务机器确定位目标服务机器。

在一些实施例中，在确定了目标服务机器的情况下，还可以从目标服务机器获取新的服务机器列表(该服务机器列表中第一条记录为该目标服务机器)，并且将该新的服务机器列表缓存起来，同时还可以同步到其他机器和运维管控中心。

在一些实施例中，依次询问了机器服务列表中所有服务机器的情况下，依然没有收到目标服务机器的回复消息时，则还可以进行重试，直到收到目标服务机器的回复为止。

图14是适于用来实现根据本公开实施方式的运维管控方法的电子设备的结构示意图。

如图14所示，电子设备1400包括中央处理单元(CPU)1401，其可以根据存储在只读存储器(ROM)1402中的程序或者从存储部分1408加载到随机访问存储器(RAM)1403中的程序而执行本公开上述方法的实施方式中的各种处理。在RAM1403中，还存储有电子设备1400操作所需的各种程序和数据。CPU1401、ROM1402以及RAM1403通过总线1404彼此相连。输入/输出(I/O)接口1405也连接至总线1404。

以下部件连接至I/O接口1405：包括键盘、鼠标等的输入部分1406；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1407；包括硬盘等的存储部分1408；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1409。通信部分1409经由诸如因特网的网络执行通信处理。驱动器1410也根据需要连接至I/O接口1405。可拆卸介质1411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1410上，以便于从其上读出的计算机程序根据需要被安装入存储部分1408。

特别地，根据本公开的实施方式，上文参考本公开实施方式中的方法可以被实现为计算机软件程序。例如，本公开的实施方式包括一种计算机程序产品，其包括有形地包含在及其可读介质上的计算机程序，所述计算机程序包含用于执行本公开实施方式中方法的程序代码。在这样的实施方式中，该计算机程序可以通过通信部分1409从网络上被下载和安装，和/或从可拆卸介质1411被安装。

附图中的流程图和框图，图示了按照本公开各种实施方式的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，路程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施方式中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。

作为另一方面，本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施方式中所述装置中所包含的计算机可读存储介质；也可以是单独存在，未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序，所述程序被一个或者一个以上的处理器用来执行描述于本公开的方法。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。