CN113296792B - 存储方法、装置、设备、存储介质和系统 - Google Patents

Abstract

本发明提供一种存储方法、装置、设备、存储介质和系统，该存储系统包括：存储管控系统以及不同应用程序对应的各容器组。任一容器组用于响应于相应应用程序的启动，向存储管控系统发送存储资源获取请求。存储管控系统用于在接收到存储资源获取请求时，创建与存储资源获取请求对应的文件系统，将文件系统关联到预先配置的存储根目录下。最终，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到存储根目录下。通过该方案，可以满足不同应用程序之间数据共享和存储隔离的需求。

Description

存储方法、装置、设备、存储介质和系统

技术领域

本发明涉及互联网技术领域，尤其涉及一种存储方法、装置、设备、存储介质和系统。

背景技术

容器化的应用部署方式已经成为了目前主流的应用部署方式，大量应用程序逐步在进行容器化改造。比如基于Kubernetes(是一种容器编排系统)的容器化应用部署方式。

在一种典型的容器编排系统架构中，会包含由众多容器组(通常称为pod)构成的容器组集群以及其他一些控制或服务组件。

pod部署在节点(node)中，节点可以是物理主机也可以是虚拟机。一个节点上一般会运行有多个pod。pod是容器编排系统中的最基本操作单元，包括一个或多个紧密相关的容器(Container)。应用开发者可以根据实际需求，创建一个或多个pod来部署应用程序。

一个容器组集群中会包含众多应用程序所对应的容器组，各个应用程序对应的容器组在运行过程中会产生大量数据，这些数据需要被持久化存储。另外，在进行数据存储的过程中，需要考虑如下的实际需求：不同应用程序之间的存储隔离需求，以及不同应用程序之间的数据共享需求。

因此，提供一种既满足应用程序之间数据共享需求，也满足应用程序之间存储隔离需求的存储方案，是一个较大的技术挑战。

发明内容

本发明实施例提供一种存储方法、装置、设备、存储介质和系统，用以满足不同应用程序之间数据共享和存储隔离的需求。

第一方面，本发明实施例提供一种存储方法，应用于存储管理系统，该方法包括：

接收容器组响应于相应应用程序的启动而发送的存储资源获取请求，所述容器组是不同应用程序对应的各容器组中的任一容器组；

创建与所述存储资源获取请求对应的文件系统，将所述文件系统关联到预先配置的存储根目录下；

其中，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到所述存储根目录下。

第二方面，本发明实施例提供一种存储装置，应用于存储管理系统，该装置包括：

接收模块，用于接收容器组响应于相应应用程序的启动而发送的存储资源获取请求，所述容器组是不同应用程序对应的各容器组中的任一容器组；

创建模块，用于创建与所述存储资源获取请求对应的文件系统，将所述文件系统关联到预先配置的存储根目录下；其中，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到所述存储根目录下。

第三方面，本发明实施例提供一种电子设备，其中包括处理器、存储器、通信接口，其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现第一方面中的存储方法。

第四方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现第一方面中的存储方法。

第五方面，本发明实施例提供一种存储系统，包括：

存储管控系统以及不同应用程序对应的各容器组；

所述容器组，用于响应于相应应用程序的启动，向所述存储管控系统发送存储资源获取请求；

所述存储管控系统，用于在接收到所述存储资源获取请求时，创建与所述存储资源获取请求对应的文件系统，将所述文件系统关联到预先配置的存储根目录下；

其中，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到所述存储根目录下。

在本发明实施例中，构建了一种存储系统，在该存储系统中除了包含多个应用程序对应的容器组外，还包含用于对容器组进行数据存储管理的存储管控系统。

实际应用中，一个应用程序可能对应有一个或多个容器组，针对任一容器组来说，当其对应的应用程序被启动时，该容器组可以基于用户(本文中的用户是指应用程序的开发方工作人员)的预先配置结果，向存储管控系统发送存储资源获取请求。存储管控系统采用文件系统的方式对各个容器组(亦即不同应用程序)产生的数据进行持久化存储。为了满足不同应用程序之间的存储隔热和数据共享需求，一方面，存储管控系统预先配置有一个虚拟的存储根目录，另一方面，当存储管控系统接收到某个应用程序对应的某个容器组发出的存储资源获取请求时，会基于该存储资源获取请求创建对应的一个文件系统，并将该文件系统关联到上述存储根目录下。

