CN112835739B

CN112835739B - Downtime processing method and device

Info

Publication number: CN112835739B
Application number: CN201911155242.7A
Authority: CN
Inventors: 胡晓伟
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Filing date: 2019-11-22
Publication date: 2024-07-09
Anticipated expiration: 2039-11-22

Abstract

The embodiment of the application discloses a downtime treatment method and device. One embodiment of the above method comprises: in response to receiving the downtime alarm information for the target host, performing downtime confirmation on the target host; in response to determining that the target host is down, acquiring related information of the target host, wherein the related information comprises information of the target host and information of a virtual machine hosted on the target host; based on the related information, performing downtime recovery on the virtual machine hosted on the target host; and responding to the completion of the downtime recovery of the target host and the virtual machine, and automatically diagnosing the downtime of the target host. The implementation improves the fault recovery quality and speed of the host.

Description

Downtime processing method and device

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a downtime processing method and device.

Background

In the related art, if the host is down, the operation and maintenance personnel can collect information of the down host, and then repair and function recovery are performed for the host.

However, this process often requires manual monitoring and handling to be implemented. And because the steps are more, the probability of error of manual processing is higher. In addition, the uncontrollable factors of manual processing are more, the intervention speed is low, and the function recovery speed is low easily, so that the fault recovery quality and speed of the product are difficult to ensure.

Disclosure of Invention

The embodiment of the application provides a downtime processing method and device.

In a first aspect, an embodiment of the present application provides a downtime processing method, including: in response to receiving downtime alarm information aiming at a target host, performing downtime confirmation on the target host; in response to determining that the target host is down, acquiring related information of the target host, wherein the related information comprises information of the target host and information of a virtual machine hosted on the target host; based on the related information, performing downtime recovery on the target host machine and the virtual machine hosted on the target host machine; and responding to the completion of the downtime of the target host machine and the virtual machine, and automatically diagnosing the downtime of the target host machine.

In some embodiments, the identifying the downtime of the target host includes: sending downtime confirmation information of the target host to target electronic equipment, wherein the downtime confirmation information is used for confirming whether the target host is downtime or not; and responding to receiving feedback information sent by the target electronic equipment and used for indicating the downtime of the target host, and confirming the downtime of the target host.

In some embodiments, the information of the virtual machine hosted on the target host machine includes resource information used by the virtual machine; and performing downtime recovery on the target host and the virtual machine hosted on the target host based on the related information, including: determining whether a non-host dependent virtual machine exists according to the resource information used by the virtual machine, wherein the non-host dependent virtual machine indicates that data required by the operation of the virtual machine is not located on the local site of the target host machine; the non-host dependent virtual machine is migrated in response to determining that the non-host dependent virtual machine exists.

In some embodiments, the information of the target host includes resource information of the target host; and said migrating said host-independent virtual machine, comprising: selecting a new host machine, wherein the resource information of the new host machine is the same as the resource information of the target host machine; and migrating the non-host dependent virtual machine to a new host machine.

In some embodiments, the performing downtime recovery on the target host and the virtual machine hosted on the target host based on the related information includes: determining whether a host dependent virtual machine exists according to the resource information used by the virtual machine, wherein the host dependent virtual machine indicates that data required by the running of the virtual machine is located in the target host; in response to determining that a host-dependent virtual machine exists and detecting that the downtime recovery of the target host is complete, detecting whether the downtime recovery of the target host is complete, wherein the downtime recovery of the target host is achieved by starting a first automatic recovery program after downtime, and starting a second automatic recovery program after the downtime recovery of the target host is complete; and migrating the host dependent virtual machine in response to determining that the downtime recovery of the host dependent virtual machine is complete.

In some embodiments, the automatically diagnosing the downtime of the target host includes: acquiring fault information of the target host and executing output information of a diagnosis command when the target host is in downtime confirmation; and determining a downtime cause and a suggested recovery step for the downtime cause according to the information of the target host, the fault information, the execution output information and a preset operation and maintenance knowledge base.

In some embodiments, the above method further comprises: in response to receiving confirmation information for the downtime cause and the suggested recovery step, adding the downtime cause and the suggested recovery step to the operation and maintenance knowledge base; and in response to receiving the modification information for the downtime reasons and the suggested recovery steps, adding the modified downtime reasons and the modified suggested recovery steps to the operation and maintenance knowledge base.

In some embodiments, the above method further comprises: and in response to determining that the target host is down, shielding fault alarm information for the target host.

In some embodiments, the above method further comprises: and in response to completion of downtime recovery of the target host and the virtual machine hosted on the target host, unblocking fault alarm information for the target host.

In some embodiments, the preset terminal is configured with a downtime manual processing interface; the method further comprises the following steps: and in response to detecting that the target host is not recovered within a preset time period, sending a manual processing notification message to a preset terminal so as to perform manual intervention processing through the downtime manual processing interface.

