CN120973473A

CN120973473A - Virtual machine monitoring systems and methods

Info

Publication number: CN120973473A
Application number: CN202511097502.5A
Authority: CN
Inventors: 马飞飞
Original assignee: Beijing Xinchi Zhitu Technology Co ltd
Current assignee: Beijing Xinchi Zhitu Technology Co ltd
Priority date: 2025-08-06
Filing date: 2025-08-06
Publication date: 2025-11-18

Abstract

The application discloses a virtual machine monitoring system and method, wherein the system comprises a safety measurement component for monitoring at least one state information of a virtual machine currently running, such as an abnormal state of task running, an abnormal state of interrupt processing, heartbeat information or service state information, a monitoring control component for acquiring the state information reported by the safety measurement component and judging whether the virtual machine currently running needs to be switched according to the state information and a preset abnormal processing strategy, and a resource allocation component for allocating hardware equipment resources to the virtual machine to be started when the monitoring control component judges that the virtual machine needs to be switched. According to the technical scheme, the system failure time can be reduced, the system availability time and reliability are improved, the timeliness and accuracy of switching between the main virtual machine and the standby virtual machine are improved, and the hardware cost of a user can be reduced.

Description

Virtual machine monitoring system and method

Technical Field

The application relates to the technical field of virtual machine monitors, in particular to a virtual machine monitoring system and method.

Background

A virtual machine monitor (Hypervisor) is middle tier software running between a physical computer system and operating system software that can allow multiple operating systems and applications to share a set of underlying physical hardware. Hypervisor may be considered a "meta" operating system in a virtual environment that coordinates and allocates each virtual machine's access to all physical devices on a physical computer system, including processors, memory, storage, network devices, and the like.

Common high-availability system construction, mainly oriented application scenarios are cloud services and cluster services, and one node often gathers business systems (such as database service systems, internet application service systems, storage service systems and the like) on a plurality of virtual machines to provide complete services. The nodes are usually located on different physical machines, even on physical machines in different places, so as to avoid common cause failure caused by power failure and natural disasters. The supervisory channel is also typically configured as a network channel that can be reached by multiple routes, maintaining communication channel redundancy.

The method for constructing the high-availability system is applied to the end-side critical business scenes of automobile control, airplane control, industrial robots and the like, and has the following problems that 1, related designs of time constraint are not adopted, node service switching time changes along with configuration of cluster services, the node service switching time is not suitable for a system requiring time certainty, 2, an operating system and an application running on the GVM are not provided with multi-layer monitoring designs, the monitoring granularity is thicker, controllable equipment sets of all virtual machines are basically consistent, the end side is not provided with redundant equipment, the equipment also lacks flexible partition multiplexing configuration, the simple main-standby switching method is difficult to ensure smooth and uninterrupted key business, 4, a monitoring channel is only provided with a network, and a monitoring channel with smaller time delay is not provided in a single Hypervisor scene, 5, the monitoring management module is based on a Windows, linux and other complex operating systems, and is difficult to pass strict functional safety standard authentication.

Disclosure of Invention

The present application has been made in view of the above-mentioned problems, and it is an object of the present application to provide a virtual machine monitoring system and method that overcomes or at least partially solves the above-mentioned problems.

According to one aspect of the present application, there is provided a virtual machine monitoring system including:

The security measurement component is used for monitoring at least one of state information of a virtual machine running at present, such as abnormal state of task running, abnormal state of interrupt processing, heartbeat information or service state information;

the monitoring control component is used for acquiring the state information reported by the security measurement component and judging whether the currently running virtual machine needs to be switched or not according to the state information and a preset exception handling strategy;

And the resource allocation component is used for allocating hardware equipment resources for the standby virtual machine to be started when the monitoring control component judges that the virtual machine needs to be switched.

In some embodiments, the small components within the safety measure component or the safety measure component and the monitoring control component communicate through a shared memory channel.

In some embodiments, the abnormal state of operation of the task monitored by the safety metric component includes at least one of:

whether the scheduling delay of the task is greater than a threshold;

whether the running share of the task in the preset period reaches a threshold value or not;

whether the task is abnormally exited;

the abnormal state of interrupt handling monitored by the safety metric component includes at least one of:

whether the interrupt processing delay of the operating system is greater than a threshold;

Whether the processing time of the interrupt handler exceeds a threshold;

Whether the number of interrupt processes in a preset period reaches a threshold value or not.

In some embodiments, the logic for security metric component monitoring comprises:

and when the virtual machine is running, determining the abnormal state according to the calling condition of the hook function of different tasks in each functional module in the operating system, the threshold value and/or the preset period.

