Method, device, electronic device and storage medium for creating encrypted system volume

Abstract

The present invention discloses a method, device, electronic device and storage medium for creating an encrypted system volume. The method includes: the Cinder platform reads the first system volume file of the first encrypted system volume in Ceph; removes the hole file from the read first system volume file to obtain the second system volume file; sends the second system volume file to the image management server, so that the image management server performs image processing on the second system volume file to obtain the third system volume file; reads the third system volume file from the image management server, and performs hole file recovery processing on the third system volume file to obtain the fourth system volume file; uses the fourth system volume file to create the second encrypted system volume in Ceph. The scheme provided by the present invention can reduce the creation time of the encrypted system volume and improve the creation rate of the encrypted system volume.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a method, device, electronic device and storage medium for creating an encrypted system volume. Background Art

[0002] OpenStack is an open source cloud computing management platform, which is composed of a series of open source tools (also called open source projects). OpenStack mainly uses pooled virtual resources to build and manage private and public clouds. Among them, open source projects include computing services (which can be called Nova), network services, storage services, identity services and image services. These five open source projects are mainly responsible for handling core cloud computing services. In addition, OpenStack also contains more than a dozen other optional projects, which users can bundle and package to create a unique and deployable cloud architecture.

[0003] Among them, the Cinder platform is responsible for the management of block storage resources in the OpenStack cloud environment. It supports all lifecycle activities of volumes and provides storage resources for end users of computing services. Ceph is a distributed file system that can provide excellent storage services in terms of performance, reliability and scalability. RBD is a block device in Ceph and is currently the most commonly used block storage type in cloud computing scenarios. OpenStack uses RBD in Ceph as the storage backend and manages the creation and deletion of volumes in RBD through the Cinder platform.

[0004] The Cinder platform will create an encrypted image based on the system volume of the encrypted volume virtual machine in the above image source, and create a new encrypted system volume based on the encrypted image. However, the process of creating a new encrypted system volume has the problems of low creation efficiency and slow creation speed. Therefore, in the related technology, the process of creating an encrypted system volume based on the encrypted image created by the system volume of the encrypted volume virtual machine needs to be optimized. Summary of the invention

[0005] To solve the related technical problems, an embodiment of the present invention provides a method, device, electronic device and storage medium for creating an encrypted system volume.

[0006] The technical solution of the embodiment of the present invention is achieved as follows:

[0007] An embodiment of the present invention provides a method for creating an encrypted system volume, which is applied to a Cinder platform. The method includes:

[0008] Read the first system volume file of the first encrypted system volume in Ceph;

[0009] Remove the hole file from the read first system volume file to obtain a second system volume file; send the second system volume file to the image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and the key corresponding to the first key identifier is the same as the key corresponding to the second key identifier in the first encrypted system volume;

[0010] Reading the third system volume file from the image management server, and performing hole file recovery processing on the third system volume file to obtain a fourth system volume file;

[0011] Using the fourth system volume file, a second encrypted system volume is created in Ceph; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume further includes a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier.

[0012] In the above solution, removing the empty file from the read first system volume file includes:

[0013] By calling the incremental backup command, the empty files are removed from the first system volume files.

[0014] In the above solution, the step of performing hole file recovery processing on the third system volume file includes:

[0015] By calling the recovery command, hole file recovery processing is performed on the third system volume file.

[0016] In the above solution, removing the empty file from the read first system volume file to obtain the second system volume file; and sending the second system volume file to the image management server includes:

[0017] Remove the empty file from the read first system volume file to obtain a second system volume file; and store the second system volume file in the storage node through the Cinder-Volume service;

[0018] The second system volume file is read from the storage node through the Cinder-Volume service, and the second system volume file is sent to the image management server.

[0019] In the above solution, the third system volume file is read from the image management server, and a hole file recovery process is performed on the third system volume file to obtain a fourth system volume file, including:

[0020] Reading the third system volume file from the image management server, and storing the third system volume file in the storage node through the Cinder-Volume service;

[0021] The third system volume file is read from the storage node through the Cinder-Volume service, and a hole file recovery process is performed on the third system volume file to obtain a fourth system volume file.

[0022] In the above scheme, the method further includes:

[0023] The second encrypted system volume is cloned to create an encrypted cache; wherein the encrypted cache further stores a fourth key identifier, and a key corresponding to the fourth key identifier is the same as a key corresponding to the third key identifier.

[0024] In the above scheme, the method further includes:

[0025] The encrypted cache is cloned to create a third encrypted system volume; wherein the third encrypted system volume further stores a fifth key identifier, and the key corresponding to the fifth key identifier is the same as the key corresponding to the third key identifier.