In a second aspect, an embodiment of the present application provides a downtime processing apparatus, including: the downtime confirmation unit is configured to confirm the downtime of the target host machine in response to receiving downtime alarm information aiming at the target host machine; an information acquisition unit configured to acquire, in response to a determination that the target host is down, related information of the target host, the related information including information of the target host and information of a virtual machine hosted on the target host; the downtime recovery unit is configured to perform downtime recovery on the target host machine and the virtual machine hosted on the target host machine based on the related information; and the automatic diagnosis unit is configured to automatically diagnose the downtime of the target host machine in response to the completion of the downtime recovery of the target host machine and the virtual machine.

In some embodiments, the downtime confirmation unit is further configured to: sending downtime confirmation information of the target host to target electronic equipment, wherein the downtime confirmation information is used for confirming whether the target host is downtime or not; and responding to receiving feedback information sent by the target electronic equipment and used for indicating the downtime of the target host, and confirming the downtime of the target host.

In some embodiments, the information of the virtual machine hosted on the target host machine includes resource information used by the virtual machine; and the downtime recovery unit is further configured to: determining whether a non-host dependent virtual machine exists according to the resource information used by the virtual machine, wherein the non-host dependent virtual machine indicates that data required by the operation of the virtual machine is not located on the local site of the target host machine; the non-host dependent virtual machine is migrated in response to determining that the non-host dependent virtual machine exists.

In some embodiments, the information of the target host includes resource information of the target host; and the downtime recovery unit is further configured to: selecting a new host machine, wherein the resource information of the new host machine is the same as the resource information of the target host machine; and migrating the non-host dependent virtual machine to a new host machine.

In some embodiments, the downtime recovery unit described above is further configured to: determining whether a host dependent virtual machine exists according to the resource information used by the virtual machine, wherein the host dependent virtual machine indicates that data required by the running of the virtual machine is located in the target host; in response to determining that a host-dependent virtual machine exists and detecting that the downtime recovery of the target host is complete, detecting whether the downtime recovery of the target host is complete, wherein the downtime recovery of the target host is achieved by starting a first automatic recovery program after downtime, and starting a second automatic recovery program after the downtime recovery of the target host is complete; and migrating the host dependent virtual machine in response to determining that the downtime recovery of the host dependent virtual machine is complete.

In some embodiments, the above-described automatic diagnostic unit is further configured to: acquiring fault information of the target host and executing output information of a diagnosis command when the target host is in downtime confirmation; and determining a downtime cause and a suggested recovery step for the downtime cause according to the information of the target host, the fault information, the execution output information and a preset operation and maintenance knowledge base.

In some embodiments, the apparatus further comprises a knowledge base updating unit configured to: in response to receiving confirmation information for the downtime cause and the suggested recovery step, adding the downtime cause and the suggested recovery step to the operation and maintenance knowledge base; and in response to receiving the modification information for the downtime reasons and the suggested recovery steps, adding the modified downtime reasons and the modified suggested recovery steps to the operation and maintenance knowledge base.

In some embodiments, the apparatus further comprises: and the information shielding unit is configured to shield fault alarm information for the target host machine in response to determining that the target host machine is down.

In some embodiments, the apparatus further comprises: and a shielding release unit configured to release the shielding of the fault alarm information for the target host in response to completion of the downtime recovery of the target host and the virtual machine hosted on the target host.

In some embodiments, the preset terminal is configured with a downtime manual processing interface; the above apparatus further comprises: and the manual intervention unit is configured to send a manual processing notification message to a preset terminal to perform manual intervention processing through the downtime manual processing interface in response to detecting that the target host is not recovered within a preset time period.

In a third aspect, an embodiment of the present application provides an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, which when executed by the one or more processors cause the one or more processors to implement the method as described in any of the embodiments of the first aspect.

In a fourth aspect, embodiments of the present application provide a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a method as described in any of the embodiments of the first aspect.

According to the downtime processing method and device provided by the embodiment of the application, after the downtime alarm information aiming at the target host is received, the target host can be confirmed. After determining that the target host is down, the related information of the target host can be acquired. The related information may include information of the target host and information of the virtual machine hosted on the target host. And then, based on the related information, performing downtime recovery on the target host machine and the virtual machine hosted on the target host machine. After the target host and the virtual machine hosted on the target host are determined to be in downtime recovery, the downtime of the target host can be automatically diagnosed. The method of the embodiment can automatically recover and automatically diagnose when the host machine is down, thereby improving the fault recovery quality and speed of the host machine.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the accompanying drawings in which:

FIG. 1 is an exemplary system architecture diagram in which an embodiment of the present application may be applied;

FIG. 2 is a flow chart of one embodiment of a downtime treatment method in accordance with the present application;

FIG. 3 is a schematic diagram of an application scenario of the downtime treatment method according to the present application;

FIG. 4 is a flow chart of another embodiment of a downtime treatment method in accordance with the present application;

FIG. 5 is a schematic diagram of an embodiment of a downtime treatment apparatus in accordance with the present application;

Fig. 6 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the application.

Detailed Description

The application is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the application and are not limiting of the application. It should be noted that, for convenience of description, only the portions related to the present application are shown in the drawings.

It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other. The application will be described in detail below with reference to the drawings in connection with embodiments.

FIG. 1 illustrates an exemplary system architecture 100 in which embodiments of a downtime processing method or downtime processing apparatus of the present application may be applied.

