An online thin migration method for Ceph RBD type volumes based on OpenStack

Abstract

This invention discloses an online thin migration method for Ceph RBD type volumes based on OpenStack, relating to the field of OpenStack cloud computing technology. The method includes: a user requests to modify the type of an in-use volume on a virtual machine via the Cinder API, providing a UUID, the new type, and a migration strategy; the Cinder Volume service determines whether a new volume needs to be created and notifies the nova-api to perform a copy switch; the nova-api verifies the UUID and queries the compute node, sending the new volume information to the nova-compute service; the nova-compute service configures the detect-zeroes option according to the driver list, and changes the configuration to off after the volume migration is completed; finally, the Cinder API is called to mount the new volume and unmount the old volume. This invention ensures that the actual storage space occupied by the virtual block device does not significantly increase after the volume type switch is completed, thus saving space.

Description

Technical Field

[0001] This invention relates to the field of OpenStack cloud computing technology, specifically to an online thin migration method for CephRBD type volumes based on OpenStack. Background Technology

[0002] OpenStack, a leader in the cloud computing field, has rapidly developed since its inception, becoming the preferred choice for private cloud solutions. It is not only an open-source cloud management platform software, but also the preferred solution for private cloud scenarios. By using OpenStack to manage and optimize public and private cloud resources, enterprises can provide services such as virtual machines, virtual disks, and virtual VPCs, improving data center resource utilization and reducing costs.

[0003] Under OpenStack management, the Virtual Disk Management Service (Cinder), as the core of virtual disk management, not only supports online switching of volume types, enabling seamless conversion from one type to another, but also allows online volume migration. Online volume migration mainly occurs during backend volume switching or volume type switching, ensuring that virtual machines continue running after data synchronization by copying data to the new volume in real time. Meanwhile, volume thinning is also an important feature, allowing the conversion of thick prepared volumes to thin prepared volumes. Thick prepared volumes have a virtual block device capacity equal to the actual storage capacity allocated to them, while thin prepared volumes have an initial capacity less than the actual allocated storage capacity and dynamically grow based on write demand. The advantage of this mechanism is that it can provide users with virtual disk space nominally exceeding the actual physical storage capacity.

[0004] However, current online volume type switching technology faces a challenge: it relies on whether the storage device supports thin writes. Thin writes refer to the situation where, when zeros are written to the end of a block device, the storage device does not actually allocate new storage capacity. When using Ceph as the storage device, even if zeros are written to the end of a logical block device, corresponding storage space is still allocated. This results in a significant increase in the storage space occupied by the virtual disk before and after a volume type switch. Summary of the Invention

[0005] This invention addresses the needs and shortcomings of current technological development by providing an online thin migration method for CephRBD type volumes based on OpenStack. This method ensures that the actual storage space occupied by the virtual block device does not increase significantly after the volume type switch is completed, thus achieving the goal of saving space.

[0006] The present invention provides an online thin migration method for Ceph RBD type volumes based on OpenStack, and the technical solution adopted to solve the above-mentioned technical problems is as follows:

[0007] An online thin migration method for Ceph RBD type volumes based on OpenStack includes the following steps:

[0008] S1. The user selects an in-use volume mounted on a virtual machine and initiates a request to modify the volume type via the Cinder API. The request includes the UUID of the selected volume, the new volume type, and the volume migration strategy.

[0009] S2. The Cinder API finds the backend storage and sends a request to the Cinder Volume service. It determines whether the new and old volume types correspond to the same backend. If they are the same, it directly updates the database record. Otherwise, it creates a new volume and notifies nova-api to perform volume copying and switching operations.

[0010] S3 and nova-api verify the UUID and query the compute node where the virtual machine is located, and send the new volume information and its correspondence with the selected volume to the nova-compute service;

[0011] The S4 and nova-compute services add the detect-zeroes option to the API for the online copying and switching of volumes in the virtual machine manager;

[0012] S5. If the storage backend corresponding to the driver in the driver list to be processed cannot support simplified volume migration, the nova-compute service determines whether the driver of the new volume is in the driver list to be processed. If it is, the detect-zeroes option is not configured when performing online volume copying and switching. If not, the detect-zeroes option is configured when performing online volume copying and switching.

