Volume creation method of Openstack cloud platform based on mimicry defense

Abstract

The present invention provides a volume creation method for an Openstack cloud platform based on mimetic defense, and relates to the field of storage technology. By placing parameter verification and calculation, volume creation information acquisition, and synchronous calling of a cinder-api component in the volume creation process within a mimetic protection zone, and placing other processes in the volume creation process, such as writing data to a database and creating a target volume, outside the mimetic protection zone, the entire volume creation process has good mimetic security performance while minimizing costs, simplifying the complexity of the volume creation process, and resolving the prior art defect that the volume creation process in the Openstack cloud platform is time-consuming after the mimetic defense technology is integrated into the Openstack cloud platform. This method achieves the purpose of shortening the volume creation process time and improving volume creation efficiency when the mimetic defense technology is integrated into the Openstack cloud platform, thereby significantly improving the stability and efficiency of the volume creation process.

Description

Technical Field

[0001] The present invention relates to the field of storage technology, and in particular to a volume creation method for an Openstack cloud platform based on mimicry defense. Background Art

[0002] Currently, multiple mimicry protection zones can be set up in the Openstack cloud platform based on mimicry defense technology. Figure 1 As shown, the area outlined by the dashed box is the mimetic protection zone. Each mimetic protection zone is equipped with a mimetic defense architecture, which includes a user-side proxy unit, multiple heterogeneous executors, and a business-side proxy unit. Data is input from the user-side proxy unit, computed and processed by multiple heterogeneous executors, and then output to the business-side proxy unit for adjudication. The business-side proxy unit then outputs the adjudication result. Establishing multiple mimetic protection zones within the OpenStack cloud platform enhances the cloud platform's security performance and improves its ability to mitigate risks.

[0003] In practice, in an Openstack cloud platform equipped with the aforementioned mimicry protection zone, when creating a volume, due to the frequent interactions between the Openstack cloud platform and the database, each access to the database must pass through a large number of mimicry security components, resulting in a long response time for each access to the database, a long volume creation process, and low efficiency. Summary of the Invention

[0004] The present invention provides a volume creation method for an Openstack cloud platform based on mimicry defense, which is used to solve the defect in the prior art that the process of creating volumes in the Openstack cloud platform is time-consuming after the mimicry defense technology is integrated into the Openstack cloud platform. The method achieves the purpose of shortening the process time of creating volumes and improving the efficiency of volume creation when the mimicry defense technology is integrated into the Openstack cloud platform.

[0005] The present invention provides a volume creation method for an Openstack cloud platform based on mimicry defense, which is applied to the Openstack cloud platform based on mimicry defense. The Openstack cloud platform based on mimicry defense includes a user-side proxy unit for receiving user requests, n target cinder-api components, a business-side proxy unit for adjudicating received messages, a rabbitmq component, a cinder-schduler component, and a cinder-volume component, where n is a positive integer and n≥3. The method includes the following steps.

[0006] The user-side proxy unit adds a mimetic tag to the received Restful request for creating the target volume to obtain a first request, and copies and distributes the first request to n target cinder-api components; the Restful request carries the volume information of the target volume; the target cinder-api component verifies the volume information in the first request; if the verification is passed, the target cinder-api component generates volume creation information based on the volume information; the target cinder-api component sends an RPC Call synchronization message carrying the mimetic tag and volume creation information to the business-side proxy unit; the business-side proxy unit determines whether the information carried in the RPCCall synchronization messages of all target cinder-api components is consistent, and if the determination result is yes, sends a second request carrying the volume creation information to the cinder-schduler component through the rabbitmq component; the cinder-schduler component responds to the second request, and if it determines that the number of volumes currently created does not exceed the preset total number of volume creations, writes the corresponding volume creation data in the database according to the volume creation information; if the volume creation data is successfully written to the database, the cinder-schduler component sends an RPC carrying the volume creation data to the cinder-volume component. Cast message; the cinder-volume component creates data based on the volume and creates a target volume.

[0007] According to a volume creation method for an Openstack cloud platform based on mimicry defense provided by the present invention, when the cinder-schduler component successfully writes the volume creation data into the database, the method further includes: executing in the current first thread an operation of returning the volume creation data to the business side proxy unit through the rabbitmq component, and creating a second thread; executing in the second thread an operation of sending an RPCCast message carrying the volume creation data to the cinder-volume component through the rabbitmq component.

