An Openstack block storage deployment method, system, device and storage medium

Abstract

The application discloses an Openstack block storage deployment method, comprising the following steps: deploying a SAN storage and deploying an OCFS2 cluster; mapping the SAN storage to the OCFS2 cluster; initializing the SAN storage as a file system in response to the OCFS2 cluster detecting the SAN storage; deploying a CTDB service in the OCFS2 cluster; and connecting the Cinder in the Openstack with the CTDB service to make the Openstack connect the block storage. The application further discloses a system, a computer device and a readable storage medium. The application realizes the connection of the Openstack block storage management module Cinder to the OCFS2 cluster by deploying the CTDB service to the OCFS2 cluster and connecting the OpenStack block storage management module Cinder with the CTDB service.

Description

Technical Field

[0001] This invention relates to the field of OpenStack, and more specifically to an OpenStack block storage deployment method, system, device, and storage medium. Background Technology

[0002] OpenStack, as an open-source cloud infrastructure management platform, manages computing, storage, and network devices, providing storage resource management for massive amounts of business data. CTDB, a highly available cluster management software, provides a high-availability solution for storage cluster file systems by managing NFS services. While CTDB itself is not an HA solution, when combined with the OCFS2 cluster file system, it can provide a simple and efficient HA cluster solution. OCFS2 is a shared disk-based cluster file system that allows multiple hosts to access files on the same disk simultaneously while ensuring file consistency. OCFS2 + NFS + CTDB together provide a highly available shared file system.

[0003] OpenStack connects to and manages storage systems by deploying block storage services (Cinder). Common cloud storage systems include GlusterFS network file system, Ceph distributed storage system, and G2 / G5 centralized storage system. OCFS2 is a shared disk file system, also known as a cluster file system, specifically built on network-shared disks. Network-shared disks are accessed by multiple hosts through a SAN (Storage Area Network). Compared to disk file systems like NFS, shared disk file systems not only need to solve the problem of effective disk space management but also the problem of concurrent modification when the file system is accessed and accessed by multiple hosts simultaneously. Therefore, distributed locking mechanisms are a common mechanism in shared disk file systems.

[0004] Since the OpenStack block storage management module Cinder does not provide a driver or solution for OCFS2 integration, OpenStack cannot integrate with OCFS2. Summary of the Invention

[0005] In view of this, in order to overcome at least one aspect of the above problems, embodiments of the present invention propose an OpenStack block storage deployment method, comprising the following steps:

[0006] Deploy SAN storage and deploy OCFS2 clusters;

[0007] Map the SAN storage to the OCFS2 cluster;

[0008] In response to the OCFS2 cluster detecting the SAN storage, the SAN storage is initialized as a file system;

[0009] Deploy the CTDB service in the OCFS2 cluster;

[0010] The CTDB service is used to interface with Cinder in OpenStack to enable the OpenStack to interface with block storage.

[0011] In some embodiments, mapping the SAN storage to the OCFS2 cluster further includes:

[0012] Install iscsi and multipath tools;

[0013] Modify the multipath configuration file;

[0014] Map the raw LUN of the SAN storage to the OCFS2 cluster node.

[0015] In some embodiments, in response to the OCFS2 cluster detecting the SAN storage, initializing the SAN storage as a file system further includes:

[0016] After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping.

[0017] In some embodiments, deploying the CTDB service in the OCFS2 cluster further includes:

[0018] Offers VIP-enabled NFS service with drift capability to external users.

[0019] In some embodiments, utilizing the CTDB service to interface with Cinder in OpenStack to enable the OpenStack interface block storage further includes:

[0020] The Cinder NFS driver is used to interface with NFS services.

[0021] Based on the same inventive concept, according to another aspect of the present invention, embodiments of the present invention also provide an OpenStack block storage deployment system, comprising:

[0022] The first deployment module is configured to deploy SAN storage and OCFS2 cluster;

