CN104239575A - Virtual machine mirror image file storage and distribution method and device - Google Patents

Abstract

The invention provides a virtual machine image file storage and distribution method and device. The storage method includes: dividing the image file into fixed-length image file blocks; and storing the image file blocks. By storing the image file in fixed-length chunks, the storage space of the virtual machine image file can be effectively saved, while ensuring a high compression ratio. The distribution method includes: determining the image file block belonging to the virtual machine of the client node; establishing a connection with other client nodes based on the P2P protocol; when there are image file blocks required by the client node virtual machine in other client nodes, Otherwise, the required image file blocks are obtained from the data server; or, when there are image file blocks required by other client node virtual machines in the client node virtual machine, the image file blocks are sent. The P2P protocol is used to realize the distribution of image files between virtual machine clients, which effectively improves the efficiency and speed of virtual machine image file distribution.

Description

Method and device for storing and distributing virtual machine image files

technical field

The invention relates to the technical field of data storage, in particular to a method and device for storing and distributing virtual machine image files.

Background technique

"Cloud computing" and "cloud storage" are relatively important technical concepts that have emerged in recent years, and have brought long-term impacts on the development of computer science and the Internet. Cloud computing and cloud storage hide the underlying complex infrastructure and management logic, and provide users with a simple, easy-to-use, and dynamically adjustable resource pool. Users do not need to master the professional knowledge inside the cloud, and do not need to directly control the underlying infrastructure of the cloud. They can easily use the computing and storage resources provided by cloud technology, and can change the usage of resources according to their own needs, so as to save costs.

With the establishment of cloud data centers of major companies, the scale of virtual machines in the cloud environment has expanded rapidly, the multiplexing of hardware resources between virtual machines and the intensification of network communication load have led to the decline in the performance of the entire cloud computing service. How to improve the performance of virtual machines? It has become an important topic in the field of virtual machine research to improve the service quality of the cloud system by improving the service performance in the environment. A virtual machine depends on its own virtual machine image files during operation. In a large-scale virtual cluster data center, the design of a storage solution for a large number of virtual machine image files is particularly important.

When creating a new virtual machine in a cloud computing environment, the hard disk image used is usually copied from a template image. However, traditional SAN (Storage Area Network and SAN protocols, storage area network and its protocols) storage devices do not support fault-tolerant processing. If the SAN device fails, the entire system cannot continue to work.

It can be seen that the existing problems in the storage and distribution of virtual machine image files are as follows:

1. Huge virtual machine image file storage occupies a huge storage space;

2. The distribution of the virtual machine image file depends solely on the image file data server, causing the image file server to become a network hotspot, which limits the establishment, operation speed and robustness of the virtual machine.

Contents of the invention

Aiming at the above problems, the present invention proposes a method and device for storing and distributing virtual machine image files to solve the problems of wasted storage space and low distribution efficiency of mass storage of virtual machine image files.

The present invention provides a virtual machine image file storage method, comprising the following steps:

Divide the image file into fixed-length image file blocks;

Store mirrored file blocks.

The present invention provides a virtual machine image file distribution method, comprising the following steps:

Determine the image file blocks that belong to the virtual machine of the client node;

Establish connections with other client nodes based on the P2P (Peer to Peer, peer-to-peer network) protocol;

When it is determined that the image file blocks required by the client node virtual machine exist in other client nodes, obtain the image file blocks from other client nodes, otherwise obtain the required image file blocks from the data server; or, after determining When there are image file blocks required by other client node virtual machines in the client node virtual machine, the image file block is sent to other client nodes, wherein the image file block is obtained by dividing the virtual machine image file by a fixed length owned.

The present invention provides a virtual machine image file storage device, comprising:

A split unit, used to split the image file into fixed-length image file blocks;

The storage unit is used to store the image file blocks.

The present invention provides a virtual machine image file distribution device, comprising:

A determination unit is used to determine the image file blocks that belong to the virtual machine of the client node;

A connection unit, configured to establish connections with other client nodes based on a peer-to-peer network P2P protocol;

The distribution unit is used to obtain the image file blocks from other client nodes when it is determined that the image file blocks required by the virtual machine of the client node exist in other client nodes, otherwise obtain the required image file blocks from the data server ; Or, when it is determined that there are image file blocks required by other client node virtual machines in the client node virtual machine, the image file block is sent to other client nodes, wherein the image file block is the virtual machine image file Obtained after dividing by fixed length.

The beneficial effects of the present invention are as follows:

In current virtual machine image file storage, due to the huge number of image files, the virtual machine image file storage occupies a huge space. In the virtual machine image file storage solution provided by the embodiment of the present invention, by dividing the virtual machine image file into fixed-length image file blocks for storage, a higher compression ratio is ensured by dividing the image file into fixed-length blocks , so the storage space of the virtual machine image file can be effectively saved.

In addition, relying solely on the image file server in the existing virtual machine image file distribution limits the establishment and running speed and robustness of the virtual machine. In view of this problem, in the virtual machine image file distribution scheme provided by the embodiment of the present invention, the P2P protocol is used to quickly clone and distribute the image file between virtual machine clients, because using the distribution method of the P2P virtual machine image file, all Both the image file server and the client node can be used as the provider of the image file block, exchange the stored image file blocks, effectively transfer the data transmission load of the image file server to the client node, balance the load of data transmission, and avoid The emergence of network hotspots effectively shortens the waiting time and IO overhead for copying image files, and improves the efficiency and speed of virtual machine image file distribution.

Description of drawings

Specific embodiments of the present invention will be described below with reference to the accompanying drawings, wherein:

FIG. 1 is a schematic flow diagram of a method for storing a virtual machine image file in an embodiment of the present invention;

Fig. 2 is a schematic diagram of the de-redundancy compression ratio realized by the system under different image file block sizes in the embodiment of the present invention;

Fig. 3 is a schematic diagram of the IO performance results of the system under different image file block size parameters in the embodiment of the present invention;

Fig. 4 is a schematic diagram of the IO performance test results of the image file block storage scheme in the embodiment of the present invention;

Fig. 5 is the performance comparison schematic diagram of the MD5 algorithm of fingerprint calculation and the SHA-1 algorithm in the embodiment of the present invention;

Fig. 6 is a schematic diagram of image file block file storage in an embodiment of the present invention;

7 is a schematic flow diagram of a method for distributing a virtual machine image file in an embodiment of the present invention;

FIG. 8 is a schematic diagram of an application scenario of a method for distributing a virtual machine image file in an embodiment of the present invention;

9 is a schematic diagram of a virtual machine image file storage device in an embodiment of the present invention;

10 is a schematic diagram of a virtual machine image file distribution device in an embodiment of the present invention;

Fig. 11 is a schematic diagram of Bonnie++ system performance test results in the embodiment of the present invention;

Fig. 12 is a schematic diagram of PostMark system performance test results in the embodiment of the present invention;

