Management method and device for Ceph volume of SPDK type of Openstack cloud platform, equipment and storage medium

Abstract

The invention provides a management method and device for a Ceph volume of an Openstack cloud platform SPDK type, equipment and a storage medium. The method comprises the following steps: creating a Ceph volume of an SPDK type on the basis of an OpenStack storage side; the OpenStack computing side responds to a mounting request, the mounting request comprises a Ceph volume of a target SPDK type, a volume mounting interface is called, metadata of the Ceph volume type of the target SPDK type is obtained, an SPDK-rbd type bdev block device and a vhost-user-blk controller are created, the SPDK-rbd type bdev block device is used for accessing and managing Ceph volume storage, and the vhost-user-blk controller is used for accessing the SPDK-rbd type bdev block device through an SPDK framework; and completing the mounting of the Ceph volume of the target SPDK type. According to the method and the device, the Ceph volume of the SPDK type is managed through the OpenStack storage side and the OpenStack calculation side, so that the virtual machine can hang and unload the Ceph volume of the SPDK type, and the management surface and the data surface of the Ceph volume of the SPDK type can be recovered when the network of the virtual machine is abnormal.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a management method, apparatus, device, and storage medium for an Openstack cloud platform SPDK-type Ceph volume. Background Art

[0002] Ceph is an open source distributed storage system with advantages such as high scalability, high performance, and high reliability. It is currently the mainstream backend storage of OpenStack, providing a unified shared storage service for OpenStack. Ceph volume refers to the logical storage unit created in the Ceph storage system, which can be used by virtual machines in OpenStack. The Storage Performance Development Kit (SPDK) provides a set of tools and libraries for writing high-performance, scalable user-mode storage applications. It mainly reduces the overhead in the I / O path by bypassing the kernel through user-mode drivers, thereby improving storage performance. In the OpenStack cloud platform, the use of SPDK technology can reduce the latency of storage I / O operations and improve throughput. In theory, the performance of Ceph volumes can be significantly improved.

[0003] However, although SPDK can improve storage performance, it is not easy to achieve consistent performance improvement in distributed environments (such as Ceph), which requires a lot of performance tuning and testing. In the OpenStack cloud platform, there is a lack of management of Ceph volumes for SPDK acceleration scenarios. For example, in the OpenStack environment, the correctness of the configuration of the existing SPDK-accelerated Ceph volumes cannot be guaranteed, and once SPDK is disconnected due to network failure or has other problems that require restarting, the storage management function of OpenStack is affected, resulting in data loss or service interruption. Summary of the invention

[0004] The present application provides a management method, apparatus, device, and storage medium for an Openstack cloud platform SPDK-type Ceph volume, which is used to solve the technical problem that the correctness of the configuration of the SPDK-accelerated Ceph volume in the OpenStack cloud platform cannot be guaranteed, and data loss or service interruption is prone to occur during restart.

[0005] In a first aspect, the present application provides a method for managing Ceph volumes of the SPDK type on an OpenStack cloud platform, including:

[0006] Create a Ceph volume of SPDK type based on the OpenStack storage side;

[0007] The OpenStack computing side responds to the mount request, which includes the target SPDK type Ceph volume, calls the mount volume interface, obtains the metadata of the target SPDK type Ceph volume type, creates an SPDK-rbd type bdev block device and a vhost-user-blk controller, wherein the SPDK-rbd type bdev block device is used to access and manage Ceph volume storage, and the vhost-user-blk controller is used to access the SPDK-rbd type bdev block device through the SPDK framework;

[0008] Complete the mounting of the target SPDK type Ceph volume.

[0009] Optionally, in the method described above, creating a Ceph volume of the SPDK type based on OpenStack includes:

[0010] In response to the storage volume creation request, confirm the type of the storage volume to be created in the cinder service of OpenStack;

[0011] When the storage volume to be created is a Ceph volume of the SPDK type, the Ceph volume is created by calling a block device library function based on the SPDK-driver, where the block device library function is a block storage interface provided by Ceph;

[0012] An identifier is added to the created Ceph volume, where the identifier is used to indicate that the Ceph volume is a Ceph volume of the SPDK type.

[0013] Optionally, in the method described above, confirming the type of the storage volume to be created in the block storage service of OpenStack includes:

[0014] The cinder service analyzes the storage volume creation request to obtain a storage volume to be created, where the storage volume to be created includes block storage information;

[0015] If the block storage information in the storage volume to be created includes preset SPDK information, it is determined that the type of the storage volume to be created is an SPDK type.

