CN116931818A

CN116931818A - Container storage management method and device

Info

Publication number: CN116931818A
Application number: CN202210736549.1A
Authority: CN
Inventors: 李明; 何小康
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-04-01
Filing date: 2022-06-27
Publication date: 2023-10-24

Abstract

The embodiment of the application provides a container storage management method and device, which are applied to the fields of information technology and container technology. The embodiment of the application can collect the storage association information of the application, collect a plurality of storage association information to obtain the storage topology of the application, and the storage topology can be provided for the data service to use. By the arrangement, on one hand, the data service can conveniently and rapidly acquire the storage topology of the required application, and different storage information is not required to be acquired in a plurality of places and then summarized to acquire the storage topology, so that the development and operation processes of each data service are simpler and more efficient, errors are less prone to occurring, and the service efficiency and the service quality of the data service are improved. On the other hand, the storage topology can be commonly used by a plurality of data services, so that the repeated labor of each data service is avoided, and the consumption of computing resources in the container cluster can be reduced.

Description

Container storage management method and device

Technical Field

The application relates to the technical field of information technology (information technology, IT) and container, in particular to a container storage management method and device.

Background

As container technology is increasingly becoming a new standard infrastructure in the field of cloud computing, more and more users deploy their applications on container clusters. Applications, when deployed to a container cluster, generate a variety of data. As a means for improving competitiveness, container manufacturers are actively developing various application-oriented data services while providing the infrastructure of the container clusters, so that users are more guaranteed when using the container clusters. Common data services include backup, disaster recovery, migration, or data security services.

In implementing data services, it is often necessary to obtain data of an application. However, different types of data may be stored in different locations, i.e., each data service may need to obtain corresponding data from different locations, which makes the efficiency of the data service poor. In addition, the container cluster has a plurality of objects, a complex structure and a plurality of storage equipment types for storing data, thereby further enhancing the problems of inefficiency and instability of data service and affecting user experience.

Therefore, how to make the data service acquire data conveniently and efficiently is a problem to be solved by those skilled in the art.

Disclosure of Invention

The embodiment of the application provides a container storage management method and device, which can manage the storage topology of an application and improve the service efficiency and reliability of data service.

In a first aspect, an embodiment of the present application provides a container storage management method, including:

collecting a plurality of storage association information from the plurality of nodes, wherein the storage association information is information related to data storage of an application;

summarizing the plurality of storage association information to obtain a storage topology of the application, wherein the storage topology of the application comprises association of elements of the application and physical storage positions of the application, the physical storage positions are positions where first storage equipment stores data of the application, and the first storage equipment is connected with the first container cluster;

In response to requests for a plurality of data services, the storage topology of the application is provided to the plurality of data services, respectively.

The embodiment of the application can collect the storage association information of the application, collect a plurality of storage association information to obtain the storage topology of the application, realize centralized management and maintenance of the storage topology of each application, and meet the perceived demand of data service on the storage topology.

Further, the storage topology can be provided to a data service. On the one hand, the upper layer data service can conveniently and rapidly acquire the storage topology of the required application in the development or operation process, and different storage information is not required to be acquired in a plurality of places and then summarized to acquire the storage topology, so that the development and operation process of each data service is simpler and more efficient, errors are less prone to occurring, and the service efficiency and the service quality of the data service are improved. On the other hand, in the embodiment of the application, the device can intensively execute the acquisition and maintenance of the application storage topology without executing the process by each service respectively, so that the repeated labor of each data service is avoided, and the consumption of the computing resources in the container cluster can be reduced.

Alternatively, the application may be an application deployed on a container cluster, in which case the application is also referred to as a containerized application. The method provided by the embodiment of the application can be used for managing containerized applications.

In a possible implementation manner of the first aspect, the container clusters areAnd the plurality of nodes comprise a Master and Node nodes. Furthermore, the service load of the containerized application is realized by the Node, and the service load of the containerized application is scheduled to the Node through the Master.

Optionally, an operation and maintenance node is also provided in some container clusters for maintaining application operation. At this time, the plurality of nodes further includes an operation and maintenance node.

In a further possible implementation manner of the first aspect, the collecting, summarizing and responding steps are performed by a container storage management device deployed in the first container cluster, the container storage management device further providing a service interface, and the responding steps specifically include:

and responding to the call of the plurality of data services to the service interface, and respectively providing the storage topology of the containerized application for the plurality of data services.

In a further possible implementation manner of the first aspect, the storage topology of the containerized application is used by the plurality of data services to implement migration, backup, dual-activity or disaster recovery, etc. of the containerized application.

In a further possible implementation manner of the first aspect, the container storage management device includes an acquisition module and a storage relationship management module. The function of collecting and storing the associated information is realized by the collecting module, and the function of summarizing and storing the associated information is realized by the storage relationship management module.

In the above embodiment, the plurality of acquisition modules acquire the storage association information at the plurality of acquisition points (the position where the acquisition modules are deployed is referred to as an acquisition point), and accordingly, the storage relationship management module may aggregate the plurality of storage association information, and generate the storage topology of the application according to the storage association information. Therefore, the data is not required to be repeatedly arranged in the generation process of the storage topology, and the embodiment of the application can rapidly and accurately generate the application storage topology.

In addition, the acquisition modules are deployed on a plurality of acquisition points, and when the storage association information on the acquisition points is changed, the storage relationship management module can acquire the changed and updated storage topology in time, so that the accuracy of the storage topology is improved, and the reliability of data service is improved.

Alternatively, the acquisition module may be deployed on a device associated with the containerized application. For example, the acquisition module may be deployed on one or more devices in a Node, master, or operation and maintenance Node, etc.

In one possible design, the stored association information may be obtained from a database on the node. For example, the database may comprise a motion database, a store database, an ECTD database, or the like. The database is typically deployed on a node, or an agent with a database on a node.

In a further possible implementation manner of the first aspect, the storage association information includes a correspondence between the application and a volume.

In a further possible implementation manner of the first aspect, the storage association information includes a correspondence between volumes used by the application and the physical storage locations.

In the embodiment, the relation among the elements in the containerized application can be collected at the collection point without concern about the whole topological structure of the containerized application, so that the work load of the collection point is lower, too much calculation resources are not occupied, a larger collection range can be covered, and the system stability is facilitated.

A persistent volume is a volume where persistent data storage may occur. If the storage space allocated to the container in the Node is a persistent volume, the data stored in the persistent volume can be reserved after the container is destroyed or deleted. In a container cluster, when using PV, persistent volume declarations (persistent volume claim, PVC) and/or storage classes (StorageClass, SC) need to be defined.

In a further possible implementation of the first aspect, the correspondence of applications to volumes comprises one or more of:

the defined PVs for PVC, SCs for PV, etc. are applied.

By embodying the correspondence between the application and the persistent volume in the storage topology, the perceived need for persistent data can be achieved. Even after the container is deleted, the data service can still acquire the data which is originally generated by the containerized application, and the service reliability of the data is improved.

In a further possible implementation of the first aspect, the physical storage location comprises one or more of the following:

logical unit number, disk array identification, disk identification, file system directory, or logical volume identification, etc.

In a further possible implementation of the first aspect, the application is deployed in a first container cluster; the method further comprises the steps of:

synchronizing the storage topology of the application to a second cluster of containers.

The synchronization may be periodic or aperiodic, for example, to the second container cluster when the storage topology is updated. At this time, the second container cluster can quickly sense the storage topology of the application, so that the application can be conveniently reconstructed in the second container cluster or the topology of the backup application can be conveniently adjusted, and the reliability of the data service can be improved.

In a further possible implementation manner of the first aspect, the storage topology of the containerized application is used for data services in the second container cluster to implement migration, backup, dual-activity, disaster recovery, or the like of the containerized application.

In a further possible implementation of the first aspect,

the container storage management apparatus also provides a first interface for invoking storage functionality provided by the first storage device.

In some scenarios, a storage device vendor provides a range of storage functions (or storage features) on the storage device, such as compression, deduplication, replication, backup, and the like. Because the storage functions provided by different storage devices are different, if the data service calls the storage functions through the private interface, additional compatibility codes may need to be developed, which affects the efficiency and reliability of the data service. The first interface of the embodiment of the application realizes unified call of different storage functions. The data service can make full use of the capacity of the bottom storage to arrange, copy and the like the data of the container application through the first interface, so that the stability and the reliability of the data service are improved, and the user experience is improved.

Alternatively, the first interface may be implemented in the form of an application programming interface (application programming interface, API).

In a further possible implementation of the first aspect, the storing function includes a storing high-speed link for transmitting data of the application.

In a further possible implementation manner of the first aspect, the data of the containerized application is stored in the high-speed link for data service transmission such as migration, backup, or dual-activity.

The storage high-speed link is a storage function, and can establish a high-speed transmission data link between the underlying data storage to realize the high-speed transmission requirement of data. According to the embodiment of the application, the data service can call the storage high-speed link, so that the data of the containerized application can be conveniently and efficiently migrated, the service quality and reliability of the data service are improved, and the user experience is improved.

In a further possible implementation manner of the first aspect, the storage function provided by the first storage device includes storing the high-speed link, the method further includes:

and in response to a call to the first interface by any one of the plurality of data services, instructing the first storage device to transfer the data of the containerized application to a second storage device over the storage high-speed link.

Alternatively, the first storage device may be a storage device to which the first container cluster is connected.

In a further possible implementation manner of the first aspect, the plurality of data services includes a first data service including a first sub-service, the first sub-service being located in a second container cluster, the method further includes:

the first sub-service rebuilds the application on the second container cluster according to the storage topology of the application and the data of the application stored on the second storage device; wherein the second storage device is connected to the second container cluster.

In a further possible implementation manner of the first aspect, the method further includes:

synchronizing a storage topology of the containerized application to the second cluster of containers;

the first sub-service obtains a storage topology of the containerized application from the second container cluster.

In a further possible implementation manner of the first aspect, the first data service further comprises a second sub-service, the second sub-service being located in the first container cluster, the method further comprising:

the second sub-service calls the service interface to acquire the storage topology of the containerized application;

The second sub-service synchronizes the storage topology of the containerized application to the first sub-service.

In a second aspect, an embodiment of the present application provides a container storage management device, where the container storage management device is configured to manage an application, where the application is deployed in a first container cluster, and the first container cluster includes a plurality of nodes, and the container storage management device is configured to implement the method described in the first aspect or any one of possible implementation manners of the first aspect.

Alternatively, the application is a containerized application.

In a possible implementation manner of the second aspect, the container storage management device includes a storage relationship management module and a plurality of acquisition modules;

the plurality of acquisition modules are used for acquiring a plurality of pieces of storage related information from the plurality of nodes, wherein the storage related information is information related to data storage of the containerized application;

the storage relation management module is used for summarizing the plurality of storage association information to obtain a storage topology of the containerized application, wherein the storage topology of the containerized application comprises the association of elements of the containerized application and physical storage positions of the containerized application, the physical storage positions are positions where first storage equipment stores data of the containerized application, and the first storage equipment is connected with the first container cluster;

The storage relationship management module is further configured to provide the storage topology of the containerized application to a plurality of data services, respectively, in response to a request of the plurality of data services.

In a further possible implementation manner of the second aspect, the storage relationship management module is further configured to:

In yet another possible implementation manner of the second aspect, the storage topology of the containerized application is used by the plurality of data services to implement migration, backup, dual-activity or disaster recovery, etc. of the containerized application.

In a further possible implementation manner of the second aspect, the storage association information includes a correspondence between the application and a volume.

In a further possible implementation manner of the second aspect, the storage association information includes a correspondence between volumes used by the application and the physical storage locations.

In a further possible implementation manner of the second aspect, the correspondence between the application and the volume includes one or more of the following:

and the application defines the PV corresponding to the PVC, the SC corresponding to the PVC and the SC corresponding to the PV.

In a further possible implementation manner of the second aspect, the physical storage location contains one or more of the following information:

and synchronizing the storage topology of the containerized application to a second container cluster, wherein the storage topology of the containerized application is used for realizing migration, backup, dual-activity or disaster recovery and the like of the containerized application in the second container cluster.

In a further possible implementation manner of the second aspect, the container storage management device further provides a first interface, and further provides a first interface, where the first interface is used to implement a call to a storage function provided by the first storage device.

In a further possible implementation manner of the second aspect, the container storage management device further comprises a storage function driving module, and the first interface is provided by the container function driving module.

In a further possible implementation manner of the second aspect, the storage function includes storing a high-speed link, and the container storage management device is further configured to:

In a further possible implementation of the second aspect, the first container cluster isAnd (5) clustering.

Further, the plurality of nodes includes a Master and a Node.

In a further possible implementation of the second aspect, the second container cluster isAnd (5) clustering.

In a third aspect, an embodiment of the present application provides a service providing system, where the service providing system includes a first container storage management device, and the service providing system further provides a plurality of data services, where the plurality of data services includes a first data service. Wherein the first container storage management device is a storage management device described in the second aspect or any possible implementation manner of the second aspect, and the service providing system is configured to implement the method described in the first aspect or any possible implementation manner of the first aspect.

In a possible implementation manner of the third aspect, the first container storage management device is located in a first container cluster, and an application is deployed in the first container cluster.

The first data service includes a first sub-service and a second sub-service, the first sub-service being located in the second container cluster, and the second sub-service being located in the first container cluster.

The first sub-service is configured to reconstruct the application on a second container cluster according to a storage topology of the application and data of the application stored on the second storage device; wherein the second storage device is connected to the second container cluster.

In the above embodiment, the first container storage management device centrally manages the storage topology of the application in the first container cluster, and the data service may acquire the storage topology of the application by calling the service interface, so that the development, maintenance and operation processes of the upper layer data service are simpler, the error probability is reduced, and the reliability is improved. In addition, the storage collected by the container storage management device is collected in real time in the background, so that the data service can quickly acquire the storage topology of the application through the container storage management device, the efficiency is higher, and the accuracy of the storage topology is higher.

In a possible implementation manner of the third aspect, the first container storage management device is further configured to synchronize a storage topology of the application to a second container storage management device in the second container cluster;

The first sub-service is further used for calling a service interface provided by the second container storage management device to acquire the storage topology of the application.

In a possible implementation manner of the third aspect, the first data service further comprises a second sub-service, the second sub-service being located in the first container cluster,

and the second sub-service is used for calling a service interface provided by the first container storage management device to acquire the storage topology of the containerized application and synchronizing the storage topology of the containerized application to the first sub-service.

In a fourth aspect, an embodiment of the present application provides a service providing system, where the first container cluster includes a plurality of first nodes, and a containerized application is deployed in the first container cluster; the first container cluster stores a first computer program or instructions, where the first computer program or instructions are loaded and executed by a first node, to cause the first container cluster to execute the container storage management method according to the first aspect or any possible implementation manner of the first aspect.

In a possible implementation manner of the fourth aspect, the system further includes a second container cluster, where the second container cluster includes a plurality of second nodes, and a second computer program or instruction is stored in the second container cluster, where the second computer program or instruction is loaded and executed by the second nodes, so that the second container cluster performs the method performed by the first aspect or the first sub-service in any possible implementation manner of the first aspect;

When the first computer program or instructions are loaded and executed by a first node, the first container cluster further performs the method performed by the first container storage management device and the second sub-service of the data service of the first aspect or any of the possible implementations of the first aspect.

In a fifth aspect, an embodiment of the present application further provides a storage relationship management apparatus, where the storage relationship management apparatus includes a storage relationship management module, where the storage relationship management module is configured to implement a part of functions in the storage relationship management apparatus provided in any one of the second aspects, for example, one or more functions of summarizing storage association information, obtaining a storage topology, or providing a service interface, and so on. See in particular the description of the previous embodiments.

Optionally, the storage relationship management module may comprise a communication unit for receiving and/or transmitting data and/or a processing unit for providing input and/or output to the processor. The processing unit is used for realizing the functions of processing, generating, calculating and the like.

In a sixth aspect, an embodiment of the present application further provides an acquisition apparatus, where the acquisition apparatus includes an acquisition module, where the acquisition module is configured to implement a part of functions in the storage relationship management apparatus provided in any one of the foregoing second aspects, for example, one or more functions of acquiring association information, reporting storage association information, and so on. See in particular the description of the previous embodiments.

Optionally, the acquisition module may include an acquisition unit and a communication unit, where the acquisition unit is configured to acquire data; the communication unit is arranged to receive and/or transmit data (e.g. to implement the function of reporting stored association information) and/or to provide input and/or output to the processor. Optionally, the acquisition module further comprises a processing unit, which is used for preprocessing the acquired data, etc.

In a seventh aspect, embodiments of the present application provide a computing device comprising a processor and a memory; the processor executes instructions stored in the memory to cause the computing device to implement the method described in any one of the preceding aspects.

Optionally, the computing device further comprises a communication interface for receiving and/or transmitting data, and/or for providing input and/or output to the processor.

The above embodiment is described taking a processor (or general-purpose processor) for executing a method by calling a computer specification as an example. In particular implementations, the processor may also be a special purpose processor in which the computer instructions are already preloaded in the processor. In the alternative, the processor may include both a special purpose processor and a general purpose processor.

In the alternative, the processor and memory may be integrated in one device, i.e., the processor and memory may be integrated.

In an eighth aspect, embodiments of the present application further provide a computing device cluster comprising at least one computing device, each computing device including a processor and a memory;

the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method of any one of the first aspects.

In a ninth aspect, embodiments of the present application provide a computer readable storage medium having instructions stored therein which, when executed on at least one processor, implement a method as described in any of the preceding aspects.

In a tenth aspect, the present application provides a computer program product comprising computer instructions which, when run on at least one processor, implement a method as described in any of the preceding aspects.

Alternatively, the computer program product may be a software installation package or a mirror package, which may be downloaded and executed on a computing device in case the aforementioned method is required.

The advantages of the technical solutions provided in the second to tenth aspects of the present application may refer to the advantages of the technical solutions in the first aspect, and are not described herein.

Drawings

The drawings that are necessary for use in the description of the embodiments will be briefly described below.

FIG. 1 is a schematic illustration of a typeIs a schematic diagram of the architecture of (a);

FIG. 2 is a schematic diagram of the relationship between storage resources, PVs, PVC;

FIG. 3 is a schematic diagram of the relationship between storage resources, PV, SC, PVC;

FIG. 4 is a schematic diagram of a container storage management device according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a storage topology of an application provided by an embodiment of the present application;

FIG. 6 is a schematic deployment diagram of a container storage management device according to an embodiment of the present application;

FIG. 7 is a schematic deployment view of yet another container storage management device according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a container storage management device according to an embodiment of the present application;

FIG. 9 is a schematic diagram of an operation scenario of a container storage management device according to an embodiment of the present application;

FIG. 10 is a schematic diagram of an operation scenario of a container storage management device according to another embodiment of the present application;

FIG. 11 is a schematic diagram of a service providing system according to an embodiment of the present application;

FIG. 12 is a schematic diagram of an operation scenario of an application migration service according to an embodiment of the present application;

FIG. 13 is a schematic diagram of an operation scenario of an application backup service according to an embodiment of the present application;

FIG. 14 is a flow chart of a method for managing container storage according to an embodiment of the present application;

FIG. 15 is a flow chart of a method for managing container storage according to an embodiment of the present application;

FIG. 16 is a flow chart of a method for managing container storage according to an embodiment of the present application;

FIG. 17 is a schematic diagram of a computing device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described in detail below with reference to the accompanying drawings.

For ease of understanding, the following description of some of the concepts related to the embodiments of the application are given by way of example for reference. The following is shown:

1. the technology of the container comprises the following steps: a virtualization technique is capable of isolating processes and resources.

2.Also known as K8s, an open-source container cluster (or container cluster operating system) can be responsible for deployment of applications, flexibility of applications, and management of applications, where deployment, flexibility, management, etc. of applications are provided to be implemented based on containers. The embodiment of the application can be applied to K8s or other clusters for containerization application.

Fig. 1 is a schematic diagram of Kubernetes architecture, including masters (or Master nodes, control nodes) and nodes (or compute nodes, working nodes).

Master is a control node of the cluster, consisting of four components, an application programming interface (application programming interface, API) Server (Server), a Scheduler, a controller manager (Controller Manager), and ETCD. Wherein, ETCD is a distributed data storage component, also called ETCD database, responsible for storing configuration information of clusters.

Node is a computing Node of the cluster, and is a Node for running the containerized application. The traffic load of an application may run on the Node in the form of a Pod in which one or more containers may run. Wherein a traffic load may be seen as a functional unit of an application for implementing one or more services.

Alternatively, the definition of the traffic load may also refer to the definition of the prior art.

In some embodiments of the present application, applications deployed in a container cluster are referred to as containerized applications. It should be understood that the present application is illustrated with a K8s container cluster and is not limited to use with the K8s container cluster in which embodiments of the present application are necessarily employed.

For example, embodiments of the present application may also be used in container clusters of other architectures.

For another example, embodiments of the present application may also be used to manage applications deployed in clusters of other computing instances (including virtual machines, containers, or bare metal servers, etc.). For example, the application in the embodiment of the present application may be deployed in a cluster including a plurality of virtual machines, or the like.

Some objects in kubernetes

An application deployed in a container cluster whose functionality is implemented by a Kubernetes object. Some Kubernetes objects are described below by way of example.

Pod (or Pod) is one scheduling unit and resource unit of Kubernetes. One Pod encloses one or more containers. The creation of the Pod is realized by an APIServer, and the Pod needs to be scheduled to a certain Node for operation by a Master after being created.

Deployment (or Deployment) is a serviced package for Pod. One depoyment may contain one or more Pod. The roles of the Pod contained by the depoyment are typically the same, so the system will automatically distribute requests for multiple pods of the depoyment.

StatefulSet (or state set) is a Kubernetes object used to manage stateful applications, which manages a set of Pod defined based on the same container. This set of Pod is created based on the same declaration, but cannot be replaced with each other. StatefulSet maintains a fixed Identification (ID) for each Pod to distinguish between different pods.

DaemonSet (or daemon set) is a daemon that runs a Pod on a node, through which processes of some management classes, such as log collection, resource monitoring, etc., are implemented.

The above objects are some of the possible objects listed for ease of understanding the Kubernetes object, and the application is equally applicable to scenes containing more or fewer Kubernetes objects.

4. Storage resources