[0026] The embodiment of the present invention further provides a device for creating an encrypted system volume, which is applied to a Cinder platform, and the device includes:

[0027] A reading module, used for reading a first system volume file of a first encrypted system volume in Ceph;

[0028] a removal module, configured to remove the hole file from the read first system volume file to obtain a second system volume file; and send the second system volume file to the image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and a key corresponding to the first key identifier is the same as a key corresponding to the second key identifier in the first encrypted system volume;

[0029] A recovery module, used for reading the third system volume file from the image management server, and performing a hole file recovery process on the third system volume file to obtain a fourth system volume file;

[0030] A creation module is used to create a second encrypted system volume in Ceph using the fourth system volume file; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume also includes a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier.

[0031] An embodiment of the present invention further provides an electronic device, comprising: a processor and a memory for storing a computer program that can be run on the processor; wherein:

[0032] The processor is used to execute the steps of any of the above methods when running the computer program.

[0033] An embodiment of the present invention further provides a storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0034] The invention provides a method, device, electronic device and storage medium for creating an encrypted system volume; a Cinder platform reads a first system volume file of a first encrypted system volume in Ceph; removes hole files from the read first system volume file to obtain a second system volume file; sends the second system volume file to an image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and the key corresponding to the first key identifier is the same as the key corresponding to the second key identifier in the first encrypted system volume; reads the third system volume file from the image management server, and performs hole file recovery processing on the third system volume file to obtain a fourth system volume file; creates a second encrypted system volume in Ceph using the fourth system volume file; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume also contains a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier. According to the solution of the embodiment of the present invention, in the process of creating an encrypted system volume based on the encrypted image created by the system volume of the encrypted volume virtual machine, before the system volume file is transmitted to the image management server, the empty files in the system volume file are first removed; at the same time, after the system volume file is obtained from the image management server, the system volume file after the empty files are removed is subjected to the empty file recovery process. In the process of transmitting the system volume file, the empty files are removed, so the amount of data transmission is reduced, thus improving the data transmission efficiency, thereby accelerating the creation rate of the encrypted system volume and shortening the creation time of the encrypted system volume. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 A schematic diagram of a process for creating an encrypted system volume in the related art;

[0036] Figure 2 A schematic diagram of a process for creating an encrypted system volume according to an embodiment of the present invention;

[0037] Figure 3 A schematic diagram of a process for creating an encrypted system volume according to an application embodiment of the present invention;

[0038] Figure 4 This is a schematic diagram of the encrypted cache creation process according to an application embodiment of the present invention;

[0039] Figure 5 A schematic diagram of the structure of a device for creating an encrypted system volume according to an embodiment of the present invention;

[0040] Figure 6 The figure is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0041] The present invention will be described in further detail below with reference to the accompanying drawings and embodiments.

[0042] The Cinder platform is responsible for the management of block storage resources in the OpenStack cloud environment. It supports all lifecycle activities of volumes and provides storage resources to users. By connecting with the Cinder platform, RBD in Ceph provides stable, reliable, and highly available block services for the OpenStack cloud environment. OpenStack uses RBD in Ceph as the storage backend and manages the creation and deletion of volumes in RBD through the Cinder platform.

[0043] When providing services, the Cinder platform architecture includes the following parts: Cinder-Api, Cinder-Scheduler and Cinder-Volume. Among them, Cinder-Api is responsible for providing REST interfaces to the outside; Cinder-Scheduler is responsible for allocating storage resources; Cinder-Volume is responsible for encapsulating various drivers, and different drivers are responsible for controlling different storage backends.

[0044] When creating a system volume, the Cinder platform can create a system volume in RBD based on the image. The sources of the image mainly include:

[0045] 1. Public cloud-based non-encrypted images or non-encrypted images uploaded by users.

[0046] 2. An encrypted image created based on the encrypted system volume of an existing encrypted volume virtual machine.

[0047] That is to say, the image sources of the system volume in RBD include public cloud-based non-encrypted images or non-encrypted images uploaded by users themselves, as well as encrypted images created through the system volume of the encrypted volume virtual machine.

[0048] Next, combine Figure 1 , describes the process of creating an encrypted image based on the encrypted system volume of an existing encrypted volume virtual machine. The process of creating an encrypted image mainly includes the following steps:

[0049] Step 1: The image management server (also known as the image management service platform, referred to as Glance in English) that provides image services creates an empty image, and the empty image stores image metadata;

[0050] Step 2: OpenStack calls the interface of the Cinder platform (which can be called the block storage management service platform or the block storage management server) and saves the system volume data of the encrypted system volume of the existing encrypted volume virtual machine in the storage node (the node running the Cinder-Volume service, which can be called the Cinder-Volume node) through the export command (which can be expressed as ceph rbd export in English).

