A high-reliability multi-redundancy virtualization method based on a microkernel

Abstract

The application discloses a kind of high reliability multiple redundancy virtualization methods based on microkernel, belongs to virtualization reliability technical field, to solve the problem that redundant system needs additional hardware, software and computing resources to support backup function, which needs to consume a large amount of system resources, which will have negative impact on the performance and resource utilization of the whole system, in the application, multiple redundancy technology is used to provide backup virtual machine for the main virtual machine, and the backup virtual machine seamlessly continues to provide services when the main virtual machine cannot work normally, improving the reliability of the system, and the backup virtual machine uses a microkernel operating system, which greatly reduces resource occupation according to the characteristics and functions of the services in the main server.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of virtualization reliability, and particularly relates to a high-reliability multi-fold redundant virtualization method based on a microkernel. BACKGROUND

[0002] The vehicle-mounted operating system adopts virtualization technology to provide a running environment for vehicle-mounted 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 vehicles. Through virtualization technology, the vehicle-mounted operating system can run different application modules and software in different virtual machines, achieving high isolation and independence between modules. This allows the vehicle-mounted system to run multiple applications such as entertainment systems, navigation systems, and vehicle management systems simultaneously 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 vehicle-mounted operating system to respond more flexibly to the needs of different applications. By allocating resources in different virtual machines, the system can better manage hardware resources such as processors, memory, and storage, allowing each application to obtain appropriate resource support and avoiding resource contention and conflicts, which helps to improve the real-time performance and performance of the system. This independent allocation of resources also provides convenience for adding new functional modules or updating existing modules in the future, as new virtual machines can be dynamically created and configured without affecting the normal operation of other modules. In this architecture, once a virtual machine or operating system has a problem, it will cause the vehicle-mounted application service to be interrupted. At the very least, it will bring inconvenience to the user's experience, such as the interruption of the navigation system may cause the driver to get lost, and the interruption of the entertainment system may affect the driver and passenger's experience. For some special functions such as automatic parking and automatic driving, if there is a problem, it may cause the vehicle to lose effective perception and control of the driving environment, which may cause the vehicle to be damaged or damage surrounding property, causing economic losses to the owner, and even may pose a serious threat to the life safety of passengers and other road users, leading to personnel casualties and legal liability issues. Therefore, the vehicle-mounted operating system needs to take additional safety measures, introduce double or even multiple redundant systems, and implement emergency switching schemes to ensure that basic functions can operate even when the system has a problem. However, redundant systems require additional hardware, software, and computing resources to support backup functions, which consumes a large amount of system resources, which negatively impacts the performance and resource utilization of the entire system.

[0003] To solve the above problems, a high-reliability multi-fold redundant virtualization method based on a microkernel is proposed. SUMMARY

[0004] The application aims to provide a high-reliability multi-fold redundancy virtualization method based on a microkernel, and solve the problems in the background art.

[0005] To achieve the above-mentioned purpose, the application provides the following technical solution: a high-reliability multi-fold redundancy virtualization method based on a microkernel, comprising the following steps:

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

[0007] S2: monitoring the sending of data streams from the main virtual machine to the external hardware device by a hardware device working state monitor at all times;

[0008] S3: continuously sending data streams to the hardware device, and if it is found to be in a stagnant state, it is considered that the system has an abnormal working state, and for the application that intermittently generates data streams to the hardware device, a time threshold is set, and if the threshold is exceeded, it is considered that the system has an abnormal working state;

[0009] S4: after recognizing the abnormal working state, starting a microkernel backup virtual machine and obtaining the control right of the external hardware device, completing the initialization of the operating system and the hardware, starting a service program and completing the initialization, replacing the main virtual machine, and continuing to provide services;

[0010] S5: after the main virtual machine has an abnormal working state, it will be restarted, and if there is still an abnormal state, a maintenance signal will be sent to the user, and if it returns to normal, the microkernel backup virtual machine will be switched back to the main virtual machine.

[0011] Further, in the step S1 of starting the main virtual machine, the monitoring client runs in the application layer of the main virtual machine and establishes a connection with the working state monitor, which runs in the Hypervisor in the form of a thread, and the working state monitor records the main virtual machine in which the client is located and monitors the working state of the main virtual machine at all times.

