Shared storage virtualization method and device, electronic equipment and storage medium

Abstract

The invention provides a shared storage virtualization method and device, electronic equipment and a storage medium, and the method comprises the steps: creating at least two mapping volumes in a storage cluster, mapping the at least two mapping volumes to nodes of a cloud computing platform, and building the nodes of the cloud computing platform into a redundant node cluster; constructing the at least two mapping volumes into an aggregation storage device, and creating a shared volume group based on the aggregation storage device; loading and configuring nodes of the shared volume group in the redundant node cluster based on the cluster management component, and creating a distributed lock space in the redundant node cluster to manage device resources of the shared volume group; and before any node executes the logical volume operation on the shared volume group, the operation authority is obtained from the distributed lock space, and the logical volume operation is executed based on the operation authority. Compared with the prior art, the redundancy and the overall availability of the system can be improved, the integrity and the consistency of the data are ensured, the performance of the system is improved, and the performance bottleneck is eliminated.

Description

Technical Field

[0001] The present disclosure relates to the technical field of cloud computing, and in particular to a method and apparatus for shared storage virtualization, an electronic device, and a storage medium. Background Art

[0002] When current cloud computing systems use a Logical Volume Manager (LVM) for backend storage, they typically use a VG as a storage pool and divide the VG into LVs to serve as cloud disks. However, this storage architecture is prone to single points of failure and lacks redundancy, making it impossible to achieve high system availability. Numerous technical solutions have been proposed to address the lack of redundancy in storage structures. However, these solutions fail to effectively address performance bottlenecks while resolving storage system redundancy issues, severely restricting the overall performance of cloud computing systems. Therefore, a new technical solution is urgently needed to improve system performance and eliminate performance bottlenecks. Summary of the Invention

[0003] The present disclosure provides a method and apparatus for shared storage virtualization, an electronic device, and a storage medium, the main purpose of which is to solve the problem that cloud computing storage systems cannot fully utilize their performance.

[0004] According to a first aspect of the present disclosure, a method for shared storage virtualization is provided, comprising:

[0005] Creating at least two mapping volumes in the storage cluster, and mapping the at least two mapping volumes to nodes of the cloud computing platform, wherein the nodes of the cloud computing platform are deployed with a cluster management component, and the nodes of the cloud computing platform are organized into a redundant node cluster;

[0006] Building at least two mapped volumes into an aggregate storage device, and creating a shared volume group based on the aggregate storage device;

[0007] Based on the cluster management component, the shared volume group is loaded and configured on the nodes in the redundant node cluster, and a distributed lock space is created in the redundant node cluster to manage the device resources of the shared volume group;

[0008] Before any node performs a logical volume operation on a shared volume group, it obtains the operation permission from the distributed lock space and performs the logical volume operation based on the operation permission.

[0009] Optionally, creating at least two mapping volumes in the storage cluster and mapping the at least two mapping volumes to nodes of the cloud computing platform includes:

[0010] Creating at least two mapping volumes of equal size in at least one storage cluster, and generating identities of the at least two mapping volumes;

[0011] At least two mapped volumes are mapped to nodes of the cloud computing platform in a predetermined mapping manner, and a storage connection is established between the nodes of the cloud computing platform and the at least two mapped volumes.

[0012] Optionally, the method further includes:

[0013] The control service is deployed in the control node of each cloud computing platform. When any control node fails, the cluster management component controls other control nodes to perform resource takeover.

[0014] Optionally, at least two mapped volumes are constructed into an aggregate storage device, and a shared volume group is created based on the aggregate storage device, including:

[0015] On the target control node, the devices corresponding to at least two mapped volumes are constructed into a redundant disk array to generate an aggregate storage device, and its metadata is stored in all member devices;

[0016] The aggregate storage device is initialized as a physical device of the disk manager through the target control node, and the physical device is created as a shared volume group, wherein a resource dependency relationship is configured between the shared volume group and the aggregate storage device.

[0017] Optionally, based on the cluster management component, load and configure the shared volume group on the nodes in the redundant node cluster, and create a distributed lock space in the redundant node cluster to manage the device resources of the shared volume group, including:

[0018] Based on the resource dependency, resource proxy configuration is performed on the shared volume group and the aggregate storage device in the remaining nodes of the redundant node cluster, wherein the remaining nodes are nodes in the redundant node cluster other than the target control node;

[0019] Mount distributed locks on nodes in a redundant node cluster and create distributed lock spaces based on the nodes where distributed locks have been mounted.

[0020] Based on the distributed lock space, access to device resources of the shared volume group is controlled and managed.

[0021] Optionally, before any node performs a logical volume operation on a shared volume group, it obtains the operation permission from the distributed lock space and performs the logical volume operation based on the operation permission, including:

[0022] Based on the operation type of the logical volume operation, any node applies for operation permission from the distributed lock space;

[0023] Based on operation permissions, any node performs logical volume operations on the shared volume group and controls the access of other nodes at the same time.

[0024] Optional operation permissions include creation permission and mounting permission;

[0025] Depending on the type of logical volume operation, any node applies to the distributed lock space for operation permissions, including:

[0026] If the logical volume operation is to create a logical volume for the control node, the control node applies for creation permission from the distributed lock space;

[0027] If the logical volume operation is to mount a logical volume to a virtual machine in a computing node, the computing node applies for mounting permission from the distributed lock space.

[0028] Optionally, based on the operation permissions, any node can perform logical volume operations on the shared volume group, including:

[0029] Based on the creation permissions, the control node creates the logical volume in the shared volume group and notifies other nodes in the redundant node cluster to update the metadata;

[0030] Based on the mount permission, the computing node obtains the volume information of the target logical volume to be mounted from the control node, activates the target logical volume, and maps the target logical volume to the virtual machine.

[0031] According to a second aspect of the present disclosure, a device for shared storage virtualization is provided, comprising:

[0032] A mapping unit, configured to create at least two mapping volumes in the storage cluster and map the at least two mapping volumes to nodes of the cloud computing platform, wherein the nodes of the cloud computing platform are deployed with a cluster management component and organize the nodes of the cloud computing platform into a redundant node cluster;

[0033] A construction unit, configured to construct at least two mapped volumes into an aggregate storage device, and create a shared volume group based on the aggregate storage device;

[0034] A configuration unit is used to load and configure the shared volume group on the nodes in the redundant node cluster based on the cluster management component, and to create a distributed lock space in the redundant node cluster to manage the device resources of the shared volume group;

[0035] The execution unit is used to obtain the operation permission from the distributed lock space before any node performs a logical volume operation on the shared volume group, and perform the logical volume operation based on the operation permission.

