Monitoring switching method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of computers, and discloses a monitoring switching method and device, computer equipment and a storage medium, and the method comprises the steps: under the condition that a management daemon is connected with a monitor node, if a management daemon message sent by the management daemon node is received, the monitor node sends the management daemon message to the computer equipment; the management daemon node sending the management daemon message is determined to be a fault node, and the management daemon is included in the management daemon node; sending a service exit message to the fault node, and indicating the fault node to close a management daemon of the fault node; if the management daemon of the fault node is the main program, a target node is determined, control information is sent to the target node, the target node is indicated to start a new main program, and the management daemon of the target node is the new main program. The problem that the stability and the reliability of a storage system are affected due to the fact that upper-layer software and cluster statistical service are temporarily unavailable due to the fact that master-slave MGR switching is slow is solved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a monitoring switching method, device, computer equipment and storage medium. Background Art

[0002] In a distributed storage system, Monitor is a monitor daemon. In order to reduce the pressure on Monitor, the Manager (MGR) service is introduced to manage and monitor the entire cluster and assume the monitoring and statistics functions that originally belonged to Monitor. At the same time, the MGR service also defines a set of command extension interface specifications. The MGR service can connect to more upper-layer services, such as management software, browser plug-ins, etc., through plug-ins that comply with this specification to expand management functions and achieve flexible cluster display, management, and analysis. In addition, the MGR service supports MGR cluster deployment, that is, MGR services can be deployed on multiple nodes in a distributed cluster to form an MGR node cluster. Among the MGR services of all nodes, there is only one main MGR, and the rest are backup MGRs. Only the main MGR will carry complete MGR services. The backup MGR is mainly elected to provide MGR services when the main MGR fails, and is usually only on standby.

[0003] If the main MGR service fails, the upper-layer service will be unable to monitor and manage the cluster, and the master-slave MGR needs to be switched in time. Currently, the MGR service of the entire cluster is maintained by Monitor, which is responsible for the election of the master and standby MGRs and the maintenance and release of mgrmap (management daemon layout information). During the current MGR switching process, Monitor determines whether it has received the beacon message sent by MGR within a certain period of time. If not, it is considered that the MGR has failed and will be marked as offline. If the offline MGR happens to be the main MGR, Monitor will re-select a standby MGR as the new main MGR, and update mgrmap and push it to each surviving node containing MGR to achieve the master-slave MGR switching. However, there is a problem in the current MGR switching process. When the main MGR is determined to be faulty, it takes some time for Monitor to select and switch to a new main MGR. During this period, the management, display and other services provided by the MGR service are all unavailable, which will cause the cluster-dependent management software, upper-layer plug-ins and cluster-related statistical services to fail or become directly unavailable, affecting the stability and reliability of the storage system.

[0004] Therefore, the related technology has the problem that the master-slave MGR switching is slow, causing the upper-layer software and cluster statistics service to be temporarily unavailable, affecting the stability and reliability of the storage system. Summary of the invention

[0005] In view of this, the present invention provides a monitoring switching method, device, computer equipment and storage medium to solve the problem that the master-slave MGR switching is slow, causing the upper-layer software and cluster statistics service to be temporarily unavailable, affecting the stability and reliability of the storage system.

[0006] In a first aspect, the present invention provides a monitoring switching method, which is applied to a monitor node, comprising:

[0007] In the case where the management daemon is connected to the monitor node, if a management daemon message sent by the management daemon node is received, determining that the management daemon node that sent the management daemon message is a faulty node, wherein the management daemon is included in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node is located at a different node from the monitor node;

[0008] Send a service exit message to the faulty node, instructing the faulty node to shut down the management daemon of the faulty node;

[0009] If the management daemon program of the failed node is the main program, determine the target node, send control information to the target node, and instruct the target node to enable a new main program, wherein the management daemon program of the target node is the new main program.

[0010] The monitoring switching method provided in this embodiment generates a management daemon message and actively sends it to the monitor node when a management daemon fails, thereby shortening the time for the monitor node to determine the failed node. The monitor node first sends a service exit message to the failed node, then determines the target node, instructs the target node to enable a new main program, and completes the switch between the master and standby management daemons. The fast switching speed avoids the unavailability of cluster management, display, and upper-layer plug-in services for a certain period of time due to a management daemon failure, improves the reliability and stability of the MGR service of the storage system when different types of nodes fail, and enhances the storage system's ability to resist risks. It solves the problem of slow master-slave MGR switching, which causes the upper-layer software and cluster statistics services to be temporarily unavailable, affecting the stability and reliability of the storage system.

[0011] In some optional implementations, sending control information to the target node to instruct the target node to enable a new main program includes:

[0012] Marking the management daemon of the failed node as failed in the management daemon layout information and determining a target node in the management daemon layout information to obtain first target layout information, wherein the management daemon of the target node is a new main program;

[0013] The first target layout information is used as control information, and the control information is sent to the management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to save the first target layout information, and instructing the target node to enable a new main program, wherein the management daemon node whose management daemon is not faulty includes the target node.

[0014] In this embodiment, the monitor node marks the management daemon of the failed node in the management daemon layout information and determines the target node to obtain the first target layout information, so that the management daemon node whose management daemon is not failed can determine whether it is the target node through the first target layout information and quickly switch the active and standby management daemons.

[0015] In some optional implementations, after determining that the management daemon node that sends the management daemon message is a faulty node, the method further includes:

[0016] If the management daemon of the faulty node is not the main program, marking the management daemon of the faulty node as faulty in the management daemon layout information, and obtaining second target layout information;

[0017] The second target layout information is sent to a management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to save the second target layout information.

[0018] In some optional embodiments, the method further comprises:

[0019] Determine a preset service interface, and encapsulate the preset service interface into a monitor node, wherein the monitor node is used to sense data transmitted by a preset service through the preset service interface, and the preset service is used to obtain status information of the node and determine whether a node fails according to the status information;

[0020] In case of sensing a candidate node list delivered by a preset service from a preset service interface, determining a candidate node according to the candidate node list, wherein the candidate node is a node where a fault occurs;

[0021] In the case where a management daemon service exists on the candidate node, a service exit message is sent to the candidate node to instruct the candidate node to shut down the management daemon of the candidate node;

[0022] Determine whether the management daemon of the candidate node is the main program;

[0023] If yes, marking the management daemon of the candidate node as faulty in the management daemon layout information and determining the management daemon to be started, to obtain third target layout information;

[0024] Sending the third target layout information to the management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to enable the management daemon to be started;