由此可见，假设存储系统中包括N个应用程序对应的N个容器组(即假设一个应用程序对应于一个容器组)，并假设每个容器组都触发一个存储资源获取请求，那么最终会生成与N个应用程序对应的N个文件系统，一个文件系统与一个应用程序对应，因此，每个应用程序对应有独立的文件系统，以实现不同应用程序之间数据存储的隔离性。另外，由于这N个文件系统都关联在同一个存储根目录下，而每个应用程序都可以访问该存储根目录，因此，可以实现不同应用程序之间的数据共享需求，即一个应用程序可以访问存储根目录下其他应用程序对应的文件系统中存储的数据。

附图说明

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

图1为本发明一实施例提供的存储系统的架构图；

图2为本发明一实施例提供的存储系统的工作原理示意图；

图3为本发明一实施例提供的存储方法的流程图；

图4为本发明一实施例提供的存储方法的流程图；

图5为本发明一实施例提供的存储装置的结构示意图；

图6为与图5所示实施例提供的存储装置对应的电子设备的结构示意图。

具体实施方式

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

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多个”一般包含至少两个。

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

本发明实施例提供了一种存储系统，该存储系统是在现有一些容器编排系统的基础上进行些许改造得到的，该容器编排系统比如为经典的kubernetes、无服务器化的kubernetes(Serverless kubernetes)。其中，Serverless：无服务器化，是一种软件架构概念，可让开发人员专注于服务代码(即应用程序)的本身逻辑上，无需关注代码部署的资源、维护等问题，从而可提高开发效率。

本发明实施例提供的存储系统对传统容器编排系统的改造，主要目的在于：提供一种新的存储方案，以同时满足不同应用程序之间数据共享数据和存储隔离的需求。

其中，存储隔离主要是指，使得每个应用程序具有独立的存储空间、独享的存储性能、独立的数据管理(如备份、快照等)。

其中，数据共享主要是指，诸如一些人工智能(AI)计算、代码构建等应用程序希望能够访问其他应用程序的数据，通过数据共享，可以节省数据拷贝和存储的成本。

在基于容器化部署方式进行应用程序的部署的场景中，可以采用文件系统来对这些应用程序进行持久化数据存储。因此，通过文件系统进行数据存储的过程中，如何既满足应用程序之间共享数据、统一管理的需求，也满足应用程序之间存储隔离的需求，是本发明实施例提供的存储方案所需解决的问题。

概括来说，本发明实施例提供的存储方案的解决思路是：将文件系统的统一命名空间能力与容器组集群的动态存储功能结合，为容器组集群中的不同应用程序提供独立的文件系统，并将这些文件系统管理在同一个目录树视图下，以提供方便的数据共享访问能力，以此满足不同应用程序之间数据共享和存储隔离的需求。

下面结合以下的一些实施例具体说明如何实现上述存储方案。

图1为本发明一实施例提供的存储系统的架构图，如图1中所示，该存储系统中包括：多个容器组(pod)以及存储管控系统。

其中，多个容器组比如为在图1中示意的podA、podB、podC，为便于描述，假设这三个容器组分别是与应用程序A、应用程序B和应用程序C对应的容器组。

值得说明的是，实际应用中，一个应用程序可能对应于一个或多个容器组。以任一应用程序X为例，先简单介绍下应用程序X与容器组的关系。实际上，完整地部署应用程序X可能需要使用M个pod，M≥1。其中，每个pod中包含一个或多个容器(Container)。实际上，由于应用程序X中往往会包含多种功能模块，可以认为几个功能上紧密相关的功能模块被部署在同一个pod内，也就是由同一个pod内的不同容器承载这几个功能模块。从物理载体的角度来说，这M个pod可以位于同一节点(比如同一物理主机或虚拟机)中，也可以位于不同的节点中。

由于在容器编排系统中，pod是最基本的操作单元，因此，不管一个应用程序对应有一个还是多个pod，本实施例中，对应用程序的数据存储管理，也是以pod为单位进行处理的。