[0008] According to a volume creation method for an Openstack cloud platform based on mimicry defense provided by the present invention, volume creation data includes: volume creation information and corresponding identification information thereof; a cinder-schduler component responds to a second request, and upon determining that the number of volumes currently being created does not exceed a preset total number of volume creations, writes corresponding volume creation data into a database according to the volume creation information, including: the cinder-schduler component responds to the second request, detecting whether the number of volumes currently being created exceeds the total number of volume creations; the cinder-schduler component generates identification information corresponding to the volume creation information when the number of volumes currently being created does not exceed a preset total number of volume creations; and the cinder-schduler component writes the volume creation information and the identification information into a database.

[0009] According to a volume creation method for an Openstack cloud platform based on mimicry defense provided by the present invention, after the cinder-schduler component writes volume creation information and identification information into a database, the method further includes: the cinder-schduler component writes a target volume creation operation record into the database.

[0010] According to a volume creation method for an Openstack cloud platform based on mimicry defense provided by the present invention, after the cinder-schduler component writes volume creation information and identification information into a database, the method further includes: the cinder-schduler component updates the volume resource information in the database; wherein the volume resource information includes: the number of volumes that have been created.

[0011] According to a volume creation method for an Openstack cloud platform based on mimicry defense provided by the present invention, volume information includes the following parameters: volume name, volume capacity, and volume type; the target cinder-api component verifies the volume information in the first request, including: the target cinder-api component extracts the volume name, volume capacity, and volume type in the volume information, and determines whether the volume name, volume capacity, and volume type are legal; if the volume name, volume capacity, and volume type are legal, determines whether the volume capacity exceeds the current capacity to be configured; if the volume capacity does not exceed the capacity to be configured, the verification passes; if the volume capacity exceeds the current configurable capacity, the verification fails, and the current program is interrupted.

[0012] According to a volume creation method for an Openstack cloud platform based on mimicry defense provided by the present invention, a business side agent unit determines whether the information carried in the RPC Call synchronization messages of all target cinder-api components is consistent, including: the business side agent unit determines whether the mimicry tags in all RPC Call synchronization messages are consistent; when the mimicry tags in all RPC Call synchronization messages are consistent, the business side agent unit determines whether the volume creation information carried in the RPC Call synchronization messages of all target cinder-api components is consistent.

[0013] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the volume creation method for the Openstack cloud platform based on mimicry defense as described in any one of the above is implemented.

[0014] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the volume creation method for the Openstack cloud platform based on mimicry defense as described in any of the above.

[0015] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements any of the above-described methods for creating volumes on an Openstack cloud platform based on mimicry defense.

[0016] The present invention provides a volume creation method for an Openstack cloud platform based on mimicry defense. The function of mimicry defense is realized by a user-side proxy unit for receiving user requests, n target cinder-api components, and a business-side proxy unit for judging received messages. The method of the present invention adds a mimicry tag to a received Restful request for creating a target volume by the user-side proxy unit to obtain a first request, and copies and distributes the first request to n target cinder-api components; the Restful request carries volume information of the target volume, n is a positive integer and n≥3; the target cinder-api component verifies the volume information in the first request; the target cinder-api component generates volume creation information according to the volume information if the verification passes; the target cinder-api component sends an RPC Call synchronization message carrying the mimicry tag and volume creation information to the business-side proxy unit; the business-side proxy unit performs RPC synchronization on all target cinder-api components. The call determines whether the information carried in the synchronization message is consistent. If the result is yes, a second request carrying the volume creation information is sent to the cinder-schduler component through the rabbitmq component; the cinder-schduler component responds to the second request, and when it determines that the number of currently created volumes does not exceed the preset total number of volume creations, writes the corresponding volume creation data in the database according to the volume creation information; when the volume creation data is successfully written to the database, the cinder-schduler component sends an RPC Cast message carrying the volume creation data to the cinder-volume component; the cinder-volume component creates the target volume according to the volume creation data. In the present invention, the parameter verification and calculation, volume creation information acquisition, and synchronous calling of the cinder-api component in the volume creation process are placed within the mimicry protection zone, and other processes in the volume creation process, such as writing data to the database and creating the target volume, are placed outside the mimicry protection zone. This ensures that the entire volume creation process has good mimicry security performance while saving costs as much as possible, simplifies the complexity of the volume creation process, and solves the problem in the prior art that the volume creation process in the Openstack cloud platform is time-consuming after the mimicry defense technology is integrated into the Openstack cloud platform. This achieves the purpose of shortening the volume creation process time and improving the volume creation efficiency when the mimicry defense technology is integrated into the Openstack cloud platform, thereby greatly improving the stability and efficiency of the volume creation process. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 It is a schematic diagram of the mimicry protection zone in the related art.