[0023] The mapping module is configured to map the SAN storage to the OCFS2 cluster;

[0024] The initialization module is configured to initialize the SAN storage as a file system in response to the OCFS2 cluster detecting the SAN storage;

[0025] The second deployment module is configured to deploy the CTDB service in the OCFS2 cluster;

[0026] The docking module is configured to use the CTDB service to dock with Cinder in OpenStack to enable the OpenStack docking block storage.

[0027] In some embodiments, the mapping module is further configured as follows:

[0028] Install iscsi and multipath tools;

[0029] Modify the multipath configuration file;

[0030] Map the raw LUN of the SAN storage to the OCFS2 cluster node.

[0031] In some embodiments, the initialization module is further configured to:

[0032] After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping.

[0033] Based on the same inventive concept, according to another aspect of the present invention, embodiments of the present invention also provide a computer device, comprising:

[0034] At least one processor; and

[0035] A memory storing a computer program that can run on the processor, wherein the processor executes the program and performs the following steps:

[0036] Deploy SAN storage and deploy OCFS2 clusters;

[0037] Map the SAN storage to the OCFS2 cluster;

[0038] In response to the OCFS2 cluster detecting the SAN storage, the SAN storage is initialized as a file system;

[0039] Deploy the CTDB service in the OCFS2 cluster;

[0040] The CTDB service is used to interface with Cinder in OpenStack to enable the OpenStack to interface with block storage.

[0041] In some embodiments, mapping the SAN storage to the OCFS2 cluster further includes:

[0042] Install iscsi and multipath tools;

[0043] Modify the multipath configuration file;

[0044] Map the raw LUN of the SAN storage to the OCFS2 cluster node.

[0045] In some embodiments, in response to the OCFS2 cluster detecting the SAN storage, initializing the SAN storage as a file system further includes:

[0046] After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping.

[0047] In some embodiments, deploying the CTDB service in the OCFS2 cluster further includes:

[0048] Offers VIP-enabled NFS service with drift capability to external users.

[0049] In some embodiments, utilizing the CTDB service to interface with Cinder in OpenStack to enable the OpenStack interface block storage further includes:

[0050] The Cinder NFS driver is used to interface with NFS services.

[0051] Based on the same inventive concept, according to another aspect of the present invention, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the following steps:

[0052] Deploy SAN storage and deploy OCFS2 clusters;

[0053] Map the SAN storage to the OCFS2 cluster;

[0054] In response to the OCFS2 cluster detecting the SAN storage, the SAN storage is initialized as a file system;

[0055] Deploy the CTDB service in the OCFS2 cluster;

[0056] The CTDB service is used to interface with Cinder in OpenStack to enable the OpenStack to interface with block storage.

[0057] In some embodiments, mapping the SAN storage to the OCFS2 cluster further includes:

[0058] Install iscsi and multipath tools;

[0059] Modify the multipath configuration file;

[0060] Map the raw LUN of the SAN storage to the OCFS2 cluster node.

[0061] In some embodiments, in response to the OCFS2 cluster detecting the SAN storage, initializing the SAN storage as a file system further includes:

[0062] After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping.

[0063] In some embodiments, deploying the CTDB service in the OCFS2 cluster further includes:

[0064] Offers VIP-enabled NFS service with drift capability to external users.

[0065] In some embodiments, utilizing the CTDB service to interface with Cinder in OpenStack to enable the OpenStack interface block storage further includes:

[0066] The Cinder NFS driver is used to interface with NFS services.

[0067] The present invention has one of the following beneficial technical effects: The solution proposed in this invention deploys the CTDB service to the OCFS2 cluster and connects the OpenStack block storage management module Cinder through the CTDB service, thereby realizing the connection between the OpenStack block storage management module Cinder and the OCFS2 cluster. Attached Figure Description

[0068] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these drawings without creative effort.