本发明实施例中，在存储系统中部署有用于对全部应用程序亦即全部pod进行数据存储管理的存储管控系统。存储管控系统通过文件系统的方式对各个pod进行数据存储管理。

为了满足不同应用程序之间的存储隔热和数据共享需求，首先，基于相关工作人员基于文件系统的统一命名空间能力，在存储管控系统中配置一个虚拟的存储根目录(如图1中所示)，以便可以实现应用程序之间的全局共享访问。

之后，当某个应用程序启动(比如首次启动)时，该应用程序对应的pod会基于用户预先的配置结果(配置需要什么样的存储资源)，向存储管控系统发送存储资源获取请求，以请求获得所需的存储资源。这里先不关心存储管控系统如何进行相应存储资源的分配，仅强调：存储管控系统基于接收到的存储资源获取请求，会创建对应的文件系统，并将创建的文件系统关联到上述存储根目录下。

为便于理解上述过程，结合图1中示意的三个pod来示例性说明。

当应用程序A启动时，与之对应的podA向存储管控系统发送存储资源获取请求。实际应用中，容器编排系统中可以提供一种API：持久卷申请(Persistent Volume Claim,简称PVC)，pod可以通过调用该API触发上述存储资源获取请求。在图1中，将podA触发的存储资源获取请求表示为PVC A。存储管控系统基于PVC A，创建与之对应的文件系统A，并将文件系统A关联到存储根目录下。从而，如图1中所示，此时会形成一条文件系统A的访问路径：/A/，其中，“A”表示文件系统A的标识。

同理，当应用程序B启动时，与之对应的podB向存储管控系统发送存储资源获取请求:PVC B。存储管控系统基于PVC B，创建与之对应的文件系统B，并将文件系统B关联到存储根目录下。从而，如图1中所示，此时会形成一条文件系统B的访问路径：/B/。当应用程序C启动时，与之对应的podC向存储管控系统发送存储资源获取请求:PVC C。存储管控系统基于PVC C，创建与之对应的文件系统C，并将文件系统C关联到存储根目录下。从而，如图1中所示，此时会形成一条文件系统C的访问路径：/C/。

由图1中的示例可知，由于为podA、podB、podC创建了各自独立的文件系统，天然地实现了彼此之间的数据存储隔离。而由于创建的各个文件系统又关联在同一的存储根目录下，形成了一种树形的视图结构，上述每个pod都可以访问该存储根目录，从而，每个pod可以通过简单的路径访问的方式，便具有访问存储根目录下所有的文件系统的能力，实现不同应用程序之间的数据共享。

以上结合图1所示实施例对本发明实施例提供的存储方案的整体执行逻辑进行了说明，下面结合以下实施例对一些具体的实现方式进行详细说明。

图2为本发明一实施例提供的存储系统的工作原理示意图，如图2中所示，在图1所示实施例的基础上，从功能上进行进一步地拆分，存储管控系统中可以包括如下两个功能模块：存储类配置模块(在图2中表示为StorageClass)以及管控执行模块(在图2中表示为Provisioner Controller)。

本质上来说，StorageClass是管理人员预先定义的一个配置文件，在该配置文件中定义了存储根目录的标识信息、多种存储类型(Class)以及可用的存储资源描述信息。

其中，存储类型可以根据实际需求来划定。实际应用中，管理人员可以定义多个class，每个class对应不同的存储类型，比如包括如下几种存储类型：高性能、低性能、高容量、低容量。实际应用中，高性能，意味着对数据的读写速率比较敏感；高容量，意味着对存储容量的需求比较大。

每种存储类型对应有相应的存储资源配置策略。比如，以高性能这种存储类型为例，相应的存储资源配置策略中描述有应该分配具有什么特征的存储资源，比如位于什么位置的存储设备、具有什么类型存储介质的存储设备，等等。

其中，可用的存储资源描述信息中描述了哪些存储资源是可用的，以及可以使用的存储资源相关的属性信息(如位置、剩余存储容量、所支持的访问模式，等等)。