[0036] Optionally, the mapping unit includes:

[0037] A first generating module is configured to create at least two mapping volumes of equal size in at least one storage cluster, and generate identities of the at least two mapping volumes;

[0038] The mapping module is used to map at least two mapping volumes to nodes of the cloud computing platform in a predetermined mapping manner, and the nodes of the cloud computing platform establish a storage connection with the at least two mapping volumes.

[0039] Optionally, the shared storage virtualization device further includes:

[0040] The control unit is used to deploy control services in the control nodes of each cloud computing platform. When any control node fails, the cluster management component controls other control nodes to perform resource takeover.

[0041] Optionally, the building blocks include:

[0042] A second generation module is configured to construct devices corresponding to at least two mapped volumes into a redundant disk array at the target control node to generate an aggregate storage device, the metadata of which is stored in all member devices;

[0043] The first creation module is configured to initialize the aggregate storage device as a physical device of the disk manager through the target control node, and create the physical device as a shared volume group, wherein the shared volume group and the aggregate storage device are configured with a resource dependency relationship.

[0044] Optionally, the configuration unit includes:

[0045] A configuration module configured to perform resource proxy configuration of the shared volume group and the aggregate storage device in the remaining nodes of the redundant node cluster based on resource dependencies, wherein the remaining nodes are nodes in the redundant node cluster other than the target control node;

[0046] The second creation module is used to mount a distributed lock on a node in a redundant node cluster and create a distributed lock space based on the node with the mounted distributed lock;

[0047] The control module is used to control access to device resources of the shared volume group based on the distributed lock space.

[0048] Optionally, the execution unit includes:

[0049] The application module is used to allow any node to apply for operation permissions from the distributed lock space based on the operation type of the logical volume operation;

[0050] The execution module is used to allow any node to perform logical volume operations on the shared volume group based on operation permissions, and simultaneously control the access of other nodes.

[0051] Optional operation permissions include creation permission and mounting permission;

[0052] The application module is also used to:

[0053] If the logical volume operation is to create a logical volume for the control node, the control node applies for creation permission from the distributed lock space;

[0054] If the logical volume operation is to mount a logical volume to a virtual machine in a computing node, the computing node applies for mounting permission from the distributed lock space.

[0055] Optionally, the execution module is further configured to:

[0056] Based on the creation permissions, the control node creates the logical volume in the shared volume group and notifies other nodes in the redundant node cluster to update the metadata;

[0057] Based on the mount permission, the computing node obtains the volume information of the target logical volume to be mounted from the control node, activates the target logical volume, and maps the target logical volume to the virtual machine.

[0058] According to a third aspect of the present disclosure, there is provided an electronic device, including:

[0059] at least one processor; and

[0060] a memory communicatively connected to the at least one processor; wherein,

[0061] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the shared storage virtualization method described in the first aspect.

[0062] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable the computer to execute the shared storage virtualization method described in the first aspect.

[0063] According to a fifth aspect of the present disclosure, a computer program product is provided, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the shared storage virtualization method as described in the first aspect.

[0064] The present disclosure provides a method and apparatus for shared storage virtualization, an electronic device, and a storage medium, relating to the field of cloud computing technology. Compared to related technologies, the present disclosure creates at least two mapped volumes in a storage cluster and maps them to cloud computing platform nodes. These nodes are then organized into a redundant node cluster using a cluster management component. If a mapped volume or node fails, the other mapped volumes and nodes continue to function normally, ensuring uninterrupted service and improving system redundancy and overall availability. By constructing at least two mapped volumes into an aggregated storage device and creating a shared volume group, storage resources can be integrated and managed uniformly. A distributed lock space is created within the redundant node cluster based on the cluster management component to manage the device resources of the shared volume group. Before any node can perform logical volume operations on the shared volume group, it must obtain operation permissions from the distributed lock space. This mechanism effectively avoids data conflicts and inconsistencies that may arise when multiple nodes operate on the shared volume group simultaneously, ensuring data integrity and consistency. By organizing the nodes of the cloud computing platform into a redundant node cluster and utilizing the shared volume group and distributed lock space management mechanisms, the risk of system failure caused by a single node or storage device failure is reduced. Even if a node fails, other nodes can quickly take over and continue operations on the shared volume group. Furthermore, the presence of a distributed lock space ensures that device resource management for the shared volume group remains consistent during node failover, further reducing the impact of single points of failure on the system. Nodes in a redundant node cluster can directly access storage resources within the storage system, eliminating the need for data access through the control node. This improves system performance and eliminates performance bottlenecks.

[0065] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] The accompanying drawings are provided to facilitate a better understanding of the present invention and do not constitute a limitation of the present disclosure.

[0067] Figure 1 A flowchart of a shared storage virtualization method provided by an embodiment of the present disclosure;

[0068] Figure 2 A flowchart of another shared storage virtualization method provided by an embodiment of the present disclosure;

[0069] Figure 3 A schematic diagram of a cloud computing platform framework provided by an embodiment of the present disclosure;

[0070] Figure 4 A schematic diagram of the structure of a shared storage virtualization device provided in an embodiment of the present disclosure;

[0071] Figure 5 A schematic diagram of the structure of another shared storage virtualization device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0072] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding. These details should be considered as merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0073] The following describes the shared storage virtualization method and apparatus, electronic device, and storage medium according to embodiments of the present disclosure with reference to the accompanying drawings.

[0074] Figure 1 A flowchart of a shared storage virtualization method provided by an embodiment of the present disclosure.

[0075] like Figure 1 As shown, the method comprises the following steps:

[0076] Step 101: Create at least two mapping volumes in a storage cluster and map the at least two mapping volumes to nodes of a cloud computing platform. The nodes of the cloud computing platform are deployed with cluster management components, and the nodes of the cloud computing platform are organized into a redundant node cluster.

[0077] In an embodiment of the present disclosure, at least two mapped volumes are created within a storage cluster. This operation is intended to provide multi-source data storage carriers for subsequent storage resource allocation and management. These mapped volumes serve as logical abstractions of storage resources, providing accessible data storage portals for nodes on the cloud computing platform. A storage cluster can be a collection of multiple storage devices connected via a network. These storage devices can be of the same type and from the same vendor, collectively providing unified storage services for the cloud computing platform. Alternatively, they can be a mix of storage devices from different vendors and models, working together through specific technical means to provide storage resources for upper-layer applications. A storage cluster can be built based on traditional disk array technology, utilizing high-speed Fibre Channel or Ethernet to connect individual storage units, or it can adopt a distributed storage architecture, distributing data across multiple nodes and ensuring data security and reliability through redundancy and fault tolerance mechanisms. A storage cluster can be managed in a centralized manner, with a dedicated management node centrally scheduling and allocating storage resources, or it can adopt a distributed management model, with each node managing itself and working collaboratively to a certain extent. This disclosure is not limited in this regard.

