High-reliability multiple redundancy virtualization method based on microkernel

Abstract

The invention discloses a high-reliability multiple redundancy virtualization method based on a microkernel, belongs to the technical field of virtualization reliability, and aims to solve the problems that a redundant system needs extra hardware, software and computing resources to support a backup function, a large number of system resources need to be consumed, and negative influences are generated on the performance and the resource utilization rate of the whole system. The multi-redundancy technology is adopted, the backup virtual machine is provided for the main virtual machine, when the main virtual machine cannot work normally, the backup virtual machine continuously provides service seamlessly, the reliability of the system is improved, the backup virtual machine adopts the micro-kernel operating system, and by means of the high-modularization specificity of the micro-kernel operating system, the reliability of the system is improved. According to the characteristics and functions of the service in the main server, resource occupation is reduced to a great extent.

Description

Technical Field

[0001] The present invention relates to the technical field of virtualization reliability, and in particular to a high-reliability multiple redundancy virtualization method based on a microkernel. Background Art

[0002] The in-vehicle operating system uses virtualization technology to provide an operating environment for in-vehicle applications, which not only improves the stability and reliability of the system, but also enhances the flexibility and maintainability of the system, providing important support for the intelligent development of modern automobiles. Through virtualization technology, the in-vehicle operating system can run different application modules and software in different virtual machines, achieving a high degree of isolation and independence between modules. This allows the in-vehicle system to run multiple applications such as entertainment systems, navigation systems, and vehicle management systems at the same time without worrying about interference and conflicts between them. For example, the navigation system and the entertainment system can run independently in their respective virtual machines without affecting each other, improving the stability and reliability of the system. In addition, virtualization technology also enables the in-vehicle operating system to respond to the needs of different applications more flexibly. By allocating resources in different virtual machines, the system can better manage hardware resources such as processors, memory, and storage, so that each application can obtain appropriate resource support, avoid resource competition and conflicts, and help improve the real-time performance and performance of the system. This independent allocation of resources also facilitates the addition of new functional modules or the updating of existing modules in the future, because new virtual machines can be dynamically created and configured without affecting the normal operation of other modules. In this architecture, once a problem occurs in the virtual machine or operating system, the in-vehicle application service will be interrupted. At the least, it will bring inconvenience to the user. For example, the interruption of the navigation system may cause the driver to get lost; the interruption of the entertainment system may affect the experience of the driver and passengers. For some special functions, such as automatic parking and automatic driving, once a problem occurs, it may cause the vehicle to lose effective perception and control of the driving environment, which may cause damage to the vehicle or damage to surrounding property, bring economic losses to the owner, and may even pose a serious threat to the life safety of passengers and other road users, resulting in casualties and legal liability issues. Therefore, it is necessary for the in-vehicle operating system to take additional safety measures, introduce dual or even multiple redundant systems, and implement emergency switching solutions to ensure that basic functions can be maintained even when problems occur in the system. However, redundant systems require additional hardware, software, and computing resources to support backup functions, which consumes a lot of system resources, which will have a negative impact on the performance and resource utilization of the entire system.

[0003] To solve the above problems, a high-reliability multiple-redundancy virtualization method based on microkernel is proposed. Summary of the invention

[0004] The purpose of the present invention is to provide a high-reliability multiple-redundancy virtualization method based on a microkernel, which solves the problems in the background technology.

[0005] To achieve the above object, the present invention provides the following technical solution: a high-reliability multiple redundancy virtualization method based on a microkernel, comprising the following steps:

[0006] S1: Start the master virtual machine, which starts to work and continuously interacts with the hardware device to which it belongs, and sends data streams to the hardware device;

[0007] S2: Monitor the data flow sent from the main virtual machine to the external hardware device at all times through the hardware device working status monitor;