Fig. 13 is a schematic diagram of the performance test results of the Linux virtual machine in the embodiment of the present invention;

FIG. 14 is a schematic diagram of a comparison of the time spent in transferring a virtual machine image file in an embodiment of the present invention;

FIG. 15 is a schematic diagram of a comparison of startup speeds of virtual machines during on-demand transmission according to an embodiment of the present invention.

Detailed ways

In order to make the technical solutions and advantages of the present invention clearer, the exemplary embodiments of the present invention will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all implementations. Exhaustive list of examples.

Fig. 1 is a schematic flow diagram of a method for storing a virtual machine image file in an embodiment of the present invention. As shown in Fig. 1, the storage of a virtual machine image file may include the following steps:

Step 101: dividing the image file into fixed-length image file blocks;

Step 102: Store the image file blocks.

In implementation, the fixed-length image file block size may be N times 4KB, where N is a natural number.

Specifically, a fixed-length image file block segmentation scheme is adopted, and 4KB or an integer multiple of 4KB is used as the image file block size as the basic data block size saved by the file system on the disk, which ensures that all data written to the disk can be divided according to the disk cluster boundary. to align. Since both the operating system image and the application image are read-only, they cannot be modified once they are written into the image file. Therefore, the fixed-length segmentation scheme can ensure a high compression ratio.

The size of the image file block will directly affect the IO performance and storage compression ratio of the system. Therefore, it is necessary to select an optimal data block size parameter in order to obtain a balance between IO performance and storage compression ratio.

Fig. 2 is a schematic diagram of the deredundancy compression ratio realized by the system under different image file slice sizes in the embodiment of the present invention. As shown in Fig. 2, deduplication is performed on 183 commonly used virtual machine image files with a total size of 2.31 TB Yu Erde obtained that these image files include multiple versions of Windows operating system and Linux operating system, and the application software includes scientific computing software, bioinformatics analysis software, database management system, office system, network service system, integrated development environment, etc. A variety of combinations basically cover most of the virtual machine application requirements. All virtual machine file systems store disk clusters with a size of 4KB. Therefore, deredundancy image file blocks smaller than 4KB cannot significantly improve the deredundancy compression ratio. When the image file block size increases, the overall de-redundancy compression ratio of the system drops rapidly.

Figure 3 is a schematic diagram of the IO performance results of the system under different image file slice size parameters in the embodiment of the present invention, as shown in Figure 3, the experimental data comes from Liquid, where Liquid is the virtual machine image file provided in the embodiment of the present invention After the storage method is applied in practice, the corresponding virtual machine image file storage system is obtained. For the convenience of calling, the device is named "Liquid". Raw data is marked in Figure 3, which is the performance of reading and writing operations on the local image file block storage, because the read and write image file blocks can only be different image file blocks after de-redundancy operations, and the number of them is smaller than that of The actual data written to the mirror is less. The data marked with de-redundancy is the result obtained by considering the de-redundancy compression ratio, which is an indicator of the actual IO performance provided by the client file system to the virtual machine. Smaller data blocks will cause more random disk read and write operations, and thus will destroy the IO performance of the system. With the growth of the image file block, the IO performance gradually improves, and gradually stabilizes after the image file block size reaches 256KB.

Based on the experimental results in the embodiments of the present invention and the actual use experience, it is shown that using the image file block size in the range of 256KB to 1MB can achieve good system IO performance and de-redundancy compression ratio, reach a balance between the two, and can meet absolute requirements. most application requirements.

In implementation, the block size of the fixed-length image file may be 256KB.

In the specific implementation, in terms of the selection of the image file block size, the size of the block can be customized, and the compressed storage of blocks of different sizes can be realized. Generally speaking, a larger block plan means the repetition degree between each image block Smaller, the compression ratio is smaller, and the smaller chunking scheme leads to a decrease in system IO performance due to the increase in the amount of metadata. After testing, the appropriate block size is 256KB, which can achieve a balance between IO performance and storage compression ratio.

Figure 4 is a schematic diagram of the IO performance test results of the image file block storage scheme in the embodiment of the present invention. As shown in Figure 4, the virtual machine image file storage scheme in the embodiment of the present invention and the common Ext4 (The fourth extended file system, extended log) are adopted Type file system fourth edition) file system design is compared and contrasted, and the experimental environment is that 32 cores main frequency is the Intel (R) Xeon CPU E5-2640 processor of 2GHz, 1 32GB internal memory server, installs the virtual system provided in the implementation of the present invention Then use 256KB as the default block size of the image file, and then write the image file with a size of 1GB to 160GB to test the read and write performance. The test results show that the performance of the optimized storage scheme provided in the embodiment of the present invention is better than that of the Ext4 file system, and the performance difference between the two in terms of image reading is not large, but it can be clearly seen in the writing performance. It is known that with the gradual expansion of the scale of stored image files in the system, the scale of metadata in the system will increase significantly in Ext4, causing its write performance to plummet when the storage capacity is greater than 10G. However, in the storage solution provided in the embodiment of the present invention, The performance of image file writing is relatively stable. For the large-scale growth of image files, the writing speed is stable above 40MB/s, and the reading performance is stable at about 30MB/s. On the whole, it supports massive image files. Storage is superior to Ext4-based solutions.

During implementation, when storing mirrored file blocks, they may be stored aligned according to disk cluster boundaries.

In a specific implementation, the fixed-length image file block can be 4KB or an integer multiple of 4KB, and can be stored on the disk aligned with the boundary of the disk cluster to effectively use the disk space.

During implementation, deredundancy may be performed on stored image file blocks.

In the specific implementation, to remove the redundancy of the stored image file blocks, the image file can be cut into variable-length or fixed-length blocks. From the effect point of view, the effect of variable-length cutting is better, but the implementation is complicated and the amount of calculation is also large. ; In the embodiment of the present invention, the image file blocks are not modified much, and fixed-length cutting is easy to implement, and can achieve a better compression effect.

During implementation, MD5 (Message Digest Algorithm MD5, message digest algorithm fifth edition) fingerprint feature calculation can be performed on the image file block to determine the fingerprint feature of the image file block; according to the fingerprint feature, the stored image file block is deredundant; While mirroring a file block, its fingerprint feature is stored at the same time.