Kubernetes storage is managed by volumes (volumes) that can claim storage resources that can be accessed. A volume may be mounted in a Pod or under a designated path of one or more containers.

Volume can be divided into two major categories, local disk storage and cloud storage (otherwise known as network storage).

First, a description will be given of a local storage, where the local disk storage may include an empty directory (empty dir), or a host address (HostPath), a configuration file (ConfigMap), a security-related file (Secret), and so on. The empty dir is a Volume type, and is mainly used for temporary storage, the life cycle of the empty dir is the same as that of Pod, and the Volume data after Pod deletion is also deleted. The Volume of the emuptydir type is then mounted with an empty directory, and the container or Pod reads and writes the file in the emuptydir.

HostPath is a persistent store provided by a node for a Pod using HostPath, if that Pod is deleted, the content inside HostPath still exists in the node. If the Pod is recreated and dispatched to the same node, after the Pod mounts the HostPath, the Pod can still read the content written by the previous Pod.

Configuration file ConfigMap, security related security Secret: is a special volume type and can also be regarded as configuration information of an application.

Cloud storage includes, but is not limited to, block storage, file storage, object storage, and the like. Illustratively, the block store includes, but is not limited to, a storage area network (storage area network, SAN), yun Yingpan (elastic volume service, EVS), etc., the file store includes, but is not limited to, a network attached storage (network attached storage, NAS), a flexible file service (scalable file service, SFS), or a very fast file store SFS Turbo, etc., and the object store includes, but is not limited to, an object store service (object storage service, OBS), etc.

The local storage may be directly hung in the Pod or container during use. Whereas cloud storage may be used by persistent storage volumes (persistent volume, PV) and persistent volume declarations (persistent volume claim, PVC). Of course, in some scenarios, local storage may also be used by PV and PVC.

PV and PVC

Kubernetes abstracts PV and PVC to define and use storage resources, freeing users from concern about specific infrastructure. When storage resources are needed, only a CPU and a memory are required to be declared. PV belongs to cluster-level resources. A PVC is a statement on a storage resource that needs to describe the properties of the requested storage resource, such as the size of the storage, the read-write permissions, etc.

PVC consumes PV resources. FIG. 2 illustrates an exemplary relationship between storage resources, PVs, and PVC, where the storage space provided by the PVs is provided by the storage device, and where storage resources need to be used, only PVC needs to be created and associated in Pod using Volume. Because PVC and PV are the one-to-one binding relationship, pod can use the storage space that the PV provided through PVC.

In some scenarios, a user may define a storage class (StorageClass, SC) when creating a PVC. SC describes the storage type "classification" in the cluster. The relationship between storage resources, PV, SC, PVC is shown in fig. 3, SC is defined when PVC is declared, and PV corresponding to SC type can be dynamically created; when the method is used, the Volume of the Pod is associated with the PVC, so that the Pod can be used for storage resources. For example, the SC may contain disks, NAS storage, OBS storage, and the like.

Illustratively, if the user needs to use NAS type storage, then in the created PVC, the SC is an identification of the NAS storage, and accordingly, the container cluster may create NAS type PV. Therefore, the PV is not required to be created in the cluster in advance, and the PV is only required to be dynamically created according to the requirement of the user when the user needs the storage space, so that the waste of the storage space is avoided.

The above description of the concepts may be used in the following embodiments.

Applications deployed in a container cluster may generate a variety of data. At the container level, data is stored in the mounted Volume, while at the storage level, the storage space of the Volume is provided in particular by the storage device. Thus, the data is actually stored on some physical storage location of the storage device. Because the container cluster has a plurality of objects, a complex structure and a plurality of types of storage equipment for storing data, when data service or an external device acquires data related to the storage of the application, the process is complex and the efficiency is low; moreover, each data service is likely to repeatedly perform such a complicated acquisition process, and thus waste of resources is also caused.

In view of the above, the embodiment of the application provides a container storage management method and a related device, which can collect storage association information of applications, collect a plurality of storage association information to obtain storage topology of the applications, and realize centralized management and maintenance of the storage topology of each application.

The storage topology can be provided for the data service, on one hand, the upper layer data service can conveniently and rapidly acquire the storage topology of the required application in the process of development or operation without acquiring different storage information from a plurality of places and summarizing the storage topology, so that the development and operation processes of each data service are simpler and more efficient, errors are less prone to occurring, and the service efficiency and the service quality of the data service are improved.

On the other hand, in the embodiment of the application, the applied storage topology can be centrally managed and maintained for common use by a plurality of data services, and the process of generating the storage topology is not required to be executed by each service respectively, so that the repeated labor of each data service is avoided, and the consumption of computing resources in a container cluster can be reduced.

In addition, through the service interface, the embodiment of the application can also meet the perception requirement of a user on the storage topology, and improves the service quality of the application.

In the embodiment of the application, an independent storage topology information is generated and stored, and each data service is not required to generate own exclusive storage topology information. When a data service issues a query request, the storage topology information may be returned. The storage topology information may be commonly used by a plurality of data services when there are a plurality of data services issuing query requests. The plurality of data services that issue the query request are different types of data services, including, for example: migration, backup, dual activity or disaster recovery, etc.; in a few cases, the multiple data services may also be the same type of data service, such as a query request issued by a different migration service, or a query request issued by a different backup service. The query requests may be issued simultaneously or at different points in time.

The system architecture of an embodiment of the present application is exemplarily described below. It should be noted that, the system architecture described in the present application is for more clearly describing the technical solution of the present application, and does not constitute a limitation to the technical solution provided by the present application, and those skilled in the art can know that, as the system architecture evolves and new service scenarios appear, the technical solution provided by the present application is applicable to similar technical problems.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a possible container storage management device according to an embodiment of the application. In some scenarios, the container storage management device is also referred to as vPool.

The container storage management device includes a storage relationship management (storage relationship manager, SRM) module 401, which may also be referred to as an SRMmanager, and an acquisition module 402. The number of storage relationship management modules and collection modules shown in fig. 4 is merely an example, and in the implementation process, the number of storage relationship management modules and/or collection modules may be one or multiple.

The acquisition module 402 can perform functions such as information acquisition and information reporting. Such as collecting and storing association information. Storage-related information herein refers to information related to data storage of an application. Further, the storage association information collected by the collection module can be reported to the storage relationship management module, and the storage relationship management module correspondingly receives the storage association information reported by the collection module.

The storage relationship management module 401 has computing capabilities capable of performing one or more of the functions of acquiring, summarizing, generating, calculating, processing, determining, etc. Illustratively, the storage relationship management module can aggregate the storage association information to obtain a storage topology of the application. The storage topology of an application includes an association between the application and a physical storage location. The physical storage location is the location where the storage device stores data of an application (described in detail below).

It should be noted that, in the embodiment of the present application, the storage topology of the application includes the association between the elements of the application and the physical storage device.

Wherein the elements of the application include, but are not limited to: platform definition application information (or application information referred to as container cluster definition), configuration information of an application, kubernetes object, pod, container, volume, or the like. Terms such as Kubernetes object, pod, container, or volume may refer to the definition of the term interpretation section described above, or to the definition in the related art. Configuration information of an application includes, but is not limited to, configuration files (e.g., configMap) of the application, account information, security information (e.g., secret, etc.), network configuration files, or rights information (e.g., license, etc.), etc. Platform definition application information is an alternative information related to the provider of the container clusters. Some providers provide some cluster-level Kubernetes objects, or functional packages, etc. in container clusters for users to use when deploying applications, which are platform-defined application information.

There is an association between the elements of the application and the physical storage locations. For example, a physical storage location corresponding to configuration information of an application, a physical storage location corresponding to volume, or the like. The association between an element of an application and a physical storage location is also referred to as a mapping in some scenarios.

Alternatively, where the application contains multiple elements, the storage topology of the application may also contain associations between the multiple elements of the application. The association includes, but is not limited to, an inclusion relationship, a binding relationship, a dependency relationship, a mapping relationship (or a correspondence relationship), and the like. For example, an application contains a Kubernetes object, a Kubernetes object contains Pod, kubernetes object contains a container, a Kubernetes object is deployed in a Node, pod corresponds to volume storing data, and so on.

Since the storage topology of the application is derived based on the storage association information, the storage association information may include one or more of the following: a single element of an application, an association between an element of an application and a physical storage location, multiple elements of an application, an association between multiple elements of an application, etc.

For ease of understanding, an exemplary storage topology is briefly described below. Referring to fig. 5, fig. 5 is a schematic diagram of a storage topology of one possible application provided in an embodiment of the present application. The storage topology includes associations between elements of an application and physical storage locations. Specifically, the storage topology includes elements such as platform definition application information, K8s objects, configuration information, pod, PVC, PV, and physical storage locations, and further includes association relationships between elements of the plurality of applications and association relationships between elements of the applications and the physical storage locations.