[0008] S3: For applications that continuously send data streams to hardware devices, if they are found to be stagnant, the system is considered to be in an abnormal working state. For applications that intermittently generate data streams to hardware devices, a time threshold is set. If the threshold is exceeded, the system is considered to be in an abnormal working state.

[0009] S4: After determining that the working status is abnormal, the microkernel backup virtual machine is started and the control of the external hardware device is obtained, the operating system initialization and hardware initialization are completed, and the service program is started and initialized, replacing the main virtual machine and continuing to provide services;

[0010] S5: When the working status of the primary virtual machine is abnormal, it will be restarted. If the abnormal status still exists, a maintenance signal will be sent to the user. If it returns to normal, the microkernel backup virtual machine will switch back to the primary virtual machine.

[0011] Furthermore, when the main virtual machine is started in S1, the monitoring client runs in the application layer of the main virtual machine and establishes a connection with the working status monitor. The working status monitor runs in Hypervisor as a thread. The working status monitor will record the main virtual machine where the current client is located and monitor the working status of the main virtual machine at any time.

[0012] Furthermore, the monitoring client will actively inquire about the working status of the virtual machine. The monitoring client runs in the virtual machine and can obtain the current working status of the virtual machine, and then regularly report it to the working status monitor running in Hypervisor through a heartbeat mechanism. If the heartbeat response information sent by the monitor is not received within the specified time, it is considered that the system has an abnormal working status.

[0013] Furthermore, when the working status monitor identifies the primary virtual machine as having an abnormal working status, it will not immediately initiate the switching of the backup server, but will send a status inquiry to the primary virtual machine through the monitoring client. If the primary virtual machine is currently in a normal working state, the monitoring client working in the primary virtual machine will respond to the inquiry. When the monitoring client receives the response, it considers that the status of the primary virtual machine is normal and will add it to the whitelist. In addition, no other operations will be performed. If the monitoring client does not receive a response to the inquiry, it considers that the primary virtual machine can no longer work normally, and the microkernel backup virtual machine will be started to continue to provide services.

[0014] Furthermore, after the whitelist is established, the primary virtual machine that successfully responds to the query is added to the whitelist and will not issue queries again.

[0015] Furthermore, the whitelist is provided with a timer, which starts timing when the primary virtual machine is added to the whitelist. After the limited time is reached, the timer will actively send an inquiry to the primary virtual machine. If a response to the inquiry is received, the timer will be updated. Otherwise, the primary virtual machine will be considered to be unable to work normally, and the backup virtual machine will be started. When data flow is monitored in the primary virtual machine, the primary virtual machine will be deleted from the whitelist.

[0016] Furthermore, when the microkernel backup virtual machine is started in S4, classification processing is performed according to the preset real-time requirements, and hot start is used for those with high real-time requirements, and cold start is used for those with low real-time requirements.

[0017] Furthermore, the hot start is that when the main virtual machine is started, the microkernel backup virtual machine is also started and completes the initialization of the virtual machine and services, and then enters a dormant state. When the microkernel backup virtual machine needs to be started, it is immediately awakened and continues to provide services instead of the main virtual machine.

[0018] Furthermore, the cold start only creates a microkernel backup virtual machine, but does not start the microkernel backup virtual machine, which is restarted when needed to complete initialization, restart services and continue to provide services in place of the main virtual machine.

[0019] Furthermore, the backup virtual machine in S4 starts the service program and completes initialization, including the following steps:

[0020] S4a: Establish a connection between the software service and the external hardware device. The Server OS issues a command to start the backup virtual machine. The auxiliary backup virtual machine of the microkernel Hypervisor starts and completes the binding between the backup virtual machine and the hardware device.

[0021] S4b: Collect hardware device information and complete hardware initialization of the service;

[0022] S4c: Collect user information, start services, and complete software initialization;

[0023] S4d: The information is saved in the cloud. The service will establish a connection with the cloud server, obtain real-time user information from the cloud, and complete the service status update. At this time, the microkernel backup virtual machine can replace the primary virtual machine to continue to provide services.

