Cloud hard disk mounting and unmounting method of Openstack cloud platform based on inherent security architecture

Abstract

The present invention provides a cloud hard disk mounting and unmounting method for an Openstack cloud platform based on an intrinsic security architecture, relating to the field of intrinsic security technology. The method comprises: when mounting a cloud hard disk, selecting target heterogeneous executors greater than 3, the target heterogeneous executors creating BDM information, sending a first message carrying the BDM information, a first identifier of a target cloud host to be mounted, and a second identifier of a target cloud hard disk to be mounted to a service-side agent unit, which determines whether the first messages of all received target heterogeneous executors are consistent, and generating a BDM table according to the BDM information, the first identifier, and the second identifier when the information is determined to be consistent. After the BDM table is successfully written to a database, an operation of mounting the target cloud hard disk in the target cloud host is executed. A similar process is also executed when unmounting the cloud hard disk, and a determination is made whether the execution results of the target heterogeneous executors are consistent, thereby effectively ensuring the consistency of data written in the database during the cloud hard disk mounting and unmounting process.

Description

Technical Field

[0001] The present invention relates to the field of intrinsic security technology, and in particular to a cloud hard disk mounting and unmounting method for an Openstack cloud platform based on an intrinsic security architecture. Background Art

[0002] An intrinsic security architecture is one with inherent security defense capabilities. It aims to transform security from an external add-on to an internal one, moving from defending against known threats to addressing unknown ones. Core frameworks of the intrinsic security architecture, such as Dynamic Heterogeneous Redundancy (DHR), include multiple heterogeneous executors, each capable of independently performing computations on received data.

[0003] With the development of cloud computing, cloud services are increasingly being applied across various industries. Ensuring faster, more efficient, and more stable cloud drive mounting and unmounting within a cloud platform's inherent security architecture has become crucial for the proper operation and use of cloud hosts within the platform. The OpenStack cloud platform is a widely used cloud computing management platform. With its inherent security architecture, each time a cloud drive is mounted (or unmounted), the corresponding request is sent simultaneously to multiple randomly selected heterogeneous executors. Based on the received request, each heterogeneous executor independently writes the data related to the mounted (or unmounted) cloud drive to the database. In practice, the execution progress of these randomly selected heterogeneous executors is often inconsistent, resulting in either identical or different results. Consequently, when writing data to the database, multiple heterogeneous executors may write the same or different data simultaneously. This can lead to data confusion, duplication, and even conflict within the database, hindering the proper mounting (or unmounting) of the cloud drive. Summary of the Invention

[0004] The present invention provides a cloud hard disk mounting and unmounting method for an Openstack cloud platform based on an inherent security architecture, which is used to solve the defects in the prior art of confusion, duplication or conflict in the data written in the database when performing the cloud hard disk mounting operation on the Openstack cloud platform with an inherent security architecture. The method achieves the purpose of ensuring the consistency of the data written in the database when mounting the cloud hard disk on the Openstack cloud platform with an inherent security architecture.

[0005] The present invention provides a cloud hard disk mounting method for an Openstack cloud platform with an inherent security architecture. The inherent security architecture includes a user-side proxy unit, a business-side proxy unit, and m heterogeneous executors. The method includes the following steps.

[0006] The user-side proxy unit receives the first Restful request for mounting a cloud hard disk from the UI; the first Restful request carries the first identifier of the target cloud host and the second identifier of the target cloud hard disk; the user-side proxy unit copies and distributes the first Restful request to n target heterogeneous executors among the m heterogeneous executors; m and n are positive integers, m≥n≥3; the target heterogeneous executor responds to the received first Restful request and creates BDM information when it determines that the target cloud host and the target cloud hard disk are both in an available state; the business-side proxy unit receives the RPC Call synchronization message carrying the BDM information, the first identifier and the second identifier from the target heterogeneous executor, and performs RPC synchronization on all target heterogeneous executors. The nova-compute component judges whether the BDM information in the call synchronization message is consistent; the nova-compute component monitors the rabbitmq message queue and obtains the first message carrying the BDM information, the first identifier and the second identifier sent to the rabbitmq message queue by the business side agent unit when the first judgment result is yes; the nova-compute component writes the BDM table obtained according to the BDM information, the first identifier and the second identifier into the database; when the BDM table is successfully written to the database, the nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor and executes the operation of mounting the target cloud hard disk in the target cloud host.

[0007] According to a cloud hard disk mounting method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, after the nova-compute component writes the BDM table obtained according to the BDM information, the first identifier and the second identifier into the database, the method also includes: the nova-compute component creates a secondary thread when the BDM table is successfully written into the database; the nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor when the BDM table is successfully written into the database, and executes the operation of mounting the target cloud hard disk in the target cloud host, including: the nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor through the current main thread, and executes the operation of mounting the target cloud hard disk in the target cloud host through the secondary thread.

[0008] According to a cloud hard disk mounting method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, after creating a secondary thread, the method further includes: the nova-compute component sends a first state change request to the cinder-api component through the secondary thread to change the state of the target cloud hard disk; the cinder-api component sets the state of the target cloud hard disk to a reserved state in response to the received first state change request; the target cloud hard disk in the reserved state is prohibited from being mounted by cloud hosts other than the target cloud host.

[0009] According to a cloud hard disk mounting method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, after creating a secondary thread, the method further includes: the nova-compute component obtains a task lock of a target cloud host through the secondary thread; and, when the operation of mounting a target cloud hard disk in the target cloud host executed through the secondary thread is completed, the task lock is released.

[0010] According to a cloud hard disk mounting method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, after the nova-compute component obtains the task lock of the target cloud host through a secondary thread, the method further includes: the nova-compute component sends a mount information request to the cinder-api component; the nova-compute component updates the BDM table in the database according to the mount information returned by the cinder-api component in response to the mount information request; wherein the mount information includes: the drive letter information of the target cloud hard disk in the target cloud host.

[0011] According to a cloud hard disk mounting method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, after a user-side proxy unit copies and distributes a first Restful request to n target heterogeneous executors among m heterogeneous executors, the method further includes: the target heterogeneous executor responds to the received first Restful request, and when it is determined that the target cloud host or the target cloud hard disk is not in an available state, returns an operation conflict message to the user-side proxy unit; and the user-side proxy unit sends an operation conflict response message corresponding to the operation conflict message to the UI for display.