[0019] Figure 2 This is one of the flow charts of the volume creation method of the Openstack cloud platform based on mimicry defense provided by the present invention.

[0020] Figure 3 This is the second flow chart of the volume creation method of the Openstack cloud platform based on mimicry defense provided by the present invention.

[0021] Figure 4 This is the third flow chart of the volume creation method for the Openstack cloud platform based on mimicry defense provided by the present invention.

[0022] Figure 5 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0023] To make the objectives, technical solutions, and advantages of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only some of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0024] The following combination Figure 2-Figure 4 The present invention describes a volume creation method for an Openstack cloud platform based on mimicry defense.

[0025] Figure 2 This is a flow chart of the volume creation method of the Openstack cloud platform based on mimicry defense provided by the present invention. Figure 2 As shown, the method includes the following S210~S280.

[0026] S210: The user-side proxy unit adds a mimic tag to the received Restful request for creating a target volume to obtain a first request, and copies and distributes the first request to n target cinder-api components; the Restful request carries volume information of the target volume.

[0027] Before introducing S210, the mimicry defense in the embodiment of the present invention is first introduced.

[0028] For example, Figure 3 As shown, the mimicry defense function in the embodiment of the present invention is implemented by a user-side proxy unit 310 for receiving user requests, n target cinder-api components 320, and a service-side proxy unit 330 for adjudicating received messages. n is a positive integer and n≥3.

[0029] It should be noted that the user-side agent unit 310 can receive user requests and also make decisions and process the received requests.