[0012] Further, the monitoring client actively inquires about the working state of the virtual machine, runs in the virtual machine, can obtain the current working state of the virtual machine, and then reports to the working state monitor running in the Hypervisor regularly in a heartbeat mechanism, and if no heartbeat response information sent by the monitor is received within a specified time, it is considered that the system has an abnormal working state.

[0013] Further, the working state monitor will not immediately start the switching of the backup server when the main virtual machine is identified as having an abnormal working state, but will send a state inquiry to the main virtual machine through the monitoring client. If the main virtual machine is currently in a normal working state, the monitoring client working in the main virtual machine will respond to the inquiry, and the monitoring client receiving the response will consider the main virtual machine to be in a normal state and will add it to the white list. In addition, no other operation will be performed. If the monitoring client does not receive a response to the inquiry, it will be considered that the main virtual machine has failed to work normally, and at this time the microkernel backup virtual machine will be started to continue to provide services.

[0014] Further, after the white list is established, the main virtual machine that successfully responds to the inquiry will be added to the white list, and no further inquiry will be sent thereafter.

[0015] Further, the white list is provided with a timer, which starts counting when the main virtual machine is added to the white list. After reaching the limited time, an inquiry will be actively sent to the main virtual machine. If a response to this inquiry is received, the timer will be updated. Otherwise, it will be considered that the main virtual machine has failed to work normally, and the standby virtual machine will be started. When it is monitored that there is data flow in the main virtual machine, the main virtual machine will be deleted from the white list.

[0016] Further, when the microkernel backup virtual machine is started in S4, it is classified and processed according to the real-time requirement set in advance. The microkernel backup virtual machine is hot-started for high real-time requirement, and is cold-started for low real-time requirement.

[0017] Further, the hot-starting 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 the service, and then enters a sleep state. When the microkernel backup virtual machine needs to be started, it is immediately woken up to replace the main virtual machine to continue to provide services.

[0018] Further, the cold-starting only creates the microkernel backup virtual machine, but does not start the microkernel backup virtual machine. When needed, it is started, completes the initialization, and then starts the service to replace the main virtual machine to continue to provide services.

[0019] Further, the backup virtual machine in S4 starts the service program and completes the 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, and the microkernel Hypervisor assists the backup virtual machine to start and complete 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 service, complete software initialization;

[0023] S4d: Save information to the cloud, the service will establish a connection with the cloud server, obtain real-time user information in the cloud, complete service state update, at this time, the microkernel backup virtual machine can replace the main virtual machine to continue to provide services.

[0024] Compared with the prior art, the beneficial effects of the present application are:

[0025] A kind of high reliability multiple redundancy virtualization method based on microkernel, multiple redundancy technology is adopted, provides backup virtual machine for main virtual machine, when main virtual machine cannot work normally, enable backup virtual machine to continue to provide services seamlessly, thereby improve the reliability of system, backup virtual machine adopts microkernel operating system, utilize the specific of highly modularized microkernel operating system, and according to the characteristics of service in main server and the function of service, thereby greatly reduce resource occupation, solve the problem that redundant system needs additional hardware, software and computing resources to support backup function, this needs to consume a large amount of system resources, this will have negative impact on the performance and resource utilization of entire system. BRIEF DESCRIPTION OF DRAWINGS

[0026] Fig. 1 For the system overall architecture schematic diagram of a kind of high reliability multiple redundancy virtualization method based on microkernel of the present application;

[0027] Fig. 2 For the overall flow schematic diagram of a kind of high reliability multiple redundancy virtualization method based on microkernel of the present application;

[0028] Fig. 3 For the microkernel backup virtual machine cold-hot start judgment architecture diagram of a kind of high reliability multiple redundancy virtualization method based on microkernel of the present application. DETAILED DESCRIPTION

[0029] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0030] Please refer to Figs. 1-3 , in order to solve the problem that redundant system needs additional hardware, software and computing resources to support backup function, this needs to consume a large amount of system resources, this will have negative impact on the performance and resource utilization of entire system, the following preferred technical solutions are provided:

[0031] A highly reliable, multi-redundant virtualization method based on a microkernel includes the following steps:

[0032] S1: Start the main virtual machine. The main virtual machine starts working and continuously interacts with the hardware device to which the main virtual machine belongs, and sends data streams to the hardware device.

[0033] S2: Monitor the data stream sent from the main virtual machine to external hardware devices in real time through the hardware device status monitor;

[0034] S3: If an application that continuously sends data streams to hardware devices is found to be in a stagnant state, it is considered that the system is in an abnormal working state. For applications that intermittently send 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 identifying the abnormal working state, start the microkernel backup virtual machine and obtain control of the external hardware devices, complete the operating system initialization and hardware initialization, start the service program and complete the initialization, take over the main virtual machine, and continue to provide services;

[0036] S5: If the main virtual machine becomes abnormal, it will be restarted. If the abnormal state 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 main virtual machine.

[0037] Specifically, when the main virtual machine and the services running within it are functioning normally, they continuously interact with the hardware devices to which the main virtual machine belongs, sending data streams to these devices. For example, peripheral screens constantly receive new display data, audio devices receive audio stream data, dashboard indicator lights receive control signals, and control commands are issued to the vehicle during autonomous driving. The hardware device status monitor constantly monitors the data streams sent from the main virtual machine to external hardware devices. For hardware devices that typically generate continuous data streams, such as display devices and audio devices, if they are found to be in a stagnant state, it is considered that the system is experiencing an abnormal working state. For hardware devices that generate intermittent data streams, a time threshold is set; if the threshold is exceeded, it is considered that the system is experiencing an abnormal working state. After an abnormal working state is identified, the microkernel backup virtual machine is started and gains control of the external hardware devices, completes operating system initialization and hardware initialization, starts and initializes service programs, and takes over from the main virtual machine to continue providing services. If the main virtual machine experiences an abnormal working state, it will be restarted, the system will be restarted, and processes will be killed. If the abnormal state still exists, a maintenance signal will be sent to the user. If normal operation is restored, the microkernel backup virtual machine will switch back to the main virtual machine.

[0038] The microkernel backup virtual machine is a simplified microkernel backup virtual machine. Compared with a traditional large kernel operating system, the simplified microkernel backup virtual machine is more lightweight, has a smaller kernel and fewer system components, which means that the backup virtual machine can start up and respond more quickly and occupy fewer system resources, thereby reducing the burden on the entire system. The kernel is simplified, different backup virtual machines are customized according to different load applications, the microkernel operating system running in the backup virtual machine retains only the necessary modules that enable the load application to normally run, and the remaining modules are excluded. In this way, a backup virtual machine is provided that is as lightweight as possible, and resource consumption is reduced. The functions of the application running in the backup virtual machine are simplified, further reducing the size of the backup virtual machine. After the main virtual machine recovers to normal, the control is returned to the main virtual machine. During the transition process, as long as the service can be normally provided, the main virtual machine provides more rich display effects by using 3D rendering technology to provide a better experience for users. When the backup virtual machine provides the automatic driving function, as long as the automatic driving can be performed without problems, the display function of the load can be removed. Therefore, the backup virtual machine is customized for the main virtual machine running different load applications, the size of the backup virtual machine is further reduced under the premise of ensuring normal service, and the occupied resources are reduced.

[0039] When the main virtual machine is started in the S1, the monitoring client runs in the application layer of the main virtual machine and establishes a connection with the working state monitor. The working state monitor runs in the Hypervisor in the form of a thread. The working state monitor records the main virtual machine where the client is located and monitors the working state of the main virtual machine at any time. The client sends the working state of the main virtual machine to the monitor at regular intervals to ensure that the current main virtual machine is always in a normal working state. When the working state of the current main virtual machine changes, for example, the main virtual machine enters hibernation or is turned off, the client actively reports to the monitor to update the working state of the main virtual machine. If the working state information sent by the monitoring client is not received within a specified time, the monitor actively inquires about the working state of the virtual machine. If the heartbeat response information sent by the monitor is not received within a specified time, it is considered that the system has a working state exception. The working state monitor of the main virtual machine also uses a heartbeat mechanism to inquire whether the virtual machine is in a normal working state at regular intervals. If the heartbeat response information sent by the monitor is not received within a specified time, it is considered that the system has a working state exception.