As shown in fig. 1, the system architecture 100 may include terminal devices 101, 102, 103, a network 104, a host 105, and virtual machines 106, 107, 108. The network 104 is a medium used to provide communication links between the terminal device 101 and the virtual machine 106, between the terminal device 102 and the virtual machine 107, and between the terminal device 103 and the virtual machine 108. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may interact with virtual machines 106, 107, 108 over network 104 using terminal devices 101, 102, 103 to receive or send messages, etc. Various communication client applications, such as video-type applications, live applications, instant messaging tools, mailbox clients, social platform software, etc., may be installed on the terminal devices 101, 102, 103.

The terminal devices 101, 102, 103 may be hardware or software. When the terminal devices 101, 102, 103 are hardware, they may be various electronic devices with display screens, including but not limited to smartphones, tablets, electronic book readers, laptop and desktop computers, and the like. When the terminal devices 101, 102, 103 are software, they can be installed in the above-listed electronic devices. Which may be implemented as multiple software or software modules (e.g., multiple software or software modules for providing distributed services) or as a single software or software module. The present invention is not particularly limited herein.

The host 105 may be a server hosted by the virtual machines 106, 107, 108. The virtual machines 106, 107, 108 may be servers providing various services, such as background servers providing support for the terminal devices 101, 102, 103. The background server may analyze and process the data such as the fault information, and feed back the processing result (for example, the fault notification information) to the terminal device.

It should be noted that, the downtime processing method provided in the embodiment of the present application may be executed by a server or a terminal device other than the host machine 105 and the virtual machines 106, 107, 108, for example, the execution body may be a server in a server cluster together with the host machine 105 and the virtual machines 106, 107, 108, or a control server, etc. Accordingly, the downtime processing apparatus may be disposed in the server or the terminal device.

It should be understood that the number of terminal devices, networks, servers, and virtual machines in fig. 1 are merely illustrative. There may be any number of terminal devices, networks, servers, and virtual machines, as desired for implementation.

With continued reference to FIG. 2, a flow 200 of one embodiment of a downtime treatment method in accordance with the present application is shown. The downtime processing method of the embodiment comprises the following steps:

In step 201, in response to receiving the downtime alarm information for the target host, a downtime confirmation is performed for the target host.

In this embodiment, the execution main body of the downtime processing method may receive downtime alarm information for the target host through a wired connection manner or a wireless connection manner. And, the execution subject may perform downtime confirmation for the target host when or after receiving downtime alarm information for the target host. Here, the downtime confirmation is used to confirm whether the target host is downtime.

Specifically, the execution body may determine whether the target host is down in various manners, for example, send a message to the target host, and if the target host does not reply within a preset duration, consider that the target host is down. Or the execution main body can remotely log in the target host machine, and if the target host machine can not successfully log in, the target host machine is considered to be down.

In some optional implementations of the present embodiment, the execution subject may perform downtime confirmation for the target host through the following steps not shown in fig. 2: sending downtime confirmation information to a target host to target electronic equipment, wherein the downtime confirmation information is used for confirming whether the target host is downtime or not; and responding to receiving feedback information sent by the target electronic equipment and used for indicating the downtime of the target host, and confirming the downtime of the target host.

In this implementation, the execution body may send, to the target electronic device, downtime confirmation information for the target host. The target electronic device may be a target host, or may be another electronic device capable of determining whether the target host is down. In practice, the executing body or the other electronic device may send detection information to the target host, and if the target host does not return information, the target host may be down. Or if the execution main body or the other electronic equipment receives the downtime event information output by the target host, the target host can be determined to be downtime.

Step 202, in response to determining that the target host is down, acquiring relevant information of the target host.

When or after determining that the target host is down, the execution subject may further acquire relevant information of the target host. Here, the related information of the target host may include information of the target host and information of a virtual machine hosted on the target host. The information of the target host may include information such as a hardware configuration of the host, a resource configuration, and a virtual machine of the host. The information of the virtual machine may include information indicating a host machine to which the virtual machine is hosted, information indicating a resource configuration of the virtual machine, and the like. The execution body may obtain relevant information of the target host from other electronic devices or locally, so as to facilitate subsequent operations, such as initiating data migration.

In some optional implementations of the present embodiment, the method may further include the following steps not shown in fig. 2: and in response to determining that the target host is down, screening fault alarm information for the target host.

In this implementation, the executing body may mask the fault alarm information for the target host when or after determining that the target host is down. It will be appreciated that the virtual machine on which the target host is hosted is not available after downtime, which may trigger a variety of fault alert messages. Typically, each fault alarm information pair triggers a certain recovery step, which may include sending information to a terminal held by a technician, or triggering a recovery procedure, etc. These alarm messages may not be sent out again after the target host has recovered from the downtime. Therefore, the execution main body can directly carry out downtime recovery on the target host machine, and simultaneously shield other fault alarm information aiming at the target host machine so as to avoid the execution of various recovery steps.

And 203, performing downtime recovery on the target host and the virtual machine hosted on the target host based on the related information.