In specific implementation, in consideration of eliminating redundancy in the process of storing the virtual machine image file, it is necessary to detect whether the image file contains duplicate image file blocks. The MD5 encryption algorithm can be used to calculate the fingerprint feature of the image file, and the image file blocks with the same fingerprint feature are considered as redundant image file blocks. For the selection of the fingerprint feature algorithm, in the embodiment of the present invention, the performance of the MD5 encryption algorithm and the SHA-1 (Secure Hash Algorithm, secure hash algorithm) algorithm is tested and compared, and the two are applied to calculate each fixed-length image file block Fingerprint characteristics, find out the process of de-redundant storage of mirror blocks with the same data. In the embodiment of the present invention, 1 to 16 concurrent threads are used for calculation tests to calculate the throughput performance difference performance of the two algorithms under the same number of threads. Figure 5 is a schematic diagram of the performance comparison between the MD5 algorithm and the SHA-1 algorithm for fingerprint calculation in the embodiment of the present invention, and the specific test comparison results are as shown in Figure 5: the MD5 algorithm is significantly better than the SHA-1 algorithm in terms of calculation throughput, and in To a certain extent, as the number of threads increases, the advantages of computing speed become more obvious, while the SHA-1 algorithm is not sensitive enough to CPU computing resources, and the computing throughput remains at a low level under multi-threaded conditions. Therefore, MD5 is a more excellent algorithm for calculating fingerprint features. Of course, in addition to the MD5 algorithm, other algorithms that can achieve the same function can also be used.

In specific implementation, after completing the image file storage of an application program or operating system, when running the image file, block the image file and perform MD5 fingerprint feature calculation, which may include:

Store the image file blocks that need to be modified in different virtual machines in the first-level cache, and store the most recently read read-only image file blocks in the second-level cache;

Perform MD5 fingerprint feature calculation on the image file blocks in the second-level cache.

In the specific implementation, two-level cache areas can be maintained in the memory, and image file blocks that need to be modified in different virtual machines are stored in the first-level cache area. Here, the first-level cache area mainly caches the virtual machine clients running Image file blocks that need to be frequently modified during the image file process, that is, the first-level cache area can be named as a private cache, and the image file blocks in the first-level cache area do not calculate fingerprint features. The second-level cache area mainly stores the read-only data blocks read recently, and performs fingerprint feature calculation on the image file blocks in the second-level cache area. That is, only when the image file blocks in the first-level cache are flushed into the second-level cache, the fingerprint features need to be calculated. Using two-level cache can effectively reduce the amount of fingerprint feature calculation of the image file blocks. In the first-level cache The image file blocks are modified for different virtual machines and cannot be used by other virtual machines, so there is no need to calculate their fingerprint features. This process ensures that frequently modified image file blocks can be quickly completed, which greatly improves the operation of the system. efficiency.

During implementation, the image file blocks in the second cache area can be determined according to the LRU (Least Recently Used, least recently used algorithm) algorithm.

In a specific implementation, the LRU algorithm may be used for cache management to speed up the access speed of the virtual machine. The LRU algorithm, that is, the least-used page replacement algorithm, serves for virtual paging storage management. Regarding the memory management of the operating system, how to save and utilize the memory with a small capacity to provide resources for the most processes has always been an important direction of research. The virtual storage management of memory is a more common method now, specifically: in the case of limited memory, expand a part of the external memory as virtual memory, and the real memory only stores the information used during the current operation. This undoubtedly greatly expands the function of the memory and greatly improves the concurrent processing capability of the computer. Virtual page storage management is a management method that divides the space required by the process into multiple pages, stores only the currently required pages in the memory, and puts the rest of the pages in the external memory.

Virtual page storage management reduces the memory space required by the process, but it also brings the disadvantage of longer running time: during the running of the process, it is inevitable to compare some information stored in the external memory with the existing information in the memory. To exchange, due to the low speed of the external memory, the time spent in this step cannot be ignored. Therefore, by adopting an excellent algorithm to reduce the number of times of reading external memory, better results can be further achieved.

During implementation, the image file blocks may be merged into a large data block BLK (Block, data block) file for storage.

During implementation, the position offset corresponding to the size of the BLK file, the free position and the fingerprint feature of the mirror image file block can be obtained; according to the size of the BLK file, the free position and the position offset corresponding to the fingerprint feature of the mirror image file block, Store image file blocks.

During implementation, a bitmap file bitmap may be used to record the used and/or unused positions of the BLK file.

In the specific implementation, Fig. 4 is a schematic diagram of the IO performance test results of the mirrored file block storage scheme in the embodiment of the present invention, and Fig. 6 is a schematic diagram of the mirrored file block file storage in the embodiment of the present invention, by merging and managing a large number of mirrored file block files, reducing Massive metadata operations in the system improve system IO performance. As shown in Figure 6 and Figure 5, the traditional virtual machine image file storage method is to place all image file blocks as separate storage files in a specified directory. In this way, a large number of image file block files will be generated in this directory, accompanied by a large amount of file metadata management, reducing system performance. In the implementation of the present invention, the principle of Haystack can be used for reference to realize virtual machine image file storage, that is, multiple image file blocks are merged and stored in one large data block BLK file.

The upper layer of the file system needs to manage the metadata of the large data block BLK, including the size of the BLK file, the free location, the offset corresponding to the fingerprint feature, etc. Here you can use the BMP (Bitmap, image file format) file to record the bitmap table used and idle records in the BLK file, and the IDX (Index, index) file to record the offset position of the fingerprint feature corresponding to the mirror file block in the BLK file. Three files Both use the first Byte character of the fingerprint as the prefix of their file name, the details can be as follows:

BMP file: Every time a new image file block is written or data is deleted, a BMP file is required. This file records whether the data space in the corresponding offset in the BLK file has been used in bit mode, and writes Before mirroring the file block, first check the free space in the BMP file, and the deleted mirror file block will set its corresponding bit position to 0.

IDX file: Record the metadata content in the corresponding BLK file, mainly used to find the offset position of the image file block corresponding to the fingerprint feature in the BLK file. To read all image file blocks first need to read the corresponding offset from IDX position, and then read the image file block from the corresponding offset position in the BLK file. In order to improve the reading speed of the image file block, the content of the IDX file can be cached in memory.

BLK file: Place the image file block data corresponding to the fingerprint feature. BLK is an array similar to the image file block set, and the length of each array element is fixed as the length of the image block, that is, in the embodiment of the present invention, it is 4KB or more Integer multiple, for the search of the image file block position, it is determined by the image file block position corresponding to the fingerprint feature of the IDX file.

As shown in FIG. 6, based on the above three files, a large number of image file block contents can be merged into the same file. When a virtual machine user writes new image block data, he can first obtain the readable and writable location BLK_ID from the BMP file, set the BLK_ID to 1 in the BMP file, and then write the corresponding fingerprint block to the BLK_ID in the IDX file Mapping, and at the same time provide the offset position corresponding to BLK_ID in the BLK file to the user for writing operation. When the mirror block already exists in Liquid, you only need to read the corresponding BLK_ID number from the IDX file, and then read the relevant data from the BLK file.

On the basis of solving the problem of virtual machine image file storage, the embodiment of the present invention aims at the problem that the existing virtual machine image file distribution only relies on the image file server, which limits the establishment, running speed and robustness of the virtual machine, and provides A method for distributing a virtual machine image file. FIG. 7 is a schematic flow diagram of the implementation of the method for distributing a virtual machine image file in an embodiment of the present invention. As shown in FIG. 7, the method may include the following steps:

Step 701: Determine the image file block that belongs to the client node virtual machine;

Step 702: establish connections with other client nodes based on the P2P protocol;

Step 703: When it is determined that the image file blocks required by the client node virtual machine exist in other client nodes, obtain the image file blocks from other client nodes, otherwise obtain the required image file blocks from the data server; or , when it is determined that there are image file blocks required by other client node virtual machines in the client node virtual machine, the image file block is sent to other client nodes, wherein the image file block is the virtual machine image file according to a predetermined Obtained after long division.

Wherein, step 701 and step 702 do not have strict timing requirements, and those skilled in the art should understand that step 702 can be performed after step 701 or before step 701, and the present invention does not limit the execution order of the above steps.

In the specific implementation, FIG. 8 is a schematic diagram of the application scenario of the virtual machine image file distribution method in the embodiment of the present invention. As shown in FIG. On the client node, all mirror file server nodes and client nodes in the system can serve as mirror file block provider nodes, and realize information distribution by exchanging stored data block fingerprint sets. During implementation, each node (including image file server nodes and client nodes) can send node load-related information to the nodes connected to it through heartbeat packets to balance the load distribution in the system, effectively avoid the emergence of network hotspots, and avoid the emergence of bottlenecks in the system.

In the specific implementation, the client node will first obtain the image file block from the client node connected to it, and only when all the client nodes connected to it do not contain the fingerprint feature corresponding to the required image file block, the client node will It will initiate a read request to the image file server to obtain the required image file blocks, effectively transfer the data transmission load of the image file server to the client node, balance the load of data transmission, and avoid the occurrence of network hotspots.

During implementation, the image file blocks obtained from other clients or data servers may be further stored in the cache area.

During implementation, the image file blocks obtained from other clients or data servers are stored in the cache area, and the image file blocks in the cache area can be determined according to the least recently used algorithm LRU.

In a specific implementation, the LRU algorithm may be used for cache management to speed up the access speed of the virtual machine. The LRU algorithm, that is, the least-used page replacement algorithm, serves for virtual paging storage management. Regarding the memory management of the operating system, how to save and utilize the memory with a small capacity to provide resources for the most processes has always been an important direction of research. The virtual storage management of memory is a more common method now, specifically: in the case of limited memory, expand a part of the external memory as virtual memory, and the real memory only stores the information used during the current operation. This undoubtedly greatly expands the function of the memory and greatly improves the concurrent processing capability of the computer. Virtual page storage management is a management method that divides the space required by the process into multiple pages, stores only the currently required pages in the memory, and puts the rest of the pages in the external memory.

Virtual page storage management reduces the memory space required by the process, but it also brings the disadvantage of longer running time: during the running of the process, it is inevitable to compare some information stored in the external memory with the existing information in the memory. To exchange, due to the low speed of the external memory, the time spent in this step cannot be ignored. Therefore, by adopting an excellent algorithm to reduce the number of times of reading external memory, better results can be further achieved.

During implementation, the MD5 fingerprint feature of the image file block can be calculated; determine whether the image file block required by the client node virtual machine exists in other client nodes according to the fingerprint feature; Whether there are image file blocks required by other client node virtual machines.

In specific implementation, after obtaining the image file of an application program or operating system by the virtual machine image file distribution method, when running the image file, block the image file and perform MD5 fingerprint feature calculation, which may include:

Store the image file blocks that need to be modified in different virtual machines in the first-level cache, and store the most recently read read-only image file blocks in the second-level cache;

Perform MD5 fingerprint feature calculation on the image file blocks in the second-level cache.

In the specific implementation, two-level cache areas can be maintained in the memory, and image file blocks that need to be modified in different virtual machines are stored in the first-level cache area. Here, the first-level cache area mainly caches the virtual machine clients running Image file blocks that need to be frequently modified during the image file process, that is, the first-level cache area can be named as a private cache, and the image file blocks in the first-level cache area do not calculate fingerprint features. The second-level cache area mainly stores the read-only data blocks read recently, and performs fingerprint feature calculation on the image file blocks in the second-level cache area. That is, only when the image file blocks in the first-level cache are flushed into the second-level cache, the fingerprint features need to be calculated. Using two-level cache can effectively reduce the amount of fingerprint feature calculation of the image file blocks. In the first-level cache The image file blocks are modified for different virtual machines and cannot be used by other virtual machines, so there is no need to calculate their fingerprint features. This process ensures that frequently modified image file blocks can be quickly completed, which greatly improves the operation of the system. efficiency.

During implementation, the image file blocks in the second cache area may be determined according to the LRU algorithm.

During implementation, determining whether there is an image file block required by the virtual machine of the client node in other client nodes according to the fingerprint feature may include: sending the fingerprint feature of the image file block required by the virtual machine of the client node to other client nodes set; the fingerprint feature set is used for other client nodes to determine whether there are image file blocks required by the client node virtual machine according to the fingerprint feature set; or, to determine whether there are other client node virtual machines in the client node virtual machine according to the fingerprint feature The image file blocks required by the end node virtual machine include: receiving the fingerprint feature set of the image file block required by the client node virtual machine sent by other client nodes; The required image file blocks.

In the specific implementation, each client node in the system can ask the metadata server node for the location of other nodes, maintain connections with these client nodes, and periodically obtain the latest image file blocks from these client nodes A collection of fingerprint features to ensure that it maintains accurate enough client node information. When it is necessary to obtain the image file block corresponding to a certain fingerprint feature, the client node first randomly selects several other client nodes, and checks whether the client nodes connected to it contain the fingerprint feature corresponding to the required image file block , if the fingerprint feature corresponding to the desired image file block is found, the image file block is obtained from the client node.

The algorithm for finding Peer data nodes in the P2P image file distribution protocol is as follows:

The meaning of the above code is:

In the algorithm for finding peer data nodes, based on the fingerprint feature of the image file block to be read, if the fingerprint feature of the image file block is found in the peer data node, find the image file block corresponding to the fingerprint feature and read it , otherwise, it means that there is no image file block to be read in the Peer data node.

When looking for client nodes, query them in random order, which can effectively avoid hot spots in the system and ensure that the load of each client node is evenly distributed.

During implementation, the image file block fingerprint feature set can be compressed using the Bloom Filter data structure before transmission.

