A method for implementing block storage acceleration in a hyper-converged environment

Abstract

The present invention discloses a method for implementing block storage acceleration in a hyper-converged environment, relating to the field of cloud computing storage technology. The method comprises: adding an "accelerated volume" creation and modification interface to the Openstack Cinder service to implement the accelerated cloud hard disk creation function and the dynamic modification function during runtime; modifying the Ceph librbd client library and Ceph OSD server of the Ceph storage layer to add the shortest path addressing function, optimize the data read and write path, and implement the read and write acceleration function of the client changing the primary write and primary read; and connecting the hypervisor in type II virtualization to the accelerated read and write of Ceph librbd to implement the virtual machine cloud hard disk read and write acceleration function. The present invention is applicable to a hyper-converged cloud computing platform that uses Openstack for virtualization management, type II computing virtualization, and Ceph rbd for underlying data storage. The cloud hard disk is mounted and used by a virtual machine and is particularly suitable for system disks. The method aims to solve the problem of dedicated block storage read and write performance in such an environment.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing storage technology, and in particular to a method for implementing block storage acceleration in a hyper-converged environment. Background Art

[0002] Hyperconverged cloud computing, an innovative architecture, tightly integrates computing, storage, networking, and other data center infrastructure components, enabling unified resource management and flexible allocation through software-defined computing. This technology effectively addresses the complexities, scalability challenges, and low resource utilization inherent in traditional IT infrastructure, meeting the demands of modern enterprises for efficient IT resource utilization, rapid deployment, and simplified management.

[0003] In a hyper-converged cloud computing environment, the maturity of server virtualization technology provides a solid technical foundation. The hypervisor, as the core of virtualization technology, sits between the underlying physical server and the operating system, allowing multiple operating systems and applications to share hardware resources. Virtualization is categorized into Type I and Type II based on the type of hypervisor. In Type II virtualization (hosted), virtual machines run on traditional operating systems, creating a virtual hardware platform where users can install different operating systems and application software as needed. Mainstream Type II virtualization hypervisors include KVM+QEMU and Virtual PC. Furthermore, hyper-converged architectures integrate storage and computing, significantly improving data processing efficiency.

[0004] Currently, the defects of related technologies and components in hyper-converged cloud computing environments include:

[0005] 1. Lack of flexibility in cloud drive management: In hyper-converged cloud computing scenarios, cloud drive operations have shortcomings. First, the cloud drive creation process is cumbersome and lacks rapid customization capabilities, making it difficult for users to quickly build cloud drives tailored to specific needs. Second, once cloud drives are operational, changes are restricted, and key performance parameters cannot be dynamically adjusted, making it difficult to cope with fluctuating business loads and impacting overall work efficiency.

[0006] 2. Inadequate storage read and write optimization: As a key support for hyper-converged architectures, storage systems require improved read and write performance. Currently, storage addressing methods are crude and fail to accurately consider the shortest data transmission path. This increases data read and write time, especially when the client switches between primary read and write nodes. Performance plummets, making it impossible to guarantee high-speed data transfer and hindering efficient system operation.

[0007] 3. Insufficient coordination between virtualization and storage: There's a gap in the coordination between Type II virtualization and storage. While the hypervisor creates a virtual hardware world, it lacks deep integration with the underlying storage. During data read and write operations, the storage system's acceleration features aren't effectively leveraged. This results in slower read and write speeds when virtual machines access cloud hard drives, preventing the full potential of hyperconverged cloud computing and hindering smooth business operations.

[0008] Overall, these defects exist in different key links of the hyper-converged cloud computing environment, affecting the performance of the entire system and user experience. Summary of the Invention

[0009] In response to the needs and shortcomings of current technological development, the present invention provides a method for implementing block storage acceleration in a hyper-converged environment.

[0010] The present invention provides a method for implementing block storage acceleration in a hyper-converged environment, and the technical solutions adopted to solve the above technical problems are as follows:

[0011] A method for implementing block storage acceleration in a hyper-converged environment comprises the following steps:

[0012] S1. Add "accelerated volume" creation and modification interfaces to the OpenStack Cinder service to implement accelerated cloud disk creation and dynamic modification during runtime.