[0051] Step 3: OpenStack calls the interface of the image management server to upload the local system volume file (i.e., the system volume data stored in the storage node in step 2) to the backend storage of the image management server in blocks; at the same time, in the key management server (which can be called the key management service platform, which can be expressed as Barbican in English), the encryption key of the encrypted system volume corresponding to the key UUID is copied through the key identifier corresponding to the encrypted system volume of the existing encrypted volume virtual machine (i.e., the universal unique identifier (UUID) of the key), so as to obtain a new encrypted system volume encryption key, and the new encrypted system volume encryption key is still stored in the key management server, and the key UUID corresponding to the new encryption key is saved in the image metadata of the empty image created in the above step 1.

[0052] Through the above steps, the creation of the encrypted image is completed.

[0053] Next, continue to combine Figure 1 , describes the process of creating an encrypted system volume based on the created encrypted image. The process of creating an encrypted system volume based on the created encrypted image includes the following steps:

[0054] Step 1: The Cinder platform calls the interface of the image management server to obtain the key UUID saved in the image metadata, and based on the key UUID, copies the encryption key of the encrypted system volume corresponding to the key UUID in the key management server, obtains the encryption key of the new encrypted system volume, and obtains the new key UUID corresponding to the new encryption key, creates an empty encrypted system volume based on the new key UUID, and saves the new key UUID in the empty encrypted system volume.

[0055] Step 2: The Cinder platform calls the image management server interface again to download the full image data from the backend storage of the image management server (which can be understood as the system volume file uploaded to the backend storage of the image management server in blocks) to the storage node to generate a temporary image file.

[0056] Step 3: The Cinder platform uses the import command (which can be expressed as ceph rbd import in English) to store the temporary image file in step 2 above into the RBD storage pool to complete the creation of the encrypted system volume.

[0057] Since the system volume file contains empty files, in the above process, when using ceph rbd export and cephrbd import to export and import the system volume data, the system volume data containing empty files (which can be understood as files with no practical use) are exported and imported in full. Exemplarily, the existing encrypted system volume is 40G, of which the actual system files only occupy 5G, and the remaining 35G are empty files. Then, based on the existing encrypted system volume, when creating a 40G encrypted system volume, in the process of creating the image, it is necessary to first download the full 40G file from the Ceph storage cluster (i.e., the RBD storage pool) to the storage node, and then upload the 40G file to the storage backend of the image management server; and, when creating an encrypted system volume through the image, it is necessary to download the 40G file to the storage node again, and then upload the 40G file to the Ceph storage cluster. Therefore, in the related art, the creation process of the above-mentioned encrypted system volume has the following problems:

[0058] 1) There are 35GB of empty files in the 40GB. These files have no practical significance, but they take up a lot of data upload and download time. This leads to slow image creation and slow system volume creation (which can also be understood as distribution).

[0059] 2) The cache space of the storage node is limited. On the one hand, using full data will increase the cache space demand of the storage node. In addition, since it is full data, the data upload and / or download time will be slow, which will cause the storage node to release the cache space after uploading or downloading the data. The cache space release speed will also be slowed down accordingly. Therefore, in high concurrency situations (such as creating multiple system volumes in parallel), various factors will lead to insufficient cache space of the storage node, resulting in a high failure rate in creating encrypted system volumes.

[0060] Based on this, the embodiment of the present invention proposes that during the creation of an encrypted system volume, the empty files in the encrypted system volume are removed to generate an encrypted system volume image file, and then the encrypted system volume image file is uploaded to the Glance image in blocks to create a custom encrypted system volume image. At the same time, when the encrypted system volume custom image is used to create an encrypted system volume, the encrypted system volume image file is uploaded to the RBD storage pool. In this way, the speed of issuing the encrypted system volume is improved and the creation time of the encrypted system volume is reduced.

[0061] The embodiment of the present invention provides a method for creating an encrypted system volume, which is applied to the OpenStack cloud computing platform, and is specifically applied to the Cinder platform. Figure 2 As shown, the method includes:

[0062] Step 201: The Cinder platform reads the first system volume file of the first encrypted system volume in Ceph;

[0063] Step 202: the Cinder platform removes the empty files from the read first system volume file to obtain a second system volume file; sends the second system volume file to the image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and the key corresponding to the first key identifier is the same as the key corresponding to the second key identifier in the first encrypted system volume;

[0064] Step 203: the Cinder platform reads the third system volume file from the image management server, and performs a hole file recovery process on the third system volume file to obtain a fourth system volume file;

[0065] Step 204: The Cinder platform uses the fourth system volume file to create a second encrypted system volume in Ceph; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume further includes a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier.

