A method and device for fast transmission of cloud host images of a multi-storage backend

Abstract

The application relates to the technical field of software development, in particular to a kind of quick transmission method and device of cloud host image of multi-storage backend, the method comprises the following steps: when uploading image, the image file corresponding to the creation image request is segmented, and each piece of image file data processed by segmentation is uploaded in parallel by different first cinder-volume node; when downloading image, according to current image state and current image storage location information, judge whether to carry out image pulling processing, if it is judged to carry out image pulling processing, according to the size of image file, the image pulling task is segmented, and each piece of image pulling task data processed by segmentation is downloaded in parallel by different second cinder-volume node. The image transmission speed of the application is fast, the response speed of cloud host image related operation is improved, and the whole cloud service is more efficient and agile.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software development, in particular to a rapid transmission method and device for cloud host image of multi-storage backend. BACKGROUND

[0002] With the acceleration of enterprise digital transformation, cloud computing application scenarios are increasingly complex and diverse. Enterprises expand their business globally and need to deploy cloud computing resources in different geographic locations to provide low-latency and high-availability services. This requires cloud host images to be quickly transmitted and deployed between different regions and different storage backends to ensure business continuity and user experience consistency.

[0003] In traditional cloud computing architecture, cloud host image management faces many problems. Especially in a multi-storage backend environment, image upload and download efficiency becomes a bottleneck. For example, when pulling images from object storage to block storage, the cinder-volume (block storage volume management component) usually downloads images through the glance-api (image service application programming interface). This approach has obvious shortcomings in high concurrency scenarios, as the management network bandwidth is heavily occupied, causing management face data transmission to be blocked.

[0004] In the above scheme, the existing image transmission speed is slow, which cannot meet the needs of rapid elastic scaling and business rapid iteration in the cloud computing environment, resulting in a delay in business response. SUMMARY

[0005] Therefore, the present application provides a rapid transmission method and device for cloud host image of multi-storage backend to solve the problem of slow image transmission speed, which cannot meet the needs of rapid elastic scaling and business rapid iteration in the cloud computing environment, resulting in a delay in business response.

[0006] In a first aspect, the present application provides a rapid transmission method for cloud host image of multi-storage backend, which comprises:

[0007] receiving a user-sent image creation request;

[0008] segmenting the image file corresponding to the image creation request, and performing parallel image upload processing on each segment of the segmented image file data through different first cinder-volume nodes to upload the image file from block storage to object storage;

[0009] receiving a user-sent system disk creation request and obtaining current image state and current image storage location information corresponding to the system disk creation request;

[0010] According to the current image state and the current image storage location information, it is judged whether to perform image pulling processing;

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

[0012] The above scheme sinks part of the functions of the glance-api to the cinder-volume nodes, so that the part of the image management functions originally concentrated in the glance-api are dispersed to the cinder-volume nodes, and no longer transit through the glance-api, but directly use the storage network of the cinder-volume nodes for downloading, which not only relieves the burden of the glance-api and improves its ability to focus on other core image management functions, but also enables the cinder-volume nodes to more directly participate in the image download operation, utilizes the close connection advantage of the cinder-volume nodes with the storage network, optimizes the entire image download process, and improves the overall efficiency and scalability of the system.

[0013] Moreover, the cinder-volume nodes of the above scheme download from the object storage in a segmented and concurrent manner, which fully utilizes the feature that the cinder-volume nodes can be horizontally scaled. For large images, each segment can be independently downloaded on different cinder-volume nodes through segment processing, 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 and concurrent mechanism can flexibly allocate tasks according to the node size to avoid a single node becoming a bottleneck. Since the above scheme adopts segmented and concurrent downloading, multiple cinder-volume nodes simultaneously read different segments of image data from the object storage and write to the block storage, which greatly reduces the overall download time compared to the traditional sequential download method. At the same time, when the image is uploaded to the object storage, a similar segment processing method is also used 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 entire process is significantly shortened, which improves the response speed of the cloud host image related operations, enhances the user experience, and makes the entire cloud service more efficient and agile.

[0014] In an alternative embodiment, the image file corresponding to the create image request is segmented, and each segment of the image file data after segmentation is uploaded in parallel to the object storage through different first cinder-volume nodes to upload the image file from the block storage to the object storage, comprising:

[0015] The image file corresponding to the create image request is segmented based on the size of the first cinder-volume node and the size of the image file, and each segment of the image file data after segmentation is obtained;

[0016] Each segment of the image file data is distributed to different first cinder-volume nodes, and a snapshot of the system disk corresponding to the create image request is established through each first cinder-volume node;

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

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

[0019] In an alternative embodiment, the method further comprises:

[0020] After the parallel image upload processing 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 completes the parallel image upload processing last.

[0021] In an alternative embodiment, the current image state and the current image storage location information corresponding to the create system disk request are obtained, comprising:

[0022] The create system disk request is parsed to obtain system disk information corresponding to the create system disk request; the system disk information includes image ID, image storage location, and system disk size;

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

[0024] In an alternative embodiment, the current image state and the current image storage location information corresponding to the create system disk request are obtained, comprising:

[0025] If the current mirror state is available state, and the current mirror storage location information points to the target Ceph cluster, it is determined not to perform mirror pulling processing;

[0026] If the current mirror state is non-available state, and the current mirror storage location information does not point to the target Ceph cluster, it is determined whether there is a download pulling task in the current storage backend for the system disk creation request;

[0027] If there is a download pulling task, the current system disk state is set to queuing, and if there is no download pulling task, it is determined to perform mirror pulling processing.

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

[0029] If it is determined not to perform mirror pulling processing, the mirror file in the target Ceph cluster is cloned and processed by a single second cinder-volume node to create a new system disk.