[0013] S2. Modify the Ceph librbd client library and Ceph OSD server of the Ceph storage layer, add the shortest path addressing function, optimize the data read and write paths, and implement the read and write acceleration function of the client changing the primary write and primary read;

[0014] S3: Connect the Hypervisor in Type II virtualization to Ceph librbd's accelerated read and write functions to implement the virtual machine cloud hard disk read and write acceleration function.

[0015] Optionally, the specific operations of step S1 include:

[0016] S1.1. At the cloud drive product level, a visual operation interface is provided, allowing users to easily enable read and write acceleration for cloud drives. A cloud drive can be mounted and used by at most one virtual machine.

[0017] S1.2. In the Cinder Volume virtual block storage management layer, you are fully responsible for connecting to the cloud disk product layer and implementing the "accelerated volume" related instructions. The specific operations are as follows:

[0018] S1.2.1. First, define and create an accelerated volume type to provide a basic template for subsequent instantiation operations.

[0019] S1.2.2. Next, create an accelerated volume and create an accelerated mirror interface by calling Ceph librbd. Configure the mirror attributes, limit the mount to a maximum of one virtual machine, and assign the "LOCAL_ACC" feature.

[0020] S1.2.3. Finally, when business needs change, call the Ceph librbd image feature setting interface to cancel or re-add the "LOCAL_ACC" feature of the image as needed to achieve dynamic adjustment of cloud hard disk performance to adapt to the differentiated storage speed requirements at different time periods and different business intensities.

[0021] Optionally, steps S1.2.2 and S1.2.3 may be implemented by performing the following operations:

[0022] By calling relevant instructions to add the "LOCAL_ACC" flag to the rbd image, an accelerated volume is created and the local acceleration feature is enabled.

[0023] When the Ceph librbd client library creates an RBD image, it also sets the LOCAL_ACC feature. When you subsequently need to enable an RBD image that has already been created and has the acceleration feature, the Ceph librbd client library automatically starts a verification process to check whether the LOCAL_ACC feature exists.

[0024] During the operation of the cloud hard disk, if business needs change and the cloud hard disk performance needs to be adjusted, call the Cephlibrbd image feature setting interface to modify the existing features of the rbd image and cancel or re-add the "LOCAL_ACC" feature as needed. This adapts to the differentiated storage speed requirements under different time periods and business intensities, and realizes dynamic optimization of cloud hard disk performance.

[0025] Optionally, the specific operations of step S2 include:

[0026] S2.1. Develop a functional module in the Ceph librbd client library to add and cancel the "LOCAL_ACC" feature of the mirror, so that it can be closely linked with the upper-layer OpenStack Cinder service and dynamically adjust the mirror acceleration status according to different instructions;

[0027] S2.2. Optimize the data read and write paths in the Ceph librbd client library, embedding client-side local read and write acceleration algorithms to ensure efficient data transmission at the client level.

[0028] S2.3. Develop a functional module for changing master storage write and read in the Ceph OSD server to ensure that data reading and writing are not affected by master node switching.

[0029] Alternatively, for a hyper-converged environment using the Ceph distributed storage system, different strategies can be used to implement the shortest path addressing for data reading and writing based on the location relationship between the virtual machine and the storage replica OSD node, as follows:

[0030] (A) When the VM and the primary OSD are on the same node, the default read / write path is the shortest path.

[0031] (B) When the VM is not on the same node as the master OSD but is on the same node as one of the slave OSDs, the read and write paths are shortened by changing the master node.

[0032] (C) When the client and the primary OSD and secondary OSD storing the replica are not on the same node, the current default read / write path is the shortest path.

[0033] Alternatively, at the Ceph librbd client library level, the specific methods for implementing shortest path addressing and master change operations through the write and read interfaces are as follows:

[0034] The shortest path addressing is performed internally in the Librbd write interface. If the current write is an expedited write, it first determines whether the replica has a local node. If there is a local node and the primary replica is not a local node, the primary replica is changed to the local node, and the current write operation is sent to the changed primary OSD on the local node. The changed primary OSD then completes the synchronous write of the remaining replicas. If the primary replica is a local node, the current write operation is directly sent to the primary replica on the local node for the write operation.

