Quick transmission method and device for cloud host mirror images of multiple storage rear ends

Abstract

The invention relates to the technical field of software development, in particular to a quick transmission method and device for a cloud host mirror image with multiple storage rear ends, and the method comprises the steps: carrying out the segmentation processing of a mirror image file corresponding to a mirror image creation request when the mirror image is uploaded, carrying out parallel mirror image uploading processing on each segment of mirror image file data after the segmentation processing through different first cinder-volume nodes; when the mirror image is downloaded, whether mirror image pulling processing is carried out or not is judged according to the current mirror image state and the current mirror image storage position information, and if the mirror image pulling processing is judged to be carried out, segmentation processing is carried out on a mirror image pulling task according to the size of a mirror image file; and carrying out parallel mirror image downloading processing on each segment of mirror image pulling task data after segmentation processing through different second cinder-volume nodes. The mirror image transmission speed is high, the response speed of related operation of the cloud host mirror image is improved, and the whole cloud service is more efficient and agile.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to a method and device for quickly transmitting a cloud host image with multiple storage backends. Background Art

[0002] As enterprises accelerate their digital transformation, cloud computing application scenarios are becoming increasingly complex and diverse. As enterprises expand their businesses globally, they need to deploy cloud computing resources in different geographical locations to provide low-latency, high-availability services. This requires that cloud host images can be quickly transferred and deployed between different regions and different storage backends to ensure business continuity and user experience consistency.

[0003] In the traditional cloud computing architecture, cloud host image management faces many problems. Especially in a multi-storage backend environment, the efficiency of uploading and downloading images becomes a bottleneck. Taking object storage and ceph block storage as an example, in the past, when pulling images from object storage to block storage, cinder-volume (block storage volume management component) was usually used to download images through glance-api (image service application programming interface). This method shows obvious shortcomings in large concurrency scenarios, and the management network bandwidth is heavily occupied, resulting in obstruction of management plane data transmission.

[0004] In the above solution, the existing mirror transmission speed is slow and cannot meet the requirements of rapid elastic scaling and rapid business iteration in the cloud computing environment, resulting in delayed business response. Summary of the invention

[0005] In view of this, the present invention provides a method and device for quickly transmitting cloud host images with multiple storage backends to solve the problem that the existing image transmission speed is slow, cannot meet the needs of rapid elastic scaling and rapid business iteration in a cloud computing environment, and causes delays in business response.

[0006] In a first aspect, the present invention provides a method for quickly transmitting a cloud host image with multiple storage backends, the method comprising:

[0007] Receive a request from a user to create an image;

[0008] The image file corresponding to the image creation request is segmented, and each segment of the image file data after the segmentation is processed is processed in parallel through different first cinder-volume nodes, so as to upload the image file from the block storage to the object storage;

[0009] Receive a system disk creation request sent by a user, and obtain current image state and current image storage location information corresponding to the system disk creation request;

[0010] Determining whether to perform image pull processing according to the current image state and the current image storage location information;

[0011] If it is determined to perform image pull processing, the image pull task is segmented according to the image file size, and each segment of the image pull task data after segmentation is processed in parallel through different second cinder-volume nodes to write the image file from the object storage to the block storage.

[0012] The above solution sinks some functions of glance-api to cinder-volume nodes, so that some image management functions originally concentrated in glance-api are dispersed to cinder-volume nodes. Instead of being transferred through glance-api, they are directly downloaded using the storage network of cinder-volume nodes. This not only reduces the burden of glance-api and improves its ability to focus on other core image management functions, but also enables cinder-volume nodes to participate in image download operations more directly, taking advantage of their close connection with the storage network, optimizing the entire image download process, and improving the overall efficiency and scalability of the system.

[0013] In addition, the cinder-volume node of the above solution adopts a segmented concurrent downloading method from the object storage, which makes full use of the feature that the cinder-volume node can be horizontally expanded. For large images, each segment can be downloaded independently on different cinder-volume nodes through segment processing, and multiple nodes work in parallel, which greatly improves the download speed. In a large concurrent scenario, that is, when there are multiple image download requests at the same time, this segmented concurrent mechanism can flexibly allocate tasks according to the node scale to avoid a single node becoming a bottleneck. Since the above solution adopts segmented concurrent downloading, multiple cinder-volume nodes simultaneously read image data of different segments from the object storage and write them to the block storage, which greatly reduces the overall download time compared with the traditional sequential download method. At the same time, when uploading the image to the object storage, a similar segmented processing method is also adopted to improve the upload efficiency through multi-node parallel processing. Whether uploading the image to the object storage or downloading from the object storage to the block storage, the time of the entire process has been significantly shortened, which improves the response speed of cloud host image-related operations, improves the user experience, and makes the entire cloud service more efficient and agile.

[0014] In an optional implementation, segmenting the image file corresponding to the image creation request, and performing parallel image upload processing on each segment of the image file data after the segmentation through different first cinder-volume nodes to upload the image file from the block storage to the object storage includes:

[0015] Based on the scale of the first cinder-volume node and the size of the image file, segment the image file corresponding to the image creation request, and obtain data of each segment of the image file after the segmentation process;

[0016] Allocating each segmented image file data to different first cinder-volume nodes, and creating a snapshot of the system disk corresponding to the image creation request through each of the first cinder-volume nodes;

[0017] After the snapshot is created, a temporary disk is cloned based on the created snapshot, and the temporary disk is copied from the volumes pool to the image pool;

[0018] Object cleaning is performed in the image pool, and each segment of image file data is read from the image pool, and each segment of image file data is written to the object storage.

[0019] In an optional embodiment, the method further includes:

[0020] After the parallel image upload process is completed, the qlance-api interface is called through the target first cinder-volume node to update the image status and image storage location information; the target first cinder-volume node is the first cinder-volume node that finally completes the parallel image upload process.

[0021] In an optional implementation manner, the obtaining the current image state and current image storage location information corresponding to the request to create a system disk includes:

[0022] Parsing the request to create a system disk, and obtaining system disk information corresponding to the request to create a system disk; the system disk information includes an image ID, an image storage location, and a system disk size;