The storage topology includes, for example, an association relationship of "configuration information-PV-physical storage location" ("-" indicates an association relationship "), that is: the application contains configuration information, the storage of which corresponds to PV4, and PV4 corresponds to physical storage location 501 in the storage device.

Since the storage topology reflects where the data of the application is stored on the storage device, when a certain item of data needs to be acquired, the data can be acquired according to the physical storage location in the storage topology. For example, the external device needs to acquire the data content of the configuration information, and can read by accessing the physical storage location 501. In a word, the process of acquiring data can be simple and efficient through the storage topology, and errors are not easy to occur.

It should be noted that the storage topology shown in fig. 5 is an exemplary storage topology provided for convenience of description, and is not limited to the storage topology, and in a specific implementation process, the storage topology may include more or less elements, and the number of elements is not strictly limited in the embodiment of the present application.

For example, in some possible implementations, storage resources provided by a storage device are exposed to a container cluster through a container storage interface (Container Storage Interface, CSI), in other words, PV is associated with the storage device through CSI drivers. Thus, the elements of the application also contain CSIdriver, or an interface provided by CSIdriver. By way of example, the storage topology may accordingly include associations between PV, CSI driver, physical storage locations.

As a possible solution, in the embodiment of the present application, the storage topology is collected in real time, which can reflect the current (or recent) storage topology applied, and can meet the accuracy requirement of the user on the storage topology.

It should be noted that there are many possible implementations of the real-time collection here. For ease of understanding, embodiments of the present application list a few possible implementations:

in the first implementation manner, the acquisition module acquires in real time, and the storage relationship management module can refresh the storage topology of the application. The application is not limited strictly by the triggering condition and the triggering timing of the refresh, and for example, the refresh of the memory topology may be a periodic refresh or an aperiodic refresh.

In an exemplary manner, in a periodic refreshing manner, the acquisition module may report the storage association information to the storage relationship management module at intervals of a certain duration (for convenience of description, referred to as a first duration), and the storage relationship management module may collect the storage association information reported by the acquisition module at intervals of a certain duration (for convenience of description, referred to as a second duration), so as to obtain a current storage topology. It should be noted that the first duration and the second duration may be different, or may be the same, which is not limited by the present application.

In this refresh mode, the acquisition module needs to periodically report information (e.g., report once every 1 minute), and thus, the storage relationship management module can monitor the operation state of the acquisition module. For example, if the acquisition module does not report the storage association information for more than a certain period of time, it is indicated that a node deploying the acquisition module may generate a fault, or the acquisition module itself may have a functional fault, which may trigger a corresponding emergency scheme. For example, the storage relationship management module may issue a reminder of the failure state, or the like. In other words, the periodic reporting mode can monitor the operation state of the acquisition module and/or the node where the acquisition module is located, so as to improve the stability of the system.

Illustratively, in the aperiodic refresh mode, the container storage management device refreshes the storage topology of the application when a change is made to the storage topology. Specifically, when the storage association information is changed, the acquisition module may report the changed storage association information to the storage relationship management module. And the storage relation management module updates the part of the changed storage topology according to the changed storage association information to obtain the current storage topology.

In this case, on the one hand, the computational overhead and the network overhead of communication can be reduced, and on the other hand, the updating of the storage association information can be reflected in the storage topology in time, and the accuracy of the storage topology is higher. In addition, the storage relationship management module only updates the part with changed storage association relationship, rather than completely regenerating the storage topology, thereby greatly reducing the operation pressure of the storage relationship management module and improving the efficiency of updating the storage topology.

In a second implementation manner, the acquisition module acquires the storage topology when the storage topology is needed, and the storage relation management module obtains the current storage topology according to the acquired storage association information.

For example, a storage relationship management module receives a query request for a storage topology of an application. In response to the query request, the acquisition module acquires the storage association information and reports the storage association information to the storage relationship management module, and the storage relationship management module obtains the storage topology of the application according to the current storage association information. In this case, the operation state of the acquisition module can be monitored, the current real-time storage topology can be obtained according to the requirement of the storage topology, and the accuracy is high.

It should be noted that the foregoing is illustrative of the concept of "real-time collection" for ease of understanding. And are not intended to limit the embodiments of the application. The real-time collection of the storage topology may also be implemented in other implementations in particular embodiments. The above real-time manner may also be combined, and the present application will not be described in detail for the combined case.

The architecture and storage topology of the container storage management device are described above and the implementation of the container storage management device is described below.

As one possible implementation, the container cluster includes a plurality of nodes, and the acquisition module 402 described above may be deployed on one or more nodes in the container cluster. For ease of description, the device in which the acquisition module is deployed will be referred to as an acquisition point in some of the embodiments below.

For example, when the container cluster contains a Master, a Node, or the like, the acquisition module 402 may be disposed on one or more of the Node, the Master, the operation and maintenance Node, or the storage device, or the like. Wherein, the related introduction of Node and Master refers to the term interpretation part; the operation and maintenance nodes are nodes with management properties arranged in some container clusters and are used for realizing operation and maintenance on the container clusters.

For example, referring to fig. 6, fig. 6 is a schematic deployment diagram of a possible container storage management device according to an embodiment of the present application. The acquisition module 402 may be deployed on a Node and/or a Master, and acquire and store association information from the Node and/or the Master; the storage relationship management module 401 may be deployed on a Node.

For another example, the acquisition module may be deployed in a database on the node. Alternatively, the database may comprise a motion database, a store database, an ECTD database, or the like. Further alternatively, the database may be deployed directly on the node, or a proxy module with the database on the node.

For example, the Master node contains an ECTD database. At this time, the acquisition module may be deployed on a Master to facilitate acquisition and storage of the associated information from the ECTD database.

In summary, the container storage management device in the embodiment of the present application includes a storage relationship management module and a plurality of acquisition modules, where the plurality of acquisition modules respectively acquire storage association information on a plurality of acquisition points, and correspondingly, the storage relationship management module may aggregate the plurality of storage association information, and generate a storage topology of an application according to the storage association information.

Because the acquisition modules are deployed on the acquisition points, when the storage relation management module generates the storage topology, the storage relation information reported by the acquisition modules is summarized, and the storage relation management module does not need to actively read data from each acquisition point. Therefore, the embodiment of the application can quickly and accurately generate the application storage topology.

In some scenarios, the storage-associated information may be pre-processed (e.g., data cleansing, deduplication, conversion to a predefined format, etc.) information. Optionally, when the acquisition module acquires information, preprocessing the acquired information to obtain storage associated information. By the arrangement, the calculation pressure of the storage relation management module can be reduced, and the rate of generating the storage topology by the storage relation management module is further improved.

The terms "module," "apparatus," and the like as used in the embodiments of the present application may be used to refer to a computer-related entity, a virtualized device, hardware, firmware, software, a process, a thread, software in execution, a combination of hardware and software, or the like. For example, an acquisition module may include, but is not limited to, physical hardware (e.g., one or more of a processor entity, a circuit entity, or a chip entity, etc.), virtualization devices (e.g., a virtual machine, or a container, etc.), software (e.g., one or more of a mirrored software package, an executable, computer instructions, or a computer program, etc., that is executable on a processor), or a combination of hardware and software (e.g., a storage medium storing a computer program, or a processor executing computer instructions, etc.), and the like. Illustratively, the functionality of the acquisition module 402 is implemented in a procedural manner; the storage relationship management module contains a plurality of containers that collectively implement the functions implemented by the storage relationship management module 401.

As yet another possible implementation, a storage relationship management module (SRMmanager) is deployed in the Node in the form of StatefulSet, which is a Kubernetes object, typically also as a controller for managing applications. The Pod managed by StatefulSet is distinguished by ID or serial number, and also has a network identifier for indicating identity at the time of communication.

The acquisition module is deployed in the form of Daemon set, which may also be referred to as SRM-Daemon. In other words, daemonSet in Node can realize function of acquisition module. DaemonSet is a Kubernetes object that can be viewed as a daemon. With DaemonSet, a set of functionally identical (or similar) Pods are run on nodes in the cluster, which Pods are used to implement daemons on the nodes.

FIG. 7 is a schematic diagram illustrating a deployment of another container storage management device according to an embodiment of the present application, where SRMmanager701 is illustratively deployed on a Node, and may be specifically deployed in one or more Pods on the Node; the acquisition module is SRM-daemon702, illustratively deployed on Node. The SRM-daemon can collect and store association information and synchronize to the SRMmanager701. Correspondingly, the SRM manager701 gathers a plurality of storage association information to obtain a storage topology of the application.

By way of example, communication between the SRM-daemon and the SRM manager may be via hypertext transfer security protocol (hypertext transfer protocol over securesocket layer, HTTPS).

It should be noted that, fig. 7 is for convenience of description, and is used as an example of SRMmanager and srmdaaemon deployed on a Node, and is not intended to limit the deployment location of SRMmanager and/or srmdaaemon. In the implementation process, the SRMmanager and/or the SRMdaemon can be deployed in a Node and/or a Master of a container cluster, for example, the SRMmanager and/or the SRMdaemon can also be deployed in a position of an operation and maintenance Node, a storage device or the like.

The memory topology in the embodiments of the present application may be provided externally. External here includes, but is not limited to, one or more of a data service, a third party device, or other cluster, etc. The external mode may be active or external in response to an external request.

Taking the example of providing a storage topology to a data service, the container storage management device may provide the storage topology of an application to one or more data services in response to a request for the one or more data services.

As one possible approach, the container storage management device may provide a service interface through which a storage topology is provided to one or more data services.

Referring to fig. 8, fig. 8 is a schematic structural diagram of another possible container storage management device (also referred to as vPool) according to an embodiment of the present application. Wherein, the description of the storage relation management module and the collection module can be referred to the description of the corresponding modules in fig. 4. The container storage management device may also provide a service interface (also referred to as a storage topology interface in some scenarios). Devices, services, etc. other than the container storage management apparatus may acquire the storage topology of the application through the service interface. For example, a data service invokes a service interface that can enable querying of the storage topology of an application.

It should be appreciated that the operation of the container storage management apparatus may also be in relation to the storage device. Storage devices are typically provided by storage vendors, and therefore, storage devices used by applications to store data are likely to come from different storage vendors. With the development of storage technology, it is possible for a storage device to support various storage functions (or referred to as storage characteristics) other than storage, in addition to the function of storing data. The storage functions are particularly suitable for the scenes of various application-oriented data services, such as migration, backup, dual-activity, disaster recovery and the like of the application. By way of example, the storage function may include, for example, storing a high-speed link, compression, deduplication, replication, backup, and the like.

Different storage vendors may provide different storage functions. Even the same storage manufacturer, which provides different storage products, may differ in storage functions. Different memory functions are often called through different interfaces. Such an interface is typically a proprietary interface provided by a storage manufacturer, and thus, in some related technologies, when a data service needs to use a storage function, compatibility adjustment needs to be performed on a code of the data service itself, which not only results in redundancy of the data service code and higher development cost, but also reduces operation efficiency of the data service.

Thus, optionally, in order to enable the data service or application to better use the storage functions provided by different storage vendors (or different storage products), the container storage management device may further provide a first interface, where the first interface may be used to implement a unified call to the storage functions of the different storage vendors (or different storage products), for example, the data service or application may call the functions of the storage device by calling the first interface.

In some possible designs, the container storage management device includes a storage characteristic driving module, where the module may implement communication with different storage devices, abstract a unified storage characteristic interface (or called a first interface) for the storage bottom layer characteristics provided by the different storage devices, and provide the first interface based on the abstract unified storage characteristic interface.

Optionally, the storage characteristic driving module may be a CSI driver (CSI driver) and/or a CSI extension driver (CSI extend driver). Accordingly, the first interface provided by the container storage management device (or the storage characteristic driving module in the container storage management device) may be a CSI interface, or may be a container storage interface extension (Container Storage Interface Extend, CSI extension). Where CSI is an industry standard interface specification intended to expose a storage system to an application, CSI extension is an extension to CSI.

It should be noted that, the first interface is an exemplary name given to distinguish the service interface above, and in the implementation process, the names of the first interface, the service interface, and the like may be replaced. In addition, the number of interfaces included in the first interface is not strictly limited in the present application, and the number of interfaces included in the first interface may be one or more. For example, the first interface may include a plurality of interfaces for calling an interface for storing a high-speed link, an interface for calling a compression function, and the like.

Optionally, the first interface is provided in the form of an application programming interface (application programming interface, API).

In summary, the first interface can be used as a standard interface for calling storage functions of different manufacturers, such as data service, application and the like, and through the first interface, decoupling between the data service and the application and bottom storage can be realized, so that the problem that interfaces need to be re-adapted to different storage manufacturers (or different storage products) is solved, and the efficiency and reliability of the data service or the application in development and operation are improved.

The following describes an operation procedure of the container storage management device, taking a service interface to implement a query of a storage topology by a plurality of data services as an example. Data services are typically managed, collected, analyzed, processed, etc. by a user application, so as to provide a series of application-oriented extended services, such as backup, disaster recovery, migration, security, etc. of the application. In some implementations, the data service may be a type of preset service provided by the container cluster to the user.

Fig. 9 is a schematic diagram of an operation scenario of a container storage management device according to an embodiment of the present application. The function of the individual modules of the container storage management device may be as described in relation to fig. 8.

The container storage management device can enable the data service to conveniently and rapidly acquire the storage topology of the required application through the service interface.

Optionally, the container storage management device may further enable the data service to call a storage function provided by the storage device through the first interface.

It should be noted that in the scenario shown in fig. 9, the storage-related information collected by the collection module includes three levels of information, namely, a containerized application layer, a container arrangement and scheduling layer, and a storage infrastructure layer.

Each hierarchy comprises a plurality of elements and/or physical storage positions of the application, wherein the elements of the application have corresponding relations, and the elements of the application and the physical storage positions also have association. The method comprises the following steps:

the storage related information of the containerized application layer may include: the application comprises a Kubernetes object, configuration information of the application, association of the Kubernetes object and the PVC, association of the configuration information and the PVC, association between the PVC and the PV and the like. Fig. 9 shows an exemplary association relationship between the three components in "Application (APP) - > PVC- > PV".

And the second layer, the container arrangement and scheduling layer comprises the association relation among the PV, the SC and the CSI driver. Note that, in the memory topology shown in fig. 9, CSI drivers are exemplarily shown by one block, but this does not represent the limitation of the number of CSI drivers according to the present application. In the implementation process, the CSI driver may be one or multiple CSI drivers.

And the storage infrastructure layer comprises an association relationship between the volume and the physical storage position, and the storage infrastructure layer comprises the association relationship among the volume, the CSI driver and the physical storage position because the storage equipment is exposed to the container cluster through the CSI driver.

The expression forms of the storage association relationship are different due to different types of storage devices.

For example, for block storage, the storage association information includes an association relationship between CSI driver and one or more of the following: logical unit number (logical unit number, LUN), disk array (redundant array of independent disks, RAID), disk, or the like.

For another example, for file storage, the storage association information includes association relations between CSI driver and one or more of the following: file directories, or NAS File Systems (FS), etc.

For another example, for a hard disk, the stored association information includes an association relationship between CSI driver and one or more of the following: logical Volume (LV), physical Volume (PV), physical Volume Group (VG), and the like.

Another possible operational scenario of the container storage management device provided by the embodiment of the present application is shown in fig. 10. The functions of the respective modules of the container storage management apparatus may be referred to in connection with the description of fig. 8.

It is noted that in the embodiment shown in fig. 10, the storage-related information includes application configuration information (i.e., the acquisition point (1) shown in fig. 10), application data mapping information (i.e., the acquisition point (2) shown in fig. 10), or mapping information between data and a storage device (i.e., the acquisition point (3) shown in fig. 10), and the like.

Wherein the application configuration information is information related to the configuration of the application.

Exemplary application configuration information includes, but is not limited to ConfigMap, secret, network configuration files, or rights information, etc. Alternatively, the application configuration information may be stored in an operation maintenance database (operation maintain database, OM DB).

The application data mapping information is used to indicate a logical storage mapping of application data, including but not limited to Kubernetes objects, pod corresponding to Kubernetes objects, volume corresponding to Pod, and the like, contained in the application. The application data mapping information may be stored in the ECTD and/or the application data mapping information may be stored on nodes etc. (not shown in fig. 10).

The memory mapping relationship between data and storage devices, i.e., the physical storage locations of the data between the storage devices. Optionally, the memory mapping between the data and the storage device is stored in a Database (DB) or a disk configuration file.

It should be understood that the data service and collection locations shown in fig. 10 are merely examples and are not intended to limit the operational scenario of the container storage management device.

It should be noted that the collection point (3) shown in fig. 10 may not be actually located in the storage device, and the collection location shown in fig. 10 is merely an example.

For example, in some scenarios, a proxy module with a storage device in a container cluster can meet the acquisition requirement for the storage mapping relationship by deploying an acquisition module on a Node (e.g., node, master, etc.) where the proxy module is located.

In order to facilitate understanding of the use of the storage topology by the data service, a simple description of the process of using the storage topology by the data service will be given below by taking an application migration scenario as an example.

Application migration refers to migrating an application located in one container cluster to a data service in another container cluster. For ease of understanding, the following description will take the example where the cluster to which the application migrates is a first container cluster and the cluster to which the application migrates is a second container cluster. Typically, the first container cluster and the second container cluster are different container clusters. Of course, the vendors of the first container cluster and the second container cluster may be the same, e.g., the first container cluster and the second container cluster are different container cluster products provided by the same vendor.

In other words, the process of application migration occurs in a system (hereinafter referred to as a service providing system) including a first container cluster and a second container cluster. The first container cluster has applications deployed therein, and the data service is capable of migrating applications from the first container cluster to the second container cluster.

In some scenarios, the data service is an extended service provided by a cluster of containers. Thus, in embodiments of the present application, the data service may be provided by the first container cluster and/or the second container cluster. Of course, the data service may also be located on a device outside the first container cluster and the second container cluster (i.e. provided by a third party device).

For ease of understanding, three examples of principals providing data services are described below using application migration as an example:

example 1, a data service is provided by a first cluster of containers. Illustratively, the first container cluster provides application migration services for applications deployed thereon. That is, the application migration service is capable of migrating applications in a first container cluster to other container clusters (e.g., a second container cluster).

Example 2, the data service is provided by a second cluster of containers. Illustratively, the second container cluster provides an application migration service by which a user may migrate applications in other container clusters (e.g., the first container cluster) into the second container cluster.

Example 3, the data service is provided by a third party device. For example, a third party data service vendor provides an application migration service that is capable of communicating with a first container cluster and a second container cluster to migrate applications in the first container cluster into the second container cluster.

The three data service providing entities (e.g., any container cluster, several nodes of a container cluster, or a third party device) in the above example are only examples, and are not limited to the data service.

The data service is implemented by means of a device, typically by which principal the data service is provided, i.e. on which principal the device implementing the data service is located. However, in some scenarios, the data service involves multiparty interactions, and although the data service is provided by a certain entity, the means for implementing the data service may be located on multiple entities.

As a possible solution, the data service comprises one or more sub-services for jointly implementing the functionality of the data service on different principals.

Fig. 11 is a schematic diagram of an architecture of a possible service providing system according to an embodiment of the present application, where the data service includes a first sub-service and/or a second sub-service. Wherein the first sub-service is located in the second container cluster for performing the step of the data service performed in the second container cluster. The second sub-service is located in the first container cluster for performing the step of the data service performed in the second container cluster.

The system architecture to which the application migration applies is described above, and the following exemplary description of the application migration process is provided.

Referring to fig. 12, fig. 12 is a schematic view of an operation scenario of an application migration service according to an embodiment of the present application. As shown in fig. 12, the process of application migration may specifically include the following steps:

step 0: the collection module (i.e., SRM-daemon) in the first container cluster collects a plurality of storage-related information. A storage relation management module (SRMmanager) in the first container cluster collects a plurality of storage association information collected by a plurality of collection modules to obtain a storage topology of an application.

As a possible solution, the SRM manager may maintain an identifier of the application corresponding to the storage topology of the application when managing the storage topology of the application, where the identifier of the application includes, but is not limited to, an ID, a number, a name, and the like. The method does not limit the acquisition mode of the identification of the application to be migrated, for example, the identification can be input by a user or user equipment, or can be issued by other management equipment. By the arrangement, not only can the unused applications be conveniently distinguished in the multi-application cluster, but also the storage topology of the corresponding applications can be conveniently provided for the data service.

It should be noted that there is a correspondence between the storage topology of the application and the identification of the application. The data service may carry an identification of the application when querying the storage topology of the application. Accordingly, the SRM manager provides the data service with the storage topology of the corresponding application according to the application identifier.

Step 1: the data service obtains an instruction to migrate the application.

It should be understood that the data service herein may be implemented by hardware, may be implemented by software, or may be implemented by a combination of hardware and software. Alternatively, the data service may be user and/or user equipment initiated.

The data service may provide an interface or interface, and the user and/or user device may trigger application migration by invoking the interface or by operating the interface, thereby allowing the data service to obtain an instruction for migrating the application.

In the present application, the migration of an application may refer to a specified application in a migration container cluster, or may refer to all applications in a migration cluster.

When migrating to a specific application in a container cluster, the data service also needs to acquire the identification of the application to be migrated.

Step 2: the data service creates a migration task, generating a migration pair.

Wherein a migration pair is a module for data interaction between a source (i.e., a first container cluster) and a target (i.e., a second container cluster). Optionally, the migration pair includes a plurality of modules, a portion of the modules being located in a first container cluster and a portion of the modules being located in a second container cluster.

The migration pair can enable the source end to know the basic condition of the target end and enable the source end and the target end to establish a trust relationship. Alternatively, the migration pair can also be used for preparation before the target is ready for migration.

Step 3: the data service invokes a service interface provided by the SRM manager to query the storage topology of the application.

Alternatively, the storage topology of the application may be used for data services to authenticate the second container cluster. For example, the data service may calculate the organization of containers and available storage resources in the second cluster of containers based on the acquired storage topology information.

For example, the data service may verify the storage space, computing power, etc. of the second container cluster based on the obtained storage topology information to determine whether the second container cluster has environmental conditions for deploying the containerized application.

As a possible solution, if the data service determines, according to the storage topology of the containerized application, that the second container cluster meets the conditions for deploying the application, a subsequent step may be performed.

As a possible solution, if the data service determines that the computing power in the second container cluster cannot meet the requirement of the service load of the application according to the storage topology of the containerized application, the data service may feed back the verification result. For example, the data service feeds back that the application cannot migrate to the second container cluster. For another example, the data service alerts the user to expand the second container cluster.

Of course, the storage topology of the application may also be used in other ways, and the present application does not impose strict restrictions on the use of the storage topology of the application by the data service. For example, the data service may also migrate data of an application from a storage device connected to the first container cluster to a storage device connected to the second container cluster according to the storage topology of the application (see step 4). For another example, the data service determines storage information available for migration in the second container cluster based on the acquired storage topology. The data service pre-determines the storage information which can be used for migration according to the storage topology, so that the efficiency and reliability of migration application can be improved, element establishment errors or data storage errors are avoided in the migration process, and the user experience is improved.

Step 4: the data service invokes a first interface provided by the container storage management means in the first container cluster, so that the first storage device migrates the data involved in the application into the second storage device.

In some scenarios, when an application is migrated from a first container cluster into a second container cluster, data of the application also needs to be migrated from a first storage device connected to the first container cluster to a second storage device connected to the second container cluster.

In one possible example, to increase the efficiency of data transfer, a storage device provides a storage high-speed link, a storage function (or storage feature) to support migration, replication, etc. of data to transfer data. For example, a storage high-speed link provided by a first storage device as shown in FIG. 12 may be used to support high-speed transfer of data on the first storage device to other storage devices (e.g., a second storage device).

In particular, the storage high-speed link may be a link for direct data transfer between storage devices provided by a storage vendor without forwarding, or control, through a compute node. The data transmission is carried out by using the storage high-speed link, so that the data transmission time delay can be obviously reduced, the data transmission efficiency can be improved, the application migration process can be completed as soon as possible, and the quality of data service can be improved.

Alternatively, in this case, the data service may invoke the storage high-speed link provided by the first storage device to transfer the data of the application onto the second storage device by invoking the first interface provided by the container storage management apparatus. Accordingly, the container storage management apparatus may drive the first storage device to transfer the data of the application to the second storage device through the storage high-speed link in response to the call of the data service to the first interface.

As a possible solution, the data service may determine, according to the storage topology of the application, a location of the data of the application on the first storage device and a location of the data of the application on the second storage device, and then invoke the first interface to migrate the data of the application from the first storage device to the second storage device.

Step 5: the data service rebuilds the application in the second container cluster by the storage topology of the application and the data of the application.

For example, the data service may reconstruct the association between the elements of the application and/or the physical storage locations from the storage topology of the application and the data of the application. The SRM in the second container cluster may maintain a storage topology of the applications in the second container cluster.

As shown in fig. 12, after the application is rebuilt in the second container cluster, the storage topology of the rebuilt application is similar to, or even identical to, the storage topology of the application originally in the first container cluster, so that the requirement of the user on application migration is met.

Further, the data service may also stop the application in the first container cluster.

Optionally, the storage topology of the application may be that the data service is obtained by calling a service interface of a container storage management device in the first container cluster, or that the SRMmanager in the first container cluster is synchronized to the second container cluster, and the data service is obtained from the second container cluster.

For example, in the case where the container storage management device is also included in the second container cluster, the SRMmanager in the first container cluster may synchronize the storage topology of the application to the SRMmanager in the second container cluster.

As one possible implementation, the data service may instruct the SRMmanager in the first container cluster to synchronize the storage topology of the application to the SRMmanager in the second container cluster. In this way, the data service may obtain the storage topology of the application by invoking a service interface provided by the container storage management device in the second container cluster.

It should be appreciated that the SRMmanager in the first container cluster and the SRMmanager in the second container cluster may be the same or different in implementation.

As a possible solution, the SRMmanager in the first container cluster comprises a database component for storing a storage topology of the application and a synchronizer component for sending the storage topology of the application, and further provides a service interface; the SRMmanager in the second container cluster comprises a database component and a synchronizer component, wherein the database component is used for storing the storage topology of the application, and the synchronizer component is used for receiving the storage topology of the application.

In the scenario shown in fig. 12, the storage relationship management module in the container storage management device centrally manages the storage topology of the application, and the upper layer data service can obtain the complete storage topology of the application only by calling the service interface, so that the calling, development and maintenance of the upper layer data service are simpler, the error probability is reduced, and the reliability is improved.

Moreover, the storage topology collected by the storage relation management module in the container storage management device is collected in real time, so that the data service can quickly acquire the storage topology of the application through the SRM, the acquisition efficiency is higher, and the accuracy of the acquired storage topology is higher.

The operation scenario of the container storage management device is described above by taking the data service query storage topology as an example in fig. 12, but the present application is equally applicable to an operation scenario in which the container storage management device actively synchronizes the storage topology to the second cluster. Taking an application backup scenario as an example, a scenario in which a container storage management device actively synchronizes a storage topology will be described.

Fig. 13 is a schematic diagram of an operation scenario of an application backup service according to an embodiment of the present application. The SRM-daemon in the first container cluster collects storage association information applied in the first container cluster. The SRMmanager in the first container cluster synchronizes the storage topology of the application in the first container cluster to the second container cluster, so that the storage topology of the application in the second container cluster is consistent with that in the first container cluster, and the backup of the application in the first container cluster is realized.

The architecture, the device and the operation scene of the embodiment of the application are described above, and the method of the embodiment of the application is described in detail below.

Referring to fig. 14, fig. 14 is a flow chart of a container storage management method according to an embodiment of the application. Alternatively, the method may be applied to the container storage management device described above, for example, the container storage management device in the embodiment of fig. 4 or fig. 8.

The container storage management method as shown in fig. 14 may include one or more steps of step S1401 to step S1403. It should be understood that the present application is described by the order of S1401 to S1403 for convenience of description, and is not intended to be limited to being necessarily performed by the above order. The embodiment of the application is not limited to the execution sequence, execution time, execution times and the like of the one or more steps.

The steps S1401 to S1403 are specifically as follows:

step S1401: the container storage management device collects a plurality of storage-related information.

The container storage management device is a device with a data acquisition function and a calculation function, and is realized by hardware, software or a combination of software and hardware.

Alternatively, the container storage management device may include a plurality of acquisition modules for implementing data acquisition functions, such as acquisition module 402 shown in fig. 4, or SRM-daemon, etc. shown in fig. 7.

Storage-related information refers to information related to data storage of an application. Alternatively, storing the association information may comprise one or more of: a single element of an application, an association between an element of an application and a physical storage location, multiple elements of an application, an association between multiple elements of an application, and the like.

For ease of understanding, the following exemplary list of several possible designs for storing the associated information:

design 1: the storage-related information includes correspondence between elements other than a volume (volume) in the application and the volume. Wherein the volume is used to manage storage resources that the application is able to use. Volumes can support a variety of back-end storage, such as local storage, cloud storage, and the like. Wherein one or more of, for example, an empty directory (emptyDir), or a host address (HostPath), etc., are stored locally. Cloud storage such as storage, file storage, object storage, and the like.

In some scenarios, cloud storage and/or local storage may be used at the time of use through PVC and PV. Accordingly, the correspondence of elements other than the volume in application (volume) to the volume may include a relationship between elements other than the volume in application (volume) and PVC and/or PC, and the like.

Illustratively, the correspondence of elements other than the volume (volume) in the application to the volume may include one or more of the following ("-" indicates an association): application-PVC, kubernetes object-PVC, kubernetes object-SC, PVC-PV, PVC-SC, SC-PV, PV-CSIdriver, SC-CSIdriver, etc.

Where "application-PVC" includes PVC as defined directly at the application level. The "Kubernetes object-PVC" includes PVC defined by the Kubernetes object in the application, and of course, the Kubernetes object may include multiple Pod and/or multiple container, and thus the PVC defined by the Kubernetes object includes PVC corresponding to the multiple Pod and/or multiple container. "PVC-PV" indicates which of the PVs the PVC binds to. "PV-SC" indicates the storage type to which the PVC corresponds, and "SC-PV" indicates the storage type to which the PV corresponds. CSIdriver is a call interface for CSI to expose storage devices to a container cluster.

It should be appreciated that some of the information in design 1 described above may be contained in the storage related information and container orchestration and scheduling layer of the containerized application layer shown in FIG. 9, according to embodiments of the present application. For example, the storage-related information of the containerized application layer includes "APP- > PV C- > PV", and the storage-related information of the container arrangement and scheduling layer includes an association relationship among the three of PV, SC, CSI driver.

Design 2: the storage association information includes a correspondence of volumes to physical storage locations. Optionally, the physical storage location comprises one or more of:

logical unit number (logical unit number, LUN), disk array (redundant array of independent disks, RAID) identification, disk identification, file system directory (Dir, otherwise known as file directory, directory), logical Volume (LV) identification, and the like.

Where a LUN is a logical unit number provided by a storage device, it is typically used on a storage device of the storage type block storage. Specifically, when using storage resources in a storage device, the storage device does not directly expose storage space to the storage device, but instead virtualizes the storage space into Logical Units (LU), and provides the Logical Units (LU) to the storage device for use by the storage device. Each logical unit has a unique logical unit number (logical unit number, LUN). Since container clusters can directly perceive logical unit numbers, those skilled in the art often refer to logical units directly with LUNs. Each LUN has an LU N ID for identifying the LUN. The specific physical location of the data within the LUN may be determined by the starting address and the length (length) of the data. For the start address, those skilled in the art are generally referred to as logical block addresses (logical block addr ess, LBA). It will be appreciated that three factors, LUN ID, LBA and length, identify a certain address field, which can be indexed to a global address. Thus, in some scenarios, the physical storage location may contain a LUN ID, LBA, and length. Of course, the physical storage locations are described above using LUN semantics as an example, and the present application is equally applicable to cases where other mapping semantics are used.

The disk array identification is used to indicate the disk array in which the data is stored. For example, the disk array identification may be a disk array number, a disk array ID, or the like.

The disk identifier is used to indicate the disk on which the data is stored. For example, the disk identification may be a disk number, a disk ID, or the like.

The file system directory is used to indicate the directory in which the data is stored. For example, the file system directory may be a folder path, a folder address, or the like.

The LV is used to indicate the logical partition provided by the storage device. In particular, the storage space of the storage device is provided by one or more hard disks, which may have only one partition, or may have multiple partitions. By integrating these physically present partitions, i.e., physical Volumes (PVs), a partition group (VG) can be obtained. These PVs and/or VGs are logically allocated again to form Logical Volumes (LV). The storage device exposes the logical partition to the container cluster, which can use the underlying PV through the LV. Alternatively, the PVs, VGs, LV may be managed by a logical volume manager (logical volume manager, LVM) to maintain their mapping.

Illustratively, the storage device exposes storage resources through CSI. The correspondence of volumes to physical storage locations includes one or more of the following: CSI driver-LUN, CSI driver-LUN-disk array-disk, CSI driver-directory (Dir) -NAS file system, CSI driver-logical volume-Physical Volume (PV) or Volume Group (VG), etc.

The above two designs are possible designs listed for facilitating understanding of the storage association information, and are not intended to limit the content of the storage association information, and in the specific implementation process, the storage association information may also include other designs, which are not described herein in detail.

It should be understood that some of the information in design 2 described above may be contained in the storage infrastructure layer shown in fig. 9 provided by an embodiment of the present application. For example, the storage-related information of the storage infrastructure layer includes "CSI driver- > LUN- > RAID- > disk".

Step S1402: the container storage management device gathers a plurality of storage-related information to obtain a storage topology of the application.

Optionally, the container storage management device includes a storage relationship management module, and the step S1402 is specifically executed by the storage relationship management module. The storage relationship management module is, for example, the storage relationship management module 401 shown in fig. 4, or the SRMmanager shown in fig. 8, or the like.

Optionally, the container storage management device may determine, through the plurality of storage association information, an association relationship between a certain element of the application and other elements and/or an association relationship between an element of the application and a physical storage location, so as to obtain a storage topology of the application. Reference may be made to the foregoing, e.g., related descriptions of fig. 5, 12, 14, etc., with respect to the storage topology of the application.

In summary, the embodiment of the application can collect and generate the storage topology of the application, and the storage topology of the application is centrally managed and maintained by the container storage device. Moreover, the acquisition modules are deployed on a plurality of acquisition points, so that the storage of the application can be collected in real time, and the accuracy of the storage topology is higher.

As a possible solution, the storage association information collected by the container storage management device may be real-time, and when the storage association information is changed, the storage topology of the corresponding update application is required. Specifically, the container storage management device may collect the storage association information a plurality of times, and update the portion in which the storage association relationship is changed according to the collected storage association information. Therefore, when the storage association relation of the application changes, the container storage management device can update the storage topology in time, so that the timeliness and accuracy of the storage topology are improved, and the requirements of users can be better met. In addition, the container storage management device only updates the part with changed storage association relation, rather than completely regenerating the storage topology, thereby greatly reducing the operation pressure of the container storage management device and improving the efficiency of updating the storage topology.

Further, the storage topology of the application obtained by the container storage management device may be provided to a data service, or other container clusters, etc. The storage of an application to a data service is described below as an example.

Step S1403 (optional): the container storage management device provides the storage topology of the application to the plurality of data services, respectively, in response to the requests of the plurality of data services.

Alternatively, the container storage management device may provide a service interface. At this time, the container storage management device can provide the storage topology of the containerized application to the plurality of data services, respectively, in response to the call of the plurality of data services to the service interface.

Alternatively, the container storage management device may actively provide the storage topology of the application outside, in addition to providing the storage topology of the application through the service interface. As shown in fig. 12 or 13, the container storage management device may synchronize the storage topology of the application to the second container cluster.

In the embodiment shown in fig. 14, the container storage management device can collect storage association information of an application, aggregate a plurality of storage association information to obtain a storage topology of the application, and implement centralized management and maintenance of the storage topology of each application.

Further, the storage topology may also be provided to data services. On the one hand, in the development or operation process of the upper layer data service, the storage topology of the required application can be conveniently and rapidly obtained only by calling the service interface, and different storage information is not required to be obtained in a plurality of places in real time and then summarized, so that the development and operation process of each data service is simpler and more efficient, errors are less prone to occurring, and the service efficiency and the service quality of the data service are improved. On the other hand, in the embodiment of the application, the storage topology of the application can be managed and maintained in a centralized way, namely, the acquisition and maintenance of the storage topology of the application are only required to be executed by the storage relation management module, and the processes are not required to be executed by each service respectively, so that the repeated labor of each data service is avoided, and the consumption of the computing resources in the container cluster can be reduced.

Referring to fig. 15, fig. 15 is a flowchart of another container storage management method according to an embodiment of the application. Alternatively, the method may be applied to a system comprising a plurality of clusters of containers, such as the system shown in fig. 11.

The container storage management method as shown in fig. 15 may include one or more steps of step S1501 to step S1507. It should be understood that the embodiment of the present application is described by the order of S1501 to S1507 for convenience of description, and is not intended to be necessarily limited to being performed by the above order. The embodiment of the application is not limited to the execution sequence, execution time, execution times and the like of the one or more steps. S1501 to step S1507 are specifically as follows:

Step S1501: a container storage management device in a first container cluster collects a plurality of storage-related information.

In particular, this step may be performed by an acquisition module in the container storage management device.

Wherein the first container cluster is a container cluster for orchestrating containers, otherwise known as a container platform or container engine. The first container cluster can be provided with an acquisition module, and the acquisition module can acquire a plurality of storage association information.

The related description may refer to the explanation in step S1401.

Step S1502: the container storage management device in the first container cluster collects a plurality of storage association information to obtain the storage topology of the application.

In particular, this step may be performed by a storage relationship management module in the container storage management device.

The related description may refer to the explanation in step S1402.

Step S1503: the data service queries the storage topology of the application by invoking a service interface.

Accordingly, the first container storage management device provides the storage topology of the application to the data service in response to the requests of the plurality of data services.

The usage of the data service for the acquired storage topology of the application may be referred to the description related to step 3 in fig. 12, and will not be repeated.

Step S1504: the data service instructs a first container storage management device in the first container cluster to provide the storage topology of the application to the second container cluster.

For example, the data service may send indication information to the first container storage management device, and accordingly, the first container storage management device provides the storage topology of the application to the second container cluster based on the indication information. The storage topology is used to deploy applications in the second container cluster.

The foregoing is merely exemplary, and the present application is not limited to the manner of indication and the format of the indication information, for example, the indication information may be a control signal, or a computer instruction.

In one possible design, the second container cluster deploys a second container storage management device. The first container storage management device may provide the storage topology of the application to a second container storage management device in a second container cluster.

It should be understood that the second storage relationship management device in the first container cluster and the second storage relationship management device in the second container cluster may be the same or different in implementation.

Further optionally, the first container storage management device includes a first SRM manager, and the second container storage management device includes a second SRM manager. At this time, step S1504 may be: the data service instructs the first SRM manager to provide the storage topology of the application to the second SRM manager.

Step S1505 (optional): the data service invokes the first interface.

Specifically, the container storage management device provides a first interface, and the data service can use the storage function provided by the storage device by calling the first interface.

It is understood that the data service may not invoke the first interface during implementation. For example, in the process of application migration, the device on the storage device may not need to be migrated, and at this time, the storage function of the storage device may not need to be invoked. For another example, the data service may invoke a storage function of the storage device directly by invoking a private interface of the storage device.

The following description will take the storage function of storing a high-speed link as an example.

Step S1506 (optional): the container storage management means instructs the first storage device to transfer the data of the application to the second storage device through the storage high-speed link.

The instruction may be transmission instruction information or may be realized by driving.

In a specific embodiment, the container storage management device responds to the call of the data service to the first interface to drive the first storage device connected with the first container cluster to transmit the data of the containerized application to the second storage device connected with the second container cluster. The related content may refer to the description of step 4 in fig. 12, and will not be described again.

It is to be understood that, in this embodiment, the step S1506 may not be performed. For example, in the process of application migration, the device on the storage device may not need to be migrated, and at this time, the storage function of the storage device may not need to be invoked.

Step S1507: the data service rebuilds the application on the second container cluster according to the storage topology of the application and the data of the application.

In this way, the application can be deployed in the second container cluster, so as to implement any item of data service in migration, backup, dual-activity, or disaster recovery of the application.

In a specific embodiment, in the application migration scenario, the data service may create a migration task, where the migration task creates a migration module in the second container cluster, and the migration module of the second container cluster completes the reconstruction of the application in the second container cluster according to the storage topology and the data of the application transmitted to the second storage device in step S1506.

Alternatively, the storage topology of the application used in step S1507 may be acquired from the first SRM manager or the second SRM manager by the data service. The related content can be referred to the description of step 5 in fig. 12, and will not be repeated.

The above embodiment is exemplified by the data of an application having been migrated to a second storage device. Of course, in some scenarios, the application may need to migrate to the second container cluster, but the storage device to which the second container cluster is connected may still be the first storage device. At this time, the data of the application may be stored in the first storage device, and the data service may complete the reconstruction of the application in the second container cluster according to the storage topology of the application and the data of the application on the first storage device.

In the embodiment shown in fig. 15, the container storage management device centrally manages the storage topology of the application, so that the calling, development and maintenance of the upper layer data service are simpler, the error probability is reduced, and the reliability is improved. In addition, the storage collected by the container storage management device is collected in real time in the background, so that the data service can quickly acquire the storage topology of the application through the container storage management device, the efficiency is higher, and the accuracy of the storage topology is higher.

In one possible design, the functionality implemented by the data service is implemented separately in the form of multiple sub-services that may be distributed across different devices that cooperate to implement the functionality implemented by the data service. In particular, the sub-service may be regarded as a functional module of the data service, and may be implemented by software, instructions, or processes. The related description may be referred to the description shown in fig. 11.

Referring to fig. 16, fig. 16 is a flowchart of another container storage management method according to an embodiment of the application. Alternatively, the method may be applied to the aforementioned systems, such as the systems shown in fig. 11, or fig. 12.

The service provision management method as shown in fig. 16 may include one or more steps of step S1601 to step S1606. It should be understood that the present application is described by the order of S1601 to S1606 for convenience of description, and is not intended to be limited to being necessarily performed by the above order. The embodiment of the application is not limited to the execution sequence, execution time, execution times and the like of the one or more steps. S1601 to S1606 are specifically as follows:

step S1601: a container storage management device in a first container cluster collects a plurality of storage-related information.

The related description may refer to the explanation in step S1501.

Step S1602: the container storage management device in the first container cluster collects a plurality of storage association information to obtain the storage topology of the application.

The related description may refer to the explanation in step S1502.

Step S1603: the data service queries the storage topology of the application through the service interface.

Please refer to the description of S1503 above, and the description is omitted.

Step S1604 (optional): the data service invokes the first interface. Please refer to the description related to S1505 above, which is not repeated.

Step S1605 (optional): the container storage management means instructs the first storage device to transfer the data of the application to the second storage device through the storage high-speed link.

Please refer to the description related to S1506 above, and the description is omitted.

Step S1606: the data service rebuilds the application on the second container cluster according to the storage topology of the application and the data of the application.

In this way, the data service may deploy the application in the second container cluster, implementing any one of migration, backup, dual-activity, or disaster recovery data service to the application.

In a specific embodiment, in the application migration scenario, the data service may create a migration task, where the migration task creates a migration module in the second container cluster, and the migration module completes the reconstruction of the application in the second container cluster according to the storage topology and the data transmitted to the second storage device in step S1605.

In connection with fig. 11, a first sub-service in the data service is used to perform one or more of step S1603, or step S1604, etc. A second sub-service in the data service is used to perform the steps performed by the data service in the second container cluster. For example, the second sub-service is used to perform one or more of the steps S1606 and the like.

In the embodiment shown in fig. 16, the container storage management device centrally manages the storage topology of the application, so that the calling, development and maintenance of the upper layer data service are simpler, the error probability is reduced, and the reliability is improved. In addition, the storage collected by the container storage management device is collected in real time in the background, so that the data service can quickly acquire the storage topology of the application through the container storage management device, the efficiency is higher, and the accuracy of the storage topology is higher.

The embodiment of the application also provides a service providing system which comprises a first container storage management device and also provides a plurality of data services. The first container storage management device is the container storage device described above, for example, the container storage management device in the embodiment shown in fig. 4 or fig. 8. The service providing system is used for implementing the container storage management method described above, for example, the container storage management method in the embodiment of fig. 14, 15 or 16.

In one possible implementation, the first container storage management device is located in a first container cluster, and an application is deployed in the first container cluster.

The first data service comprises a first sub-service and a second sub-service, the first sub-service is located in the second container cluster, and the second sub-service is located in the first container cluster;

The first sub-service is configured to reconstruct the containerized application on the second container cluster according to a storage topology of the containerized application and data of the containerized application stored on a second storage device; wherein the second storage device is connected to the second container cluster.

In a possible implementation manner, the first container storage management device is further configured to synchronize a storage topology of the containerized application to a second container storage management device in the second container cluster;

the first sub-service is further used for calling a service interface provided by the second container storage management device to acquire the storage topology of the containerized application.

In a possible implementation manner, the first data service further includes a second sub-service, where the second sub-service is located in a first container cluster, and the first sub-service is further configured to invoke a service interface provided by the first container storage management device to obtain a storage topology of the containerized application, and synchronize the storage topology of the containerized application with the first sub-service.

The embodiment of the application also provides a service providing system, which comprises a first container cluster, wherein the first container cluster comprises a plurality of first nodes, and a containerized application is deployed in the first container cluster; the first container cluster stores a first computer program or instructions, where the first computer program or instructions is loaded and executed by the first node, so that the first container cluster implements the container storage management method described above, for example, the container storage management method in the embodiment of fig. 13, 14, or 16.

In a possible implementation manner, the system further comprises a second container cluster, where the second container cluster includes a plurality of second nodes, and a second computer program or instructions are stored in the second container cluster, where the second computer program or instructions are loaded and executed by the second nodes, so that the second container cluster implements a method performed by the second container cluster and/or a method performed by a first sub-service in the data service in the foregoing embodiment;

the first container cluster also performs the method performed by the first container storage management device and/or the second sub-service of the data service of the previous embodiment when the first computer program or instructions are loaded and executed by the first node.

Alternatively, the container clusters in the foregoing example may beOr alternatively, the container clusters in the foregoing embodiments may be replaced with other computing instance clusters, such as a virtual machine cluster, a bare metal server cluster, and so on.

The embodiment of the application also provides a storage relationship management device, which comprises a storage relationship management module, wherein the storage relationship management module is used for realizing one or more functions of summarizing storage association information, obtaining storage topology, providing a service interface and the like in the embodiment. See in particular the description of the previous embodiments.

Optionally, the storage relationship management module may comprise a communication unit for receiving and/or transmitting data (e.g. implementing the function of receiving, or summarizing, storage of associated information) and/or a processing unit for providing input and/or output to the processor; the processing unit is used for realizing the functions of processing, generating, calculating and the like. The embodiment of the application also provides a collecting device which comprises a collecting module, wherein the collecting module is used for realizing one or more functions of collecting the associated information, reporting and storing the associated information and the like in the embodiment. See in particular the description of the previous embodiments.

Optionally, the acquisition module may include an acquisition unit and a communication unit, where the acquisition unit is configured to acquire data; the communication unit is arranged to receive and/or transmit data (e.g. to implement the function of reporting stored association information) and/or to provide input and/or output to the processor.

Optionally, the acquisition module further comprises a processing unit, which is used for preprocessing the acquired data, etc.

The present application also provides a computing device 170. A computing device is a device having computing capabilities. The device herein may be an entity's device, such as a node, server (e.g., rack-mounted server), host, etc.; virtual devices are also possible, such as virtual machines, containers, etc.

As shown in fig. 17, the computing device 170 includes: processor 1702, memory 1701, bus 1704, and optionally a communication interface 1703. The processor 1702 and the memory 1701 and the like communicate with each other via a bus 1704. It should be understood that the present application is not limited to the number of processors, memories in computing device 170.

The memory 1701 is used to provide storage space in which application data, user data, operating systems, computer programs, and the like may be optionally stored. The memory 1701 may include volatile memory (RAM), such as random access memory (random access memory). The memory 1701 may also include a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory, a mechanical hard disk (HDD), or a solid state disk (solid state drive, SSD).

The processor 1702 is a module for performing operations and may include any one or more of a central processing unit (central processing unit, CPU), a graphics processor (graphics processing unit, GPU), a Microprocessor (MP), a digital signal processor (digital signal processor, DSP), a coprocessor (assisting the central processing unit in performing corresponding processing and applications), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a micro control unit (Microcontroller Unit, MCU), or the like.

The communication interface 1703 is used to provide information input or output to the at least one processor. And/or the communication interface 1703 may be used to receive externally transmitted data and/or transmit data to the outside. The communication interface 1703 may be a wired link interface including, for example, an ethernet cable, or may be a wireless link (Wi-Fi, bluetooth, general wireless transmission, other wireless communication technologies, etc.) interface. Optionally, the communication interface 1703 may also include a transmitter (e.g., radio frequency transmitter, antenna, etc.) or a receiver, etc. coupled to the interface.

The bus 1704 may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, or the like. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one line is shown in fig. 17, but not only one bus or one type of bus. The bus 1704 may include a path to transfer information between various components of the computing device 170 (e.g., the memory 1701, the processor 1702, the communication interface 1703).

In an embodiment of the present application, the memory 1701 stores executable instructions, and the processor 1702 executes the executable instructions to implement the container storage management method described above, for example, the container storage management method in the embodiment of fig. 13, 14, 16, etc. That is, the memory 1701 has stored thereon instructions for executing the container storage management method.

Alternatively, the memory 1701 stores executable instructions that are executed by the processor 1702 to implement the functions of one or more of the aforementioned storage relationship management module, acquisition module, storage characteristic driving module, and the like, respectively, to implement the container storage management method.

The embodiment of the application also provides a computing device cluster. The cluster of computing devices includes at least one computing device 170. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop, notebook, or smart phone.

As shown in fig. 17, the cluster of computing devices includes at least one computing device 170. The same instructions for performing the container storage management method may be stored in memory 1701 in one or more computing devices 170 in the cluster of computing devices.

In some possible implementations, the memory 1701 of one or more computing devices 170 in the computing device cluster may also each have stored therein a portion of instructions for performing the container storage management method. In other words, a combination of one or more computing devices 170 may collectively execute instructions for performing the container storage management method.

It should be noted that the memory 1701 in different computing devices 170 in the computing device cluster may store different instructions for performing part of the functions of the container storage relationship apparatus, respectively. That is, the instructions stored by the memory 1701 in the different computing device 170 may implement the functionality of one or more modules (or means) of a storage relationship management module, acquisition module, storage characteristics drive, or data service (not shown in FIG. 17).

In some possible implementations, one or more computing devices in a cluster of computing devices may be connected through a network. Wherein the network may be a wide area network or a local area network, etc.

Embodiments of the present application also provide a computer program product comprising instructions. The computer program product may be software or a program product containing instructions capable of running on a computing device or stored in any useful medium. The computer program instructions are configured to implement the container storage management method described above, for example, the container storage management method in the embodiment of fig. 13, 14, 16, etc.

The embodiment of the application also provides a computer readable storage medium. The computer-readable storage medium includes instructions for implementing the container storage management method described above, for example, the container storage management method in the embodiment of fig. 13, 14, 16, or the like.

The computer readable storage medium may be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), etc.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