[0030] In an optional embodiment, the mirror pulling task is segmented and processed according to the size of the mirror file, and each segment of the mirror pulling task data after segmentation processing is downloaded in parallel by different second cinder-volume nodes to write the mirror file from the object storage to the block storage, comprising:

[0031] Based on the size of the second cinder-volume node and the size of the mirror file, the mirror pulling task is segmented and processed, and each segment of the mirror pulling task data after segmentation processing is obtained;

[0032] Each segment of the mirror pulling task data is distributed to different second cinder-volume nodes, and the corresponding segment of the mirror file data is read from the object storage by the different second cinder-volume nodes, and the mirror file data is written to the block storage;

[0033] After the parallel mirror downloading processing is completed, the target second cinder-volume node is checked for the system disk waiting to be created; the target second cinder-volume node is the second cinder-volume node that completes the parallel mirror downloading processing last;

[0034] If there is a waiting system disk, the mirror file data obtained by downloading is cloned and processed to create a 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 application provides a device for fast transmission of cloud host image of multi-storage backend, the device comprising:

[0037] A creation image request receiving module is configured to receive a creation image request sent by a user.

[0038] An image uploading module is configured to perform segmentation processing on an image file corresponding to the creation image request, and perform parallel image uploading processing on each segment of the image file data after the segmentation processing through different first cinder-volume nodes, so as to upload the image file from block storage to object storage.

[0039] A system disk creation receiving request module is configured to 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.

[0040] An image pulling judgment module is configured to judge whether to perform image pulling processing according to the current image state and the current image storage location information.

[0041] An image downloading module is configured to, if it is judged to perform image pulling processing, perform segmentation processing on the image pulling task according to the image file size, and perform parallel image downloading processing on each segment of the image pulling task data after the segmentation processing 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 application provides a computer device, comprising a memory and a processor, the memory and the processor are in communication connection with each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the fast transmission method of cloud host image of multi-storage backend according to the first aspect or any one of the corresponding embodiments thereof.

[0043] In a fourth aspect, the present application provides a computer readable storage medium, the computer readable storage medium stores computer instructions, and the computer instructions are used to make the computer execute the fast transmission method of cloud host image of multi-storage backend according to the first aspect or any one of the corresponding embodiments thereof.

[0044] In a fifth aspect, the present application provides a computer program product, comprising computer instructions, and the computer instructions are used to make the computer execute the fast transmission method of cloud host image of multi-storage backend according to the first aspect or any one of the corresponding embodiments thereof.

[0045] The technical solution provided by the present application can include the following beneficial effects:

[0046] The present application sinks part of the functions of the glance-api to the cinder-volume node, so that part of the image management functions originally concentrated in the glance-api are distributed to the cinder-volume node, and no longer transit through the glance-api, but directly use the storage network of the cinder-volume node for downloading, not only reducing the burden of the glance-api and improving its ability to focus on other core image management functions, but also enabling the cinder-volume node to more directly participate in the image download operation, taking advantage of its close connection with the storage network, optimizing the entire image download process and improving the overall efficiency and scalability of the system.

[0047] Moreover, the cinder-volume node of the present application downloads from the object storage in a segmented and concurrent manner, fully utilizing the feature that the cinder-volume node can be horizontally scaled. For large images, through segmented processing, each segment can be independently downloaded on different cinder-volume nodes, multiple nodes work in parallel, greatly improving the download speed. In a large concurrent scenario, that is, when there are multiple image download requests at the same time, this segmented and concurrent mechanism can flexibly allocate tasks according to the size of the nodes to avoid a single node becoming a bottleneck. Since the present application adopts segmented and concurrent downloading, multiple cinder-volume nodes simultaneously read different segmented image data from the object storage and write to the block storage, which greatly reduces the overall download time compared to the traditional sequential download method. At the same time, when uploading images to the object storage, a similar segmented processing method is also used 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 entire process is significantly shortened, improving the response speed of cloud host image related operations, enhancing user experience, and making the entire cloud service more efficient and agile. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0049] Figure 1 is a flowchart of a fast transmission method of cloud host images of a multi-storage backend according to an embodiment of the present application;

[0050] Figure 2 is a flowchart of another fast transmission method of cloud host images of a multi-storage backend according to an embodiment of the present application;

[0051] Figure 3 is a mirror upload diagram for creating a mirror request according to an embodiment of the present application;

[0052] Figure 4 is a range division diagram for the first cinder-volume node to process data according to an embodiment of the present application;

[0053] Figure 5 is a mirror download diagram for creating a system disk request according to an embodiment of the present application;

[0054] Figure 6 is a range division diagram for the second cinder-volume node to process data according to an embodiment of the present application;

[0055] Figure 7 is a flowchart of another method for fast transmission of cloud host images of a multi-storage backend according to an embodiment of the present application;

[0056] Figure 8 is a structural block diagram of a device for fast transmission of cloud host images of a multi-storage backend according to an embodiment of the present application;