[0016] Optionally, in the method described above, creating an SPDK-rbd type bdev block device includes:

[0017] Querying from the metadata whether there is a historical bdev of a Ceph volume of the target SPDK type, where the historical bdev is of rbd type;

[0018] If so, push error information;

[0019] If not, a command for creating an rbd type bdev is sent to the SPDK-vhost, and an SPDK-rbd type bdev block device is created based on the SPDK-vhost, wherein the SPDK-rbd type bdev block device includes identification information uniquely corresponding to the Ceph volume of the target SPDK type.

[0020] Optionally, in the method described above, creating a vhost-user-blk controller includes:

[0021] After confirming that the SPDK-rbd type bdev block device is created successfully, call the SPDK-rbd-create-blk-controller interface to send a controller creation command to the SPDK vhost service, and create a SPDK-based blk type vhost-user-blk controller based on the vhost service.

[0022] Optionally, in the method as described above, completing the mounting of the target SPDK type Ceph volume includes:

[0023] After confirming that the vhost-user-blk controller is successfully created, obtain the socket path corresponding to the vhost-user-blk controller;

[0024] The OpenStack computing side constructs an extensible markup language according to the socket path, where the extensible markup language is used to describe the SPDK-rbd type bdev block device;

[0025] The virtualization interface library is called, and the extensible markup language is passed into the volume mounting interface of the virtualization interface library to complete the mounting of the Ceph volume of the target SPDK type.

[0026] Optionally, the method as described above further comprises:

[0027] Start the SPDK vhost service so that all business operations are written to the operate.log log file;

[0028] Reconnection parameters are configured in the computing side of OpenStack, and the reconnection parameters are used to send a reconnection request to the virtual host according to a preset time period when it is detected that the connection of the virtual host is disconnected.

[0029] In a second aspect, the present application provides a management device for a Ceph volume of the SPDK type, including:

[0030] The storage volume creation module is used to create SPDK-type Ceph volumes based on the OpenStack storage side;

[0031] The target volume acquisition module, in which the OpenStack computing side responds to a mount request including a target SPDK type Ceph volume, calls a volume mount interface, obtains metadata of the target SPDK type Ceph volume type, creates an SPDK-rbd type bdev block device and a vhost-user-blk controller, wherein the SPDK-rbd type bdev block device is used to access and manage Ceph volume storage, and the vhost-user-blk controller is used to access the SPDK-rbd type bdev block device through the SPDK framework;

[0032] The target volume mounting module is used to complete the mounting of the target SPDK type Ceph volume.

[0033] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and computer executable instructions stored in the memory and executable on the processor, wherein when the processor executes the computer executable instructions, it implements the method for managing Ceph volumes of the SPDK type of the OpenStack cloud platform described in any one of the first aspects above.

[0034] In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the management method of the Ceph volume of the SPDK type of the OpenStack cloud platform described in any one of the first aspects above.

[0035] In a fifth aspect, the present application provides a computer program product. When the computer program product runs on a terminal device, the terminal device executes the method for managing Ceph volumes of the SPDK type of the OpenStack cloud platform as described in any one of the first aspects above.

[0036] The present application provides a method, device, equipment, and storage medium for managing Ceph volumes of SPDK type on the Openstack cloud platform. The method creates a Ceph volume of SPDK type based on the OpenStack storage side. The OpenStack computing side responds to a mount request, the mount request includes a target SPDK type Ceph volume, calls a mount volume interface, obtains metadata of the target SPDK type Ceph volume type, creates an SPDK-rbd type bdev block device and a vhost-user-blk controller, the SPDK-rbd type bdev block device is used to access and manage Ceph volume storage, and the vhost-user-blk controller is used to access the SPDK-rbd type bdev block device through the SPDK framework; and completes the mounting of the target SPDK type Ceph volume. The present application manages SPDK type Ceph volumes through the OpenStack storage side and computing side, and realizes the mounting and unmounting of SPDK type Ceph volumes by virtual machines and the recovery of the management and data surfaces of SPDK type Ceph volumes due to network anomalies of virtual machines. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0038] FIG. 1( a ) is a schematic diagram of an application scenario of the SPDK type Ceph volume management method provided in an embodiment of the present application; FIG. 1( b ) is a schematic diagram of an application scenario of the SPDK type Ceph volume management method provided in an embodiment of the present application Figure 2 ;