[0069] Figure 1 A flowchart illustrating the OpenStack block storage deployment method provided for an embodiment of the present invention;

[0070] Figure 2 A schematic diagram of the structure of the OpenStack block storage deployment system provided for an embodiment of the present invention;

[0071] Figure 3 A schematic diagram of the structure of a computer device provided for an embodiment of the present invention;

[0072] Figure 4 A schematic diagram of the structure of a computer-readable storage medium provided for an embodiment of the present invention. Detailed Implementation

[0073] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to specific examples and the accompanying drawings.

[0074] It should be noted that all uses of "first" and "second" in the embodiments of the present invention are for the purpose of distinguishing two entities or parameters with the same name but different names. It is clear that "first" and "second" are only for the convenience of expression and should not be construed as limiting the embodiments of the present invention. Subsequent embodiments will not explain this in detail.

[0075] According to one aspect of the present invention, embodiments of the present invention provide an OpenStack block storage deployment method, such as... Figure 1 As shown, it may include the following steps:

[0076] S1, deploy SAN storage and deploy OCFS2 cluster;

[0077] S2, map the SAN storage to the OCFS2 cluster;

[0078] S3, in response to the OCFS2 cluster detecting the SAN storage, initialize the SAN storage as a file system;

[0079] S4, Deploy CTDB service in the OCFS2 cluster;

[0080] S5, use the CTDB service to interface with Cinder in OpenStack to enable the OpenStack interface block storage.

[0081] The proposed solution is to deploy the CTDB service to the OCFS2 cluster and connect the CTDB service to the OpenStack block storage management module Cinder, thereby enabling the OpenStack block storage management module Cinder to connect to the OCFS2 cluster.

[0082] In some embodiments, mapping the SAN storage to the OCFS2 cluster further includes:

[0083] Install iscsi and multipath tools;

[0084] Modify the multipath configuration file;

[0085] Map the raw LUN of the SAN storage to the OCFS2 cluster node.

[0086] Specifically, the SAN storage device management module is responsible for managing SAN storage access, raw LUN mounting, unmounting, etc.

[0087] The deployment details for the SAN storage device management module are as follows:

[0088] a) Installation tools: iscsi, multipath tool

[0089] yum install iscsi-initiator-utils libiscsi;

[0090] yum install device-mapper device-mapper-multipath;

[0091] b) Modify the multipath configuration file / etc / multipath.conf

[0092] c) Map SAN storage raw LUNs to OCFS2 cluster nodes;

[0093] OCFS2 cluster nodes discover iSCSI storage via SAN storage management addresses;

[0094] OCFS2 cluster nodes perform login to SAN storage;

[0095] Configure OCFS2 cluster nodes to automatically map at startup;

[0096] Finally, create raw LUNs of a preset size in the SAN storage as shared disks and map them to each node of the OCFS cluster.

[0097] In some embodiments, in response to the OCFS2 cluster detecting the SAN storage, initializing the SAN storage as a file system further includes:

[0098] After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping.

[0099] Specifically, the cluster file system management module is responsible for deploying OCFS2 management and cluster components, and initializing the OCFS2 cluster file system based on the raw LUNs of SAN storage. Since OCFS2 cluster deployment requires the Linux operating system to have the OCFS2 kernel module installed, the OCFS2 management tools to be started, and the OCFS2 module to be loaded, raw LUNs mounted from SAN storage can be initialized based on OCFS2. The same SAN storage LUN can be mounted on multiple OCFS2 nodes and used as a shared disk.

[0100] The deployment details of the cluster file system management module are as follows:

[0101] a) Install the OCF2 kernel module and management tools;

[0102] b) Disable firewalld and SELinux;

[0103] c) Configure the OCFS2 cluster, with the IP address being the OCFS2 management IP;

[0104] d) Start the OCFS2 management tool and load the module;

[0105] e) Initialize the G2 shared disk;

