Mimicry cloud platform executor synchronization system and method, electronic equipment and storage medium

Abstract

The invention provides a mimicry cloud platform executor synchronization system and method, electronic equipment and a storage medium, and the system comprises a central scheduling module which is used for issuing a central scheduling instruction carrying identifiers of an unreliable executor, a standby executor and a source executor to an executor agent module after receiving an executor exception report; the executor agent module is used for responding to the instruction, using the agent service of the unreliable executor to enable the unreliable executor to be offline, calling the data synchronization module to complete a data synchronization task between the standby executor and the source executor, and using the agent service of the standby executor to enable the standby executor to be online; the data synchronization module is used for establishing FTP connection between the standby execution body and the source execution body, decoupling metadata of the source execution body and respectively synchronizing three types of data obtained by decoupling to the standby execution body, reliable and efficient data synchronization can be carried out on the standby execution body and the source execution body before the standby execution body is scheduled to be online, the whole process consumes less time, and the efficiency is high. And the user experience is not influenced.

Description

Technical Field

[0001] The present invention relates to the field of mimicry defense technology, and in particular to a mimicry cloud platform execution body synchronization system, method, electronic device and storage medium. Background Art

[0002] When the executor of the mimetic cloud platform is detected to have abnormal output due to attacks or other reasons, it needs to be handled in a timely manner, otherwise the subsequent system business will be affected and cause abnormalities. The negative feedback scheduler needs to schedule the unreliable executor to go offline and schedule the backup executor to go online to maintain the normal operation of the mimetic system. The key problem that needs to be solved in this process is how to reliably and efficiently synchronize data with the current normal operating executor before scheduling the backup executor online, ensuring that the internal state of the newly online executor is consistent with the normal operating executor, and the whole process takes less time and does not affect the user experience. Summary of the invention

[0003] The present invention provides a mimetic cloud platform executor synchronization system, method, electronic device and storage medium, which are used to achieve reliable and efficient data synchronization between a backup executor and a source executor before the backup executor is scheduled to go online, and the whole process is less time-consuming and does not affect the user experience.

[0004] The present invention provides a virtual cloud platform execution body synchronization system, including: a central scheduling module, an execution body proxy module and a data synchronization module; wherein: The central scheduling module is used to send the central scheduling instruction carrying the identification of the unreliable executor, the backup executor and the source executor to the executor proxy module after receiving the executor abnormality report; The executor proxy module is used to respond to the central scheduling instruction, use the proxy service of the unreliable executor to perform offline operation on the unreliable executor, call the data synchronization module to complete the data synchronization task between the standby executor and the source executor, and use the proxy service of the standby executor to perform online operation on the standby executor; The data synchronization module is used to establish a file transfer protocol connection between the backup executor and the source executor, decouple the metadata of the source executor, and synchronize the decoupled local data, keyword mapping data and database table data to the backup executor respectively.

[0005] According to a mimetic cloud platform execution body synchronization system provided by the present invention, the central scheduling module is also used for: Determining the unreliable actuator based on the actuator abnormality report; Randomly selecting the standby executor from the remaining executors after excluding the newly offline executor from the standby executor pool; Searching for an online executable with the latest metadata from multiple online executables as a candidate source executable, wherein the online executable with the latest metadata is an executable that has been synchronized online normally and is running stably or an executable that was last offline when the mimic cloud platform is shut down; If the number of the candidate source execution bodies exceeds one, the candidate source execution body with the shortest network path to the backup execution body is selected from the plurality of candidate source execution bodies as the source execution body.

[0006] According to a mimetic cloud platform execution body synchronization system provided by the present invention, the data synchronization module includes: A local data synchronization submodule, used to generate a local data file list based on a pre-configured resource rule, send the local data file list to the standby execution body, and send each corresponding local data file in the local data file list to the standby execution body in turn; A keyword mapping synchronization submodule is used to obtain an original hash mapping table, delete the key-value pair of the unreliable executable body in the original hash mapping table, and insert a data item with the identifier of the backup executable body as the key and the resource data index of the source executable body as the value in the original hash mapping table based on the key-value pair of the source executable body, so as to synchronously update the original hash mapping table; the original hash mapping table is used to store keyword mapping relationships in a hash mapping manner, the keyword mapping relationships are obtained by extracting keywords from multi-channel response messages, and the keyword mapping relationships include mapping relationships between each executable body and the resource data index; The database table synchronization submodule is used to synchronize the database tables of the components of the source execution body to the backup execution body in full, and synchronize the incremental database tables added during the full synchronization process to the backup execution body.