Reference to "at least one" in embodiments of the application means one or more, and "a plurality" means two or more. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a. b, c, (a and b), (a and c), (b and c), or (a and b and c), wherein a, b, c may be single or plural. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: three cases of a alone, a and B together, and B alone, wherein A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship.

And, unless otherwise indicated, the use of ordinal numbers such as "first," "second," etc., by embodiments of the present application is used for distinguishing between multiple objects and is not used for limiting a sequence, timing, priority, or importance of the multiple objects. For example, the first container storage management device and the second container storage management device are provided for convenience of description, and are not intended to represent differences in device structures, deployment orders, importance levels, etc. of the first container storage management device and the first container storage management device.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and the storage medium may be a read only memory, a magnetic disk or an optical disk, etc.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; these modifications or substitutions do not depart from the essence of the corresponding technical solutions from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A container storage management method for managing a containerized application deployed in a first container cluster, the first container cluster including a plurality of nodes, the method comprising:

collecting a plurality of storage association information from the plurality of nodes, wherein the storage association information is information related to data storage of the containerized application;

summarizing the plurality of storage association information to obtain a storage topology of the containerized application, wherein the storage topology of the containerized application comprises association of elements of the containerized application and physical storage positions of the containerized application, the physical storage positions are positions where first storage equipment stores data of the containerized application, and the first storage equipment is connected with the first container cluster;