[0039] Figure 2 A flowchart of a method for managing Ceph volumes of the SPDK type on an OpenStack cloud platform provided in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of a management device for an SPDK-type Ceph volume on an OpenStack cloud platform provided in an embodiment of the present application;

[0041] Figure 4 A schematic diagram of the structure of an electronic device for a method for managing Ceph volumes of the SPDK type on an OpenStack cloud platform provided in an embodiment of the present application.

[0042] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0043] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0044] In the related technology, in the OpenStack cloud platform, the use of SPDK technology can reduce the latency of storage I / O operations and improve throughput. In theory, the performance of Ceph volumes can be significantly improved, but there is a lack of management of Ceph volumes for SPDK acceleration scenarios.

[0045] In view of the above technical problems, the embodiments of the present application aim to propose a management method, apparatus, device, and storage medium for SPDK-type Ceph volumes. The core concept of the method is: the preparation and creation process of SPDK-accelerated Ceph shared volumes is implemented through the basic configuration of the block storage service in OpenStack, the computing service is connected to the SPDK interface to complete the mounting of the Ceph volume, and the correct configuration of the SPDK-accelerated Ceph volume is implemented, and the SPDK virtual host service is associated in the block storage service and the computing service, and the execution record of the SPDK driver is stored in real time in the virtual host service, so that when the virtual host service is restarted, the storage management function of OpenStack can still continue to operate normally, avoiding problems such as data omission.

[0046] In order to better understand the solution of the embodiment of the present application, an application scenario involved in the embodiment of the present application is first introduced below.

[0047] Please refer to Figure 1. Figure 1(a) is a schematic diagram of an application scenario of the SPDK type Ceph volume management method provided in an embodiment of the present application. As shown in Figure 1(a), it includes a user terminal 100 and a server 200, wherein the user terminal 100 can be used to send management instructions such as storage volume creation, deletion, and volume mounting to the server 200, and the server 200 performs related operations after receiving the instructions. Specifically, the server 200 is an OpenStack environment, which includes Cinder service, Nova service, Ceph and SPDKvhost, Cinder service includes cinder-api, cinder-volume and storage database, and Nova service includes nova-compute and SPDK driver.

[0048] For storage volume creation instructions, cinder-api sends the instructions to cinder-volume after receiving them. The cinder-volume service determines the creation severity based on the cinder-type in the instructions. If it is an SPDK-type accelerated Ceph volume, it sends a request to the SPDK driver. After receiving the creation request, the SPDK driver calls the RBDlibrary function to create the Ceph volume, and then adds a mark in the metadata of the Ceph volume to indicate that the current volume is an SPDK-type Ceph volume.

[0049] For the storage volume mounting instructions, nova-compute mainly sends a query request to the Cinder service after receiving the volume mounting request to query the information of the volume to be mounted. After cinder-api receives the query request, it finds the corresponding volume information from the cinder database and returns it to nova-compute. nova-compute queries whether there is a tag of the spdk-rbd keyword based on the metadata of the obtained volume information. If it exists, it proves that the current Ceph volume that needs to be mounted is the SPDK type. Nova-compute sends the volume mounting request to the SPDK driver, which creates the relevant block device and returns a sock link path to nova-compute. Nova-compute calls the virtualization interface library and completes the mounting in combination with the sock link path.

[0050] FIG. 1( b ) is a schematic diagram of an application scenario of a method for managing Ceph volumes of the SPDK type on an OpenStack cloud platform provided in an embodiment of the present application. Figure 2 , as shown in Figure 1(b), it is mainly used in VM (Virtual Manufacturing) hosts, that is, virtual machines, including QEMU (Quick EMUlator, an open source virtual machine monitor and simulator). QEMU can establish a vhost-user communication channel with the SPDK vhost through a Unix socket. Therefore, when the operating system in the virtual machine issues storage requests (such as read and write operations), these requests are sent to QEMU through the Virtio storage device. After receiving the Virtio request, QEMU forwards the request to the SPDK vhost through the vhost-user protocol. The SPDK vhost processes these requests in user mode and interacts directly with Ceph to achieve high-performance storage operations.

[0051] The following specific embodiments are used to describe in detail how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0052] Figure 2 A flowchart of a method for managing SPDK-type Ceph volumes on an OpenStack cloud platform provided in an embodiment of the present application. Figure 2 As shown, the method of this embodiment includes:

[0053] S201: Create a Ceph volume of the SPDK type based on the OpenStack storage side.

[0054] The execution subject of the embodiment of the present application may be the above-mentioned server, or may be a SPDK-type Ceph volume management system in the server, wherein the SPDK-type Ceph volume management system may be implemented by software.