[0007] According to a mimetic cloud platform execution body synchronization system provided by the present invention, the database table synchronization submodule includes: A full synchronization unit, used for exporting the database tables of the components of the source executable body, sending the database tables of the components of the source executable body to the backup executable body, and importing the database tables of the components of the source executable body into the database of the backup executable body; The incremental synchronization unit is used to export the modification log files of the database table read and written by each component of the source execution body, send each modification log file to the standby execution body, and incrementally update the database of the standby execution body based on each modification log file.

[0008] A mimic cloud platform execution body synchronization system provided by the present invention also includes: The collaborative control module is used to orchestrate the various data synchronization tasks in a parallel scenario where multiple standby executors are synchronously online, coordinate resource access conflicts between the standby executors, and coordinate specialized processing caused by architectural differences and / or operating system differences between heterogeneous executors during the synchronization process.

[0009] A mimic cloud platform execution body synchronization system provided by the present invention also includes: The data cleaning module is used to respond to the central scheduling instruction, clear the metadata of the unreliable executable body, and place the cleaned unreliable executable body into a backup executable body pool.

[0010] The present invention also provides a method for synchronizing an executable body of a mimic cloud platform, comprising: After receiving the abnormal report of the execution body, a central dispatch instruction carrying the identification of the unreliable execution body, the backup execution body and the source execution body is generated; In response to the central dispatch instruction, the unreliable executor is offlined by using the proxy service of the unreliable executor; Establishing a file transfer protocol connection between the standby execution body and the source execution body, decoupling the metadata of the source execution body, and synchronizing the decoupled local data, keyword mapping data and database table data to the standby execution body respectively; The proxy service of the standby executive body is used to perform an online operation on the standby executive body.

[0011] 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, wherein when the processor executes the program, the method for synchronizing an executable body of a mimetic cloud platform as described above is implemented.

[0012] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method for synchronizing an executable body of a simulated cloud platform.

[0013] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements the above-mentioned method for synchronizing an executable body of a mimetic cloud platform.

[0014] The present invention provides a virtual cloud platform execution body synchronization system, method, electronic device and storage medium, the system includes a central scheduling module, an execution body proxy module and a data synchronization module; wherein: the central scheduling module is used to send a central scheduling instruction carrying the identification of the unreliable execution body, the backup execution body and the source execution body to the execution body proxy module after receiving the execution body abnormality report; the execution body proxy module is used to respond to the central scheduling instruction, use the proxy service of the unreliable execution body to take the unreliable execution body offline, call the data synchronization module to complete the data synchronization task between the backup execution body and the source execution body, and use the proxy service of the backup execution body to perform the offline operation on the backup execution body. The execution body performs online operations; the execution body proxy module is equivalent to a middleware between the scheduling layer and the real execution body, which can shield the different underlying implementations of all heterogeneous execution bodies, and can implement the online and offline actions of each execution body for different execution bodies, and synchronize the data with the source execution body before the standby execution body is scheduled online; the data synchronization module is used to establish a file transfer protocol connection between the standby execution body and the source execution body, decouple the metadata of the source execution body, and synchronize the decoupled local data, keyword mapping data and database table data to the standby execution body respectively, so that the standby execution body can be reliably and efficiently synchronized with the source execution body. And the whole process takes less time, does not require user participation, and does not affect the user experience. Therefore, the present invention can reliably and efficiently synchronize the data between the standby execution body and the source execution body before the standby execution body is scheduled online, and the whole process takes less time, and does not affect the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces 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.

[0016] Figure 1 It is a structural diagram of the virtual cloud platform execution body synchronization system provided by an embodiment of the present invention.

[0017] Figure 2 It is a flowchart of the method for synchronizing an executable body of a mimic cloud platform provided in an embodiment of the present invention.

[0018] Figure 3 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0020] Open source cloud management systems (such as OpenStack) provide various resource management and application services in the form of independent components. Users can combine and build on demand according to actual scenarios. They are highly decoupled and flexible, and are widely deployed and used in cloud computing and cloud platforms. However, the frequent network security incidents in recent years have also attracted widespread attention and concern. In response to this series of incidents, the current common solution is to patch, which is a last-ditch approach that cannot fundamentally solve the problem. However, the virtual OpenStack designed based on the Dynamic Heterogeneous Redundancy (DHR) architecture can effectively defend against unknown backdoors and vulnerabilities without any prior knowledge, improve system security, and eliminate system risks.