[0040] The main virtual machine does not interact with the hardware device at all times, for example, when a user pauses the playing of music or video, the data flow is interrupted at this time, which does not mean that the main virtual machine cannot work normally, therefore, when the working state monitor identifies that the main server is in an abnormal working state, the backup server is not immediately switched, but the monitoring client sends a state inquiry to the main virtual machine, if the main virtual machine is currently in a normal working state, the monitoring client working in the main virtual machine responds to the inquiry, the monitor receives the response, and considers that the main virtual machine is in a normal state, and adds it to the white list, and no other operation is performed, if the monitor does not receive the response to the inquiry, it is considered that the main virtual machine cannot work normally, at this time, the standby virtual machine is started to continue to provide services.

[0041] After the white list is established, the main virtual machine that successfully responds to the inquiry is added to the white list, and the inquiry is not sent again, the white list has a timer, which starts counting when the virtual machine is added to the white list, and sends an inquiry to the main virtual machine after reaching the limited time, if the response to the inquiry is received, the timer is updated, otherwise it is considered that the main virtual machine cannot work normally, and the standby virtual machine is started, when the main virtual machine is monitored to have data flow, the main virtual machine is deleted from the white list, the timer works in the kernel layer of the main virtual machine, its main function is to send a signal to the main virtual machine working state monitor in the form of an interrupt at an interval of 60s, the interrupt has the highest response level, so it can be immediately captured and processed by the monitor, if the monitor does not receive the interrupt signal within the specified time, the standby virtual machine is immediately enabled to replace the current main virtual machine to continue to provide services, since the interval time of the timer is long, it cannot provide high real-time performance, here it acts as the last barrier, when all the previous functions cannot work normally, the timer can ensure that the standby virtual machine can still be correctly enabled.

[0042] In S4, when the microkernel backup virtual machine is started, it is classified and processed according to the pre-set real-time requirement, the microkernel backup virtual machine is started and the initialization of the virtual machine and the service is completed, and then enters the sleep state, when the microkernel backup virtual machine needs to be started, it is immediately woken up to replace the main virtual machine to continue to provide services, the cold start only creates the microkernel backup virtual machine, but does not start the microkernel backup virtual machine, and needs to be started when needed, completes the initialization, and then starts the service and replaces the main virtual machine to continue to provide services.

[0043] Specifically, the hot start mode is that when the system starts, the backup virtual machine also starts and completes the initialization of the virtual machine and the service, and then enters the sleep state. When the backup virtual machine needs to be started, it is immediately woken up to replace the main virtual machine to continue to provide services. The advantage of the hot start mode is that the backup virtual machine can replace the main virtual machine as soon as possible, and the disadvantage is that more resources are occupied. The cold start mode is that when the system starts, only the backup virtual machine is created, but the backup virtual machine is not started. When needed, the virtual machine is started, the initialization is completed, and then the service is started to replace the main virtual machine to continue to provide services. The advantage of the cold start mode is that fewer resources are occupied, and the disadvantage is that the response speed is slow. For services with high real-time requirements, such as navigation and automatic driving, the hot start mode is used to recover services as soon as possible. For services without real-time requirements, such as audio and video playback, the cold start mode is used to reduce resource consumption.

[0044] In S4, the backup virtual machine starts the service program and completes the 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, and the backup virtual machine is started with the assistance of the microkernel Hypervisor, and the binding between the backup virtual machine and the hardware device is completed.

[0046] S4b: Collect hardware device information, such as instrument panel service needs to obtain the current vehicle condition, complete hardware initialization of the service;

[0047] S4c: Collect user information, such as identity verification, start service, and complete software initialization;

[0048] S4d: Some services save the latest information to the cloud, such as online music playback will save the user's current playback object and playback progress to the cloud. The service will establish a connection with the cloud server to obtain real-time user information on the cloud, complete service state update, and the standby server can replace the main server to continue to provide services.

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