[0023] Based on the image ID, the current image state and current image storage location information corresponding to the create system disk request are obtained by calling the image service API interface.

[0024] In an optional implementation, the determining whether to perform image pull processing according to the current image state and the current image storage location information includes:

[0025] If the current image state is available, and the current image storage location information points to the target ceph cluster, it is determined that the image pull process is not performed;

[0026] If the current image state is unavailable and the current image storage location information does not point to the target ceph cluster, determine whether there is a download and pull task for the create system disk request in the current storage backend;

[0027] If there is a download pull task, the current system disk state is set to queued; if there is no download pull task, it is determined to perform image pull processing.

[0028] In an optional embodiment, the method further includes:

[0029] If it is determined not to perform the image pull process, a clone image process is performed on the image file in the target ceph cluster through a single second cinder-volume node to create a new system disk.

[0030] In an optional implementation, segmenting the image pull task according to the size of the image file, and performing parallel image download processing on each segment of the image pull task data after the segmentation through different second cinder-volume nodes to write the image file from the object storage to the block storage includes:

[0031] Based on the scale of the second cinder-volume node and the size of the image file, the image pull task is segmented and the image pull task data of each segment after the segmentation is obtained;

[0032] Allocate the image pull task data of each segment to different second cinder-volume nodes, read the image file data of the corresponding segment from the object storage through the different second cinder-volume nodes, and write the image file data to the block storage;

[0033] After the parallel image download process is completed, the system disk to be created is checked through the target second cinder-volume node; the target second cinder-volume node is the second cinder-volume node that last completes the parallel image download process;

[0034] If there is a waiting system disk, the downloaded image file data will be used to clone the system disk;

[0035] If there is no waiting system disk, it is determined that the entire system disk creation process has been completed.

[0036] In a second aspect, the present invention provides a fast transmission device for a cloud host image with multiple storage backends, the device comprising:

[0037] A mirror creation request receiving module, used to receive a mirror creation request sent by a user;

[0038] An image upload module, used for segmenting the image file corresponding to the image creation request, and performing parallel image upload processing on each segment of the image file data after the segmentation through different first cinder-volume nodes, so as to upload the image file from the block storage to the object storage;

[0039] A system disk creation request receiving module is used to receive a system disk creation request sent by a user, and obtain the current image state and current image storage location information corresponding to the system disk creation request;

[0040] An image pull determination module, used to determine whether to perform image pull processing according to the current image state and the current image storage location information;

[0041] The image download module is used to, if it is determined to perform image pull processing, segment the image pull task according to the size of the image file, and perform parallel image download processing on each segment of the image pull task data after segmentation through different second cinder-volume nodes, so as to write the image file from the object storage to the block storage.

[0042] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to execute a method for quickly transmitting a cloud host image with multiple storage backends according to the first aspect or any corresponding embodiment thereof.

[0043] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute a method for quickly transmitting a cloud host image with multiple storage backends according to the first aspect or any corresponding embodiment thereof.

[0044] In a fifth aspect, the present invention provides a computer program product, comprising computer instructions, which are used to enable a computer to execute a method for quickly transmitting a cloud host image with multiple storage backends according to the first aspect or any corresponding embodiment thereof.

[0045] The technical solution provided by the present invention may include the following beneficial effects:

[0046] The present invention sinks part of the functions of glance-api to the cinder-volume node, so that part of the image management functions originally concentrated in the glance-api are dispersed to the cinder-volume node, and no longer transits through the glance-api, but directly uses the storage network of the cinder-volume node for downloading, which not only reduces the burden of glance-api and improves its ability to focus on other core image management functions, but also enables the cinder-volume node to participate in the image download operation more directly, and uses its advantage of close connection with the storage network to optimize the entire image download process and improve the overall efficiency and scalability of the system.

[0047] In addition, the cinder-volume node of the present invention adopts a segmented concurrent mode to download from the object storage, making full use of the characteristic that the cinder-volume node can be horizontally expanded. For large images, each segment can be downloaded independently on different cinder-volume nodes through segmented processing, and multiple nodes work in parallel, which greatly improves the download speed. In a large concurrent scenario, that is, when there are multiple image download requests at the same time, this segmented concurrent mechanism can flexibly allocate tasks according to the node scale to avoid a single node from becoming a bottleneck. Since the present invention adopts segmented concurrent downloading, multiple cinder-volume nodes simultaneously read the image data of different segments from the object storage and write them into the block storage, which greatly reduces the overall download time compared with the traditional sequential download method. At the same time, when the image is uploaded to the object storage, a similar segmented processing method is also adopted to improve the upload efficiency through multi-node parallel processing. Whether the image is uploaded to the object storage or downloaded from the object storage to the block storage, the time of the whole process has been significantly shortened, which improves the response speed of the cloud host image-related operations, improves the user experience, and makes the entire cloud service more efficient and agile. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0049] Figure 1 It is a flowchart of a method for quickly transmitting a cloud host image with multiple storage backends according to an embodiment of the present invention;

[0050] Figure 2 It is a flowchart of another method for quickly transmitting a cloud host image with multiple storage backends according to an embodiment of the present invention;

[0051] Figure 3 is a schematic diagram of image uploading according to an embodiment of the present invention to create an image request;

[0052] Figure 4 is a schematic diagram of the range division of data processed by the first cinder-volume node according to an embodiment of the present invention;

[0053] Figure 5 is a schematic diagram of image downloading for creating a system disk request according to an embodiment of the present invention;

[0054] Figure 6 is a schematic diagram of the range division of data processed by the second cinder-volume node according to an embodiment of the present invention;

[0055] Figure 7 is a flowchart of another method for quickly transmitting a cloud host image with multiple storage backends according to an embodiment of the present invention;

[0056] Figure 8 It is a structural block diagram of a fast transmission device for cloud host images with multiple storage backends according to an embodiment of the present invention;