[0025] If not, marking the management daemon of the candidate node as faulty in the management daemon layout information to obtain fourth target layout information;

[0026] The fourth target layout information is sent to the management daemon node whose management daemon is not faulty, and the management daemon node whose management daemon is not faulty is instructed to save the fourth target layout information.

[0027] In this embodiment, node failures are quickly sensed through preset services, and the candidate nodes with failures are sent to the monitor node. The monitor node determines whether the main program needs to be switched by judging whether the management daemon of the candidate node is the main program for the candidate nodes with management daemon services. In the case of abnormal node failure, the monitor node can also complete the switch between the main and standby MGR services, which improves the reliability and stability of the MGR service of the storage system when different types of node failures occur, and enhances the ability of the storage system to resist risks.

[0028] In a second aspect, the present invention provides a monitoring switching method, which is applied to manage a daemon node, comprising:

[0029] Determine a monitor node corresponding to the management daemon, and connect the management daemon to the monitor node, wherein the management daemon is included in the management daemon node, and the management daemon node and the monitor node are located at different nodes;

[0030] If a management daemon fails, a management daemon message is generated and sent to a monitor node, wherein the monitor node is used to determine that the management daemon node is a failed node according to the management daemon message;

[0031] In case of receiving a service exit message, shutting down the management daemon, wherein the service exit message is generated by the monitor node in case of receiving a management daemon message and determining that the management daemon is a master program.

[0032] The monitoring switching method provided in this embodiment generates a management daemon message when a management daemon fails and actively sends it to the monitor node, so that the monitor node determines the failed node and promptly determines the target node, thereby shortening the time it takes for the monitor node to determine the failed node. The monitor node instructs the failed node to exit the management daemon and instructs the target node to start a new main program, thereby completing the switch between the master and standby management daemons. This solves the problem that the master-slave MGR switch is slow, causing the upper-layer software and cluster statistics service to be temporarily unavailable, thus affecting the stability and reliability of the storage system.

[0033] In some optional embodiments, the method further comprises:

[0034] In the case where the management daemon program has not failed and the first target layout information is received, judging whether the management daemon program node is a target node according to the first target layout information, wherein the management daemon program of the target node is a new main program, and the first target layout information is obtained after the monitor node marks the management daemon program of the failed node as failed in the management daemon program layout information and determines the target node in the management daemon program layout information when the management daemon program of the failed node is the main program;

[0035] If the management daemon node is the target node, a new master program of the target node is started.

[0036] In some optional implementations, determining a monitor node corresponding to a management daemon includes:

[0037] Get the target address information and monitor node layout information corresponding to the management daemon;

[0038] According to the target address information and the monitor node layout information, the monitor node whose address information is different from the target address information is determined, and the monitor node whose address information is different from the target address information is used as the monitor node corresponding to the management daemon.

[0039] In this embodiment, the Monitor that is not in the same node as the MGR service is determined based on the target address information and the monitor node layout information, so as to avoid the situation where the Monitor in the same node cannot complete the processing of the MGR fault message after a failure occurs in the node where the MGR service is located, thereby improving the reliability and stability of the active-standby MGR switching.

[0040] In a third aspect, the present invention provides a monitoring switching device, which is deployed on a monitor node and includes:

[0041] A first determining unit is configured to determine that the management daemon node that sends the management daemon message is a faulty node if a management daemon message sent by the management daemon node is received when the management daemon is connected to the monitor node, wherein the management daemon is included in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node is located at a different node from the monitor node;

[0042] A first sending unit is used to send a service exit message to the faulty node, instructing the faulty node to shut down the management daemon of the faulty node;

[0043] The second sending unit is used to determine the target node if the management daemon of the failed node is the main program, send control information to the target node, and instruct the target node to enable a new main program, wherein the management daemon of the target node is the new main program.

[0044] In a fourth aspect, the present invention provides a monitoring switching device, which is deployed on a management daemon node and includes:

[0045] A second determining unit is used to determine a monitor node corresponding to the management daemon and connect the management daemon to the monitor node, wherein the management daemon is included in the management daemon node, and the management daemon node and the monitor node are located at different nodes;

[0046] A third sending unit is used to generate a management daemon message if a management daemon fails, and send the management daemon message to the monitor node, wherein the monitor node is used to determine that the management daemon node is a failed node according to the management daemon message;

[0047] The closing unit is used to close the management daemon program when receiving a service exit message, wherein the service exit message is generated by the monitor node when receiving a management daemon program message and determining that the management daemon program is a main program.

[0048] In a fifth aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor are communicatively connected to each other, computer instructions are stored in the memory, and the processor executes the monitoring switching method of the above-mentioned first aspect or any corresponding embodiment thereof by executing the computer instructions, or executes the monitoring switching method of the above-mentioned second aspect or any corresponding embodiment thereof.

[0049] In a sixth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the monitoring switching method of the above-mentioned first aspect or any corresponding embodiment thereof, or to execute the monitoring switching method of the above-mentioned second aspect or any corresponding embodiment thereof.

[0050] In the seventh aspect, the present invention provides a computer program product, including computer instructions, which are used to enable a computer to execute the monitoring switching method of the above-mentioned first aspect or any corresponding embodiment, or to execute the monitoring switching method of the above-mentioned second aspect or any corresponding embodiment. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the related technologies, the drawings required for use in the specific embodiments or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0052] Figure 1 is a flow chart of a monitoring switching method applied to a monitor node according to an embodiment of the present invention;

[0053] Figure 2 is a flowchart of switching the active and standby MGRs in a scenario where an active failure occurs in a node according to an embodiment of the present invention;

[0054] Figure 3 is a flow chart of switching the standby MGR service to the main MGR service according to an embodiment of the present invention;

[0055] Figure 4 is a flowchart of switching the active and standby MGRs in a node abnormal failure scenario according to an embodiment of the present invention;

[0056] Figure 5 is a flow chart of a monitoring switching method applied to a management daemon node according to an embodiment of the present invention;

[0057] Figure 6 is a structural block diagram of a monitoring switching device deployed on a monitor node according to an embodiment of the present invention;

[0058] Figure 7 is a structural block diagram of a monitoring switching device deployed on a management daemon node according to an embodiment of the present invention;