[0078] Map at least two mapped volumes to the nodes of the cloud computing platform. This mapping process is implemented through specific communication protocols and interface technologies, ensuring that the nodes of the cloud computing platform can identify and access the storage resources corresponding to these mapped volumes. A cluster management component is pre-deployed on the nodes of the cloud computing platform, which plays a role in coordination and control across the entire system. With the help of the cluster management component, the nodes of the cloud computing platform can be organized into a redundant node cluster. The cluster management component uses a series of complex algorithms and mechanisms to monitor the status of each node, schedule resources, and detect and recover from faults. This ensures that critical services or applications can continue to operate even in the event of node failure, network interruption, or resource anomaly, thereby eliminating the risk of single points of failure.

[0079] Creating multiple mapped volumes and mapping them to nodes provides the cloud computing platform with rich and flexibly deployable storage resources, meeting the diverse storage capacity and performance requirements of different businesses. Organizing nodes into redundant node clusters significantly improves system reliability and fault tolerance. If a node fails due to hardware failure, software error, or other unexpected circumstances, a redundant node can immediately take over, ensuring continuous storage resource availability and preventing business interruptions caused by single points of failure.

[0080] Step 102: construct at least two mapped volumes into an aggregate storage device, and create a shared volume group based on the aggregate storage device.

[0081] In an embodiment of the present disclosure, at least two mapped volumes are constructed as an aggregate storage device, and this process is achieved through a specific storage virtualization technology. Specifically, the underlying storage management system is used to integrate the physical storage space of multiple mapped volumes, shielding the physical differences between the mapped volumes, and forming a unified storage entity at the logical level, namely, an aggregate storage device. This integration is not a simple physical superposition, but is based on complex algorithms and data structures to achieve efficient organization and management of storage resources, ensuring that data read and write operations can be reasonably distributed among multiple mapped volumes, thereby improving the overall performance of the storage system. A shared volume group is created based on the aggregate storage device. The shared volume group provides a unified, sharable storage resource pool for each node of the cloud computing platform. The nodes can flexibly allocate and use storage resources from the shared volume group according to their own business needs.

[0082] Building multiple mapped volumes into an aggregated storage device effectively improves storage resource utilization. By integrating multiple mapped volumes, storage resource fragmentation is avoided. Aggregated storage devices also enhance storage system performance. By optimizing data distribution and read / write strategies across multiple mapped volumes, data parallelization is achieved, improving storage system I / O performance.

[0083] Step 103 : Based on the cluster management component, the shared volume group is loaded and configured on the nodes in the redundant node cluster, and a distributed lock space is created in the redundant node cluster to manage the device resources of the shared volume group.

[0084] In an embodiment of the present disclosure, a shared volume group is loaded and configured on a node in a redundant node cluster based on a cluster management component. This process relies on the resource scheduling and configuration management capabilities of the cluster management component. The cluster management component transmits relevant information of the shared volume group to each node in the redundant node cluster through a specific communication protocol and configuration instructions. Each node loads the shared volume group based on the received information so that the shared volume group can be identified and accessed on the local node. During the loading process, the node will perform a series of initialization tasks, such as establishing a connection with the shared volume group, allocating local resources for access and management of the volume group, etc., to ensure that the shared volume group can operate normally on each node and provide basic support for subsequent storage operations.

[0085] Creating a distributed lock space within a redundant node cluster to manage the device resources of a shared volume group is a key step in ensuring data consistency and orderly operations within the shared volume group. Leveraging distributed system technology, a distributed lock space is constructed within the redundant node cluster. This distributed lock space operates through a complex set of distributed algorithms and synchronization mechanisms, with the core purpose of effectively managing and controlling the device resources of the shared volume group. When multiple nodes need to perform operations on a shared volume group, such as creating, modifying, or deleting logical volumes, they must first obtain the corresponding operation permissions from the distributed lock space. The distributed lock space, based on pre-set rules and policies, ensures that conflicts do not occur when multiple nodes access the shared volume group. This can be achieved by, but is not limited to, only allowing one node to obtain a lock for a specific operation at a time. This prevents multiple nodes from performing conflicting operations on the shared volume group simultaneously, ensuring data consistency and integrity.

[0086] By configuring the shared volume group through the cluster management component, it can be widely deployed in a redundant node cluster, allowing each node to conveniently use the storage resources in the shared volume group, improving the accessibility and utilization efficiency of storage resources, and thus enhancing the performance of the entire storage architecture.

[0087] Step 104 : Before any node performs a logical volume operation on a shared volume group, it obtains the operation permission from the distributed lock space and performs the logical volume operation based on the operation permission.

[0088] In an embodiment of the present disclosure, when any node in a redundant node cluster needs to perform a logical volume operation on a shared volume group, it will first initiate a request to the distributed lock space to obtain operation permissions. The node and the distributed lock space interact in accordance with a specific communication protocol and authentication mechanism to ensure the legitimacy and security of the request. After receiving the request, the distributed lock space verifies and processes the request based on the internal preset lock management strategy. If no other node currently holds a lock for the operation and resources permit, the distributed lock space will grant the requesting node the corresponding operation permission and return authorization information. After obtaining the operation permission, the node performs the corresponding logical volume operation based on the permission. This process involves operations such as allocating, adjusting or releasing storage space within the shared volume group, depending on the type of logical volume operation, such as creating a logical volume, expanding or shrinking the size of a logical volume, deleting a logical volume, etc. During the operation execution process, the node will strictly operate in accordance with the scope of the obtained permission to ensure the legitimacy and accuracy of the operation.

[0089] This mechanism of obtaining operational permissions before executing logical volume operations effectively avoids data conflicts and inconsistencies that can arise when multiple nodes concurrently operate on a shared volume group. In a cloud computing environment, multiple nodes may simultaneously initiate different logical volume operations on a shared volume group. Without effective permission control, this can lead to serious consequences such as data corruption and chaotic storage resource allocation. By introducing a distributed lock space for operational permission management, it ensures that only one node can perform a specific logical volume operation on a shared volume group at a time, ensuring data integrity and consistency. This mechanism also improves the stability and reliability of the storage system, avoids system failures caused by concurrent operation conflicts, and provides strong support for the stable operation of the cloud computing platform.