in response to requests of a plurality of data services, the storage topology of the containerized application is provided to the plurality of data services, respectively.

2. The method according to claim 1, wherein the method further comprises:

the steps of collecting, summarizing and responding are executed by a container storage management device deployed in the first container cluster, the container storage management device further provides a service interface, and the responding step specifically includes:

3. The method of claim 1 or 2, wherein a storage topology of the containerized application is used by the plurality of data services to enable migration, backup, dual-activity, or disaster recovery of the containerized application.

4. A method according to any of claims 1 to 3, wherein the storage association information comprises a correspondence of the containerized application to volumes and/or a correspondence of volumes used by the containerized application to the physical storage locations.

5. The method of claim 4, wherein the containerized application to volume correspondence comprises one or more of:

the persistent volume defined by the containerized application declares a persistent volume PV corresponding to PVC, a storage class SC corresponding to PVC, and an SC corresponding to PV.

6. The method of any one of claims 1 to 5, wherein the physical storage location contains one or more of the following information:

logical unit number, disk array identification, disk identification, file system directory, or logical volume identification.

7. The method according to claim 2, characterized in that:

the container storage management apparatus also provides a first interface for enabling invocation of a storage function provided by the first storage device.

8. The method of claim 7, wherein the storing function includes storing a high-speed link, the method further comprising:

9. The method of claim 8, wherein the plurality of data services comprises a first data service comprising a first sub-service, the first sub-service being located in a second cluster of containers, the method further comprising:

the first sub-service rebuilds the containerized application on the second container cluster according to a storage topology of the containerized application and data of the containerized application stored on the second storage device; wherein the second storage device is connected to the second container cluster.

10. The method according to claim 9, wherein the method further comprises:

11. The method of claim 9, wherein the first data service further comprises a second sub-service, the second sub-service being located in the first container cluster, the method further comprising:

12. The method according to any one of claims 1-11, wherein:

the first container cluster isAnd the plurality of nodes comprise a Master and Node nodes.

13. A container storage management device, wherein the container storage management device is configured to manage a containerized application, the containerized application being deployed in a first container cluster, the first container cluster comprising a plurality of nodes; the container storage management device comprises a storage relation management module and a plurality of acquisition modules, wherein:

14. The container storage management device of claim 13, wherein the storage relationship management module is further configured to:

15. The container storage management apparatus of claim 13 or 14, wherein a storage topology of the containerized application is used by the plurality of data services to enable migration, backup, dual-activity, or disaster recovery of the containerized application.

16. Container storage management apparatus according to any one of claims 13 to 15, wherein the storage topology comprises a correspondence of objects of a containerized application with a storage directory and/or a correspondence of the storage directory with a physical storage location.