[0057] Fig. 9 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0059] It should be noted that with the rapid development of cloud computing, the demand for storage is growing, especially for the storage and management of virtual machine images. These image files are usually large in size and require efficient storage and fast access. In a cloud computing environment, it is usually necessary to integrate multiple storage backends, such as object storage and block storage, to meet different performance and cost requirements. Object storage is suitable for the storage of large-scale data, while block storage provides high-performance data access. Traditional image management methods face performance bottlenecks and efficiency issues when processing large-capacity data and high-concurrency requests, especially during image upload and download, which consumes a lot of management network bandwidth.

[0060] In a cloud environment, users need to quickly deploy new virtual machine instances, which requires the cloud platform to quickly pull image files from object storage and create new system disks on block storage. Cloud service providers may need to migrate and manage images between different data centers or availability zones, which requires that image data be efficiently transferred between different storage backends. In big data analysis and processing scenarios, large amounts of data may need to be processed and stored, which may exist in the form of images and need to be quickly uploaded and downloaded. In order to improve the availability of cloud services and achieve disaster recovery, image copies need to be stored in different geographical locations, and images need to be able to be quickly synchronized between different storage systems and data centers.

[0061] The present invention improves the storage efficiency and performance of the cloud platform, reduces costs, and enhances the reliability and flexibility of cloud services by optimizing the upload and download processes of the image, and is applicable to the above-mentioned various cloud computing scenarios. When an enterprise or user needs to quickly create multiple cloud host instances, the present invention can quickly pull images from the object storage to the ceph block storage to create a cloud host system disk, and use the segmented concurrent download method of the cinder-volume node to greatly shorten the creation time of the cloud host. At the same time, since the download of the image through the glance-api transit to occupy the management network bandwidth is avoided, the smooth flow of the management network is ensured, so that the system can stably perform other management operations, such as monitoring the operating status of the cloud host, dynamically adjusting resource configuration, etc. In the cloud service architecture where the enterprise has multiple available zones, the present invention realizes the ability of the image to cross the available zones. For example, when a data center in a certain area needs to quickly deploy a cloud host with the same configuration as other areas, the present invention can be used to quickly transfer the existing image to the data center in the target area, so as to realize rapid sharing and flexible allocation of resources, and improve the overall operational efficiency and resource utilization of the enterprise. For multiple storage backends that use object storage and ceph block storage at the same time, the present invention provides an efficient image management method, which can store some commonly used images in object storage to save costs, and these images need to be quickly loaded into ceph block storage as system disks when creating a cloud host. Through optimized upload and download processes, the present invention can quickly and accurately complete the transmission and management of images in this hybrid storage environment, ensure the collaborative work between different storage backends, and give full play to the respective advantages of object storage and ceph block storage, such as the large-capacity storage advantage of object storage and the high-performance read and write advantage of ceph block storage.

[0062] According to an embodiment of the present invention, an embodiment of a method for quickly transmitting a cloud host image with multiple storage backends is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0063] In this embodiment, a method for quickly transmitting a cloud host image with multiple storage backends is provided. Figure 1 is a flow chart of a method for fast transmission of a cloud host image with multiple storage backends according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0064] Step S101: receiving a request for creating an image sent by a user.

[0065] Furthermore, the user request will first reach the upper-layer component of the cloud service platform, which is responsible for parsing and preliminarily processing the user request, and then forwarding it to the component responsible for specific image management operations. In this scenario, the request will eventually be sent to the cinder-api interface. As an important interface for interacting with user requests, the cinder-api interface receives requests from the upper layer and starts the actual processing of the image file, providing the necessary trigger conditions for subsequent steps.

[0066] Step S102, segmenting the image file corresponding to the image creation request, and performing parallel image upload processing on each segment of the image file data after segmentation through different first cinder-volume nodes, so as to upload the image file from the block storage to the object storage.

[0067] Furthermore, this embodiment processes the image file in segments to better utilize system resources and realize parallel upload. Since the image file may be large, if it is uploaded as a whole, the processing time of a single node is long and may cause uneven resource usage. This embodiment can decompose a large file into multiple smaller parts by segmentation, and each part can be processed independently, thereby improving the overall upload speed. This embodiment performs segmentation according to the scale of the first cinder-volume node, which can ensure that the size of each segment is appropriate and make full use of the processing power of each node. The cinder-api interface performs segmentation processing according to the image size, and then calls other first cinder-volume nodes through rpc to process the segmented tasks for parallel processing. Each segment is assigned to a different first cinder-volume node, and these nodes work simultaneously to upload their respective data segments to the object storage. This parallel upload can significantly improve the upload speed and reduce the overall upload time. Among them, the cinder-volume node is a server that manages block storage. Block storage provides high-performance random data access functions, and object storage provides large-scale unstructured data storage.

[0068] Step S103: receiving a system disk creation request sent by a user, and obtaining current image state and current image storage location information corresponding to the system disk creation request.

[0069] Furthermore, when the user needs to create a new cloud host system disk, a request to create a system disk will be issued. This request will also be processed by the relevant components of the cloud service platform and finally reach the module responsible for processing the creation of the system disk. Obtaining the current image status and storage location information is crucial for subsequent judgment and operation. The image status can include multiple states such as available, unavailable, being created, and being updated. This embodiment obtains this information by calling the glance-api interface. The second cinder-volume node uses the functions provided by the glance-api interface to query the detailed information of the image according to the relevant parameters in the request to create a system disk (such as image ID, etc.), which provides the necessary data support for subsequent accurate judgment and efficient processing.

[0070] Step S104: determine whether to perform image pull processing according to the current image state and the current image storage location information.

[0071] Furthermore, based on the information obtained in step S103, the second cinder-volume node will determine whether image pull processing is required. If the image already exists in the target ceph cluster (block storage) and is in an available state, it is not necessary to pull it. If the image is not in the target ceph cluster or is not in an available state, it is necessary to pull the image data from the object storage.

[0072] Step S105, if it is determined to perform image pull processing, the image pull task is segmented according to the size of the image file, and each segment of the image pull task data after segmentation is processed in parallel through different second cinder-volume nodes to write the image file from the object storage to the block storage.