In some embodiments, the processing step of judging whether the scheduling delay of the task is smaller than a threshold value comprises judging whether the enabling task is a monitoring task when the hook function of the enabling task is called, recording the task enabling time td1 in a monitoring task list if the enabling task is the monitoring task, judging whether the target task to be switched is the monitoring task when the task switching hook function is called, recording the task scheduling time td2 if the task switching hook function is the monitoring task, calculating the scheduling delay time td2-td1 if the task switching hook function is the monitoring task, judging whether the scheduling delay time is larger than the threshold value, reporting abnormal information of the scheduling delay timeout to a monitoring control component if the scheduling delay time is larger than the threshold value, and not reporting if the scheduling delay time is not larger than the threshold value;

The processing step of judging whether the running share of each task reaches a threshold value or not comprises the steps of starting a timer, recording the running time ts1 of each monitoring task currently, obtaining the running time ts2 of each monitoring task again when the timer expires, calculating the running share = ts2-ts1 of each task in the period, judging whether the running share of each task is smaller than the threshold value, and reporting abnormal information of insufficient running shares of the tasks to a monitoring control component if the running share of each task is smaller than the threshold value;

The processing step of whether the task exits abnormally comprises the steps of judging whether the task exits are key tasks or not when the task exit hook function is called, and reporting the abnormal exit state information of the key tasks to the monitoring control component if the task exits are key tasks.

In some embodiments, the processing step of judging whether the interrupt processing delay of the operating system is larger than a threshold value comprises recording a starting time ti1 when an interrupt closing hook function of an interrupt closing function of the operating system is detected to be called, recording an ending time ti2 when the interrupt opening hook function of the interrupt opening function of the operating system is detected to be called, calculating interrupt closing times ti2-ti1, judging whether the interrupt closing time is larger than the threshold value, and reporting state information of interrupt delay timeout to a monitoring control component if the interrupt closing time is larger than the threshold value;

The processing step of judging whether the processing time of the interrupt processing program exceeds a threshold value or not comprises the steps of judging whether the interrupt is monitored or not when the interrupt processing entrance hook function is called, recording the interrupt processing starting time tc1 in a monitored interrupt list if the interrupt processing entrance hook function is called, judging whether the interrupt is monitored or not when the interrupt processing exit hook function is called, recording the interrupt processing ending time tc2 if the interrupt processing starting time tc2 is called, calculating interrupt processing time = tc2-tc1 if the interrupt processing time is more than the threshold value, judging whether the interrupt processing time is more than the threshold value, and reporting abnormal information of interrupt processing overtime to a monitoring control component if the interrupt processing time is more than the threshold value;

The processing step of judging whether the processing quantity of the interrupt in the preset period reaches the threshold value or not comprises the steps of starting a timer, wherein a timing interval is the preset period, recording the current count c1 of each monitoring interrupt, obtaining the current count c2 of each monitoring interrupt when the timer expires, calculating the processing quantity of the interrupt in the period = c2-c1, judging whether the processing quantity of the interrupt is smaller than the threshold value or not, and if yes, reporting abnormal information of insufficient critical interrupt processing quantity in the preset period to a monitoring control component.

In some embodiments, the anomaly handling policy preset in the monitoring control component includes at least one of:

the virtual machine is switched if the task scheduling delay is found to exceed the threshold value for X times continuously;

any critical task exits abnormally, and the virtual machine is switched;

the virtual machine is switched if the key interrupt processing time exceeds the threshold value for Y times continuously;

if the interrupt delay time exceeds the threshold value, switching the virtual machine;

wherein X, Y and Z are preset integer values.

In some embodiments, the virtual machine includes a primary virtual machine and a standby virtual machine, and when the primary virtual machine and the standby virtual machine are in a symmetric mode and respectively possess the same device resources and capabilities, the processing steps of the monitoring control component include:

S1, starting a heartbeat timer;

S2, waiting for the security measurement component to report state information and acquiring heartbeat timer information;

S3, judging whether the heartbeat of the virtual machine is lost or not, if so, entering S5, and if not, entering S4;

s4, judging whether the safety measurement component of the virtual machine reports abnormal information or not, if not, returning to S2, and if so, entering S5;

s5, judging whether switching is needed according to a preset exception handling strategy, if not, recording and reporting exception information, returning to S2, and if so, entering S6;

s6, judging whether the current abnormal virtual machine is a main virtual machine or not;

S7, if not, the main virtual machine continues to take over the service, restarting the standby virtual machine, then recording and reporting the restarting information, if so, changing the standby virtual machine into the main virtual machine and taking over the service, simultaneously changing the original main virtual machine into the standby virtual machine and restarting, and then recording and reporting the restarting information.

In some embodiments, the virtual machine includes a primary virtual machine and a backup virtual machine, and when the primary virtual machine and the backup virtual machine are in an asymmetric mode and the backup virtual machine obtains fewer device resources and capabilities relative to the primary virtual machine, the processing step of monitoring the control component includes:

S1, starting a heartbeat timer;

S3, judging whether the heartbeat loss condition of the virtual machine exists or not, if so, entering S6, and if not, entering the next step;

S5, judging whether switching is needed according to a preset exception handling strategy, if not, recording and reporting exception information and returning to S2, and if so, entering S6;