[0059] Figure 8 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0061] The MGR service is responsible for tracking runtime indicators and the current state of the cluster. It is the middle layer for the interaction between Monitor and upper-level services. It is responsible for the management and monitoring of the entire cluster and assumes the monitoring and statistical functions that originally belonged to Monitor, such as: some basic query command responses, OSD (ObjectStorageDevice, data storage device) reported message processing, etc., so that Monitor can focus more on cluster status data maintenance and reduce the pressure of the cluster on Monitor. Monitor is the cluster monitor daemon. As can be seen from the above, the MGR service in the distributed storage cluster is already an indispensable module of the cluster. If the MGR service fails, the upper-level service will be unable to monitor and manage the cluster, such as the collection and display of cluster performance statistics, the query and display of PG (Placement Group) status, and the cluster extension plug-in.

[0062] MGR cluster deployment supports the operation mode of one master and multiple backups. Only the master MGR will carry the complete MGR service. The backup MGR is mainly elected to provide MGR services when the master MGR fails. It is usually only on standby and only interacts with the Monitor through scheduled beacon messages and subscribes to mgrmap (MGR layout information). In Monitor, in order to maintain the MGR service of the entire cluster, an MGRMonitor is separated to maintain the MGR cluster of the cluster, which is responsible for the election of the master and backup MGRs and the maintenance and release of mgrmap. In the current MGR failover process, Monitor mainly relies on the beacon messages that the MGR service sends to Monitor regularly. Each time it receives a beacon message, Monitor will mark the current survival time of the MGR service. When a certain MGR service fails (such as node shutdown, network interruption, node downtime, etc.), the beacon messages between the MGR service and Monitor will be interrupted. When Monitor determines that the beacon message of the MGR is lost for more than a certain period of time (the default is 30s), it is considered to have failed and will be marked as offline. If the offline one happens to be the main MGR, it will re-select an MGR as the main MGR, and update the mgrmap and push it to each surviving MGR node. In the MGR service, if it is the main MGR in the new mgrmap received, it will initialize the MGR service and the corresponding plug-in service, and begin to receive and process messages sent by OSD or upper-level services to maintain the display, management, and analysis capabilities of the cluster.

[0063] From the above analysis, it can be seen that there is a problem with the current MGR service failover. When the MGR service fails due to network failure, node downtime, etc., the Monitor cannot quickly perceive the MGR service failure and can only rely on the beacon message (heartbeat message) timeout to perceive the MGR failure. It will take some time for the Monitor to select a new main MGR. During this period, the management, display and other services provided by the MGR are unavailable, which will cause the management software, upper-level plug-ins, and cluster-related statistical services that rely on the cluster to fail or become directly unavailable, affecting the management, display and other functions provided by the cluster to the outside world, causing the management software, upper-level plug-ins, and cluster-related statistical services that rely on the cluster to fail or become directly unavailable, affecting the stability and reliability of the storage system.

[0064] Based on the above content, the embodiment of the present invention provides a monitoring switching method, introduces a fast switching mechanism, improves the MGR service and Monitor service linking mechanism for active failure of the MGR service, and the MGR service preferentially connects to the non-node Monitor. A new mechanism is added to actively notify the Monitor when a failure occurs, so that the Monitor can quickly perceive the MGR failure, re-determine the main MGR, and quickly switch the main and standby MGRs; for abnormal failures of the MGR service, through the rapid perception of the high-availability module of the storage system, the Monitor service can quickly perceive the failure changes of the MGR service, re-select the main MGR, quickly switch the main and standby MGRs, and quickly provide MGR services to the outside. The problem of cluster management, display, and upper-layer plug-in services being unavailable for a certain period of time after the main MGR fails in two major failure scenarios of the storage system node (active failure and abnormal failure) is solved, which greatly shortens the service unavailability time and improves the reliability and stability of the distributed storage system. This can achieve the effect of improving the reliability and stability of the MGR service of the storage system when different types of node failures occur, and enhancing the ability of the storage system to resist risks.

[0065] According to an embodiment of the present invention, a management daemon switching embodiment is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a monitor node, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0066] In this embodiment, a monitoring switching method is provided, which can be used for a monitor node. Figure 1 is a flow chart of a monitoring switching method according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0067] Step S101, when the management daemon is connected to the monitor node, if a management daemon message sent by the management daemon node is received, it is determined that the management daemon node that sends the management daemon message is a faulty node, wherein the management daemon is included in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node is different from the node where the monitor node is located.

[0068] Specifically, in a distributed storage system, in order to reduce the pressure of the cluster on the Monitor, the MGR service is introduced. The MGR service tracks the runtime indicators and the current status of the cluster, and assumes the monitoring and statistical functions that originally belonged to the Monitor, such as: some basic query command responses, OSD (ObjectStorageDevice, data storage device) reported message processing, etc. Therefore, the monitoring switching method of the present application is to switch or process the MGR service, for example: when the node where the MGR service is located fails, switch the MGR service in working state.

[0069] This embodiment introduces two mechanisms for active fault scenarios, such as active node shutdown and active MGR (management daemon) service stop. When the MGR service starts, it will give priority to connecting to non-local node Monitor (monitor node); the MGR service will actively capture faults and notify the Monitor when a fault occurs, so that the Monitor can quickly perceive the failure of the MGR service.

[0070] When the MGR service starts to select a monitor and establish a link, a screening mechanism is added to enable the MGR service to give priority to selecting and establishing a link with a non-local node monitor. The priority connection to non-local node monitors is to ensure that the fault message sent by the MGR can be sent to the monitor quickly and accurately after a fault occurs. If the MGR is connected to the local node monitor service, when the node is shut down, the MGR will send the message to the local node monitor, but the monitor is also processing the fault, and the MGR fault message cannot be processed.

[0071] A new MGR service fault capture module is added to the MGR service, and selection is made based on the signal of the fault occurrence. In this embodiment, the MGR service fault capture module mainly captures the signal of active faults. At the same time, a new management daemon message is added, such as the MMGRDown message, which is used by MGR to send fault information to Monitor. When the management daemon (MGR) and the monitor (Monitor) module are connected, when an active fault occurs in the MGR service or the management daemon node where the MGR service is located, the MGR service captures the fault, encapsulates the fault type into a new management daemon message, such as the MMGRDown message, and sends it to the Monitor service, actively notifying the Monitor of the fault information. Wait for the Monitor service to respond to the message before continuing the service exit process.

[0072] When the management daemon is connected to the monitor node, if the Monitor receives a management daemon message sent by the management daemon node, it determines that the management daemon node that sent the management daemon message is a faulty node, that is, the management daemon node has an active fault. In addition, after receiving the management daemon message, the Monitor can add the corresponding management daemon node information to the off_mgr_node list and add the management daemon message to the wait_for_finish_propose queue, which will send a service exit message to the corresponding management daemon node that sent the management daemon message after the Monitor proposal is completed.