[0024] Compared with the prior art, the present invention has the following beneficial effects:

[0025] A high-reliability multiple-redundancy virtualization method based on a microkernel adopts multiple-redundancy technology to provide a backup virtual machine for a main virtual machine. When the main virtual machine fails to work properly, the backup virtual machine is enabled to seamlessly continue to provide services, thereby improving the reliability of the system. The backup virtual machine adopts a microkernel operating system, and utilizes the highly modular characteristics of the microkernel operating system. According to the characteristics and functions of the services in the main server, the resource occupation is greatly reduced, and the problem that the redundant system needs additional hardware, software and computing resources to support the backup function, which consumes a large amount of system resources, which will have a negative impact on the performance and resource utilization of the entire system, is solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 A schematic diagram of the overall system architecture of a microkernel-based high-reliability multiple redundancy virtualization method of the present invention;

[0027] Figure 2 It is a schematic diagram of the overall process of a high-reliability multiple-redundancy virtualization method based on a microkernel of the present invention;

[0028] Figure 3 The present invention provides a high-reliability multiple-redundancy virtualization method based on a microkernel, which is a microkernel backup virtual machine cold and hot start judgment architecture diagram. DETAILED DESCRIPTION

[0029] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only 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.

[0030] See also Figure 1-Figure 3 In order to solve the problem that the redundant system requires additional hardware, software and computing resources to support the backup function, which consumes a lot of system resources and has a negative impact on the performance and resource utilization of the entire system, the following preferred technical solutions are provided:

[0031] A high-reliability multiple-redundancy virtualization method based on a microkernel comprises the following steps:

[0032] S1: Start the master virtual machine, which starts to work and continuously interacts with the hardware device to which it belongs, and sends data streams to the hardware device;

[0033] S2: Monitor the data flow sent from the main virtual machine to the external hardware device at all times through the hardware device working status monitor;

[0034] S3: For applications that continuously send data streams to hardware devices, if they are found to be stagnant, the system is considered to be in an abnormal working state. For applications that intermittently generate data streams to hardware devices, a time threshold is set. If the threshold is exceeded, the system is considered to be in an abnormal working state.

[0035] S4: After determining that the working status is abnormal, the microkernel backup virtual machine is started and the control of the external hardware device is obtained, the operating system initialization and hardware initialization are completed, and the service program is started and initialized, replacing the main virtual machine and continuing to provide services;

[0036] S5: When the working status of the primary virtual machine is abnormal, it will be restarted. If the abnormal status still exists, a maintenance signal will be sent to the user. If it returns to normal, the microkernel backup virtual machine will switch back to the primary virtual machine.

[0037] Specifically, when the main virtual machine and the services running in the main virtual machine are in a normal working state, they will continue to interact with the hardware devices to which the main virtual machine belongs and send data streams to the hardware devices. For example, the peripheral screen will continuously receive new display data, the sound device will receive audio stream data, the dashboard and other indicator lights will receive control signals, and the control instructions issued to the vehicle during automatic driving, etc. The hardware device working status monitor will always monitor the data stream sent by the main virtual machine to the external hardware device. For hardware devices that usually continuously generate data streams, such as display devices and sound devices, once they are found to be in a stagnant state, it is considered that the system has an abnormal working state. For hardware devices that intermittently generate data streams, a time threshold is set. If the threshold is exceeded, it is considered that the system has an abnormal working state. After the working state is determined to be abnormal, the microkernel backup virtual machine is started and the control right of the external hardware device is obtained, the operating system initialization and hardware initialization are completed, and the service program is started and initialized to replace the main virtual machine and continue to provide services. After the working state of the main virtual machine is abnormal, it will be restarted, the system will be restarted, and the process will be killed. If there is still an abnormal state, a maintenance signal will be sent to the user. If it returns to normal, the microkernel backup virtual machine will be switched back to the main virtual machine.