Provisioner Controller是执行存储资源分配以及文件系统管理的功能模块。其中，对文件系统的管理比如包括创建、删除等。实际应用中，Provisioner Controller可以部署在独立于各pod所在节点的一个节点内，当然，也可以部署在某个pod所在的节点中。

为了让各个pod能够基于上述配置文件(即StorageClass)进行所需的存储资源的请求，还可以对各个pod进行配置，以配置各个pod对StorageClass的引用。具体地，存储管控系统可以将配置文件发送至各pod，从而，各pod可以基于该配置文件中包含的多种存储类型以及可用的存储资源描述信息，确定目标存储类型和目标存储容量，进而发送包含目标存储类型和目标存储容量的存储资源获取请求。

如图2中所示，podA对应的用户可以从多种存储类型中指定一种目标存储类型，并声明所需的目标存储容量，基于该用户的这些配置结果，podA可以在应用程序A启动的时候，自动向Provisioner Controller触发图中示意的PVC A这个存储资源获取请求。同理，podB触发图中示意的PVC B这个存储资源获取请求,podC触发图中示意的PVC C这个存储资源获取请求。

以PVC A为例，Provisioner Controller基于PVC A中包含的目标存储类型和目标存储容量，从可用的存储资源中分配目标存储资源，以及创建对应的文件系统A，将文件系统A关联到存储根目录下，以及将目标存储资源与文件系统A关联。其中，文件系统A与目标存储资源关联，是指文件系统A可以使用该目标存储资源，即往该目标存储资源中存入数据、删除数据、修改数据，等等。

在创建出文件系统A之后，可以将文件系统A的标识信息反馈至触发PVC A的podA，以便podA可以根据文件系统A的标识信息，将产生的数据存入文件系统A中。其中，文件系统A的标识信息比如可以是其所在的存储路径：/A/。

另外，以podA为例，为了实现podA对其他pod(比如podB)的数据访问，当应用程序A启动时，会执行挂载存储的过程，此时，可以将存储根目录挂载至podA，以使podA对能够访问存储根目录下关联的各个文件系统。

另外，仍以podA为例，Provisioner Controller在创建出文件系统A之后，可以建立podA与该文件系统A之间的绑定关系，以便后续基于该绑定关系对文件系统A进行管理。比如，当应用程序A的卸载时，可以根据该绑定关系，确定出与应用程序A对应的podA相对应的文件系统A，进而将文件系统A从存储根目录下删除。

值得说明的是，实际应用中，一个pod可以触发不同的存储资源获取请求。具体来说，pod对应的应用程序对存储资源的需求可能会动态变化，用户可以按需对pod进行所需存储资源的配置，以便通过重启应用程序，使得pod在应用程序重启时，根据用户最新的配置向存储管控系统触发对应的存储资源获取请求，比如，podA可能先后触发PVC A1和PVCA2两个存储资源获取请求，此时，存储管控系统会创建与这两个存储资源获取请求各自对应的文件系统。

由此可见，本发明实施例中，各个应用程序可以采用动态存储的方式来进行数据的存储。其中，所述动态存储方式，是指根据应用程序动态变态的存储需求而动态分配存储资源、创建文件系统的方式。

综上，本发明实施例中，通过将文件系统的统一命名空间与动态存储机制相结合，使得容器集群中各个应用程序进行数据持久化存储时，既具备方便的数据共享访问能力，也能够实现应用程序之间的存储隔离。

图3为本发明一实施例提供的存储方法的流程图，该存储方法可以由前述实施例中的存储管控系统来执行。如图3所示，该存储方法可以包括如下步骤：

301、接收容器组响应于相应应用程序的启动而发送的存储资源获取请求，所述容器组是不同应用程序对应的各容器组中的任一容器组。

302、创建与存储资源获取请求对应的文件系统，将文件系统关联到预先配置的存储根目录下，其中，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到存储根目录下。

图4为本发明一实施例提供的存储方法的流程图，该存储方法可以由前述实施例中的存储管控系统来执行。如图4所示，该存储方法可以包括如下步骤：

401、接收配置文件，配置文件中包括存储根目录的标识信息、多种存储类型以及可用的存储资源描述信息。

402、将配置文件发送至容器组，以使容器组确定目标存储类型和目标存储容量，所述容器组是不同应用程序对应的各容器组中的任一容器组。