[0073] The above process is as follows Figure 2 As shown, when the MGR service is started, it will first establish a link with the Monitor service of a non-local node; if a fault occurs, the MGR service will capture the fault; send a fault message MMGRDown; and wait for the Monitor response.

[0074] Step S102: Send a service exit message to the faulty node, instructing the faulty node to shut down the management daemon of the faulty node.

[0075] Specifically, after Monitor receives the management daemon message sent by MGR, it immediately completes a mgrmap (management daemon layout information) change. Specifically: first mark the MGR service of the faulty node as faulty. If the faulty node is the main MGR node, immediately elect a new main MGR. After the processing is completed, trigger the proposal to update mgrmap. After completing the proposal to update mgrmap, Monitor processes the wait_for_finish_propose queue. If there is an MMGRDown message to be replied to in the queue, it replies with a service exit message to the faulty node, for example: MMGRDown message, instructing the faulty node to shut down the management daemon of the faulty node. If the faulty node receives a service exit message, the faulty node then exits the remaining MGR processes until the MGR service of the faulty node is shut down. The above process is as follows: Figure 2 As shown, reply the message; release the resources and exit the process.

[0076] Step S103, if the management daemon of the failed node is the main program, determine the target node, send control information to the target node, and instruct the target node to enable a new main program, wherein the management daemon of the target node is the new main program.

[0077] Specifically, because the MGR cluster operates in a one-master-multiple-standby mode, only the master MGR will carry complete MGR services. The standby MGR is mainly elected to provide MGR services when the master MGR fails, and is usually only on standby. If the management daemon of the failed node is the master program, that is, the MGR service of the failed node is the master MGR, in order not to affect the normal provision of management, display and other services by the MGR cluster, a new master MGR needs to be re-determined. Determine that the management daemon is the target node of the new master program, send control information to the target node, and instruct the target node to enable the new master program.

[0078] After the standby MGR node receives the control information, if it parses the control information and finds that it is the target node, the node will immediately reinitialize and initialize all MGR plug-ins, provide the main MGR service to the outside world, and maintain the management and display functions of the partial status of the cluster. The above-mentioned main and standby MGR switching process can shorten the unavailability time of MGR services from minutes to within 10 seconds.

[0079] The monitoring switching method provided in this embodiment generates a management daemon message and actively sends it to the monitor node when a management daemon fails, thereby shortening the time for the monitor node to determine the failed node. The monitor node first sends a service exit message to the failed node, then determines the target node, instructs the target node to enable a new main program, and completes the switch between the master and standby management daemons. The fast switching speed avoids the unavailability of cluster management, display, and upper-layer plug-in services for a certain period of time due to a management daemon failure, improves the reliability and stability of the MGR service of the storage system when different types of nodes fail, and enhances the storage system's ability to resist risks. It solves the problem of slow master-slave MGR switching, which causes the upper-layer software and cluster statistics services to be temporarily unavailable, affecting the stability and reliability of the storage system.

[0080] In some optional implementations, sending control information to the target node to instruct the target node to enable a new main program includes:

[0081] Marking the management daemon of the failed node as failed in the management daemon layout information and determining a target node in the management daemon layout information to obtain first target layout information, wherein the management daemon of the target node is a new main program;

[0082] The first target layout information is used as control information, and the control information is sent to the management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to save the first target layout information, and instructing the target node to enable a new main program, wherein the management daemon node whose management daemon is not faulty includes the target node.

[0083] Specifically, the management daemon layout information is, for example, mgrmap. After the Monitor receives the management daemon message sent by the MGR, it immediately updates the management daemon layout information, first marking the MGR service of the faulty node as faulty in the management daemon layout information. If the MGR service of the faulty node is the main MGR, a new main MGR is immediately elected. For example, after the Monitor receives the management daemon message, it adds the corresponding management daemon node information to off_mgr_node, and in the process of updating mgrmap, the Monitor makes a judgment on the faulty node. If there is a main MGR node among them, the main MGR switch mark switch_mgr is marked as true, and all off_mgr_node nodes are removed from the current mgrmap to obtain pending_mgrmap. Pending_mgrmap is the management daemon node with normal MGR service. A new main MGR is elected as the target node in pending_mgrmap. The Monitor determines the target node containing the new main MGR in the management daemon layout information, and after processing, triggers the proposal to update the management daemon layout information to obtain the first target layout information.

[0084] Monitor uses the first target layout information as control information, and sends the control information to the management daemon node whose management daemon is not faulty, instructs the management daemon node whose management daemon is not faulty to save the first target layout information, and instructs the target node to enable a new main program. The management daemon whose management daemon is not faulty is a surviving MGR node. After receiving the first target layout information, the surviving MGR node reads the first target layout information to determine whether it is a target node. If it was a backup MGR node before but is currently a target node, it enables a new main program, for example: enters the initialization process to initialize MGR and all plug-in services, and provide MGR functions to the outside world. If it is not a target node, it saves the first target layout information and continues to be a backup MGR node without making any changes.

[0085] The above process is as follows Figure 2 As shown, Monitor handles the failure; whether it is the main MGR node; if so, re-elect a main MGR, actively update mgrmap and push it to the surviving MGR node, if not, actively update mgrmap and push it to the surviving MGR node, and reply to the message.

[0086] In this embodiment, the monitor node marks the management daemon of the failed node in the management daemon layout information and determines the target node to obtain the first target layout information, so that the management daemon node whose management daemon is not failed can determine whether it is the target node through the first target layout information and quickly switch the active and standby management daemons.

[0087] In some optional implementations, after determining that the management daemon node that sends the management daemon message is a faulty node, the method further includes:

[0088] If the management daemon of the faulty node is not the main program, marking the management daemon of the faulty node as faulty in the management daemon layout information, and obtaining second target layout information;

[0089] The second target layout information is sent to a management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to save the second target layout information.

[0090] Specifically, the management daemon layout information is such as mgrmap. After the Monitor receives the management daemon message sent by the MGR, it immediately updates the management daemon layout information. If the MGR service of the faulty node is not the main MGR, the MGR service of the faulty node is marked as faulty in the management daemon layout information. After processing, the proposal to update the management daemon layout information is triggered to obtain the second target layout information.