s6, judging whether the virtual machine with the current abnormality is a main machine, if not, continuing to take over the service by the main machine, restarting the standby virtual machine, and recording and reporting restarting information, otherwise, entering S7;

S7, the standby virtual machine takes over the service, restarts the main virtual machine, and records and reports the restarting information;

and S8, judging whether the restarting of the main virtual machine is successful, if so, restarting the service by the main virtual machine, then entering the next cycle, and if not, returning to S5.

According to another aspect of the present application, there is provided a virtual machine monitoring method, including:

Monitoring at least one of abnormal state of task operation, abnormal state of interrupt processing, heartbeat information or service state information of a currently running virtual machine;

acquiring the state information, and judging whether the currently running virtual machine needs to be switched or not according to the state information and a preset exception handling strategy;

and when the virtual machine is judged to be required to be switched, hardware equipment resources are allocated for the virtual machine to be started, and the virtual machine takes over tasks.

From the above, according to the virtual machine monitoring system disclosed by the application, the system failure time can be reduced, the system availability time and reliability can be improved, the timeliness and accuracy of switching between the main virtual machine and the standby virtual machine can be improved, and the hardware cost of a user can be reduced.

The foregoing description is only an overview of the present application, and is intended to be implemented in accordance with the teachings of the present application in order that the same may be more clearly understood and to make the same and other objects, features and advantages of the present application more readily apparent.

Drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the application. Also, like reference numerals are used to designate like parts throughout the figures. In the drawings:

FIG. 1 illustrates a schematic diagram of a virtual machine monitoring system according to some embodiments of the application;

FIG. 2 illustrates a schematic architecture of a virtual machine monitoring system execution architecture according to some embodiments of the application;

FIG. 3 illustrates a flow diagram of critical task scheduling delay monitoring in accordance with some embodiments of the application;

FIG. 4 illustrates a flow diagram of the run share monitoring of critical tasks within a preset period according to some embodiments of the application;

FIG. 5 illustrates a flow diagram of critical task exception exit monitoring in accordance with some embodiments of the application;

FIG. 6 illustrates a flow diagram of a process for monitoring interrupt latency according to some embodiments of the application;

FIG. 7 illustrates a flow diagram of a process for monitoring critical interrupt handling timeout according to some embodiments of the application;

FIG. 8 illustrates a flow chart of critical interrupt handling statistics over a predetermined period according to some embodiments of the application;

FIG. 9 illustrates a flow diagram for determining whether to switch virtual machines using an exception handling policy according to some embodiments of the application;

FIG. 10 is a flow chart of determining whether to switch virtual machines using an exception handling policy according to further embodiments of the present application;

FIG. 11 illustrates a flow diagram of a virtual machine monitoring method according to some embodiments of the application.

Detailed Description

Exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the application to those skilled in the art.

Aiming at the defect that the conventional multi-virtual machine high-availability system based on the virtual machine monitor is applied to the terminal-side critical service scene, the embodiment of the application provides a high-availability virtual machine monitoring scheme suitable for the critical service scene, the virtual machine monitoring scheme is based on a monitor Hypervisor conforming to the functional safety standard, a monitoring control component, a resource allocation component and a safety measurement component at least partially running in the virtual machine, various high-availability software systems can be constructed in different critical service scenes, various main-standby switching modes are provided, the requirement of the response delay of the critical service on the time is met, the service unavailability time is reduced, and the reliability level of the system is improved.

FIG. 1 shows a schematic diagram of a virtual machine monitoring system according to one embodiment of the application, the system comprising:

The security measurement component 110 is configured to monitor at least one state information of a currently running virtual machine, including an abnormal state of task running, an abnormal state of interrupt processing, heartbeat information, or service state information;

The monitoring control component 120 is configured to obtain status information reported by the security measurement component, and determine whether to switch a currently running virtual machine according to the status information and a preset exception handling policy;

And the resource allocation component 130 is configured to allocate hardware device resources for the standby virtual machine to be started when the monitoring control component determines that the virtual machine needs to be switched.

In some alternative embodiments, in conjunction with the architecture diagram shown in fig. 2, the security metric component 110 may be disposed in a virtual machine, or may be divided into a plurality of sub-components disposed in the virtual machine and in a monitor, respectively, and the monitoring control component and the resource allocation component are software components running in the monitor (Hypervisor).

In some embodiments, communication between gadgets within the safety metrics component or between the safety metrics component and the monitoring control component is via a shared memory channel. Optionally, the shared memory channel needs to be modified and reinforced to meet the communication requirement.

According to the embodiment, the method and the device have the advantages that the service state in the virtual machine can be monitored more timely by at least partially running the safety measurement component in the virtual machine, the risk of system failure can be reduced, and the safe and available time of the system is improved.

The monitoring content of the security measurement component is aimed at the general functions of the operating system, can be conveniently adapted to various operating systems without specially designating the operating system, and improves the convenience and the universality of the application of the security measurement component.