[0106] mkfs.ocfs2-b4k-C64k-N4-Lg2_ocfs2 / dev / mapper / 3600507670880812d6800000000000094

[0107] Where: -b and -C are the block size and cluster unit size, respectively; b supports 512 bytes to 4k, 4k is the recommended size, suitable for almost all disk sizes; c supports 4k to 1M, 128k is more suitable for large files; -N 4 is the number of nodes +1; -L is the name of the formatted disk.

[0108] f) Mount the OCFS2 shared disk and view the cluster;

[0109] mount-t ocfs2 / dev / sdb1 / mnt / nfs /

[0110] mounted.ocfs2–f.

[0111] In some embodiments, deploying the CTDB service in the OCFS2 cluster further includes:

[0112] Offers VIP-enabled NFS service with drift capability to external users.

[0113] Specifically, the CTDB high availability management module is responsible for deploying the CTDB high availability cluster and managing services such as SAMBA and NFS-SERVER. It provides externally accessible NFS services with a VIP that can be migrated. CTDB manages node members, performs recovery / failover, IP relocation, and monitors the status of NFS services. The CTDB cluster is configured with two sets of IPs: Private IPs for heartbeat and internal cluster communication, and Public IPs for providing virtual access VIPs externally. When an internal node fails, CTDB will schedule other available nodes to take over its previously assigned Public VIP. After the failed node recovers, the migrated Public VIP will be retaken, ensuring uninterrupted service.

[0114] The detailed installation process for the CTDB high availability management module is as follows:

[0115] a) Install CTDB components

[0116] b) CTDB configuration: / etc / ctdb / ctdbd.conf

[0117] c) Start the CTDB service

[0118] The nfs-server service does not need to be started manually; the ctdb service monitors, manages, and starts the nfs service.

[0119] In some embodiments, utilizing the CTDB service to interface with Cinder in OpenStack to enable the OpenStack interface block storage further includes:

[0120] The Cinder NFS driver is used to interface with NFS services.

[0121] Specifically, the OpenStack block storage integration module automatically integrates with the CTDB high-availability cluster based on Cinder's NFS driver, and ultimately enables reading and writing of the OCFS file system. It uses custom configuration based on NFS integration and Ansible to complete the containerized deployment and integration of block storage with NFS via Cinder.

[0122] The deployment details for the OpenStack block storage integration module are as follows:

[0123] a) Add NFS interface configuration

[0124] vim / etc / kolla / config / cinder / nfs_shares

[0125] 10.48.51.185: / mnt / nfs

[0126] 10.48.51.186: / mnt / nfs

[0127] 10.48.51.187: / mnt / nfs

[0128] b) Turn on the NFS docking switch

[0129] vim / etc / kolla / globals.yml

[0130] enable_cinder_backend_nfs:"yes"

[0131] c) Add NFS interface configuration

[0132] vim / etc / kolla / config / cinder / cinder-volume.conf

[0133] [DEFAULT]

[0134] enabled_backends = nfs - 1

[0135] [nfs-1]

[0136] volume_driver=cinder.volume.drivers.nfs.NfsDriver

[0137] nfs_shares_config= / etc / kolla / cinder-volume / nfs_shares

[0138] volume_backend_name = nfs-01

[0139] d) Deploy and interface with NFS

[0140] kolla-ansible deploy-i multinode-t cinder

[0141] Since the OpenStack block storage management module Cinder does not provide a driver or solution for OCFS2 integration, OpenStack block storage solutions based on OCFS2 are not commonly used in project deployments. However, Cinder provides a native NFS driver to support NFS integration. NFS itself lacks cluster file system characteristics and cannot solve the problem of concurrent modifications to the file system when accessed and accessed by multiple hosts simultaneously. This solution leverages Cinder's native NFS integration feature and combines CTDB with OCFS cluster file system management of NFS services to implement an OpenStack block storage deployment solution. Testing has demonstrated good stability and performance.