[0021] The OpenStack system with mimetic structure is built with heterogeneous general-purpose servers. Among them, the client is the entrance for users to access the operating cloud platform and perform user interaction. The executor set is a group of OpenStack control nodes designed according to the DHR architecture. The OpenStack control node is responsible for the specific allocation of computing resources. The distribution voter is responsible for distributing the input requests of the client or control node to multiple executors, and adjudicating the output responses of multiple executors and returning them to the client or control node. Once an abnormality is detected in the output of the executor, an abnormality report will be generated and actively reported to the negative feedback scheduler. The negative feedback scheduler archives and analyzes the received abnormality reports, dynamically schedules and manages the executors according to the built-in strategy, and maintains the healthy operation of the entire system.

[0022] When the executor is detected to have abnormal output due to an attack or other reasons, it needs to be handled in a timely manner, otherwise the subsequent system business will be affected and cause abnormalities. The negative feedback scheduler needs to schedule the unreliable executor to go offline, and schedule the backup executor to go online to maintain the normal operation of the mimic system. The key problem that needs to be solved in this process is how to reliably and efficiently synchronize the data between the backup executor and the currently normal operating executor before scheduling it online, ensuring that the internal state of the newly online executor is consistent with the normal operating executor, and the whole process takes less time and does not affect the user experience.

[0023] Based on this, an embodiment of the present invention provides a virtual cloud platform execution body synchronization system, method, electronic device and storage medium, which are described in detail below.

[0024] Combine the following Figure 1 The simulated cloud platform execution body synchronization system of the present invention is described. The simulated cloud platform may be a simulated OpenStack cloud platform, but the present embodiment is not limited thereto.

[0025] Please refer to Figure 1 , Figure 1 Schematic diagram of the structure of the virtual cloud platform execution synchronization system provided by the embodiment of the present invention. Figure 1 As shown, the system includes a central scheduling module 1, an execution agent module 2 and a data synchronization module 3.

[0026] The central scheduling module 1 is used to send the central scheduling instruction carrying the identification of the unreliable executor, the backup executor and the source executor to the executor proxy module 2 after receiving the executor abnormality report.

[0027] Exemplarily, when the distribution voter detects that the output of the execution body is abnormal, it generates an execution body abnormality report and actively reports the execution body abnormality report to the central scheduling module 1. After receiving the execution body abnormality report, the central scheduling module 1 assumes that the unreliable execution body is the execution body 1, the standby execution body is the execution body 4, the source execution body is the execution body 3, the unreliable execution body is the execution body with abnormal output, and the source execution body is the execution body currently running normally, and sends the central scheduling instruction carrying <Executor 1, Executor 4, Executor 3> to the execution body proxy module 2.

[0028] The execution body proxy module 2 is used to respond to the central scheduling instructions, use the proxy service of the unreliable execution body to take the unreliable execution body offline, call the data synchronization module 3 to complete the data synchronization task between the backup execution body and the source execution body, and use the proxy service of the backup execution body to bring the backup execution body online.

[0029] Specifically, taking the pseudo-OpenStack cloud platform as an example, the executor proxy module 2 is equivalent to a middleware between the scheduling layer and the real executor, which can shield the different underlying implementations of all heterogeneous executors. The executor proxy module 2 provides a proxy service for each executor, and the proxy service and the executor are bound one-to-one. In response to the central scheduling instruction, the unreliable executor is offlined using the proxy service of the unreliable executor, that is, the OpenStack service of the unreliable executor is shut down. The OpenStack service includes components such as Keystone, Nova, Neutron, Glance, and Placement. Call the data synchronization module 3 to complete the data synchronization task between the backup executor and the source executor, and use the proxy service of the backup executor to go online on the backup executor, that is, start the OpenStack service of the backup executor. The status monitoring and operation and maintenance of the OpenStack service can be achieved through Linux instructions, OpenStack API, etc.

[0030] The data synchronization module 3 is used to establish a file transfer protocol connection between the standby execution body and the source execution body, decouple the metadata of the source execution body, and synchronize the decoupled local data, keyword mapping data and database table data to the standby execution body respectively.

[0031] Specifically, the data synchronization module 3 is the key link of the execution body synchronization, and is responsible for the specific implementation of the execution body metadata synchronization process. First, a File Transfer Protocol (FTP) connection is established between the standby execution body and the source execution body. Then, the metadata of the source execution body is decoupled and divided into three categories at the data level: ① Local data, which is the business resource data stored locally in the source execution body. This type of data has been determined when the heterogeneous execution body is constructed, and it is configured as a local resource file list to read; ② Keyword mapping data, which is the mapping relationship data of different indexes of the same resource extracted by the request for the heterogeneous execution body during the distribution and arbitration process, and corresponds to the execution body one by one; ③ Database table data, which is the business data stored in the SQL database during the operation of the cloud platform, is the core data of OpenStack, and each component is managed by a library table. The local data, keyword mapping data and database table data are synchronized to the standby execution body respectively, and these three types of data are processed independently without interfering with each other.