After the related information of the target host is obtained, the execution main body can perform downtime recovery on the target host and the virtual machine hosted on the target host. The downtime recovery may include data migration, such as migration of data stored on a target host. The method can be realized by sending an instruction to the target host machine when the downtime is recovered, and can also be realized by automatically starting a recovery program by the target host machine. For example, the execution main body or other electronic devices send a data migration instruction to the target host machine, or a downtime recovery program is implanted in the target host machine in advance, and when the target host machine is downtime, a downtime event triggers the recovery program to realize downtime recovery.

In some alternative implementations of the present embodiment, the information of the virtual machine hosted on the target host includes resource information used by the virtual machine. The execution body may further implement downtime recovery through the following steps not shown in fig. 2: determining whether a non-host dependent virtual machine exists according to the resource information used by the virtual machine; in response to determining that the non-host dependent virtual machine is present, the non-host dependent virtual machine is migrated.

In this implementation, the resource information used by the virtual machine may include information of a storage location of data of the virtual machine, for example, if the data of the virtual machine is stored in the cloud, the resource information used by the virtual machine may include a cloud disk. If the data of the virtual machine is stored locally to the target host, the resource information used by the virtual machine may include a local disk. The execution body may determine whether there is a non-host dependent virtual machine based on the resource information used by the virtual machine. This time, a non-host dependent virtual machine may refer to a virtual machine that can run without the need for data local to the host. Since the data that is not dependent on the host-independent virtual machine is not stored locally on the target host, the failure of the host-independent virtual machine can be resolved by migrating the host-independent virtual machine to other hosts.

In some alternative implementations of the present embodiment, the information of the target host includes resource information of the target host. In migrating a non-host dependent virtual machine, the execution body may be implemented by the following steps, not shown in fig. 2: selecting a new host machine; migration of the non-host dependent virtual machine to the new host.

In this implementation, the execution body may select a new host for the non-host dependent virtual machine. In order to ensure that the virtual machine can quickly recover from failure, the execution subject may select a host machine whose resource information is the same as that of the target host machine as a new host machine. In this way, the fault recovery can be achieved without requiring a new setting for the non-host dependent virtual machine.

In some alternative implementations of the present embodiment, the execution body may further implement downtime recovery through the following steps not shown in fig. 2: determining whether a host dependent virtual machine exists according to the resource information used by the virtual machine; detecting whether the host dependent virtual machine is in downtime recovery completion or not in response to determining that the host dependent virtual machine exists and detecting that downtime recovery of the target host machine is complete; and in response to determining that the downtime recovery of the host-dependent virtual machine is complete, selecting a new host machine and migrating the host-dependent virtual machine to the new host machine.

In this implementation manner, the execution body may further determine, according to the resource information used by the virtual machine, whether there is a host dependent virtual machine. Here, the host-dependent virtual machine means that data required for the virtual machine to run is located locally to the target host. If the execution subject determines that the host dependent virtual machine exists, the downtime recovery degree of the target host can be detected. In the implementation manner, the downtime recovery of the target host is realized by starting a first automatic recovery program after the target host is in downtime. If the downtime recovery of the target host is completed, the execution body may detect whether the downtime recovery of the host-dependent virtual machine is completed. And after the target host machine is in downtime recovery, starting a second automatic recovery program to realize the downtime recovery of the host dependent virtual machine. After determining that the host-dependent virtual machine downtime recovery is completed, the execution body can migrate the host-dependent virtual machine. Specifically, the executing body may select a new host machine and then migrate the host dependent virtual machine to the new host machine. It can be understood that the selection of the new host machine may be the same as the selection of the new host machine by the migration process of the non-host dependent virtual machine, or the migration of the host dependent virtual machine to the host machine hosted by the migrated non-host dependent virtual machine may be performed.

And 204, in response to the completion of the downtime recovery of the target host and the virtual machine, automatically diagnosing the downtime of the target host.

The execution body can automatically diagnose the downtime of the target host machine when or after determining that the downtime of the target host machine and the virtual machine is recovered. In this embodiment, the automatic diagnosis may determine the cause of the downtime of the target host, a means for solving the downtime, or a suggested recovery step for the downtime, etc.

In some optional implementations of the present embodiment, the method may further include the following steps not shown in fig. 2: and in response to completion of downtime recovery of the target host and the virtual machine hosted on the target host, unblocking fault alarm information for the target host.

In this implementation, the execution body may unmask the fault alert information for the target host when or after determining that the recovery of the target host and the virtual machine hosted on the target host from downtime is complete. In this way, fault monitoring of the target host and the virtual machines hosted on the target host may be resumed.

In some optional implementations of this embodiment, the preset terminal device is configured with a downtime manual processing interface. Here, the preset terminal may be a terminal device used by an operation and maintenance person. The above method may further comprise the following steps, not shown in fig. 2: and in response to detecting that the target host is not recovered within the preset time period, sending a manual processing notification message to the preset terminal so as to perform manual intervention processing through the downtime manual processing interface.

In this implementation manner, if the execution body detects that the target host is not recovered within the preset duration, the execution body may send a manual processing notification message to the preset terminal. Thus, operation and maintenance personnel can perform manual intervention treatment through the downtime manual treatment interface so as to recover the downtime target host machine as soon as possible.