[0091] After the Monitor proposal is completed, the second target layout information is sent to the management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to save the second target layout information. After receiving the second target layout information, the management daemon node whose management daemon is not faulty saves the second target layout information and continues to serve as the backup MGR node without making any changes. The above process is as follows Figure 3 As shown, the standby MGR receives the new mgrmap; determines whether to become the main MGR; if not, continues to operate as the standby MGR.

[0092] In some optional embodiments, the method further comprises:

[0093] Determine a preset service interface, and encapsulate the preset service interface into a monitor node, wherein the monitor node is used to sense data transmitted by a preset service through the preset service interface, and the preset service is used to obtain status information of the node and determine whether a node fails according to the status information;

[0094] In case of sensing a candidate node list delivered by a preset service from a preset service interface, determining a candidate node according to the candidate node list, wherein the candidate node is a node where a fault occurs;

[0095] In the case where a management daemon service exists on the candidate node, a service exit message is sent to the candidate node to instruct the candidate node to shut down the management daemon of the candidate node;

[0096] Determine whether the management daemon of the candidate node is the main program;

[0097] If yes, marking the management daemon of the candidate node as faulty in the management daemon layout information and determining the management daemon to be started, to obtain third target layout information;

[0098] Sending the third target layout information to the management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to enable the management daemon to be started;

[0099] If not, marking the management daemon of the candidate node as faulty in the management daemon layout information to obtain fourth target layout information;

[0100] The fourth target layout information is sent to the management daemon node whose management daemon is not faulty, and the management daemon node whose management daemon is not faulty is instructed to save the fourth target layout information.

[0101] Specifically, for abnormal failure scenarios, such as network interruption, node downtime / crash, etc., this embodiment cannot capture abnormal failure scenarios by relying on the MGR service in the node, but can rely on the high-availability service of the distributed cluster to detect abnormal failure scenarios. Therefore, this embodiment introduces a fault handling mechanism based on cluster high-availability services to complete the rapid switching of MGR service failures in abnormal failure scenarios.

[0102] The preset service is a high-availability service of the distributed cluster, such as CTDB service, keepalive service, etc. The main function of the preset service is to quickly sense (with a perception capability of seconds, generally within about 2 seconds) abnormal fault scenarios such as node-level network interruption and node downtime. The preset service interface is an interface for high-availability services to call. The preset service interface is encapsulated in Monitor for high-availability services to call.

[0103] The preset service obtains the status information of the node and determines whether the node fails (such as network anomaly, node downtime) based on the status information. After the preset service detects a node failure, it calls the preset service interface and passes the candidate node list (off_node_list) to the Monitor through the preset service interface. The candidate node list records the failed nodes, namely the candidate nodes.

[0104] When the Monitor senses the candidate node list delivered by the preset service from the preset service interface, it reads the candidate node list (off_node_list), determines the candidate node, identifies the candidate node in the off_node_list, determines whether the candidate node has an MGR (management daemon) service, and discards the node without MGR service to obtain a faulty MGR node list (off_mgr_node). If the candidate node has a management daemon service, a service exit message is sent to the candidate node, instructing the candidate node to shut down the management daemon of the candidate node.

[0105] Determine whether the management daemon of the candidate node is the main program. If so, immediately update the management daemon layout information. First, mark the MGR service of the faulty node as faulty in the management daemon layout information. If the MGR service of the faulty node is the main MGR, immediately elect a new main MGR. For example, after receiving the management daemon message, the Monitor adds the corresponding management daemon node information to off_mgr_node, and in the process of updating mgrmap, the Monitor makes a judgment on the faulty node. If there is a main MGR node, the main MGR switch mark switch_mgr is marked as true, and all off_mgr_node nodes are removed from the current mgrmap to obtain pending_mgrmap. Pending_mgrmap is the management daemon node with normal MGR service. A new main MGR is elected as the target node in pending_mgrmap. Determine the target node containing the new main MGR in the management daemon layout information. After processing, trigger the proposal to update the management daemon layout information to obtain the third target layout information.

[0106] The third target layout information is sent to the management daemon node whose management daemon is not faulty. After receiving the first target layout information, the management daemon node whose management daemon is not faulty reads the first target layout information to determine whether it is the target node. If it was previously a standby MGR node but is currently a target node, a new main program is enabled, for example: entering the initialization process to initialize MGR and all plug-in services, and providing MGR functions to the outside world. If it is not the target node, the first target layout information is saved and it continues to be a standby MGR node without any modification.

[0107] If the management daemon of the candidate node is not the main program, the MGR service of the faulty node is marked as faulty in the management daemon layout information. After processing, the proposal is triggered to update the management daemon layout information to obtain the second target layout information. The fourth target layout information is sent to the management daemon node whose management daemon is not faulty. After receiving the second target layout information, the management daemon node whose management daemon is not faulty saves the second target layout information and continues to serve as a backup MGR node without making any changes.

[0108] The above process is as follows Figure 4 As shown, the cluster is running normally; the high-availability service detects the fault and calls the interface; the Monitor receives the list of faulty nodes; determines whether the faulty node is an MGR node, if not, discards the fault; if it is an MGR node, determines whether it contains the main MGR node, if not, actively updates mgrmap and pushes it to the surviving MGR node; if a main MGR is to be re-elected, actively updates mgrmap and pushes it to the surviving MGR node.

[0109] In this embodiment, node failures are quickly sensed through preset services, and the candidate nodes with failures are sent to the monitor node. The monitor node determines whether the main program needs to be switched by judging whether the management daemon of the candidate node is the main program for the candidate nodes with management daemon services. In the case of abnormal node failure, the monitor node can also complete the switch between the main and standby MGR services, which improves the reliability and stability of the MGR service of the storage system when different types of node failures occur, and enhances the ability of the storage system to resist risks.

[0110] According to an embodiment of the present invention, an embodiment of a monitoring switching method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a management daemon node, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0111] In this embodiment, a monitoring switching method is provided, which can be used to manage daemon nodes. Figure 5 is a flow chart of a monitoring switching method according to an embodiment of the present invention. Figure 5 As shown, the process includes the following steps:

[0112] Step S501, determining a monitor node corresponding to a management daemon, and connecting the management daemon to the monitor node, wherein the management daemon is included in the management daemon node, and the management daemon node and the monitor node are located at different nodes.

[0113] Specifically, in a distributed storage system, in order to reduce the pressure of the cluster on the Monitor, the MGR service is introduced. The MGR service tracks the runtime indicators and the current status of the cluster, and assumes the monitoring and statistical functions that originally belonged to the Monitor, such as: some basic query command responses, OSD (ObjectStorageDevice, data storage device) reported message processing, etc. Therefore, the monitoring switching method of the present application is to switch or process the MGR service, for example: when the node where the MGR service is located fails, switch the MGR service in working state.