[0090] The present disclosure provides a method for shared storage virtualization. Compared to related technologies, this embodiment creates at least two mapped volumes in a storage cluster and maps them to cloud computing platform nodes. These nodes are then organized into a redundant node cluster using a cluster management component. If a mapped volume or node fails, the other mapped volumes and nodes continue to function normally, ensuring uninterrupted service and improving system redundancy and overall availability. By constructing at least two mapped volumes into an aggregated storage device and creating a shared volume group, storage resources can be integrated and managed uniformly. A distributed lock space is created within the redundant node cluster based on the cluster management component to manage the device resources of the shared volume group. Before any node can perform logical volume operations on the shared volume group, it must obtain operation permissions from the distributed lock space. This mechanism effectively avoids data conflicts and inconsistencies that may arise when multiple nodes operate on the shared volume group simultaneously, ensuring data integrity and consistency. By organizing the cloud computing platform nodes into a redundant node cluster and utilizing the shared volume group and distributed lock space management mechanisms, the risk of system failure caused by a single node or storage device failure is reduced. Even if a node fails, other nodes can quickly take over its work and continue operations on the shared volume group. Furthermore, the presence of a distributed lock space ensures that during a node failover, shared volume group device resource management remains consistent, further reducing the impact of single points of failure on the system. Nodes in a redundant node cluster can directly access storage resources within the storage system, eliminating the need for data access through a control node. This improves system performance and eliminates performance bottlenecks.

[0091] In order to clearly illustrate the embodiments of the present disclosure, this embodiment provides a flowchart of another shared storage virtualization method.

[0092] like Figure 2 As shown, the method comprises the following steps:

[0093] Step 201: Create at least two mapping volumes of equal size in at least one storage cluster, and generate identities of the at least two mapping volumes.

[0094] Specifically, in step 201, at least two mapping volumes of equal size are created in at least one storage cluster through the volume creation function provided by the storage system. In some embodiments of the present disclosure, in order to prevent the storage cluster from failing and causing the storage system to become unusable, different mapping volumes are generally created in different storage clusters. Redundant backup of data is achieved. While creating the mapping volume, the storage system automatically generates identities for at least two mapping volumes. The identity is a unique identifier for the mapping volume, which is used to accurately distinguish and locate each mapping volume in the entire cloud computing storage environment. It usually contains information such as the device ID and the volume serial number. For example, volume Lun1 is created in the first storage cluster A, and volume Lun2 of the same size as Lun1 is created in the second storage cluster B. Lun1 and Lun2 can also be created in the same storage cluster. When a mapping volume fails, other mapping volumes can seamlessly take over the work, ensuring the continuous availability of data and improving the reliability of the storage system. At the same time, multiple mapping volumes can process data read and write requests in parallel, improving the overall performance of the storage system.

[0095] Step 202: Map at least two mapped volumes to nodes of the cloud computing platform through a predetermined mapping method, and establish a storage connection between the nodes of the cloud computing platform and the at least two mapped volumes.

[0096] Specifically, in step 202, at least two mapped volumes are mapped to the cloud computing platform nodes using a predetermined mapping method. The predetermined mapping method here includes, but is not limited to, iSCSI, FC, or other SCSI-based mapping methods. Taking iSCSI mapping as an example, on the cloud computing platform nodes, an iSCSI initiator must be configured. This program scans the network to discover the mapped volumes created in the storage cluster. The storage cluster must configure an iSCSI target and associate the created mapped volumes with the corresponding iSCSI target. Once the node's iSCSI initiator establishes a connection with the storage cluster's iSCSI target, the mapped volumes can be mounted to the node, enabling the node to access the mapped volumes. If FC (Fibre Channel) mapping is used, the node must be equipped with an FC host bus adapter (HBA) card, and the storage cluster must also have an FC interface. The node's HBA card is connected to the storage cluster's FC interface via an optical fiber cable, and communication is performed using the FC protocol. Corresponding configurations are performed on the storage cluster and nodes, such as setting partitions and creating logical unit number (LUN) mappings, so that the nodes can identify and access the mapped volumes. During the mapping process, the cloud computing platform nodes establish storage connections with at least two mapped volumes. This means that nodes can not only identify the mapped volume but also interact with the data in the mapped volume. The node will treat the mapped volume as an extension of the local storage device and manage it through the file system driver or block device driver.

[0097] When building a cloud computing storage architecture, cluster management components are pre-deployed on each node of the cloud computing platform. Pacemaker and Corosync are used as examples to illustrate cluster management components. During the deployment phase, Pacemaker and Corosync are installed on each cloud computing platform node. After installation, a series of configuration operations enable these components to work together. Pacemaker is primarily responsible for resource management and fault detection. By defining rules for starting, stopping, and monitoring resources, it ensures the normal operation of critical services and resources in the cluster. Corosync focuses on messaging and membership management between cluster members. It establishes communication channels between nodes, enabling them to exchange status information in real time.

[0098] When configuring a cloud computing platform's nodes into a redundant node cluster, Corosync comes into play. It uses multicast or unicast communication to establish reliable connections between nodes, forming a communication network. Through this network, each node can send heartbeat messages to other nodes to check their health. If a node doesn't receive heartbeat messages from other nodes within a specified timeframe, Corosync deems it a failure and notifies Pacemaker of this information.

[0099] Upon receiving node failure information, Pacemaker handles it according to pre-defined resource management policies. For example, if a controller node fails, Pacemaker automatically migrates critical services (such as the cinder-volume service) running on that node to other healthy nodes to ensure service continuity. Pacemaker also readjusts resource allocation to ensure that the overall performance of the cluster is not significantly affected.

[0100] In this redundant node cluster, each node has a clear division of responsibilities, yet they also back up each other. Regarding storage resource management, when a node needs to access shared storage resources, the cluster management component coordinates operations between nodes to ensure data consistency and integrity. For example, when operating on a shared volume group, the cluster management component uses a distributed locking mechanism (such as DLM or Sanlock) to control node access to resources, preventing multiple nodes from performing conflicting operations on the same resource simultaneously.

[0101] Step 203: At the target control node, the devices corresponding to the at least two mapped volumes are constructed into a redundant disk array to generate an aggregate storage device, and metadata of the aggregate storage device is stored in all member devices.