[0073] Furthermore, if it is necessary to pull an image, the glance-api interface is called to process the image pulling task in segments, similar to the upload process. Each segment task is assigned to a different second cinder-volume node, and different second cinder-volume nodes perform parallel image download processing on each segment of the image pulling task data after segment processing. Each node is responsible for reading the corresponding segmented image file data from the object storage and writing it to the block storage. In this process, data is transferred from the object storage to the block storage. The high-performance read and write characteristics of the block storage enable the written data to be quickly used by the cloud host. For example, after the system disk is created, the cloud host can immediately start and run based on the system disk of this block storage, providing a fast service response. At the same time, this parallel download method also improves the utilization rate of the object storage, avoids the performance bottleneck caused by the download of a single large file to the object storage, and enables the entire storage system to work together more efficiently.

[0074] In this embodiment, another method for quickly transmitting cloud host images with multiple storage backends is provided. Figure 2 is a flowchart of another method for fast transmission of cloud host images with multiple storage backends according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0075] Step S201: receiving a request for creating an image sent by a user.

[0076] For further information, see Figure 3 The image upload diagram of the image creation request is shown. First, the user's image creation request is finally sent to the cinder-api interface through the upper-layer components. The request first reaches the upper-layer components of the cloud service platform, which are responsible for handling the initial verification of user requests, permission checks, and request routing. After being processed by the upper-layer components, the request is forwarded to the cinder-api interface. As an important interface for block storage-related operations, the cinder-api interface will be responsible for coordinating the subsequent image creation process. It is a key link directly related to the user request in the entire image upload process.

[0077] Step S202, segmenting the image file corresponding to the image creation request, and performing parallel image upload processing on each segment of the image file data after segmentation through different first cinder-volume nodes, so as to upload the image file from the block storage to the object storage.

[0078] In an optional implementation, the step S202 includes:

[0079] Based on the scale of the first cinder-volume node and the size of the image file, segment the image file corresponding to the image creation request, and obtain data of each segment of the image file after segmentation;

[0080] Allocate each segmented image file data to different first cinder-volume nodes, and create a snapshot of the system disk corresponding to the image creation request through each first cinder-volume node;

[0081] After the snapshot is created, a temporary disk is cloned based on the created snapshot, and the temporary disk is copied from the volumes pool to the image pool;

[0082] Objects are cleaned up in the image pool, and each segment of image file data is read from the image pool, and each segment of image file data is written to the object storage.

[0083] Furthermore, this embodiment processes the image file in segments according to the scale factors such as the number and performance of the first cinder-volume nodes and the actual size of the image file, and at the same time, obtains each segment of the image file data after segment processing to prepare for subsequent allocation to the node processing. The image file data of each segment is allocated to different first cinder-volume nodes. After receiving the allocated segment data, each node first creates a snapshot of the system disk corresponding to the image creation request. The snapshot operation can quickly record the state of the system disk at the current moment, which serves as a reference point for subsequent data processing to ensure data consistency and integrity. After the snapshot is established, a temporary disk is cloned based on the snapshot. The cloning operation will create a temporary copy of the same snapshot data as the original system disk, and then copy the temporary disk from the volume volumes pool to the image image pool. The volume volumes pool is usually used to store data volumes related to the cloud host system disk, while the image image pool is a storage area for image management. Objects are cleaned up in the image image pool. The cleanup operation may include deleting temporary files, invalid data, etc. to optimize the storage structure of the image data and improve the data quality. Then, each segment of the image file data is read from the image image pool and written to the object storage. Object storage is suitable for storing large amounts of unstructured data, such as image files. Storing image data in object storage can facilitate the subsequent sharing and use of images between different regions and nodes. Through the above steps, different first cinder-volume nodes simultaneously process the segmented image file data they are responsible for, realizing parallel image upload. Each node independently performs the process of acquiring data from the system disk (through operations such as snapshots and cloning), data conversion (copying to the image pool and cleaning), and writing data to the object storage. Multiple nodes working in parallel greatly shorten the upload time of the entire image file and improve the overall performance and resource utilization of the system.

[0084] Further, such as Figure 3 As shown, this embodiment divides the image file into segments, and then dispatches the operation of each segment of data to a different first cinder-volume node for processing. When the last segment is processed, the first cinder-volume node that has completed the processing last calls the glance-api interface to update the image status and the image storage location information. Figure 4The diagram shows the range division of data processed by the first cinder-volume node. When a user creates a private image task using an existing cloud host system disk, it is directly distributed to multiple first cinder-volume node tasks. Assuming n, the length of data processed by each first cinder-volume node becomes smaller, and the processing time is greatly shortened. The image data previously processed by one cinder-volume node is changed to be processed concurrently by multiple first cinder-volume nodes, which greatly improves the speed of uploading the image to the object storage. With the cluster module specifications, it supports horizontal increase of the number of first cinder-volume nodes to improve the concurrent processing capability. Each cinder-volume node is responsible for data processing in a specific range, reads the corresponding segmented data from the block storage, and prepares to upload it to the object storage. The specific range is expressed as: cinder-volume:0-(segment-1); cinder-volume:segment-(2*segment-1); cinder-volume:2*segment-(3*segment-1), until cinder-volume:(n-1)*segment-(image_size-1). Where n is the node number, segment is the segment size, and image_size is the image size. The overall process revolves around data processing from block storage to object storage, which is executed in parallel by multiple first cinder-volume nodes.

[0085] Step S203, after the parallel image upload process is completed, the qlance-api interface is called through the target first cinder-volume node to update the image state and the image storage location information; the target first cinder-volume node is the first cinder-volume node that finally completes the parallel image upload process.

[0086] Furthermore, when all segmented image file data has been uploaded to the object storage, it is necessary to determine that the entire image upload task has been completed. In the parallel upload process, each first cinder-volume node is responsible for processing a segment, and the node that finally completes the segment upload is regarded as the target first cinder-volume node, which can accurately determine the completion of the entire image upload task. The target first cinder-volume node calls the glance-api interface to update the image status and image storage location information. The image status can include status identifiers such as "upload completed", "available", and "unavailable". Updating the status information can allow other system components and users to understand the current status of the image. At the same time, the image storage location information (i.e., the specific location in the object storage) is accurately recorded so that the image can be quickly located and obtained when it is needed later. For example, when a user requests to create a cloud host system disk based on this image, the system can quickly extract the image data from the object storage according to the storage location information, thereby improving the efficiency of system disk creation.

