2*2oo2 safety system based on a cloud platform
Patent Information
- Application Number
- CN202110861010.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-07-29
- Publication Date
- 2026-10-09
- Estimated Expiration
- 2041-07-29
AI Technical Summary
[0003]然而,传统2*2OO2安全系统严重依赖多硬件计算单元构成的硬件架构,具体来说,A系统和B系统需要4个独立的硬件计算单元,管理单元也需要1个独立的硬件计算单元,传统2*2OO2安全系统至少需要5个独立的硬件计算单元
[0015]This application provides a cloud-based 2x2002 security system. The system deploys two 2002 subsystems on at least two cloud hosts, each subsystem comprising virtual machines with different operating systems. When a failure is detected in one subsystem, the first management node switches to the other. Compared to traditional 2x2002 security systems that rely on physical isolation for security, this cloud-based system uses a cloud platform instead of physical hardware. While maintaining security, it effectively improves the availability, reliability, and maintainability of the 2x2002 security system, while also significantly reducing hardware and maintenance costs. Furthermore, since this cloud-based system is based on a traditional cloud architecture, there is no need to redesign the cloud platform's architecture.
Smart Images

Figure CN115686736B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing, and more particularly to a 2*2OO2 security system based on a cloud platform. Background Technology
[0002] The hardware structure of a traditional 2x2OO2 (double 2 out of 2) security system includes a management unit, System A, and System B. System A includes host A1 and host A2, and System B includes host B1 and host B2. Hosts A1, A2, B1, B2, and the management unit each run on independent computers. Hosts A1 and A2 within System A constitute an independent 2x2 system, and System B is similar to System A. System A and System B have identical hardware and software structures, forming a redundant hot standby system, which is the 2x2OO2 security system. Hosts A1 and A2 in System A, hosts B1 and B2 in System B, and the management unit communicate with each other through the internal bus of the security system to achieve functions such as data comparison between the two machines in the same system, primary / standby system management, and primary / standby system switching.
[0003] However, traditional 2x2002 security systems heavily rely on a hardware architecture composed of multiple hardware computing units. Specifically, systems A and B require four independent hardware computing units, and the management unit also requires one independent hardware computing unit, meaning a traditional 2x2002 security system needs at least five independent hardware computing units. Consequently, traditional 2x2002 security systems suffer from high hardware costs, high maintenance costs throughout their lifecycle, significant difficulties in improving reliability and availability, and poor maintainability. Therefore, effectively improving the availability, reliability, maintainability, and cost reduction of 2x2002 security systems has become a pressing technical challenge. Summary of the Invention
[0004] The purpose of this application is to propose a cloud-based 2*2OO2 security system to address the technical problems in the prior art of how to effectively improve the availability, reliability, maintainability, and cost reduction of 2*2OO2 security systems.
[0005] According to a first aspect of the embodiments of this application, a 2*2002 security system based on a cloud platform is provided. The system includes: a first 2002 subsystem, which is set on at least two cloud hosts and includes a first virtual machine and a second virtual machine, the first virtual machine and the second virtual machine having different types of operating systems installed; a second 2002 subsystem, which is set on at least two cloud hosts and includes a fourth virtual machine and a fifth virtual machine, the fourth virtual machine and the fifth virtual machine having different types of operating systems installed; and a first management node, which is set on a cloud host and includes a third virtual machine. The first management node is used to switch to the second 2002 subsystem when a failure is detected in the first 2002 subsystem, or to switch to the first 2002 subsystem when a failure is detected in the second 2002 subsystem.
[0006] Optionally, the system further includes: a second management node, which is located on a cloud host and includes: a sixth virtual machine. The second management node is used to work with the first management node in a redundant hot standby manner.
[0007] Optionally, the first virtual machine is equipped with a first diagnostic component, which is used to obtain a first running state, the first running state including: the running state of the first virtual machine, the application running on the first virtual machine, and at least one of the running states of the first diagnostic component; the second virtual machine is equipped with a second diagnostic component, which is used to obtain a second running state, the second running state including: the running state of the second virtual machine, the application running on the second virtual machine, and at least one of the running states of the second diagnostic component; the first diagnostic component and the second diagnostic component diagnose the running state of the first 2OO2 subsystem by exchanging the first running state and the second running state, and notify the second 2OO2 subsystem of the running state of the first 2OO2 subsystem. The system is as follows: The fourth virtual machine is equipped with a fourth diagnostic component, which is used to obtain a fourth running state, including the running state of the fourth virtual machine, the application running on the fourth virtual machine, and at least one of the fourth diagnostic components; The fifth virtual machine is equipped with a fifth diagnostic component, which is used to obtain a fifth running state, including the running state of the fifth virtual machine, the application running on the fifth virtual machine, and at least one of the fifth diagnostic components; The fourth diagnostic component and the fifth diagnostic component diagnose the running state of the second 2002 subsystem by exchanging the fourth running state and the fifth running state, and notify the first 2002 subsystem of the running state of the second 2002 subsystem.
[0008] Optionally, a third diagnostic component is provided on the cloud host where the first 2002 subsystem resides. The third diagnostic component is used to obtain the operating status of the cloud host where the first 2002 subsystem resides. Based on the operating status of the cloud host and the operating status of the first 2002 subsystem obtained by the first and second diagnostic components, the third diagnostic component determines the final operating status of the first 2002 subsystem and notifies the second 2002 subsystem of the final operating status. A sixth diagnostic component is provided on the cloud host where the second 2002 subsystem resides. The sixth diagnostic component is used to obtain the operating status of the cloud host where the second 2002 subsystem resides. Based on the operating status of the cloud host and the operating status of the second 2002 subsystem obtained by the fourth and fifth diagnostic components, the sixth diagnostic component determines the final operating status of the second 2002 subsystem and notifies the first 2002 subsystem of the final operating status.
[0009] Optionally, the first virtual machine and the second virtual machine exchange input data and perform calculations on the exchanged input data to obtain output data corresponding to the exchanged input data. If the output data is consistent and the first 2002 subsystem is operating normally, then the output of the first 2002 subsystem is valid; otherwise, the output of the first 2002 subsystem is invalid. The fourth virtual machine and the fifth virtual machine exchange input data and perform calculations on the exchanged input data to obtain output data corresponding to the exchanged input data. If the output data is consistent and the second 2002 subsystem is operating normally, then the output of the second 2002 subsystem is valid; otherwise, the output of the second 2002 subsystem is invalid.
[0010] Optionally, the first management node is configured to allocate one of the first virtual machine or the second virtual machine as the first master virtual machine, the first master virtual machine being configured to perform comparison calculations of the output data of the first virtual machine and the second virtual machine, and further allocate one of the fourth virtual machine or the fifth virtual machine as the second master virtual machine, the second master virtual machine being configured to perform comparison calculations of the output data of the fourth virtual machine and the fifth virtual machine.
[0011] Optionally, the first management node is further configured to migrate the input data on the cloud host where the first 2OO2 subsystem is located when the first 2OO2 subsystem fails, or to migrate the input data on the cloud host where the second 2OO2 subsystem is located when the second 2OO2 subsystem fails.
[0012] Optionally, the first management node is further configured to set the first 2OO2 subsystem and the second 2OO2 subsystem as a primary 2OO2 subsystem and a backup 2OO2 subsystem, respectively.
[0013] Optionally, the system further includes: at least one backup cloud host, which, when any cloud host set by the first 2OO2 subsystem and the second 2OO2 subsystem fails, migrates the input data of the failed cloud host to the backup cloud host.
[0014] Optionally, the migration of input data from the faulty cloud host to the backup cloud host is performed by either the first 2OO2 subsystem or the second 2OO2 subsystem, using a healthy cloud host or a healthy 2OO2 subsystem.
[0015] This application provides a cloud-based 2x2002 security system. The system deploys two 2002 subsystems on at least two cloud hosts, each subsystem comprising virtual machines with different operating systems. When a failure is detected in one subsystem, the first management node switches to the other. Compared to traditional 2x2002 security systems that rely on physical isolation for security, this cloud-based system uses a cloud platform instead of physical hardware. While maintaining security, it effectively improves the availability, reliability, and maintainability of the 2x2002 security system, while also significantly reducing hardware and maintenance costs. Furthermore, since this cloud-based system is based on a traditional cloud architecture, there is no need to redesign the cloud platform's architecture. Attached Figure Description
[0016] The accompanying drawings are intended only to illustrate and explain this application and do not limit the scope of this application.
[0017] Figure 1 A schematic diagram of a traditional 2*2OO2 security system is shown.
[0018] Figure 2 A schematic diagram of a cloud-based 2*2002 security system according to an embodiment of this application is shown;
[0019] Figure 3 A schematic diagram of the cloud host architecture in the cloud platform of this application embodiment is shown;
[0020] Figure 4 A schematic diagram of a cloud host and a diagnostic component in a virtual machine within the cloud host, according to an embodiment of this application, is shown.
[0021] Figure 5 This illustration shows a schematic diagram of the interaction between diagnostic components in a virtual machine within the same 2002 subsystem of this application embodiment;
[0022] Figure 6 A schematic diagram illustrating virtual machine interaction within the same 2002 subsystem according to an embodiment of this application is shown;
[0023] Figure 7 A schematic diagram of the management node in two 2002 subsystems of this application embodiment is shown;
[0024] Figure 8 This illustration shows a schematic diagram of the backup of a cloud host that has failed in one of the two 2002 subsystems in an embodiment of this application.
[0025] Explanation of reference numerals in the attached figures:
[0026] 11: The First Computer;
[0027] 12: Second computer;
[0028] 13: The third computer;
[0029] 14: The Fourth Computer;
[0030] 15: The first 2002 system;
[0031] 16: The Second 2002 System;
[0032] 20: Cloud platform;
[0033] 21: Redundant Ethernet network;
[0034] 22: First Cloud Server;
[0035] 23: Second cloud server;
[0036] 24: First Virtual Machine;
[0037] 25: Second virtual machine;
[0038] 26: The fourth virtual machine;
[0039] 27: The Fifth Virtual Machine;
[0040] 28: The third virtual machine;
[0041] 29: The Sixth Virtual Machine;
[0042] 30: Memory;
[0043] 31: Bus;
[0044] 32: First virtual processor;
[0045] 33: Second virtual processor;
[0046] 34: Processor;
[0047] 35: First diagnostic component;
[0048] 36: The application of the first virtual machine;
[0049] 37: Fourth diagnostic component;
[0050] 38: Applications in the fourth virtual machine;
[0051] 39: Third diagnostic component;
[0052] 40: Sixth Diagnostic Component;
[0053] 41: Second diagnostic component;
[0054] 42: Applications in the second virtual machine;
[0055] 43: Fifth Diagnostic Component;
[0056] 44: Applications of the fifth virtual machine;
[0057] 45: First scheduling procedure;
[0058] 46: Second scheduling procedure;
[0059] 47: Primary Subsystem;
[0060] 48: Backup subsystem;
[0061] 49: First backup cloud server;
[0062] 50: Second backup cloud server;
[0063] 51: The first virtual machine in the first backup cloud host;
[0064] 52: The second virtual machine in the first backup cloud host;
[0065] 53: The first virtual machine in the second backup cloud host;
[0066] 54: The second virtual machine in the second backup cloud host. Detailed Implementation
[0067] To provide a clearer understanding of the technical features, objectives, and effects of the embodiments of this application, the specific implementation methods of the embodiments of this application will now be described with reference to the accompanying drawings.
[0068] Figure 1 A schematic diagram of a traditional 2*2OO2 (double 2 out of 2) security system is shown. Figure 1As shown, a traditional 2*2002 security system includes a first 2002 (2 out of 2) system 15 and a second 2002 (2 out of 2) system 16. The first 2002 system 15 consists of a first computer 11 and a third computer 13, while the second 2002 system 16 consists of a second computer 12 and a fourth computer 14. The software, hardware, and structure of the first 2002 system 15 and the second 2002 system 16 are completely identical, forming a redundant hot standby system. Specifically, if the first 2002 system 15 fails, the second 2002 system 16 should be responsible for calculating the input data and obtaining the output result. If the second 2002 system 16 fails, the first 2002 system 15 should be responsible for calculating the input data and obtaining the output result. A failure of either the first computer 11 or the third computer 13 in the first 2002 system 15 will cause the first 2002 system 15 to fail. Similarly, a failure of the second computer 12 or the fourth computer 14 in the second 2002 system 16 will cause the second 2002 system 16 to fail. The first 2002 system 15 and the second 2002 system 16 primarily detect faults by comparing the outputs from the two computers within the same 2002 system. If the outputs from the two computers within the same 2002 system are inconsistent, the 2002 system should automatically set its operating state to a fault state. However, traditional 2*2002 security systems heavily rely on a hardware architecture composed of multiple computers. Therefore, traditional 2*2002 security systems have high hardware costs and increased maintenance difficulty, thereby reducing their availability. Thus, it is evident that there is a technical challenge in effectively improving the availability of traditional 2*2002 security systems.
[0069] To address the aforementioned technical problems, the inventors of this application propose a cloud-based 2*2OO2 security system to solve the technical problem of how to effectively improve the availability of traditional 2*2OO2 security systems.
[0070] Figure 2 A schematic diagram of a cloud-based 2*2002 security system according to an embodiment of this application is shown. Figure 2As shown in the embodiment of this application, the cloud-based 2*2002 security system includes: a first 2002 subsystem, which is set on at least two cloud hosts and includes a first virtual machine 24 and a second virtual machine 25, with different types of operating systems installed on the first virtual machine 24 and the second virtual machine 25; a second 2002 subsystem, which is set on at least two cloud hosts and includes a fourth virtual machine 26 and a fifth virtual machine 27, with different types of operating systems installed on the fourth virtual machine 26 and the fifth virtual machine 27; and a first management node, which is set on a cloud host and includes a third virtual machine 28. The first management node is used to switch to the second 2002 subsystem when a failure is detected in the first 2002 subsystem, or to switch to the first 2002 subsystem when a failure is detected in the second 2002 subsystem.
[0071] In this embodiment, the cloud-based 2*2002 security system deploys two 2002 subsystems on at least two cloud hosts, and each 2002 subsystem includes virtual machines with different operating system types. When a failure is detected in one 2002 subsystem, the first management node switches to the other 2002 subsystem. Compared to traditional 2*2002 security systems that achieve security through physical isolation, this cloud-based 2*2002 security system uses a cloud platform instead of physical hardware to implement the 2*2002 security system. While ensuring security, it can effectively improve the availability, reliability, and maintainability of the 2*2002 security system, and also effectively reduce the hardware cost and hardware maintenance cost. Furthermore, since the cloud-based 2*2002 security system is based on a traditional cloud architecture, there is no need to redesign the cloud architecture of the cloud platform.
[0072] In a specific example, such as Figure 2As shown, the first 2OO2 subsystem consists of a first virtual machine 24 in the first cloud host 22 of the cloud platform 20 and a second virtual machine 25 in the second cloud host 23 of the cloud platform 20. To meet the diversity requirements of IEC 61508, promptly detect faults, and reduce the probability of leading to dangerous situations, the operating system type of the first virtual machine 24 in the first cloud host 22 is different from the operating system type of the second virtual machine 25 in the second cloud host 23. For example, the operating system type of the first virtual machine 24 in the first cloud host 22 is Windows, while the operating system type of the second virtual machine 25 in the second cloud host 23 is Linux. The second 2OO2 subsystem consists of a fourth virtual machine 26 in the first cloud host 22 of the cloud platform 20 and a fifth virtual machine 27 in the second cloud host 23 of the cloud platform 20. To meet the diversity requirements of IEC 61508, promptly detect faults, and reduce the probability of leading to dangerous situations, the operating system type of the fourth virtual machine 26 in the first cloud host 22 is different from the operating system type of the fifth virtual machine 27 in the second cloud host 23. For example, the operating system type of the fourth virtual machine 26 in the first cloud host 22 is Windows, while the operating system type of the fifth virtual machine 27 in the second cloud host 23 is Linux. The first management node communicates with the first 2OO2 subsystem and the second 2OO2 subsystem through the Ethernet redundant network 21. The operating system type of the third virtual machine 28 included in the first management node can be either Windows or Linux.
[0073] In some optional embodiments, the system further includes a second management node, which is located on a cloud host and includes a sixth virtual machine 29. The second management node is used to work with the first management node in a redundant hot standby manner. Therefore, in the event of a failure of the first management node, the second management node can take over the operation of the first management node, thereby further improving the availability of the 2*2002 security system based on the cloud platform.
[0074] In a specific example, the second management node communicates with both the first and second 2002 subsystems via a redundant Ethernet network 21. The operating system of the sixth virtual machine 29 included in the second management node can be either Windows or Linux.
[0075] In some alternative embodiments, the cloud host supports virtualization of various types of hardware. For example... Figure 3As shown, the first cloud host 22 includes a memory 30, a first virtual machine 24 and a fourth virtual machine 26 communicating with the memory 30 via a bus 31, and a processor 34 communicating with the first virtual machine 24 and the fourth virtual machine 26 via the bus 31. The first virtual machine 24 is equipped with a first virtual processor 32, and the fourth virtual machine 26 is equipped with a second virtual processor 33. Therefore, it can be seen that the first cloud host 22 supports memory virtualization in addition to processor virtualization.
[0076] In some optional embodiments, the first virtual machine 24 is provided with a first diagnostic component 35, which is used to obtain a first running state, the first running state including: the running state of the first virtual machine 24, the running application 36 on the first virtual machine 24, and at least one of the running states of the first diagnostic component 35; the second virtual machine 25 is provided with a second diagnostic component 41, which is used to obtain a second running state, the second running state including: the running state of the second virtual machine 25, the running application 42 on the second virtual machine 25, and at least one of the running states of the second diagnostic component 41; the first diagnostic component 35 and the second diagnostic component 41 diagnose the running state of the first 2OO2 subsystem by exchanging the first running state and the second running state, and notify the second 2OO2 subsystem of the running state of the first 2OO2 subsystem. The second subsystem is further divided into two subsystems. The fourth virtual machine 26 is equipped with a fourth diagnostic component 37, which is used to obtain a fourth running state, including at least one of the following: the running state of the fourth virtual machine 26, the running application 38 on the fourth virtual machine 26, and the running state of the fourth diagnostic component 37. The fifth virtual machine 27 is equipped with a fifth diagnostic component 43, which is used to obtain a fifth running state, including at least one of the following: the running state of the fifth virtual machine 27, the running application 44 on the fifth virtual machine 27, and the running state of the fifth diagnostic component 43. The fourth diagnostic component 37 and the fifth diagnostic component 43 diagnose the running state of the second 2002 subsystem by exchanging the fourth and fifth running states, and notify the first 2002 subsystem of the running state of the second 2002 subsystem. Therefore, by setting a first diagnostic component and a second diagnostic component in the first virtual machine and the second virtual machine respectively, the first and second running states can be obtained relatively easily. Furthermore, by exchanging the first and second operating states, the first diagnostic component and the second diagnostic component can accurately diagnose the operating state of the first 2002 subsystem and promptly notify the second 2002 subsystem of the operating state of the first 2002 subsystem. Similarly, by setting the fourth and fifth diagnostic components on the fourth virtual machine 26 and the fifth virtual machine 27 respectively, the fourth and fifth operating states can be obtained relatively easily. Furthermore, by exchanging the fourth and fifth operating states, the fourth and fifth diagnostic components can accurately diagnose the operating state of the second 2002 subsystem and promptly notify the first 2002 subsystem of the operating state of the second 2002 subsystem.
[0077] In a specific example, the first diagnostic component 35 can be understood as a component with diagnostic functions set in the first virtual machine 24. The operating state of the first virtual machine 24 includes a normal operating state or a faulty operating state. The operating state of the application running on the first virtual machine 24 includes a normal operating state or a faulty operating state. The operating state of the first diagnostic component 35 includes a normal operating state or a faulty operating state. The second diagnostic component 41 can be understood as a component with diagnostic functions set in the second virtual machine 25. The operating state of the second virtual machine 25 includes a normal operating state or a faulty operating state. The operating state of the application running on the second virtual machine 25 includes a normal operating state or a faulty operating state. The operating state of the second diagnostic component 41 includes a normal operating state or a faulty operating state. After the first diagnostic component 35 and the second diagnostic component 41 exchange the first operating state and the second operating state, the first diagnostic component 35 diagnoses the operating state of the first 2OO2 subsystem based on the first operating state and the second operating state. Specifically, if both the first operating state and the second operating state are in a normal operating state, then the first diagnostic component 35 diagnoses the operating state of the first 2002 subsystem as normal. Otherwise, the first diagnostic component 35 diagnoses the operating state of the first 2002 subsystem as a faulty operating state. After the first diagnostic component 35 and the second diagnostic component 41 exchange the first operating state and the second operating state, the second diagnostic component 41 can also diagnose the operating state of the first 2002 subsystem based on the first operating state and the second operating state. The specific diagnostic process is similar to that of the first diagnostic component 35 and will not be repeated here. After the first diagnostic component 35 or the second diagnostic component 41 completes the diagnosis of the operating state of the first 2002 subsystem, the first diagnostic component 35 or the second diagnostic component 41 notifies the first management node of the operating state of the first 2002 subsystem through a diagnostic message. If the operating state of the first 2002 subsystem is a faulty operating state, then the first management node switches to using the second 2002 subsystem.
[0078] The fourth diagnostic component 37 can be understood as a component with diagnostic functions installed in the fourth virtual machine 26. The operating state of the fourth virtual machine 26 includes a normal operating state or a faulty operating state. The operating state of the application running on the fourth virtual machine 26 includes a normal operating state or a faulty operating state. The operating state of the fourth diagnostic component 37 includes a normal operating state or a faulty operating state. The fifth diagnostic component 43 can be understood as a component with diagnostic functions installed in the fifth virtual machine 27. The operating state of the fifth virtual machine 27 includes a normal operating state or a faulty operating state. The operating state of the application running on the fifth virtual machine 27 includes a normal operating state or a faulty operating state. The operating state of the fifth diagnostic component 43 includes a normal operating state or a faulty operating state. After the fourth diagnostic component 37 and the fifth diagnostic component 43 exchange the fourth and fifth operating states, the fourth diagnostic component 37 diagnoses the operating state of the second 2002 subsystem based on the fourth and fifth operating states. Specifically, if both the fourth and fifth operating states are in a normal operating state, the fourth diagnostic component 37 diagnoses the second 2002 subsystem as being in a normal operating state. Otherwise, the fourth diagnostic component 37 diagnoses the second 2002 subsystem as being in a fault operating state. After the fourth diagnostic component 37 and the fifth diagnostic component 43 exchange the fourth and fifth operating states, the fifth diagnostic component 43 can also diagnose the operating state of the second 2002 subsystem based on the fourth and fifth operating states. The specific diagnostic process is similar to that of the fourth diagnostic component 37 and will not be repeated here. After the fourth diagnostic component 37 or the fifth diagnostic component 43 completes the diagnosis of the operating state of the second 2002 subsystem, the fourth diagnostic component 37 or the fifth diagnostic component 43 notifies the first management node of the operating state of the second 2002 subsystem through a diagnostic message. If the second 2OO2 subsystem is in a fault state, the first management node switches to use the first 2OO2 subsystem.
[0079] In a specific example, such as Figure 5As shown, the first 2OO2 subsystem consists of a first virtual machine 24 in the first cloud host 22 and a second virtual machine 25 in the second cloud host 23. A first diagnostic component 35 in the first virtual machine 24 is used to obtain the running status of the first virtual machine 24, the application 36 running on the first virtual machine 24, and the first diagnostic component 35 itself. A second diagnostic component 41 in the second virtual machine 25 is used to obtain the running status of the second virtual machine 25, the application 42 running on the second virtual machine 25, and the second diagnostic component 41 itself. The first diagnostic component 35 and the second diagnostic component 41 exchange their respective running statuses through diagnostic messages, diagnose the running status of the first 2OO2 subsystem, and notify the first management node of the running status of the first 2OO2 subsystem. If the running status of the first 2OO2 subsystem is a running failure state, the first management node switches to using the second 2OO2 subsystem.
[0080] In some optional embodiments, a third diagnostic component 39 is provided on the cloud host where the first 2002 subsystem resides. The third diagnostic component 39 is used to obtain the operating status of the cloud host where the first 2002 subsystem resides. Based on the operating status of the cloud host and the operating status of the first 2002 subsystem obtained by the first diagnostic component 35 and the second diagnostic component 41, the third diagnostic component 39 determines the final operating status of the first 2002 subsystem and notifies the second 2002 subsystem of the final operating status. A sixth diagnostic component 40 is provided on the cloud host where the second 2002 subsystem resides. The sixth diagnostic component 40 is used to obtain the operating status of the cloud host where the second 2002 subsystem resides. Based on the operating status of the cloud host and the operating status of the second 2002 subsystem obtained by the fourth diagnostic component 37 and the fifth diagnostic component 43, the sixth diagnostic component 40 determines the final operating status of the second 2002 subsystem and notifies the first 2002 subsystem of the final operating status. Therefore, by providing a third diagnostic component on the cloud host where the first 2002 subsystem resides, the operating status of the cloud host where the first 2002 subsystem resides can be obtained relatively easily. Furthermore, based on the operating status of the cloud host where the first 2002 subsystem resides, and the operating status of the first 2002 subsystem obtained from the diagnostics of the first diagnostic component 35 and the second diagnostic component 41, the final operating status of the first 2002 subsystem can be determined more accurately, and the final operating status of the first 2002 subsystem can be promptly notified to the second 2002 subsystem. Similarly, by setting a sixth diagnostic component on the cloud host where the second 2002 subsystem resides, the operating status of the cloud host where the second 2002 subsystem resides can be obtained relatively easily. Furthermore, based on the operating status of the cloud host where the second 2002 subsystem resides, and the operating status of the second 2002 subsystem obtained from the diagnostics of the fourth diagnostic component 37 and the fifth diagnostic component 43, the final operating status of the second 2002 subsystem can be determined more accurately, and the final operating status of the second 2002 subsystem can be promptly notified to the first 2002 subsystem.
[0081] In a specific example, the third diagnostic component 39 can be understood as a component with diagnostic functions installed on the cloud host where the first 2002 subsystem resides. The operating status of the cloud host where the first 2002 subsystem resides includes a normal operating status or a faulty operating status. If the operating status of the cloud host where the first 2002 subsystem resides is normal, and the operating status of the first 2002 subsystem obtained by the first diagnostic component 35 and the second diagnostic component 41 is also normal, the third diagnostic component 39 determines that the final operating status of the first 2002 subsystem is normal. Otherwise, the third diagnostic component 39 determines that the final operating status of the first 2002 subsystem is faulty. After determining the final operating status of the first 2002 subsystem, the third diagnostic component 39 notifies the first management node of the final operating status of the first 2002 subsystem through a diagnostic message. If the final operating status of the first 2002 subsystem is faulty, the first management node switches to using the second 2002 subsystem.
[0082] The sixth diagnostic component 40 can be understood as a component with diagnostic functions installed on the cloud host where the second 2002 subsystem resides. The operating status of the cloud host where the second 2002 subsystem resides includes a normal operating status or a fault operating status. If the operating status of the cloud host where the second 2002 subsystem resides is normal, and the operating status of the second 2002 subsystem obtained by the fourth diagnostic component 37 and the fifth diagnostic component 43 is also normal, the sixth diagnostic component 40 determines that the final operating status of the second 2002 subsystem is normal. Otherwise, the sixth diagnostic component 40 determines that the final operating status of the second 2002 subsystem is fault operating. After determining the final operating status of the second 2002 subsystem, the sixth diagnostic component 40 notifies the first management node of the final operating status of the second 2002 subsystem through a diagnostic message. If the final operating status of the second 2002 subsystem is fault operating, the first management node switches to using the first 2002 subsystem.
[0083] In a specific example, such as Figure 4As shown, since both the first virtual machine 24 included in the first 2002 subsystem and the fourth virtual machine 26 included in the second 2002 subsystem are located in the first cloud host 22, the diagnostic component set on the first cloud host 22 can be either the third diagnostic component 39 or the sixth diagnostic component 40. The diagnostic component set on the first cloud host 22 is used to obtain the operating status of the first cloud host 22, and based on the operating status of the first cloud host and the operating status of the first 2002 subsystem obtained by the first diagnostic component 35 and the second diagnostic component 41, determine the final operating status of the first 2002 subsystem, and notify the first management node of the final operating status of the first 2002 subsystem. If the final operating status of the first 2002 subsystem is a running failure state, the first management node switches to using the second 2002 subsystem. Furthermore, the diagnostic component set on the first cloud host 22 determines the final operating status of the second 2002 subsystem based on the operating status of the first cloud host and the operating status of the second 2002 subsystem obtained by the fourth diagnostic component 37 and the fifth diagnostic component 43, and notifies the first management node of the final operating status of the second 2002 subsystem. If the final operating state of the second 2OO2 subsystem is a running failure state, then the first management node switches to using the first 2OO2 subsystem.
[0084] In some optional embodiments, the first virtual machine 24 and the second virtual machine 25 exchange input data and perform calculations on the exchanged input data to obtain output data corresponding to the exchanged input data. If the output data is consistent and the first 2002 subsystem is operating normally, the output of the first 2002 subsystem is valid; otherwise, the output of the first 2002 subsystem is invalid. Similarly, the fourth virtual machine 26 and the fifth virtual machine 27 exchange input data and perform calculations on the exchanged input data to obtain output data corresponding to the exchanged input data. If the output data is consistent and the second 2002 subsystem is operating normally, the output of the second 2002 subsystem is valid; otherwise, the output of the second 2002 subsystem is invalid. Therefore, in the event that the output data of the first virtual machine 24 and the second virtual machine 25 are inconsistent, or that the first 2002 subsystem malfunctions, the output of the first 2002 subsystem is invalid, and the second 2002 subsystem can be used, thereby further improving the availability of the 2*2002 security system based on the cloud platform. Furthermore, in the event that the output data of the fourth virtual machine 26 and the fifth virtual machine 27 are inconsistent, or in the event that the second 2OO2 subsystem fails, the output of the second 2OO2 subsystem becomes invalid, and the first 2OO2 subsystem can then be used, thereby further improving the availability of the cloud-based 2*2OO2 security system.
[0085] In a specific example, for a single 2*2*002 subsystem, it uses data flows and mechanisms similar to those in a traditional 2*2*002 security system. For example... Figure 6As shown, the first virtual machine 24 in the first cloud host 22 and the second virtual machine 25 in the second cloud host 23 constitute the first 2OO2 subsystem. The interaction process between the first virtual machine 24 and the second virtual machine 25 is as follows: the application 36 in the first virtual machine 24 and the application 42 in the second virtual machine 25 exchange input data; the application 36 in the first virtual machine 24 and the application 42 in the second virtual machine 25 periodically synchronize the data and status used to calculate the exchanged input data; the application 36 in the first virtual machine 24 and the application 42 in the second virtual machine 25 respectively calculate the exchanged input data; the application 36 in the first virtual machine 24 sends the calculated output result to the application 42 in the second virtual machine 25 for comparison; the second virtual machine 25... Application 42 compares the output sent by application 36 in the first virtual machine 24 with its own calculated output. Based on the comparison result and the running status of the first 2002 subsystem provided by the second diagnostic component 41 in the second virtual machine 25, it determines whether the output of the first 2002 subsystem is valid. If the comparison result indicates that the input data is consistent and the first 2002 subsystem is running normally, the output of the first 2002 subsystem is determined to be valid; otherwise, the output of the first 2002 subsystem is determined to be invalid. Then, through the second diagnostic component 41 in the second virtual machine 25, the second 2002 subsystem is notified that the output of the first 2002 subsystem is invalid. After this, the first 2002 subsystem should be automatically taken over by the second 2002 subsystem.
[0086] In some optional embodiments, the first management node is configured to allocate one of the first virtual machine 24 or the second virtual machine 25 as a first master virtual machine, the first master virtual machine being configured to perform comparison calculations of the output data of the first virtual machine 24 and the second virtual machine 25; and further allocate one of the fourth virtual machine 26 or the fifth virtual machine 27 as a second master virtual machine, the second master virtual machine being configured to perform comparison calculations of the output data of the fourth virtual machine 26 and the fifth virtual machine 27. Therefore, by allocating one of the first virtual machine 24 or the second virtual machine 25 as a first master virtual machine for performing comparison calculations of the output data of the first virtual machine 24 and the second virtual machine 25 through the first management node, the availability of the 2*2002 security system based on the cloud platform can be further improved. Furthermore, by allocating one of the fourth virtual machine 26 or the fifth virtual machine 27 as a second master virtual machine for performing comparison calculations of the output data of the fourth virtual machine 26 and the fifth virtual machine 27 through the first management node, the availability of the 2*2002 security system based on the cloud platform can be further improved.
[0087] In some optional embodiments, the first management node is further configured to migrate the input data on the cloud host where the first 2002 subsystem resides when the first 2002 subsystem fails, or to migrate the input data on the cloud host where the second 2002 subsystem resides when the second 2002 subsystem fails. Therefore, when the first 2002 subsystem fails, the third virtual machine 28 can achieve higher availability of the cloud-based 2*2002 security system by migrating the input data on the cloud host where the first 2002 subsystem resides. Furthermore, when the second 2002 subsystem fails, the sixth virtual machine 29 can achieve higher availability of the cloud-based 2*2002 security system by migrating the input data on the cloud host where the second 2002 subsystem resides.
[0088] In a specific example, when the first 2002 subsystem fails, the first management node migrates the input data from the cloud host containing the first 2002 subsystem to a backup cloud host. Specifically, the first management node migrates the input data from the cloud host containing the first 2002 subsystem to the backup cloud host through network communication. When the second 2002 subsystem fails, the first management node migrates the input data from the cloud host containing the second 2002 subsystem to a backup cloud host. Specifically, the first management node migrates the input data from the cloud host containing the second 2002 subsystem to the backup cloud host through network communication.
[0089] In some optional embodiments, the first management node is further configured to set the first 2002 subsystem and the second 2002 subsystem as a primary 2002 subsystem and a backup 2002 subsystem, respectively. Therefore, by setting the first 2002 subsystem as the primary 2002 subsystem and the second 2002 subsystem as the backup 2002 subsystem through the first management node, the availability of the cloud-based 2*2002 security system can be improved.
[0090] In a specific example, such as Figure 7As shown, the first management node includes a third virtual machine 28 in the first cloud host 22. Specifically, the first management node includes a first scheduler 45 in the third virtual machine 28 in the first cloud host 22. The second management node includes a sixth virtual machine 29 in the second cloud host 23. Specifically, the second management node includes a second scheduler 46 in the sixth virtual machine 29 in the second cloud host 23. When the 2*2002 security system based on the cloud platform is initialized, the first management node sets the first 2002 subsystem as the primary 2002 subsystem and sets the second 2002 subsystem as the backup 2002 subsystem. Simultaneously, the first management node allocates either the first virtual machine 24 or the second virtual machine 25 as a first primary virtual machine for comparing and calculating the output data of the first virtual machine 24 and the second virtual machine 25, and allocates either the fourth virtual machine 26 or the fifth virtual machine 27 as a second primary virtual machine for comparing and calculating the output data of the fourth virtual machine 26 and the fifth virtual machine 27. When the first 2002 subsystem fails, the first management node communicates with the backup cloud host via the network to migrate the input data on the cloud host containing the first 2002 subsystem to the backup cloud host. When the second 2002 subsystem fails, the first management node communicates with the backup cloud host via the network to migrate the input data on the cloud host containing the second 2002 subsystem to the backup cloud host.
[0091] In some optional embodiments, the system further includes at least one backup cloud host, which, when any cloud host configured in the first 2OO2 subsystem and the second 2OO2 subsystem fails, migrates the input data of the failed cloud host to the backup cloud host. Therefore, when any cloud host configured in the first 2OO2 subsystem and the second 2OO2 subsystem fails, migrating the input data of the failed cloud host to the backup cloud host effectively avoids hardware failures of the failed cloud host, thereby effectively improving the availability of the 2*2OO2 security system based on the cloud platform.
[0092] In a specific example, the migration of input data from the failed cloud server to the backup cloud server is accomplished by either the first 2002 subsystem or the second 2002 subsystem, using either the healthy cloud server or the healthy 2002 subsystem. Therefore, by using either the healthy cloud server or the healthy 2002 subsystem in the first and second 2002 subsystems to migrate the input data from the failed cloud server to the backup cloud server, the migration of input data from the failed cloud server to the backup cloud server can be reliably achieved.
[0093] In a specific example, when a fault is diagnosed in either the first 2OO2 subsystem or the second 2OO2 subsystem via a diagnostic component in the cloud host, the diagnostic component in the faulty cloud host notifies the first management node of the operational fault status of the faulty cloud host. This allows the first management node to invoke the healthy 2OO2 subsystem to migrate the input data of the faulty cloud host to the backup cloud host. Optionally, when a fault is diagnosed in either the first 2OO2 subsystem or the second 2OO2 subsystem via a diagnostic component in the cloud host, the diagnostic component in the faulty cloud host notifies the healthy cloud host of the operational fault status of the faulty cloud host. This allows the healthy cloud host to migrate the input data of the faulty cloud host to the backup cloud host.
[0094] In a specific example, such as Figure 8 As shown, if both the first cloud host 22 and the second cloud host 23 are in a fault state, the input data of the first cloud host 22 is migrated to the first backup cloud host 49, and the input data of the second cloud host 23 is migrated to the second backup cloud host 50. Furthermore, the primary subsystem 47 formed by the first virtual machine 51 in the first backup cloud host 49 and the first virtual machine 53 in the second backup cloud host 50 corresponds to the primary subsystem 47 formed by the first virtual machine 24 in the first cloud host 22 and the second virtual machine 25 in the second cloud host 23. The backup subsystem 48 formed by the second virtual machine 52 in the first backup cloud host 49 and the second virtual machine 54 in the second backup cloud host 50 corresponds to the backup subsystem 48 formed by the fourth virtual machine 26 in the first cloud host 22 and the fifth virtual machine 27 in the second cloud host 23.
[0095] It should be understood that although the present invention is described according to various embodiments, not every embodiment contains only one independent technical solution. This way of describing the invention is only for clarity. Those skilled in the art should regard the invention as a whole. The technical solutions in each embodiment can also be appropriately combined to form other implementation methods that can be understood by those skilled in the art.
[0096] The above are merely illustrative embodiments of the present invention and are not intended to limit the scope of the present invention. Any equivalent changes, modifications, and combinations made by those skilled in the art without departing from the concept and principles of the present invention should fall within the protection scope of the present invention.
Claims
1. A 2*2002 security system based on a cloud platform, the system comprising: The first 2OO2 subsystem is set on at least two cloud hosts. The first 2OO2 subsystem includes: a first virtual machine (24) and a second virtual machine (25). The first virtual machine (24) and the second virtual machine (25) are equipped with different types of operating systems. The second 2OO2 subsystem is set on at least two cloud hosts. The second 2OO2 subsystem includes: a fourth virtual machine (26) and a fifth virtual machine (27), wherein the fourth virtual machine (26) and the fifth virtual machine (27) are equipped with different types of operating systems. The first management node is set on the cloud host and includes a third virtual machine (28). The first management node is used to switch to the second 2OO2 subsystem when the first 2OO2 subsystem is detected to have failed, or to switch to the first 2OO2 subsystem when the second 2OO2 subsystem is detected to have failed. The first virtual machine (24) is equipped with a first diagnostic component (35), which is used to obtain a first running state. The first running state includes the running state of at least one of the following: the first virtual machine (24), the application (36) running on the first virtual machine (24), and the first diagnostic component (35). The second virtual machine (25) is equipped with a second diagnostic component (41), which is used to obtain a second running state, the second running state including: the running state of the second virtual machine (25), the application (42) running on the second virtual machine (25), and at least one of the second diagnostic component (41); The first diagnostic component (35) and the second diagnostic component (41) diagnose the operating status of the first 2OO2 subsystem by exchanging the first operating status and the second operating status, and notify the second 2OO2 subsystem of the operating status of the first 2OO2 subsystem; The fourth virtual machine (26) is provided with a fourth diagnostic component (37), which is used to obtain a fourth running state, the fourth running state including: the running state of the fourth virtual machine (26), the application (38) running on the fourth virtual machine (26), and the running state of the fourth diagnostic component (37). The fifth virtual machine (27) is provided with a fifth diagnostic component (43), which is used to obtain a fifth running state, which includes the running state of at least one of the following: the fifth virtual machine (27), the application (44) running on the fifth virtual machine (27), and the fifth diagnostic component (43). The fourth diagnostic component (37) and the fifth diagnostic component (43) diagnose the operating status of the second 2OO2 subsystem by exchanging the fourth operating status and the fifth operating status, and notify the first 2OO2 subsystem of the operating status of the second 2OO2 subsystem; A third diagnostic component (39) is provided on the cloud host where the first 2OO2 subsystem is located. The third diagnostic component (39) is used to obtain the operating status of the cloud host where the first 2OO2 subsystem is located. The third diagnostic component (39) determines the final operating status of the first 2OO2 subsystem based on the operating status of the cloud host and the operating status of the first 2OO2 subsystem obtained by the first diagnostic component (35) and the second diagnostic component (41), and notifies the second 2OO2 subsystem of the final operating status. The cloud host where the second 2OO2 subsystem is located is equipped with a sixth diagnostic component (40), which is used to obtain the operating status of the cloud host where the second 2OO2 subsystem is located; The sixth diagnostic component (40) determines the final operating status of the second 2OO2 subsystem based on the operating status of the cloud host and the operating status of the second 2OO2 subsystem obtained by the fourth diagnostic component (37) and the fifth diagnostic component (43), and notifies the first 2OO2 subsystem of the final operating status.
2. The 2*2002 security system based on a cloud platform according to claim 1, wherein, The system also includes: The second management node is set on the cloud host and includes a sixth virtual machine (29). The second management node is used to work with the first management node in a redundant hot standby manner.
3. The 2*2002 security system based on a cloud platform according to claim 1, wherein, The first virtual machine (24) and the second virtual machine (25) exchange input data and perform calculations on the exchanged input data to obtain the output data corresponding to the exchanged input data. If the output data is consistent and the first 2OO2 subsystem is running normally, then the output of the first 2OO2 subsystem is valid; otherwise, the output of the first 2OO2 subsystem is invalid. The fourth virtual machine (26) and the fifth virtual machine (27) exchange input data and perform calculations on the exchanged input data to obtain the output data corresponding to the exchanged input data. If the output data is consistent and the second 2OO2 subsystem is running normally, then the output of the second 2OO2 subsystem is valid; otherwise, the output of the second 2OO2 subsystem is invalid.
4. The 2*2002 security system based on a cloud platform according to claim 3, wherein, The first management node is used to allocate one of the first virtual machine (24) or the second virtual machine (25) as the first master virtual machine. The first master virtual machine is used to perform comparison calculations of the output data of the first virtual machine (24) and the second virtual machine (25). It also allocates one of the fourth virtual machine (26) or the fifth virtual machine (27) as the second master virtual machine. The second master virtual machine is used to perform comparison calculations of the output data of the fourth virtual machine (26) and the fifth virtual machine (27).
5. The 2*2002 security system based on a cloud platform according to claim 4, wherein, The first management node is also configured to migrate the input data on the cloud host where the first 2OO2 subsystem is located when the first 2OO2 subsystem fails, or to migrate the input data on the cloud host where the second 2OO2 subsystem is located when the second 2OO2 subsystem fails.
6. The 2*2002 security system based on a cloud platform according to claim 4, wherein, The first management node is further configured to set the first 2OO2 subsystem and the second 2OO2 subsystem as the primary 2OO2 subsystem and the backup 2OO2 subsystem, respectively.
7. The 2*2002 security system based on a cloud platform according to claim 1, wherein, The system also includes: At least one backup cloud server, When any cloud host set up in the first 2OO2 subsystem and the second 2OO2 subsystem fails, the input data of the failed cloud host will be migrated to the backup cloud host.
8. The 2*2002 security system based on a cloud platform according to claim 7, wherein, The migration of input data from the faulty cloud host to the backup cloud host is accomplished by either the first 2OO2 subsystem or the healthy cloud host in the second 2OO2 subsystem.
Citation Information
Patent Citations
Heterogeneous cloud-based multi-fault safety train control platform implementation method
CN110830596A
Rail transit train control system
CN211519529U