[0038] The microkernel backup virtual machine is a streamlined microkernel backup virtual machine. Compared with the traditional large kernel operating system, the streamlined microkernel backup virtual machine is lighter and has a smaller kernel and fewer system components. This means that the backup virtual machine can start and respond more quickly while occupying fewer system resources, thereby reducing the burden on the entire system. The kernel is streamlined, and different backup virtual machines are customized according to different load applications. The microkernel operating system running in the backup virtual machine only retains the necessary modules that enable the normal operation of the load application, and the remaining modules are excluded. In this way, a backup virtual machine that is as lightweight as possible is provided to reduce resource consumption, and the functions of the applications running in the backup virtual machine are streamlined to further reduce Reduce the size of the backup virtual machine. The backup virtual machine only plays a transitional role. When the primary virtual machine returns to normal, control will be transferred to the primary virtual machine again. During the transition process, as long as the service can be provided normally, it will be sufficient. For example, when performing autonomous driving, in order to allow users to have a better experience, the primary virtual machine will use 3D rendering technology to provide richer display effects. When the backup virtual machine provides the autonomous driving function, as long as it can ensure that the autonomous driving can be carried out without problems, the load display function can be removed. Therefore, targeted customization of backup virtual machines for the primary virtual machines running different load applications can further reduce the size of the backup virtual machines and reduce resource usage while ensuring their normal service provision.

[0039] When the master virtual machine is started in S1, the monitoring client runs in the application layer of the master virtual machine and establishes a connection with the working status monitor. The working status monitor runs in Hypervisor in the form of a thread. The working status monitor will record the master virtual machine where the current client is located and monitor the working status of the master virtual machine at any time. The client will periodically send the working status of the current master virtual machine to the monitor to ensure that the current master virtual machine is always in a normal working state. When the working state of the current master virtual machine changes, such as entering sleep or being shut down, the client will actively send a report to the monitor so that the monitor can update the working state of the master virtual machine. If the working state information sent by the monitoring client is not received within the specified time, the monitor will actively inquire about the working state of the virtual machine. If the heartbeat response information sent by the monitor is not received within the specified time, it is considered that the system has an abnormal working state. The master virtual machine working state monitor will also use the heartbeat mechanism to periodically inquire whether the virtual machine is in a normal working state. If the heartbeat response information sent by the monitor is not received within the specified time, it is considered that the system has an abnormal working state.

[0040] The primary virtual machine does not interact with the hardware devices all the time. For example, when the user pauses the playback of music or video, the interruption of data flow at this time does not mean that the primary virtual machine cannot work normally. Therefore, when the working status monitor marks the primary server as abnormal in working status, it will not immediately start the switching of the backup server. Instead, it will send a status inquiry to the primary virtual machine through the monitoring client. If the primary virtual machine is currently in normal working status, the monitoring client working in the primary virtual machine will respond to the inquiry. When the monitor receives the response, it considers that the primary virtual machine is in normal status and will add it to the whitelist. In addition, no other operations will be performed. If the monitor does not receive a response to the inquiry, it believes that the primary virtual machine has failed to work normally. At this time, the backup virtual machine will be started to continue to provide services.

[0041] After the whitelist is established, the primary virtual machine that successfully responds to the query will be added to the whitelist, and no query will be issued again. The whitelist is equipped with a timer, which starts counting when the virtual machine is added to the whitelist. After the specified time is reached, the primary virtual machine will be actively queried. If a response to the query is received, the timer will be updated, otherwise the primary virtual machine will be considered to be unable to work normally, and the backup virtual machine will be started. When data flow is detected in the primary virtual machine, the primary virtual machine will be deleted from the whitelist. The timer works in the kernel layer of the primary virtual machine. Its main function is to send a signal in the form of an interrupt to the primary virtual machine working status monitor at intervals of 60s. The interrupt has the highest response level, so it can be captured and processed immediately by the monitor. If the monitor does not receive the interrupt signal within the specified time, the backup virtual machine will be immediately enabled to replace the current primary virtual machine to continue to provide services. Since the timer interval is long, it cannot provide high real-time performance. It acts as the last barrier here. When all the previous functions cannot work normally, the timer can ensure that the backup virtual machine can still be correctly enabled.