[0087] Step S204: receiving a system disk creation request sent by a user, and obtaining current image state and current image storage location information corresponding to the system disk creation request.

[0088] In an optional implementation, the step S204 includes:

[0089] Parse the request to create a system disk and obtain the system disk information corresponding to the request to create a system disk; the system disk information includes the image ID, the image storage location and the system disk size;

[0090] Based on the image ID, the current image state and current image storage location information corresponding to the create system disk request are obtained by calling the image service API interface.

[0091] Further, after receiving the request to create a system disk sent by the user, this embodiment first parses the request. The request to create a system disk contains various information related to the creation of the system disk, such as the image information used, the system disk size requirement, the storage location, etc. By parsing the request, the key system disk information is extracted, including the image ID, the image storage location, and the system disk size. The image ID is an identifier that uniquely identifies the image, which can accurately locate and identify the required image resources. The image storage location information can help the system determine where to obtain the image data, and the system disk size determines the capacity of the created system disk. This embodiment uses the extracted image ID to obtain the current image status and current image storage location information corresponding to the request to create a system disk by calling the image service API interface (i.e., the glance-api interface). The glance-api interface, as a service interface responsible for image file management, provides the function of querying various attribute information of the image. According to the image ID, the current status and storage location information of the image can be found and returned in the image management system. The acquired image status and storage location information will be used for subsequent decisions such as whether image pull processing is required and how to perform the pull operation.

[0092] Step S205: Determine whether to perform image pull processing according to the current image state and the current image storage location information.

[0093] In an optional implementation, the step S205 includes:

[0094] If the current image state is available and the current image storage location information points to the target ceph cluster, it is determined that the image pull process is not performed;

[0095] If the current image state is unavailable and the current image storage location information does not point to the target ceph cluster, determine whether there is a download and pull task for the create system disk request in the current storage backend;

[0096] If there is a download pull task, the current system disk state is set to queued; if there is no download pull task, it is determined to perform image pull processing.

[0097] Further, when the current image state is obtained to be available, and the current image storage location information points to the target ceph cluster, it means that there is already an available image in the target ceph cluster, and its location is clear. In this case, no additional image pull processing is required, because the required image is already in the right location and can be used directly. This judgment mechanism helps to optimize the overall performance and resource utilization efficiency of the system, avoids repeated image pulls when it is not necessary, reduces the occupation of network bandwidth, the read and write operations of object storage and ceph block storage, and the processing burden of cinder-volume nodes. At the same time, the step of pulling the image can be skipped directly, which also speeds up the creation of the system disk. When the current image state is unavailable, or the current image storage location information does not point to the target ceph cluster, it means that it is necessary to further check whether the image pull processing is required. The unavailable state may mean that the image is being created, updated, or there are other problems that make it temporarily unavailable, and the storage location is not in the target ceph cluster, which means that the image data needs to be obtained from other locations. In this case, it is further determined whether there is a download pull task in the current storage backend for the request to create a system disk. If there is a download pull task, it means that there are other identical or related tasks in progress. In order to avoid duplicate pulls and resource conflicts, the current system disk status is set to queued. This ensures that the image pull operation is carried out in order in a concurrent situation, avoiding network congestion and storage resource competition caused by multiple tasks pulling the same image at the same time. If there is no download pull task, it is determined to be image pull processing, and the system will start the subsequent image pull process, obtain the image data from the appropriate location and create a system disk.

[0098] Step S206, if it is determined to perform image pull processing, the image pull task is segmented according to the image file size, and each segment of the image pull task data after segmentation is processed in parallel through different second cinder-volume nodes to write the image file from the object storage to the block storage.

[0099] In an optional implementation, step S206 includes:

[0100] Based on the scale of the second cinder-volume node and the size of the image file, the image pull task is segmented and the image pull task data of each segment after segmentation is obtained;

[0101] Allocate the image pull task data of each segment to a different second cinder-volume node, read the image file data of the corresponding segment from the object storage through the different second cinder-volume node, and write the image file data to the block storage;

[0102] After the parallel image download process is completed, the system disk to be created is checked through the target second cinder-volume node; the target second cinder-volume node is the second cinder-volume node that last completes the parallel image download process;

[0103] If there is a waiting system disk, the downloaded image file data will be used to clone the system disk;

[0104] If there is no waiting system disk, it is determined that the entire system disk creation process has been completed.

[0105] Further, similar to uploading, this embodiment performs segmented processing on the image pull task according to the scale of the second cinder-volume node (such as the number of nodes, performance, etc.) and the image file size. Parameters such as the size of each segment, the offset start bit, etc. are calculated to ensure that the segmentation is reasonable and the parallel processing capability of the node can be fully utilized. This embodiment distributes the image pull task data of each segment to different second cinder-volume nodes. After each node receives the assigned task, it starts to read the image file data of the corresponding segment from the object storage. By reading the data of different segments from the object storage at the same time by multiple nodes, parallel image download is realized. It utilizes the distributed characteristics and network bandwidth of the object storage to speed up the acquisition of image data. After the parallel image download processing is completed, this embodiment checks the system disk waiting to be created by the target second cinder-volume node that finally completes the segment download for which it is responsible. The target second cinder-volume node can accurately judge the completion of the entire image download task. At this time, the data of the entire image has been successfully downloaded from the object storage to the node local or temporary cache. Then, the target node checks whether there are other system disks waiting to be created using the image data. If there are waiting system disks, the downloaded image file data will be used to clone the system disk. If there are no waiting system disks, the entire system disk creation process is considered to be completed, and the system can release related resources, such as cleaning up temporary data, closing unnecessary network connections, etc., and feedback the successful creation of the system disk to the user or other related components, marking the end of this system disk creation task.