[0013] S6. When the driver for the new volume is in the list of drivers to be processed, further query the version of the virtual machine manager and determine whether its version meets the requirements. a) If it meets the requirements, configure the detect-zeroes attribute of the virtual disk to on. b) If it does not meet the requirements, do not configure the detect-zeroes option when performing online copying and switching of volumes.

[0014] The S7 and nova-compute services wait for the virtual machine manager to complete the volume migration operation, and then call the virtual machine manager's method to change the detect-zeroes configuration of the corresponding disk to off;

[0015] The S8 and nova-compute services call the Cinder API to mount the new volume and notify the Cinder service to unmount the selected volume.

[0016] Optionally, in step S1, after the user initiates a request through the Cinder API, the Cinder API service performs the following checks:

[0017] Check if the selected volume's UUID is valid and exists in the database;

[0018] Does the new volume type exist in the database?

[0019] Is the volume migration policy set to "Do not perform migration" or "Perform volume migration"?

[0020] After the inspection is completed, proceed with the subsequent operations.

[0021] Optionally, step S2 specifically includes:

[0022] The Cinder API finds the corresponding backend storage based on the UUID of the volume selected by the user and sends the request to the corresponding Cinder volume service backend for processing.

[0023] The Cinder Volume service first determines whether the new volume type requested by the user corresponds to the same backend as the current type of the selected volume.

[0024] a) If so, directly modify the volume record in the database, update the volume type in the volume record to the new volume type requested by the user, and return success.

[0025] b) If not, the backend migration is performed. The Cinder Volume service creates a new volume of the same type as the new volume requested by the user. Then, the UUID of the selected volume, virtual machine, and new volume is sent to the nova-api service to notify it to perform volume copy and switching operations.

[0026] Optionally, step S3 specifically includes:

[0027] nova-api verifies the UUID of the selected volume, virtual machine, and new volume;

[0028] After successful verification, the compute node where the virtual machine is located is queried based on the virtual machine's UUID, and the new volume information and its correspondence with the selected volume are sent to the nova-compute service of that compute node.

[0029] Optionally, nova-api verifies the UUID of the selected volume, virtual machine, and new volume. Specific verification operations include:

[0030] Confirm that the virtual machine's UUID is a valid UUID string and that the virtual machine exists;

[0031] Confirm that the selected volume and the new volume exist.

[0032] Optionally, in step S4, during the copying process, the virtual machine manager reads the data segment of the selected volume and determines whether its content is all 0:

[0033] a) If so, call the discard command of the virtual machine manager to release the portion of the content with the given offset and length in the new volume;

[0034] b) If not, then execute the write logic.

[0035] Optionally, in step S7, the nova-compute service calls the virtual machine manager's method to modify the corresponding disk's detect-zeroes configuration to off, which disables the storage device's detection of whether the written data is 0. This prevents the virtual machine's application system from checking whether the data is all zeros when writing new data.

[0036] Optionally, when the Cinder service unmounts the selected volume, it performs the following steps:

[0037] The Cinder service validates the incoming parameters to ensure that the UUID, selected volume, and new volume information are valid.

[0038] After confirming the parameters are valid, the Cinder service copies the metadata information of the selected volume, excluding the UUID, to the new volume;

[0039] The Cinder service deletes the selected volume, including removing the data and metadata of the selected volume from the storage system and releasing the associated resources.

[0040] After the selected volume is deleted, the Cinder service continues to clear the contents of the selected volume;

[0041] The Cinder service modifies the UUID of the new volume to the UUID of the selected volume.

[0042] The online thin migration method for Ceph RBD type volumes based on OpenStack, as proposed in this invention, has the following advantages compared to existing technologies:

[0043] 1. This invention ensures that the actual storage space occupied by the virtual block device does not increase significantly after the volume type switching is completed, thus saving space. It can maintain the streamlined characteristics of the new volume after the online volume migration is completed, thereby improving the migration speed and saving resources. It is applicable to various volume types and migration strategies, provides a flexible volume management method, and can be expanded and adjusted according to different needs.