[0055] In this application, OpenStack includes two services, one is the block storage (Cinder) service, and the other is the computing (Nova) service. Among them, Cinder is responsible for managing and providing persistent block storage volumes. Cinder allows users to create, attach, detach and delete storage volumes, and supports multiple storage backends (such as Ceph). These storage volumes can be mounted on virtual machine instances for data storage; Nova is responsible for managing the life cycle of virtual machine instances, including operations such as creating, starting, stopping, migrating and deleting virtual machines. Nova provides management and scheduling of computing resources by interacting with the underlying virtualization technology (such as virtual hosts).

[0056] The management of SPDK-type Ceph volumes on the OpenStack storage side is mainly based on the service implementation of the Cinder module of OpenStack. The first step is to prepare and configure SPDK to support Ceph storage, and the second step is to manage these Ceph volumes through the driver layer of the Cinder module.

[0057] Before creation, preparations can include: modifying the cinder.conf configuration file, and adding the relevant SPDK-accelerated Ceph storage configuration information under the backend keyword. It can be understood that by adding SPDK-accelerated Ceph storage configuration information in cinder.conf, the Cinder service can recognize and use SPDK to accelerate Ceph storage volumes, thereby ensuring that Cinder can correctly interact with SPDK and Ceph storage systems. In addition, by defining the Cinder service type that uses SPDK acceleration, users can specify this type when creating Ceph volumes, thereby ensuring that the created volumes use SPDK-accelerated Ceph storage.

[0058] S202: The OpenStack computing side responds to the mount request, which includes the target SPDK type Ceph volume, calls the volume mount interface, obtains the metadata of the target SPDK type Ceph volume type, creates an SPDK-rbd type bdev block device and a vhost-user-blk controller, wherein the SPDK-rbd type bdev block device is used to access and manage Ceph volume storage, and the vhost-user-blk controller is used to access the SPDK-rbd type bdev block device through the SPDK framework.

[0059] This step is mainly implemented by the computing side (Nova service) in OpenStack. The Nova service of OpenStack is responsible for managing computing resources. The volume mount request is first received by the Nova service and then passed to the specific nova-compute module for processing. Specifically, after receiving the volume mount request, the nova-compute module will send a query request to the Cinder module to obtain detailed information about the storage volume to be mounted, so as to determine the type of storage volume in order to select the appropriate mounting method. For SPDK type Ceph volumes, nova-compute sends the volume mount request to the SPDK driver and calls the SPDK driver to process the SPDK-accelerated Ceph volume mount operation.

[0060] S203: Complete the mounting of the target SPDK type Ceph volume.

[0061] In this step, an Extensible Markup Language (XML) may be constructed according to the path of the vhost-user-blk controller, and the mount interface of Libvirt may be called to pass the XML in to implement the mount.

[0062] The management method of SPDK-type Ceph volumes provided in this embodiment is to create SPDK-type Ceph volumes based on the OpenStack storage side; the OpenStack computing side responds to the mount request, the mount request includes the target SPDK-type Ceph volume, calls the volume mount interface, obtains the metadata of the target SPDK-type Ceph volume type, creates an SPDK-rbd-type bdev block device and a vhost-user-blk controller, the SPDK-rbd-type bdev block device is used to access and manage Ceph volume storage, and the vhost-user-blk controller is used to access the SPDK-rbd-type bdev block device through the SPDK framework; and completes the mounting of the target SPDK-type Ceph volume. This application manages SPDK-type Ceph volumes through the OpenStack storage side and the computing side, and realizes the mounting and unmounting of SPDK-type Ceph volumes by virtual machines and the recovery of the management and data planes of SPDK-type Ceph volumes due to virtual machine network anomalies.

[0063] The technical solution of the above-mentioned SPDK type Ceph volume management method is introduced in detail below.

[0064] In a possible implementation, the SPDK type Ceph volume management method provided in this embodiment confirms the type of storage volume to be created in the block storage service of OpenStack, creates a Ceph volume based on the SPDK driver calling the block device library function and adds an identifier to the created Ceph volume.

[0065] Specifically, creating an SPDK-type Ceph volume based on OpenStack includes: in response to a storage volume creation request, confirming the type of the storage volume to be created in the cinder service of OpenStack; when the storage volume to be created is an SPDK-type Ceph volume, creating the Ceph volume based on the SPDK-driver calling a block device library function, wherein the block device library function is a block storage interface provided by Ceph; and adding an identifier to the created Ceph volume, wherein the identifier is used to indicate that the Ceph volume is an SPDK-type Ceph volume.