[0012] According to a cloud hard disk mounting method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, the intrinsic security architecture also includes: a feedback control unit; after determining whether the BDM information in the RPC Call synchronization message of all target heterogeneous executors is consistent, the method further includes: a business-side agent unit, when the first determination result is negative, obtains identification information of a first abnormal heterogeneous executor in an abnormal state among n target heterogeneous executors, and sends the identification information of the first abnormal heterogeneous executor to the feedback control unit; the feedback control unit rotates and cleans the first abnormal heterogeneous executor.

[0013] According to a cloud hard disk mounting method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, after returning a third identifier of a BDM table to a target heterogeneous executor, the method further includes: a user-side proxy unit receiving a mount response message returned by the target heterogeneous executor based on the received third identifier; the user-side proxy unit determining whether the mount response messages returned by all target heterogeneous executors are consistent; obtaining a second determination result; if the second determination result is yes, sending the second determination result to a UI for display; if the second determination result is no, obtaining identification information of a second abnormal heterogeneous executor in an abnormal state among all current target heterogeneous executors, and sending the identification information of the second abnormal heterogeneous executor to a feedback control unit; and the feedback control unit rotating and cleaning the second abnormal heterogeneous executor.

[0014] The present invention also provides a cloud hard disk unloading method for an Openstack cloud platform based on an inherent security architecture. The inherent security architecture includes a user-side agent unit, a business-side agent unit, and m heterogeneous execution bodies. The method includes the following steps.

[0015] The user-side proxy unit receives a second Restful request from the UI to uninstall the cloud hard disk; the second Restful request carries the first identifier of the target cloud host and the second identifier of the target cloud hard disk; the user-side proxy unit copies and distributes the second Restful request to k target heterogeneous executors among the m heterogeneous executors; m and k are positive integers, m≥k≥3; in response to the received second Restful request, the target heterogeneous executor sends an RPC Call asynchronous message carrying the first identifier and the second identifier to the business-side proxy unit if it determines that the target cloud host is in an available state; the business-side proxy unit determines whether the RPC Call asynchronous messages of all target heterogeneous executors are consistent; the nova-compute component monitors the rabbitmq message queue and obtains the second message carrying the first identifier and the second identifier sent to the rabbitmq message queue by the business-side proxy unit if the third determination result is yes; the nova-compute component executes the operation of uninstalling the target cloud hard disk from the target cloud host based on the first identifier and the second identifier.

[0016] According to a cloud hard disk unloading method of an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, the nova-compute component executes an operation of unloading a target cloud hard disk in a target cloud host according to a first identifier and a second identifier, including: the nova-compute component obtains a task lock of the target cloud host according to the first identifier; the nova-compute component obtains a BDM table containing the first identifier and the second identifier from a database according to the first identifier and the second identifier; the nova-compute component unloads the target cloud hard disk from the target cloud host according to the mounting information of the target cloud hard disk in the BDM table; the nova-compute component deletes the BDM table in the database; the nova-compute component sends a second state change request to the cinder-api component; and the cinder-api component sets the state of the target cloud hard disk to a usable state in response to the received second state change request.

[0017] According to a cloud hard disk unloading method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, the intrinsic security architecture also includes: a feedback control unit; after the business side agent unit determines whether the RPCCall asynchronous messages of all target heterogeneous executors are consistent, it also includes: when the third determination result is no, the business side agent unit obtains the identification information of a third abnormal heterogeneous executor in an abnormal state among all current target heterogeneous executors, and sends the identification information of the third abnormal heterogeneous executor to the feedback control unit; the feedback control unit rotates and cleans the third abnormal heterogeneous executor.

[0018] According to a cloud hard disk unloading method for an Openstack cloud platform based on an intrinsic security architecture provided by the present invention, the target heterogeneous executor responds to the received second Restful request, and after determining that the target cloud host is in an available state, sends an RPC Call asynchronous message carrying a first identifier and a second identifier to a business-side proxy unit. The method further includes: the target heterogeneous executor returns an unloading response message to the user-side proxy unit; after receiving the unloading response message, the user-side proxy unit performs a consistency decision on the unloading response messages returned by all target heterogeneous executors to obtain a fourth decision result; if the fourth decision result is yes, the fourth decision result is sent to a UI for display; if the fourth decision result is no, the identification information of a fourth abnormal heterogeneous executor in an abnormal state among all current target heterogeneous executors is obtained, and the identification information of the fourth abnormal heterogeneous executor is sent to a feedback control unit; and the feedback control unit rotates and cleans the fourth abnormal heterogeneous executor.

[0019] The present invention provides a cloud hard disk mounting and unmounting method for an Openstack cloud platform based on an inherent security architecture. The method can determine whether the execution results of multiple target heterogeneous executors are consistent in a business-side proxy unit. If the determination result is that the execution results of the multiple target heterogeneous executors are consistent, the cloud hard disk mounting operation or cloud hard disk unmounting operation is performed. This avoids the situation where multiple heterogeneous executors successively write the same data or write different data to the database, resulting in confusion, duplication, or even conflict in the data written in the database. This ensures the consistency of data written in the database when mounting or unmounting a cloud hard disk in an Openstack cloud platform that introduces an inherent security architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the present invention or the prior art, a brief introduction is 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.

[0021] Figure 1 This is one of the flow diagrams of the cloud hard disk mounting method of the Openstack cloud platform based on the inherent security architecture provided by the present invention.

[0022] Figure 2 It is a schematic diagram of the inherent security architecture provided by the present invention.

[0023] Figure 3 This is the second flow chart of the cloud hard disk mounting method of the Openstack cloud platform based on the inherent security architecture provided by the present invention.

[0024] Figure 4 This is one of the flow charts of the cloud hard disk uninstallation method of the Openstack cloud platform based on the inherent security architecture provided by the present invention.

[0025] Figure 5 This is the second flow chart of the cloud hard disk uninstallation method of the Openstack cloud platform based on the inherent security architecture provided by the present invention.

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

[0027] 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.

[0028] The following combination Figure 1-Figure 5 The present invention describes a cloud hard disk mounting and unmounting method for the Openstack cloud platform based on an inherent security architecture.