[0032] In addition, the data synchronization module 3 will report the synchronization status of the three types of data to the central scheduling module 1. After all the synchronization statuses are completed, the standby execution body will be put into operation.

[0033] The emulated cloud platform execution body synchronization system provided by the embodiment of the present invention includes a central scheduling module, an execution body proxy module and a data synchronization module; wherein: the central scheduling module is used to send a central scheduling instruction carrying the identification of the unreliable execution body, the backup execution body and the source execution body to the execution body proxy module after receiving the execution body abnormality report; the execution body proxy module is used to respond to the central scheduling instruction, use the proxy service of the unreliable execution body to take the unreliable execution body offline, call the data synchronization module to complete the data synchronization task between the backup execution body and the source execution body, and use the proxy service of the backup execution body to bring the backup execution body online Operation; The execution body proxy module is equivalent to a middleware between the scheduling layer and the real execution body, which can shield the different underlying implementations of all heterogeneous execution bodies, and can implement the online and offline actions of each execution body for different execution bodies, and synchronize the data with the source execution body before the standby execution body is scheduled online; The data synchronization module is used to establish a file transfer protocol connection between the standby execution body and the source execution body, decouple the metadata of the source execution body, and synchronize the decoupled local data, keyword mapping data and database table data to the standby execution body respectively, so that the standby execution body and the source execution body can be reliably and efficiently synchronized. And the whole process takes less time, does not require user participation, and does not affect the user experience. Therefore, the embodiment of the present invention can reliably and efficiently synchronize the data between the standby execution body and the source execution body before the standby execution body is scheduled online, and the whole process takes less time and does not affect the user experience.

[0034] Furthermore, the virtual cloud platform execution body synchronization system of this embodiment is lightweight, simple to deploy, and does not require excessive human intervention. Moreover, it is universal and can be extended to other virtual systems.

[0035] In one embodiment, the central scheduling module 1 is also used to: determine an unreliable executor based on an executor exception report; randomly select a backup executor from the remaining executors after excluding the newly offline executor from the backup executor pool; search for an online executor with the latest metadata from multiple online executors as a candidate source executor, where the online executor with the latest metadata is an executor that has been synchronized online normally and is running stably or an executor that was last offline when the mimic cloud platform was shut down; if the number of candidate source executors exceeds one, select a candidate source executor with the shortest network path to the backup executor from multiple candidate source executors as the source executor.

[0036] For example, taking the virtual OpenStack cloud platform as an example, the executor set of the virtual OpenStack cloud platform is a group of OpenStack control nodes designed according to the DHR architecture, using heterogeneous architectures such as X86 and ARM and different operating systems such as CentOS and Ubuntu. Assume that executors 1, 2, and 3 are running online, and executors 4-N are executors in the standby executor pool.

[0037] The central scheduling module 1 analyzes the execution body abnormality report to find that the execution body 1 is attacked, resulting in abnormal judgment, and marks the execution body 1 as an unreliable execution body.

[0038] After excluding the newly offline executor from the backup executor pool, randomly select an executor from the remaining executors, for example, select executor 4 as the backup executor to replace executor 1. First, random selection is for unpredictability, which can give play to the advantages of heterogeneous executors. Secondly, excluding the newly offline executor from this random strategy is a reinforcement of security. It should be noted that generally, the executor will go offline only when there is a disturbance. The suspension of this executor for one round is also for security isolation.

[0039] Selecting executor 2 and executor 3 with the latest metadata from executor 2 and executor 3 currently running normally as candidate source executors can ensure that the metadata of the candidate source executors is the latest, and selecting the candidate source executor with the shortest network path to executor 4 as the source executor can improve network transmission efficiency.

[0040] In this embodiment, unreliable executors, backup executors, and source executors can be quickly identified. In addition, by randomly selecting a backup executor from the remaining executors after excluding the newly offline executor from the backup executor pool, the advantages of heterogeneous executors can be brought into play through random selection, and the newly offline executors can be safely isolated, thereby enhancing the security of the system. Selecting one of the online executors as a data synchronization source based on the latest metadata and proximity principles can not only ensure the latest metadata, but also improve network transmission efficiency.

[0041] In one embodiment, the data synchronization module 3 includes: a local data synchronization submodule 31 , a keyword mapping synchronization submodule 32 and a database table synchronization submodule 33 .

[0042] The local data synchronization submodule 31 is used to generate a local data file list based on a pre-configured resource rule, send the local data file list to the standby execution body, and send the corresponding local data files in the local data file list to the standby execution body in sequence.