The application uses the shared memory channel to replace the conventional Ethernet channel, ensures the time certainty of monitoring, and can be used for systems requiring real-time control, such as automobile control, airplane control, industrial robots and the like.

The monitoring control component operates in the hypervisor meeting the functional safety requirements, and provides an abnormal strategy customizing mechanism, so that the monitoring control component can ensure that the monitoring control component also meets the functional safety requirements, can be conveniently applied to control systems of different services, and improves the high-availability application scene.

In some embodiments, as shown in connection with fig. 2, in the overall highly available virtual machine monitoring system architecture, the respective functions of the components include:

The resource allocation component in the monitor configures the equipment to different virtual machines according to the configuration of the user, and the user can allocate the proper equipment set to the main virtual machine and the standby virtual machine through proper configuration, so that the two virtual machines have enough equipment to complete service operation. The device configuration information is transferred to the virtual machine operating system in a mode of virtual firmware, DTS flat device tree files and the like according to the mode supported by the virtual machine operating system. Meanwhile, the resource allocation component uses hardware functions such as secondary address mapping and the like to ensure the access isolation of the virtual machine to the devices, namely, the virtual machine can only use the devices allocated to the virtual machine and can not access the devices not belonging to the virtual machine.

The monitoring control component is responsible for monitoring the abnormal state of the main virtual machine through the security measurement component, when the current abnormal state of the virtual machine is monitored, and the switching threshold value is reached, switching is started, other virtual machines are utilized to take over services, and meanwhile, the abnormal virtual machine can be restarted to detect the availability of the abnormal virtual machine, so that the smooth work of the abnormal virtual machine when the abnormal virtual machine is required to take over the services is ensured.

In some embodiments, the security metrics component is a software component running on the virtual machine responsible for monitoring the operating system state of the virtual machine, consisting essentially of:

task running states, user configurable critical task list (including system tasks and application tasks) to be monitored, the monitored task running states including:

Whether the scheduling delay of the task is smaller than a preset threshold.

Within a preset period, whether the running share of the task reaches a preset threshold value or not.

Monitoring whether the critical task is abnormally exited.

The processing state of the key interrupt processing, the user can configure an interrupt list needing to be monitored, and the processing state of the monitored interrupt processing comprises:

Whether the interrupt processing delay of the operating system is smaller than a set threshold value is indirectly monitored by monitoring the interrupt closing time of the operating system.

Whether the processing time of the interrupt handler for the critical interrupt has timed out.

And in a preset period, judging whether the processing quantity of the key interrupt reaches a set value.

Further, the system also comprises a monitoring control component which uses a shared memory channel to send information to the Hypervisor, wherein the sent information comprises heartbeat information, state abnormality information of a monitored key task or key interrupt and service state synchronization information.

It should be noted that, the security measurement component is at least partially operated on the user virtual machine and is responsible for monitoring the operation states of key tasks and key interrupts of the user virtual machine, and meanwhile, the heartbeat message and the abnormal state are reported to the monitoring control component in the Hypervisor, and the service application can also report the service state information through the channel of the security measurement component.

Compared with the conventional heartbeat, the Hypervisor can grasp the critical tasks and the running conditions of the critical interrupt more timely through the safety measurement component, can start the error processing flow more timely, reduce the failure time of the system and improve the usability of the whole system.

In some embodiments, the relevant process flow for the security metrics component to monitor the critical tasks includes:

the specific steps of the processing flow for monitoring whether the scheduling delay of the key task is smaller than the threshold value are shown in the figure 3, and comprise the steps of judging whether the enabling task is a monitoring task when the hook function of the enabling task is called, recording the task enabling time td1 in a monitoring task list if the enabling task is the monitoring task, judging whether the task to be switched is the monitoring task when the task switching hook function is called, recording the task scheduling time td2 if the task switching task is the monitoring task, calculating the scheduling delay time td2-td1 if the task switching task is the monitoring task, judging whether the scheduling delay time is larger than the threshold value, reporting abnormal information of the scheduling delay timeout to a monitoring control component if the scheduling delay time is larger than the threshold value, and not reporting if the abnormal information is not larger than the threshold value.

There is no direct sequential call relationship between the task enabling hook function being called and the task scheduling function hook being called, and there is a logical dependency relationship (this relationship is expressed using a dotted line in fig. 3). That is, after the task enabling hook function is called, the task enabling hook function is not necessarily called in the same context, but the task enabling hook function may be called in different contexts, but for the same monitored task, the task enabling hook function is required to be called first, the time point td1 when the task is enabled (i.e. the task is set to an executable state and is added into a scheduling queue to wait for a CPU) is recorded, then, the task scheduling function hook is called, the time point td2 when the monitored task is scheduled to obtain the CPU is recorded, and thus scheduling delay is calculated.