[0106] For further information, see Figure 5The image download schematic diagram of the creation system disk request is shown. When the image is downloaded, the second cinder-volume node receives the creation system disk request. The second cinder-volume node calls the glance-api interface to obtain the current status and storage location information of the image. The second cinder-volume node determines whether the image already exists in the target ceph cluster according to the storage backend currently managed by itself. If the current target ceph cluster already exists, the second cinder-volume node directly clones and creates the system disk, and the task is completed. If the current target ceph cluster does not exist, check whether the image has a download and pull task in the current storage backend. If there is a download task, the current system disk status is set to queue; if not, create a new image pull task. Then, the task is segmented according to the size of the image and handed over to different second cinder-volume nodes for processing. The last second cinder-volume node that completes the download task checks whether there is a queued system disk. If so, clone it in turn. If not, the entire image download task is completed.

[0107] See also Figure 6The diagram shows the range division of data processed by the second cinder-volume node. The user creates a cloud host system disk in the ceph cluster using an image stored in an existing object storage. The second cinder-volume node reads the image data from the object storage and stores it in the images pool of the ceph cluster. This task divides the image file into segments, each of which is processed by a second cinder-volume node, so the download time of an image is greatly shortened. The image data previously processed by a cinder-volume node is changed to be processed concurrently by multiple second cinder-volume nodes, which greatly improves the speed of uploading images to the object storage. With the cluster module specifications, it supports horizontal increase of the number of second cinder-volume nodes to improve concurrent processing capabilities. After the image file is stored in the images pool of the block storage, a snapshot of the image will be taken and write-protected. If there is a request to create a system disk for the storage backend, the second cinder-volume node directly clones the snapshot of the image to quickly create a new system disk. Each second cinder-volume node is responsible for processing data in a specific range, which is represented by the interval from the start position to the end position, such as cinder-volume:0-(segment-1), cinder-volume:segment-(2*segment-1), etc., all the way to cinder-volume:(n-1)*segment-(image_size-1), where n represents the node number, segment represents the segment size, and image_size represents the image size. The overall process reflects that multiple second cinder-volume nodes process data in parallel. The data from a specific starting point to the corresponding interval is processed by a specific second cinder-volume node, and the data processed is from the images pool. Figure 6 In the example, Bucket is an object storage bucket, which is a storage unit in object storage, and the images pool is a storage resource pool used to store volume data, such as block storage.

[0108] Step S207: If it is determined that the image pull process is not to be performed, a clone image process is performed on the image file in the target ceph cluster through a single second cinder-volume node to create a new system disk.

[0109] Furthermore, when it is determined that no image pull processing is performed, it means that an available image already exists in the target ceph cluster and the location is correct. At this time, the image file in the target ceph cluster is cloned through a single second cinder-volume node to create a new system disk. The cloning operation can quickly copy the image file and create a copy that is identical to the original image as a new system disk. This direct cloning method avoids unnecessary network transmission and coordination overhead between nodes, and effectively utilizes the existing image resources in the target ceph cluster. At the same time, it reduces the processing time and resource consumption of the system because there is no need to start complex image pull processes, such as segmented processing, parallel downloading of multiple nodes, and other operations. This helps to improve the efficiency of the entire cloud service system in processing system disk creation requests, especially when the image already exists and is available, it can quickly respond to user needs, improve user experience, and make the creation of cloud hosts faster and more convenient.

[0110] For further information, see Figure 7 A flowchart of another method for quickly transmitting a cloud host image with multiple storage backends is shown, comprising the following steps:

[0111] 1. The user first sends a request to create a private image for the existing cloud host system disk, and the request is sent to the cinder-api interface. That is, the user initiates a request to create a private image for the existing cloud host system disk on the cloud service platform. This request is processed by the upper-layer component and sent to the cinder-api interface, which marks the beginning of the image creation process. The user's needs are passed to the key interface responsible for block storage-related operations.

[0112] 2. The cinder-api interface finds the corresponding cinder-volume node for processing based on the input system disk identifier volume-id. That is, the cinder-api interface finds the corresponding node among the numerous cinder-volume nodes to process the task of creating a private image based on the input system disk identifier volume-id interface. The system disk identifier volume-id is the unique identifier of the system disk, which ensures accurate positioning of the node responsible for processing.

[0113] 3. The cinder-volume node first takes a snapshot of the system disk, then clones a temporary disk, copies the temporary disk from the volumes pool to the image pool, and starts to clean up the object in the image pool. That is, the cinder-volume node first takes a snapshot of the system disk. The snapshot is a record of the state of the system disk at a certain moment, providing a data backup for subsequent operations. Then clone a temporary disk, copy it from the volumes pool to the image pool, and clean up the object in the image pool. This step realizes the conversion from system disk data to an intermediate state suitable for image processing, preparing for subsequent writing to object storage. The volumes pool is a storage resource pool used to store virtual machine volumes (disks), and the image pool refers to a storage resource pool used to store virtual machine images. The volumes pool and the image pool are located in the block storage system, providing block storage, allowing virtual machines to directly access storage blocks.

[0114] 4. After the cinder-volume node reads the data from the mirror pool, it writes it to the object storage bucket. That is, the cinder-volume node reads the data from the mirror pool and then writes it to the object storage bucket. Object storage is suitable for storing a large amount of unstructured data. Storing the mirror data here facilitates subsequent sharing and distribution.

[0115] 5. When the image data is written (that is, after step 4), the cinder-volume node calls the glance-api interface to complete the addition and update of the image location backend. That is, when all the image data is written to the object storage bucket, the cinder-volume node calls the glance-api interface to complete the addition and update of the image location backend, ensuring that the storage location information of the image is accurately recorded, which is convenient for subsequent search and use.

[0116] 6. User request Figure 7 The user requests to use the above image to create a new system disk in availability zone 3. This means that the user can use the existing image to quickly deploy a new cloud host system disk in other zones.