In some optional implementations of this embodiment, the method further includes: and sending fault notification information to target terminal equipment associated with the service of the virtual machine, wherein the fault notification information corresponds to the category of the virtual machine. Correspondingly, the method further comprises the steps of: and sending fault release notification information to the target terminal equipment in response to receiving the downtime release information of the target host.

In these alternative implementations, the executing entity may send fault notification information to the target terminal device to notify the user of the virtual machine affected by the downtime of the target host. The failure notification information indicates that the virtual machine is affected by the downtime of the target host. The target terminal device associated with the virtual machine service may be not only a terminal device requesting the virtual machine service, but also a terminal device used by a customer service person corresponding to the service of the virtual machine, or a terminal device of an operation and maintenance person of the service, and the like.

In practice, the executing body may categorize the virtual machines and send different fault notification information to the target terminal devices associated with the services of the virtual machines of different categories. The target terminal devices associated with the services of the different classes of virtual machines may be different.

Specifically, the classification of the virtual machine may be based on whether the virtual machine depends on the host machine, and thus, a host-dependent virtual machine and a non-host-dependent virtual machine are obtained, where the dependence on the host may refer to that the virtual machine needs data local to the host machine to operate. In addition, the basis of classification may also be whether to provide services to customers (i.e., users), and thereby obtain user-service virtual machines and non-user-service virtual machines. The user service virtual machine refers to that the virtual machine provides service for certain software of the terminal equipment of the client, and the host machine downtime of the virtual machine directly influences the use of the software by the user. It should be noted that, the virtual machine may be divided according to only one division basis to obtain a virtual machine with one class label, or may be divided according to more than two bases to obtain a virtual machine with at least two class labels. For example, one virtual machine may serve both a host dependent virtual machine and a user virtual machine.

For example, the virtual machine a of the target host is a user service virtual machine, the virtual machine B of the target host is a non-user service virtual machine, and the execution body sends the failure notification information a, i.e. "system failure", to the service-associated number 1 mobile machine of the virtual machine a, and sends the failure notification information B, i.e. "system failure", to the service-associated number 2 mobile machine of the virtual machine B.

For example, if the virtual machine a of the target host is a host-dependent virtual machine, the virtual machine B of the target host is a non-host-dependent virtual machine, and the execution subject sends the failure notification information a, i.e. "system failure, to the mobile phone 1 associated with the service of the virtual machine a, asking for personnel to overhaul. The failure notification information B, that is, "system failure, is sent to the mobile phone No. 2 associated with the service of the virtual machine B, and is good later.

The downtime release information indicates that the downtime of the target host has been released, and the function of the target host may be restored or restored. The execution body may send, when receiving the downtime release information, failure notification information indicating that the downtime failure has been released to the target terminal device.

The implementation modes can carry out fault notification to each terminal device according to the categories, so that users corresponding to the virtual machines in different categories receive the targeted notification, and meanwhile, the fault notification information is more readable.

With continued reference to fig. 3, fig. 3 is a schematic diagram of an application scenario of the downtime processing method according to the present embodiment. In the application scenario of fig. 3, the control server 301 may perform downtime confirmation for the target host 302 in response to downtime alarm information for the target host 302. After determining that the target host 302 is down, the control server 301 acquires relevant information of the target host 302. And based on the relevant information, the target host 302 is downed for recovery. After the downtime recovery is completed, the downtime of the target host 302 is automatically diagnosed.

According to the downtime processing method provided by the embodiment of the application, after the downtime alarm information aiming at the target host is received, the target host can be confirmed to be downtime. After determining that the target host is down, the related information of the target host can be acquired. The related information may include information of the target host and information of the virtual machine hosted on the target host. And then, based on the related information, performing downtime recovery on the target host machine and the virtual machine hosted on the target host machine. After the target host and the virtual machine hosted on the target host are determined to be in downtime recovery, the downtime of the target host can be automatically diagnosed. The method of the embodiment can automatically recover and automatically diagnose when the host machine is down, thereby improving the fault recovery quality and speed of the host machine.

With continued reference to FIG. 4, a flow 400 of another embodiment of a downtime treatment method in accordance with the present application is shown. As shown in fig. 4, the downtime processing method of the present embodiment may include the following steps:

and step 401, in response to receiving the downtime alarm information for the target host, performing downtime confirmation on the target host.

In step 402, in response to determining that the target host is down, relevant information of the target host is obtained.

And step 403, performing downtime recovery on the target host and the virtual machine hosted on the target host based on the related information.

The principle of steps 401 to 403 is similar to that of steps 201 to 203 and will not be described here again.

And step 404, in response to completion of downtime recovery of the target host and the virtual machine, obtaining fault information of the target host and execution output information of the diagnosis command when downtime confirmation is performed on the target host.

In this embodiment, the relevant information of the target host may include log information of the target host and environment information of the target host. The log information may be data generated by the target host during the operation process. The environmental information may include information of the environment in which the target host is located, may include temperature, humidity, location, and the like.

The execution body may acquire fault information of the target host when or after determining that the downtime recovery of the target host and the virtual machine is completed. The failure information may be information indicating a failure type of the target host. In particular, the fault types may include hardware faults and software faults. The fault information may be obtained from other electronic devices, from a hardware fault platform that collects hardware fault information, or from a software fault platform that collects software fault information. The electronic equipment and the fault platform can collect the fault event information output by the host machine so as to determine the fault information.