[0142] Based on the same inventive concept, according to another aspect of the present invention, embodiments of the present invention also provide a mailbox-based remote control system 400, such as... Figure 2 As shown, it includes:

[0143] An OpenStack block storage deployment system includes:

[0144] The first deployment module is configured to deploy SAN storage and OCFS2 cluster;

[0145] The mapping module is configured to map the SAN storage to the OCFS2 cluster;

[0146] The initialization module is configured to initialize the SAN storage as a file system in response to the OCFS2 cluster detecting the SAN storage;

[0147] The second deployment module is configured to deploy the CTDB service in the OCFS2 cluster;

[0148] The docking module is configured to use the CTDB service to dock with Cinder in OpenStack to enable the OpenStack docking block storage.

[0149] In some embodiments, the mapping module is further configured as follows:

[0150] Install iscsi and multipath tools;

[0151] Modify the multipath configuration file;

[0152] Map the raw LUN of the SAN storage to the OCFS2 cluster node.

[0153] In some embodiments, the initialization module is further configured to:

[0154] After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping.

[0155] Based on the same inventive concept, according to another aspect of the present invention, such as Figure 3 As shown, embodiments of the present invention also provide a computer device 501, comprising:

[0156] At least one processor 520; and

[0157] Memory 510 stores a computer program 511 that can run on a processor. When the processor 520 executes the program, it performs the following steps:

[0158] Deploy SAN storage and deploy OCFS2 clusters;

[0159] Map the SAN storage to the OCFS2 cluster;

[0160] In response to the OCFS2 cluster detecting the SAN storage, the SAN storage is initialized as a file system;

[0161] Deploy the CTDB service in the OCFS2 cluster;

[0162] The CTDB service is used to interface with Cinder in OpenStack to enable the OpenStack to interface with block storage.

[0163] In some embodiments, mapping the SAN storage to the OCFS2 cluster further includes:

[0164] Install iscsi and multipath tools;

[0165] Modify the multipath configuration file;

[0166] Map the raw LUN of the SAN storage to the OCFS2 cluster node.

[0167] In some embodiments, in response to the OCFS2 cluster detecting the SAN storage, initializing the SAN storage as a file system further includes:

[0168] After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping.

[0169] In some embodiments, deploying the CTDB service in the OCFS2 cluster further includes:

[0170] Offers VIP-enabled NFS service with drift capability to external users.

[0171] In some embodiments, utilizing the CTDB service to interface with Cinder in OpenStack to enable the OpenStack interface block storage further includes:

[0172] The Cinder NFS driver is used to interface with NFS services.

[0173] Based on the same inventive concept, according to another aspect of the present invention, such as Figure 4 As shown, embodiments of the present invention also provide a computer-readable storage medium 601, which stores a computer program 610. When the computer program 610 is executed by a processor, it performs the following steps:

[0174] Deploy SAN storage and deploy OCFS2 clusters;

[0175] Map the SAN storage to the OCFS2 cluster;

[0176] In response to the OCFS2 cluster detecting the SAN storage, the SAN storage is initialized as a file system;

[0177] Deploy the CTDB service in the OCFS2 cluster;

[0178] The CTDB service is used to interface with Cinder in OpenStack to enable the OpenStack to interface with block storage.

[0179] In some embodiments, mapping the SAN storage to the OCFS2 cluster further includes:

[0180] Install iscsi and multipath tools;

[0181] Modify the multipath configuration file;

[0182] Map the raw LUN of the SAN storage to the OCFS2 cluster node.

[0183] In some embodiments, in response to the OCFS2 cluster detecting the SAN storage, initializing the SAN storage as a file system further includes:

[0184] After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping.

[0185] In some embodiments, deploying the CTDB service in the OCFS2 cluster further includes:

[0186] Offers VIP-enabled NFS service with drift capability to external users.

[0187] In some embodiments, utilizing the CTDB service to interface with Cinder in OpenStack to enable the OpenStack interface block storage further includes:

[0188] The Cinder NFS driver is used to interface with NFS services.

[0189] Finally, it should be noted that those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods.

[0190] Furthermore, it should be understood that the computer-readable storage medium (e.g., memory) described herein may be volatile memory or non-volatile memory, or may include both volatile memory and non-volatile memory.

[0191] Those skilled in the art will also understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in conjunction with the disclosure herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the functionality of various illustrative components, blocks, modules, circuits, and steps has been generally described. Whether this functionality is implemented as software or as hardware depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art can implement the functionality in various ways for each specific application, but such implementation decisions should not be construed as departing from the scope of the embodiments disclosed herein.

[0192] The above are exemplary embodiments disclosed in this invention. However, it should be noted that various changes and modifications can be made without departing from the scope of the embodiments of this invention as defined by the claims. The functions, steps, and / or actions of the methods according to the disclosed embodiments described herein do not need to be performed in any particular order. Furthermore, although the elements disclosed in the embodiments of this invention may be described or claimed individually, they may be understood as multiple unless explicitly limited to a singular number.

[0193] It should be understood that, as used herein, the singular form “a” is intended to include the plural form as well, unless the context clearly supports an exception. It should also be understood that, as used herein, “and / or” refers to any and all possible combinations of one or more of the associated listed items.

[0194] The embodiment numbers disclosed in the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0195] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0196] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of the invention (including the claims) is limited to these examples. Within the framework of the invention, technical features of the above embodiments or different embodiments can be combined, and many other variations of different aspects of the invention exist, which are not provided in the details for the sake of brevity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

Claims

1. An OpenStack block storage deployment method, characterized in that, Includes the following steps: Deploy SAN storage and deploy OCFS2 clusters; Map the SAN storage to the OCFS2 cluster; In response to the OCFS2 cluster detecting the SAN storage, the SAN storage is initialized as a file system; Deploy the CTDB service in the OCFS2 cluster; The CTDB service is used to interface with Cinder in OpenStack to enable the OpenStack interface block storage; Mapping the SAN storage to the OCFS2 cluster further includes: Install iscsi and multipath tools; Modify the multipath configuration file; Map the raw LUN of the SAN storage to the OCFS2 cluster node; In response to the OCFS2 cluster detecting the SAN storage, the SAN storage is initialized as a file system, further including: After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping. Deploying the CTDB service in the OCFS2 cluster further includes: Offers VIP driftable NFS service to external users; Utilizing the CTDB service to interface with Cinder in OpenStack to enable the OpenStack interface block storage, further includes: The Cinder NFS driver is used to interface with NFS services.

2. An OpenStack block storage deployment system, characterized in that, include: The first deployment module is configured to deploy SAN storage and OCFS2 cluster; The mapping module is configured to map the SAN storage to the OCFS2 cluster; The initialization module is configured to initialize the SAN storage as a file system in response to the OCFS2 cluster detecting the SAN storage; The second deployment module is configured to deploy the CTDB service in the OCFS2 cluster; The docking module is configured to use the CTDB service to dock with Cinder in OpenStack to enable the OpenStack docking block storage; The mapping module is also configured as follows: Install iscsi and multipath tools; Modify the multipath configuration file; Map the raw LUN of the SAN storage to the OCFS2 cluster node; The initialization module is also configured as follows: After installing the OCFS2 kernel module, starting the OCFS2 management tool and loading the OCFS2 kernel module, initialize the raw LUN of the SAN storage mapping. The second deployment module is also configured as follows: Offers VIP driftable NFS service to external users; The docking module is also configured as follows: The Cinder NFS driver is used to interface with NFS services.

3. A computer device, comprising: At least one processor; as well as A memory storing a computer program executable on the processor, characterized in that the processor executes the steps of the method as described in claim 1 when executing the program.

4. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it performs the steps of the method as described in claim 1.

Images