[0114] This embodiment introduces two mechanisms for active fault scenarios, such as active node shutdown and active MGR (management daemon) service stop. When the MGR service starts, it will give priority to connecting to non-local node Monitor (monitor node); the MGR service will actively capture faults and notify the Monitor when a fault occurs, so that the Monitor can quickly perceive the failure of the MGR service.

[0115] When the MGR service starts to select a monitor and establish a link, a screening mechanism is added to enable the MGR service to give priority to selecting and establishing a link with a non-local node monitor. The priority connection to non-local node monitors is to ensure that the fault message sent by the MGR can be sent to the monitor quickly and accurately after a fault occurs. If the MGR is connected to the local node monitor service, when the node is shut down, the MGR will send the message to the local node monitor, but the monitor is also processing the fault, and the MGR fault message cannot be processed.

[0116] Step S502: If a management daemon fails, a management daemon message is generated and sent to a monitor node, wherein the monitor node is used to determine that the management daemon node is a failed node according to the management daemon message.

[0117] Specifically, a new MGR service fault capture module is added to the MGR service, and selection is made according to the signal of the fault. In this embodiment, the MGR service fault capture module mainly captures the signal of active fault. At the same time, a new management daemon message is added, such as the MMGRDown message, which is used by the MGR to send fault information to the Monitor.

[0118] When the management daemon (MGR) is connected to the monitor (Monitor) module, when the MGR service fault capture module detects that the MGR service or the management daemon node where the MGR service is located has an active fault, the MGR service captures the fault, encapsulates the fault type into a newly added management daemon message, such as: MMGRDown message, and sends it to the Monitor service, actively notifying the Monitor of the fault information. And wait for the Monitor service to respond to the message before continuing the service exit process.

[0119] Step S503: when a service exit message is received, the management daemon is closed, wherein the service exit message is generated by the monitor node when it receives a management daemon message and determines that the management daemon is the main program.

[0120] Specifically, after Monitor receives the management daemon message sent by MGR, it immediately completes a mgrmap (management daemon layout information) change. Specifically: first mark the MGR service of the faulty node as faulty. If the faulty node is the main MGR node, immediately elect a new main MGR. After the processing is completed, trigger the proposal to update mgrmap. After completing the proposal to update mgrmap, Monitor processes the wait_for_finish_propose queue. If there is an MMGRDown message to be replied in the queue, it replies with a message and replies to the faulty node with a service exit message, such as an MMGRDown message, instructing the faulty node to shut down the management daemon of the faulty node.

[0121] If the management daemon is a faulty node and receives a service exit message, the faulty node then exits the remaining MGR processes until the MGR service of the faulty node is shut down. Figure 2 As shown, reply the message; release the resources and exit the process.

[0122] The monitoring switching method provided in this embodiment generates a management daemon message when a management daemon fails and actively sends it to the monitor node, so that the monitor node determines the failed node and promptly determines the target node, thereby shortening the time it takes for the monitor node to determine the failed node. The monitor node instructs the failed node to exit the management daemon and instructs the target node to start a new main program, thereby completing the switch between the master and standby management daemons. This solves the problem that the master-slave MGR switch is slow, causing the upper-layer software and cluster statistics service to be temporarily unavailable, thus affecting the stability and reliability of the storage system.

[0123] In some optional embodiments, the method further comprises:

[0124] In the case where the management daemon program has not failed and the first target layout information is received, judging whether the management daemon program node is a target node according to the first target layout information, wherein the management daemon program of the target node is a new main program, and the first target layout information is obtained after the monitor node marks the management daemon program of the failed node as failed in the management daemon program layout information and determines the target node in the management daemon program layout information when the management daemon program of the failed node is the main program;

[0125] If the management daemon node is the target node, a new master program of the target node is started.

[0126] Specifically, after Monitor receives the management daemon message sent by MGR, it immediately updates the management daemon layout information. First, the MGR service of the faulty node is marked as faulty in the management daemon layout information. Then, Monitor determines the target node containing the new main MGR in the management daemon layout information. After processing, it triggers the proposal to update the management daemon layout information to obtain the first target layout information.

[0127] Monitor uses the first target layout information as control information and sends the control information to the management daemon node whose management daemon is not faulty. The management daemon whose management daemon is not faulty is the surviving MGR node. After receiving the first target layout information, the surviving MGR node reads the first target layout information to determine whether it is the target node. If it was a backup MGR node before but is currently the target node, a new main program is enabled, for example: entering the initialization process to initialize MGR and all plug-in services, providing main MGR services to the outside world, and maintaining the management and display functions of part of the cluster status.

[0128] The above process is as follows Figure 3 As shown, the standby MGR receives the new mgrmap; determines whether to become the main MGR; if so, initializes the MGR and all plug-in services and provides services to the outside world.

[0129] In some optional implementations, determining a monitor node corresponding to a management daemon includes:

[0130] Get the target address information and monitor node layout information corresponding to the management daemon;

[0131] According to the target address information and the monitor node layout information, the monitor node whose address information is different from the target address information is determined, and the monitor node whose address information is different from the target address information is used as the monitor node corresponding to the management daemon.

[0132] Specifically, this embodiment introduces a mechanism for active fault scenarios: when the MGR service is started, it preferentially connects to the Monitor (monitor node) that is not the current node, to avoid the situation where, after a fault occurs at the node where the MGR service is located, if the Monitor is on the same node, the Monitor is also processing the fault and the MGR fault message cannot be processed.

[0133] Get the target address information corresponding to the management daemon, for example: the IP (Internet Protocol) information of the node where the MGR service is located. Get the monitor node layout information (monmap), which records the address information of the monitors contained in the distributed system and the nodes where the monitors are located, for example: the IP information of the node where the monitors are located.

[0134] According to the target address information and the monitor node layout information, determine the monitor node whose address information is different from the target address information, for example: determine a monitor whose IP information of the node where the monitor is located is different from the IP information of the node where the MGR service is located. The monitor node whose address information is different from the target address information is used as the monitor node corresponding to the management daemon, and establish its connection relationship with the MGR service.

[0135] In this embodiment, the Monitor that is not in the same node as the MGR service is determined based on the target address information and the monitor node layout information, so as to avoid the situation where the Monitor in the same node cannot complete the processing of the MGR fault message after a failure occurs in the node where the MGR service is located, thereby improving the reliability and stability of the active-standby MGR switching.