[0029] Figure 1 This is one of the flow diagrams of the cloud hard disk mounting method of the Openstack cloud platform based on the inherent security architecture provided by the embodiment of the present invention. Figure 1 As shown, the method includes the following S110~170.

[0030] S110: The user-side proxy unit receives a first Restful request for mounting a cloud hard disk from the UI; the first Restful request carries a first identifier of a target cloud host and a second identifier of a target cloud hard disk.

[0031] Before introducing S110 , the intrinsic security architecture provided by the embodiment of the present invention is first introduced.

[0032] like Figure 2 As shown, the content security architecture provided by the embodiment of the present invention includes a user-side agent unit 201 , m (m is a positive integer and m≥3) heterogeneous executors (nova-api) 202 , a service-side agent unit 203 and a feedback control unit 204 .

[0033] The user-side agent unit 201 is configured to receive a user request from a user interface (UI), select n target heterogeneous executors from m heterogeneous executors, and copy and distribute the received user request to each of the n target heterogeneous executors.

[0034] The heterogeneous execution body 202 is used to complete parameter verification, calculation, and execution of the received user request, and then output the execution result to the service-side agent module 203.

[0035] The business-side proxy module 203 is used to adjudicate the execution results received from the heterogeneous executor 202 and send the adjudication results to the business execution module (the business execution module in this application is the nova-compute component of the Openstack cloud platform), so that the business execution module performs corresponding operations according to the adjudication results.

[0036] The feedback control unit 204 is used to rotate and clean abnormal heterogeneous execution bodies, so as to timely discover and process abnormal heterogeneous execution bodies among multiple heterogeneous execution bodies to ensure the normal operation of the entire architecture.

[0037] Next, we will continue to introduce S110. Figure 3 As shown, Figure 3 The user-side proxy unit in Figure 2 In the user-side agent unit 201, the user can send a mount request to the UI to mount the cloud hard disk. The UI generates a first Restful request based on the mount request and sends the first Restful request to the user-side agent unit.

[0038] The first Restful request carries the first identifier of the target cloud host to be mounted by the user and the second identifier of the target cloud hard disk to be mounted.

[0039] The first identifier of the target cloud host is, for example, a universally unique identifier (UUID) of the target cloud host.

[0040] The second identifier of the target cloud hard disk is, for example, the UUID of the target cloud hard disk.

[0041] S120: The user-side proxy unit copies and distributes the first Restful request to n target heterogeneous executors among the m heterogeneous executors; m and n are positive integers, m≥n≥3.

[0042] The user-side proxy unit selects n target heterogeneous executors from the m heterogeneous executors, and copies and distributes the first Restful request to each target heterogeneous executor in the n target heterogeneous executors.

[0043] When the user-side agent unit selects n target heterogeneous executors from m heterogeneous executors, it may first randomly select n target heterogeneous executors from the heterogeneous executors in normal states according to relevant parameters in each heterogeneous executor.

[0044] In the embodiment of the present invention, see Figure 2 , the heterogeneous executor can be the nova-api component (corresponding to Figure 2 in nova-api).