[0030] Next, we will introduce S210. Figure 3 and Figure 4 , user terminal ( Figure 3 and Figure 4 The client (not shown) may send a Restful request to the user-side proxy unit. The Restful request carries volume information of the target volume, which may include, for example, the name, capacity, and type of the target volume and other parameters related to the creation of the target volume.

[0031] See also Figure 4 After receiving the Restful request from the user terminal, the user-side proxy unit adds a preset mimicry tag to the Restful request to obtain a first request.

[0032] The preset mimetic tag is used to identify the Restful request so that when the subsequent business-side proxy unit receives messages from multiple cinder-api service executors, it can identify messages from the same Restful request based on the mimetic tag carried in the message.

[0033] For example, adding a preset mimicry tag in a Restful request may include adding a preset mimicry tag in a request header of the Restful request.

[0034] Please continue to see Figure 3 and Figure 4 , n is 3. After receiving the first request, the user-side proxy unit copies and distributes the first request to three target cinder-api components. The three target cinder-api components process the information in the first request and send it to the service-side proxy unit.

[0035] The above n target cinder-api components are cinder-api components randomly selected from m cinder-api components, where m is a positive integer and m≥n.

[0036] Please continue to see Figure 3 The user-side proxy unit 310, the service-side proxy unit 330, and the target cinder-api component 320 between the two constitute a mimic protection zone.

[0037] S220: The target cinder-api component verifies the volume information in the first request.

[0038] The target cinder-api component may extract various parameters related to the volume from the volume information of the first request, and then determine whether the data types of the extracted parameters are legal.

[0039] For example, the target cinder-api component can extract the volume name, volume capacity, and volume type from the volume information, and then determine whether the volume name, volume capacity, and volume type are legal.

[0040] If the volume name, volume capacity, and volume type are valid, the target cinder-api component can further determine whether the volume capacity exceeds the current unallocated capacity. The current unallocated capacity is the available capacity that can be allocated to the target volume.

[0041] If the volume capacity does not exceed the configurable capacity, the verification passes and S230 is executed; if the volume capacity exceeds the configurable capacity, the verification fails and the current program is interrupted.

[0042] In some examples, the process of determining whether the volume name, volume capacity, and volume type are legal can be as follows: add the volume name, volume capacity, and volume type parameters extracted from the first request to the kwargs dictionary, and check whether the data type of the parameters in the kwargs dictionary complies with the specifications, etc. If it complies with the specifications, it is legal; if it does not comply with the specifications, it is illegal.

[0043] In some examples, when all parameters in the volume information are legal, the above-mentioned verification may also include: determining whether necessary parameters are missing in the volume information of the first request. For example, multiple necessary parameters may be set in advance, and the multiple necessary parameters are compared with the parameters extracted from the volume information. If one or more of the above-mentioned multiple necessary parameters do not exist in all the parameters of the first request, it is determined that the necessary parameters are missing; otherwise, the necessary parameters are not missing.

[0044] Before extracting the parameters in the volume information of the first request, the target cinder-api component may construct a workflow (worker flow) to verify whether the parameters related to the volume are legal.

[0045] S230: If the above verification is passed, the target cinder-api component generates volume creation information according to the volume information.

[0046] If the verification passes, the target cinder-api component extracts the parameters in the volume information and then generates volume creation information based on the extracted parameters.

[0047] Volume creation information can be carried in the form of a volume object. Figure 3 and Figure 4 As shown, generating volume creation information may be performing volume object creation, that is, creating a new volume object in the program based on the volume information, and the information in the volume object is the volume creation information.

[0048] It should be noted that S220~S230 corresponds to Figure 3 In the process of "parameter verification and calculation, and volume object creation", S220~S230 corresponds to Figure 4 The target cinder-api component executes the processes of "parameter extraction and verification", "volume request parameter extraction", and "volume object creation".

[0049] S240: The target cinder-api component sends an RPC Call synchronization message carrying the mimic tag and volume creation information to the service-side agent unit.

[0050] Since the message sent by the target cinder-api component to the service-side proxy unit is a synchronous message, the target cinder-api component will not process other received messages before receiving the feedback message returned by the service-side proxy unit.

[0051] S240 compatible Figure 3 Synchronous call in .

[0052] S250: The service-side agent unit determines whether the information carried in the RPC Call synchronization messages of all target cinder-api components is consistent. If the determination result is yes, the agent sends a second request carrying the volume creation information to the cinder-schduler component through the rabbitmq component.

[0053] In some embodiments, the business side agent unit directly determines whether the information carried in the RPC Call synchronization messages of all target cinder-api components is consistent. If the determination result is yes, that is, the information carried in the RPC Call synchronization messages of all target cinder-api components is consistent, the business side agent unit sends a second request carrying volume creation information to the cinder-schduler component through the rabbitmq component.

[0054] If the decision result is no, that is, the information carried in the RPC Call synchronization messages of all target cinder-api components is inconsistent, the service-side proxy unit returns an information inconsistency message to the user-side proxy unit.

[0055] In some embodiments, in order to improve processing efficiency, the business side agent unit may first determine whether the mimetic tags in all RPC Call synchronization messages are consistent. When it is determined that the mimetic tags in all RPC Call synchronization messages are consistent, it can be determined that all RPC Call synchronization messages are issued based on the same Restful request. In the previous case, the business side agent unit determines whether the volume creation information carried in the RPC Call synchronization messages of all target cinder-api components is consistent. When it is determined that the volume creation information carried in the RPC Call synchronization messages of all target cinder-api components is consistent, the determination result is yes, that is, the information carried in the RPC Call synchronization messages of all target cinder-api components is consistent, and the business side agent unit sends a second request carrying the volume creation information to the cinder-schduler component through the rabbitmq component.

[0056] When it is determined that the mimic tags in all RPC Call synchronization messages are inconsistent, or when it is determined that the volume creation information carried in the RPC Call synchronization messages of all target cinder-api components is inconsistent, the judgment result is determined to be no, that is, the volume creation information carried in the RPC Call synchronization messages of all target cinder-api components is inconsistent, then a message of inconsistent information is returned to the user-side agent unit.

[0057] S260: The cinder-schduler component responds to the second request, and when determining that the number of volumes currently created does not exceed the preset total number of volume creations, writes corresponding volume creation data into the database according to the volume creation information.

[0058] The cinder-schduler component can first respond to the second request and detect whether the number of volumes currently created exceeds the preset total number of volumes created (corresponding to Figure 4 The total number of volumes created is the total number of volumes that can be created in the system.

[0059] Volume creation data includes volume creation information and its corresponding identification information. If the cinder-schduler component detects that the number of volumes currently being created does not exceed the preset total number of volumes to be created, it generates identification information corresponding to the volume creation information. For example, if a volume object is created in S230, the cinder-schduler component uses the created volume object to call the database module and generate a volume-id corresponding to the volume object as the identification information of the volume object. The cinder-schduler component then writes the volume creation information and identification information to the database.

[0060] For example, after the cinder-schduler component generates the volume-id corresponding to the volume object, it adds a new volume data in the volume table of the database and records the data in the volume object in the volume table (corresponding to Figure 4 Complete the operation of writing volume creation information and identification information to the database.

[0061] In some embodiments, after the cinder-schduler component writes the volume creation information and identification information into the database, the embodiment of the present invention further includes: the cinder-schduler component updates the volume resource information in the database (corresponding to Figure 4 The volume resource information includes the number of created volumes.

[0062] Volume resource information refers to information related to volumes created in the database, such as the number of created volumes and the total capacity of created volumes. After the cinder-schduler component writes the volume creation and identification information to the database, it can update the volume resource information in the database, for example, by increasing the number of created volumes by 1. In specific implementations, volume resource information is recorded in the database's quota table. After the cinder-schduler component writes the volume creation and identification information to the database, it can update the volume resource information in the quota table to synchronize the information.

[0063] In the event that a cinder-scheduler or cinder-volume service exception causes a system restart, in order to quickly restore to the current volume creation process after the restart, after the cinder-scheduler component writes the volume creation information and identification information to the database, the embodiment of the present invention further includes: the cinder-scheduler component writing a target volume creation operation record to the database. The creation operation record, for example, includes the action of creating the volume.

[0064] For example, after the volume object and its corresponding volume-id are written to the volume table, the volume object calls the database and records the current volume creation operation in the worker table of the database. When the cinder-scheduler or cinder-volume service encounters an exception and is restarted, the service can be called again to perform the volume creation operation based on the above volume creation operation recorded in the worker table.

[0065] S270: When the volume creation data is successfully written into the database, the cinder-schduler component sends an RPC Cast message carrying the volume creation data to the cinder-volume component.

[0066] See also Figure 4 , while the cinder-schduler component sends an RPCCast message carrying volume creation data to the inder-volume component, it also returns the volume creation data to the business-side agent unit.

[0067] In some embodiments, the cinder-schduler component may send an RPC Cast message carrying volume creation data to the inder-volume component through the current first thread, and simultaneously return the volume creation data to the service-side proxy unit through the first thread.

[0068] Because when the cinder-schduler component sends the RPC Cast message carrying the volume creation data to the inder-volume component through the current first thread, and because the RPC Call message previously sent by the cinder-api component to the business-side proxy unit is a synchronous message, the cinder-api service is still in a blocked state. In this case, in order to shorten the response time, the cinder-schduler component can, when the volume creation data is successfully written to the database, execute the operation of returning the volume creation data to the business-side proxy unit through the rabbitmq component in the current first thread, and create a second thread; and execute the operation of sending the RPCCast message carrying the volume creation data to the cinder-volume component through the rabbitmq component in the second thread.

[0069] The second thread selects the optimal storage backend through an algorithm based on information such as the volume type, and initiates an RPC Cast call to the cinder-volume component through the rabbitmq message queue in the rabbitmq component. This call is an asynchronous call, that is, the RPC Cast message sent by the rabbitmq component to the cinder-volume component is an asynchronous message.

[0070] S280: The cinder-volume component creates data based on the volume and creates a target volume.

[0071] See also Figure 4 As shown in the figure, after receiving the RPC Cast message, the cinder-volume component builds a workflow, determines the volume type of the target volume to be created based on the volume creation data, and then calls the specified storage backend driver component to create the target volume.

[0072] For example, after receiving an RPC Cast message, the cinder-volume component constructs a workflow to execute the task of creating a volume object. Based on the volume-id, it retrieves the volume object corresponding to the volume-id from the database, extracts the volume creation information from the volume object, and sets the volume type in the volume creation information to the volume type of the target volume to be created. The task of creating the target volume is then executed. Based on the volume type of the target volume, the corresponding volume creation method in the driver component of the specified storage backend is called, mainly including methods such as mirroring, snapshotting, and backup. The storage backend is then called through the driver component, and the target volume is successfully created on the storage.

[0073] The present invention provides a volume creation method for an Openstack cloud platform based on mimicry defense. The mimicry defense function is realized by a user-side proxy unit for receiving user requests, n target cinder-api components, and a business-side proxy unit for judging received messages. n is a positive integer and n≥3. The method of the present invention adds a mimicry tag to a received Restful request for creating a target volume by the user-side proxy unit to obtain a first request, and copies and distributes the first request to n target cinder-api components; the Restful request carries volume information of the target volume; the target cinder-api component verifies the volume information in the first request; the target cinder-api component generates volume creation information according to the volume information if the verification passes; the target cinder-api component sends an RPCCall synchronization message carrying the mimicry tag and volume creation information to the business-side proxy unit; the business-side proxy unit performs RPC on all target cinder-api components. The call determines whether the information carried in the synchronization message is consistent. If the result is yes, a second request carrying the volume creation information is sent to the cinder-schduler component through the rabbitmq component; the cinder-schduler component responds to the second request, and if it determines that the number of volumes currently created exceeds the preset total number of volume creations, it writes the corresponding volume creation data in the database according to the volume creation information; if the volume creation data is successfully written to the database, the cinder-schduler component sends an RPC Cast message carrying the volume creation data to the cinder-volume component; the cinder-volume component creates the target volume according to the volume creation data. In the present invention, the parameter verification and calculation, volume creation information acquisition, and synchronous calling of the cinder-api component in the volume creation process are placed within the mimicry protection zone, and other processes in the volume creation process, such as writing data to the database and creating the target volume, are placed outside the mimicry protection zone. This ensures that the entire volume creation process has good mimicry security performance while saving costs as much as possible, simplifies the complexity of the volume creation process, and solves the problem in the prior art that the volume creation process in the Openstack cloud platform is time-consuming after the mimicry defense technology is integrated into the Openstack cloud platform. This achieves the purpose of shortening the volume creation process time and improving the volume creation efficiency when the mimicry defense technology is integrated into the Openstack cloud platform, thereby greatly improving the stability and efficiency of the volume creation process.

[0074] The embodiment of the present invention only performs database read operations within the mimetic protection zone and performs database write operations outside the mimetic protection zone, saving the waiting time of the business-side agent unit waiting for multiple write requests to arrive when performing database write operations inside the mimetic protection zone, thereby improving the speed of database write operations and ensuring the consistency of data writing.

[0075] This embodiment of the present invention adds a synchronous call module (i.e., Cinder-API sends an RPC call synchronization message to the service-side proxy unit). After the Cinder-API component sends the RPC call synchronization message, other requests are blocked until the Cinder-API component receives a response from the service-side proxy unit. When executing a database write operation, the target volume's volume creation information (such as the volume-id in the above example) is generated.

[0076] In this embodiment of the present invention, if the volume creation data is successfully written to the database, a second thread is created. The first thread then returns the volume creation data to the cinder-api component, ultimately returning the volume creation data to the user terminal. This second thread selects the optimal backend, forwards the message, and calls the driver to create the target volume. This ensures that the returned information contains the corresponding identifier for the volume creation information and minimizes the waiting time for the returned information.

[0077] Figure 5 An example of a physical structure diagram of an electronic device is shown below. Figure 5As shown, the electronic device may include: a processor 510 , a communication interface 520 , a memory 530 and a communication bus 540 , wherein the processor 510 , the communication interface 520 and the memory 530 communicate with each other via the communication bus 540 . The processor 510 can call the logic instructions in the memory 530 to execute the volume creation method of the Openstack cloud platform based on mimicry defense. The method is applied to the Openstack cloud platform based on mimicry defense. The Openstack cloud platform based on mimicry defense includes a user-side agent unit for receiving user requests, n target cinder-api components, a business-side agent unit for adjudicating received messages, a rabbitmq component, a cinder-schduler component, and a cinder-volume component, where n is a positive integer and n≥3; the method includes: the user-side agent unit adds a mimicry label to the received Restful request for creating a target volume to obtain a first request, and copies and distributes the first request to the n target cinder-api components; the Restful request carries volume information of the target volume; the target cinder-api component verifies the volume information in the first request; the target cinder-api component generates volume creation information according to the volume information if the verification passes; the target cinder-api component sends an RPC Call synchronization message carrying the mimicry label and volume creation information to the business-side agent unit; the business-side agent unit performs RPC Call synchronization on all target cinder-api components The call determines whether the information carried in the synchronization message is consistent. If the result is yes, a second request carrying the volume creation information is sent to the cinder-schduler component through the rabbitmq component; the cinder-schduler component responds to the second request, and when it determines that the number of currently created volumes does not exceed the preset total number of volume creations, writes the corresponding volume creation data in the database according to the volume creation information; when the volume creation data is successfully written to the database, the cinder-schduler component sends an RPC Cast message carrying the volume creation data to the cinder-volume component; the cinder-volume component creates the target volume according to the volume creation data.

[0078] Furthermore, the logic instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0079] On the other hand, the present invention also provides a computer program product, which includes a computer program. The computer program can be stored on a computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the volume creation method of the Openstack cloud platform based on mimicry defense provided by the above methods. The method is applied to the Openstack cloud platform based on mimicry defense. The Openstack cloud platform based on mimicry defense includes a user-side agent unit for receiving user requests, n target cinder-api components, a business-side agent unit for adjudicating received messages, a rabbitmq component, a cinder -schduler component and cinder-volume component, n is a positive integer and n≥3; the method includes: the user-side proxy unit adds a mimicry tag to the received Restful request for creating a target volume to obtain a first request, and copies and distributes the first request to n target cinder-api components; the Restful request carries volume information of the target volume; the target cinder-api component verifies the volume information in the first request; if the verification passes, the target cinder-api component generates volume creation information based on the volume information; the target cinder-api component sends an RPC carrying the mimicry tag and volume creation information to the business-side proxy unit Call synchronization message; the business-side agent unit determines whether the information carried in the RPC Call synchronization messages of all target cinder-api components is consistent. If the determination result is yes, the second request carrying volume creation information is sent to the cinder-schduler component through the rabbitmq component; the cinder-schduler component responds to the second request, and when it determines that the number of currently created volumes does not exceed the preset total number of volume creations, writes the corresponding volume creation data in the database according to the volume creation information; if the volume creation data is successfully written to the database, the cinder-schduler component sends an RPC Cast message carrying volume creation data to the cinder-volume component; the cinder-volume component creates the target volume according to the volume creation data.

[0080] On the other hand, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the volume creation method of the Openstack cloud platform based on mimicry defense provided by the above-mentioned methods, the method being applied to the Openstack cloud platform based on mimicry defense, the Openstack cloud platform based on mimicry defense including a user-side proxy unit for receiving user requests, n target cinder-api components, a business-side proxy unit for adjudicating received messages, a rabbitmq component, a cinder-schduler component, and a cinder-volume component, where n is a positive integer and n≥3; the method including: the user-side proxy unit adding a mimicry label to the received Restful request for creating a target volume to obtain a first request, and copying and distributing the first request to the n target cinder-api components; the Restful request carries volume information of the target volume; the target cinder-api component verifies the volume information in the first request; the target cinder-api component generates volume creation information based on the volume information if the verification passes; the target cinder-api component sends an RPC carrying the mimicry label and volume creation information to the business-side proxy unit Call synchronization message; the business-side agent unit determines whether the information carried in the RPC Call synchronization messages of all target cinder-api components is consistent. If the determination result is yes, the second request carrying volume creation information is sent to the cinder-schduler component through the rabbitmq component; the cinder-schduler component responds to the second request, and when it determines that the number of currently created volumes does not exceed the preset total number of volume creations, writes the corresponding volume creation data in the database according to the volume creation information; if the volume creation data is successfully written to the database, the cinder-schduler component sends an RPC Cast message carrying volume creation data to the cinder-volume component; the cinder-volume component creates the target volume according to the volume creation data.

[0081] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0082] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the essence of the above technical solution, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for causing a computer device (such as a personal computer, server, or network device) to execute the methods described in each embodiment or certain portions of the embodiments.

[0083] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A volume creation method for an Openstack cloud platform based on mimicry defense, characterized in that: The method is applied to an Openstack cloud platform based on mimicry defense, the Openstack cloud platform based on mimicry defense including a user-side proxy unit for receiving user requests, n target cinder-api components, a business-side proxy unit for adjudicating received messages, a rabbitmq component, a cinder-schduler component, and a cinder-volume component, where n is a positive integer and n≥3; the method includes: The user-side proxy unit adds a mimic tag to the received RESTful request for creating a target volume to obtain a first request, and copies and distributes the first request to the n target cinder-api components; the RESTful request carries volume information of the target volume; The target cinder-api component verifies the volume information in the first request; The target cinder-api component generates volume creation information according to the volume information if the verification passes; The target cinder-api component sends an RPC Call synchronization message carrying the mimic tag and the volume creation information to the service-side agent unit; The service-side agent unit determines whether the information carried in the RPC Call synchronization message of all target cinder-api components is consistent, and if the determination result is yes, sends a second request carrying the volume creation information to the cinder-schduler component through the rabbitmq component; The cinder-schduler component responds to the second request and, if it is determined that the number of volumes currently being created does not exceed the preset total number of volumes to be created, writes corresponding volume creation data into the database according to the volume creation information; When the volume creation data is successfully written into the database, the cinder-schduler component sends an RPC Cast message carrying the volume creation data to the cinder-volume component; The cinder-volume component creates the target volume according to the volume creation data.

2. The volume creation method of the Openstack cloud platform based on mimicry defense according to claim 1 is characterized in that: In the case where the volume creation data is successfully written into the database by the cinder-schduler component, the method further includes: In the current first thread, executing an operation of returning the volume creation data to the service-side proxy unit through the rabbitmq component, and creating a second thread; In the second thread, an operation of sending an RPC Cast message carrying the volume creation data to the cinder-volume component through the rabbitmq component is executed.

3. The volume creation method of the Openstack cloud platform based on mimicry defense according to claim 1 is characterized in that: The volume creation data includes: the volume creation information and its corresponding identification information; the cinder-schduler component responds to the second request, and when determining that the number of volumes currently created does not exceed a preset total number of volume creations, writes corresponding volume creation data into the database according to the volume creation information, including: The cinder-schduler component responds to the second request and detects whether the number of volumes currently created exceeds the total number of volumes created; The cinder-schduler component generates the identification information corresponding to the volume creation information when the number of volumes currently created does not exceed the preset total number of volume creations; The cinder-schduler component writes the volume creation information and the identification information into the database.

4. The volume creation method of the Openstack cloud platform based on mimicry defense according to claim 3 is characterized in that: After the cinder-schduler component writes the volume creation information and the identification information into the database, the method further includes: The cinder-schduler component writes the target volume creation operation record into the database.

5. The volume creation method of the Openstack cloud platform based on mimicry defense according to claim 3 is characterized in that: After the cinder-schduler component writes the volume creation information and the identification information into the database, the method further includes: The cinder-schduler component updates the volume resource information in the database; wherein the volume resource information includes: the number of created volumes.

6. The volume creation method of the Openstack cloud platform based on mimicry defense according to claim 1 is characterized in that: The volume information includes the following parameters: volume name, volume capacity, and volume type; the target cinder-api component verifies the volume information in the first request, including: The target cinder-api component extracts the volume name, volume capacity, and volume type from the volume information, and determines whether the volume name, volume capacity, and volume type are legal; If the volume name, the volume capacity, and the volume type are legal, determining whether the volume capacity exceeds the current capacity to be configured; If the volume capacity does not exceed the capacity to be configured, the verification passes; In the case that the volume capacity exceeds the current configurable capacity, the verification fails and the current program is interrupted.

7. The volume creation method of the Openstack cloud platform based on mimicry defense according to claim 1 is characterized in that: The service-side proxy unit determines whether the information carried in the RPC Call synchronization message of all target cinder-api components is consistent, including: The service-side agent unit determines whether the mimic tags in all the RPC Call synchronization messages are consistent; When the mimic tags in all the RPC Call synchronization messages are consistent, the service-side agent unit determines whether the volume creation information carried in the RPC Call synchronization messages of all the target cinder-api components is consistent.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the volume creation method of the Openstack cloud platform based on mimicry defense as described in any one of claims 1 to 7 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the volume creation method of the Openstack cloud platform based on mimicry defense as described in any one of claims 1 to 7 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the volume creation method of the Openstack cloud platform based on mimicry defense as described in any one of claims 1 to 7 is implemented.

Images