[0136] In some optional implementations, the process of Monitor switching the active and standby MGR services may also include steps A1 to A7.

[0137] Step A1, Monitor assigns a domain name to the MGR cluster. The effective node of the domain name is the master node, for example: node A. The MGR service in node A is the master MGR service.

[0138] Step A2: Monitor changes the connection address of the application to the domain name.

[0139] Step A3: After the Monitor determines the failed node according to the management daemon message, it determines the target node and changes the MEMBER_ROLE field in the replication_group_members table in the MySQL database of the target node to the PRIMARY field.

[0140] Specifically, the target node is, for example, Node B. If the MEMBER_ROLE field in the replication_group_members table is changed to the PRIMARY field, it means that the primary node has switched from Node A to Node B. And the primary and standby databases need to be switched, that is, the data in the database of Node A is synchronized to the database of Node B, and the database of Node B is enabled as the primary database.

[0141] Step A4, the target node detects whether the read_only parameter in the mysql database has been turned off; if it is turned off, it means that the master-slave database switch has been completed, and the new master database, that is, the database of node B, can be opened, and the MGR service of the target node can be started as the main MGR service; if it is not closed, wait until the read_only parameter is turned off, then open the new master database and start the MGR service of the target node as the main MGR service.

[0142] Specifically, when the master database is switched, the original master database becomes a slave database, and any one of the multiple slave databases is switched to a new master database. At this time, the domain name cannot necessarily correspond to the new master database, so step A5 is executed.

[0143] Step A5, Monitor modifies the current IP address so that the current IP address and the domain name correspond to each other.

[0144] In step A6, the Monitor instructs the application to automatically reconnect and relocate to the new IP address through the domain name to complete the switch between the primary and standby MGR services.

[0145] In this embodiment, when a management daemon fails, a management daemon message is generated and actively sent to the monitor node, shortening the time it takes for the monitor node to determine the failed node. The monitor changes the MEMBER_ROLE field to the PRIMARY field to instruct the target node to complete the master-slave database switch and use the MGR service of the target node as the master MGR service to complete the master-slave MGR service switch. This improves the reliability and stability of the MGR service of the storage system when different types of nodes fail, and enhances the storage system's ability to resist risks.

[0146] In this embodiment, a monitoring switching device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0147] This embodiment provides a monitoring switching device, which is deployed on a monitor node, such as Figure 6 As shown, including:

[0148] A first determining unit 601 is configured to determine that the management daemon node that sends the management daemon message is a faulty node if a management daemon message sent by the management daemon node is received when the management daemon is connected to the monitor node, wherein the management daemon is included in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node is located at a different node from the monitor node;

[0149] A first sending unit 602 is used to send a service exit message to the faulty node, instructing the faulty node to shut down the management daemon of the faulty node;

[0150] The second sending unit 603 is used to determine a target node if the management daemon of the failed node is the main program, and send control information to the target node to instruct the target node to enable a new main program, wherein the management daemon of the target node is the new main program.

[0151] In some optional implementations, the second sending unit 603 sends control information to the target node to instruct the target node to enable a new main program, including:

[0152] Marking the management daemon of the failed node as failed in the management daemon layout information and determining a target node in the management daemon layout information to obtain first target layout information, wherein the management daemon of the target node is a new main program;

[0153] The first target layout information is used as control information, and the control information is sent to the management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to save the first target layout information, and instructing the target node to enable a new main program, wherein the management daemon node whose management daemon is not faulty includes the target node.

[0154] In some optional implementations, after determining that the management daemon node that sends the management daemon message is a faulty node, the apparatus further includes:

[0155] an obtaining unit, configured to mark the management daemon of the faulty node as faulty in the management daemon layout information if the management daemon of the faulty node is not the main program, and obtain second target layout information;

[0156] The fourth sending unit is used to send the second target layout information to the management daemon node whose management daemon is not faulty, and instruct the management daemon node whose management daemon is not faulty to save the second target layout information.

[0157] In some optional embodiments, the device further comprises:

[0158] An encapsulation unit, used to determine a preset service interface and encapsulate the preset service interface into a monitor node, wherein the monitor node is used to sense data transmitted by a preset service through the preset service interface, and the preset service is used to obtain status information of the node and determine whether a node fails according to the status information;

[0159] A third determining unit is configured to determine a candidate node according to the candidate node list when a candidate node list for preset service delivery is sensed from the preset service interface, wherein the candidate node is a node where a fault occurs;

[0160] a fifth sending unit, configured to send a service exit message to the candidate node, instructing the candidate node to shut down the management daemon of the candidate node, if a management daemon service exists in the candidate node;

[0161] A first judging unit, used to judge whether the management daemon program of the candidate node is a main program;

[0162] a first marking unit, configured to, if yes, mark the management daemon of the candidate node as faulty in the management daemon layout information and determine the management daemon to be started, to obtain third target layout information;

[0163] A sixth sending unit, configured to send the third target layout information to a management daemon node whose management daemon is not faulty, and instruct the management daemon node whose management daemon is not faulty to enable the management daemon to be started;

[0164] a second marking unit, configured to, if not, mark the management daemon of the candidate node as faulty in the management daemon layout information, to obtain fourth target layout information;

[0165] The seventh sending unit is used to send the fourth target layout information to the management daemon node whose management daemon is not faulty, and instruct the management daemon node whose management daemon is not faulty to save the fourth target layout information.

[0166] This embodiment provides a monitoring switching device, which is deployed on a management daemon node, such as Figure 7 As shown, including:

[0167] The second determining unit 701 is used to determine the monitor node corresponding to the management daemon and connect the management daemon to the monitor node, wherein the management daemon is included in the management daemon node, and the management daemon node and the monitor node are located at different nodes;

[0168] The third sending unit 702 is used to generate a management daemon message if a management daemon fails, and send the management daemon message to the monitor node, wherein the monitor node is used to determine that the management daemon node is a failed node according to the management daemon message;

[0169] The closing unit 703 is used to close the management daemon program when receiving a service exit message, wherein the service exit message is generated by the monitor node when receiving a management daemon program message and determining that the management daemon program is a main program.

[0170] In some optional embodiments, the device further comprises:

[0171] a second judgment unit, configured to judge whether the management daemon node is a target node according to the first target layout information when the management daemon does not fail and the first target layout information is received, wherein the management daemon of the target node is a new main program, and the first target layout information is obtained after the monitor node marks the management daemon of the faulty node as a failure in the management daemon layout information and determines the target node in the management daemon layout information when the management daemon of the faulty node is the main program;