[0043] Specifically, taking the pseudo-OpenStack cloud platform as an example, the components covered by the source executor include Keystone, Nova, Neutron, Glance, Placement, etc. After the component composition of the source executor is clear, the list of local data files stored locally has been determined, thereby generating local data synchronization rules for each component, that is, pre-configured resource rules. Generate a list of local data files by loading the pre-configured resource rules. The list of local data files may include all mirror files stored locally by the Glance component, etc. An FTP connection is established with the source executor as the server and the standby executor as the client. After the FTP connection is established, the local data file list is first sent to the standby executor through the FTP connection, and then the corresponding local data files in the local data file list are sent to the standby executor in turn through the FTP connection. After all local data files are transferred, the local data synchronization process ends.

[0044] The keyword mapping synchronization submodule 32 is used to obtain the original hash mapping table, delete the key-value pairs of the unreliable executable body in the original hash mapping table, and insert the data item with the identifier of the backup executable body as the key and the resource data index of the source executable body as the value into the original hash mapping table based on the key-value pairs of the source executable body, so as to synchronize and update the original hash mapping table. The original hash mapping table is used to store the keyword mapping relationship in the form of hash mapping. The keyword mapping relationship is obtained by extracting the keywords in the multi-channel response message, and the keyword mapping relationship includes the mapping relationship between each executable body and the resource data index.

[0045] Specifically, taking the pseudo OpenStack cloud platform as an example, users are unaware of heterogeneous executors in client operations. However, the components of the executor itself use a random number strategy to encode resource data, which will cause inconsistent index data between executors. In order to ensure the accuracy of keyword indexing of the same resource data by different executors, the keywords in the multi-channel response messages are extracted to form a keyword mapping relationship, which is stored in the Redis database in the form of hash mapping. The above keywords include but are not limited to the universally unique identifier (UUID), Internet Protocol (IP) address, Media Access Control (Mac) address, token, etc. of resources such as users, projects, networks, subnets, instances, and images.

[0046] Taking instance resources as an example, the general form of the mapping relationship of the hash map is: <executable 1: instance: UUID1; executable 2: instance: UUID2; executable 3: instance: UUID3>. When the virtual OpenStack cloud platform is running, the access consistency of heterogeneous executables to resource data can be guaranteed by querying this data.

[0047] When the central scheduling instruction is received and parsed, it is found that executor 1 is unreliable. The backup executor 4 will be synchronized online with executor 3 as the source executor, and the keyword mapping synchronization will begin. Delete "executor 1: instance: UUID1" in the hash mapping table, and insert "executor 4: instance: UUID3" into the hash mapping table with executor 3 as the baseline, so that executor 4 can index the instance resource. The mapping relationship of the synchronized hash mapping table is updated to <executor 2: instance: UUID2; executor 3: instance: UUID3; executor 4: instance: UUID3>.

[0048] In addition, by updating the mapping relationship of the hash mapping table, the pseudo-OpenStack cloud platform can complete the management access of the standby executor to the resource data in a lightweight manner. Since the pseudo-OpenStack cloud platform manages a large number of resource types and instances, the constructed keyword mapping relationship is large in scale. When synchronizing keyword mappings, Redis's pipeline technology can be used to process mapping data in segments and batches. Specifically, first, the hash type mapping data is obtained in batches; secondly, the source executor is used as the benchmark in the mapping relationship, and the associated data of the standby executor is inserted, and then batch updates are performed again, which can greatly improve the synchronization efficiency while reducing the database access load.

[0049] The database table synchronization submodule 33 is used to synchronize the database tables of each component of the source execution body to the standby execution body in full, and synchronize the incremental database tables added during the full synchronization process to the standby execution body.

[0050] Specifically, the database tables of each component of the source execution body are fully synchronized to the standby execution body. Since the full synchronization of the execution body will take some time, the incremental addition of the database tables added during the full synchronization process can be synchronized to the standby execution body in an incremental manner, thereby ensuring that the metadata of the standby execution body is absolutely consistent with the metadata of the source execution body.

[0051] In this embodiment, on the one hand, the local data synchronization submodule, keyword mapping synchronization submodule and database table synchronization submodule are independent of each other, comply with the design pattern principles, and support inheritance and secondary development; on the other hand, the local data synchronization submodule, keyword mapping synchronization submodule and database table synchronization submodule each complete their own synchronization tasks, and can achieve reliable and efficient data synchronization.

[0052] In one embodiment, the database table synchronization submodule 33 includes: a full synchronization unit 331 and an incremental synchronization unit 332 .

[0053] The full synchronization unit 331 is used to export the database tables of each component of the source executable body, send the database tables of each component of the source executable body to the backup executable body, and import the database tables of each component of the source executable body into the database of the backup executable body.