[0066] In actual application, the Cinder platform is a storage platform in the OpenStack cloud computing platform, which is used to provide stable data block storage services for running instances in the OpenStack cloud computing platform. The plug-in driver architecture of the Cinder platform is conducive to the creation and management of block devices, such as creating volumes, deleting volumes, mounting and unmounting volumes on instances, etc.

[0067] In actual application, the image management server is an image management service platform in the OpenStack cloud computing platform, including a virtual machine image search and retrieval system that can support multiple virtual machine image formats (such as AKI, AMI, ARI, ISO, QCOW2, Raw, VDI, VHD and VMDK), and has the functions of creating and uploading images, deleting images, and editing basic image information.

[0068] In actual application, Ceph is a unified, distributed file system designed for excellent performance, reliability and scalability, which can provide persistent block storage devices for physical machines and virtual machines.

[0069] In one embodiment, the Cinder platform can remove the empty files from the first system volume file by calling the incremental backup command (which can be expressed as ceph rbd export-diff in English). Here, the incremental backup command is an existing command in Ceph, and the command can be directly called by Ceph. Exemplarily, the incremental backup command can be rbdexport-diff --pool volumes volume.name / var / lib / cinder / conversion / volume.name.

[0070] Correspondingly, the Cinder platform can perform hole file recovery processing on the third system volume file by calling the recovery command (which can be expressed in English as ceph rbdimport-diff). Here, the recovery command is also an existing command in Ceph, and the command can be directly called through Ceph. Exemplarily, the recovery command can be rbd import-diff--pool volumes--path / var / lib / cinder / conversion / tmpy9Mxy5--imagevolume.name.

[0071] In actual application, all tasks of the Cinder platform need to be executed through the Cinder-Volume service. Therefore, the Cinder platform can send the second system volume file to the image management server through the Cinder-Volume service.

[0072] Based on this, in one embodiment, the Cinder platform removes the empty file from the read first system volume file to obtain the second system volume file; and sends the second system volume file to the image management server, including:

[0073] The Cinder platform removes the empty file from the read first system volume file to obtain a second system volume file; and stores the second system volume file to the storage node through the Cinder-Volume service;

[0074] The Cinder platform reads the second system volume file from the storage node through the Cinder-Volume service, and sends the second system volume file to the image management server.

[0075] In actual application, the storage node is a physical machine node running the Cinder-Volume service.

[0076] After the image management server performs image processing on the second system volume file to obtain the third system volume file, the image management server will also store the third system volume file.

[0077] Accordingly, in actual application, the Cinder platform can obtain the fourth system volume file from the image management server through the Cinder-Volume service.

[0078] Based on this, in one embodiment, the third system volume file is read from the image management server, and the third system volume file is processed for hole file recovery to obtain the fourth system volume file, including:

[0079] The Cinder platform reads the third system volume file from the image management server, and stores the third system volume file to the storage node through the Cinder-Volume service;

[0080] The Cinder platform reads the third system volume file from the storage node through the Cinder-Volume service, and performs hole file recovery processing on the third system volume file to obtain a fourth system volume file.

[0081] In actual application, the key management server will store the encryption key corresponding to each encrypted system volume, and the key identifier of each encryption key will be stored in the corresponding encrypted system volume. Therefore, when creating a second encrypted system volume based on the first encrypted system volume, you can copy an encryption key based on the encryption key of the first encrypted system volume, and store the key identifier of the new encryption key in the second encrypted system volume.

[0082] Specifically, in one embodiment, copying a new encryption key according to the encryption key of the first encryption system volume, and storing the key identifier of the new encryption key in the second encryption system volume includes:

[0083] Acquire a second key identifier from the first encryption system volume, where the second key identifier represents a key identifier of an encryption key corresponding to the first encryption system volume;

[0084] Sending the second key identifier to the image management server; so that the image management server copies the encryption key corresponding to the first encryption system volume in the key management server according to the second key identifier, obtains the copied first key and the first key identifier corresponding to the copied first key; and stores the obtained first key identifier;

[0085] Obtaining a first key identifier from the image management server;

[0086] The copied first key is copied in the key management server according to the first key identifier, the copied second key and the third key identifier corresponding to the copied second key are obtained; and the third key identifier is stored in the second encryption system volume.

[0087] In actual application, an encrypted cache can be created in the RBD storage pool in Ceph based on the already created second encrypted system volume, and the encrypted cache can be used to conveniently create new encrypted system volumes.

[0088] Based on this, in one embodiment, creating an encrypted cache based on the second encrypted system volume includes:

[0089] The Cinder platform clones the second encrypted system volume to create an encrypted cache; wherein the encrypted cache also stores a fourth key identifier, and a key corresponding to the fourth key identifier is the same as a key corresponding to the third key identifier.