In the specific implementation, Bloom filter is a binary vector data structure proposed by Howard Bloom in 1970. It has good space and time efficiency and can be used to detect whether an element is a member of the set. This detection will only The data in the set is misjudged, and the data that is not in the set is not misjudged, so that each detection request returns "in the set (possibly wrong)" and "not in the set (absolutely not in the set)" two In this case, it can be seen that the Bloom filter sacrifices the correct rate for time and space. If you need to judge whether an element is in a set, the usual method is to save all the elements, and then know whether it is in the set by comparison. Linked lists and trees are based on this idea. When the number of elements in the set changes Larger, the space and time required are linearly increased, and the retrieval speed is getting slower and slower. Bloom filter uses a hash function method to map an element to a point on an m-length array. When the point is 1, the element is in the set, otherwise it is not in the set. The disadvantage of this method is that there may be conflicts when there are many detected elements. The solution is to use k hash functions corresponding to k points. If all points are 1, then the element is in the set. If there are 0, the element is not in the set.

A Bloom Filter has the following parameters:

m: the width of the bit array (number of bits);

n: the number of keys added to it;

k: the number of hash functions used;

f: False Positive ratio;

The f of Bloom Filter satisfies the following formula:

${<span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; 1</span>}<span\; class="notranslate">\; -</span>{<span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; 1</span>}<span\; class="notranslate">\; -</span>\frac{\mathrm{<span\; class="notranslate">\; 1</span>}}{\mathrm{<span\; class="notranslate">\; m</span>}}<span\; class="notranslate">\; )</span>}^{\mathrm{<span\; class="notranslate">\; k\; n</span>}}<span\; class="notranslate">\; )</span>}^{\mathrm{<span\; class="notranslate">\; k</span>}}<span\; class="notranslate">\; \&ap;</span>{<span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; 1</span>}<span\; class="notranslate">\; -</span>{\mathrm{<span\; class="notranslate">\; e</span>}}^{<span\; class="notranslate">\; -</span>\mathrm{<span\; class="notranslate">\; k\; n</span>}<span\; class="notranslate">\; /</span>\mathrm{<span\; class="notranslate">\; m</span>}}<span\; class="notranslate">\; )</span>}^{\mathrm{<span\; class="notranslate">\; k</span>}}$

When m and n are given, the value of k that can minimize f is:

$\frac{\mathrm{<span\; class="notranslate">\; m</span>}}{\mathrm{<span\; class="notranslate">\; no</span>}}\mathrm{<span\; class="notranslate">\; ln</span>}\mathrm{<span\; class="notranslate">\; 2</span>}<span\; class="notranslate">\; \&ap;</span>\frac{\mathrm{<span\; class="notranslate">\; 9</span>}\mathrm{<span\; class="notranslate">\; m</span>}}{\mathrm{<span\; class="notranslate">\; 13</span>}\mathrm{<span\; class="notranslate">\; no</span>}}<span\; class="notranslate">\; \&ap;</span>\mathrm{<span\; class="notranslate">\; 0.7</span>}\frac{\mathrm{<span\; class="notranslate">\; m</span>}}{\mathrm{<span\; class="notranslate">\; no</span>}}$

The f given at this time is:

According to the above formula, for any given f, there are:

n=m ln(0.6185)/ln(f)

At the same time, k hashes are needed to achieve this goal:

k=-ln(f)/ln(2)

Since k must be an integer, in the program implementation of Bloom Filter, the above formula should also be used to obtain the actual f:

f＝(1-e ^-kn/m ) ^k

The above three formulas are the key formulas for the program to realize Bloom Filter.

The transmitted fingerprint set is compressed through the data structure of Bloom Filter. Each BloomFilter is a Bit array, using m binary bits to represent a set with n fingerprints. When a new fingerprint is added to the Bloom Filter, k hash functions will be used to obtain the positions in the k Bit array, and then the data bits in these positions will be set to 1 to indicate that a new fingerprint is added. When detecting whether a fingerprint belongs to a Bloom Filter, also use k hash functions to find k positions in the bit array, and detect whether the data in these positions are all 1, if and only if all the positions are 1, Prove that the fingerprint to be detected belongs to the Bloom Filter.

Each client node in the system will look for the location of other client nodes from the metadata server node, maintain connections with these client nodes, and periodically obtain the latest Boom Filter array from these client nodes to ensure its maintenance These client node information are accurate enough. When the client node needs to obtain the image file block corresponding to a certain fingerprint feature, the client node first randomly selects several client nodes, and checks whether the Boom Filter array of these client nodes contains the required image file If the fingerprint feature of the required image file block is found in one or several of these client nodes, the client node will preferentially obtain the image block data from one of these client nodes, only When all client nodes do not contain the fingerprint data of the required mirror file block, the client node will initiate a read request to the mirror file server to obtain the required mirror block content. Using this optimally designed P2P data distribution mode, the data transmission load on the mirror server can be effectively transferred to the client, and the load distribution in the system can be balanced to avoid the emergence of network hotspots and effectively avoid the emergence of bottlenecks in the system .

During implementation, the image file blocks may be compressed with a compression algorithm whose compression speed is higher than that of the network bandwidth. Furthermore, the compression algorithm may be Google Snappy compression algorithm.

In specific implementation, since the image file needs to be transmitted through the network. In order to reduce the consumption of network bandwidth as much as possible and increase the speed of network transmission to the maximum value, in the embodiment of the present invention, a simple compression process can be performed on the transmitted image file blocks to reduce the size of each data packet. The compression algorithm of the image file block must have a relatively fast speed, at least higher than the network bandwidth, so as to avoid itself becoming a bottleneck. In addition, too many CPU computing resources cannot be occupied, so as not to affect the operation of the virtual machine. By comparing some commonly used mature compression algorithms, for example, Google's Snappy compression function library to compress image file blocks. The main goal of this library is to ensure fast compression speed, not to achieve high compression ratio. The Snappy compression algorithm can achieve a reasonable compression ratio, which is very suitable for compressing network data packets. The test results prove that the Snappy data compression algorithm is superior to the two data compression algorithms gzip and bzip2. The specific test results are as follows:

The Google Snappy algorithm is used because it is commonly used and mainstream, and is easy to use/understand by those skilled in the art, so here we take the Google Snappy algorithm as an example; however, theoretically speaking, it is also possible to use other algorithms, as long as it can achieve fast The purpose of compression is sufficient. The Google Snappy algorithm is only used as a preferred embodiment to teach those skilled in the art how to implement the present invention, but it does not mean that only the Google Snappy algorithm can be used. In the implementation process, it can be combined with practical needs to determine the corresponding algorithm.

The fast cloning of image files eliminates the waiting time and IO overhead for copying new image files, and greatly reduces the time it takes for users to create new virtual machines; in the cloud computing platform, creating a new virtual machine The best practice is to copy a new virtual machine image file from a pre-configured image file template, which can avoid reinstalling the operating system and applications every time a new virtual machine is created, and avoid spending too much time. Most of the virtual machine image files are several GB in size, and it takes several minutes to assign an image file of this size byte by byte, and as the number of virtual machines to be created increases, the total time required will also increase. It grows linearly. In order to effectively create a new virtual machine image file, Liquid provides a fast copy function of the image file, which can create a new virtual machine image file in a very short time.