[0054] For example, each execution body uses MariaDB database to store business data and configures and enables Binlog service, involving keystone, glance, placement, nova_api, nova, nova_cell0, neutron and other databases and all the table items therein. After the database table synchronization starts, a full synchronization is first performed, and the database tables of each component of the source execution body are exported through the database interface, and then transmitted to the standby execution body in sequence, and the database tables of each component of the source execution body are overwritten and imported into the database of the standby execution body.

[0055] The incremental synchronization unit 332 is used to export the modification log files of the database table read and written by each component of the source execution body, send each modification log file to the standby execution body, and incrementally update the database of the standby execution body based on each modification log file.

[0056] Exemplarily, the Binlog file of the source executable body is exported and sent to the standby executable body, and the consistency update of the database of the standby executable body is completed in an incremental manner. The Binlog file is a binary format file used to record the SQL statement information of the user updating the database.

[0057] In this embodiment, the full synchronization unit fully synchronizes the database tables of each component of the source execution body to the backup execution body, and the incremental synchronization unit incrementally synchronizes the newly added database tables during the full synchronization process to the backup execution body, thereby achieving consistent update of the database of the backup execution body.

[0058] In one embodiment, the system further comprises: The collaborative control module 4 is used to orchestrate various data synchronization tasks in a parallel scenario where multiple standby executors are synchronously online, coordinate resource access conflicts between the standby executors, and coordinate specialized processing caused by architectural differences and / or operating system differences between heterogeneous executors during the synchronization process.

[0059] Specifically, the collaborative control module 4 can support the parallel scenarios of multiple standby executors going online synchronously. Based on the design basis of synchronous data decoupling, various data synchronization tasks are arranged, and resource access conflicts between the standby executors are coordinated to achieve one-to-many efficient data synchronization. The collaborative control module 4 can also coordinate the specialized processing caused by architectural differences and / or operating system differences between heterogeneous executors during the synchronization process.

[0060] For example, considering the parallel scenario where multiple standby executors are launched synchronously, since the synchronization process of the executors is decoupled, there is only one copy of the Redis database where the keyword mapping is located, and the collaborative control module 4 can coordinate the synchronization tasks between multiple standby executors and possible multiple source executors to avoid access conflicts of unique resources. In addition, the coordination of executors is caused by the special processing of equipment efficiency differences. The synchronization of executors is an application in which the final experience effect is determined by the shortcomings, so it is necessary to make up for the equipment efficiency differences through coordinated control.

[0061] In this embodiment, in a parallel scenario where multiple standby executors are synchronously online, various data synchronization tasks are arranged and resource access conflicts between the standby executors are coordinated, so that one-to-many efficient data synchronization can be achieved. In addition, specialized processing caused by architecture differences and / or operating system differences between heterogeneous executors during the synchronization process can also be coordinated.

[0062] In one embodiment, the system further comprises: The data cleaning module 5 is used to respond to the central scheduling instruction, clear the metadata of the unreliable executable body, and place the cleaned unreliable executable body into the backup executable body pool.

[0063] Specifically, the data cleaning module 5 receives the central scheduling instruction, analyzes and finds that the executable body 1 is unreliable, and clears the metadata of the executable body 1, so that the executable body 1 can be restored to its initial state. Through data cleaning, the abnormality of the executable body caused by attack or other reasons can be restored, and the hidden dangers of the system can be eliminated. When the cleaning work is completed, the executable body 1 is placed in the backup executable body pool to improve resource utilization.

[0064] In this embodiment, data cleaning can recover the abnormality of the executable body caused by attacks or other reasons, eliminate system risks, and improve resource utilization by placing the unreliable executable body after cleaning into the backup executable body pool.

[0065] The following is a description of the mimetic cloud platform execution body synchronization method provided by the present invention. The mimetic cloud platform execution body synchronization method described below and the mimetic cloud platform execution body synchronization system described above can be referenced to each other.

[0066] Please refer to Figure 2 , Figure 2 Schematic diagram of the process of synchronizing the virtual cloud platform execution body provided by the embodiment of the present invention. Figure 2 As shown, the method may include the following steps: Step 201: after receiving an abnormal report of an executable body, a central dispatch instruction carrying the identifications of an unreliable executable body, a backup executable body and a source executable body is generated; Step 202, responding to the central dispatching instruction, using the proxy service of the unreliable executive to perform offline operation on the unreliable executive; Step 203: Establish a file transfer protocol connection between the standby execution body and the source execution body, decouple the metadata of the source execution body, and synchronize the decoupled local data, keyword mapping data, and database table data to the standby execution body respectively; Step 204: Use the proxy service of the standby executive body to perform an online operation on the standby executive body.