[0044] 2. This invention effectively reduces storage space waste through online streamlined migration. The entire migration process is conducted online without interrupting virtual machine services, allowing users to complete volume type conversion without downtime, ensuring business continuity and stability. Verifying UUIDs and querying compute nodes ensures operational security and accuracy. Checking the new volume driver and virtual machine manager version guarantees compatibility and reliability. Configuring the `detect-zeroes` option based on the driver list and virtual machine manager version optimizes migration performance, further improving efficiency. After the new volume is mounted, the selected volume is unmounted, releasing unused resources and facilitating better management of system resources and improved resource utilization. The use of the `detect-zeroes` option during migration ensures data consistency before and after migration, avoiding problems caused by data inconsistency.

[0045] 3. This invention is compatible with different versions of virtual machine managers and different types of drivers, and no further processing is required for drivers that already support simplified migration; it saves the resource usage of backend storage, avoids the situation where migrating sparse volumes would also occupy the same capacity as the virtual volume size, saves storage resources, and reduces the operating costs of data centers. Attached Figure Description

[0046] Appendix Figure 1 This is a flowchart of the method according to Embodiment 1 of the present invention. Detailed Implementation

[0047] To make the technical solution, the technical problem solved, and the technical effect of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with specific embodiments.

[0048] The English terms used in the embodiments are explained as follows:

[0049] OpenStack is an open-source cloud computing management platform project that provides a set of APIs for building and managing public and private clouds. OpenStack can control a large number of computing, network, and storage resources and provides users with a graphical interface through a dashboard to manage and control these resources.

[0050] Ceph is a distributed object storage system that provides high-performance, high-availability, and highly scalable storage solutions. Ceph can be used as block storage, file storage, or object storage.

[0051] RBD: RBD stands for Rados Block Device, a block storage interface provided by Ceph. It allows users to create and manage virtual disks on a Ceph cluster, which can be used by the operating system just like local disks.

[0052] The Cinder API is a collection of RESTful APIs that define the specific methods and paths for interacting with the Cinder service. It provides developers with a programming interface that allows them to interact directly with the Cinder service through code.

[0053] The Cinder API service serves as the front-end interface for OpenStack block storage services, responsible for receiving and processing external requests. These requests include operations such as volume creation, deletion, and mounting. The Cinder API service typically comprises three main components: cinder-api, cinder-scheduler, and cinder-volume. These components work together to implement the complete process from receiving API requests to completing volume operations.

[0054] Example 1:

[0055] Combined with appendix Figure 1 This embodiment proposes an online thin migration method for Ceph RBD type volumes based on OpenStack, which includes the following steps:

[0056] S1. The user selects an in-use volume mounted on a virtual machine and initiates a request to modify the volume type via the Cinder API. The request includes the UUID of the selected volume, the new volume type, and the volume migration strategy.

[0057] Subsequently, the Cinder API service performs the following checks:

[0058] i) Whether the selected volume's UUID is valid and exists in the database;

[0059] ii) Does the new volume type exist in the database?

[0060] iii) Whether the volume migration strategy is "do not perform migration" or "perform volume migration"; it should be added that: "do not perform volume migration" means that switching a volume from the previous volume type to the new volume type does not require any backend changes, while for the new volume type corresponding to a different type of volume backend, the "perform volume migration" option should be selected.

[0061] After the inspection is completed, proceed with the subsequent operations.

[0062] S2. The Cinder API finds the corresponding backend storage based on the UUID of the volume selected by the user and sends the request to the corresponding Cinder volume service backend for processing.

[0063] The Cinder Volume service first determines whether the new volume type requested by the user corresponds to the same backend as the current type of the selected volume:

[0064] a) If so, directly modify the volume record in the database, update the volume type in the volume record to the new volume type requested by the user, and return success;

[0065] b) If not, the backend migration is performed. The Cinder Volume service creates a new volume as the target volume. The type of the new volume is the same as the new volume type requested by the user. Then, the UUID of the selected volume, virtual machine and new volume is sent to the nova-api service to notify it to perform volume copy and switch operations.

[0066] S3 and nova-api validate the UUIDs of the selected volume, virtual machine, and new volume, including: confirming that the virtual machine's UUID is a valid UUID string and that the virtual machine exists, and confirming that the selected volume and new volume exist.