[0035] The shortest path addressing is performed internally in the Librbd read interface. If the current read is an accelerable read, it first determines whether the replica has a local node. If there is a local node and the primary replica is not a local node, the primary node is changed to the local node, and then the current read operation is sent to the changed primary OSD on the local node to complete the data read operation from the local node; if the primary replica is a local node, the current read operation is directly sent to the primary replica on the local node for the read operation.

[0036] Further optionally, the specific operations of step S3 include:

[0037] S3.1. In a Type II virtualization scenario, open the image to prepare for subsequent connection with the Ceph librbd client library.

[0038] S3.2. Implement the Ceph librbd client library to become the primary storage write interface. This ensures that when the VM performs data write tasks, it can directly use the optimized write function of the Ceph librbd library to write data to the storage layer at high speed and stability.

[0039] S3.3. At the same time, the Ceph librbd client library is seamlessly connected to the primary storage read interface, so that when the virtual machine reads data, it can use the accelerated read function of the Ceph librbd client library to quickly obtain the required data, ultimately achieving all-round acceleration of virtual machine cloud hard disk reading and writing.

[0040] The method for implementing block storage acceleration in a hyper-converged environment of the present invention has the following beneficial effects compared with the prior art:

[0041] 1. The present invention uses shortest path addressing to change primary reads and primary writes, thereby improving the read and write performance of clients and Ceph storage on the same node in a hyper-converged cloud computing environment. By modifying the Ceph librbd client library to add shortest path addressing, the read and write acceleration function of changing primary writes and primary reads on the client is realized. The hypervisor in type II virtualization is connected to the accelerated read and write of Cephlibrbd to realize the read and write acceleration function of the virtual machine cloud hard disk and improve the read and write performance of block storage.

[0042] 2. The present invention is applicable to a hyper-converged cloud computing platform that uses Openstack for virtualization management, Type II computing virtualization, and Ceph RBD for underlying data storage. The cloud hard disk is mounted and used by a virtual machine and is particularly suitable for system disks. It aims to solve the read and write performance problems of dedicated block storage in such environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Attachment Figure 1 is a flow chart of a method according to embodiment 1 of the present invention;

[0044] Attachment Figure 2 This is an implementation architecture diagram of the first embodiment of the present invention;

[0045] Attachment Figure 3 This is a schematic diagram of the process of implementing accelerated writing in embodiment 1 of the present invention;

[0046] Attachment Figure 4 This is a schematic diagram of the process of implementing accelerated reading in Example 1 of the present invention. DETAILED DESCRIPTION

[0047] In order to make the technical solution, the technical problems solved and the technical effects of the present invention more clear, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.

[0048] Example 1:

[0049] Combined with attachment Figure 1 、 2 This embodiment proposes a method for implementing block storage acceleration in a hyper-converged environment, which includes the following steps:

[0050] S1. Add "accelerated volume" creation and modification interfaces to the OpenStack Cinder service to implement accelerated cloud disk creation and dynamic modification during runtime. Specific operations include:

[0051] S1.1. At the cloud drive product level, a visual operation interface is provided, allowing users to easily enable read and write acceleration for cloud drives. A cloud drive can be mounted and used by at most one virtual machine.

[0052] S1.2. In the Cinder Volume virtual block storage management layer, you are fully responsible for connecting to the cloud disk product layer and implementing the "accelerated volume" related instructions. The details are as follows:

[0053] S1.2.1. First, define and create an accelerated volume type to provide a basic template for subsequent instantiation operations.

[0054] S1.2.2. Next, create an accelerated volume and create an accelerated mirror interface by calling Ceph librbd. Configure the mirror attributes, limit the mount to a maximum of one virtual machine, and assign the "LOCAL_ACC" feature.

[0055] S1.2.3. Finally, when business needs change, call the Ceph librbd image feature setting interface to cancel or re-add the "LOCAL_ACC" feature of the image as needed to achieve dynamic adjustment of cloud hard disk performance to adapt to the differentiated storage speed requirements at different time periods and different business intensities.