[0066] Furthermore, confirming the type of the storage volume to be created in the block storage service of OpenStack includes: the block storage service analyzes the request to create the storage volume to obtain the storage volume to be created, and the storage volume to be created includes block storage information; if the block storage information in the storage volume to be created includes preset SPDK information, determining that the type of the storage volume to be created is an SPDK type.

[0067] Within the Cinder service, the API component cinder-api of the Cinder service is responsible for receiving and processing user requests, and then the scheduler component cinder-schedule selects the appropriate storage backend (host), and finally the request is sent to the component cinder-volume that performs the storage operation. The cinder-volume service can determine the type of volume to be created based on the cinder-type specified in the request. If cinder-type contains a pre-set SPDK type, such as driver:spdk-rbd, the storage volume to be created is identified as a Ceph volume of the SPDK type. At this point, cinder-volume can send a request to create a volume to the SPDK driver and call the SPDK driver to perform the actual volume creation operation.

[0068] It is understandable that an identifier can be added to the metadata of the Ceph volume, such as volume-type:spdk-rbd, to identify that the volume is a Ceph volume accelerated by SPDK, so that the system can recognize and manage these SPDK-accelerated Ceph volumes and ensure that subsequent operations (such as mounting and unmounting volumes, etc.) can handle these volumes correctly.

[0069] In this embodiment, by confirming the type of storage volume to be created in the block storage service of OpenStack, the SPDK driver calls the block device library function to create a Ceph volume and adds an identifier to the created Ceph volume, the correct configuration of the SPDK-accelerated Ceph volume is achieved.

[0070] In a possible implementation, creating an SPDK-rbd type bdev block device includes: querying from the metadata whether there is a historical bdev of the target Ceph volume, the historical bdev being of the rbd type; if so, pushing an error message; if not, sending a command to create an rbd type bdev to the SPDK-vhost, and creating an SPDK-rbd type bdev block device based on the SPDK-vhost, the SPDK-rbd type bdev block device containing identification information uniquely corresponding to the target Ceph volume.

[0071] Creating a vhost-user-blk controller includes: after confirming that the SPDK-rbd type bdev block device is successfully created, calling the SPDK-rbd-create-blk-controller interface to send a controller creation command to the vhost service of SPDK, and creating a vhost-user-blk controller of the blk type based on SPDK based on the vhost service.

[0072] In this embodiment, the Nova service of OpenStack is responsible for managing computing resources. The volume mount request is first received by the Nova service and then passed to the specific nova-compute module for processing. After receiving the volume mount request, the nova-compute module will send a query request to the Cinder service to obtain detailed information of the target SPDK type Ceph volume to be mounted.

[0073] nova-compute determines the type of storage volume in order to select the appropriate mounting method. Specifically, based on the metadata in the volume information obtained from Cinder, it checks whether it contains the preset SPDK information (such as spdk-rbd). If it does, it means that the volume is an SPDK-accelerated Ceph volume, so the SPDK driver can be called to handle the mounting operation of the SPDK-accelerated Ceph volume.

[0074] In this embodiment, the SPDK driver can be specifically used to process SPDK-accelerated Ceph shared volumes, which can be divided into two levels: "spdk-rbd-driver" is responsible for the business logic related to OpenStack, and "spdk-base-driver" is responsible for the interface interaction with the SPDK virtual host (vhost). When the SPDK driver receives the volume attachment command, it will call the "spdk-rbd-attach" interface of the "spdk-rbd-driver". It can be understood that after creating an SPDK-rbd type bdev block device, a vhost-user-blk controller can be created to manage and access the SPDK-rbd type bdev block device through the controller.

[0075] It should be noted that spdk-rbd-driver can first call the spdk-rbd-create-bdev function to create a bdev block device of type rbd. It will first check whether the corresponding bdev block device of type rbd already exists (historical bdev block device of type rbd). If it does, it will report an error, otherwise it will send a command to the SPDK virtual host to create a new bdev block device of type rbd, with the name containing the UUID of the volume, thereby ensuring that a unique RBD block device is created for each volume and avoiding duplicate creation.

[0076] It should be noted that in this application, the query and verification steps can also be combined. For example, the Cinder module can directly return metadata containing the SPDK keyword to avoid nova-compute performing a secondary query.