For Liquid, an image file is actually represented by metadata that preserves the fingerprint characteristics of all image file blocks. The operation of copying the mirror file can be completely replaced by copying the metadata, and it only needs to adjust the reference count of the mirror file block additionally. Since the underlying storage of Liquid is Content Addressable Storage, which supports copy-on-write operations, the modification of the cloned image file will not affect the content of the template image file, nor will it affect the subsequent cloned image file. affect. The metadata of the virtual machine image file is mainly composed of fingerprint metadata, and its data size is much smaller than that of the image file. When a 256KB image file block size is used, the metadata of a 10GB image file is only 640KB, and its copy operation can be completed in milliseconds. Compared with the solution of copying the content of the image file byte by byte, the image cloning function provided by Liquid can greatly shorten the time for creating a new virtual machine image file and speed up the creation of a new virtual machine image.

Finally, the image file can be transmitted on demand through the network, which can reduce the content of the image file transmitted over the network to a minimum, and can effectively reduce the network load. Liquid supports copy-on-write (Copy-on-Write) technology to copy an image file block from other client nodes to the current client node, and then download the required image file block in real time according to the access of the virtual machine. This enables the client node to start the virtual machine before the image file is transferred to the local storage, which saves the waiting time for transferring the image file, thereby significantly shortening the time spent on starting the virtual machine.

Furthermore, since the data transferred over the network is limited to the parts that need to be accessed at startup, the amount of data transferred over the network is limited to a small value. Compared with the practice of downloading the entire image file and then starting the virtual machine, this saves waiting time and reduces network transmission overhead, which has great advantages.

Based on the same inventive concept as the method for storing a virtual machine image file, an embodiment of the present invention also provides a virtual machine image file storage device. Because the principle of these devices to solve the problem is similar to a method for storing virtual machine image files, the implementation of these devices can be referred to the implementation of the method, and the repetition will not be repeated.

FIG. 9 is a schematic diagram of a storage device for a virtual machine image file in an embodiment of the present invention. As shown in FIG. 9, the storage device for a virtual machine image file may include:

A segmentation unit 901, configured to segment the image file into fixed-length image file blocks;

The storage unit 902 is configured to store image file blocks.

During implementation, the division unit may be further used to divide the image file into fixed-length image file blocks by N times of 4KB, where N is a natural number.

During implementation, the splitting unit may be further used to split the image file into fixed-length image file blocks of 256 KB.

In implementation, the storage unit may be further used to store mirrored file blocks in a disk cluster boundary-aligned manner.

In implementation, the storage unit may be further used to de-redundant the stored image file blocks.

In implementation, it may further include:

The fingerprint feature unit is used to carry out MD5 fingerprint feature calculation to the image file block to determine the fingerprint feature of the image file block;

The storage unit can be further used to de-redundant the stored image file blocks according to the fingerprint features, and store the fingerprint features while storing the image file blocks.

In implementation, the fingerprint feature unit is used to run the image file after completing the storage of an application program or operating system image file, which may include:

The cache subunit is used to store image file blocks that need to be modified in different virtual machines in the first-level cache area, and store recently read read-only image file blocks in the second-level cache area;

The fingerprint characteristic sub-unit is used for carrying out MD5 fingerprint characteristic calculation to the image file block in the second-level cache area;

The determining subunit is used to determine the fingerprint feature of the image file block according to the fingerprint feature calculated by the fingerprint feature subunit.

In implementation, the cache subunit may be further configured to determine the image file blocks in the second cache area according to the least recently used algorithm (LRU).

In implementation, the storage unit can be further used to merge the image file blocks into a large data block BLK file for storage.

In implementation, the storage unit can be further used to store the mirrored file block according to the size of the BLK file, the free location, and the position offset corresponding to the fingerprint feature of the mirrored file block.

In implementation, the storage unit can be further used to record the used and/or unused positions of the BLK file by using the bitmap file bitmap.

In the virtual machine image file storage device provided in the embodiment of the present invention, by dividing the virtual machine image file into fixed-length image file blocks for storage, since the image file is divided into fixed-length blocks, a higher compression ratio is ensured. Therefore, the storage space of the virtual machine image file can be effectively saved.

Based on the same inventive concept as the virtual machine image file distribution method, an embodiment of the present invention also provides a virtual machine image file distribution device. Since the principle of these devices to solve the problem is similar to a method for distributing virtual machine image files, the implementation of these devices can be referred to the implementation of the method, and the repetition will not be repeated.

FIG. 10 is a schematic diagram of a virtual machine image file distribution device in an embodiment of the present invention. As shown in FIG. 10, the virtual machine image file distribution device may include:

A determining unit 1001, configured to determine the image file blocks that belong to the client node virtual machine;

A connection unit 1002, configured to establish connections with other client nodes based on the peer-to-peer network P2P protocol;

The distribution unit 1003 is configured to obtain the image file blocks from other client nodes when it is determined that the image file blocks required by the virtual machine of the client node exist in other client nodes, otherwise obtain the image file blocks from the data server block; or, when it is determined that there are image file blocks required by other client node virtual machines in the client node virtual machine, the image file block is sent to other client nodes, wherein the image file block is The virtual machine image file is obtained by dividing the image file according to a fixed length.

In implementation, the virtual machine image file distribution device may further include a cache unit, configured to store image file blocks obtained from other clients or data servers in the cache area.

In implementation, the cache unit is further configured to determine the image file blocks in the cache area according to the least recently used algorithm (LRU).

In implementation, the virtual machine image file distribution device can further include a fingerprint feature calculation unit, which can be used to calculate the MD5 fingerprint feature of the image file block;

The distribution unit can be further used to determine whether there are image file blocks required by the client node virtual machine in other client nodes according to the fingerprint characteristics, or to determine whether other client nodes exist in the client node virtual machine according to the fingerprint characteristics The image file blocks required by the virtual machine.

In implementation, the distribution unit can be further used to send the image file blocks required by the virtual machine of the client node to other client nodes when determining whether there are image file blocks required by the virtual machine of the client node according to the fingerprint feature. The fingerprint feature set of the image file block; the fingerprint feature set is used for other client nodes to determine whether there is an image file block required by the virtual machine of the client node based on the fingerprint feature set; or, when determining the client node based on the fingerprint feature When there are image file blocks required by other client node virtual machines in the end node virtual machine, receive the image file block fingerprint feature set required by the client node virtual machine sent by other client nodes; determine according to the fingerprint feature set Whether there are image file blocks required by this client node virtual machine.

In implementation, the distribution unit can be further used to perform Bloom Filter data structure compression on the image file block fingerprint feature set before sending the image file block fingerprint feature set required by the client node virtual machine to other client nodes deal with.

In implementation, the distribution unit may be further configured to compress the image file blocks with a compression algorithm whose compression speed is higher than the network bandwidth speed.