The execution main body can also acquire the execution output information of the diagnosis command when other electronic equipment confirms the downtime of the target host. It can be appreciated that the execution body or other electronic device may send some diagnostic commands to the target host when performing downtime confirmation or fault confirmation on the target host, and the target host may output some information for the diagnostic commands. This information reflects the type of failure of the target host.

And step 405, determining a downtime cause and a suggested recovery step for the downtime cause according to the information of the target host, the fault information, the execution output information and a preset operation and maintenance knowledge base.

The execution main body can determine the downtime cause of the target host machine and the suggested recovery step aiming at the downtime cause according to the obtained information and the preset operation and maintenance knowledge base. Here, the operation and maintenance knowledge base may include the type of the fault, the cause of the fault, and the steps taken to recover the fault. The execution body can search the operation and maintenance knowledge base by taking the obtained information as a search word, obtain the fault reason matched with the information as a downtime reason, and take a recovery step corresponding to the fault reason as a suggested recovery step.

The execution body can output the obtained downtime reasons and the suggested recovery steps for operation and maintenance personnel to refer to.

In some optional implementations of the present embodiment, the method may further include the following steps not shown in fig. 4: in response to receiving the confirmation information for the downtime cause and the suggested recovery step, adding the downtime cause and the suggested recovery step to the operation and maintenance knowledge base; and in response to receiving the modification information for the downtime cause and the suggested recovery step, adding the modified downtime cause and the modified suggested recovery step to the operation and maintenance knowledge base.

In this implementation manner, the execution body may output the obtained downtime cause and the suggested recovery step for the operation and maintenance personnel to view. If the operation and maintenance personnel determine that the downtime causes and suggest that the recovery steps are correct, the operation and maintenance personnel can be added into an operation and maintenance knowledge base. Similarly, if the operation and maintenance personnel determine that the downtime cause and the recommended recovery step are wrong, the downtime cause and the recommended recovery step can be modified according to the downtime cause of the downtime of the target host. The execution body may add the modified downtime cause and the modified suggested recovery step to the operation and maintenance knowledge base. In this way, an update of the operation and maintenance knowledge base can be achieved.

In some optional implementations of this embodiment, the execution body may further update the first automatic recovery program that the target host operates when down according to the updated operation and maintenance knowledge base. Or the execution body can update the second automatic recovery program operated by the virtual machine hosted on the target host machine when the virtual machine is down according to the updated operation and maintenance knowledge base.

The downtime processing method provided by the embodiment of the application can automatically diagnose the downtime reasons and update the operation and maintenance knowledge base.

With further reference to fig. 5, as an implementation of the method shown in the foregoing drawings, the present application provides an embodiment of a downtime processing apparatus, where the embodiment of the apparatus corresponds to the embodiment of the method shown in fig. 2, and the apparatus may be specifically applied to various electronic devices.

As shown in fig. 5, the downtime processing apparatus 500 of the present embodiment includes: a downtime confirmation unit 501, an information acquisition unit 502, a downtime restoration unit 503, and an automatic diagnosis unit 504.

The downtime confirmation unit 501 is configured to perform downtime confirmation on the target host in response to receiving downtime alarm information for the target host.

The information obtaining unit 502 is configured to obtain relevant information of the target host in response to determining that the target host is down. The related information includes information of the target host and information of a virtual machine hosted on the target host.

And a downtime recovery unit 503 configured to perform downtime recovery on the target host and the virtual machine hosted on the target host based on the related information.

An automatic diagnosis unit 504 configured to automatically diagnose the downtime of the target host in response to completion of the downtime recovery of the target host and the virtual machine.

In some optional implementations of the present embodiment, the downtime confirmation unit 501 may be further configured to: sending downtime confirmation information to a target host to target electronic equipment, wherein the downtime confirmation information is used for confirming whether the target host is downtime or not; and responding to receiving feedback information sent by the target electronic equipment and used for indicating the downtime of the target host, and confirming the downtime of the target host.

In some alternative implementations of the present embodiment, the information of the virtual machine hosted on the target host includes resource information used by the virtual machine. The downtime recovery unit 503 is further configured to: determining whether a non-host dependent virtual machine exists according to the resource information used by the virtual machine, wherein the non-host dependent virtual machine indicates that data required by the operation of the virtual machine is not located on the local site of the target host; in response to determining that the non-host dependent virtual machine is present, the non-host dependent virtual machine is migrated.

In some alternative implementations of the present embodiment, the information of the target host includes resource information of the target host. The downtime recovery unit 503 is further configured to: selecting a new host, wherein the resource information of the new host is the same as the resource information of the target host; migration of the non-host dependent virtual machine to the new host.