[0050] The above merely describes preferred specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art, according to the technical solution and inventive concept of the present application, makes equivalent replacement or change within the technical range disclosed by the present application, should be covered within the protection scope of the present application.

Claims

1. A microkernel-based high-reliability multi-fold redundant virtualization method, characterized by, Includes the following steps: S1: Start the main virtual machine. The main virtual machine starts working and continuously interacts with the hardware device to which the main virtual machine belongs, and sends data streams to the hardware device. S2: Monitor the data stream sent from the main virtual machine to external hardware devices in real time through the hardware device status monitor; S3: If an application that continuously sends data streams to hardware devices is found to be in a stagnant state, it is considered that the system is in an abnormal working state. For applications that intermittently send 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 identifying the abnormal working state, start the microkernel backup virtual machine and obtain control of the external hardware devices, complete the operating system initialization and hardware initialization, start the service program and complete the initialization, take over the main virtual machine, and continue to provide services; S5: If the main virtual machine is in an abnormal working state, it will be restarted. If the abnormal state 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 main virtual machine. 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 the Hypervisor as a thread. The working status monitor records the main virtual machine where the current client is located and monitors the working status of the main virtual machine at any time. The monitoring client actively queries the working status of the virtual machine. Running within the virtual machine, the client obtains its current working status and periodically reports it to the working status monitor running in the Hypervisor via a heartbeat mechanism. If no heartbeat response is received from the monitor within a specified time, the system is considered to be in an abnormal working state. When the working status monitor identifies the primary virtual machine as being in an abnormal working state, it will not immediately initiate a switchover of the backup server. Instead, it will send a status query to the primary virtual machine through the monitoring client. If the primary virtual machine is currently in a normal working state, the monitoring client running within the primary virtual machine will respond to the query. Upon receiving this response, the monitoring client considers the primary virtual machine to be in a normal state and adds it to the whitelist. No further operations are performed. If the monitoring client does not receive a response to the query, it considers the primary virtual machine to be unable to work normally and will then start a microkernel backup virtual machine to continue providing services. After the whitelist is established, the main virtual machine that successfully responds to the query will be added to the whitelist and will not send queries again. The whitelist has a timer that starts counting when the main virtual machine is added to the whitelist. After a certain time is reached, the whitelist will actively send a query to the main virtual machine. If a response to the query is received, the timer will be updated; otherwise, the whitelist will assume that the main virtual machine is no longer working properly and will start a backup virtual machine. When data flow is detected in the main virtual machine, the whitelist will be removed.

2. The microkernel-based high-reliability multi-redundancy virtualization method of claim 1, wherein: When starting the microkernel backup virtual machine in S4, it is classified and processed according to the pre-set real-time requirements. A warm start is used for those with high real-time requirements, and a cold start is used for those with low real-time requirements.

3. The microkernel-based high-reliability multi-redundancy virtualization method as described in claim 2, characterized in that: The so-called warm start means that when the main virtual machine starts, the microkernel backup virtual machine also starts and completes the initialization of the virtual machine and services, and then enters a hibernation state. When it is necessary to start the microkernel backup virtual machine, it is immediately awakened and replaces the main virtual machine to continue providing services.

4. The microkernel-based high-reliability multi-redundancy virtualization method as described in claim 2, characterized in that: The cold start only creates a microkernel backup virtual machine, but does not start the microkernel backup virtual machine. It is started when needed, completes initialization, and then starts the service to replace the main virtual machine to continue providing services.

5. The microkernel-based high-reliability multi-redundancy virtualization method as described in claim 1, characterized in that: The backup virtual machine in S4 starts the service program and completes initialization, including the following steps: S4a: Establishes a connection between the software service and the external hardware device. The Server OS issues a command to start the backup virtual machine. The microkernel Hypervisor's auxiliary backup virtual machine starts and completes the binding between the backup virtual machine and the hardware device. S4b: Collects hardware device information and completes the hardware initialization of the service; S4c: Collect user information, start services, and complete software initialization; S4d: Information is stored 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 microkernel backup virtual machine can replace the main virtual machine to continue to provide services.

Images