During implementation, the distribution unit can be further used to compress image file blocks using the Google Snappy compression algorithm.

The virtual machine image file distribution device provided in the embodiment of the present invention uses the P2P protocol to quickly clone and distribute image files between virtual machine clients, so all image file servers and client nodes can be used as image files. The provider of the file block exchanges the stored image file blocks with each other, effectively transfers the data transmission load of the image file server to the client node, balances the data transmission load, avoids the occurrence of network hotspots, and effectively shortens the copying of image files. The required waiting time and IO overhead improve the efficiency and speed of virtual machine image file distribution.

An example is used below to illustrate. In this example, the virtual machine image file storage solution and the virtual machine image file distribution solution provided in the embodiment of the present invention are adopted.

Figure 11 is a schematic diagram of the performance test results of the Bonnie++ system in the embodiment of the present invention, Figure 12 is a schematic diagram of the performance test results of the PostMark system in the embodiment of the present invention, and Figure 13 is a schematic diagram of the performance test results of the Linux virtual machine in the embodiment of the present invention, as shown in Figure 11 to As shown in Figure 13, in order to compare the performance of different mirrored storage systems and reflect the performance of the Liquid mirrored storage system more realistically, the embodiment of the present invention uses a virtual machine to perform performance test experiments on them, and the experimental environment is deployed on the Tsinghua virtual computing platform Nova system.

First of all, the test is to compare the IO performance of the virtual machine. The experiment uses two IO performance testing tools, Bonnie++ and PostMark, to compare the IO performance of Raw format, Qcow2 format stored in the local file system, and Raw image format files stored in Liquid. In this experiment, Liquid used image block sizes ranging from 16KB to 2MB. All virtual machine images are a newly created 50GB file using the ext4 file system. The virtual machine uses 2GB of memory and 1 vCPU, and the running operating system environment is Ubuntu 10.10 and Linux Kernel 2.6.35.

Please refer to the results shown in Figure 11 and Figure 12. From the test results, it can be seen that the Native IO of the local file system on the physical machine has the best performance. This is used as a benchmark against other image file storage solutions. The image file in Raw format has the best read and write performance, because its format is simple and will not bring too much performance overhead. For image files in Qcow2 format and image files stored in the Liquid system, since write operations frequently involve the allocation of new data blocks, their write performance is significantly affected. However, although Liquid also provides redundant support when writing data, its IO speed is still slightly faster than Qcow2, because it uses an excellent caching mechanism internally to ensure that write operations can be performed efficiently. Compared with writing operations, the speed of data reading is less affected, because the read data is actually cached by the operating system. A reasonable data block size will be able to use the cache more effectively, while a larger data block will result in a lower cache hit rate, and a smaller data block will cause additional performance overhead due to the need for frequent random IO operations .

As shown in Figure 13, for the test set of virtual machine startup speed, the Raw image format performed best, followed by the Qcow2 image file format. Virtual machine image files stored in Liquid are slightly slower to start, because the cache still has time to prepare and store commonly used data blocks to provide IO acceleration. Smaller image file blocks increase boot time because more random IO operations are performed during the virtual machine startup phase. In the test of decompression and compilation operation of Linux source code, the performance of Liquid is better than that of Qcow2 format. This is because the caching mechanism in Liquid ensures that recently frequently accessed image file blocks are cached in memory to ensure better IO performance. These two tests will generate a large number of small files. For a large number of image file blocks, Liquid does not directly write these image file blocks to disk, but temporarily places them in the cache, so that they can be written to the same file later. When mirroring file blocks, it is possible to do so quickly. When the cache is full, Liquid will centrally and batch-write the image files to the disk storage, which is better than fragmented small data IO performance.

Fig. 14 is a schematic diagram of the comparison of the time spent in transferring the virtual machine image file in the embodiment of the present invention. As shown in Fig. 14, in order to illustrate the speed of the method for distributing the virtual machine image file provided in the embodiment of the present invention, an 8GB image file is transferred from The time it takes for 1 client node to transmit to 7 other client nodes. The image file used for testing is a freshly installed Ubuntu 10.10, using a data block size of 256KB. From the test results, in these tests, it takes the most time to directly use the scp tool (Secure Copy, safe copy) to transfer the image file, because the source node of the image file itself has become a hotspot in the system, and the bandwidth of its network transmission It is saturated, and the encryption and decryption algorithm of the scp tool itself also brings a lot of performance loss. NFS storage also faces similar problems, but due to the optimization of its own implementation, the performance is better than scp. The BitTorrent protocol avoids the bottleneck of the image file source node by sharing the load of data transmission to all nodes, and its performance is far better than scp tools and NFS storage. However, the BitTorrent protocol itself does not take into account the redundant data in the mirror, so the duplicate data is still transmitted through the network. Liquid also uses the P2P transmission method, but it takes into account the existence of redundant data blocks and avoids transmitting duplicate data through the network, so it has achieved better performance than BitTorrent.

The performance of On-demand Fetching is measured by the speed of starting the virtual machine. As shown in Figure 15, compared to the traditional method of starting the virtual machine after downloading the image file, on-demand transmission can start the virtual machine before the image file is downloaded, and transmit the required image data blocks in real time. To meet the IO requirements of the virtual machine. It can be seen in the experiment that the start-up time required for on-demand transmission is longer than that of the traditional method. This is because an RPC (Remote Procedure Call Protocol, Remote Procedure Call Protocol) needs to be performed in real time each time a mirror file block is missing. ), download the corresponding image file block. This will bring longer latency than local IO. When the image file blocks become smaller, the number of missing data blocks on the local disk will increase, so more network IO operations will be required, resulting in longer startup time. But even with this time overhead, the overall time to start the virtual machine is shortened, so this actually speeds up the startup of the virtual machine. In addition, the embodiment of the present invention also tests the startup speed of the virtual machine, decompresses and compiles the source code of the Linux kernel, and other system performance tests. This test set includes both CPU-Intensive and IO-Intensive tests, which can effectively represent common virtual machine workloads. In this test, the Linux kernel source code used is 3.0.4.

For the convenience of description, each part of the above device is divided into various modules or units by function and described separately. Of course, when implementing the present invention, the functions of each module or unit can be implemented in one or more pieces of software or hardware.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

While preferred embodiments of the invention have been described, additional changes and modifications to these embodiments can be made by those skilled in the art once the basic inventive concept is appreciated. Therefore, it is intended that the appended claims be construed to cover the preferred embodiment as well as all changes and modifications which fall within the scope of the invention.

Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention also intends to include these modifications and variations.

Claims (34)