In some optional implementations of the present embodiment, the downtime recovery unit 503 is further configured to: determining whether a host dependent virtual machine exists according to the resource information used by the virtual machine, wherein the host dependent virtual machine indicates that data required by the operation of the virtual machine is located in the target host; in response to determining that a host-dependent virtual machine exists and detecting that the downtime of a target host is completed, detecting whether the downtime of the host-dependent virtual machine is completed, wherein the downtime of the target host is completed by starting a first automatic recovery program after downtime, and starting a second automatic recovery program after the downtime of the target host is completed; and migrating the host-dependent virtual machine in response to determining that the downtime recovery of the host-dependent virtual machine is complete.

In some optional implementations of the present embodiment, the automatic diagnostic unit 504 is further configured to: obtaining fault information of a target host and executing output information of a diagnosis command when the target host is in downtime confirmation; and determining the downtime cause and the suggested recovery step aiming at the downtime cause according to the information of the target host, the fault information, the execution output information and the preset operation and maintenance knowledge base.

In some optional implementations of this embodiment, the apparatus 500 may further include a knowledge base updating unit not shown in fig. 5, configured to: in response to receiving the confirmation information for the downtime cause and the suggested recovery step, adding the downtime cause and the suggested recovery step to the operation and maintenance knowledge base; and in response to receiving the modification information for the downtime cause and the suggested recovery step, adding the modified downtime cause and the modified suggested recovery step to the operation and maintenance knowledge base.

In some optional implementations of this embodiment, the apparatus 500 may further include an information shielding unit, which is not shown in fig. 5, configured to shield the fault alarm information for the target host in response to determining that the target host is down.

In some optional implementations of this embodiment, the apparatus 500 may further include a shielding release unit, which is not shown in fig. 5, configured to release the shielding of the fault alarm information for the target host in response to completion of the downtime recovery of the target host and the virtual machine hosted on the target host.

In some optional implementations of this embodiment, the preset terminal is configured with a downtime manual processing interface. The apparatus 500 may further include a human intervention unit, not shown in fig. 5, configured to send a human intervention notification message to the preset terminal to perform a human intervention process through the downtime human intervention interface in response to detecting that the target host is not restored within the preset time period.

It should be appreciated that the units 501 to 504 described in the downtime treatment apparatus 500 correspond to the respective steps in the method described with reference to fig. 2. Thus, the operations and features described above with respect to the downtime treatment method are equally applicable to the apparatus 500 and the units contained therein, and are not described in detail herein.

Referring now to fig. 6, a schematic diagram of an electronic device 600 suitable for use in implementing embodiments of the present disclosure is shown. The electronic device shown in fig. 6 is merely an example and should not impose any limitations on the functionality and scope of use of embodiments of the present disclosure.

As shown in fig. 6, the electronic device 600 may include a processing means (e.g., a central processing unit, a graphics processor, etc.) 601, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage means 608 into a Random Access Memory (RAM) 603. In the RAM603, various programs and data required for the operation of the electronic apparatus 600 are also stored. The processing device 601, the ROM 602, and the RAM603 are connected to each other through a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

In general, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 607 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 608 including, for example, magnetic tape, hard disk, etc.; and a communication device 609. The communication means 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While fig. 6 shows an electronic device 600 having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead. Each block shown in fig. 6 may represent one device or a plurality of devices as needed.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via communication means 609, or from storage means 608, or from ROM 602. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing means 601. It should be noted that, the computer readable medium according to the embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In an embodiment of the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. Whereas in embodiments of the present disclosure, the computer-readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: in response to receiving the downtime alarm information for the target host, performing downtime confirmation on the target host; in response to determining that the target host is down, acquiring related information of the target host, wherein the related information comprises information of the target host and information of a virtual machine hosted on the target host; based on the related information, performing downtime recovery on the virtual machine hosted on the target host; and responding to the completion of the downtime recovery of the target host and the virtual machine, and automatically diagnosing the downtime of the target host.

Computer program code for carrying out operations of embodiments of the present disclosure may be written in one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments described in the present disclosure may be implemented by means of software, or may be implemented by means of hardware. The described units may also be provided in a processor, for example, described as: a processor includes a downtime confirmation unit, an information acquisition unit, a downtime restoration unit, and an automatic diagnosis unit. The names of these units do not limit the units themselves in some cases, and for example, the downtime confirmation unit may also be described as "a unit that performs downtime confirmation for a target host".

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above technical features, but encompasses other technical features formed by any combination of the above technical features or their equivalents without departing from the spirit of the invention. Such as the above-described features, are mutually substituted with (but not limited to) the features having similar functions disclosed in the embodiments of the present disclosure.

Claims

1.A downtime treatment method, comprising:

responsive to receiving downtime alarm information for a target host, performing downtime confirmation on the target host;

In response to determining that the target host is down, acquiring related information of the target host, wherein the related information comprises information of the target host and information of a virtual machine hosted on the target host, and the information of the virtual machine hosted on the target host comprises resource information used by the virtual machine;

based on the related information, performing downtime recovery on the target host and the virtual machine hosted on the target host;

Responding to the completion of the downtime of the target host and the virtual machine, and automatically diagnosing the downtime of the target host;

and performing downtime recovery on the target host and the virtual machine hosted on the target host based on the related information, wherein the downtime recovery comprises the following steps:

Determining whether a host dependent virtual machine exists according to the resource information used by the virtual machine, wherein the host dependent virtual machine represents that data required by the running of the virtual machine is located in the target host;