[0056] Specifically, the following operations are performed to supplement the underlying details of accelerated volume creation and performance adjustment: ① By calling relevant instructions to add the "LOCAL_ACC" flag to the rbd image, an accelerated volume is created and given the local acceleration feature; ② When the Cephlibrbd client library creates the rbd image, the "LOCAL_ACC" feature is set synchronously; when the created rbd image with the acceleration feature needs to be opened later, the Ceph librbd client library automatically starts the verification process to verify whether the "LOCAL_ACC" feature exists; ③ During the operation of the cloud hard disk, if business needs change and the cloud hard disk performance needs to be adjusted, the Cephlibrbd image feature setting interface is called to modify the existing features of the rbd image, and cancel or re-add the "LOCAL_ACC" feature as needed. This adapts to the differentiated storage speed requirements under different time periods and different business intensities, and realizes dynamic optimization of cloud hard disk performance. This section details the process of creating accelerated volumes and dynamically optimizing performance by manipulating rbd images, such as adding the "LOCAL_ACC" flag, setting and verifying features, and modifying features. These operations explain the underlying principles of calling the Ceph librbd interface to create and adjust accelerated volumes in steps S1.2.2 and S1.2.3, and further refine the implementation of accelerated volume-related functions.

[0057] S2. Modify the Ceph librbd client library and Ceph OSD server of the Ceph storage layer to add the shortest path addressing function, optimize the data read and write paths, and implement the read and write acceleration function of the client changing the primary write and primary read. The specific operations include:

[0058] S2.1. Develop a functional module in the Ceph librbd client library to add and cancel the "LOCAL_ACC" feature of the mirror, so that it can be closely linked with the upper-layer OpenStack Cinder service and dynamically adjust the mirror acceleration status according to different instructions;

[0059] S2.2. Optimize the data read and write paths in the Ceph librbd client library, embedding client-side local read and write acceleration algorithms to ensure efficient data transmission at the client level.

[0060] S2.3. Develop a functional module for changing master storage write and read in the Ceph OSD server to ensure that data reading and writing are not affected by master node switching.

[0061] Combined with attachment Figure 3 、 4 At the Ceph librbd client library level, the specific means of implementing shortest path addressing and master change operations through the write interface and read interface are as follows:

[0062] The shortest path addressing is performed internally in the Librbd write interface. If the current write is an expedited write, it first determines whether the replica has a local node. If there is a local node and the primary replica is not a local node, the primary replica is changed to the local node, and the current write operation is sent to the changed primary OSD on the local node. The changed primary OSD then completes the synchronous write of the remaining replicas. If the primary replica is a local node, the current write operation is directly sent to the primary replica on the local node for the write operation.

[0063] The shortest path addressing is performed internally in the Librbd read interface. If the current read is an accelerable read, it first determines whether the replica has a local node. If there is a local node and the primary replica is not a local node, the primary node is changed to the local node, and then the current read operation is sent to the changed primary OSD on the local node to complete the data read operation from the local node; if the primary replica is a local node, the current read operation is directly sent to the primary replica on the local node for the read operation.

[0064] Through the above specific means, the specific technical implementation methods of optimizing the data read and write path in step S2.2 and developing the main storage write and read function modules in step S2.3 are explained to convert the abstract function description into specific interface operations.

[0065] Specifically, taking the Ceph distributed storage system in a hyper-converged environment as an example, based on the location relationship between the virtual machine and the storage replica OSD node, we discuss how to implement the shortest path addressing for data reading and writing in different situations (A, B, and C). The details are as follows:

[0066] Assume that virtual machine vm1 is on host1, and the three replica OSD nodes of a rados object corresponding to the rbd image are (x, y, z), where x is the primary OSD;

[0067] (A) x = host1, that is, when the virtual machine and the primary OSD are on the same node, the default read and write path is the shortest path. Currently, Ceph's default read and write are initiated by the client and the primary OSD.

[0068] (a1) For write operations, client host1 first sends the data to the master OSD node x through the network, and then the master OSD sends it to the two slave nodes y and z;

[0069] (a2) For read operations, the client directly accesses the primary OSD x node through the network to read data.