[0067] In one embodiment, step 201 further includes: Determine unreliable actuators based on actuator anomaly reports; A backup executor is randomly selected from the remaining executors after excluding the newly offline executor from the backup executor pool; Search for the online executor with the latest metadata from multiple online executors as the candidate source executor. The online executor with the latest metadata is the executor that has been synchronized online normally and is running stably, or the executor that was last offline when the mimic cloud platform was shut down. If the number of candidate source execution bodies exceeds one, a candidate source execution body having the shortest network path to the backup execution body is selected from the plurality of candidate source execution bodies as the source execution body.

[0068] In one embodiment, step 203 includes: Step 2031: Generate a local data file list based on a pre-configured resource rule, send the local data file list to the standby executor, and send each local data file corresponding to the local data file list to the standby executor in turn; Step 2032: obtain the original hash mapping table, delete the key-value pair of the unreliable executable body in the original hash mapping table, and insert a data item with the identifier of the backup executable body as the key and the resource data index of the source executable body as the value into the original hash mapping table based on the key-value pair of the source executable body, so as to synchronously update the original hash mapping table; the original hash mapping table is used to store the keyword mapping relationship in a hash mapping manner, the keyword mapping relationship is obtained by extracting the keywords in the multi-channel response message, and the keyword mapping relationship includes the mapping relationship between each executable body and the resource data index; Step 2033: Fully synchronize the database tables of the components of the source execution body to the standby execution body, and synchronize the incremental database tables added during the full synchronization process to the standby execution body.

[0069] In one embodiment, step 2033 includes: Exporting the database tables of the components of the source executable body, sending the database tables of the components of the source executable body to the standby executable body, and importing the database tables of the components of the source executable body into the database of the standby executable body overwriting; Export modification log files of database table reading and writing of each component of the source executable body, send each modification log file to the standby executable body, and incrementally update the database of the standby executable body based on each modification log file.

[0070] In one embodiment, the method further comprises: In the parallel scenario where multiple standby executors are synchronously launched, various data synchronization tasks are orchestrated, resource access conflicts between the standby executors are coordinated, and specialized processing caused by architectural differences and / or operating system differences between heterogeneous executors during the synchronization process is coordinated.

[0071] In one embodiment, the method further comprises: In response to the central scheduling instruction, the metadata of the unreliable executor is cleared, and the cleaned unreliable executor is placed in the backup executor pool.

[0072] Please refer to Figure 3 , Figure 3 Schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 3 As shown, the electronic device may include: a processor 310, a communication interface 320, a memory 330 and a communication bus 340, wherein the processor 310, the communication interface 320 and the memory 330 communicate with each other through the communication bus 340. The processor 310 may call the logic instructions in the memory 330 to execute the emulated cloud platform execution body synchronization method, the method comprising: after receiving the execution body abnormality report, generating a central scheduling instruction carrying the identification of the unreliable execution body, the backup execution body and the source execution body; responding to the central scheduling instruction, using the proxy service of the unreliable execution body to perform offline operation on the unreliable execution body; establishing a file transfer protocol connection between the backup execution body and the source execution body, decoupling the metadata of the source execution body, and synchronizing the decoupled local data, keyword mapping data and database table data to the backup execution body respectively; using the proxy service of the backup execution body to perform online operation on the backup execution body.

[0073] In addition, the logic instructions in the above-mentioned memory 330 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0074] On the other hand, the present invention also provides a computer program product, which includes a computer program, which can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the mimetic cloud platform executor synchronization method provided by the above-mentioned method embodiments, the method including: after receiving an executor abnormality report, generating a central scheduling instruction carrying the identification of an unreliable executor, a backup executor and a source executor; responding to the central scheduling instruction, using the proxy service of the unreliable executor to take the unreliable executor offline; establishing a file transfer protocol connection between the backup executor and the source executor, decoupling the metadata of the source executor, and synchronizing the decoupled local data, keyword mapping data and database table data to the backup executor respectively; using the proxy service of the backup executor to bring the backup executor online.

[0075] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it is implemented to execute the mimetic cloud platform executor synchronization method provided by the above-mentioned method embodiments. The method includes: after receiving an executor abnormality report, generating a central scheduling instruction carrying the identifications of an unreliable executor, a backup executor and a source executor; responding to the central scheduling instruction, using the proxy service of the unreliable executor to take the unreliable executor offline; establishing a file transfer protocol connection between the backup executor and the source executor, decoupling the metadata of the source executor, and synchronizing the decoupled local data, keyword mapping data and database table data to the backup executor respectively; and using the proxy service of the backup executor to bring the backup executor online.