[0042] When the microkernel backup virtual machine is started in S4, it is classified and processed according to the pre-set real-time requirements. Hot start is used for those with high real-time requirements, and cold start is used for those with low real-time requirements. The hot start is when the main virtual machine is started, the microkernel backup virtual machine is also started and the initialization of the virtual machine and services is completed, and then it enters the dormant state. When the microkernel backup virtual machine needs to be started, it is immediately awakened and replaces the main virtual machine to continue to provide services. The cold start only creates a microkernel backup virtual machine, but does not start the microkernel backup virtual machine. It will be started when needed, complete the initialization, and then start the service and replace the main virtual machine to continue to provide services.

[0043] Specifically, the hot start method is that when the system starts, the backup virtual machine is also started and the initialization of the virtual machine and services is completed, and then it enters a dormant state. When the backup virtual machine needs to be started, it is immediately awakened to replace the main virtual machine to continue to provide services. The advantage of the hot start method is that the backup virtual machine can take over the work of the main virtual machine at the fastest speed. The disadvantage is that it occupies more resources; cold start method: when the system starts, only a backup virtual machine is created, but the backup virtual machine is not started. When needed, the virtual machine is started again to complete the initialization, and then the service is started and replaces the main virtual machine to continue to provide services. The advantage of the cold start method is that it occupies less resources, and the disadvantage is that the response speed is slow. For services with high real-time requirements, such as navigation and autonomous driving, a hot start method is used to restore services as soon as possible. For services without real-time requirements, such as audio and video playback, a cold start method is used to reduce resource consumption.

[0044] The backup virtual machine in S4 starts the service program and completes initialization, including the following steps:

[0045] S4a: Establish a connection between the software service and the external hardware device. The Server OS issues a command to start the backup virtual machine. The auxiliary backup virtual machine of the microkernel Hypervisor starts and completes the binding between the backup virtual machine and the hardware device.

[0046] S4b: Collect hardware device information. For example, the dashboard service needs to obtain the current vehicle status and complete the hardware initialization of the service.

[0047] S4c: collects user information, such as identity authentication, starts services, and completes software initialization;

[0048] S4d: Some services save the latest information in the cloud. For example, online music playback will save the user's current playback object and playback progress in the cloud. The service will establish a connection with the cloud server to obtain real-time user information from the cloud and complete the service status update. At this time, the backup server can replace the main server and continue to provide services.

[0049] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0050] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A high-reliability multiple-redundancy virtualization method based on a microkernel, characterized in that: The following steps are involved: S1: Start the master virtual machine, which starts to work and continuously interacts with the hardware device to which it belongs, and sends data streams to the hardware device; S2: Monitor the data flow sent from the main virtual machine to the external hardware device at all times through the hardware device working status monitor; S3: For applications that continuously send data streams to hardware devices, if they are found to be stagnant, the system is considered to be in an abnormal working state. For applications that intermittently generate data streams to hardware devices, a time threshold is set. If the threshold is exceeded, the system is considered to be in an abnormal working state. S4: After determining that the working status is abnormal, the microkernel backup virtual machine is started and the control of the external hardware device is obtained, the operating system initialization and hardware initialization are completed, and the service program is started and initialized, replacing the main virtual machine and continuing to provide services; S5: When the working status of the primary virtual machine is abnormal, it will be restarted. If the abnormal status still exists, a maintenance signal will be sent to the user. If it returns to normal, the microkernel backup virtual machine will switch back to the primary virtual machine.