[0067] After successful verification, the compute node where the virtual machine is located is queried based on the virtual machine's UUID, and the new volume information and its correspondence with the selected volume are sent to the nova-compute service of that compute node.

[0068] The S4 and nova-compute services add the detect-zeroes option to the API for the online copying and switching of volumes by the virtual machine manager.

[0069] During the copying process, the virtual machine manager reads the data segment of the selected volume and checks if its content is all 0:

[0070] a) If so, call the discard command of the virtual machine manager to release the portion of the content with the given offset and length in the new volume;

[0071] b) If not, then execute the write logic.

[0072] S5. When the storage backend corresponding to a driver in the driver list that needs to be processed cannot support simplified volume migration, the nova-compute service determines whether the driver for the new volume is in the driver list that needs to be processed:

[0073] If so, then the detect-zeroes option is not configured when performing online volume copying and switching, and then proceed to step S6;

[0074] If not, then configure the detect-zeroes option when performing online volume copying and switching, and then continue to step S7.

[0075] S6. When the driver for the new volume is in the list of drivers to be processed, further query the version of the virtual machine manager and determine whether its version meets the requirements, and then continue to execute step S7.

[0076] a) If the requirements are met, the detect-zeroes property of the virtual disk is configured to be on. The purpose of configuring it to be on is to use the capabilities of the virtual machine manager mentioned in step S4, and when the input data is all zeros, the write-zero method of the virtual machine manager is called to release the data in the corresponding storage area of ​​the new volume, thereby saving storage space.

[0077] b) If the requirements are not met, the detect-zeroes option will not be configured when performing online volume copying and switching.

[0078] It should be noted that common virtual machine managers such as QEMU provide the QMP API, which allows cloud platform management programs to obtain the current version of the virtual machine manager.

[0079] The S7 and nova-compute services wait for the virtual machine manager to complete the volume migration operation, and then call the virtual machine manager's method to change the corresponding disk's detect-zeroes configuration to off. This disables the storage device's detection of whether the written data is 0, so that when the virtual machine's application system writes new data, the virtual machine manager no longer checks whether the data is all zeros, thus saving computing resources on the compute nodes.

[0080] The S8 and nova-compute services call the Cinder API to mount the new volume and notify the Cinder service to unmount the selected volume.

[0081] When the Cinder service unmounts the selected volume, it performs the following steps:

[0082] (i) The Cinder service validates the incoming parameters. The incoming parameters refer to the data information that the Cinder service needs to receive and process when performing the unmount operation. They usually include the UUID, the selected volume, and the new volume information. The validation determines that the UUID, the selected volume, and the new volume information are valid.

[0083] (ii) After confirming that the parameters are valid, the Cinder service copies the metadata information of the selected volume, excluding the UUID, to the new volume;

[0084] (iii) The Cinder service deletes the selected volume, including removing the data and metadata of the selected volume from the storage system and releasing the associated resources;

[0085] (iv) After the selected volume is deleted, the Cinder service continues to clear the contents of the selected volume;

[0086] (v) The Cinder service modifies the UUID of the new volume to the UUID of the selected volume.

[0087] In summary, the online thin migration method for Ceph RBD type volumes based on OpenStack, as proposed in this invention, ensures that the actual storage space occupied by the virtual block device does not increase significantly after the volume type switch is completed, thus saving space. It can also maintain the thin characteristics of the new volume after the online migration is completed, thereby improving the migration speed and saving resource usage.

[0088] This invention is applicable to various volume types and migration strategies, provides a flexible volume management method, and can be expanded and adjusted according to different needs.

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

Claims