[0070] (B) x≠host1, y|z=host1, that is, when the virtual machine is not on the same node as the master OSD but is on the same node as one of the slave OSDs, the read and write paths are shortened by changing the master operation.

[0071] (b1) For write operations, client host1 first sends data to the master OSD node x over the network, which is then sent to two slave nodes y and z. The current path is that host1 first sends data to node x (not host1), and then x sends data to nodes y and z, one of which is host1. For this scenario, the rados object (x, y, z) can be changed to (y = host1, x, z) or (z = host1, x, y). The paths after the change of master are: host1 directly to x and z, or host1 directly to x and y, which is significantly shorter.

[0072] (b2) For read operations, client host1 first sends a data read request over the network to the primary OSD node x, which then sends it back to host1. For this scenario, the rados object (x, y, z) can be made primary to (y = host1, x, z) or (z = host1, x, y). After this change, the read path becomes a local read from host1 to host1, significantly shortening the path.

[0073] (C) x≠host1, y≠host1, z≠host1, that is, when the client and the primary OSD and secondary OSD storing the replica are not on the same node, the current default read / write path is the shortest path.

[0074] (c1) For write operations, client host1 first sends the data to the master OSD node x through the network, and then the master OSD sends it to the two slave nodes y and z;

[0075] (c1) For read operations, client host1 directly accesses the primary OSD x node through the network to read data, which is the shortest path that can be achieved under the current circumstances.

[0076] S3. Connect the Hypervisor in Type II virtualization to Ceph librbd's accelerated read and write functions to implement accelerated read and write capabilities for virtual machine cloud hard disks. Specific operations include:

[0077] S3.1. In a Type II virtualization scenario, open the image to prepare for subsequent connection with the Ceph librbd client library.

[0078] S3.2. Implement the Ceph librbd client library to become the primary storage write interface. This ensures that when the VM performs data write tasks, it can directly use the optimized write function of the Ceph librbd library to write data to the storage layer at high speed and stability.

[0079] S3.3. At the same time, the Ceph librbd client library is seamlessly connected to the primary storage read interface, so that when the virtual machine reads data, it can use the accelerated read function of the Ceph librbd client library to quickly obtain the required data, ultimately achieving all-round acceleration of virtual machine cloud hard disk reading and writing.

[0080] In summary, the method for implementing block storage acceleration in a hyper-converged environment of the present invention is applicable to a hyper-converged cloud computing platform that uses Openstack for virtualization management, Type II computing virtualization, and Ceph RBD for underlying data storage. The cloud hard disk is mounted and used by a virtual machine and is particularly suitable for system disks. The method aims to solve the problem of dedicated block storage read and write performance in such an environment.

[0081] The above specific examples are used to illustrate the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made by those skilled in the art without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.

Claims

1. A method for implementing block storage acceleration in a hyper-converged environment, characterized in that: The steps include: S1. Add "accelerated volume" creation and modification interfaces to the OpenStack Cinder service to implement accelerated cloud disk creation and dynamic modification during runtime. Specific operations include: S1.

1. At the cloud drive product level, a visual operation interface is provided, allowing users to easily enable read and write acceleration for cloud drives. A cloud drive can be mounted and used by at most one virtual machine. S1.

2. At the Cinder Volume virtual block storage management layer, you are fully responsible for connecting to the cloud disk product layer and implementing "accelerated volume" related instructions, including: S1.2.

1. First, define and create an accelerated volume type to provide a basic template for subsequent instantiation operations. S1.2.