[0102] Specifically in step 203, on the target control node of the cloud computing platform, it is necessary to build the devices corresponding to at least two mapping volumes into a redundant disk array. The MD (Multiple Devices, also known as soft RAID) function in the Linux kernel can be used to achieve this goal. Taking the construction of a redundant disk array at the RAID1 level as an example, a specific command line tool, such as mdadm, is used to combine the devices corresponding to at least two mapping volumes into a logical redundant disk array. During operation, the mdadm tool will configure each device as a member device of the RAID1 array based on preset parameters, so that data can be written to these devices at the same time, realizing data redundancy backup. The aggregate storage device in the embodiment of the present disclosure is an MD device that utilizes the MD function to combine and create mapping volumes Lun1 and Lun2. The aggregate storage device integrates multiple physically separated mapping volume devices into a logical whole, providing a unified storage access interface for upper-layer applications. In the process of generating the aggregate storage device, its metadata is stored in all member devices. Metadata includes key information about the aggregate storage device, such as the device's UUID (Universally Unique Identifier), which uniquely identifies the aggregate storage device across the entire system; the UUIDs of each member device, which accurately identify each participating mapped volume device; and bitmap information related to data storage and management. This bitmap information corresponds to the block size information of a specific aggregate storage device and records the storage status of data on each member device, such as which data blocks are in use, which are free, and the consistency status of data blocks. By storing metadata on all member devices, each member device has information that fully describes the status of the aggregate storage device.

[0103] Building a redundant array of disks (RAID) from at least two mapped volumes creates an aggregate storage device, significantly enhancing storage reliability. For example, in the case of RAID 1, if a member device fails, the remaining members can continue to provide services using their stored data and metadata, ensuring data loss and uninterrupted services, eliminating the threat of single points of failure to the storage system.

[0104] Step 204 : Initialize the aggregate storage device as a physical device of the disk manager through the target control node, and create the physical device as a shared volume group, wherein a resource dependency relationship is configured between the shared volume group and the aggregate storage device.

[0105] Specifically in step 204, the target control node uses disk management technology to initialize the aggregate storage device as a physical device of the disk manager (such as LVM, Logical Volume Manager in the Linux system). In the Linux system environment, this initialization operation is completed by executing a specific command (such as pvcreate). This command will create a physical volume (PV) metadata structure on the aggregate storage device, marking the device for LVM management, so that the disk manager can identify and manage the aggregate storage device. Then, based on the initialized physical device, the target control node creates a shared volume group (VG) by executing relevant commands (such as vgcreate). A shared volume group is a logical storage pool consisting of one or more physical volumes, which provides a unified resource space for the creation of upper-level logical volumes. When creating a shared volume group, the system will assign it a unique identifier and management information for tracking and managing the physical devices in the volume group and the subsequently created logical volumes.

[0106] At the same time, to ensure system stability and rational resource management, a resource dependency is configured between the shared volume group and the aggregate storage device. This dependency is set through a specific configuration file or management tool, such as using the pcs command for configuration. The resource dependency clearly stipulates that the startup and operation of the shared volume group depends on the normal working status of the aggregate storage device. In other words, the shared volume group can only be correctly activated and used when the aggregate storage device is mounted normally and its metadata is complete and available. The setting of this dependency ensures the orderliness of storage resource management and avoids abnormalities in the shared volume group due to the inability to obtain the required resources when the aggregate storage device fails, thereby ensuring the stability of the entire storage system.

[0107] Initializing aggregate storage devices as physical devices in the disk manager and creating shared volume groups enables abstraction and unified management of storage resources. The creation of shared volume groups provides a centralized, sharable storage resource pool for each node in the cloud computing platform. Each node can flexibly divide and use logical volumes from the shared volume group based on business needs, improving storage resource utilization and allocation flexibility.

[0108] Step 205 : Based on the resource dependency, resource proxy configuration is performed on the shared volume group and the aggregate storage device in the remaining nodes of the redundant node cluster, wherein the remaining nodes are nodes in the redundant node cluster excluding the target control node.

[0109] Specifically, in step 205, based on the established resource dependency between the shared volume group and the aggregate storage device, resource agent configuration is carried out on the remaining nodes in the redundant node cluster except the target control node. This process is achieved with the help of the resource agent function of the cluster management tool (such as Pacemaker). Taking Pacemaker as an example, first, on each remaining node, ensure that the Pacemaker software is running normally and configured correctly. Pacemaker interacts with the underlying storage resources through the resource agent. The resource agent is a software module that encapsulates the management operations of specific resources (such as shared volume groups and aggregate storage devices), allowing Pacemaker to manage different types of resources in a unified manner.

[0110] To configure resource agents for shared volume groups and aggregate storage devices, you need to execute specific commands (such as the pcs command) on the remaining nodes. These commands are used to register the resource agents for shared volume groups and aggregate storage devices with Pacemaker and set related parameters. For example, you need to specify resource identifiers for shared volume groups and aggregate storage devices so that Pacemaker can accurately identify and manage them; set up resource start, stop, and monitoring scripts so that Pacemaker can automatically manage the lifecycle of these resources; and clarify the dependencies between resources to ensure that the resource agent configuration for shared volume groups depends on the successful configuration of the resource agent for aggregate storage devices. This aligns with the resource dependencies previously established on the target control node, ensuring consistent resource management across the entire cluster.

[0111] During the configuration process, Pacemaker verifies that the resource agent's configuration information is correct and attempts to start the resource agent. If the configuration is correct and resources are available, the resource agent successfully starts on the remaining nodes, establishes connections to the shared volume group and aggregate storage devices, and enables these nodes to identify and access the storage resources in the shared volume group.

[0112] Step 206: Mount a distributed lock on a node in the redundant node cluster, create a distributed lock space based on the node where the distributed lock has been mounted, and control access to device resources of the shared volume group based on the distributed lock space.

[0113] Specifically, in step 206, a distributed lock needs to be mounted on each node in the redundant node cluster. Distributed locks can be implemented using, but are not limited to, tools such as DLM (Distributed Lock Manager) or Sanlock. Taking DLM as an example, on each node, the DLM software must first be properly installed and its configuration parameters meet system requirements. By executing specific commands or calling the corresponding API interface, the DLM is associated with the node, enabling the distributed lock to be mounted on the node. This mounting operation enables the node to participate in distributed lock management, laying the foundation for the subsequent construction of a distributed lock space.

[0114] After distributed locks are mounted on each node, a distributed lock space is created based on the nodes that have mounted distributed locks. This process is achieved through the collaborative work of distributed lock management software. The Distributed Lock Management (DLM) establishes communication links between nodes and coordinates and manages lock resources on each node using a specific distributed algorithm. Based on this created distributed lock space, access to the shared volume group's device resources is controlled and managed. When a node needs to perform an operation on a shared volume group, such as creating or deleting a logical volume, or modifying volume properties, it first sends a lock acquisition request to the distributed lock space. Based on pre-set rules, the distributed lock space determines whether the request is valid and whether lock resources are available. If the request is valid and a lock is available, the distributed lock space assigns the lock to the requesting node. Only after the node obtains the lock can it perform the corresponding operation on the shared volume group's device resources. After the operation is completed, the node must promptly release the lock so that other nodes can obtain the lock and perform the operation.

