Universal storage adaptation method for cloud computing platform

Abstract

The invention provides a universal storage adaptation method for a cloud computing platform, which belongs to the technical field of cloud computing, and is characterized in that an OpenStack Cinder is cut, only a driver of a butt-joint storage manufacturer and a relevant part of a configuration file are reserved, an API (Application Program Interface) entry and business logic are self-researched to form an IaaS (Infrastructure as a Service) micro-service storage adapter storage-cinder, and RESTful interfaces such as volumes, snapshots and the like are externally provided. When new storage is docked, information such as a management IP and a storage pool is collected, a corresponding cinder driver file is obtained and put into a K8S specified directory, and ciner.conf is edited and written into back-end configuration; and the cloud platform block storage service calls an adapter interface through a driver of the cloud platform block storage service to complete operations such as management and subsequent creation, deletion, mounting, unloading and the like. According to the scheme, the new storage adaptation development and joint debugging workload is reduced, and the delivery efficiency is improved.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing technology, and in particular relates to a general storage adaptation method for cloud computing platforms. Background Technology

[0002] In cloud computing platforms, block storage devices typically come from different manufacturers, series, and versions, with varying interfaces and functionalities. Current practices often require the cloud platform to research the interface of each new storage device and perform customized adaptation and integration testing, with additional adjustments needed to ensure compatibility between different versions. Furthermore, many devices are only available at the customer's site, making coordination and integration difficult. When project deadlines are tight, these factors can easily lead to delays in cloud platform version releases and delivery difficulties. Summary of the Invention

[0003] In view of this, the present invention aims to propose a universal storage adaptation method for cloud computing platforms to at least solve one of the problems in the background art.

[0004] To achieve the above objectives, the technical solution of the present invention is implemented as follows:

[0005] A general storage adaptation method for cloud computing platforms, applied to the IaaS microservice storage adapter in the cloud platform management area, the method comprising:

[0006] Receive storage operation requests from cloud platform block storage services, wherein the storage operation requests carry at least the storage backend identifier, operation type, and operation parameters;

[0007] Based on the storage backend identifier, new storage device information corresponding to the storage backend identifier is parsed from the configuration file. The new storage device information includes at least the management address and storage pool information.

[0008] Locate the cinder driver file corresponding to the storage backend identifier in the preset driver directory, and initialize a driver class instance based on the configuration file and the cinder driver file;

[0009] The storage operation request is mapped to a function call to the driver class instance to perform the creation, deletion, mounting or unmounting of cloud disks or snapshots, and the execution result is returned to the cloud platform block storage service as a RESTful interface response.

[0010] The cloud platform's block storage service side records the resource metadata corresponding to the storage operation request for cloud platform management and querying.

[0011] Furthermore, the preset driver directory is the designated mount directory of the container orchestration platform Kubernetes; when connecting to a new storage device type, the cinder driver file provided by the storage vendor is placed in the preset driver directory and the configuration file is edited, so that the cloud platform can manage the new storage device type without modifying the business code.

[0012] Furthermore, the parsing configuration file includes: configuring independent backend configuration sections for different storage backends, each backend configuration section including at least a backend identifier, management address, storage pool name, and driver class path; the storage backend identifier is used to select the corresponding backend configuration section when multiple storage devices coexist.

[0013] Furthermore, before initializing the driver class instance, an integrity check is performed on the required fields in the configuration file corresponding to the storage backend identifier, and a loadability check is performed on the cinder driver file. When the check fails, an error response containing the failure field and the reason for failure is returned to prevent management failure or misoperation caused by incorrect configuration.

[0014] Furthermore, the IaaS microservice storage adapter trims down the OpenStack Cinder, retaining only the driver portion for interfacing with various storage vendors and related configuration files. The IaaS microservice storage adapter also develops its own RESTful entry point and business orchestration logic to provide a unified storage operation interface to the cloud platform block storage service.

[0015] Furthermore, the IaaS microservice storage adapter maintains a driver instance cache table, where the cache key includes at least the storage backend identifier. When a subsequent storage operation request with the same storage backend identifier is received, the initialized driver class instance is reused, and the driver instance cache table is invalidated and rebuilt when a change in the configuration file or driver file is detected.