[0076] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0077] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0078] 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 embodiments of the present invention.

Claims

1. A virtual cloud platform execution body synchronization system, characterized in that: include: Central scheduling module, execution agent module and data synchronization module; among which: The central scheduling module is used to send the central scheduling instruction carrying the identification of the unreliable executor, the backup executor and the source executor to the executor proxy module after receiving the executor abnormality report; The executor proxy module is used to respond to the central scheduling instruction, use the proxy service of the unreliable executor to perform offline operation on the unreliable executor, call the data synchronization module to complete the data synchronization task between the standby executor and the source executor, and use the proxy service of the standby executor to perform online operation on the standby executor; The data synchronization module is used to establish a file transfer protocol connection between the backup executor and the source executor, decouple the metadata of the source executor, and synchronize the decoupled local data, keyword mapping data and database table data to the backup executor respectively.

2. The virtual cloud platform execution body synchronization system according to claim 1, characterized in that: The central scheduling module is also used for: Determining the unreliable actuator based on the actuator abnormality report; Randomly selecting the standby executor from the remaining executors after excluding the newly offline executor from the standby executor pool; Searching for an online executable with the latest metadata from multiple online executables as a candidate source executable, wherein the online executable with the latest metadata is an executable that has been synchronized online normally and is running stably or an executable that was last offline when the mimic cloud platform is shut down; If the number of the candidate source execution bodies exceeds one, the candidate source execution body with the shortest network path to the backup execution body is selected from the plurality of candidate source execution bodies as the source execution body.

3. The virtual cloud platform execution body synchronization system according to claim 1, characterized in that: The data synchronization module includes: A local data synchronization submodule, used to generate a local data file list based on a pre-configured resource rule, send the local data file list to the standby execution body, and send each corresponding local data file in the local data file list to the standby execution body in turn; A keyword mapping synchronization submodule is used to obtain an original hash mapping table, delete the key-value pair of the unreliable executable body in the original hash mapping table, and insert a data item with the identifier of the backup executable body as the key and the resource data index of the source executable body as the value in the original hash mapping table based on the key-value pair of the source executable body, so as to synchronously update the original hash mapping table; the original hash mapping table is used to store keyword mapping relationships in a hash mapping manner, the keyword mapping relationships are obtained by extracting keywords from multi-channel response messages, and the keyword mapping relationships include mapping relationships between each executable body and the resource data index; The database table synchronization submodule is used to synchronize the database tables of the components of the source execution body to the backup execution body in full, and synchronize the incremental database tables added during the full synchronization process to the backup execution body.

4. The virtual cloud platform execution body synchronization system according to claim 3, characterized in that: The database table synchronization submodule includes: A full synchronization unit, used for exporting the database tables of the components of the source executable body, sending the database tables of the components of the source executable body to the backup executable body, and importing the database tables of the components of the source executable body into the database of the backup executable body; The incremental synchronization unit is used to export the modification log files of the database table read and written by each component of the source execution body, send each modification log file to the standby execution body, and incrementally update the database of the standby execution body based on each modification log file.

5. The virtual cloud platform execution body synchronization system according to any one of claims 1 to 4, characterized in that: Also includes: The collaborative control module is used to orchestrate the various data synchronization tasks in a parallel scenario where multiple standby executors are synchronously online, coordinate resource access conflicts between the standby executors, and coordinate specialized processing caused by architectural differences and / or operating system differences between heterogeneous executors during the synchronization process.

6. The virtual cloud platform execution body synchronization system according to any one of claims 1 to 4, characterized in that: Also includes: The data cleaning module is used to respond to the central scheduling instruction, clear the metadata of the unreliable executable body, and place the cleaned unreliable executable body into a backup executable body pool.

7. A method for synchronizing an executable body of a virtual cloud platform, characterized in that: include: After receiving the abnormal report of the execution body, a central dispatch instruction carrying the identification of the unreliable execution body, the backup execution body and the source execution body is generated; In response to the central dispatch instruction, the unreliable executor is offlined by using the proxy service of the unreliable executor; Establishing a file transfer protocol connection between the standby execution body and the source execution body, decoupling the metadata of the source execution body, and synchronizing the decoupled local data, keyword mapping data and database table data to the standby execution body respectively; The proxy service of the standby executive body is used to perform an online operation on the standby executive body.

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 method for synchronizing the virtual cloud platform execution body as described in claim 7 is implemented.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, the method for synchronizing the virtual cloud platform execution body as claimed in claim 7 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by the processor, the method for synchronizing the virtual cloud platform execution body as claimed in claim 7 is implemented.

Images