[0117] 7. When other available zones create cloud host system disks based on this image, the cinder-api interface performs segment processing according to the image size. In this embodiment, the cinder-api interface is configured to configure how many segments to divide according to the cinder-volume node scale. For example, it is divided into 5 segments for data processing. First, the size of each segment if it is divided into 5 segments is calculated: chunk = int (math.ceil (float (totalsize) / segnum)), and then the length of each segment and the offset start bit are obtained, and finally the list information of the entire segment is obtained, and then other cinder-volume nodes are called through rpc for segment processing. That is, when other available zones need to create cloud host system disks based on this image, in order to improve efficiency and adapt to different network environments, the cinder-api interface performs segment processing according to the image size and cinder-volume node scale. This embodiment calculates the size of each segment when it is divided into a specific number of segments (for example, 5 segments), and obtains the length of each segment and the offset start bit, thereby obtaining the list information of the entire segment. Then, other cinder-volume nodes are called through rpc (remote procedure call) for segment processing, making full use of the parallel processing capabilities of multiple nodes.

[0118] 8. When each cinder-volume node processes a segmentation task, it reads the corresponding segmentation content from the object storage, realizing parallel reading operations. Multiple nodes simultaneously obtain different parts of the mirror data from the object storage, which improves the speed of data acquisition.

[0119] 9. The cinder-volume node writes the segmented content to the block storage, that is, converts the image data from the object storage format to a block storage format suitable for the cloud host system disk, in preparation for creating the system disk.

[0120] 10. After the last segment task is completed, the cinder-volume node that has completed the task will update the disk status information and clone the queued disks. That is, after the last segment task is completed, the cinder-volume node that has completed the task will be responsible for updating the disk status information. At the same time, if there is a queued disk that needs to create a system disk, it will be cloned to quickly create a system disk using the downloaded image data, thereby improving the concurrent processing capability of the system.

[0121] In summary, the above solution sinks some functions of glance-api to cinder-volume nodes, so that some image management functions originally concentrated in glance-api are dispersed to cinder-volume nodes. Instead of being transferred through glance-api, they are directly downloaded using the storage network of cinder-volume nodes. This not only reduces the burden of glance-api and improves its ability to focus on other core image management functions, but also enables cinder-volume nodes to participate in image download operations more directly, taking advantage of their close connection with the storage network, optimizing the entire image download process, and improving the overall efficiency and scalability of the system.

[0122] In addition, the cinder-volume node of the above solution adopts a segmented concurrent downloading method from the object storage, which makes full use of the feature that the cinder-volume node can be horizontally expanded. For large images, each segment can be downloaded independently on different cinder-volume nodes through segment processing, and multiple nodes work in parallel, which greatly improves the download speed. In a large concurrent scenario, that is, when there are multiple image download requests at the same time, this segmented concurrent mechanism can flexibly allocate tasks according to the node scale to avoid a single node becoming a bottleneck. Since the above solution adopts segmented concurrent downloading, multiple cinder-volume nodes simultaneously read image data of different segments from the object storage and write them to the block storage, which greatly reduces the overall download time compared with the traditional sequential download method. At the same time, when uploading the image to the object storage, a similar segmented processing method is also adopted to improve the upload efficiency through multi-node parallel processing. Whether uploading the image to the object storage or downloading from the object storage to the block storage, the time of the entire process has been significantly shortened, which improves the response speed of cloud host image-related operations, improves the user experience, and makes the entire cloud service more efficient and agile.

[0123] In this embodiment, a fast transmission device for cloud host images with multiple storage backends is also provided, which is used to implement the above embodiments and preferred implementations, and will not be repeated for what has been described. As used below, the term "module" can implement a combination of software and / or hardware for a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0124] This embodiment provides a fast transmission device for cloud host images with multiple storage backends, such as Figure 8 As shown, including:

[0125] The image creation request receiving module 801 is used to receive an image creation request sent by a user;

[0126] The image upload module 802 is used to segment the image file corresponding to the image creation request, and perform parallel image upload processing on each segment of the image file data after segmentation through different first cinder-volume nodes, so as to upload the image file from the block storage to the object storage;

[0127] The system disk creation request receiving module 803 is used to receive a system disk creation request sent by a user, and obtain the current image state and current image storage location information corresponding to the system disk creation request;

[0128] The image pull determination module 804 is used to determine whether to perform image pull processing according to the current image state and the current image storage location information;

[0129] The image download module 805 is used to segment the image pulling task according to the size of the image file if it is determined to perform image pulling processing, and perform parallel image download processing on each segment of the image pulling task data after segmentation through different second cinder-volume nodes to write the image file from the object storage to the block storage.

[0130] In some optional implementations, the image uploading module 802 is further used to:

[0131] Based on the scale of the first cinder-volume node and the size of the image file, segment the image file corresponding to the image creation request, and obtain data of each segment of the image file after segmentation;

[0132] Allocate each segmented image file data to different first cinder-volume nodes, and create a snapshot of the system disk corresponding to the image creation request through each first cinder-volume node;

[0133] After the snapshot is created, a temporary disk is cloned based on the created snapshot, and the temporary disk is copied from the volumes pool to the image pool;

[0134] Objects are cleaned up in the image pool, and each segment of image file data is read from the image pool, and each segment of image file data is written to the object storage.

[0135] In an optional embodiment, the device is also used for:

[0136] After the parallel image upload process is completed, the qlance-api interface is called through the target first cinder-volume node to update the image status and image storage location information; the target first cinder-volume node is the first cinder-volume node that finally completes the parallel image upload process.

[0137] In an optional implementation, the system disk creation request receiving module 803 is further configured to:

[0138] Parse the request to create a system disk and obtain the system disk information corresponding to the request to create a system disk; the system disk information includes the image ID, the image storage location and the system disk size;

[0139] Based on the image ID, the current image state and current image storage location information corresponding to the create system disk request are obtained by calling the image service API interface.

[0140] In an optional implementation, the image pull determination module 804 is further configured to:

[0141] If the current image state is available and the current image storage location information points to the target ceph cluster, it is determined that the image pull process is not performed;

[0142] If the current image state is unavailable and the current image storage location information does not point to the target ceph cluster, determine whether there is a download and pull task for the create system disk request in the current storage backend;