[0016] Furthermore, the storage operation request includes volume operations and snapshot operations; the volume operations include at least creating a volume, deleting a volume, mounting a volume, and unmounting a volume, and the snapshot operations include at least creating a snapshot and deleting a snapshot; the operation parameters include at least one or more of the following: cloud disk identifier, capacity, target host, or target mount point identifier.

[0017] Furthermore, the storage operation request also carries a tenant identifier and an availability zone identifier; the IaaS microservice storage adapter selects the corresponding storage backend identifier from the configuration file based on the tenant identifier and availability zone identifier, or verifies the operation parameters to restrict storage access across tenants and across availability zones.

[0018] Furthermore, this solution discloses a general storage adaptation system for cloud computing platforms, including:

[0019] The interface access module is used to receive storage operation requests from the cloud platform's block storage service via RESTful API and return the execution results.

[0020] The configuration parsing module is used to parse the corresponding new storage device information from the cinder.conf configuration file based on the storage backend identifier;

[0021] The driver management module is used to load the Cinder driver file in the preset driver directory and initialize the driver class instance based on the new storage device information;

[0022] The operation orchestration module is used to map the storage operation request to a function call to the driver class instance to complete the creation, deletion, mounting or unmounting of cloud disks or snapshots;

[0023] The result output module is used to return the execution result to the cloud platform block storage service and output resource metadata that can be used for platform recording.

[0024] Furthermore, the driver management module also includes a driver change detection unit, which is used to detect changes in driver files in the preset driver directory and / or detect changes in the cinder.conf configuration file, and trigger the reconstruction of the corresponding driver class instance to support the rapid access of new storage device types and online updates of storage backend configurations.

[0025] Compared with existing technologies, the general storage adaptation method for cloud computing platforms described in this invention has the following advantages:

[0026] (1) This invention decouples the storage interface capability from the cloud platform block storage service, independently implements a microservice-based storage adapter and provides a unified RESTful interface to the outside world, so that the upper-layer block storage service can complete operations such as volume and snapshot in a consistent calling manner, thereby reducing the impact of interface differences between different storage vendors on the platform capability implementation, reducing the workload of repeated development and debugging on the platform side, and improving the efficiency and maintainability of storage capability expansion.

[0027] (2) By trimming Cinder, this invention retains only the core parts related to the driver and configuration file. The adapter loads the corresponding driver file and parses the configuration parameters at runtime. After the backend selects and initializes the driver instance, the access of new storage types can be completed by "deploying driver files + updating configuration files". There is no need to modify the upper-layer business code or rebuild the entire block storage service. This significantly reduces the implementation threshold of new storage management and shortens the delivery cycle.

[0028] (3) When processing storage operation requests, the present invention parses the corresponding management address and storage pool information from the configuration file according to the storage backend identifier carried in the request, and maps the request to a function call to the driver instance to complete operations such as creation, deletion, mounting, unmounting and snapshot, so that each operation can be clearly attributed to the specific backend and specific driver path, which facilitates the platform side to uniformly record and query resource metadata, reduce the risk of misoperation in the scenario of multiple backends coexisting and improve the efficiency of fault location.

[0029] (4) This invention connects storage information collection, driver acquisition and deployment, configuration writing, interface management, volume / snapshot full lifecycle operation and resource information entry into the database through a unified management and calling link. This enables the platform to quickly complete access and verification according to the standard process even when there are difficulties in device coordination and large differences in the versions of field devices. It also maintains a consistent implementation method and operation and maintenance approach when expanding more storage backends in the future, thereby improving the stability of large-scale delivery. Attached Figure Description

[0030] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0031] Figure 1 This is a schematic diagram of the overall system architecture of the cloud computing platform interfacing with block storage according to an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram of the cloud computing platform storage adapter architecture according to an embodiment of the present invention. Detailed Implementation