[0090] Here, since an encrypted cache is created in the RBD storage pool in Ceph, the method of creating the encrypted cache (i.e., creating an encrypted cache based on the second encrypted system volume) is different from the method of creating an encrypted system volume in the above steps 201 to 204 (which can be understood as the method of generating an encrypted image on the image management server).

[0091] Correspondingly, based on the created encryption cache, a third encrypted system volume is created, including:

[0092] The Cinder platform clones the encrypted cache to create a third encrypted system volume; wherein the third encrypted system volume also stores a fifth key identifier, and the key corresponding to the fifth key identifier is the same as the key corresponding to the third key identifier.

[0093] In actual application, obtaining the fourth key identifier includes:

[0094] Based on the second encryption system volume, obtaining a third key identifier in the second encryption system volume;

[0095] According to the third key identifier, the second key corresponding to the third key identifier is copied in the key management server to obtain the copied third key and the fourth key identifier corresponding to the copied third key; and the fourth key identifier is stored in the encryption cache.

[0096] In actual application, obtaining the fifth key identifier includes:

[0097] Based on the encryption cache, obtaining a fourth key identifier in the encryption cache;

[0098] According to the fourth key identifier, the third key corresponding to the fourth key identifier is copied in the key management server to obtain the copied fourth key and the fifth key identifier corresponding to the copied fourth key; and the fifth key identifier is stored in the third encryption system volume.

[0099] A new encrypted system volume is created in Ceph through the encrypted cache. Since the encrypted cache is stored in Ceph, each time a new encrypted system volume is created, the corresponding files can be directly obtained from the encrypted cache in Ceph without importing and exporting the corresponding files from the image management server. Therefore, the efficiency of creating the encrypted system volume is further improved and the creation time of the encrypted system volume is further shortened.

[0100] The method for creating an encrypted system volume provided by an embodiment of the present invention is as follows: a Cinder platform reads a first system volume file of a first encrypted system volume in Ceph; removes hole files from the read first system volume file to obtain a second system volume file; sends the second system volume file to an image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and the key corresponding to the first key identifier is the same as the key corresponding to the second key identifier in the first encrypted system volume; reads the third system volume file from the image management server, and performs hole file recovery processing on the third system volume file to obtain a fourth system volume file; uses the fourth system volume file to create a second encrypted system volume in Ceph; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume also contains a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier. According to the solution of the embodiment of the present invention, in the process of creating an encrypted system volume based on the encrypted image created by the system volume of the encrypted volume virtual machine, before the system volume file is transmitted to the image management server, the empty files in the system volume file are first removed; at the same time, after the system volume file is obtained from the image management server, the system volume file after the empty files are removed is subjected to the empty file recovery process. In the process of transmitting the system volume file, the empty files are removed, so the amount of data transmission is reduced, thus improving the data transmission efficiency, thereby accelerating the creation rate of the encrypted system volume and shortening the creation time of the encrypted system volume.

[0101] The present invention is further described in detail below in conjunction with application examples.

[0102] This application embodiment provides a method for improving the efficiency of issuing encrypted system volumes. The method mainly includes the following two parts:

[0103] 1) Create an encrypted custom image through the encrypted system volume of the encrypted volume virtual machine in Ceph's RBD;

[0104] 2) Create an encrypted system volume in Ceph's RBD by encrypting the custom image.

[0105] Combine the following Figure 3 The above two parts are explained. The process of creating an encrypted custom image through the encrypted system volume of the encrypted volume virtual machine in the RBD of Ceph includes the following steps:

[0106] Step 1: The image service management end creates an empty image, and the empty image stores image metadata;

[0107] Step 2: OpenStack calls the Cinder platform interface, removes the empty files of the encrypted system volume in RBD through the ceph rbd export-diff command, generates a system volume image file, and saves the system volume image file in the storage node;

[0108] Step 3: OpenStack calls the image service management interface to divide the local system volume file (i.e., the system volume image file stored in the storage node in step 2 above) into multiple blocks according to the set file size (e.g., 70M) and upload them to the backend storage of the image service management end; at the same time, the encrypted system volume key corresponding to the key UUID of the encrypted system volume of the existing encrypted volume virtual machine is copied in the key management server to obtain a new encrypted system volume key, and a new key UUID corresponding to the new encrypted system volume key is obtained, and the new key UUID is saved in the image metadata of the empty image created in step 1.

[0109] Through the above steps, the creation of an encrypted custom image is completed.

[0110] Next, continue to combine Figure 3 , describes the process of creating an encrypted system volume in Ceph's RBD by encrypting a custom image. The process of creating an encrypted system volume in Ceph's RBD by encrypting a custom image includes the following steps:

[0111] Step 1: The Cinder platform calls the interface of the image service management end to obtain the key UUID saved in the image metadata; based on the obtained key UUID, the encrypted system volume key corresponding to the key UUID is copied in the key service management end to obtain a new encrypted system volume key, and obtain a new key UUID corresponding to the new encrypted system volume key, create an empty encrypted system volume based on the new key UUID, and save the new key UUID in the empty encrypted system volume;

[0112] Step 2: The Cinder platform calls the interface of the image service management end again to download the image data (that is, the system volume image file created above and stored in the backend storage of the image service management end) from the backend storage of the image service management end to the storage node, and generates a temporary image file;

[0113] Step 3: The Cinder platform uses the ceph rbd import-diff command to restore the temporary image file in step 2 above, stores the restored image file in the RBD storage pool, and completes the creation of the encrypted system volume.

[0114] In the above process, when the encrypted system volume data is exported and imported, ceph rbd export-diff is used to remove the empty files of the encrypted system volume, generate the RBD system volume image file, and then upload it to the image of the image service management end in blocks to make a custom image of the encrypted system volume; and when the custom image is used to create the encrypted system volume, ceph rbdimport-diff is used to recover the empty files of the image file, and then it is stored in the RBD storage pool, that is, the exported and imported data is the non-full data with the empty files in the ceph block removed. In this way, not only the encrypted image creation speed and system volume delivery efficiency are improved, but also the cache space pressure of the storage node is reduced, thereby reducing the system volume creation failure rate caused by insufficient cache space of the storage node in high concurrency.

[0115] In addition, based on the creation of the above-mentioned encrypted system volume, this application embodiment also provides a cache method for creating an encrypted custom image, such as Figure 4 As shown, the following steps are included:

[0116] Step 1: The Cinder platform copies a key for encrypting the system volume in the key service management terminal, obtains the key UUID of the key, and saves the key UUID in the metadata of the encryption cache;

[0117] In this way, the encryption attribute of the encrypted cache is consistent with the encryption attribute of the encrypted system volume, and the key of the encrypted cache is unique.

[0118] Step 2: The Cinder platform clones the data in the encrypted system volume in Ceph and generates an encrypted cache. The data in the encrypted cache is consistent with the data in the encrypted system volume.

[0119] Through the above steps, the encrypted cache of the encrypted custom image is completed. To use the encrypted image again to create an encrypted system volume, you do not need to download the image again, just clone the encrypted cache. Specifically, the process of creating an encrypted system volume based on the encrypted cache is as follows:

[0120] Step 1: Cinder copies a key of the encrypted cache in the key service management terminal, obtains the key UUID of the copied key, and saves the key UUID in the metadata of the encrypted system volume;

[0121] Step 2: Cinder clones the encrypted cache in Ceph and creates an encrypted system volume.

[0122] From the above description, it can be seen that the solution provided by the embodiment of the present invention supports the encrypted system volume cache technology. By creating an encrypted system volume through the encrypted cache, there is no need to download and import the image data every time. Compared with the method of creating an encrypted system volume based on an encrypted image, the traditional encrypted system volume creation process is improved and the encrypted system volume creation time is shortened. At the same time, it can also reduce the cache space pressure of the storage node and reduce the failure rate of creating the system volume under high concurrency.

[0123] In order to implement the method of the embodiment of the present invention, the embodiment of the present invention also provides a device for creating an encrypted system volume, which is applied to the Cinder platform, such as Figure 5 As shown, the device 500 for creating an encrypted system volume includes: a reading module 501, a removal module 502, a recovery module 503 and a creation module 504; wherein,

[0124] The reading module 501 is used to read the first system volume file of the first encrypted system volume in Ceph;

[0125] The removal module 502 is used to remove the hole file from the read first system volume file to obtain a second system volume file; send the second system volume file to the image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and the key corresponding to the first key identifier is the same as the key corresponding to the second key identifier in the first encrypted system volume;

[0126] The recovery module 503 is used to read the third system volume file from the image management server, and perform hole file recovery processing on the third system volume file to obtain a fourth system volume file;

[0127] The creation module 504 is used to create a second encrypted system volume in Ceph using the fourth system volume file; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume further includes a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier.

[0128] In one embodiment, the removal module 502 is further configured to:

[0129] By calling the incremental backup command, the empty files are removed from the first system volume files.

[0130] In one embodiment, the recovery module 503 is further used to:

[0131] By calling the recovery command, hole file recovery processing is performed on the third system volume file.

[0132] In one embodiment, the removal module 502 is further configured to:

[0133] Remove the empty file from the read first system volume file to obtain a second system volume file; and store the second system volume file in the storage node through the Cinder-Volume service;