[0115] Step 207: According to the operation type of the logical volume operation, any node applies for operation permission from the distributed lock space.

[0116] Further, as a refinement of this embodiment, according to the operation type of the logical volume operation, any node applies for operation permission from the distributed lock space, including: if the logical volume operation is to create a logical volume for the control node, the control node applies for creation permission from the distributed lock space; if the logical volume operation is to mount a logical volume on the virtual machine in the computing node, the computing node applies for mounting permission from the distributed lock space.

[0117] Specifically, in step 207, the distributed lock space is precisely requested for the corresponding operation permissions based on the type of logical volume operation. During the operation of the cloud computing platform, any node in the redundant node cluster must initiate an operation permission request from the distributed lock space based on the specific type of logical volume operation before performing any logical volume operation. This mechanism is designed to ensure the atomicity and consistency of logical volume operations in the shared volume group, avoiding data conflicts and errors caused by concurrent operations on multiple nodes.

[0118] To be more specific, when a logical volume operation is performed on a control node to create a logical volume, the control node will interact with the distributed lock space according to a specific communication protocol and apply for creation permissions from the distributed lock space. For example, in an OpenStack cloud computing environment, Figure 3As shown, the cinder-volume service deployed on the control node is responsible for managing storage resources. When a logical volume needs to be created to provide cloud disk services to users, the cinder-volume service will call the corresponding interface function and send a request message containing parameters such as the operation type (create logical volume) and resource identifier (shared volume group and related information) to the distributed lock space. After receiving the request, the distributed lock space determines whether the control node can be granted creation permission based on its internal preset lock allocation strategy and resource status. If no other nodes are currently performing potentially conflicting operations and the shared volume group has sufficient resources, the distributed lock space will return the creation permission to the control node. Only after obtaining the permission can the control node perform the operation of creating a logical volume on the shared volume group, such as creating a logical volume (LV) through the LVM command.

[0119] When the logical volume operation is used to mount the logical volume for the virtual machine in the compute node, the compute node is responsible for applying for the mount permission from the distributed lock space. For example, the nova-compute service in the compute node of OpenStack is used. Figure 3 As shown in the figure, when a virtual machine needs to mount a logical volume to obtain storage resources, the nova-compute service first obtains relevant information about the logical volume to be mounted, such as the logical volume's UUID (Universally Unique Identifier). Then, through the communication interface with the distributed lock space, it sends a mount permission request containing key information such as the operation type (mounting a logical volume) and the logical volume's UUID. After receiving the request, the distributed lock space verifies and processes it. It checks the current status of the logical volume to confirm whether it is mountable and whether any other nodes are performing conflicting operations on the logical volume. If all conditions are met, the distributed lock space grants mount permission to the compute node. Only after obtaining mount permission can the compute node correctly mount the logical volume to the virtual machine using virtualization management tools such as libvirt, allowing the virtual machine to access the storage resources in the shared volume group.

[0120] In step 208 , based on the operation authority, any node performs a logical volume operation on the shared volume group and controls access by other nodes at the same time.

[0121] Furthermore, as a refinement of this embodiment, based on operation permissions, any node performs logical volume operations on the shared volume group, including: based on creation permissions, the control node creates a logical volume in the shared volume group and notifies other nodes in the redundant node cluster to update metadata; based on mount permissions, the computing node obtains the volume information of the target logical volume to be mounted from the control node, activates the target logical volume, and maps the target logical volume to the virtual machine.

[0122] Specifically, in step 208, based on the operation permissions obtained by the node in step 207, precise operational control of the shared volume group is achieved, while maintaining data synchronization and stability across all nodes in the cluster. Once any node obtains operation permissions, it can perform corresponding logical volume operations on the shared volume group. In actual operation, different types of operation permissions correspond to different operational processes and requirements.

[0123] For operations based on create permissions, the control node creates a logical volume in a shared volume group. For example, in an OpenStack environment with LVM storage management, after receiving create permissions from a distributed lock space, the control node calls LVM-related commands (such as lvcreate) to create a logical volume (LV) in a shared volume group (VG). During the creation process, the control node sets parameters such as the logical volume size and name based on business requirements. After creation, to ensure data consistency among other nodes in the redundant node cluster, the control node needs to notify other nodes in the redundant node cluster to update metadata. The control node uses cluster management services (such as the communication mechanisms in cluster environments built with Pacemaker and Corosync) to send metadata update messages to other nodes containing detailed information about the newly created logical volume. This information includes key data such as the logical volume's UUID, size, and location within the shared volume group. Upon receiving the update message, other nodes update their locally stored metadata for the shared volume group and aggregate storage device based on the message content, ensuring consistent understanding of shared storage resources across all nodes.

[0124] When operations based on mount permissions are involved, after obtaining mount permissions, the compute node will request volume information for the target logical volume to be mounted from the controller node. In the OpenStack architecture, the nova-compute service on the compute node is responsible for managing the virtual machine's computing resources. Based on the mount permissions, the nova-compute service communicates with the cinder-volume service on the controller node (for example, using OpenStack's message queue mechanism or RESTful API) to obtain detailed volume information for the target logical volume, such as the volume UUID and device path. After obtaining the volume information, the compute node activates the target logical volume. This activation process involves the device driver on the compute node initializing the logical volume, enabling the compute node to recognize and access it. After successful activation, the compute node uses the libvirt virtualization management tool to map the target logical volume to the virtual machine. Based on the virtual machine's configuration information, libvirt adds the target logical volume to the virtual machine's virtual device list, allowing the virtual machine to access the logical volume as if it were a local storage device, thereby enabling the virtual machine to use shared storage resources.

[0125] Furthermore, in some embodiments of the present disclosure, in order to enable the cloud computing platform to better cope with various failures of the control nodes, the redundancy of the control nodes can also be achieved by adopting but not limited to the following methods, including: deploying control services in the control nodes of each cloud computing platform, and controlling other control nodes through cluster management components to perform resource takeover when any control node fails.