[0077] In this embodiment, by calling the SPDK block device driver and performing a block device check, a corresponding Ceph block device is created for the verified target SPDK type Ceph volume, ensuring that the mount operation can proceed smoothly and the SPDK-accelerated Ceph volume is correctly configured.

[0078] In a possible implementation, the SPDK-type Ceph volume management method provided in this embodiment constructs an extensible markup language through a vhost-user-blk controller and a socket path, and then completes the mounting of the target SPDK-type Ceph volume according to the virtualization interface library called by the extensible markup language.

[0079] Specifically, the mounting of the target Ceph volume is completed, including: after confirming that the vhost-user-blk controller is successfully created, obtaining the socket path corresponding to the vhost-user-blk controller; the OpenStack computing side constructs an extensible markup language according to the socket path, and the extensible markup language is used to describe the SPDK-rbd type bdev block device; calling a virtualization interface library, passing the extensible markup language into the volume mounting interface of the virtualization interface library, and completing the mounting of the target Ceph volume.

[0080] In this embodiment, after the SPDK-rbd type bdev block device is successfully created in the previous step, the SPDK block device driver can call the spdk-rbd-create-blk-controller interface, send a command to the SPDK virtual host service, create a vhost-user-blk controller, and if successful, return a socket connection path. After returning the generated socket path to the nova-compute service, nova-compute constructs an XML containing the SPDK block device information, and calls the mount interface of the virtualization interface library, passing in the XML to achieve mounting.

[0081] It should be noted that in this application, pre-configuration and caching mechanisms can also be used to create and manage commonly used RVD block devices and controllers in advance to reduce the overhead of real-time creation; a higher-level API can also be developed to automatically generate the required XML and call the virtualization interface library interface to reduce the complexity of manual construction and calling.

[0082] In this embodiment, an extensible markup language is constructed by creating an SPDK block device controller and a socket path, and then the mounting of the target SPDK type Ceph volume is completed according to the virtualization interface library called by the extensible markup language, so that the virtual machine can access the newly created SPDK-accelerated Ceph volume.

[0083] In a possible implementation, considering that the virtual host may experience network disconnection, the SPDK-type Ceph volume management method provided in this embodiment also includes: starting the SPDK vhost service so that all business operations are written to the operate.log log file; configuring reconnection parameters in the OpenStack computing service, and the reconnection parameters are used to send a reconnection request to the virtual host according to a preset time period when it is detected that the virtual host is disconnected.

[0084] In this step, the SPDK vhost service operations, such as creating and deleting block devices, can be recorded in log files. Since these operations are performed by the virtual host service, the log files are usually stored on the host where the virtual host service is located. When the virtual host service is restarted, the management plane data is restored by reading the log files to ensure the continuity and consistency of the system.

[0085] It is understandable that when the virtual machine mounts the volume, a reconnect parameter is added. This parameter ensures that if the virtual host service is disconnected due to a network failure while the virtual machine remains online, the virtual machine will periodically try to reconnect to the virtual host. Once the virtual host service is back online, the virtual machine can automatically restore the virtual host connection with SPDK.

[0086] In this embodiment, the specific structure of xml is as follows:

[0087] <disk type='vhostuser'device='disk'>

[0088] <driver name='qemu'type='raw' / >

[0089] <source type＝'unix'path＝' tmp vhost-blk.sock'>

[0090] <reconnect enabled='yes'timeout='10' / >

[0091]

[0092] <target dev='vdf'bus='virtio' / >

[0093]

[0094] In this embodiment, by configuring reconnection parameters in the computing service of OpenStack, the high availability of the system is improved to ensure that the virtual machine can reconnect immediately and continue to work normally after the virtual host service is restored. In addition, through the automatic reconnection mechanism, the service interruption time caused by the virtual host service failure is reduced, ensuring that the communication between the data plane and the management plane can be restored as soon as possible.

[0095] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

[0096] It should be further noted that, although the various steps in the flowchart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0097] Figure 3 A schematic diagram of a management device for an OpenStack cloud platform SPDK type Ceph volume provided in an embodiment of the present application. Figure 3 As shown, the management device of the SPDK type Ceph volume includes:

[0098] A storage volume creation module 31 is used to create a Ceph volume of the SPDK type based on OpenStack, and store the Ceph volume of the SPDK type in a block storage service database, where the block storage service database is used to store the Ceph volume of the SPDK type and the Ceph volume of the non-SPDK type;