The process of scheduling shares of the monitoring key tasks in the preset period is shown in combination with fig. 4, and comprises the following steps of starting a timer, recording the running time ts1 of each monitoring task currently, obtaining the running time ts2 of each monitoring task again when the timer expires, calculating the running shares=ts2-ts 1 of each task in the period, judging whether the running shares of each task are smaller than a threshold value, and reporting abnormal information of the insufficient running shares of the tasks to a monitoring control component if the running shares are smaller than the threshold value.

It should be noted that the timer function and the task execution time may be obtained from the virtual machine operating system.

The process flow for monitoring whether the critical task exits abnormally is shown in fig. 5, and the steps include judging whether the task exits are critical tasks when the task exit hook function is called, and reporting the abnormal exit state information of the critical task to the monitoring control component if the task exits are critical tasks.

It should be noted that, according to fig. 3 to 5, in order to implement the above-mentioned monitoring function when the system is running, information such as a critical task, a threshold value, a preset period, etc. needs to be configured in advance in a configuration file, and a hook function is registered or hooked in advance in the operating system. After the virtual machine is started, information such as a key task, a preset period, a threshold value and the like is read from the configuration file, and a monitoring function of the security measurement component is started.

It should be noted that after the operating system registers the task exit hook function, the hook function is not called in the context of the monitored task, but as the system runs, the task exit function hook is called when there is a task exit in the system, so this is shown by the dashed line in fig. 5.

Other embodiments of the application also illustrate the process flow of the safety metric component monitoring interrupt latency:

The process flow of monitoring interrupt delay by the safety measurement component is shown in fig. 6, and specifically, the processing step of judging whether the interrupt processing delay is larger than a threshold value includes recording a start time ti1 when an interrupt closing hook function of an interrupt closing function of an operating system is detected to be called, recording an end time ti2 when the interrupt opening hook function of the interrupt opening function of the operating system is detected to be called, calculating interrupt closing time ti2-ti1, judging whether the interrupt closing time is larger than the threshold value, and reporting state information of interrupt delay timeout to the monitoring control component if the interrupt closing time is larger than the threshold value.

In the open source operating system, there may be a ready interface, if not, it can be added by source code modification, and if not, it can also see if the closed source operating system provides corresponding interrupt closing time statistics or interrupt delay monitoring function, if not, it can not perform interrupt delay monitoring on the operating system, and from the aspect of time certainty of functional safety, the closed source operating system is not suitable for carrying critical services.

FIG. 6 is a process flow based on a hook function hooking function that an operating system can provide interrupt opening and interrupt closing. Wherein after the interrupt delay monitoring function is turned on, the program does not execute directly until the interrupt closing hook function is invoked, but may be invoked in a different context as triggered by other tasks as the system runs, and is therefore represented by a dashed line in the figure.

The process steps of the key interrupt processing time monitoring flow, as shown in fig. 7, of judging whether the processing time of the interrupt processing program exceeds a threshold value or not, when the interrupt processing entry hook function is detected to be called, judging whether the interrupt is monitored or not, if yes, recording the interrupt processing starting time tc1 in a monitoring interrupt list, when the interrupt processing exit hook function is detected to be called, judging whether the interrupt is monitored or not, if yes, recording the interrupt processing ending time tc2, calculating the interrupt processing time=tc2-tc 1, judging whether the interrupt processing time is larger than the threshold value, and if yes, reporting abnormal information of interrupt processing timeout to a monitoring control component.

Based on the process flow that the operating system can provide hook hooking of interrupt handling entry hooks and interrupt handling exit, open source operating systems typically have ready interfaces that can be added by source code modification if not. After the interrupt timeout monitoring function is turned on, the program is not directly executed until the interrupt processing entry hook function is called, but is called in the interrupt processing flow of the operating system as the system runs, so the interrupt processing flow is indicated by a dotted line in fig. 7.

The process of monitoring the number of critical interrupts in a period is shown in fig. 8, and the processing steps of judging whether the number of interrupts in a preset period reaches a threshold value or not include starting a timer, wherein a timing interval is the preset period, recording the current count c1 of each monitoring interrupt, obtaining the current count c2 of each monitoring interrupt when the timer expires, calculating the number of interrupts in the period=c2-c 1, judging whether the number of interrupts is smaller than the threshold value, and if yes, reporting abnormal information of insufficient number of critical interrupts in the preset period to a monitoring control component.

The timer function and the interrupt number acquisition function shown in the flow are provided by most operating systems.

According to other embodiments of the present application, a process flow of monitoring the control component is also presented, with particular reference to fig. 9 and 10. In this case, fig. 9 is mainly applicable to the case where the device resources allocated to the primary virtual machine and the standby virtual machine are the same, so when one virtual machine is abnormally required to be switched, the other virtual machine becomes the primary virtual machine, and services are managed in parallel, and the mode does not need to be manually switched back to the original virtual machine, and of course, the mode can also be applicable to the case where the device resources are different. FIG. 10 is generally applicable to the case where the device resources of the primary virtual machine and the standby virtual machine are not equal, and once the primary virtual machine resumes to start, the service needs to be switched back to the primary virtual machine, otherwise, overload operation may occur.