[0172] A startup unit is used to start a new main program of the target node if the management daemon node is the target node.

[0173] In some optional implementations, the second determining unit 701 determines the monitor node corresponding to the management daemon, including:

[0174] Get the target address information and monitor node layout information corresponding to the management daemon;

[0175] According to the target address information and the monitor node layout information, the monitor node whose address information is different from the target address information is determined, and the monitor node whose address information is different from the target address information is used as the monitor node corresponding to the management daemon.

[0176] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0177] The monitoring switching device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0178] The embodiment of the present invention also provides a computer device having the above Figure 6 or Figure 7 The monitoring switching device shown.

[0179] See also Figure 8 , Figure 8 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 8 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 8 A processor 10 is taken as an example.

[0180] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include an integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0181] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0182] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0183] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0184] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0185] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0186] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0187] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined in this application.

Claims

1. A monitoring switching method, characterized in that: The method is applied to a monitor node, and the method comprises: In the case where the management daemon is connected to the monitor node, if a management daemon message sent by the management daemon node is received, determining that the management daemon node that sent the management daemon message is a faulty node, wherein the management daemon is included in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node is different from the node where the monitor node is located; Sending a service exit message to the faulty node, instructing the faulty node to shut down the management daemon of the faulty node; If the management daemon of the failed node is the main program, determine a target node, send control information to the target node, and instruct the target node to enable a new main program, wherein the management daemon of the target node is the new main program.

2. The method according to claim 1, characterized in that: The sending of control information to the target node to instruct the target node to enable a new main program includes: Marking the management daemon of the faulty node as faulty in the management daemon layout information and determining the target node in the management daemon layout information to obtain first target layout information, wherein the management daemon of the target node is the new main program; The first target layout information is used as the control information, and the control information is sent to the management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to save the first target layout information, and instructing the target node to enable the new main program, wherein the management daemon node whose management daemon is not faulty includes the target node.

3. The method according to claim 1, characterized in that: After determining that the management daemon node that sends the management daemon message is a faulty node, the method further includes: If the management daemon of the faulty node is not the main program, marking the management daemon of the faulty node as faulty in the management daemon layout information, and obtaining second target layout information; The second target layout information is sent to a management daemon node whose management daemon is not faulty, and the management daemon node whose management daemon is not faulty is instructed to save the second target layout information.

4. The method according to claim 1, characterized in that: The method further comprises: Determine a preset service interface, and encapsulate the preset service interface into the monitor node, wherein the monitor node is used to sense data transmitted by a preset service through the preset service interface, and the preset service is used to obtain node status information and determine whether the node fails according to the status information; In case that a candidate node list transmitted by the preset service is sensed from the preset service interface, determining a candidate node according to the candidate node list, wherein the candidate node is a node where a fault occurs; In the case where the candidate node has a management daemon service, sending the service exit message to the candidate node to instruct the candidate node to shut down the management daemon of the candidate node; Determining whether the management daemon of the candidate node is the main program; If yes, marking the management daemon of the candidate node as faulty in the management daemon layout information and determining a management daemon to be started, to obtain third target layout information; Sending the third target layout information to a management daemon node whose management daemon is not faulty, instructing the management daemon node whose management daemon is not faulty to enable the management daemon to be started; If not, marking the management daemon of the candidate node as faulty in the management daemon layout information to obtain fourth target layout information; The fourth target layout information is sent to a management daemon node whose management daemon is not faulty, and the management daemon node whose management daemon is not faulty is instructed to save the fourth target layout information.

5. A monitoring switching method, characterized in that: The method is applied to manage daemon nodes, and the method comprises: Determine a monitor node corresponding to a management daemon, and connect the management daemon to the monitor node, wherein the management daemon is included in the management daemon node, and the management daemon node is different from the node where the monitor node is located; If the management daemon fails, a management daemon message is generated and sent to the monitor node, wherein the monitor node is used to determine that the management daemon node is a failed node according to the management daemon message; In case of receiving a service exit message, shutting down the management daemon, wherein the service exit message is generated by the monitor node when receiving the management daemon message and determining that the management daemon is a master program.

6. The method according to claim 5, characterized in that The method further comprises: In the case where the management daemon program has not failed and the first target layout information is received, judging whether the management daemon program node is a target node according to the first target layout information, wherein the management daemon program of the target node is a new main program, and the first target layout information is obtained by the monitor node after marking the management daemon program of the faulty node as failed in the management daemon program layout information and determining the target node in the management daemon program layout information when the management daemon program of the faulty node is the main program; If the management daemon node is the target node, the new main program of the target node is started.

7. The method according to claim 5, characterized in that The step of determining the monitor node corresponding to the management daemon program includes: Obtaining target address information and monitor node layout information corresponding to the management daemon; According to the target address information and the monitor node layout information, a monitor node whose address information is different from the target address information is determined, and the monitor node whose address information is different from the target address information is used as the monitor node corresponding to the management daemon.

8. A monitoring switching device, characterized in that: The device is deployed on a monitor node, and comprises: a first determining unit, configured to determine that the management daemon node that sends the management daemon message is a faulty node if a management daemon message sent by the management daemon node is received when the management daemon is connected to the monitor node, wherein the management daemon is included in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node is different from the node where the monitor node is located; A first sending unit, configured to send a service exit message to the faulty node, instructing the faulty node to shut down a management daemon of the faulty node; The second sending unit is used to determine a target node if the management daemon of the failed node is a main program, and send control information to the target node to instruct the target node to enable a new main program, wherein the management daemon of the target node is the new main program.

9. A monitoring switching device, characterized in that: The device is deployed on a management daemon node, and the device comprises: A second determining unit is used to determine a monitor node corresponding to the management daemon and connect the management daemon to the monitor node, wherein the management daemon is included in the management daemon node, and the management daemon node is different from the node where the monitor node is located; a third sending unit, configured to generate a management daemon message if the management daemon fails, and send the management daemon message to the monitor node, wherein the monitor node is configured to determine that the management daemon node is a failed node according to the management daemon message; The closing unit is used to close the management daemon program when receiving a service exit message, wherein the service exit message is generated by the monitor node when receiving the management daemon program message and determining that the management daemon program is a main program.

10. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the monitoring switching method according to any one of claims 1 to 7 by executing the computer instructions.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the monitoring switching method according to any one of claims 1 to 7.

Images