[0099] The target volume acquisition module 32 is used to respond to a mount request, wherein the mount request includes a target SPDK type Ceph volume, obtain the target SPDK type Ceph volume from the block storage service database, determine the type of the target SPDK type Ceph volume, and when the type of the target volume is SPDK, obtain the SPDKdriver of the target SPDK type Ceph volume;

[0100] A driver execution module 33, used to create a Ceph block device according to the SPDK driver, and start the virtual host service of the SPDK, wherein the virtual host service is used to store the execution record of the SPDK driver in real time;

[0101] The target volume mounting module 34 is used to call the virtualization interface library to complete the mounting of the target SPDK type Ceph volume based on the Ceph block device.

[0102] In a possible design, the storage volume creation module 31 is specifically used for:

[0103] In response to the storage volume creation request, confirm the type of the storage volume to be created in the block storage service of OpenStack;

[0104] When the storage volume to be created is a Ceph volume of the SPDK type, the Ceph volume is created by calling a block device library function based on the SPDK driver, where the block device library function is a block storage interface provided by Ceph;

[0105] An identifier is added to the created Ceph volume, where the identifier is used to indicate that the Ceph volume is a Ceph volume of the SPDK type.

[0106] In a possible design, the storage volume creation module 31 is specifically used for:

[0107] The block storage service analyzes the storage volume creation request to obtain a storage volume to be created, where the storage volume to be created includes block storage information;

[0108] If the block storage information in the storage volume to be created includes preset SPDK information, it is determined that the type of the storage volume to be created is an SPDK type.

[0109] In a possible design, the SPDK driver includes an SPDK block device driver, and the SPDK block device driver is used to implement the service encapsulation of OpenStack. The driver execution module 33 is specifically used to:

[0110] Call the SPDK block device driver to obtain the block device interface;

[0111] A block device check is performed based on the block device interface, and a Ceph block device corresponding to the target SPDK type Ceph volume is created after the check passes.

[0112] In a possible design, the SPDK driver also includes an SPDK basic driver, and the SPDK basic driver is used to implement interface encapsulation for interacting with the SPDK virtual host. The driver execution module 33 is specifically used to:

[0113] Check whether the target SPDK type Ceph volume has a historical block device;

[0114] If so, the test fails and an error message is pushed;

[0115] If not, a Ceph block device is created in the virtual host based on the SPDK basic driver, and the Ceph block device includes identification information that uniquely corresponds to the Ceph volume of the target SPDK type.

[0116] In a possible design, the target volume mounting module 34 is specifically used for:

[0117] Creating an SPDK block device controller based on the Ceph block device, and obtaining a socket path based on the SPDK block device controller;

[0118] Using a computing service of OpenStack to construct an extensible markup language according to the socket path, wherein the extensible markup language is used to describe the Ceph block device;

[0119] The virtualization interface library is called, and the extensible markup language is passed into the mounting interface of the virtualization interface library to complete the mounting of the Ceph volume of the target SPDK type.

[0120] In a possible design, the target volume mounting module 34 is further specifically used for:

[0121] A reconnection parameter is configured in the computing service of OpenStack, and the reconnection parameter is used to send a reconnection request to the virtual host according to a preset time period when it is detected that the connection of the virtual host is disconnected.

[0122] It should be understood that the above-mentioned device embodiments are only illustrative, and the device of the present application can also be implemented in other ways. For example, the division of units / modules in the above-mentioned embodiments is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.

[0123] In addition, unless otherwise specified, each functional unit / module in each embodiment of the present application may be integrated into one unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The above-mentioned integrated unit / module may be implemented in the form of hardware or in the form of a software program module.

[0124] Figure 4A schematic diagram of the structure of an electronic device for a method for managing Ceph volumes of the SPDK type on an OpenStack cloud platform provided in an embodiment of the present application. Figure 4 As shown, the electronic device of this embodiment includes: at least one processor 40 ( Figure 4 Only one is shown in the figure) a processor, a memory 41, and a computer program stored in the memory 41 and executable on at least one processor 40, and when the processor 40 executes the computer program, the steps in any of the above-mentioned method embodiments are implemented.

[0125] The electronic device may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will appreciate that Figure 4 These are merely examples of electronic devices and do not constitute a limitation on the electronic devices. The electronic devices may include more or fewer components than those shown in the figure, or a combination of certain components, or different components. For example, the electronic devices may also include input and output devices, network access devices, etc.