[0045] For example, Figure 3 As shown, n is 3, and the user-side proxy unit randomly selects 3 nova-api components in normal state from multiple nova-api components (corresponding to Figure 3In nova-api1, nova-api2, and nova-api3, the first Restful request is copied and distributed to the three selected nova-api components.

[0046] S130: The target heterogeneous executor creates BDM information in response to the received first Restful request if it is determined that the target cloud host and the target cloud hard disk are both in an available state.

[0047] BDM is the abbreviation of block_device_mapping, which means block device mapping.

[0048] After receiving the first Restful request, the target heterogeneous executor can query the status of the target cloud host corresponding to the first identifier in the database through the business side agent unit, and query the status of the target cloud hard disk corresponding to the second identifier in the database through the business side agent unit.

[0049] If the target cloud host is in active or shutdown state and no other tasks are being executed, determine that the target cloud host is in available state.

[0050] When the status of the target cloud hard disk is in the available state, it is determined that the status of the target cloud hard disk is in the available state.

[0051] When it is determined that the target cloud host and the target cloud hard disk are both in an available state, the target heterogeneous executor creates BDM information, sends an RPC Call synchronization message carrying the BDM information, the first identifier and the second identifier to the service side agent unit, and then executes S140.

[0052] Before determining that the target cloud host and the target cloud hard disk are both in an available state, the target heterogeneous executor can perform parameter processing on the parameters in the first Restful request. Parameter processing includes parameter verification and parameter calculation. Parameter verification includes verifying the legality and integrity of the parameters, and parameter calculation includes calculating one or more parameters to obtain new parameters.

[0053] For example, see Figure 3 After receiving the first Restful request, the target heterogeneous executor first processes the parameters. After that, when it is determined that the target cloud host and the target cloud hard disk are both available, it creates the BDM information ( Figure 3 (not shown), the RPC Call synchronization message carrying the BDM information, the first identifier and the second identifier is sent to the service side agent unit.

[0054] It should be noted that the message sent to the service side agent unit here is a synchronous message, that is, after receiving the return message returned by the service side agent unit, the target heterogeneous executor will not process other received messages.

[0055] In some embodiments, when it is determined that the target cloud host or target cloud hard disk is not in an available state, the target heterogeneous executor returns an operation conflict message to the user-side agent unit; after receiving the operation conflict message, the user-side agent unit can adjudicate the operation conflict messages returned by all target heterogeneous executors to determine whether the operation conflict messages are consistent. When it is determined that the operation conflict messages are consistent, an operation conflict response message corresponding to the operation conflict message is sent to the UI for display to prompt the user that the current operation has a conflict and cannot continue to be executed; when the operation conflict message is inconsistent, a target heterogeneous executor in an abnormal state among the n target heterogeneous executors is obtained, and information about the target heterogeneous executor is sent to the feedback control unit so that the feedback control unit can rotate and clean the target heterogeneous executor.

[0056] S140: The service-side agent receives an RPC Call synchronization message carrying BDM information, a first identifier, and a second identifier from a target heterogeneous executor, and determines whether the BDM information in the RPC Call synchronization messages of all target heterogeneous executors is consistent.

[0057] The business side agent unit determines whether the BDM information in the RPC Call synchronization messages of all target heterogeneous executors is consistent. When the first determination result is yes, that is, when the BDM information in the RPC Call synchronization messages of all target heterogeneous executors is consistent, the first message carrying the BDM information, the first identifier and the second identifier is sent to the rabbitmq message queue, and then S150 is executed.

[0058] For example, Figure 3 As shown, the business side agent unit sends the first message to the rabbitmq message queue ( Figure 3 The corresponding one is rabbitmq).

[0059] When the first judgment result is negative, that is, when the BDM information in the RPC Call synchronization message of all target heterogeneous executors is inconsistent, the business side agent unit obtains the identification information of the first abnormal heterogeneous executor in the abnormal state among the n target heterogeneous executors, and sends the identification information of the first abnormal heterogeneous executor to the feedback control unit, and the feedback control unit rotates and cleans the first abnormal heterogeneous executor.

[0060] S150: The nova-compute component monitors the rabbitmq message queue to obtain a first message carrying BDM information, a first identifier, and a second identifier, which is sent by the service-side agent unit to the rabbitmq message queue when the first determination result is yes.

[0061] For example, Figure 3 As shown, the nova-compute component ( Figure 3 The corresponding nova-compute in the example can monitor the RabbitMQ message queue and obtain the first message from the RabbitMQ message queue when the RabbitMQ message queue receives the first message.

[0062] S160: The nova-compute component writes the BDM table obtained according to the BDM information, the first identifier, and the second identifier into the database.

[0063] The nova-compute component may first generate an initial BDM data structure table according to the BDM information, and fill the first identifier and the second identifier into the initial BDM data structure table to obtain a BDM table.

[0064] Before writing the BDM table to the database, the nova-compute component can first write the operation record of mounting the target cloud hard disk to the database, making it easier for administrators to view operation logs and other information.

[0065] The BDM information in the first message obtained by the nova-compute component is consistent in n target heterogeneous executors. In this case, the nova-compute component will write the BDM table obtained based on the BDM information, the first identifier and the second identifier into the database. There will be no problems such as confusion, duplication or conflict in the written data, effectively ensuring the consistency of the data written to the database.

[0066] S170: When the BDM table is successfully written into the database, the nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor and mounts the target cloud hard disk on the target cloud host.

[0067] When the BDM table is successfully written to the database, the nova-compute component may return a third identifier of the BDM table (eg, the UUID of the BDM table) to the target heterogeneous executor, so that the target heterogeneous executor returns a mount response to the user agent unit based on the received third identifier.

[0068] On the user-side proxy unit side, the user-side proxy unit receives the mount response message returned by the target heterogeneous executor according to the third identifier it receives, and then determines whether the mount response messages returned by all target heterogeneous executors are consistent to obtain a second determination result.

[0069] If the second decision result is yes, the user-side agent unit sends the second decision result to the UI for display.

[0070] If the second determination result is negative, the user-side agent unit obtains identification information of a second abnormal heterogeneous executor in an abnormal state among all current target heterogeneous executors, and sends the identification information of the second abnormal heterogeneous executor to the feedback control unit.

[0071] The feedback control unit rotates and cleans the second abnormal heterogeneous executor.

[0072] For example, see Figure 3 , the nova-compute component returns the third identifier of the BDM table to each nova-api component. After receiving the third identifier, each nova-api component returns a mount response message (corresponding to Figure 3 After receiving the mount responses from all target heterogeneous executors, the user-side proxy unit determines whether the mount response messages from all target heterogeneous executors are consistent, and obtains a second determination result. The second determination result may include: the mount response messages from all target heterogeneous executors are consistent, or the mount response messages from all target heterogeneous executors are inconsistent. The user-side proxy unit may send the second determination result to the UI for display, so that the user can understand the current status of the cloud drive mount process.

[0073] In some embodiments, the two events of returning the third identifier of the BDM table to the target heterogeneous executor and performing the operation of mounting the target cloud hard disk in the target cloud host can be executed simultaneously on the same thread.

[0074] In some embodiments, in order to improve processing efficiency, after the nova-compute component writes the BDM table obtained based on the BDM information, the first identifier and the second identifier into the database, if the BDM table is successfully written into the database, the nova-compute component can create a secondary thread. In this case, the nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor through the current main thread, and executes the operation of mounting the target cloud hard disk in the target cloud host through the secondary thread.

[0075] For example, see Figure 3The nova-compute component returns the UUID of the BDM table to the nova-api component and creates a new thread (the secondary thread) to mount the target cloud hard disk on the target cloud host.

[0076] In some embodiments, see Figure 3 The nova-compute component can send a first state change request to the cinder-api component through the created secondary thread to change the state of the target cloud hard disk; in response to the received first state change request, the cinder-api component sets the state of the target cloud hard disk to the reserved state; the target cloud hard disk in the reserved state is prohibited from being mounted by any cloud host other than the target cloud host, ensuring that the target cloud hard disk can be uniquely mounted on the target cloud host.

[0077] In some embodiments, the nova-compute component may acquire the task lock of the target cloud host through a secondary thread, and release the task lock when the operation of mounting the target cloud hard disk in the target cloud host executed through the secondary thread is completed.

[0078] Based on the above task lock setting, when the target cloud hard disk is mounted on the target cloud host, if the target cloud host also needs to mount other cloud hard disks, the task lock of the target cloud host will be occupied, causing the secondary thread to be blocked waiting for the release of the task lock, thereby achieving the purpose of concurrently mounting cloud hard disks on the same target cloud host on the user side.

[0079] In some embodiments, after the nova-compute component obtains the task lock of the target cloud host through the secondary thread, the nova-compute component can send a mount information request to the cinder-api component. The nova-compute component updates the BDM table in the database according to the mount information returned by the cinder-api component in response to the mount information request; wherein the mount information includes: the drive letter information of the target cloud hard disk in the target cloud host.

[0080] For example, Figure 3 As shown in the figure, after obtaining the task lock of the target cloud host, the nova-compute component sends a request to the cinder-api component to update the target cloud disk status and obtain the backend mounting information, updates the mounting information in the BDM, and completes operations such as mounting the cloud disk by calling the libvirt driver.

[0081] It should be noted that Figure 3For example, three heterogeneous executors receive a message processing response forwarded by the business-side proxy module through the message synchronization mechanism. They then obtain the UUID in the BDM table and query the database based on this UUID to retrieve the BDM table. Because the three heterogeneous executors receive the same UUID, when not under attack, the BDM table contents retrieved by each executor are identical, ensuring data consistency when performing the same operation.

[0082] The cloud hard disk mounting method for the Openstack cloud platform based on the inherent security architecture provided by the present invention can determine whether the execution results of multiple target heterogeneous executors are consistent in a business-side agent unit. When the determination result is that the execution results of the multiple target heterogeneous executors are consistent, the cloud hard disk mounting operation is performed, thereby avoiding the situation where multiple heterogeneous executors successively write the same data or write different data to the database, thereby causing confusion, duplication, or even conflict in the data written in the database. The defect in the prior art that the data written in the database is confused, duplicated, or conflicted when the cloud hard disk mounting operation is performed in the Openstack cloud platform introduced with the inherent security architecture is solved, and the purpose of ensuring the consistency of the data written in the database when mounting the cloud hard disk in the Openstack cloud platform introduced with the inherent security architecture is achieved.

[0083] The present invention also provides a method for uninstalling a cloud hard disk of an Openstack cloud platform with an inherent security architecture. The introduction of the inherent security architecture can be found in the corresponding description of each unit in the content security architecture 200 in the above embodiment, which will not be repeated here.

[0084] like Figure 4 As shown, the cloud hard disk uninstallation method of the Openstack cloud platform with an inherent security architecture includes the following S410 to S460.

[0085] S410: The user-side agent unit receives a second Restful request for uninstalling the cloud hard disk from the UI; the second Restful request carries the first identifier of the target cloud host and the second identifier of the target cloud hard disk.

[0086] The first identifier of the target cloud host is, for example, the UUID of the target cloud host, and the second identifier of the target cloud hard disk is, for example, the UUID of the target cloud hard disk.

[0087] S420: The user-side proxy unit copies and distributes the second Restful request to k target heterogeneous executors among the m heterogeneous executors; m and k are positive integers, and m≥k≥3.

[0088] When the user-side agent unit selects k target heterogeneous executors from m heterogeneous executors, it can first determine the heterogeneous executors in a normal state based on relevant parameters in each heterogeneous executor, and randomly select k target heterogeneous executors from all heterogeneous executors in a normal state.

[0089] For example, Figure 5 As shown, k is 3, and the user-side agent unit randomly selects 3 nova-api components in normal state from multiple nova-api components (corresponding to Figure 5 In nova-api), the second Restful request is copied and distributed to the three selected nova-api components.

[0090] S430: In response to the received second Restful request, the target heterogeneous executor sends an RPC Call asynchronous message carrying the first identifier and the second identifier to the service-side proxy unit when determining that the target cloud host is in an available state.

[0091] After receiving the second Restful request, the target heterogeneous executor first checks whether the target cloud host meets the offloading requirements, such as whether the target cloud host is in an available state.

[0092] The target cloud host is in an available state, including active or shutdown, and has no other tasks running.

[0093] S440: The service-side agent unit determines whether the RPC Call asynchronous messages of all target heterogeneous executors are consistent.

[0094] The service-side agent unit determines whether the RPC Call asynchronous messages of all target heterogeneous executors are consistent, and obtains a third determination result.

[0095] If the third determination result is yes, that is, if the RPC Call asynchronous messages of all target heterogeneous execution bodies are consistent, S450 is executed.

[0096] When the third judgment result is no, that is, when the RPC Call asynchronous messages of all target heterogeneous executors are inconsistent, the identification information of the third abnormal heterogeneous executor in the abnormal state among the k target heterogeneous executors is obtained, and the identification information of the third abnormal heterogeneous executor is sent to the feedback control unit, and the feedback control unit rotates and cleans the third abnormal heterogeneous executor.

[0097] S450: The nova-compute component monitors the rabbitmq message queue to obtain a second message carrying the first identifier and the second identifier, which is sent by the service-side agent unit to the rabbitmq message queue when the third determination result is yes.

[0098] For example, Figure 5 As shown, the nova-compute component ( Figure 5 The corresponding nova-compute in the example can monitor the RabbitMQ message queue and obtain the second message from the RabbitMQ message queue when the RabbitMQ message queue receives the second message.

[0099] S460: The nova-compute component performs an operation of uninstalling the target cloud hard disk in the target cloud host according to the first identifier and the second identifier.

[0100] For example, Figure 5 As shown in the figure, the nova-compute component first obtains the task lock for the target cloud host and creates a record of the cloud drive unmounting operation in the database. This record includes information such as the target cloud host's primary identifier and the target cloud drive's secondary identifier. Creating this record facilitates task rollbacks and allows administrators to view operation logs and other information.

[0101] While creating the cloud drive unmounting operation record, the nova-compute component can send a second state change request to the cinder-api component, requesting that the cinder-api component change the state of the target cloud drive. In response to the second state change request, the cinder-api component sets the state of the target cloud drive to "unmounting."

[0102] The nova-compute component queries the status of the target cloud host, obtains the BDM table containing the first identifier and the second identifier from the database, obtains the mount information (such as the drive letter) of the target cloud disk from the BDM table, and then the libvirt driver unmounts the target cloud disk from the target cloud host.

[0103] Finally, the nova-compute component deletes the BDM table containing the first and second identifiers in the database and calls the cinder-api component again to change the status of the target cloud disk to available, allowing other cloud hosts to mount, delete, and perform other operations on the target cloud disk.

[0104] Finally, release the task lock to complete the process of uninstalling the target cloud hard drive.

[0105] Please continue to see Figure 5As shown, the nova-api component sends the RPCCall asynchronous message to the business-side agent unit to uninstall the cloud hard disk, and also returns the uninstall response message to the user-side agent unit. The user-side agent unit determines whether the uninstall response messages of all received target heterogeneous executors are consistent and obtains the fourth determination result.

[0106] When the fourth determination result is yes, that is, when the uninstall response messages of all target heterogeneous executables are consistent, the fourth determination result is sent to the UI for display.

[0107] When the fourth determination result is negative, that is, when the uninstall response messages of all target heterogeneous executors are inconsistent, the identification information of the fourth abnormal heterogeneous executor in the target heterogeneous executors that is in an abnormal state is obtained, and the identification information of the fourth abnormal heterogeneous executor is sent to the feedback control unit, and the feedback control unit rotates and cleans the fourth abnormal heterogeneous executor.

[0108] The cloud hard disk unloading method of the Openstack cloud platform based on the inherent security architecture provided by the present invention can determine whether the execution results of multiple target heterogeneous executors are consistent in the business-side agent unit. When the determination result is that the execution results of the multiple target heterogeneous executors are consistent, the cloud hard disk unloading operation is performed, thereby avoiding the situation where multiple heterogeneous executors successively write the same data or write different data to the database, thereby causing confusion, duplication, or even conflict in the data written in the database. The defect in the prior art that the data written in the database is confused, repeated, or conflicting when the cloud hard disk unloading operation is performed in the Openstack cloud platform introduced with the inherent security architecture is solved, and the purpose of ensuring the consistency of the data written in the database when unloading the cloud hard disk in the Openstack cloud platform introduced with the inherent security architecture is achieved.

[0109] The embodiments of the present invention can achieve the following beneficial effects:

[0110] 1. Compared to other built-in security architectures, the addition of nova-api to the database requires that database operation records for mounting and unmounting cloud drives and the creation of the block_device_mapping table be processed by the business-side agent for adjudication, significantly impacting cloud drive mounting and unmounting efficiency and increasing system instability. By validating and calculating request parameters within the heterogeneous executor, nova-api saves the original database input to memory and sends it as the request message content to the business-side agent for adjudication. This single adjudication by the business-side agent eliminates the multiple database additions, deletions, and modifications that would have occurred in the original heterogeneous executor. Database additions, deletions, and modifications are handled by the business-layer unit nova-compute, significantly reducing the complexity of the cloud drive mounting process and improving cloud drive mounting efficiency.

[0111] 2. Compared with native OpenStack cloud platforms (OpenStack cloud platforms without an inherent security architecture), by converting multiple nova-APIs into multiple heterogeneous executors to simultaneously perform cloud disk mounting and unmounting tasks, the cloud platform's security during cloud disk mounting and unmounting operations is enhanced through its dynamic, heterogeneous, and redundant features.

[0112] 3. Since each business-side proxy unit decision consumes a lot of time and resources, two RPC call message calls are changed to one RPC call call. Therefore, the entire cloud drive mounting process only needs to execute a single RPC call synchronously to complete the entire function, simplifying the cloud drive mounting process and improving the efficiency of the cloud drive mounting process.

[0113] 4. Implementing concurrent cloud drive mounting operations. To enable concurrent cloud drive mounting operations on the same cloud host, a coroutine mechanism (i.e., creating a secondary thread) is added to the cloud drive mounting process in the nova-compute service to ensure that after writing data such as the block_device_mapping (BDM table) and operation logs to the database, the data is immediately returned to the nova-api service (the executor of the nova-api service, the target heterogeneous executor in this invention). A task lock mechanism is also added to resolve conflicts when mounting multiple cloud drives on the same cloud host simultaneously.

[0114] Figure 6 An example of a physical structure diagram of an electronic device is shown below. Figure 6As shown, the electronic device may include: a processor 610 , a communications interface 620 , a memory 630 and a communication bus 640 , wherein the processor 610 , the communications interface 620 and the memory 630 communicate with each other via the communication bus 640 . The processor 610 can call the logic instructions in the memory 630 to execute the cloud hard disk mounting method of the Openstack cloud platform based on the intrinsic security architecture, and the method includes: the user-side agent unit receives the first Restful request for mounting the cloud hard disk from the UI; the first Restful request carries the first identifier of the target cloud host and the second identifier of the target cloud hard disk; the user-side agent unit copies and distributes the first Restful request to n target heterogeneous executors among the m heterogeneous executors; m and n are positive integers, m≥n≥3; the target heterogeneous executor responds to the received first Restful request, and creates BDM information when it determines that the target cloud host and the target cloud hard disk are both in an available state; the business-side agent unit receives the RPC Call synchronization message carrying the BDM information, the first identifier and the second identifier from the target heterogeneous executor, and performs RPC synchronization on all target heterogeneous executors. The nova-compute component judges whether the BDM information in the call synchronization message is consistent; the nova-compute component monitors the rabbitmq message queue and obtains the first message carrying the BDM information, the first identifier and the second identifier sent to the rabbitmq message queue by the business side agent unit when the first judgment result is yes; the nova-compute component writes the BDM table obtained according to the BDM information, the first identifier and the second identifier into the database; when the BDM table is successfully written to the database, the nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor and executes the operation of mounting the target cloud hard disk in the target cloud host.

[0115] Alternatively, the processor 610 may call logic instructions in the memory 630 to execute a cloud hard disk unloading method for an Openstack cloud platform based on an intrinsic security architecture, the method comprising: a user-side proxy unit receiving a second Restful request from a UI for unloading a cloud hard disk; the second Restful request carrying a first identifier of a target cloud host and a second identifier of a target cloud hard disk; the user-side proxy unit replicating and distributing the second Restful request to k target heterogeneous executors among m heterogeneous executors; m and k being positive integers, m≥k≥3; in response to the received second Restful request, the target heterogeneous executors sending an RPCCall asynchronous message carrying the first identifier and the second identifier to the business-side proxy unit if it is determined that the target cloud host is in an available state; the business-side proxy unit determining whether the RPC Call asynchronous messages of all target heterogeneous executors are consistent; the nova-compute component monitoring the rabbitmq message queue to obtain a second message carrying the first identifier and the second identifier, which is sent to the rabbitmq message queue by the business-side proxy unit if a third determination result is yes; and the nova-compute component executing an operation of unloading the target cloud hard disk from the target cloud host based on the first identifier and the second identifier.

[0116] Furthermore, the logic instructions in the aforementioned memory 630 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.

[0117] On the other hand, the present invention also provides a computer program product, which includes a computer program, which can be stored on a computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the cloud hard disk mounting method of the Openstack cloud platform based on the intrinsic security architecture provided by the above methods, the method including: a user-side agent unit receives a first Restful request for mounting a cloud hard disk from a UI; the first Restful request carries a first identifier of a target cloud host and a second identifier of a target cloud hard disk; the user-side agent unit copies and distributes the first Restful request to n target heterogeneous executors among m heterogeneous executors; m and n are positive integers, m≥n≥3; the target heterogeneous executor responds to the received first Restful request, and creates BDM information when it determines that the target cloud host and the target cloud hard disk are both in an available state; the business-side agent unit receives an RPC Call synchronization message carrying BDM information, a first identifier and a second identifier from the target heterogeneous executor, and performs RPC synchronization on all target heterogeneous executors. The nova-compute component judges whether the BDM information in the call synchronization message is consistent; the nova-compute component monitors the rabbitmq message queue and obtains the first message carrying the BDM information, the first identifier and the second identifier sent to the rabbitmq message queue by the business side agent unit when the first judgment result is yes; the nova-compute component writes the BDM table obtained according to the BDM information, the first identifier and the second identifier into the database; when the BDM table is successfully written to the database, the nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor and executes the operation of mounting the target cloud hard disk in the target cloud host.

[0118] Alternatively, when the computer program is executed by a processor, the computer can execute the cloud hard disk unloading method for the Openstack cloud platform based on the intrinsic security architecture provided by the above methods, the method comprising: a user-side agent unit receiving a second Restful request for unloading the cloud hard disk from a UI; the second Restful request carrying a first identifier of a target cloud host and a second identifier of a target cloud hard disk; the user-side agent unit replicating and distributing the second Restful request to k target heterogeneous executors among m heterogeneous executors; m and k being positive integers, m≥k≥3; in response to the received second Restful request, the target heterogeneous executors sending an RPC Call asynchronous message carrying the first identifier and the second identifier to the business-side agent unit if it is determined that the target cloud host is in an available state; the business-side agent unit determining whether the RPC Call asynchronous messages of all target heterogeneous executors are consistent; the nova-compute component monitoring the RabbitMQ message queue to obtain a second message carrying the first identifier and the second identifier, which the business-side agent sends to the RabbitMQ message queue if a third determination result is yes; and the nova-compute component executing an operation of unloading the target cloud hard disk from the target cloud host based on the first identifier and the second identifier.

[0119] On the other hand, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which is implemented by a processor to execute the cloud hard disk mounting method of the Openstack cloud platform based on the intrinsic security architecture provided by the above-mentioned methods when the computer program is executed, the method comprising: a user-side agent unit receives a first Restful request for mounting a cloud hard disk from a UI; the first Restful request carries a first identifier of a target cloud host and a second identifier of a target cloud hard disk; the user-side agent unit copies and distributes the first Restful request to n target heterogeneous executors among m heterogeneous executors; m and n are positive integers, m≥n≥3; the target heterogeneous executor responds to the received first Restful request, and creates BDM information when it determines that the target cloud host and the target cloud hard disk are both in an available state; the business-side agent unit receives an RPC Call synchronization message carrying the BDM information, the first identifier and the second identifier from the target heterogeneous executor, and performs RPC synchronization on all target heterogeneous executors. The nova-compute component judges whether the BDM information in the call synchronization message is consistent; the nova-compute component monitors the rabbitmq message queue and obtains the first message carrying the BDM information, the first identifier and the second identifier sent to the rabbitmq message queue by the business side agent unit when the first judgment result is yes; the nova-compute component writes the BDM table obtained according to the BDM information, the first identifier and the second identifier into the database; when the BDM table is successfully written to the database, the nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor and executes the operation of mounting the target cloud hard disk in the target cloud host.

[0120] Alternatively, when the computer program is executed by a processor, it is implemented to perform the cloud hard disk unloading method for the Openstack cloud platform based on the intrinsic security architecture provided by each of the above methods, the method comprising: a user-side agent unit receiving a second RESTful request from a UI to unload the cloud hard disk; the second RESTful request carrying a first identifier of a target cloud host and a second identifier of a target cloud hard disk; the user-side agent unit replicating and distributing the second RESTful request to k target heterogeneous executors among m heterogeneous executors; m and k being positive integers, m≥k≥3; in response to the received second RESTful request, the target heterogeneous executors, upon determining that the target cloud host is in an available state, send an RPC Call asynchronous message carrying the first identifier and the second identifier to the business-side agent unit; the business-side agent unit determines whether the RPC Call asynchronous messages of all target heterogeneous executors are consistent; the nova-compute component monitors the RabbitMQ message queue to obtain a second message carrying the first identifier and the second identifier, which the business-side agent sends to the RabbitMQ message queue if the third determination result is yes; and the nova-compute component, based on the first identifier and the second identifier, performs an operation to unload the target cloud hard disk from the target cloud host.

[0121] 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.

[0122] 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 cloud hard disk mounting method for the Openstack cloud platform based on an inherent security architecture, characterized in that: The inherent security architecture includes a user-side agent unit, a service-side agent unit, and m heterogeneous execution bodies. The method includes: The user-side proxy unit receives a first RESTful request for mounting a cloud hard disk from the UI; the first RESTful request carries a first identifier of a target cloud host and a second identifier of a target cloud hard disk; The user-side proxy unit copies and distributes the first Restful request to n target heterogeneous executors among the m heterogeneous executors; m and n are positive integers, m≥n≥3; In response to the received first Restful request, the target heterogeneous executor creates BDM information if it is determined that the target cloud host and the target cloud hard disk are both in an available state; The service-side agent unit receives an RPC Call synchronization message carrying the BDM information, the first identifier, and the second identifier from the target heterogeneous executor, and determines whether the BDM information in the RPC Call synchronization message of all the target heterogeneous executors is consistent; The nova-compute component monitors the rabbitmq message queue to obtain the first message carrying the BDM information, the first identifier, and the second identifier, which is sent by the service-side agent unit to the rabbitmq message queue when the first determination result is yes; The nova-compute component writes a BDM table obtained according to the BDM information, the first identifier, and the second identifier into a database; The nova-compute component creates a secondary thread when the BDM table is successfully written into the database; The nova-compute component returns the third identifier of the BDM table to the target heterogeneous executor through the current main thread, and executes the operation of mounting the target cloud hard disk in the target cloud host through the secondary thread; The nova-compute component obtains the task lock of the target cloud host through the secondary thread; The nova-compute component sends a mount information request to the cinder-api component; The nova-compute component updates the BDM table in the database according to the mount information returned by the cinder-api component in response to the mount information request; wherein the mount information includes: the drive letter information of the target cloud hard disk in the target cloud host; When the operation of mounting the target cloud hard disk in the target cloud host executed by the secondary thread is completed, the task lock is released.

2. The cloud hard disk mounting method of the Openstack cloud platform based on the inherent security architecture according to claim 1 is characterized in that: After creating the secondary thread, the following steps are also included: The nova-compute component sends a first state change request to the cinder-api component through the secondary thread to change the state of the target cloud hard disk; In response to the received first state change request, the cinder-api component sets the state of the target cloud hard disk to a reserved state; the target cloud hard disk in the reserved state is prohibited from being mounted by any cloud host other than the target cloud host.

3. The cloud hard disk mounting method of the Openstack cloud platform based on the inherent security architecture according to claim 1 is characterized in that: After the user-side proxy unit copies and distributes the first Restful request to n target heterogeneous executors among the m heterogeneous executors, the method further includes: In response to the received first Restful request, the target heterogeneous executor returns an operation conflict message to the user-side proxy unit if it is determined that the target cloud host or the target cloud hard disk is not in the available state; The user-side agent unit sends an operation conflict response message corresponding to the operation conflict message to the UI for display.

4. The cloud hard disk mounting method of the Openstack cloud platform based on the inherent security architecture according to claim 1 is characterized in that: The inherent security architecture further includes: a feedback control unit; after determining whether the BDM information in the RPC Call synchronization message of all the target heterogeneous execution bodies is consistent, it also includes: When the first determination result is negative, the service-side agent unit obtains identification information of a first abnormal heterogeneous executor in an abnormal state among the n target heterogeneous executors, and sends the identification information of the first abnormal heterogeneous executor to the feedback control unit; The feedback control unit rotates and cleans the first abnormal heterogeneous executor.

5. The cloud hard disk mounting method of the Openstack cloud platform based on the inherent security architecture according to claim 4 is characterized in that: After returning the third identifier of the BDM table to the target heterogeneous executable, the method further includes: The user-side proxy unit receives a mount response message returned by the target heterogeneous executor according to the received third identifier; The user-side proxy unit determines whether the mount response messages returned by all the target heterogeneous execution bodies are consistent; and obtains a second determination result; If the second decision result is yes, sending the second decision result to the UI for display; If the second determination result is negative, obtaining identification information of a second abnormal heterogeneous executor in an abnormal state among all current target heterogeneous executors, and sending the identification information of the second abnormal heterogeneous executor to the feedback control unit; The feedback control unit rotates and cleans the second abnormal heterogeneous executor.

6. A cloud hard disk uninstallation method for the Openstack cloud platform based on an inherent security architecture, characterized in that: The inherent security architecture includes a user-side agent unit, a service-side agent unit, and m heterogeneous execution bodies. The method includes: The user-side proxy unit receives a second RESTful request from the UI for uninstalling the cloud hard disk; the second RESTful request carries the first identifier of the target cloud host and the second identifier of the target cloud hard disk; The user-side proxy unit copies and distributes the second Restful request to k target heterogeneous executors among the m heterogeneous executors; m and k are positive integers, m≥k≥3; In response to the received second Restful request, the target heterogeneous executor sends an RPC Call asynchronous message carrying the first identifier and the second identifier to the service-side proxy unit if it is determined that the target cloud host is in an available state; The service-side agent unit determines whether the RPC Call asynchronous messages of all the target heterogeneous execution bodies are consistent; The nova-compute component monitors the rabbitmq message queue to obtain the second message carrying the first identifier and the second identifier sent by the service-side agent unit to the rabbitmq message queue when the third determination result is yes; The nova-compute component performs an operation of uninstalling the target cloud hard disk in the target cloud host according to the first identifier and the second identifier.

7. The cloud hard disk uninstallation method of the Openstack cloud platform based on the inherent security architecture according to claim 6 is characterized in that: The nova-compute component performs an operation of uninstalling the target cloud hard disk in the target cloud host according to the first identifier and the second identifier, including: The nova-compute component obtains the task lock of the target cloud host according to the first identifier; The nova-compute component obtains a BDM table including the first identifier and the second identifier from a database according to the first identifier and the second identifier; The nova-compute component uninstalls the target cloud hard disk from the target cloud host according to the mount information of the target cloud hard disk in the BDM table; The nova-compute component deletes the BDM table in the database; The nova-compute component sends a second state change request to the cinder-api component; In response to the received second status change request, the cinder-api component sets the status of the target cloud hard disk to be usable.

8. The cloud hard disk uninstallation method of the Openstack cloud platform based on the inherent security architecture according to claim 6 is characterized in that: The inherent security architecture further includes: a feedback control unit; after the service-side agent unit determines whether the RPC Call asynchronous messages of all target heterogeneous execution bodies are consistent, it also includes: When the third determination result is negative, the service-side agent unit obtains identification information of a third abnormal heterogeneous executor in an abnormal state among all the target heterogeneous executors, and sends the identification information of the third abnormal heterogeneous executor to the feedback control unit; The feedback control unit rotates and cleans the third abnormal heterogeneous execution body.

9. The cloud hard disk uninstallation method of the Openstack cloud platform based on the inherent security architecture according to claim 8 is characterized in that: In response to the received second Restful request, the target heterogeneous executor sends an RPC Call asynchronous message carrying the first identifier and the second identifier to the service-side proxy unit when determining that the target cloud host is in an available state. The method further includes: The target heterogeneous executor returns an uninstall response message to the user-side agent unit; After receiving the uninstallation response message, the user-side agent unit performs consistency determination on the uninstallation response messages returned by all the target heterogeneous execution bodies to obtain a fourth determination result; If the fourth decision result is yes, sending the fourth decision result to the UI for display; If the fourth determination result is negative, obtaining identification information of a fourth abnormal heterogeneous executor in an abnormal state among all the target heterogeneous executors, and sending the identification information of the fourth abnormal heterogeneous executor to the feedback control unit; The feedback control unit rotates and cleans the fourth abnormal heterogeneous execution body.

Images