2. Next, create an accelerated volume. Create an accelerated mirror interface by calling Ceph librbd. Configure the mirror attributes, limit the mount to a maximum of one virtual machine, and enable the local acceleration feature, namely, the "LOCAL_ACC" feature. Finally, when business needs change, the Ceph librbd image feature configuration interface is called to remove or re-add the "LOCAL_ACC" feature of the image as needed. This allows for dynamic adjustment of cloud disk performance to accommodate the varying storage speed requirements at different times and business intensities. S2. Modify the Ceph librbd client library and Ceph OSD server of the Ceph storage layer to add the shortest path addressing function, optimize the data read and write paths, and implement the read and write acceleration function of the client changing the primary write and primary read. For hyper-converged environments using the Ceph distributed storage system, different strategies are used to implement the shortest path addressing for data read and write based on the location relationship between the virtual machine and the storage replica OSD node. The details are as follows: (A) When the virtual machine and the primary OSD are on the same node, the default read / write path is the shortest path; (B) When the virtual machine is not on the same node as the master OSD, but is on the same node as one of the slave OSDs, the read and write paths are shortened by changing the master to the master. The change of master operation is to change the slave OSD to the master OSD. (C) When the client and the primary OSD and secondary OSD storing the replica are not on the same node, the current default read / write path is the shortest path; S3: Connect the Hypervisor in Type II virtualization to Ceph librbd's accelerated read and write functions to implement the virtual machine cloud hard disk read and write acceleration function.

2. The method for implementing block storage acceleration in a hyper-converged environment according to claim 1, characterized in that: Specifically, perform the following operations to implement steps S1.2.2 and S1.2.3: By calling relevant instructions to add the "LOCAL_ACC" flag to the rbd image, an accelerated volume is created and the local acceleration feature is enabled. When the Ceph librbd client library creates an RBD image, it also sets the "LOCAL_ACC" feature. When you subsequently need to enable an RBD image that has already been created and has the acceleration feature, the Ceph librbd client library automatically starts a verification process to check whether the "LOCAL_ACC" feature exists. If business requirements change during cloud disk operation and cloud disk performance needs to be adjusted, call the Ceph librbd image feature setting interface to modify the existing features of the rbd image and cancel or re-add the "LOCAL_ACC" feature as needed. This adapts to the differentiated storage speed requirements at different time periods and business intensities, achieving dynamic optimization of cloud disk performance.

3. The method for implementing block storage acceleration in a hyper-converged environment according to claim 1, wherein: The specific operations of step S2 include: S2.

1. Develop a functional module in the Ceph librbd client library to add and disable the "LOCAL_ACC" feature of the mirror, enabling close interaction with the upper-layer OpenStack Cinder service to dynamically adjust the mirror acceleration status based on different instructions. S2.

2. Optimize the data read and write paths in the Ceph librbd client library, embedding client-side local read and write acceleration algorithms to ensure efficient data transmission at the client level. S2.

3. Develop a functional module for changing master storage write and read in the Ceph OSD server to ensure that data reading and writing are not affected by master node switching.

4. The method for implementing block storage acceleration in a hyper-converged environment according to claim 3, wherein: At the Ceph librbd client library level, the specific methods for implementing shortest path addressing and master change operations through the write interface and read interface are as follows: The shortest path addressing is performed internally in the Librbd write interface. If the current write is an expedited write, it first determines whether the replica has a local node. If there is a local node and the primary replica is not a local node, the primary replica is changed to the local node, and the current write operation is sent to the changed primary OSD on the local node. The changed primary OSD then completes the synchronous write of the remaining replicas. If the primary replica is a local node, the current write operation is directly sent to the primary replica on the local node for the write operation. The shortest path addressing is performed internally in the Librbd read interface. If the current read is an accelerable read, it first determines whether the replica has a local node. If there is a local node and the primary replica is not a local node, the primary node is changed to the local node, and then the current read operation is sent to the changed primary OSD on the local node to complete the data read operation from the local node; if the primary replica is a local node, the current read operation is directly sent to the primary replica on the local node for the read operation.

5. The method for implementing block storage acceleration in a hyper-converged environment according to claim 4, characterized in that: The specific operations of step S3 include: S3.

1. In a Type II virtualization scenario, open the image to prepare for subsequent connection with the Ceph librbd client library. S3.

2. Implement the Ceph librbd client library to become the primary storage write interface. This ensures that when the VM performs data write tasks, it can directly use the optimized write function of the Ceph librbd library to write data to the storage layer at high speed and stability. S3.

3. At the same time, the Ceph librbd client library is seamlessly connected to the primary storage read interface, so that when the virtual machine reads data, it can use the accelerated read function of the Ceph librbd client library to quickly obtain the required data, ultimately achieving all-round acceleration of virtual machine cloud hard disk reading and writing.

Images