403、接收容器组响应于相应应用程序的启动而发送的包含目标存储类型和目标存储容量的存储资源获取请求。

404、响应于所述相应应用程序的启动，将存储根目录挂载至所述容器组，以使容器组能够访问存储根目录下关联的各个文件系统。

其中，某应用程序启动后，相应的容器组可以向存储管控系统发通知消息，以使其将存储根目录挂载至容器组。

405、根据目标存储类型和目标存储容量，从可用的存储资源中分配目标存储资源，创建与存储资源获取请求对应的文件系统，将文件系统关联到存储根目录下，将目标存储资源与文件系统关联。

406、将文件系统的标识信息反馈至所述容器组，以使其根据该文件系统的标识信息将产生的数据存入该文件系统中。

可选地，该方法还可以包括如下步骤：建立所述容器组与所述文件系统之间的绑定关系，基于该绑定关系对所述文件系统进行管理。比如，响应于所述相应应用程序的卸载，根据该绑定关系，将所述文件系统从存储根目录下删除。

图3和图4所示实施例中未展开描述的内容可以参考前述其他实施例中的相关说明，在此不赘述。

以下将详细描述本发明的一个或多个实施例的存储装置。本领域技术人员可以理解，这些存储装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图5为本发明一实施例提供的存储装置的结构示意图，该存储装置位于前述实施例中提及的存储管控系统中。如图5所示，该存储装置包括：接收模块11、创建模块12。

接收模块11，用于接收容器组响应于相应应用程序的启动而发送的存储资源获取请求，所述容器组是不同应用程序对应的各容器组中的任一容器组。

创建模块12，用于创建与所述存储资源获取请求对应的文件系统，将所述文件系统关联到预先配置的存储根目录下；其中，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到所述存储根目录下。

可选地，所述接收模块11还用于：接收配置文件，所述配置文件中包括所述存储根目录的标识信息、多种存储类型以及可用的存储资源描述信息。所述装置还包括：发送模块，用于将所述配置文件发送至所述容器组，以使所述容器组确定目标存储类型和目标存储容量，并发送包含所述目标存储类型和目标存储容量的所述存储资源获取请求。

可选地，所述装置还包括：分配模块，用于根据所述目标存储类型和目标存储容量，从可用的存储资源中分配目标存储资源，将所述目标存储资源与所述文件系统关联。

可选地，所述发送模块还可以用于：将所述文件系统的标识信息反馈至所述容器组，以使所述容器组根据所述文件系统的标识信息将产生的数据存入所述文件系统中。

可选地，所述装置还包括：挂载模块，用于响应于所述相应应用程序的启动，将所述存储根目录挂载至所述容器组，以使所述容器组能够访问所述存储根目录下关联的各个文件系统。

可选地，所述装置还包括：管理模块，用于建立所述容器组与所述文件系统之间的绑定关系，基于所述绑定关系对所述文件系统进行管理。

可选地，所述管理模块具体可以用于：响应于所述相应应用程序的卸载，根据所述绑定关系，将所述文件系统从所述存储根目录下删除。

图5所示存储装置可以执行前述图1至图4所示实施例中存储管控系统所执行的各个步骤，本实施例未详细描述的部分，可参考前述实施例的相关说明，在此不再赘述。

在一个可能的设计中，上述图5所示的存储装置的结构可实现为一电子设备。如图6所示，该电子设备可以包括：处理器21、存储器22、通信接口23。其中，存储器22上存储有可执行代码，当所述可执行代码被处理器21执行时，至少使处理器21可以实现如前述图1至图4所示实施例中存储管理系统所执行的各个步骤。

其中，处理器21可以是中央处理器(Central Processing Unit，简称CPU)，也可以是现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)、图形处理器(Graphics Processing Unit，简称GPU)、网络处理器(network process units，简称NPU)、人工智能芯片等具有计算能力的器件。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行前述图1至图4所示实施例中存储管理系统所执行的各个步骤。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的各个模块可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (13)

1.一种存储系统，包括：

存储管控系统以及不同应用程序对应的各容器组；