[0143] If there is a download pull task, the current system disk state is set to queued; if there is no download pull task, it is determined to perform image pull processing.

[0144] In an optional embodiment, the device is also used for:

[0145] If it is determined not to perform the image pull process, the image file in the target ceph cluster is cloned through a single second cinder-volume node to create a new system disk.

[0146] In an optional implementation, the image download module 805 is further used to:

[0147] Based on the scale of the second cinder-volume node and the size of the image file, the image pull task is segmented and the image pull task data of each segment after segmentation is obtained;

[0148] Allocate the image pull task data of each segment to a different second cinder-volume node, read the image file data of the corresponding segment from the object storage through the different second cinder-volume node, and write the image file data to the block storage;

[0149] After the parallel image download process is completed, the system disk to be created is checked through the target second cinder-volume node; the target second cinder-volume node is the second cinder-volume node that last completes the parallel image download process;

[0150] If there is a waiting system disk, the downloaded image file data will be used to clone the system disk;

[0151] If there is no waiting system disk, it is determined that the entire system disk creation process has been completed.

[0152] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0153] The embodiment of the present invention also provides a computer device, see Fig. 9 , Fig. 9 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Fig. 9 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig. 9 A processor 10 is taken as an example.

[0154] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0155] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0156] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0157] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0158] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0159] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0160] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0161] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the defined scope.

Claims

1. A method for fast transmission of cloud host images with multiple storage backends, characterized in that: The method comprises: Receive a request from a user to create an image; The image file corresponding to the image creation request is segmented, and each segment of the image file data after the segmentation is processed is processed in parallel through different first cinder-volume nodes, so as to upload the image file from the block storage to the object storage; Receive a system disk creation request sent by a user, and obtain current image state and current image storage location information corresponding to the system disk creation request; Determining whether to perform image pull processing according to the current image state and the current image storage location information; If it is determined to perform image pull processing, the image pull task is segmented according to the image file size, and each segment of the image pull task data after segmentation is processed in parallel through different second cinder-volume nodes to write the image file from the object storage to the block storage.

2. The method according to claim 1, characterized in that The image file corresponding to the image creation request is segmented, and each segment of the image file data after the segmentation is processed is parallelly image uploaded through different first cinder-volume nodes to upload the image file from the block storage to the object storage, including: Based on the scale of the first cinder-volume node and the size of the image file, segment the image file corresponding to the image creation request, and obtain data of each segment of the image file after the segmentation process; Allocating each segmented image file data to different first cinder-volume nodes, and creating a snapshot of the system disk corresponding to the image creation request through each of the first cinder-volume nodes; After the snapshot is created, a temporary disk is cloned based on the created snapshot, and the temporary disk is copied from the volumes pool to the image pool; Object cleaning is performed in the image pool, and each segment of image file data is read from the image pool, and each segment of image file data is written to the object storage.

3. The method according to claim 2, characterized in that The method further comprises: After the parallel image upload process is completed, the qlance-api interface is called through the target first cinder-volume node to update the image status and image storage location information; the target first cinder-volume node is the first cinder-volume node that finally completes the parallel image upload process.

4. The method according to claim 1, characterized in that: The obtaining of the current image state and current image storage location information corresponding to the request to create a system disk includes: Parsing the request to create a system disk, and obtaining system disk information corresponding to the request to create a system disk; the system disk information includes an image ID, an image storage location, and a system disk size; Based on the image ID, the current image state and current image storage location information corresponding to the create system disk request are obtained by calling the image service API interface.

5. The method according to claim 1, characterized in that The determining whether to perform image pull processing according to the current image state and the current image storage location information includes: If the current image state is available, and the current image storage location information points to the target ceph cluster, it is determined that the image pull process is not performed; If the current image state is unavailable and the current image storage location information does not point to the target ceph cluster, determine whether there is a download and pull task for the create system disk request in the current storage backend; If there is a download pull task, the current system disk state is set to queued; if there is no download pull task, it is determined to perform image pull processing.

6. The method according to claim 1, characterized in that The method further comprises: If it is determined not to perform the image pull process, a clone image process is performed on the image file in the target ceph cluster through a single second cinder-volume node to create a new system disk.

7. The method according to any one of claims 1 to 6, characterized in that: The image pulling task is segmented according to the size of the image file, and each segment of the image pulling task data after segmentation is processed in parallel through different second cinder-volume nodes to write the image file from the object storage to the block storage, including: Based on the scale of the second cinder-volume node and the size of the image file, the image pull task is segmented and the image pull task data of each segment after the segmentation is obtained; Allocate the image pull task data of each segment to different second cinder-volume nodes, read the image file data of the corresponding segment from the object storage through the different second cinder-volume nodes, and write the image file data to the block storage; After the parallel image download process is completed, the system disk to be created is checked through the target second cinder-volume node; the target second cinder-volume node is the second cinder-volume node that last completes the parallel image download process; If there is a waiting system disk, the downloaded image file data will be used to clone the system disk; If there is no waiting system disk, it is determined that the entire system disk creation process has been completed.

8. A fast transmission device for cloud host images with multiple storage backends, characterized in that: The device comprises: A mirror creation request receiving module, used to receive a mirror creation request sent by a user; An image upload module, used for segmenting the image file corresponding to the image creation request, and performing parallel image upload processing on each segment of the image file data after the segmentation through different first cinder-volume nodes, so as to upload the image file from the block storage to the object storage; A system disk creation request receiving module is used to receive a system disk creation request sent by a user, and obtain the current image state and current image storage location information corresponding to the system disk creation request; An image pull determination module, used to determine whether to perform image pull processing according to the current image state and the current image storage location information; The image download module is used to, if it is determined to perform image pull processing, segment the image pull task according to the size of the image file, and perform parallel image download processing on each segment of the image pull task data after segmentation through different second cinder-volume nodes, so as to write the image file from the object storage to the block storage.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method for rapidly transmitting a cloud host image with multiple storage backends as described in any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute a method for quickly transmitting a cloud host image with multiple storage backends according to any one of claims 1 to 7.

Images