in response to determining that a host-dependent virtual machine exists and detecting that the downtime recovery of the target host is completed, detecting whether the downtime recovery of the host-dependent virtual machine is completed, wherein the downtime recovery of the target host is achieved by starting a first automatic recovery program after downtime, and starting a second automatic recovery program after the downtime recovery of the target host is completed;

And in response to determining that the downtime recovery of the host-dependent virtual machine is completed, selecting a new host machine and migrating the host-dependent virtual machine to the new host machine.

2. The method of claim 1, wherein the downtime confirmation of the target host comprises:

Sending downtime confirmation information of the target host to target electronic equipment, wherein the downtime confirmation information is used for confirming whether the target host is downtime or not;

and responding to receiving feedback information sent by the target electronic equipment and used for indicating the downtime of the target host, and confirming the downtime of the target host.

3. The method of claim 1, wherein the information of the virtual machine hosted on the target host includes resource information used by the virtual machine; and

And performing downtime recovery on the target host and the virtual machine hosted on the target host based on the related information, including:

Determining whether a non-host dependent virtual machine exists according to the resource information used by the virtual machine, wherein the non-host dependent virtual machine indicates that data required by the running of the virtual machine is not located on the local site of the target host;

in response to determining that a non-host dependent virtual machine exists, the non-host dependent virtual machine is migrated.

4. The method of claim 3, wherein the information of the target host includes resource information of the target host; and

The migrating the non-host dependent virtual machine includes:

Selecting a new host, wherein the resource information of the new host is the same as the resource information of the target host;

And migrating the non-host dependent virtual machine to a new host.

5. The method of claim 1, wherein the automatically diagnosing downtime of the target host comprises:

Acquiring fault information of the target host and executing output information of a diagnosis command when the target host is in downtime confirmation;

And determining a downtime cause and a suggested recovery step for the downtime cause according to the information of the target host, the fault information, the execution output information and a preset operation and maintenance knowledge base.

6. The method of claim 5, wherein the method further comprises:

in response to receiving confirmation information for the downtime cause and the suggested recovery step, adding the downtime cause and the suggested recovery step to the operation and maintenance knowledge base;

And in response to receiving the modification information for the downtime cause and the suggested recovery step, adding the modified downtime cause and the modified suggested recovery step to the operation and maintenance knowledge base.

7. The method of claim 1, wherein the method further comprises:

And in response to determining that the target host is down, shielding fault alarm information for the target host.

8. The method of claim 7, wherein the method further comprises:

And responding to the completion of downtime recovery of the target host and the virtual machine hosted on the target host, and unblocking fault alarm information of the target host.

9. The method of claim 1, wherein the preset terminal is configured with a downtime manual processing interface; and

The method further comprises the steps of:

And in response to detecting that the target host is not recovered within a preset time period, sending a manual processing notification message to a preset terminal so as to perform manual intervention processing through the downtime manual processing interface.

10. A downtime treatment apparatus, comprising:

the downtime confirmation unit is configured to confirm the downtime of the target host machine in response to receiving downtime alarm information for the target host machine;

An information acquisition unit configured to acquire, in response to determining that the target host is down, related information of the target host, the related information including information of the target host and information of a virtual machine hosted on the target host, the information of the virtual machine hosted on the target host including resource information used by the virtual machine;

The downtime recovery unit is configured to perform downtime recovery on the target host machine and the virtual machine hosted on the target host machine based on the related information;

An automatic diagnosis unit configured to automatically diagnose downtime of the target host in response to completion of downtime recovery of the target host and the virtual machine;

Wherein the downtime recovery unit is further configured to:

11. The apparatus of claim 10, wherein the downtime confirmation unit is further configured to:

12. The apparatus of claim 10, wherein the information of the virtual machine hosted on the target host includes resource information used by the virtual machine; and

The downtime recovery unit is further configured to:

13. The apparatus of claim 12, wherein the information of the target host comprises resource information of the target host; and

The downtime recovery unit is further configured to:

And migrating the non-host dependent virtual machine to a new host.

14. The apparatus of claim 10, wherein the automatic diagnostic unit is further configured to:

15. The apparatus of claim 14, wherein the apparatus further comprises a knowledge base updating unit configured to:

16. The apparatus of claim 10, wherein the apparatus further comprises:

And an information shielding unit configured to shield fault alarm information for the target host in response to determining that the target host is down.

17. The apparatus of claim 16, wherein the apparatus further comprises:

And a shielding release unit configured to release the shielding of the fault alarm information for the target host in response to completion of downtime recovery of the target host and the virtual machine hosted on the target host.

18. The apparatus of claim 10, wherein the pre-set terminal is configured with a downtime manual processing interface; and

The apparatus further comprises:

And the manual intervention unit is configured to send a manual processing notification message to a preset terminal to perform manual intervention processing through the downtime manual processing interface in response to detecting that the target host is not recovered within a preset time period.

19. An electronic device, comprising:

One or more processors;

a storage device having one or more programs stored thereon,

When executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-9.

20. A computer readable medium having stored thereon a computer program, wherein the program when executed by a processor implements the method of any of claims 1-9.