所述容器组，用于响应于相应应用程序的启动，确定目标存储类型和目标存储容量，向所述存储管控系统发送包含所述目标存储类型和目标存储容量的存储资源获取请求；

所述存储管控系统，用于接收配置文件，将所述配置文件发送至所述容器组，所述配置文件中包括存储根目录的标识信息、多种存储类型以及可用的存储资源描述信息；在接收到所述存储资源获取请求时，创建与所述存储资源获取请求对应的文件系统，将所述文件系统关联到预先配置的存储根目录下；根据所述目标存储类型和目标存储容量，从可用的存储资源中分配目标存储资源，将所述目标存储资源与所述文件系统关联；

其中，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到所述存储根目录下，所述目标存储类型是所述多种存储类型中的一种。

2.根据权利要求1所述的系统，所述存储管控系统还用于：

建立所述容器组与所述文件系统之间的绑定关系；

基于所述绑定关系对所述文件系统进行管理。

3.根据权利要求2所述的系统，所述存储管控系统具体用于：响应于所述相应应用程序的卸载，根据所述绑定关系，将所述文件系统从所述存储根目录下删除。

4.根据权利要求1所述的系统，所述存储管控系统还用于：将所述文件系统的标识信息反馈至所述容器组；

所述容器组还用于：根据所述文件系统的标识信息，将产生的数据存入所述文件系统中。

5.根据权利要求1所述的系统，所述存储管控系统还用于：

响应于所述相应应用程序的启动，将所述存储根目录挂载至所述容器组，以使所述容器组能够访问所述存储根目录下关联的各个文件系统。

6.一种存储方法，应用于存储管理系统，所述方法包括：

接收配置文件，所述配置文件中包括存储根目录的标识信息、多种存储类型以及可用的存储资源描述信息；

将所述配置文件发送至容器组；

接收容器组响应于相应应用程序的启动而发送的存储资源获取请求，所述容器组是不同应用程序对应的各容器组中的任一容器组，所述存储资源获取请求包含目标存储类型和目标存储容量，所述目标存储类型是所述多种存储类型中的一种；

创建与所述存储资源获取请求对应的文件系统，将所述文件系统关联到预先配置的存储根目录下，以及，根据所述目标存储类型和目标存储容量，从可用的存储资源中分配目标存储资源，将所述目标存储资源与所述文件系统关联；

其中，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到所述存储根目录下。

7.根据权利要求6所述的方法，所述方法还包括：

建立所述容器组与所述文件系统之间的绑定关系；

基于所述绑定关系对所述文件系统进行管理。

8.根据权利要求7所述的方法，所述基于所述绑定关系对所述文件系统进行管理，包括：

响应于所述相应应用程序的卸载，根据所述绑定关系，将所述文件系统从所述存储根目录下删除。

9.根据权利要求6所述的方法，所述方法还包括：

将所述文件系统的标识信息反馈至所述容器组，以使所述容器组根据所述文件系统的标识信息将产生的数据存入所述文件系统中。

10.根据权利要求6所述的方法，所述方法还包括：

响应于所述相应应用程序的启动，将所述存储根目录挂载至所述容器组，以使所述容器组能够访问所述存储根目录下关联的各个文件系统。

11.一种存储装置，应用于存储管理系统，所述装置包括：

接收模块，用于接收配置文件，所述配置文件中包括存储根目录的标识信息、多种存储类型以及可用的存储资源描述信息，接收容器组响应于相应应用程序的启动而发送的存储资源获取请求，所述容器组是不同应用程序对应的各容器组中的任一容器组，所述存储资源获取请求包含目标存储类型和目标存储容量，所述目标存储类型是所述多种存储类型中的一种；

发送模块，用于将所述配置文件发送至所述容器组；

创建模块，用于创建与所述存储资源获取请求对应的文件系统，将所述文件系统关联到预先配置的存储根目录下，以及，根据所述目标存储类型和目标存储容量，从可用的存储资源中分配目标存储资源，将所述目标存储资源与所述文件系统关联；其中，与不同容器组触发的存储资源获取请求相对应的文件系统都关联到所述存储根目录下。

12.一种电子设备，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求6至10中任一项所述的存储方法。

13.一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求6至10中任一项所述的存储方法。

Images