[0134] The second system volume file is read from the storage node through the Cinder-Volume service, and the second system volume file is sent to the image management server.

[0135] In one embodiment, the recovery module 503 is further used to:

[0136] Reading a third system volume file from the image management server, and storing the third system volume file in a storage node through a Cinder-Volume service;

[0137] The third system volume file is read from the storage node through the Cinder-Volume service, and a hole file recovery process is performed on the third system volume file to obtain a fourth system volume file.

[0138] In one embodiment, the creation module 504 is further used to:

[0139] The second encrypted system volume is cloned to create an encrypted cache; wherein the encrypted cache further stores a fourth key identifier, and a key corresponding to the fourth key identifier is the same as a key corresponding to the third key identifier.

[0140] In one embodiment, the creation module 504 is further used to:

[0141] The platform clones the encryption cache to create a third encryption system volume; wherein the third encryption system volume also stores a fifth key identifier, and the key corresponding to the fifth key identifier is the same as the key corresponding to the third key identifier.

[0142] In actual application, the reading module 501, the removing module 502, the restoring module 503 and the creating module 504 may be implemented by a processor in the device for creating the encrypted system volume.

[0143] It should be noted that: the device for creating an encrypted system volume provided in the above embodiment only uses the division of the above program modules as an example to illustrate when creating an encrypted system volume. In actual application, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device is divided into different program modules to complete all or part of the above-described processing. In addition, the device for creating an encrypted system volume provided in the above embodiment and the method for creating an encrypted system volume are of the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0144] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiment of the present invention, the embodiment of the present invention also provides an electronic device, which is applied to the Cinder platform, such as Figure 6 As shown, the electronic device 600 includes:

[0145] Communication interface 601, capable of exchanging information with other devices (such as network devices, terminals, etc.);

[0146] A processor 602, connected to the communication interface 601 to implement information interaction with other devices, and used to execute the method provided by one or more of the above technical solutions when running a computer program;

[0147] The memory 603 is used to store computer programs that can be run on the processor 602 .

[0148] Specifically, the processor 602 is configured to perform the following operations:

[0149] Read the first system volume file of the first encrypted system volume in Ceph;

[0150] Remove the hole file from the read first system volume file to obtain a second system volume file; send the second system volume file to the image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and the key corresponding to the first key identifier is the same as the key corresponding to the second key identifier in the first encrypted system volume;

[0151] Reading the third system volume file from the image management server, and performing hole file recovery processing on the third system volume file to obtain a fourth system volume file;

[0152] Using the fourth system volume file, a second encrypted system volume is created in Ceph; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume further includes a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier.

[0153] In one embodiment, the processor 602 is further configured to perform the following operations:

[0154] By calling the incremental backup command, the empty files are removed from the first system volume files.

[0155] In one embodiment, the processor 602 is further configured to perform the following operations:

[0156] By calling the recovery command, hole file recovery processing is performed on the third system volume file.

[0157] In one embodiment, the processor 602 is further configured to perform the following operations:

[0158] Remove the empty file from the read first system volume file to obtain a second system volume file; and store the second system volume file in the storage node through the Cinder-Volume service;

[0159] The second system volume file is read from the storage node through the Cinder-Volume service, and the second system volume file is sent to the image management server.

[0160] In one embodiment, the processor 602 is further configured to perform the following operations:

[0161] Reading a third system volume file from the image management server, and storing the third system volume file in a storage node through a Cinder-Volume service;

[0162] The third system volume file is read from the storage node through the Cinder-Volume service, and a hole file recovery process is performed on the third system volume file to obtain a fourth system volume file.

[0163] In one embodiment, the processor 602 is further configured to perform the following operations:

[0164] The second encrypted system volume is cloned to create an encrypted cache; wherein the encrypted cache further stores a fourth key identifier, and a key corresponding to the fourth key identifier is the same as a key corresponding to the third key identifier.

[0165] In one embodiment, the processor 602 is further configured to perform the following operations:

[0166] The encrypted cache is cloned to create a third encrypted system volume; wherein the third encrypted system volume further stores a fifth key identifier, and the key corresponding to the fifth key identifier is the same as the key corresponding to the third key identifier.

[0167] It should be noted that: the specific process of the processor 602 performing the above operations is detailed in the method embodiment, which will not be repeated here.

[0168] Of course, in actual application, the various components in the electronic device 600 are coupled together through the bus system 604. It can be understood that the bus system 604 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 604 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Figure 6 Various buses are labeled as bus system 604 .

[0169] The memory 603 in the embodiment of the present invention is used to store various types of data to support the operation of the electronic device 600. Examples of such data include: any computer program used to operate on the electronic device 600.