[0126] Specifically, to enable cloud computing platforms to more effectively cope with various control node failures, implementing a control node redundancy mechanism is an effective solution. Specifically, control node redundancy can be achieved using, but is not limited to, the following methods. Deploy control services on each cloud computing platform's control node. For example, the OpenStack cloud computing platform typically deploys the cinder-volume service on its control nodes to manage storage resources, along with other related control services to collaboratively manage resource scheduling, user authentication, and other functions across the entire platform. These control services run on their respective control nodes and interact with other services through inter-process communication (IPC) to maintain the normal operation of the cloud computing platform. When any control node fails, the cluster management component plays a key role. In the technical solution described in this document, commonly used cluster management components such as Pacemaker and Corosync work together to manage the entire cluster. Pacemaker is responsible for resource management and scheduling, while Corosync facilitates inter-node communication and membership management. When Corosync detects a control node failure, it broadcasts the failure information to all other nodes via the cluster's internal communication network.

[0127] Upon receiving a fault notification, Pacemaker controls other control nodes to perform resource takeover operations based on pre-defined resource takeover policies. Regarding storage resource management, if the failed control node is the node hosting the cinder-volume service, Pacemaker selects one or more functioning control nodes to take over its storage resource management responsibilities. For example, Pacemaker determines the appropriate takeover node based on factors such as the load and resource availability of each control node. After selecting a takeover node, Pacemaker calls the cinder-volume service API on that node to activate the storage resources, such as shared volume groups and logical volumes, previously managed by the failed node. During activation, the takeover node retrieves the latest metadata from the shared storage to ensure consistent operations on storage resources. Furthermore, Pacemaker adjusts resource allocation policies within the cluster to reroute user requests originally handled by the failed node to the takeover node, ensuring the continuous and stable operation of the cloud computing platform's storage services.

[0128] It should be noted that the embodiments of the present disclosure may include multiple steps. For the convenience of description, these steps are numbered, but these numbers do not limit the execution time slots or execution order between the steps; these steps can be implemented in any order, and the embodiments of the present disclosure do not limit this.

[0129] Corresponding to the above-mentioned shared storage virtualization method, the present disclosure also provides a shared storage virtualization device. Since the device embodiment of the present disclosure corresponds to the above-mentioned method embodiment, details not disclosed in the device embodiment can be referred to the above-mentioned method embodiment and will not be repeated in this disclosure.

[0130] Figure 4 A structural diagram of a shared storage virtualization device provided by an embodiment of the present disclosure is shown in FIG. Figure 4 Shown, including:

[0131] A mapping unit 31 is configured to create at least two mapping volumes in the storage cluster and map the at least two mapping volumes to nodes of the cloud computing platform, wherein the nodes of the cloud computing platform are deployed with a cluster management component to organize the nodes of the cloud computing platform into a redundant node cluster;

[0132] A construction unit 32 is configured to construct at least two mapped volumes into an aggregate storage device, and create a shared volume group based on the aggregate storage device;

[0133] The configuration unit 33 is configured to load and configure the shared volume group on the nodes in the redundant node cluster based on the cluster management component, and to create a distributed lock space in the redundant node cluster to manage the device resources of the shared volume group;

[0134] The execution unit 34 is configured to obtain an operation permission from the distributed lock space before any node performs a logical volume operation on the shared volume group, and perform the logical volume operation based on the operation permission.

[0135] The present disclosure provides a shared storage virtualization device. Compared to related technologies, this embodiment creates at least two mapped volumes in a storage cluster and maps them to cloud computing platform nodes. These nodes are then organized into a redundant node cluster using a cluster management component. If a mapped volume or node fails, the other mapped volumes and nodes continue to function normally, ensuring uninterrupted service and improving system redundancy and overall availability. By constructing at least two mapped volumes into an aggregated storage device and creating a shared volume group, storage resources can be integrated and managed uniformly. A distributed lock space is created within the redundant node cluster based on the cluster management component to manage the device resources of the shared volume group. Before any node can perform logical volume operations on the shared volume group, it must obtain operation permissions from the distributed lock space. This mechanism effectively avoids data conflicts and inconsistencies that may arise when multiple nodes operate on the shared volume group simultaneously, ensuring data integrity and consistency. By organizing the cloud computing platform nodes into a redundant node cluster and utilizing the shared volume group and distributed lock space management mechanisms, the risk of system failure caused by a single node or storage device failure is reduced. Even if a node fails, other nodes can quickly take over its work and continue operations on the shared volume group. Furthermore, the presence of a distributed lock space ensures that during a node failover, shared volume group device resource management remains consistent, further reducing the impact of single points of failure on the system. Nodes in a redundant node cluster can directly access storage resources within the storage system, eliminating the need for data access through a control node. This improves system performance and eliminates performance bottlenecks.

[0136] Furthermore, in a possible implementation of this embodiment, as Figure 5 As shown, the mapping unit 31 includes:

[0137] A first generating module 311 is configured to create at least two mapping volumes of equal size in at least one storage cluster, and generate identities of the at least two mapping volumes;

[0138] The mapping module 312 is configured to map the at least two mapping volumes to nodes of the cloud computing platform in a predetermined mapping manner, and establish a storage connection between the nodes of the cloud computing platform and the at least two mapping volumes.

[0139] Furthermore, in a possible implementation of this embodiment, as Figure 5 As shown, the shared storage virtualization device also includes:

[0140] The control unit 35 is used to deploy control services in the control nodes of each cloud computing platform, and to control other control nodes to perform resource takeover through the cluster management component when any control node fails.

[0141] Furthermore, in a possible implementation of this embodiment, as Figure 5As shown, the construction unit 32 includes:

[0142] The second generation module 321 is configured to construct the devices corresponding to the at least two mapped volumes into a redundant disk array at the target control node to generate an aggregate storage device, and store its metadata in all member devices;

[0143] The first creation module 322 is configured to initialize the aggregate storage device as a physical device of the disk manager through the target control node, and create the physical device as a shared volume group, wherein the shared volume group and the aggregate storage device are configured with a resource dependency relationship.

[0144] Furthermore, in a possible implementation of this embodiment, as Figure 5 As shown, the configuration unit 33 includes:

[0145] A configuration module 331 is configured to perform resource proxy configuration of the shared volume group and the aggregate storage device in the remaining nodes of the redundant node cluster based on the resource dependency relationship, wherein the remaining nodes are nodes in the redundant node cluster other than the target control node;

[0146] The second creation module 332 is used to mount a distributed lock on a node in the redundant node cluster and create a distributed lock space based on the node on which the distributed lock has been mounted;

[0147] The control module 333 is used to control and manage access to device resources of the shared volume group based on the distributed lock space.

[0148] Furthermore, in a possible implementation of this embodiment, as Figure 5 As shown, the execution unit 34 includes:

[0149] Application module 341, used for any node to apply for operation permission from the distributed lock space according to the operation type of the logical volume operation;

[0150] The execution module 342 is used to allow any node to perform logical volume operations on the shared volume group based on the operation authority, and to control the access of other nodes at the same time.

[0151] Furthermore, in a possible implementation of this embodiment, the operation permission includes a creation permission and a mount permission;

[0152] The application module 341 is also used to:

[0153] If the logical volume operation is to create a logical volume for the control node, the control node applies for creation permission from the distributed lock space;

[0154] If the logical volume operation is to mount a logical volume to a virtual machine in a computing node, the computing node applies for mounting permission from the distributed lock space.

[0155] Furthermore, in a possible implementation of this embodiment, the execution module 342 is further configured to:

[0156] Based on the creation permissions, the control node creates the logical volume in the shared volume group and notifies other nodes in the redundant node cluster to update the metadata;

[0157] Based on the mount permission, the computing node obtains the volume information of the target logical volume to be mounted from the control node, activates the target logical volume, and maps the target logical volume to the virtual machine.

[0158] It should be noted that the above explanation of the method embodiment is also applicable to the device of this embodiment, and the principles are the same, which is not limited in this embodiment.

[0159] For descriptions of features in the embodiments corresponding to the apparatus for shared storage virtualization, reference may be made to the relevant descriptions of the embodiments corresponding to the method for shared storage virtualization, which will not be detailed here.

[0160] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps of any of the above-mentioned shared storage virtualization method embodiments.

[0161] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned shared storage virtualization method embodiments when running.

[0162] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0163] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned shared storage virtualization method embodiments are implemented.

[0164] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above-mentioned shared storage virtualization method embodiments.

[0165] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0166] The above is a detailed introduction to the method and device, electronic device and storage medium for shared storage virtualization provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for shared storage virtualization, characterized in that: include: Creating at least two mapping volumes in a storage cluster, and mapping the at least two mapping volumes to nodes of a cloud computing platform, wherein the nodes of the cloud computing platform are deployed with a cluster management component, and the nodes of the cloud computing platform are organized into a redundant node cluster; constructing the at least two mapped volumes into an aggregate storage device, and creating a shared volume group based on the aggregate storage device; Loading and configuring the shared volume group on nodes in the redundant node cluster based on the cluster management component, and creating a distributed lock space in the redundant node cluster to manage device resources of the shared volume group; Before any node performs a logical volume operation on the shared volume group, it obtains an operation permission from the distributed lock space and performs the logical volume operation based on the operation permission.

2. The shared storage virtualization method according to claim 1, wherein: The step of creating at least two mapping volumes in the storage cluster and mapping the at least two mapping volumes to nodes of the cloud computing platform includes: Creating the at least two mapping volumes of equal size in at least one storage cluster, and generating identities of the at least two mapping volumes; The at least two mapped volumes are mapped to the nodes of the cloud computing platform in a predetermined mapping manner, and a storage connection is established between the nodes of the cloud computing platform and the at least two mapped volumes.

3. The shared storage virtualization method according to claim 1, wherein: The method further comprises: A control service is deployed in each control node of the cloud computing platform. When any control node fails, the cluster management component controls other control nodes to perform resource takeover.

4. The method for shared storage virtualization according to claim 1, wherein: The step of constructing the at least two mapped volumes into an aggregate storage device and creating a shared volume group based on the aggregate storage device includes: Building the devices corresponding to the at least two mapped volumes into a redundant disk array at the target control node to generate the aggregate storage device, and storing the metadata of the aggregate storage device in all member devices; The aggregate storage device is initialized as a physical device of a disk manager through the target control node, and the physical device is created as the shared volume group, wherein a resource dependency relationship is configured between the shared volume group and the aggregate storage device.

5. The shared storage virtualization method according to claim 4, wherein: The step of loading and configuring the shared volume group on nodes in the redundant node cluster based on the cluster management component and creating a distributed lock space in the redundant node cluster to manage device resources of the shared volume group includes: Based on the resource dependency, performing resource proxy configuration on the shared volume group and the aggregate storage device in the remaining nodes of the redundant node cluster, wherein the remaining nodes are nodes in the redundant node cluster other than the target control node; Mounting a distributed lock on a node in the redundant node cluster, and creating the distributed lock space based on the node on which the distributed lock has been mounted; Based on the distributed lock space, access to device resources of the shared volume group is controlled and managed.

6. The shared storage virtualization method according to claim 1, wherein: Before any node performs a logical volume operation on the shared volume group, obtaining an operation permission from the distributed lock space, and performing the logical volume operation based on the operation permission, including: According to the operation type of the logical volume operation, any node applies for the operation permission from the distributed lock space; Based on the operation permission, any node performs the logical volume operation on the shared volume group and controls access by other nodes at the same time.

7. The shared storage virtualization method according to claim 6, wherein: The operation permissions include creation permissions and mounting permissions; According to the operation type of the logical volume operation, any node applies for the operation permission from the distributed lock space, including: If the logical volume operation is to create a logical volume by the control node, the control node applies for the creation permission from the distributed lock space; If the logical volume operation is to mount a logical volume to a virtual machine in a computing node, the computing node applies for the mount permission from the distributed lock space.

8. The shared storage virtualization method according to claim 7, wherein: The performing of the logical volume operation on the shared volume group by any node based on the operation permission includes: Based on the creation permission, the control node creates a logical volume in the shared volume group and notifies other nodes in the redundant node cluster to update metadata; Based on the mount permission, the computing node obtains volume information of the target logical volume to be mounted from the control node, activates the target logical volume, and maps the target logical volume to the virtual machine.

9. A shared storage virtualization device, characterized in that: include: a mapping unit, configured to create at least two mapped volumes in the storage cluster and map the at least two mapped volumes to nodes of the cloud computing platform, wherein the nodes of the cloud computing platform are deployed with a cluster management component and the nodes of the cloud computing platform are organized into a redundant node cluster; a construction unit, configured to construct the at least two mapped volumes into an aggregate storage device, and create a shared volume group based on the aggregate storage device; A configuration unit, configured to load and configure the shared volume group on nodes in the redundant node cluster based on the cluster management component, and to create a distributed lock space in the redundant node cluster to manage device resources of the shared volume group; The execution unit is configured to obtain an operation permission from the distributed lock space before any node executes a logical volume operation on the shared volume group, and execute the logical volume operation based on the operation permission.

10. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the shared storage virtualization method according to any one of claims 1 to 8.

11. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to cause the computer to execute the shared storage virtualization method according to any one of claims 1 to 8.

Images