2. A microkernel-based high-reliability multiple-redundancy virtualization method as claimed in claim 1, characterized in that: When the master virtual machine is started in S1, the monitoring client runs in the application layer of the master virtual machine and establishes a connection with the working status monitor. The working status monitor runs in the Hypervisor in the form of a thread. The working status monitor records the master virtual machine where the current client is located and monitors the working status of the master virtual machine at any time.

3. A high-reliability multiple-redundancy virtualization method based on a microkernel as claimed in claim 2, characterized in that: The monitoring client will actively inquire about the working status of the virtual machine. The monitoring client runs in the virtual machine and can obtain the current working status of the virtual machine. Then, it will periodically report to the working status monitor running in the Hypervisor through a heartbeat mechanism. If the heartbeat response information sent by the monitor is not received within the specified time, it is considered that the system has an abnormal working status.

4. A microkernel-based high-reliability multiple-redundancy virtualization method as claimed in claim 3, characterized in that: When the working status monitor identifies the primary virtual machine as having an abnormal working status, it will not immediately start switching the backup server, but will send a status inquiry to the primary virtual machine through the monitoring client. If the primary virtual machine is currently in a normal working state, the monitoring client working in the primary virtual machine will respond to the inquiry. After the monitoring client receives the response, it considers that the primary virtual machine is in a normal state and will add it to the whitelist. In addition, no other operations will be performed. If the monitoring client does not receive a response to the inquiry, it considers that the primary virtual machine can no longer work normally, and the microkernel backup virtual machine will be started to continue to provide services.

5. A microkernel-based high-reliability multiple-redundancy virtualization method as claimed in claim 4, characterized in that: After the whitelist is established, the primary virtual machine that successfully responds to the query is added to the whitelist and will not issue queries again.

6. A microkernel-based high-reliability multiple-redundancy virtualization method as claimed in claim 5, characterized in that: The whitelist is provided with a timer, which starts timing when the primary virtual machine is added to the whitelist. When the limited time is reached, the primary virtual machine will be actively asked to query. If a response to the query is received, the timer will be updated. Otherwise, the primary virtual machine will be considered to be unable to work normally, and the backup virtual machine will be started. When data flow is monitored in the primary virtual machine, the primary virtual machine will be deleted from the whitelist.

7. A microkernel-based high-reliability multiple-redundancy virtualization method as claimed in claim 1, characterized in that: When the microkernel backup virtual machine is started in S4, classification processing is performed according to the preset real-time requirements, and hot start is used for those with high real-time requirements, and cold start is used for those with low real-time requirements.

8. A microkernel-based high-reliability multiple-redundancy virtualization method as claimed in claim 7, characterized in that: The hot start is that when the main virtual machine is started, the microkernel backup virtual machine is also started and the initialization of the virtual machine and services is completed, and then it enters a dormant state. When the microkernel backup virtual machine needs to be started, it is immediately awakened to replace the main virtual machine to continue to provide services.

9. A microkernel-based high-reliability multiple-redundancy virtualization method as claimed in claim 7, characterized in that: The cold start only creates a microkernel backup virtual machine, but does not start the microkernel backup virtual machine. It is restarted when needed to complete initialization, and then the service is restarted to replace the main virtual machine to continue to provide services.

10. The high-reliability multiple-redundancy virtualization method based on a microkernel as claimed in claim 1, characterized in that: The backup virtual machine in S4 starts the service program and completes initialization, including the following steps: S4a: Establish a connection between the software service and the external hardware device. The Server OS issues a command to start the backup VM. The auxiliary backup VM of the microkernel Hypervisor starts and completes the binding between the backup VM and the hardware device. S4b: Collect hardware device information and complete hardware initialization of the service; S4c: Collect user information, start services, and complete software initialization; S4d: The information is saved in the cloud. The service will establish a connection with the cloud server, obtain real-time user information from the cloud, and complete the service status update. At this time, the microkernel backup virtual machine can replace the primary virtual machine to continue to provide services.

Images