[0126] The processor 40 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0127] The specific implementation process of the processor 401 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0128] In some embodiments, the memory 41 may be an internal storage unit of an electronic device, such as a memory of the electronic device. In other embodiments, the memory 41 may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device. Further, the memory 41 may also include both an internal storage unit of the electronic device and an external storage device. The memory 41 is used to store an operating system, an application program, a boot loader (BootLoader), data, and other programs, such as program codes of computer programs, etc. The memory 41 may also be used to temporarily store data that has been output or is to be output.

[0129] The embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0130] The computer-readable storage medium mentioned above can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0131] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in the above-mentioned electronic device.

[0132] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0133] In the above embodiments, the description of each embodiment has its own emphasis. For the part not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0134] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0135] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for managing Ceph volumes of SPDK type on an OpenStack cloud platform, characterized in that: Create a Ceph volume of SPDK type based on the OpenStack storage side; The OpenStack computing side responds to the mount request, which includes the target SPDK type Ceph volume, calls the mount volume interface, obtains the metadata of the target SPDK type Ceph volume type, creates an SPDK-rbd type bdev block device and a vhost-user-blk controller, wherein the SPDK-rbd type bdev block device is used to access and manage Ceph volume storage, and the vhost-user-blk controller is used to access the SPDK-rbd type bdev block device through the SPDK framework; Complete the mounting of the target SPDK type Ceph volume.

2. The method according to claim 1, characterized in that The creation of an SPDK-type Ceph volume based on OpenStack includes: In response to the storage volume creation request, confirm the type of the storage volume to be created in the cinder service of OpenStack; When the storage volume to be created is a Ceph volume of the SPDK type, the Ceph volume is created by calling a block device library function based on the SPDK-driver, where the block device library function is a block storage interface provided by Ceph; An identifier is added to the created Ceph volume, where the identifier is used to indicate that the Ceph volume is a Ceph volume of the SPDK type.

3. The method according to claim 2, characterized in that Confirming the type of storage volume to be created in the block storage service of OpenStack includes: The cinder service analyzes the storage volume creation request to obtain a storage volume to be created, where the storage volume to be created includes block storage information; If the block storage information in the storage volume to be created includes preset SPDK information, it is determined that the type of the storage volume to be created is an SPDK type.

4. The method according to claim 1, characterized in that: The creation of the SPDK-rbd type bdev block device includes: Querying from the metadata whether there is a historical bdev of a Ceph volume of the target SPDK type, where the historical bdev is of rbd type; If so, push error information; If not, a command for creating an rbd type bdev is sent to the SPDK-vhost, and an SPDK-rbd type bdev block device is created based on the SPDK-vhost, wherein the SPDK-rbd type bdev block device includes identification information uniquely corresponding to the Ceph volume of the target SPDK type.

5. The method according to claim 4, characterized in that The creation of the vhost-user-blk controller includes: After confirming that the SPDK-rbd type bdev block device is created successfully, call the SPDK-rbd-create-blk-controller interface to send a controller creation command to the SPDK vhost service, and create a SPDK-based blk type vhost-user-blk controller based on the vhost service.

6. The method according to any one of claim 5, characterized in that: The step of completing the mounting of the target SPDK type Ceph volume includes: After confirming that the vhost-user-blk controller is successfully created, obtain the socket path corresponding to the vhost-user-blk controller; The OpenStack computing side constructs an extensible markup language according to the socket path, where the extensible markup language is used to describe the SPDK-rbd type bdev block device; The virtualization interface library is called, and the extensible markup language is passed into the volume mounting interface of the virtualization interface library to complete the mounting of the Ceph volume of the target SPDK type.

7. The method according to any one of claims 1 to 6, characterized in that: The method further includes: Start the SPDK vhost service so that all business operations are written to the operate.log log file; Reconnection parameters are configured in the computing side of OpenStack, and the reconnection parameters are used to send a reconnection request to the virtual host according to a preset time period when it is detected that the connection of the virtual host is disconnected.

8. A management device for Ceph volumes of SPDK type on an OpenStack cloud platform, characterized in that: include: The storage volume creation module is used to create SPDK-type Ceph volumes based on the OpenStack storage side; The target volume acquisition module, in which the OpenStack computing side responds to a mount request including a target SPDK type Ceph volume, calls a volume mount interface, obtains metadata of the target SPDK type Ceph volume type, creates an SPDK-rbd type bdev block device and a vhost-user-blk controller, wherein the SPDK-rbd type bdev block device is used to access and manage Ceph volume storage, and the vhost-user-blk controller is used to access the SPDK-rbd type bdev block device through the SPDK framework; The target volume mounting module is used to complete the mounting of the target SPDK type Ceph volume.

9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

Images