17. The container storage management device of claim 16, wherein the containerized application to volume correspondence comprises one or more of:

18. The container storage management device of any one of claims 13 to 17, wherein the physical storage location contains one or more of the following information:

19. The container storage management device of any one of claims 13 to 18, wherein the storage relationship management module is further configured to:

and synchronizing the storage topology of the containerized application to a second container cluster, wherein the storage topology of the containerized application is used for realizing migration, backup, dual-activity or disaster recovery of the containerized application in the second container cluster.

20. The container storage management apparatus of any one of claims 13 to 19, further providing a first interface for enabling invocation of a storage function provided by the first storage device.

21. The container storage management device of claim 20, further comprising a storage function driver module, the first interface being provided by the container function driver module.

22. The container storage management device of claim 21, wherein the storage function comprises a storage high-speed link, the container storage management device further configured to:

23. The apparatus of any of claims 13-22, wherein the first container cluster isA cluster, the plurality of nodes includingMaster and Node.

24. A service providing system, characterized in that the service providing system comprises a first container storage managing apparatus, the service providing system further provides a plurality of data services including a first data service, the first container storage managing apparatus is the container storage managing apparatus according to any one of claims 11 to 18,

The first container storage management device is located in a first container cluster, and a containerized application is deployed in the first container cluster;

the first data service includes a first sub-service, the first sub-service being located in the second container cluster;

25. The service providing system of claim 24, wherein the plurality of service providing units,

the first container storage management device is further configured to synchronize a storage topology of the containerized application to a second container storage management device in the second container cluster;

26. The service providing system of claim 24, wherein said first data service further comprises a second sub-service, said second sub-service being located in said first container cluster,

27. A service providing system, comprising a first container cluster comprising a plurality of first nodes, the first container cluster having a containerized application deployed therein; the first container cluster has stored therein a first computer program or instructions that are loaded and executed by the first node to cause the first container cluster to perform the container storage management method of any of claims 1-7.

28. The service providing system of claim 27, further comprising a second container cluster comprising a plurality of second nodes, the second container cluster having stored therein a second computer program or instructions that are loaded and executed by the second nodes to cause the second container cluster to perform the method performed by the first sub-service of the data service of any of claims 8-10;

The first container cluster further performs the method performed by the first container storage management device and the second sub-service of the data service as claimed in any of claims 8-10 when the first computer program or instructions are loaded and executed by the first node.

29. A computer readable storage medium comprising computer instructions for implementing the container storage management method of any one of claims 1 to 12.