[0170] The method disclosed in the above embodiment of the present invention can be applied to the processor 602, or implemented by the processor 602. The processor 602 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 602 or the instruction in the form of software. The above processor 602 may be a general processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 602 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiment of the present invention. The general processor may be a microprocessor or any conventional processor, etc. In combination with the steps of the method disclosed in the embodiment of the present invention, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in the memory 603. The processor 602 reads the information in the memory 603 and completes the steps of the above method in combination with its hardware.

[0171] In an exemplary embodiment, the electronic device 600 can be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD), field programmable gate array (FPGA), general processor, controller, microcontroller (MCU), microprocessor, or other electronic components to execute the aforementioned method.

[0172] It can be understood that the memory 603 of the embodiment of the present invention can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM, SyncLink Dynamic Random Access Memory), and direct RAMbus random access memory (DRRAM, Direct Rambus Random Access Memory).The memories described in the embodiments of the present invention are intended to include, but are not limited to, these and any other suitable types of memories.

[0173] In an exemplary embodiment, the embodiment of the present invention further provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, for example, including a memory 603 storing a computer program, and the computer program can be executed by a processor 602 of an electronic device 600 to complete the steps of the aforementioned method. The computer-readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface storage, optical disk, or CD-ROM.

[0174] It should be noted that: "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0175] In addition, the technical solutions described in the embodiments of the present invention can be arbitrarily combined without conflict.

[0176] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention.

Claims

1. A method for creating an encrypted system volume, characterized in that: Applied to the Cinder platform, the method includes: Read the first system volume file of the first encrypted system volume in Ceph; Remove the empty file from the read first system volume file to obtain the second system volume file; sending the second system volume file to the image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and a key corresponding to the first key identifier is the same as a key corresponding to the second key identifier in the first encrypted system volume; Reading the third system volume file from the image management server, and performing hole file recovery processing on the third system volume file to obtain a fourth system volume file; Using the fourth system volume file, a second encrypted system volume is created in Ceph; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume further includes a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier.

2. The method according to claim 1, characterized in that The removing of the hole file from the read first system volume file comprises: By calling the incremental backup command, the empty files are removed from the first system volume files.

3. The method according to claim 1, characterized in that The performing hole file recovery processing on the third system volume file includes: By calling the recovery command, hole file recovery processing is performed on the third system volume file.

4. The method according to claim 1, characterized in that: Remove the empty file from the read first system volume file to obtain the second system volume file; and sending the second system volume file to the image management server, including: Remove the empty file from the read first system volume file to obtain the second system volume file; and storing the second system volume file in the storage node through the Cinder-Volume service; The second system volume file is read from the storage node through the Cinder-Volume service, and the second system volume file is sent to the image management server.

5. The method according to claim 1, characterized in that: The step of reading the third system volume file from the image management server and performing hole file recovery processing on the third system volume file to obtain a fourth system volume file includes: Reading the third system volume file from the image management server, and storing the third system volume file in the storage node through the Cinder-Volume service; The third system volume file is read from the storage node through the Cinder-Volume service, and a hole file recovery process is performed on the third system volume file to obtain a fourth system volume file.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The second encrypted system volume is cloned to create an encrypted cache; wherein the encrypted cache further stores a fourth key identifier, and a key corresponding to the fourth key identifier is the same as a key corresponding to the third key identifier.

7. The method according to claim 6, characterized in that The method further comprises: The encrypted cache is cloned to create a third encrypted system volume; wherein the third encrypted system volume further stores a fifth key identifier, and the key corresponding to the fifth key identifier is the same as the key corresponding to the third key identifier.

8. A device for creating an encrypted system volume, characterized in that: Applied to the Cinder platform, the device includes: A reading module, used for reading a first system volume file of a first encrypted system volume in Ceph; a removal module, configured to remove the hole file from the read first system volume file to obtain a second system volume file; and send the second system volume file to the image management server, so that the image management server performs image processing on the second system volume file to obtain a third system volume file; wherein the image management server also stores a first key identifier, and a key corresponding to the first key identifier is the same as a key corresponding to the second key identifier in the first encrypted system volume; A recovery module, used for reading the third system volume file from the image management server, and performing a hole file recovery process on the third system volume file to obtain a fourth system volume file; A creation module is used to create a second encrypted system volume in Ceph using the fourth system volume file; wherein the fourth system volume file is the same as the first system volume file, and the second encrypted system volume also includes a third key identifier, and the key corresponding to the third key identifier is the same as the key corresponding to the first key identifier.

9. An electronic device, characterized in that: include: A processor and a memory for storing a computer program capable of running on the processor; wherein, When the processor is used to run the computer program, the steps of the method according to any one of claims 1 to 7 are performed.

10. A storage medium storing a computer program, wherein: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images