Referring specifically to fig. 9, when the primary and standby virtual machines are in a symmetric mode, the processing steps of the monitoring control component include:

S1, starting a heartbeat timer;

S7, if not, the main virtual machine takes over the service, restarting the standby virtual machine, then recording and reporting the restarting information, if so, changing the standby virtual machine into the main virtual machine, taking over the service, simultaneously changing the original main virtual machine into the standby virtual machine, restarting, and then recording and reporting the restarting information.

It should be noted that when the Hypervisor is started, the main virtual machine and the standby virtual machine are started respectively according to the configuration of the user (the device resources of each virtual machine are configured in the configuration file of the virtual machine, the device resource management component provides functions, which are the basic functions of all the hypervisors, the industry general technology), the monitoring control component uses the high-speed shared memory channel (the hypervisors and the virtual machine, and the high-speed shared memory channel between the virtual machines, which are the functions provided by most hypervisors, belong to the industry general technology, and are not related to the key technical point of the application, so the application does not describe in detail), the connection is established with the security measurement component in the virtual machine, the state of the virtual machine is monitored, and when the state of the main virtual machine is abnormal, the fault processing operations such as alarming, reporting, standby are switched according to the strategy configured by the user are monitored.

In fig. 9, the exception handling policy is mainly configured by the end user according to the service situation, and the configurable exception policy is as follows:

and the key task scheduling delay is found to exceed the threshold value for X times continuously, and the virtual machine is required to be restarted.

Any critical task exits abnormally and the virtual machine needs to be restarted.

And (3) discovering that the key interrupt processing time exceeds the threshold value for Y times continuously, and restarting the virtual machine.

The interrupt delay time is found to exceed the threshold value for Z times continuously, and the virtual machine is required to be restarted.

In mode 1 of fig. 9, both the primary virtual machine and the backup virtual machine have the same device resource configuration. Exactly the same service may be performed. The disadvantage is high system cost and large power consumption.

In other embodiments, the monitoring control component further provides another control module, in which case, the standby virtual machine configures fewer device resources, temporarily provides degraded service, and after the primary virtual machine returns to normal, the primary virtual machine provides service, and the standby virtual machine is switched to the standby state again. Referring to fig. 10, when the primary and standby virtual machines are in an asymmetric mode, the processing steps of the monitoring control component include:

S1, starting a heartbeat timer;

S6, judging whether the virtual machine with the current abnormality is a main machine, if not, the main machine takes over service, restarting the standby virtual machine, and recording and reporting restarting information, if so, entering S7;

In fig. 10, the exception handling policy is mainly configured by the end user according to the traffic situation, and similar to the mode of fig. 9, the configurable exception policy is referred to as follows:

Wherein X, Y and Z take positive integer values.

The system constructed in the mode of fig. 10 requires less cost and is more economical than the system constructed in the mode of fig. 9.

Referring to fig. 11, the application further provides a virtual machine monitoring method, which comprises the following steps:

Step S110, monitoring at least one of abnormal state of task operation, abnormal state of interrupt processing, heartbeat information or service state information of a currently operated virtual machine;

step S120, acquiring the state information, and judging whether the currently running virtual machine needs to be switched or not according to the state information and a preset exception handling strategy;

and step S130, when the virtual machine is judged to need to be switched, hardware equipment resources are allocated for the virtual machine to be started, and the standby virtual machine takes over tasks.

According to the embodiment of the method, the system failure time can be reduced, the system availability time and reliability are improved, the timeliness and accuracy of switching between the main virtual machine and the standby virtual machine are improved, and the hardware cost of a user can be reduced.

It should be noted that, the specific implementation manner of each method embodiment may be performed with reference to the specific implementation manner of the corresponding system embodiment, which is not described herein.

In summary, the embodiments of the present application achieve the following features or beneficial effects:

The system failure time is reduced, and the system available time is improved. For example, a typical Linux-based intelligent driving system for an automobile requires 3-10 seconds from a hot restart to normal operation of the service. The high-availability system constructed by the application can be used for primary and backup hot switching, and can be normally completed in millisecond level, and compared with the system failure time which is reduced from second level to millisecond level.

And the reliability of the system is improved. The high availability system constructed according to the application is equivalent to adding parallel nodes to the original functional links. Assuming that the error probability of a single system is 0.01, after two single systems are connected in parallel to form a high-availability system, the error probability of the high-availability system is 0.0001, and the reliability of the system is improved by 100 times.

And the timeliness and accuracy of the primary and standby switching are improved. Conventionally, hypervisors-based high availability systems use heartbeats to monitor, and when the hypervisors monitor that a heartbeat is lost, traffic in the virtual machine system has failed for a period of time, and possibly the heartbeat has not been lost, but the traffic has failed. The safety measurement component provided by the application can more accurately and timely monitor service faults, timely trigger the primary and standby switching and reduce the failure time of a high-availability system.