[0033] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0034] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0035] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0036] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0037] In one embodiment, the cloud platform's management area deploys block storage services and general storage adapter microservices. The general storage adapter runs independently as a storage-cinder, providing RESTful APIs for volumes and snapshots. Internally, the adapter reuses the driver capabilities and configuration parsing capabilities related to interfacing with storage vendors from OpenStack Cinder, and removes other platform-independent components. The adapter itself develops and implements logic such as request entry, request orchestration, and return encapsulation, enabling the upper-layer block storage service to complete storage operations without directly integrating storage vendor SDKs or private interfaces.

[0038] In a viable deployment approach, storage-cinder runs as a container within a Kubernetes cluster. The container mounts a driver directory and a configuration directory. The driver directory stores the cinder driver files for each storage vendor, while the configuration directory stores the cinder.conf file. The cinder.conf file employs a multi-backend configuration approach. Each backend configuration section includes at least the following parameters: backend identifier (backend_name), driver classpath (e.g., volume_driver or equivalent), management address, authentication information, and storage pool name or pool identifier. These parameters are used to accurately select the target backend when multiple storage devices coexist, and to provide the necessary context for subsequent driver initialization.

[0039] When a new storage device type needs to be connected, this embodiment completes the management process as follows: First, collect information about the new storage device, including management IP, storage pool name, etc.; second, obtain the cinder driver file corresponding to the storage device and place it in the specified mount directory of K8S; then, edit cinder.conf to add or update the corresponding backend configuration section, and write the new storage device information and driver class path; finally, the cloud platform block storage service calls the storage-cinder interface through its own driver layer, so that the new storage device is managed by the cloud platform as a backend and is in a callable state.

[0040] In an optional implementation, to avoid misoperation due to configuration errors, storage-cinder performs integrity and availability checks on the target backend upon first call or when it is managed, including the integrity of required fields, driver class loadability, backend management address connectivity, and authentication validity. If the check fails, it returns an error response containing the failure field and the reason for the failure, and prevents further write operations such as creation and deletion from being performed on the backend.

[0041] When performing volume / snapshot operations on the cloud platform, the upper-layer block storage service sends operation requests to storage-cinder via a RESTful API. The request carries at least the backend identifier (backend_name), operation type, and operation parameters, which may include the volume identifier, capacity, target host, or target mount point identifier. Upon receiving the request, storage-cinder parses the corresponding backend's management address and storage pool information from cinder.conf based on the backend_name, and initializes a driver instance using the driver files already deployed in the driver directory. It then maps the request to function calls on the driver instance to perform operations such as creating, deleting, mounting, and unmounting volumes, as well as creating and deleting snapshots. The execution results are then encapsulated into a RESTful response and returned to the upper-layer block storage service.

[0042] In an optional implementation, to reduce the overhead of repeated initialization, storage-cinder maintains a driver instance cache with `backend_name` as the key: when subsequent requests hit the same `backend_name`, the already initialized instance is reused; when a change is detected in `cinder.conf` or the driver file (e.g., determined by file timestamps, hash values, or hot update notifications), the cache is invalidated and the driver instance is rebuilt to ensure that configuration updates take effect promptly and to avoid mixing old and new configurations. In concurrent scenarios, backend-level mutual exclusion control can be added to the parsing of configurations, initialization of instances, and execution of business processes to ensure that instance rebuilding occurs only once for the same backend at any given time.

[0043] In an optional implementation, to improve maintainability and traceability, storage-cinder generates a request context and records log fields for each storage operation. These fields include at least request_id, backend_name, driver class identifier or driver version fingerprint, input parameter summary, start time, end time, return code, and exception summary. When a driver call fails, cleanup actions are performed according to preset rules (e.g., reclaiming residual resources if volume creation fails) and the reason for failure is passed to the upper-layer block storage service for unified alerting and retries. After receiving a successful response, the upper-layer block storage service stores the resource metadata of the volume / snapshot in its database. This metadata includes at least the cloud platform-side resource identifier, backend_name identifier, storage pool identifier, and vendor-side unique resource identifier, thereby supporting subsequent queries, auditing, and fault location.