1. a virtual machine image file storage method, is characterized in that, comprises the steps: Divide the image file into fixed-length image file blocks; Store mirrored file blocks. 2. The method according to claim 1, wherein the fixed-length image file block size is N times 4KB, wherein N is a natural number. 3. The method according to claim 2, wherein the fixed-length image file block size is 256KB. 4. The method according to any one of claims 1 to 3, wherein when storing the image file blocks, they are aligned and stored according to disk cluster boundaries. 5. The method of claim 1, further comprising: Deredundancy is performed on stored image file blocks. 6. The method of claim 5, further comprising: Perform message digest algorithm fifth edition MD5 fingerprint feature calculation on the image file block to determine the fingerprint feature of the image file block; De-redundancy the stored image file blocks according to the fingerprint characteristics; While storing the image file block, its fingerprint feature is stored. 7. The method according to claim 1, characterized in that merging the image file blocks into a large data block BLK file and storing them. 8. The method of claim 7, comprising: Obtain the size of the BLK file, the free position and the position offset corresponding to the fingerprint feature of the image file block; The image file block is stored according to the size of the BLK file, the free location, and the position offset corresponding to the fingerprint feature of the image file block. 9. The method of claim 8, comprising: A bitmap file bitmap is used to record the used and/or unused positions of the BLK file. 10. A method for distributing virtual machine image files, comprising the steps of: Determine the image file blocks that belong to the virtual machine of the client node; Establish connections with other client nodes based on the peer-to-peer network P2P protocol; When it is determined that there are image file blocks required by the client node virtual machine in other client nodes, obtain the image file blocks from other client nodes, otherwise obtain the required image file blocks from the data server; or, in When it is determined that there are image file blocks required by other client node virtual machines in the client node virtual machine, the image file blocks are sent to other client nodes, wherein the image file blocks are virtual machine image files Obtained after dividing by fixed length. 11. The method according to claim 10, further comprising: storing the image file blocks obtained from other clients or data servers in a cache area. 12. The method according to claim 11, wherein storing the image file blocks obtained from other clients or data servers in the cache area comprises: determining the image file blocks in the cache area according to the least recently used algorithm (LRU). 13. The method of claim 10, further comprising: Calculate the MD5 fingerprint feature of the image file block; Determine whether there are image file blocks required by the virtual machine of this client node in other client nodes according to the fingerprint feature, or determine whether there is an image file required by the virtual machine of other client nodes in the virtual machine of the client node according to the fingerprint feature file blocks. 14. The method according to claim 13, wherein, according to the fingerprint feature, determining whether there are image file blocks required by the virtual machine of the client node in other client nodes comprises: sending the client node to other client nodes The image file block fingerprint feature set required by the node virtual machine; the fingerprint feature set is used for other client nodes to determine whether there is an image file block required by the client node virtual machine according to the fingerprint feature set; Or, determine whether there are image file blocks required by other client node virtual machines in the client node virtual machine according to the fingerprint feature, including: receiving image file blocks required by the client node virtual machine sent by other client nodes A fingerprint feature set; determine whether there is an image file block required by the client node virtual machine according to the fingerprint feature set. 15. The method according to claim 14, further comprising: compressing the image file block fingerprint feature set using a Bloom Filter data structure before transmission. 16. The method of claim 10, further comprising: The image file blocks are compressed with a compression algorithm whose compression speed is higher than the network bandwidth speed. 17. The method according to claim 16, comprising: The compression algorithm is the Google Snappy compression algorithm. 18. A virtual machine image file storage device, comprising: A split unit, used to split the image file into fixed-length image file blocks; The storage unit is used to store the image file blocks. 19. The device according to claim 18, wherein the division unit is further configured to divide the image file into fixed-length image file blocks by N times of 4KB, wherein N is a natural number. 20. The device according to claim 19, wherein the splitting unit is further configured to split the image file into 256KB fixed-length image file blocks. 21. The device according to any one of claims 18 to 20, wherein the storage unit is further configured to store mirrored file blocks in a disk cluster boundary-aligned manner. 22. The device according to claim 18, wherein the storage unit is further configured to perform de-redundancy on the stored image file blocks. 23. The apparatus of claim 22, further comprising: The fingerprint feature unit is used to carry out MD5 fingerprint feature calculation to the image file block to determine the fingerprint feature of the image file block; The storage unit is further used to de-redundant the stored image file blocks according to the fingerprint features, and store the fingerprint features while storing the image file blocks. 24. The device according to claim 18, wherein the storage unit is further configured to merge the image file blocks into a large data block BLK file for storage. 25. The device according to claim 24, wherein the storage unit is further configured to store the image file block according to the size of the BLK file, the free location, and the position offset corresponding to the fingerprint feature of the image file block. 26. The device according to claim 25, wherein the storage unit is further configured to use a bitmap file bitmap to record the used and/or unused positions of the BLK file. 27. A device for distributing virtual machine image files, comprising: A determination unit is used to determine the image file blocks that belong to the virtual machine of the client node; A connection unit, configured to establish connections with other client nodes based on a peer-to-peer network P2P protocol; A distribution unit, configured to obtain the image file blocks from other client nodes when it is determined that the image file blocks required by the virtual machine of the client node exist in other client nodes, otherwise obtain the image file blocks from the data server or, when it is determined that there are image file blocks required by other client node virtual machines in the client node virtual machine, the image file blocks are sent to other client nodes, wherein the image file blocks are virtual The machine image file is obtained by dividing the image file according to the fixed length. 28. The device according to claim 27, further comprising: a cache unit, configured to store image file blocks obtained from other clients or data servers in the cache area. 29. The device according to claim 28, wherein the cache unit is further configured to determine the image file blocks in the cache according to a least recently used algorithm (LRU). 30. The apparatus of claim 27, further comprising: A fingerprint feature calculation unit, configured to calculate the MD5 fingerprint feature of the image file block; The distribution unit is further used to determine whether there are image file blocks required by the client node virtual machine in other client nodes according to the fingerprint feature, or to determine whether there are other client node virtual machines in the client node virtual machine according to the fingerprint feature The desired image file blocks. 31. The device according to claim 30, wherein the distributing unit is further configured to send other clients The node sends the image file block fingerprint feature set required by the client node virtual machine; the fingerprint feature set is used for other client nodes to determine whether there is an image file block required by the client node virtual machine according to the fingerprint feature set; or , when determining whether there are image file blocks required by other client node virtual machines in the client node virtual machine according to the fingerprint characteristics, receiving the image file block fingerprints required by the client node virtual machine sent by other client nodes A feature set; determine whether there is an image file block required by the client node virtual machine according to the fingerprint feature set. 32. The device according to claim 31, wherein the distribution unit is further configured to, before sending the image file block fingerprint feature set required by the client node virtual machine to other client nodes, The fingerprint feature set is processed by Bloom Filter data structure compression. 33. The device according to claim 27, wherein the distribution unit is further configured to compress the image file block with a compression algorithm whose compression speed is higher than a network bandwidth speed. 34. The device according to claim 33, wherein the distributing unit is further configured to compress the image file block using the Google Snappy compression algorithm.