And the economy of the system is improved. While the conventional method generally requires a plurality of physical machines to construct, the scheme provided by the application can construct a high-availability system based on a Hypervisor on a single physical machine, so that the hardware cost of a user is reduced.

It should be noted that:

The algorithms and displays presented herein are not inherently related to any particular computer, virtual machine, or other apparatus. Various general purpose devices may also be used with the teachings herein. The required structure for the construction of such devices is apparent from the description above. In addition, the present application is not directed to any particular programming language. It will be appreciated that the teachings of the present application described herein may be implemented in a variety of programming languages, and the above description of specific languages is provided for disclosure of enablement and best mode of the present application.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the application may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the application, various features of the application are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed application requires more features than are expressly recited in each claim.

Those skilled in the art will appreciate that the modules in the apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. The modules or units or components of the embodiments may be combined into one module or unit or component and, furthermore, they may be divided into a plurality of sub-modules or sub-units or sub-components. Any combination of all features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or units of any method or apparatus so disclosed, may be used in combination, except insofar as at least some of such features and/or processes or units are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features but not others included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the application and form different embodiments.

Various component embodiments of the application may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art will appreciate that some or all of the functions of some or all of the components in a grid map construction apparatus according to an embodiment of the present application may be implemented in practice using a microprocessor or Digital Signal Processor (DSP). The present application can also be implemented as an apparatus or device program (e.g., a computer program and a computer program product) for performing a portion or all of the methods described herein. Such a program embodying the present application may be stored on a computer readable medium, or may have the form of one or more signals. Such signals may be downloaded from an internet website, provided on a carrier signal, or provided in any other form.

The embodiment of the application also provides a nonvolatile computer storage medium, which stores at least one executable instruction, and the computer executable instruction can execute the virtual machine monitoring method in any of the method embodiments.

It should be noted that the above-mentioned embodiments illustrate rather than limit the application, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The application may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The use of the words first, second, third, etc. do not denote any order. These words may be interpreted as names.

Claims

1. A virtual machine monitoring system, characterized in that the virtual machine monitoring system comprises:

The security measurement component is used to monitor at least one of the following status information of the currently running virtual machine: abnormal status of task execution, abnormal status of interrupt handling, heartbeat information or business status information;

The monitoring and control component is used to obtain the status information reported by the security measurement component, and determine whether it is necessary to switch the currently running virtual machine based on the status information and the preset anomaly handling strategy.

The resource allocation component is used to allocate hardware resources to the virtual machine to be started when the monitoring and control component determines that the virtual machine needs to be switched.

2. The virtual machine monitoring system according to claim 1, wherein the sub-components within the security measurement component or the security measurement component communicate with the monitoring and control component via a shared memory channel.

3. The virtual machine monitoring system according to claim 1, wherein the abnormal running state of the task monitored by the security measurement component includes at least one of the following:

Does the task scheduling delay exceed the threshold?

Whether the percentage of tasks completed within the preset period has reached the threshold;

Did the task exit abnormally?

The abnormal states of interrupt handling monitored by the security metric component include at least one of the following:

Does the operating system's interrupt handling delay exceed a threshold?

Does the interrupt handler's processing time exceed the threshold?

Has the number of interrupts processed within the preset period reached the threshold?

4. The virtual machine monitoring system according to claim 3, wherein the monitoring logic of the security measurement component includes:

Configure a task list, threshold, and/or preset period in the virtual machine's configuration file, and register hook functions within the virtual machine's operating system; when the virtual machine is running, determine the abnormal state based on the call status of hook functions for different tasks in each functional module of the operating system, the threshold, and/or the preset period.

5. The virtual machine monitoring system according to claim 3 or 4, characterized in that the processing step of determining whether the task scheduling delay is less than a threshold includes: when the hook function of the enabled task is detected to be called, determining whether the enabled task is a monitoring task; if so, recording the task enable time td1 in the monitoring task list; when the task switching hook function is called, determining whether the target task of the switch is a monitoring task; if so, recording the task scheduling time td2 and calculating the scheduling delay time td2-td1; determining whether the scheduling delay time is greater than a threshold, and if it is greater than the threshold, reporting the scheduling delay timeout exception information to the monitoring and control component; if it is not greater than the threshold, not reporting.

The steps for determining whether the running share of a task within a preset period has reached the threshold include: starting a timer with a preset interval and recording the running time ts1 of each monitored task; when the timer expires, obtaining the running time slice ts2 of each monitored task again, and calculating the running share of each task within the period = ts2 - ts1; determining whether the running share of each task is less than the threshold; if it is less than the threshold, reporting the abnormal information of insufficient running share of the task to the monitoring and control component.