[0057] Figure 9 is a hardware structure diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0058] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in connection with the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[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 the cloud computing environment, it is often 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 large-scale data storage, while block storage provides high-performance data access. Traditional image management methods face performance bottlenecks and efficiency problems when handling large-capacity data and high-concurrency requests, especially during image upload and download processes, which require a large amount 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 efficient transmission of image data 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. To improve the availability of cloud services and implement disaster recovery, image copies need to be stored in different geographic locations, and images need to be quickly synchronized between different storage systems and data centers.

[0061] The present application optimizes the upload and download process of images, improves the storage efficiency and performance of the cloud platform, reduces costs, and enhances the reliability and flexibility of cloud services, suitable for various cloud computing scenarios described above. When an enterprise or user needs to quickly create multiple cloud host instances, the present application can quickly pull images from object storage to ceph block storage to create cloud host system disks, and use the segmented and concurrent download method of cinder-volume nodes to greatly shorten the creation time of cloud hosts. At the same time, by avoiding the occupation of management network bandwidth by downloading images through glance-api, the management network is ensured to be unblocked, so that the system can stably perform other management operations such as monitoring the running state of cloud hosts, dynamically adjusting resource configuration, etc. In an enterprise cloud service architecture with multiple availability zones, the present application realizes the capability of image cross-availability zone. For example, when a data center in a certain region needs to quickly deploy cloud hosts with the same configuration as other regions, the present application can be used to quickly transfer existing images to the target region data center, realizing the quick sharing and flexible allocation of resources, improving the overall operational efficiency and resource utilization of the enterprise. For multiple storage backends using object storage and ceph block storage, the present application provides an efficient image management method, which can store some commonly used images in object storage to save costs, and load these images onto ceph block storage as system disks when creating cloud hosts. Through the optimized upload and download process, the present application can quickly and accurately complete the transmission and management of images in this hybrid storage environment, ensuring the collaborative work between different storage backends, and fully utilizing the advantages of object storage and ceph block storage, such as the large-capacity storage advantage of object storage and the high-performance read-write advantage of ceph block storage.

[0062] According to the embodiment of the present application, a multi-storage backend cloud host image fast transmission method 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 the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that here.

[0063] In the present embodiment, a multi-storage backend cloud host image fast transmission method is provided, Figure 1 is a flowchart of a multi-storage backend cloud host image fast transmission method according to an embodiment of the present application, as shown in Figure 1 The flowchart includes the following steps:

[0064] Step S101, receiving a user's request for creating an image.

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

[0066] Step S102, segmenting the image file corresponding to the request for creating an image, and performing parallel image uploading processing on each segment of the image file data processed by different first cinder-volume nodes, so as to upload the image file from block storage to object storage.

[0067] Further, the embodiment processes the mirror file in segments to better utilize system resources and achieve parallel uploading. Since the mirror file can be large, if uploaded as a whole, a single node will take a long time to process and can cause uneven resource occupation. By segmenting, the embodiment can break the large file into multiple smaller parts, each of which can be processed independently, thereby improving the overall upload speed. The embodiment segments according to the size of the first cinder-volume node, which can ensure that each segment is of appropriate size and makes full use of the processing capacity of each node. The cinder-api interface segments according to the size of the mirror, and then calls other first cinder-volume nodes through rpc to process the segmented tasks in parallel. 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 uploading can significantly improve the upload speed and reduce the overall upload time. The cinder-volume node is a server that manages block storage, which provides high-performance random data access functions, and the object storage provides large-scale unstructured data storage.

[0068] Step S103, receiving the user's request to create a system disk, and obtaining the current mirror state and current mirror storage location information corresponding to the request to create a system disk.

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

[0070] Step S104, determining whether to perform mirror pulling processing according to the current mirror state and current mirror storage location information.

[0071] Further, according to the information obtained in step S103, the second cinder-volume node will determine whether to perform mirror pulling processing. If the mirror already exists in the target ceph cluster (block storage) and is in an available state, pulling is not needed. If the mirror does not exist in the target ceph cluster or is not in an available state, mirror data needs to be pulled from the object storage.

[0072] If it is determined that the mirror pulling process is performed, the mirror pulling task is segmented according to the size of the mirror file, and each segmented mirror pulling task data is downloaded in parallel by different second cinder-volume nodes to write the mirror file from the object storage to the block storage.

[0073] Further, if the mirror needs to be pulled, the glance-api interface is called to segment the mirror pulling task, similar to the uploading process. Each segmented task is assigned to a different second cinder-volume node, and each segmented mirror pulling task data is downloaded in parallel by different second cinder-volume nodes. Each node is responsible for reading the corresponding segmented mirror file data from the object storage and writing it to the block storage. In this process, data is transmitted from the object storage to the block storage. The high-performance read-write characteristics of the block storage enable the written data to be quickly used by the cloud host, for example, after the system disk creation is completed, the cloud host can immediately start and run based on this block storage system disk, providing fast service response. At the same time, this parallel downloading method also improves the utilization of the object storage, avoiding the performance bottleneck of a single large file download on the object storage, making the entire storage system work more efficiently.

[0074] In this embodiment, another method for quickly transferring cloud host images of a multi-storage backend is provided, Figure 2 is a flowchart of another method for quickly transferring cloud host images of a multi-storage backend according to an embodiment of the present application, as shown in Figure 2 The flowchart includes the following steps:

[0075] Step S201, receiving a user's request to create an image.

[0076] Further, please refer to Figure 3 The image upload diagram of the request to create an image is shown in the figure. First, the user's request to create an image is finally sent to the cinder-api interface through the upper component. The request first reaches the upper component of the cloud service platform, which is responsible for preliminary verification, permission check, and request routing, etc. After processing by the upper component, the request is forwarded to the cinder-api interface, which is an important interface for block storage related operations, and will be responsible for coordinating the subsequent image creation process, which is the key link directly associated with the user's request in the entire image uploading process.

[0077] In step S202, the image file corresponding to the image creation request is segmented, and each segmented image file data is uploaded in parallel through different first cinder-volume nodes to upload the image file from the block storage to the object storage.

[0078] In an optional embodiment, step S202 includes:

[0079] The image file corresponding to the image creation request is segmented based on the size of the first cinder-volume node and the size of the image file, and each segmented image file data is obtained.

[0080] Each segmented image file data is distributed to different first cinder-volume nodes, and a snapshot of the system disk corresponding to the image creation request is established through each first cinder-volume node.

[0081] After the snapshot is established, a temporary disk is cloned based on the established snapshot, and the temporary disk is copied from the volume pool to the image pool.

[0082] In the image pool, the objects are cleaned up, and each segmented image file data is read from the image pool and written to the object storage.

[0083] Further, the embodiment segments the image file according to the number of first cinder-volume nodes, performance, and other scale factors, and the actual size of the image file, and obtains each segment of the image file data after segmentation processing, to prepare for subsequent allocation to nodes for processing. Each segment of the image file data is allocated to different first cinder-volume nodes. After each node receives the allocated segment data, it 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 time 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 creates a temporary copy identical to the snapshot data of the original system disk, and then copies 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 system disk of the cloud host, and the image image pool is a storage area for image management. Object cleaning is performed in the image image pool, which can include deleting temporary files, invalid data, and the like, to optimize the storage structure of the image data and improve data quality. Then each segment of the image file data is read from the image image pool and written to the object storage. The object storage is suitable for storing a large amount of unstructured data, such as image files. Storing image data in the object storage can facilitate subsequent sharing and use of images in different areas and between different nodes. Through the above steps, different first cinder-volume nodes simultaneously process the segment image file data they are responsible for, achieving parallel image uploading. Each node independently performs the process of obtaining system disk data (through snapshot and cloning operations), data conversion (copying to the image pool and cleaning), and data writing to the object storage. Parallel work of multiple nodes greatly shortens the upload time of the entire image file, and improves the overall performance and resource utilization of the system.

[0084] Further, as shown in Figure 3 the embodiment segments the image file, and then schedules different first cinder-volume nodes to process each segment of data. When the last segment processing is completed, the last completed first cinder-volume node calls the glance-api interface to update the image status and image storage location information. Please refer to Figure 4The first cinder-volume node processing data range division diagram shown in the figure, the user creates a private image task with an existing cloud host system disk, and directly distributes multiple first cinder-volume node tasks. Assuming n, the data length processed by each first cinder-volume node is smaller, and the processing time is greatly shortened. The image data processed by the previous cinder-volume node is replaced by multiple first cinder-volume nodes for concurrent processing, greatly improving the speed of image uploading to object storage. With the cluster module specification, the number of first cinder-volume nodes can be increased horizontally to improve concurrent processing capability. Each cinder-volume node is responsible for processing a specific range of data, reading the corresponding segmented data from block storage, and preparing to upload to object storage. The specific range is represented 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 represents the node number, segment represents the segment size, and image_size represents the image size. The overall process revolves around data processing from block storage to object storage, performed in parallel by multiple first cinder-volume nodes.

[0085] Step S203, after the completion of the parallel image uploading process, the target first cinder-volume node calls the qlance-api interface to update the image state and image storage location information; the target first cinder-volume node is the first cinder-volume node that completes the parallel image uploading process last.

[0086] Further, when all the segmented image file data is completed uploading to the object storage, it is necessary to determine that the entire image uploading task has been completed. In the parallel uploading process, each first cinder-volume node is responsible for processing a segment, and the node that finally completes the uploading of the segment it is responsible for is regarded as the target first cinder-volume node, which can accurately determine the completion of the entire image uploading task. The target first cinder-volume node calls the glance-api interface to update the image state and image storage location information. The image state can include state identifiers such as "uploading completed", "available", and "unavailable", and updating the state information can enable other system components and users to understand the current state 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 needed in the future. 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 user-sent request for creating a system disk, and obtaining current image state and current image storage location information corresponding to the request for creating a system disk.

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

[0089] parsing the request for creating a system disk to obtain system disk information corresponding to the request for creating a system disk; the system disk information includes an image ID, an image storage location, and a system disk size;

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

[0091] Further, when receiving the user sent system disk creation request, the embodiment first parses the request, and the system disk creation request contains various information related to system disk creation, such as image information used, system disk size requirement, storage location, etc. By parsing the request, the key system disk information is extracted, including image ID, image storage location and system disk size, etc. The image ID is an identifier that uniquely identifies the image, which can accurately locate and identify the required image resource. 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. The embodiment uses the extracted image ID to obtain the current image state and current image storage location information corresponding to the system disk creation request by calling the image service API interface (i.e. glance-api interface). The glance-api interface is a service interface responsible for image file management, which provides the function of querying various attribute information of the image. According to the image ID, the current state and storage location information of the image can be found and returned in the image management system. The obtained image state and storage location information will be used for subsequent decision-making, such as whether image pulling processing is needed and how to perform pulling operation, etc.

[0092] In step S205, whether image pulling processing is performed is determined according to the current image state and the current image storage location information.

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

[0094] If the current image state is an available state, and the current image storage location information points to the target ceph cluster, it is determined that no image pulling processing is performed.

[0095] If the current image state is an unavailable state, and the current image storage location information does not point to the target ceph cluster, it is determined whether there is a download pulling task in the current storage backend for the system disk creation request.

[0096] If there is a download pulling task, the current system disk state is set to queuing, and if there is no download pulling task, it is determined that image pulling processing is performed.

[0097] Further, when the current image state is determined to be available and the current image storage location information points to the target ceph cluster, it indicates that there is already an available image in the target ceph cluster, and its location is clear. In this case, no additional image pulling process is needed because the required image is already in the right place and can be used directly. This judgment mechanism helps to optimize the overall performance and resource utilization efficiency of the system, avoiding unnecessary repeated pulling of images, reducing the occupation of network bandwidth, object storage and ceph block storage read-write operations, and the processing burden of cinder-volume nodes. At the same time, the step of pulling the image can be directly skipped, which also speeds up the system disk creation. When the current image state is not available or the current image storage location information does not point to the target ceph cluster, it indicates that further checking is needed to determine whether image pulling is needed. The non-available state may indicate that the image is being created, updated or there are other problems that cause it to be temporarily unavailable, while the storage location not in the target ceph cluster means that the image data needs to be obtained from other locations. In this case, further judgment is made on whether there is a download pulling task in the current storage backend for the system disk creation request. If there is a download pulling task, it means that there is already another same or related task being processed, in order to avoid repeated pulling and resource conflicts, the current system disk state is set to queued, which can ensure that the image pulling operation is performed in sequence in the concurrent case, avoiding network congestion, storage resource competition and other problems caused by multiple tasks pulling the same image at the same time. If there is no download pulling task, it is determined to perform image pulling, and the system will start the subsequent image pulling process to obtain image data from the appropriate location and create a system disk.

[0098] In step S206, if it is determined to perform image pulling, the image pulling task is segmented according to the size of the image file, and each segmented image pulling task data is processed for parallel image download through different second cinder-volume nodes to write the image file from the object storage to the block storage.

[0099] In an optional embodiment, the step S206 includes:

[0100] The image pulling task is segmented based on the size of the second cinder-volume node and the size of the image file, and each segmented image pulling task data is obtained;

[0101] Each segmented image pulling task data is distributed to different second cinder-volume nodes, and the corresponding segmented image file data is read from the object storage through the different second cinder-volume nodes, and the image file data is written to the block storage;

[0102] After the parallel mirror image download processing is completed, the target second cinder-volume node checks the system disk waiting to be created; the target second cinder-volume node is the second cinder-volume node that completes the parallel mirror image download processing last;

[0103] If there is a waiting system disk, the mirror image file data obtained by downloading is used for cloning system disk processing;

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

[0105] Further, similar to uploading, the embodiment performs segmented processing on the mirror image pulling task according to the scale (such as the number of nodes, performance, etc.) of the second cinder-volume node and the size of the mirror image file. The size, offset start bit, and other parameters of each segment are calculated to ensure that the segmentation is reasonable and can fully utilize the parallel processing capability of the node. The mirror image pulling task data of each segment is distributed to different second cinder-volume nodes in the embodiment. After each node receives the assigned task, it starts reading the mirror image file data of the corresponding segment from the object storage. By simultaneously reading data of different segments from the object storage through multiple nodes, parallel mirror image download is achieved. It takes advantage of the distributed characteristics of the object storage and network bandwidth to speed up the acquisition speed of the mirror image data. After the parallel mirror image download processing is completed, the target second cinder-volume node checks the system disk waiting to be created; the target second cinder-volume node is the second cinder-volume node that completes the parallel mirror image download processing last; the target second cinder-volume node can accurately determine the completion of the entire mirror image download task, at which time the entire mirror image data has been successfully downloaded from the object storage to the local node or temporary cache. Then, the target node checks whether there are other system disks waiting in the queue to use the mirror image data for creation. If there is a waiting system disk, the mirror image file data obtained by downloading is used for cloning system disk processing. If there is no waiting system disk, it is determined that the entire system disk creation process is completed, and the system can release related resources, such as cleaning up temporary data, closing unnecessary network connections, etc., and feedback the system disk creation success information to the user or other related components, marking the end of this system disk creation task.

[0106] Further, please refer to Figure 5The illustrated image download schematic diagram of creating system disk request, when the image is downloaded, the second cinder-volume node receives the request of creating system disk, the second cinder-volume node calls the glance-api interface to obtain the current state and storage location information of the image, the second cinder-volume node judges whether the image exists in the target Ceph cluster according to the current storage backend managed by itself, if the image exists in the current target Ceph cluster, the second cinder-volume node directly clones to create system disk, and the task is completed, if the image does not exist in the current target Ceph cluster, it is checked whether there is a download pulling task in the current storage backend, if there is a download task, the current system disk state is set to queuing; if not, a new image pulling task is created. Then, the task is segmented according to the size of the image, and is processed by different second cinder-volume nodes, and finally, the second cinder-volume node that completes the download task checks whether there is a queued system disk, and if there is, cloning is sequentially performed, and if not, the entire image download task is completed.

[0107] See Figure 6The second cinder-volume node processes the range division of the data. A user creates a cloud host system disk using an image stored in the existing object storage. The second cinder-volume node reads the image data from the object storage and stores the image data in the images pool of the Ceph cluster. The task segments the image file, and each segment is processed by a second cinder-volume node. Therefore, the time required for downloading an image is greatly shortened. Previously, one cinder-volume node processed image data, and multiple second cinder-volume nodes concurrently process the image data, which greatly improves the speed of uploading the image to the object storage. As the cluster module specification increases, the number of second cinder-volume nodes can be increased horizontally to improve the concurrent processing capability. After the image file is stored in the images pool of the block storage, a snapshot of the image is taken and write protection is added. If there is a request to create a system disk using 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 a specific range of data. The range is represented as an interval from a start position to an end position, such as cinder-volume:0-(segment-1), cinder-volume:segment-(2*segment-1), and so on, up 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 the parallel processing of data by multiple second cinder-volume nodes. From a specific starting point, the data in the corresponding interval is processed by a specific second cinder-volume node. The data processing object comes from the images pool. Figure 6 In the above embodiment, the Bucket is an object storage bucket, which is a storage unit in the object storage. The images pool is a storage resource pool used to store volume data, such as block storage.

[0108] In step S207, if it is determined not to perform image pulling processing, a single second cinder-volume node is used to clone the image file in the target Ceph cluster to create a new system disk.

[0109] Further, when it is determined not to perform the mirror pulling process, it means that there is already a usable mirror in the target Ceph cluster and the location is correct. At this time, the mirror file in the target Ceph cluster is processed by a single second cinder-volume node to create a new system disk. The cloning operation can quickly copy the mirror file to create a copy of the original mirror as a new system disk. This direct cloning method avoids unnecessary network transmission and coordination overhead between nodes, effectively utilizing the existing mirror resources in the target Ceph cluster. At the same time, it reduces the processing time and resource consumption of the system, because it does not need to start a complex mirror pulling process, such as segmentation processing, multiple node parallel downloading, etc. This helps to improve the efficiency of the entire cloud service system in processing system disk creation requests, especially when the mirror already exists and is available, it can quickly respond to user needs, improve user experience, and make cloud host creation more rapid and convenient.

[0110] Further, please refer to Figure 7 Another flowchart of a method for fast transmission of cloud host images of a multi-storage backend is shown, comprising the following steps:

[0111] 1. The user first issues a request to create a private image for an existing cloud host system disk, and the request is issued to the cinder-api interface. That is, the user initiates a request to create a private image for an existing cloud host system disk on the cloud service platform, and this request is processed by the upper layer component and then issued to the cinder-api interface, which marks the beginning of the image creation process and the user's demand is 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 according to the incoming 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 according to the incoming system disk identifier volume-id interface. The system disk identifier volume-id is the unique identifier of the system disk, which ensures accurate positioning to the responsible node.

[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 volume pool to the image pool, and begins cleaning up the object in the image pool. In other words, the cinder-volume node first takes a snapshot of the system disk; the snapshot is a record of the system disk's state at a certain point in time, providing a data backup for subsequent operations. Next, it clones a temporary disk, copies it from the volume pool to the image pool, and cleans up the object in the image pool. This step transforms the system disk data into an intermediate state suitable for image processing, preparing for subsequent writing to object storage. The volume pool is a storage resource pool used to store virtual machine volumes (disks), and the image pool is a storage resource pool used to store virtual machine images. Both the volume pool and the image pool reside in the block storage system, providing block storage and allowing virtual machines to directly access storage blocks.

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

[0115] 5. After the image data is written (i.e., after step 4), the cinder-volume node calls the glance-api interface to complete the addition and update of the image location backend. In other words, once 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 image's storage location information is accurately recorded for easy retrieval and use later.

[0116] 6. User request in Figure 7 The user requests to create a new system disk in Availability Zone 3 using the image created above. This means the user can leverage an existing image to quickly deploy a new cloud server system disk in other zones.

[0117] 7、Other available areas create cloud host system disk according to the image, and cinder-api interface segments according to the size of the image. In this embodiment, the cinder-api interface is configured to segment according to the size of the cinder-volume node, for example, segmenting 5 segments of data processing. First, calculate the size of each segment if segmented into 5 segments: chunk = int(math.ceil(float(totalsize) / segnum)), then obtain the length and offset start bit of each segment, and finally obtain the list information of the entire segment. Then, through rpc, call other cinder-volume nodes for segmentation processing. That is, when other available areas need to create cloud host system disk according to the image, in order to improve efficiency and adapt to different network environments, cinder-api interface segments according to the size of the image and the size of the cinder-volume node. In this embodiment, the size of each segment is calculated when segmented into a specific number of segments (for example, 5 segments), the length and offset start bit of each segment are obtained, and the list information of the entire segment is obtained. Then, through rpc (remote procedure call), call other cinder-volume nodes for segmentation processing, and fully utilize the parallel processing capability of multiple nodes.

[0118] 8、Each cinder-volume node processes the segmentation task by reading the corresponding segment content from the object storage, realizing parallel reading operation, multiple nodes simultaneously obtaining different parts of the image data from the object storage, improving 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 the block storage format suitable for cloud host system disk, and prepares for creating system disk.

[0120] 10、After the last segment task is completed, the cinder-volume node that has completed the task updates the disk state information and the queued disk to make an image snapshot clone. That is, after the last segment task is completed, the cinder-volume node that has completed the task is responsible for updating the disk state information, and if there is a queued disk that needs to create a system disk, it will make an image snapshot clone, quickly create a system disk using the downloaded image data, and improve the concurrent processing capability of the system.

[0121] In summary, the above scheme sinks part of the functions of the glance-api to the cinder-volume node, so that the part of the image management functions originally concentrated in the glance-api are dispersed to the cinder-volume node, and no longer transit through the glance-api, but directly use the storage network of the cinder-volume node for downloading, not only reducing the burden of the glance-api and improving its ability to focus on other core image management functions, but also enabling the cinder-volume node to more directly participate in the image download operation, taking advantage of its close connection with the storage network, optimizing the entire image download process and improving the overall efficiency and scalability of the system.

[0122] Moreover, the cinder-volume node of the above scheme downloads from the object storage in a segmented and concurrent manner, fully utilizing the feature that the cinder-volume node can be horizontally scaled. For large images, through segmentation processing, each segment can be independently downloaded on different cinder-volume nodes, and multiple nodes work in parallel, greatly improving the download speed. In a large concurrent scenario, that is, when there are multiple image download requests at the same time, this segmented and concurrent mechanism can flexibly allocate tasks according to the size of the nodes to avoid a single node becoming a bottleneck. Since the above scheme uses segmented and concurrent downloading, multiple cinder-volume nodes simultaneously read different segmented image data from the object storage and write to the block storage, which greatly reduces the overall download time compared to 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 used 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 entire process is significantly shortened, improving the response speed of the cloud host image related operations, enhancing the user experience, and making the entire cloud service more efficient and agile.

[0123] In the embodiment, a multi-storage backend cloud host image fast transmission device is also provided, which is used to implement the above embodiments and preferred embodiments, and details are not repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware is also possible and contemplated.

[0124] The embodiment provides a multi-storage backend cloud host image fast transmission device, as shown in Figure 8 , comprising:

[0125] The image creation request receiving module 801 is configured to receive a user-sent image creation request.

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

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

[0128] The mirror pulling judgment module 804 is configured to judge whether to perform mirror pulling processing according to the current mirror state and the current mirror storage location information;

[0129] The mirror downloading module 805 is configured to, if it is judged to perform mirror pulling processing, perform segmentation processing on the mirror pulling task according to the mirror file size, and perform parallel mirror downloading processing on each segment of the mirror pulling task data processed by the segmentation processing through different second cinder-volume nodes, so as to write the mirror file from the object storage to the block storage.

[0130] In some optional embodiments, the mirror uploading module 802 is further configured to:

[0131] perform segmentation processing on the mirror file corresponding to the creation mirror request based on the first cinder-volume node scale and the mirror file size, and obtain each segment of the mirror file data processed by the segmentation processing;

[0132] allocate each segment of the mirror file data to different first cinder-volume nodes, and establish a snapshot of the system disk corresponding to the creation mirror request through each first cinder-volume node;

[0133] After the snapshot is established, a temporary disk is cloned based on the established snapshot, and the temporary disk is copied from the volume volumnes pool to the mirror image pool;

[0134] perform object cleaning in the mirror image pool, read each segment of the mirror file data from the mirror image pool, and write the each segment of the mirror file data to the object storage.

[0135] In an optional embodiment, the apparatus is further configured to:

[0136] After the parallel mirror uploading process is completed, a qlance-api interface is called through a target first cinder-volume node to update mirror state and mirror storage location information; the target first cinder-volume node is the first cinder-volume node that completes the parallel mirror uploading process last.

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

[0138] The system disk creation request is parsed to obtain system disk information corresponding to the system disk creation request; the system disk information includes an image ID, an image storage location, and a system disk size.

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

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

[0141] If the current image state is an available state and the current image storage location information points to a target Ceph cluster, it is determined that no image pulling process is performed.

[0142] If the current image state is an unavailable state and the current image storage location information does not point to the target Ceph cluster, it is determined whether there is a download pulling task in the current storage backend.

[0143] If there is a download pulling task, the current system disk state is set to queuing, and if there is no download pulling task, it is determined that an image pulling process is performed.

[0144] In an optional implementation, the apparatus is further configured to:

[0145] If it is determined that no image pulling process is performed, a single second cinder-volume node is used to perform a clone mirror process on the image file in the target Ceph cluster to create a new system disk.

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

[0147] Based on the second cinder-volume node scale and the image file size, the image pulling task is processed in segments, and each segment of image pulling task data after the segment processing is obtained.

[0148] allocating the image pulling task data of each segment to different second cinder-volume nodes, reading the corresponding segmented image file data from the object storage through the different second cinder-volume nodes, and writing the image file data to the block storage;

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

[0150] If there is a system disk waiting, the image file data obtained through downloading is used to clone the system disk;

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

[0152] Further function descriptions of the above modules and units are the same as those of the above corresponding embodiments, and will not be described here.

[0153] The embodiment of the present application further provides a computer device, please refer to Figure 9 , Figure 9 is a structural schematic diagram of a computer device provided by the optional embodiment of the present application, as shown in Figure 9 , the computer device comprises one or more processors 10, a memory 20, and an interface for connecting various components, including a high-speed interface and a low-speed interface. Various components are communicatively connected to each other by different buses, and can be installed on a common mainboard or in other ways as needed. The processor can process instructions executed in the computer device, including instructions stored in the memory or graphics information stored on the memory to display a 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 with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, each device providing part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 9 In the figure, the processor 10 is taken as an example.

[0154] The processor 10 can be a central processor, a network processor, or a combination thereof. The processor 10 can further include a hardware chip. The hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device can be a complex programmable logic device, a field programmable logic gate array, a general array logic, or any combination thereof.

[0155] The memory 20 stores instructions executable by the at least one processor 10 to cause the at least one processor 10 to perform the methods illustrated by the above embodiments.

[0156] The memory 20 can include a program storage area and a data storage area. The program storage area can store an operating system, application programs required by at least one function, and the like. The data storage area can store data created according to the use of the computer device, and the like. In addition, the memory 20 can include a high-speed random access memory, and can further include a non-transitory memory such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some alternative embodiments, the memory 20 can optionally include a memory disposed remotely from the processor 10, which can be connected to the computer device through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0157] The memory 20 can include a volatile memory such as a random access memory, and can further include a non-volatile memory such as a flash memory, a hard disk, or a solid state disk, and a combination of the above-mentioned kinds of memories.

[0158] The computer device further includes a communication interface 30 for communication of the computer device with other devices or communication networks.

[0159] The embodiments of the present application also provide a computer readable storage medium. The above-mentioned methods according to the embodiments of the present application can be implemented in hardware, firmware, or recorded in a storage medium, or stored in a remote storage medium or a non-transitory machine readable storage medium and downloaded to a local storage medium through network downloading of computer code, so that the methods described herein can be processed by such software on a storage medium using a general purpose computer, a special purpose processor, or programmable or special purpose hardware. The storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid state disk, and the like. Further, the storage medium can also include a combination of the above-mentioned kinds of memories. It can be understood that the computer, the processor, the microprocessor controller, or the 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 the computer, the processor, or the hardware, the methods illustrated by the above embodiments are implemented.

[0160] Part of the present application can be applied as a computer program product, for example, computer program instructions, when executed by a computer, through the operation of the computer, the method and / or technical solutions according to the present application can be called or provided. Those skilled in the art should understand that the form of computer program instructions in computer readable medium includes but is not limited to source file, executable file, installation package file and the like, and accordingly, the way of computer program instructions executed by computer includes but is not limited to: the computer directly executes the instructions, or the computer compiles the instructions and then executes the corresponding compiled program, or the computer reads and executes the instructions, or the computer reads and installs the instructions and then executes the corresponding installed program. Here, the computer readable medium can be any available computer readable storage medium or communication medium accessible to the computer.

[0161] Although the embodiments of the present application are described in conjunction with the drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes fall within the scope defined.

Claims

1. A method for fast transmission of cloud host images with multi-storage backends, characterized in that, The method comprises: receiving a user-sent image creation request; segmenting the image file corresponding to the image creation request, and performing parallel image upload processing on each segmented image file data through different first cinder-volume nodes to upload the image file from block storage to object storage, comprising: based on the first cinder-volume node scale and the image file size, segmenting the image file corresponding to the image creation request, and obtaining each segmented image file data; distributing each segmented image file data to different first cinder-volume nodes, and establishing a snapshot for the system disk corresponding to the image creation request through each first cinder-volume node; after the snapshot is established, cloning a temporary disk based on the established snapshot, and copying the temporary disk from the volume pool to the image pool; performing object cleaning in the image pool, and reading each image file data from the image pool; and writing the image file data to the object storage; receiving a user-sent system disk creation request, and obtaining current image state and current image storage location information corresponding to the system disk creation request; determining whether to perform image pulling processing according to the current image state and the current image storage location information; if it is determined to perform image pulling processing, segmenting the image pulling task according to the image file size, and performing parallel image download processing on each segmented image pulling task data through different second cinder-volume nodes to write the image file from the object storage to the block storage.

2. The method of claim 1, wherein, The method further comprises: after the parallel image upload processing is completed, updating the image state and the image storage location information through a target first cinder-volume node calling a qlance-api interface; the target first cinder-volume node is the first cinder-volume node that completes the parallel image upload processing last.

3. The method of claim 1, wherein, The method further comprises: analyzing the system disk creation request to obtain system disk information corresponding to the system disk creation request; the system disk information includes image ID, image storage location, and system disk size; based on the image ID, calling an image service API interface to obtain the current image state and the current image storage location information corresponding to the system disk creation request.

4. The method of claim 1, wherein, The method further comprises: if the current image state is available and the current image storage location information points to a target ceph cluster, it is determined that image pulling processing is not performed. If the current mirror state is an unavailable state, and the current mirror storage location information does not point to the target Ceph cluster, it is determined whether there is a download pulling task for the current storage backend after the creation of the system disk request; If there is a download pulling task, the current system disk state is set to queued, and if there is no download pulling task, it is determined to perform mirror pulling processing.

5. The method of claim 1, wherein, The method further comprises: If it is determined not to perform mirror pulling processing, the mirror file in the target Ceph cluster is cloned and imaged by a single second cinder-volume node to create a new system disk.

6. The method according to any one of claims 1 to 5, characterized in that, The segmented processing of the mirror pulling task according to the size of the mirror file, and the parallel mirror downloading processing of each segment of the mirror pulling task data after the segmented processing by different second cinder-volume nodes to write the mirror file from the object storage to the block storage, comprises: Based on the size of the second cinder-volume node and the size of the mirror file, the mirror pulling task is segmented and processed, and each segment of the mirror pulling task data after the segmented processing is obtained; Each segment of the mirror pulling task data is distributed to different second cinder-volume nodes, the corresponding segment of the mirror file data is read from the object storage by the different second cinder-volume nodes, and the mirror file data is written to the block storage; After the parallel mirror downloading processing is completed, the target second cinder-volume node is checked for the system disk waiting to be created; the target second cinder-volume node is the second cinder-volume node that completes the parallel mirror downloading processing last; If there is a waiting system disk, the mirror file data obtained by downloading is cloned and imaged to process the system disk; If there is no waiting system disk, it is determined that the entire system disk creation process has been completed.

7. A device for fast transmission of cloud host images of multi-storage backends, characterized in that, The device comprises: A creation mirror request receiving module for receiving a user-sent creation mirror request; The mirror uploading module is configured to segment the image file corresponding to the creation mirror request, and perform parallel mirror uploading processing on each segment of the image file data processed by different first cinder-volume nodes, so as to upload the image file from the block storage to the object storage, including: segmenting the image file corresponding to the creation mirror request based on the first cinder-volume node scale and the image file size, and obtaining each segment of the image file data processed; distributing each segment of the image file data to different first cinder-volume nodes, and establishing a snapshot for the system disk corresponding to the creation mirror request through each first cinder-volume node; after the snapshot is established, cloning a temporary disk based on the established snapshot, and copying the temporary disk from the volume volumes pool to the image image pool; performing object cleaning in the image image pool, and reading each segment of the image file data from the image image pool, and writing each segment of the image file data to the object storage; The creation system disk receiving request module is configured to receive a creation system disk request sent by a user, and obtain current mirror state and current mirror storage location information corresponding to the creation system disk request; The mirror pulling judgment module is configured to judge whether to perform mirror pulling processing according to the current mirror state and the current mirror storage location information; The mirror downloading module is configured to, if it is judged to perform mirror pulling processing, segment the mirror pulling task according to the image file size, and perform parallel mirror downloading processing on each segment of the mirror pulling task data processed by different second cinder-volume nodes, so as to write the image file from the object storage to the block storage.

8. A computer device, comprising: Comprising: A memory and a processor, which are mutually connected in communication, the memory stores computer instructions, and the processor executes the computer instructions to perform the method for fast transmission of cloud host mirror of multiple storage backends according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions, and the computer instructions are used to make the computer execute the method for fast transmission of cloud host mirror of multiple storage backends according to any one of claims 1 to 6.

Images