[0044] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A general storage adaptation method for cloud computing platforms, characterized in that, An IaaS microservice storage adapter applied to a cloud platform management area, the method comprising: Receive storage operation requests from cloud platform block storage services, wherein the storage operation requests carry at least the storage backend identifier, operation type, and operation parameters; Based on the storage backend identifier, new storage device information corresponding to the storage backend identifier is parsed from the configuration file. The new storage device information includes at least the management address and storage pool information. Locate the cinder driver file corresponding to the storage backend identifier in the preset driver directory, and initialize a driver class instance based on the configuration file and the cinder driver file; The storage operation request is mapped to a function call to the driver class instance to perform the creation, deletion, mounting or unmounting of cloud disks or snapshots, and the execution result is returned to the cloud platform block storage service as a RESTful interface response. The cloud platform's block storage service side records the resource metadata corresponding to the storage operation request for cloud platform management and querying.

2. The method according to claim 1, characterized in that, The preset driver directory is the designated mount directory of the container orchestration platform Kubernetes. When connecting to a new storage device type, the cinder driver file provided by the storage vendor is placed in the preset driver directory and the configuration file is edited, so that the cloud platform can manage the new storage device type without modifying the business code.

3. The method according to claim 1, characterized in that, The parsing configuration file includes: configuring independent backend configuration sections for different storage backends, each backend configuration section including at least a backend identifier, management address, storage pool name, and driver class path; the storage backend identifier is used to select the corresponding backend configuration section when multiple storage devices coexist.

4. The method according to claim 1, characterized in that, Before initializing the driver class instance, integrity checks are performed on the required fields in the configuration file corresponding to the storage backend identifier, and loadability checks are performed on the Cinder driver file. If the checks fail, an error response containing the failure field and the reason for failure is returned to prevent management failures or misoperations caused by incorrect configuration.

5. The method according to claim 1, characterized in that, The IaaS microservice storage adapter trims down OpenStackCinder, retaining only the driver portion for interfacing with various storage vendors and related configuration files. The IaaS microservice storage adapter also develops its own RESTful entry point and business orchestration logic to provide a unified storage operation interface to the cloud platform's block storage service.

6. The method according to claim 1, characterized in that, The IaaS microservice storage adapter maintains a driver instance cache table, where the cache key includes at least the storage backend identifier. When a subsequent storage operation request with the same storage backend identifier is received, the initialized driver class instance is reused, and the driver instance cache table is invalidated and rebuilt when a change in the configuration file or driver file is detected.

7. The method according to claim 1, characterized in that, The storage operation request includes volume operations and snapshot operations; the volume operations include at least creating a volume, deleting a volume, mounting a volume, and unmounting a volume, and the snapshot operations include at least creating a snapshot and deleting a snapshot; the operation parameters include at least one or more of the following: cloud disk identifier, capacity, target host, or target mount point identifier.

8. The method according to claim 1, characterized in that, The storage operation request also carries a tenant identifier and an availability zone identifier; the IaaS microservice storage adapter selects the corresponding storage backend identifier from the configuration file based on the tenant identifier and availability zone identifier, or verifies the operation parameters to restrict storage access across tenants and availability zones.

9. A universal storage adaptation system for cloud computing platforms, characterized in that, include: The interface access module is used to receive storage operation requests from the cloud platform's block storage service via RESTful API and return the execution results. The configuration parsing module is used to parse the corresponding new storage device information from the cinder.conf configuration file based on the storage backend identifier; The driver management module is used to load the Cinder driver file in the preset driver directory and initialize the driver class instance based on the new storage device information; The operation orchestration module is used to map the storage operation request to a function call to the driver class instance to complete the creation, deletion, mounting or unmounting of cloud disks or snapshots; The result output module is used to return the execution result to the cloud platform block storage service and output resource metadata that can be used for platform recording.

10. The system according to claim 9, characterized in that, The driver management module also includes a driver change detection unit, which is used to detect changes in driver files in the preset driver directory and / or detect changes in the cinder.conf configuration file, and trigger the reconstruction of the corresponding driver class instance to support the rapid access of new storage device types and online updates of storage backend configurations.

Images