1. An online thin migration method for Ceph RBD type volumes based on OpenStack, characterized in that, Includes the following steps: S1. The user selects an in-use volume mounted on a virtual machine and initiates a request to modify the volume type via the Cinder API. The request includes the UUID of the selected volume, the new volume type, and the volume migration strategy. S2. The Cinder API finds the backend storage and sends a request to the Cinder Volume service. It determines whether the new and old volume types correspond to the same backend. If they are the same, it directly updates the database record. Otherwise, it creates a new volume and notifies nova-api to perform volume copying and switching operations. S3 and nova-api verify the UUID and query the compute node where the virtual machine is located, and send the new volume information and its correspondence with the selected volume to the nova-compute service; The S4 and nova-compute services add the detect-zeroes option to the API for the online copying and switching of volumes in the virtual machine manager; S5. When the storage backend corresponding to the driver in the driver list to be processed cannot support the simplified volume migration, the nova-compute service determines whether the driver of the new volume is in the driver list to be processed. If it is, the detect-zeroes option is not configured when performing online volume copying and switching. If not, the detect-zeroes option is configured when performing online volume copying and switching. S6. When the driver for the new volume is in the list of drivers to be processed, further query the version of the virtual machine manager and determine whether its version meets the requirements. a) If it meets the requirements, configure the detect-zeroes attribute of the virtual disk to on. b) If it does not meet the requirements, do not configure the detect-zeroes option when performing online copying and switching of volumes. The S7 and nova-compute services wait for the virtual machine manager to complete the volume migration operation, and then call the virtual machine manager's method to change the detect-zeroes configuration of the corresponding disk to off; The S8 and nova-compute services call the Cinder API to mount the new volume and notify the Cinder service to unmount the selected volume. Specifically, the Cinder service validates the incoming parameters to ensure that the UUID, selected volume, and new volume information are valid. After confirming the parameters are valid, the Cinder service copies the metadata information of the selected volume (excluding the UUID) to the new volume. The Cinder service deletes the selected volume, including removing the data and metadata of the selected volume from the storage system and releasing related resources. After deleting the selected volume, the Cinder service continues to clear the contents of the selected volume. The Cinder service modifies the UUID of the new volume to the UUID of the selected volume.

2. The online thin migration method for Ceph RBD type volumes based on OpenStack according to claim 1, characterized in that, After executing step S1, when the user initiates a request through the Cinder API, the Cinder API service performs the following checks: Check if the selected volume's UUID is valid and exists in the database; Does the new volume type exist in the database? Is the volume migration policy set to "Do not perform migration" or "Perform volume migration"? After the inspection is completed, proceed with the subsequent operations.

3. The online thin migration method for Ceph RBD type volumes based on OpenStack according to claim 1, characterized in that, Step S2 specifically includes: The Cinder API finds the corresponding backend storage based on the UUID of the volume selected by the user and sends the request to the corresponding cindervolume service backend for processing. The Cinder Volume service first determines whether the new volume type requested by the user corresponds to the same backend as the current type of the selected volume. a) If so, directly modify the volume record in the database, update the volume type in the volume record to the new volume type requested by the user, and return success. b) If not, the backend migration is performed. The Cinder Volume service creates a new volume of the same type as the new volume requested by the user. Then, the UUID of the selected volume, virtual machine, and new volume is sent to the nova-api service to notify it to perform volume copy and switching operations.

4. The online thin migration method for Ceph RBD type volumes based on OpenStack according to claim 1, characterized in that, Step S3 specifically includes: nova-api verifies the UUID of the selected volume, virtual machine, and new volume; After successful verification, the compute node where the virtual machine is located is queried based on the virtual machine's UUID, and the new volume information and its correspondence with the selected volume are sent to the nova-compute service of that compute node.

5. The online thin migration method for Ceph RBD type volumes based on OpenStack according to claim 4, characterized in that, nova-api verifies the UUID of the selected volume, virtual machine, and new volume. The specific verification operations include: Confirm that the virtual machine's UUID is a valid UUID string and that the virtual machine exists; Confirm that the selected volume and the new volume exist.

6. The online thin migration method for Ceph RBD type volumes based on OpenStack according to claim 1, characterized in that, In step S4, during the copying process, the virtual machine manager reads the data segment of the selected volume and determines whether its content is all 0s. a) If so, call the discard command of the virtual machine manager to release the portion of the content with the given offset and length in the new volume; b) If not, then execute the write logic.

7. The online thin migration method for Ceph RBD type volumes based on OpenStack according to claim 1, characterized in that, In step S7, the nova-compute service calls the virtual machine manager's method to modify the corresponding disk's detect-zeroes configuration to off. This disables the storage device's detection of whether written data is zero, so that when the virtual machine's application system writes new data, the virtual machine manager no longer checks whether the data is all zeros.

Images