The steps for handling whether a task has exited abnormally include: when the task exit hook function is detected to be called, determine whether the exiting task is a critical task; if so, report the status information of the critical task's abnormal exit to the monitoring and control component.

6. The virtual machine monitoring system according to claim 3 or 4, characterized in that the step of determining whether the interrupt handling delay of the operating system is greater than a threshold includes: when the interrupt shutdown hook function of the operating system interrupt shutdown function is detected to be called, recording the start time ti1; when the interrupt enable hook function of the operating system interrupt enable function is detected to be called, recording the end time ti2, calculating the interrupt shutdown time ti2-ti1; determining whether the interrupt shutdown time is greater than the threshold, and if it is greater than the threshold, reporting the interrupt delay timeout status information to the monitoring and control component;

The steps for determining whether the interrupt handler's processing time exceeds the threshold include: when the interrupt handler's entry hook function is called, determining whether to monitor the interrupt; if so, recording the interrupt handling start time tc1 in the monitored interrupt list; when the interrupt handler's exit hook function is called, determining whether to monitor the interrupt; if so, recording the interrupt handling end time tc2, and calculating the interrupt handling time = tc2 - tc1; determining whether the interrupt handling time is greater than the threshold; if so, reporting the interrupt handling timeout exception information to the monitoring and control component.

The steps for determining whether the number of interrupts processed within a preset period has reached the threshold include: starting a timer with a preset interval and recording the current count c1 of each monitored interrupt; when the timer expires, obtaining the current count c2 of each monitored interrupt and calculating the number of interrupts processed within the period = c2 - c1; determining whether the number of interrupts processed is less than the threshold, and if so, reporting an abnormal message that the number of critical interrupts processed within the preset period is insufficient to the monitoring and control component.

7. The virtual machine monitoring system according to any one of claims 1-4, characterized in that the preset anomaly handling strategy in the monitoring and control component includes at least one of the following:

If task scheduling delay exceeds the threshold X times consecutively, switch virtual machines.

If any critical task exits abnormally, switch virtual machines;

If the critical interrupt handling time exceeds the threshold for Y consecutive times, switch virtual machines.

If the interrupt delay time exceeds the threshold for Z consecutive times, switch virtual machines.

Where X, Y, and Z are preset integer values.

8. The virtual machine monitoring system according to any one of claims 1-4, characterized in that the virtual machine includes a primary virtual machine and a standby virtual machine, and when the primary virtual machine and the standby virtual machine are in a symmetrical mode and have the same equipment resources and capabilities, the processing steps of the monitoring and control component include:

S1, start the heartbeat timer;

S2, wait for the security measurement component to report status information and obtain heartbeat timer information;

S3, determine if there is a case of virtual machine heartbeat loss. If yes, proceed to S5; otherwise, proceed to S4.

S4, determine if any virtual machine security measurement component has reported abnormal information. If not, return to S2; otherwise, proceed to S5.

S5, determine whether a switch is needed based on the preset exception handling strategy; if not, record and report the exception information and return to S2; if yes, proceed to S6.

S6, determine whether the currently abnormal virtual machine is the primary virtual machine;

S7. Otherwise, the primary virtual machine continues to take over the business, restarts the standby virtual machine, and then records and reports the restart information; if yes, the standby virtual machine is made the primary virtual machine and takes over the business, while the original primary virtual machine is changed to the standby virtual machine and restarted, and then the restart information is recorded and reported.

9. The virtual machine monitoring system according to any one of claims 1-4, characterized in that the virtual machine includes a primary virtual machine and a standby virtual machine, and when the primary virtual machine and the standby virtual machine are in an asymmetric mode, and the standby virtual machine obtains fewer device resources and capabilities relative to the primary virtual machine, the processing steps of the monitoring and control component include:

S1, start the heartbeat timer;

S3, determine if there is a case of virtual machine heartbeat loss. If yes, proceed to S6; otherwise, proceed to the next step.

S5, determine whether a switch is needed based on the preset exception handling strategy; otherwise, record and report the exception information and return to S2; otherwise, proceed to S6.

S6, determine if the currently abnormal virtual machine is the primary one; if not, the primary virtual machine continues to take over the business, restart the standby virtual machine, and record and report the restart information; if it is, proceed to S7.

S7, the standby virtual machine takes over the service, restarts the primary virtual machine, and records and reports the restart information;

S8 determines whether the primary virtual machine has restarted successfully. If the restart is successful, the primary virtual machine will take over the business again and enter the next loop. If the restart is unsuccessful, return to S5.

10. A virtual machine monitoring method, characterized in that the virtual machine monitoring method includes:

Monitor at least one of the following status information of the currently running virtual machine: abnormal status of task execution, abnormal status of interrupt handling, heartbeat information or business status information;

Obtain the status information, and determine whether to switch the currently running virtual machine based on the status information and the preset exception handling strategy;

When it is determined that a virtual machine needs to be switched, hardware resources are allocated to the virtual machine to be started, and the virtual machine takes over the tasks.