Monitoring switching method and device, computer device and storage medium

Abstract

This invention relates to the field of computer technology and discloses a monitoring and switching method, apparatus, computer equipment, and storage medium. The method includes: when a management daemon is connected to a monitor node, if a management daemon message is received from a management daemon node, determining that the management daemon node sending the message is a faulty node, wherein the management daemon is contained within the management daemon node; sending a service exit message to the faulty node, instructing the faulty node to close its management daemon; if the faulty node's management daemon is the master program, determining a target node, and sending control information to the target node, instructing the target node to activate a new master program, wherein the target node's management daemon is the new master program. This solves the problem of slow master-slave MGR switching, which causes temporary unavailability of upper-layer software and cluster statistics services, affecting the stability and reliability of the storage system.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and specifically to a monitoring switching method, apparatus, computer equipment, and storage medium. Background Technology

[0002] In a distributed storage system, the Monitor is a monitor daemon. To alleviate the load on the Monitor, a Management Daemon (MGR) service is introduced, responsible for the management and monitoring of the entire cluster, and taking over the monitoring and statistical functions originally belonging to the Monitor. Simultaneously, the MGR service defines a set of command extension interface specifications. Through plugins conforming to this specification, the MGR service can connect to more upper-layer services, such as management software and browser plugins, to extend management functions and achieve flexible cluster display, management, and analysis. Furthermore, the MGR service supports MGR cluster deployment, meaning that the MGR service can be deployed on multiple nodes in a distributed cluster, forming an MGR node cluster. Among all the MGR services on all nodes, there is only one primary MGR, and the rest are backup MGRs. Only the primary MGR will carry the full MGR service; the backup MGRs are mainly elected as the primary MGR to provide MGR service when the primary MGR fails, and otherwise remain in standby mode.

[0003] If the primary MGR service fails, the monitoring and management functions of the upper-layer services for the cluster will become unavailable, necessitating timely switching between the primary and standby MGRs. Currently, the Monitor maintains the MGR service for the entire cluster, responsible for the election of the primary and standby MGRs and the maintenance and publication of the mgrmap (management daemon layout information). During the current MGR switchover process, the Monitor checks whether it receives beacon messages from the MGR within a certain time. If not, it considers the MGR to have failed and marks it as offline. If the offline MGR happens to be the primary MGR, the Monitor will select a new standby MGR as the new primary MGR and update the mgrmap, pushing it to all surviving nodes containing the MGR, thus achieving the primary / standby MGR switchover. However, there is a problem with the current MGR switchover process: after determining that the primary MGR has failed, it takes some time for the Monitor to select and switch to a new primary MGR. During this period, the management and display services provided by the MGR service are unavailable. This can cause management software, upper-layer plugins, and cluster-related statistical services that depend on the cluster to malfunction or become unavailable, affecting the stability and reliability of the storage system.

[0004] Therefore, the related technologies suffer from slow master-slave MGR switching, which causes temporary unavailability of upper-layer software and cluster statistics services, affecting the stability and reliability of the storage system. Summary of the Invention

[0005] In view of this, the present invention provides a monitoring and switching method, apparatus, computer equipment and storage medium to solve the problem that slow master-slave MGR switching causes temporary unavailability of upper-layer software and cluster statistics services, 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 and includes:

[0007] When the management daemon is connected to the monitor node, if a management daemon message is received from the management daemon node, the management daemon node that sent the management daemon message is determined to be a faulty node. Here, the management daemon is contained in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node and the monitor node are on different nodes.

[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 of the faulty node is the main program, identify the target node, send control information to the target node, and instruct the target node to enable the new main program, wherein the management daemon of the target node is the new main program.

[0010] The monitoring switchover method provided in this embodiment generates a management daemon message and actively sends it to the monitor node when the management daemon fails. This shortens the time it takes for the monitor node to identify the faulty node. The monitor node first sends a service exit message to the faulty node, then identifies the target node and instructs it to activate the new master program, completing the master-slave management daemon switchover. This fast switchover avoids temporary unavailability of cluster management, display, and upper-layer plugin services after a management daemon failure, improving the reliability and stability of the MGR service in the event of different types of node failures, and enhancing the storage system's ability to withstand risks. It also solves the problem of slow master-slave MGR switchover, which causes temporary unavailability of upper-layer software and cluster statistics services, affecting the stability and reliability of the storage system.

[0011] In some optional implementations, control information is sent to the target node, instructing it to enable a new main program, including:

[0012] In the management daemon layout information, the management daemon of the faulty node is marked as faulty, and the target node is determined in the management daemon layout information to obtain the first target layout information, wherein the management daemon of the target node is the new main program;

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

[0014] In this embodiment, the monitor node marks the management daemon of the faulty node in the management daemon layout information and determines the target node, thus obtaining the first target layout information. This allows the management daemon node whose management daemon is not faulty to determine whether it is the target node through the first target layout information and quickly perform a primary / backup management daemon switchover.

[0015] In some alternative implementations, after determining that the management daemon node that sent 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, mark the management daemon of the faulty node as faulty in the management daemon layout information to obtain the second target layout information;

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

[0018] In some alternative implementations, the method further includes:

[0019] Determine the preset service interface and encapsulate it into the monitor node. The monitor node is used to perceive the data transmitted by the preset service through the preset service interface, and the preset service is used to obtain the status information of the node and determine whether the node has failed based on the status information.

[0020] If the list of candidate nodes passed by the preset service is perceived from the preset service interface, the candidate nodes are determined according to the list of candidate nodes, where the candidate nodes are the nodes that have failed.

[0021] If the candidate node has a management daemon service, send a service exit message to the candidate node, instructing the candidate node to shut down the candidate node's management daemon;

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

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

[0024] Send the third target layout information to the management daemon node that is not faulty, and instruct the management daemon node that is not faulty to enable the management daemon to be started;

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

[0026] Send the fourth target layout information to the management daemon node that is not faulty, and instruct the management daemon node that is not faulty to save the fourth target layout information.

[0027] In this implementation, a preset service quickly detects node failures and sends candidate nodes with potential failures to a monitor node. The monitor node then determines whether a management daemon service is the primary service for each candidate node and whether a switch to the primary service is necessary. This allows the monitor node to perform a primary / standby MGR service switchover even in the event of a node failure, improving the reliability and stability of the MGR service under different types of node failures and enhancing the storage system's resilience to risks.

[0028] Secondly, this invention provides a monitoring switching method, which is applied to managing daemon nodes, including:

[0029] Identify the monitor node corresponding to the management daemon and connect the management daemon to the monitor node. The management daemon is contained in the management daemon node, and the management daemon node is located on a different node than the monitor node.

[0030] If the management daemon fails, a management daemon message is generated and sent to the monitor node. The monitor node is used to determine that the management daemon node is the faulty node based on the management daemon message.

[0031] Upon receiving a service exit message, the management daemon is shut down. The service exit message is generated by the monitor node upon receiving a management daemon message and determining that the management daemon is the main program.

[0032] The monitoring switchover method provided in this embodiment generates a management daemon message and actively sends it to the monitor node when the management daemon fails. This enables the monitor node to identify the faulty node and promptly determine the target node, shortening the time required for the monitor node to identify the faulty node. The monitor node instructs the faulty node to exit the management daemon and instructs the target node to start a new master program, completing the master-slave management daemon switchover. This solves the problem of slow master-slave MGR switchover, which causes temporary unavailability of upper-layer software and cluster statistics services, affecting the stability and reliability of the storage system.

[0033] In some alternative implementations, the method further includes:

[0034] If the management daemon is not faulty and the first target layout information is received, determine whether the management daemon node is the target node based on the first target layout information. The management daemon of the target node is the new master program. The first target layout information is obtained by the monitor node after 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 when the management daemon of the faulty node is the master program.

[0035] If the management daemon node is the target node, then start the new main program on the target node.

[0036] In some optional implementations, the monitor node corresponding to the management daemon is determined, including:

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

[0038] Based on the target address information and monitor node layout information, identify the monitor nodes whose address information differs from the target address information, and designate these monitor nodes as the monitor nodes corresponding to the management daemon.

[0039] In this embodiment, a Monitor that is not on the same node as the MGR service is determined based on the target address information and the monitor node layout information. This avoids the situation where the Monitor on the same node cannot complete the processing of MGR failure messages after the node where the MGR service is located fails, thereby improving the reliability and stability of the primary and backup MGR switchover.

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

[0041] The first determining unit is used to determine, when the management daemon is connected to the monitor node, that the management daemon node that sent the management daemon message is a faulty node if a management daemon message is received from the management daemon node. The management daemon is contained in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node and the monitor node are located on different nodes.

[0042] The 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 faulty node is the main program, and send control information to the target node to instruct the target node to enable the new main program, wherein the management daemon of the target node is the new main program.

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

[0045] The second determining unit 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 contained in the management daemon node, and the management daemon node is different from the monitor node.

[0046] The third sending unit is used to generate a management daemon message and send the management daemon message to the monitor node if the management daemon fails. The monitor node is used to determine that the management daemon node is a faulty node based on the management daemon message.

[0047] The shutdown unit is used to shut down the management daemon upon receiving a service exit message. The service exit message is generated by the monitor node upon receiving a management daemon message and determining that the management daemon is the main program.

[0048] Fifthly, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the monitoring and switching method of the first aspect or any corresponding embodiment described above, or to perform the monitoring and switching method of the second aspect or any corresponding embodiment described above.

[0049] In a sixth aspect, the present invention provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the monitoring and switching method of the first aspect or any corresponding embodiment thereof, or to execute the monitoring and switching method of the second aspect or any corresponding embodiment thereof.

[0050] In a seventh aspect, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the monitoring and switching method of the first aspect or any corresponding embodiment thereof, or to execute the monitoring and switching method of the second aspect or any corresponding embodiment thereof. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of the present invention, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

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

[0053] Figure 2 This is a flowchart illustrating the switching of primary and backup MGRs in a scenario where a node experiences an active failure, according to an embodiment of the present invention.

[0054] Figure 3 This is a flowchart illustrating the switching of the backup MGR service to the primary MGR service according to an embodiment of the present invention.

[0055] Figure 4 This is a flowchart illustrating the switching of primary and backup MGRs in the event of a node failure, according to an embodiment of the present invention.

[0056] Figure 5 This is a flowchart illustrating a monitoring and switching method for managing daemon nodes according to an embodiment of the present invention.

[0057] Figure 6 This 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 This is a structural block diagram of a monitoring and switching device deployed on a management daemon node according to an embodiment of the present invention;

[0059] Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] The MGR service is responsible for tracking runtime metrics and the current state of the cluster. It acts as an intermediary layer between the Monitor and upper-layer services, managing and monitoring the entire cluster. It also takes over monitoring and statistical functions originally belonging to the Monitor, such as basic query command responses and OSD (Object Storage Device) message processing. This allows the Monitor to focus more on maintaining cluster state data, reducing the pressure on the Monitor from the cluster. The Monitor is a daemon process for monitoring the cluster. As can be seen, the MGR service is an indispensable module in a distributed storage cluster. If the MGR service fails, the monitoring and management functions of the upper-layer services will become unavailable. For example, the collection and display of cluster performance statistics, the query and display of PG (Placement Group) status, and cluster extension plugins will malfunction.

[0062] MGR cluster deployment supports a primary-multiple-standby operating mode. Only the primary MGR will carry the full MGR service. The standby MGRs are mainly elected as the primary MGR to provide MGR services when the primary MGR fails. Otherwise, they are in standby mode, only interacting with the Monitor via periodic beacon messages and subscribing to mgrmap (MGR layout information). Within the Monitor, to maintain the MGR service of the entire cluster, a separate MGRMonitor is used to maintain the MGR cluster, responsible for the election of primary and standby MGRs and the maintenance and publishing of mgrmap. During the current MGR failover process, the Monitor primarily relies on beacon messages periodically sent by the MGR service. Each time a beacon message is received, the Monitor marks the current uptime of that MGR service. When an MGR service fails (e.g., node shutdown, network interruption, node crash), beacon messaging between that MGR service and the Monitor ceases. If the Monitor determines that beacon messages for an MGR have been lost for more than a certain period (default 30 seconds), it considers the MGR to have failed and marks it as offline. If the offline MGR happens to be the primary MGR, a new primary MGR will be selected, and the mgrmap will be updated and pushed to all surviving MGR nodes. Within the MGR service, if it receives a new mgrmap indicating itself as the primary MGR, it will initialize the MGR service and corresponding plugin services, beginning to receive and process messages sent by OSDs or upper-layer services, maintaining the cluster's display, management, and analysis capabilities.

[0063] The above analysis reveals a problem with the current MGR service failover: when the MGR service fails due to network failures, node crashes, or other issues, the Monitor cannot quickly detect the failure. It can only detect the failure by relying on beacon messages (heartbeat messages) timeouts. It takes some time before the Monitor elects a new primary MGR. During this period, the management and display services provided by the MGR are unavailable. This can cause management software, upper-layer plugins, and cluster-related statistical services that depend on the cluster to malfunction or become unavailable, affecting the management and display functions provided by the cluster and impacting the stability and reliability of the storage system.

[0064] Based on the above, this invention provides a monitoring and switching method that introduces a fast switching mechanism. For proactive MGR service failures, the method improves the linking mechanism between the MGR and Monitor services. The MGR service prioritizes connecting to Monitors on non-local nodes. A new mechanism is added to proactively notify the Monitor of MGR failures, enabling the Monitor to quickly detect MGR failures, re-determine the primary MGR, and quickly switch between primary and backup MGRs. For anomalous MGR service failures, the storage system's high-availability module enables the Monitor service to quickly detect changes in MGR service failures, re-select the primary MGR, quickly switch between primary and backup MGRs, and quickly provide MGR services externally. This solves the problem of temporary unavailability of cluster management, display, and upper-layer plugin services after a primary MGR failure in two main types of storage system node failure scenarios (proactive and anomalous failures), significantly shortening service downtime and improving the reliability and stability of the distributed storage system. Ultimately, this enhances the reliability and stability of the MGR service under different types of node failures, strengthening the storage system's ability to withstand 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 in the accompanying drawings can be executed in the monitor node. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0066] This embodiment provides a monitoring switching method that can be used on monitor nodes. Figure 1 This is a flowchart of a monitoring switching method according to an embodiment of the present invention, such as... 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 is received from the management daemon node, the management daemon node that sent the management daemon message is determined to be a faulty node. Here, the management daemon is contained in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node and the monitor node are located on different nodes.

[0068] Specifically, in distributed storage systems, to reduce the pressure on the Monitor from the cluster, the MGR service is introduced. The MGR service tracks runtime metrics and the current state of the cluster, taking over the monitoring and statistical functions originally belonging to the Monitor, such as basic query command responses and message processing reported by OSDs (Object Storage Devices). Therefore, the monitoring switching method in this application involves switching or processing the MGR service; for example, switching the active MGR service when the node hosting the MGR service fails.

[0069] For proactive failure scenarios, such as node shutdown or MGR (Management Daemon) service termination, this embodiment introduces two mechanisms: when the MGR service starts, it prioritizes connecting to non-local Monitor nodes; the MGR service proactively captures failures and notifies the Monitor when a failure occurs, enabling the Monitor to quickly detect MGR service failures.

[0070] During the MGR service startup process of selecting a Monitor and establishing a connection, a screening mechanism is added to prioritize connecting to Monitors outside the local node. Prioritizing connections to non-local Monitors ensures that fault messages sent by MGR can be quickly and accurately delivered to the Monitor in the event of a failure. If MGR connects to the local Monitor service, when the node shuts down, MGR will send the message to the local Monitor, but that Monitor will also be processing the fault, thus failing to complete the processing of the MGR fault message.

[0071] A new MGR service fault capture module is added to the MGR service. This module selects based on the fault signal; in this embodiment, it primarily captures signals of active faults. A new management daemon message, such as the MMGRDown message, is also added for MGR to send fault information to the Monitor. When the management daemon (MGR) and the Monitor module are connected, if an active fault occurs in the MGR service or the management daemon node containing the MGR service, the MGR service captures the fault, encapsulates the fault type in the newly added management daemon message (e.g., MMGRDown), and sends it to the Monitor service, actively notifying the Monitor of the fault information. The service then waits for a response from the Monitor service 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 from the management daemon node, it determines that the management daemon node that sent the message is a faulty node, meaning that the management daemon node has actively failed. Additionally, 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. This queue will send a service exit message to the corresponding management daemon node that sent the management daemon message after the Monitor completes its deliberations.

[0073] The above process is as follows Figure 2 As shown, when the MGR service starts, it prioritizes establishing connections with Monitor services that are not on the local node; if a failure occurs, the MGR service detects the failure, sends a failure message MMGRDown, and waits for a response from the Monitor.

[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 receiving the management daemon message from the MGR, the Monitor immediately performs a mgrmap (management daemon layout information) change. Specifically: first, the MGR service of the failed node is marked as failed. If the failed node is the primary MGR node, a new primary MGR is immediately elected, and after processing, a proposal to update the mgrmap is triggered. After completing the mgrmap update, the Monitor processes the wait_for_finish_propose queue. If there is an pending MMGRDown message in the queue, a message reply is sent to the failed node, indicating a service exit message, such as an MMGRDown message, instructing the failed node to shut down its management daemon. If the failed node receives a service exit message, it then proceeds with the exit operations of the remaining MGR processes until the failed node's MGR service is shut down. The above process is as follows: Figure 2 As shown, reply with a message; release resources and exit the process.

[0076] Step S103: If the management daemon of the faulty node is the main program, determine the target node, send control information to the target node, and instruct the target node to enable the 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 primary MGR will carry the full MGR service. The standby MGRs are mainly elected as the primary MGR to provide MGR services when the primary MGR fails; otherwise, they are in standby mode. If the management daemon of the failed node is the primary program, meaning the MGR service of the failed node is the primary MGR, a new primary MGR needs to be determined to ensure the MGR cluster can provide normal management, display, and other services. The target node for determining the management daemon as the new primary program is then targeted by sending control information to instruct it to activate the new primary program.

[0078] After the standby MGR node receives the control message, if it parses the message and finds that it is the target node, it immediately reinitializes and initializes all MGR plugins, providing the primary MGR service and maintaining the management and display functions of some cluster states. This primary / standby MGR failover process can reduce the downtime of MGR service from minutes to within 10 seconds.

[0079] The monitoring switchover method provided in this embodiment generates a management daemon message and actively sends it to the monitor node when the management daemon fails. This shortens the time it takes for the monitor node to identify the faulty node. The monitor node first sends a service exit message to the faulty node, then identifies the target node and instructs it to activate the new master program, completing the master-slave management daemon switchover. This fast switchover avoids temporary unavailability of cluster management, display, and upper-layer plugin services after a management daemon failure, improving the reliability and stability of the MGR service in the event of different types of node failures, and enhancing the storage system's ability to withstand risks. It also solves the problem of slow master-slave MGR switchover, which causes temporary unavailability of upper-layer software and cluster statistics services, affecting the stability and reliability of the storage system.

[0080] In some optional implementations, control information is sent to the target node, instructing it to enable a new main program, including:

[0081] In the management daemon layout information, the management daemon of the faulty node is marked as faulty, and the target node is determined in the management daemon layout information to obtain the first target layout information, wherein the management daemon of the target node is the new main program;

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

[0083] Specifically, the management daemon layout information is, for example, mgrmap. After receiving a management daemon message from the MGR, the Monitor immediately updates the management daemon layout information. First, it marks 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 primary MGR, a new primary MGR is immediately elected. For example, after receiving the management daemon message, the Monitor adds the corresponding management daemon node information to off_mgr_node. During the mgrmap update process, the Monitor judges the faulty nodes. If there is a primary MGR node among them, it sets the primary MGR switch flag switch_mgr to true, removes all off_mgr_node nodes from the current mgrmap, and obtains pending_mgrmap. pending_mgrmap contains management daemon nodes with normal MGR service. A new primary MGR is elected as the target node from pending_mgrmap. The Monitor determines the target node containing the new primary MGR in the management daemon layout information. After processing, it triggers a proposal to update the management daemon layout information, obtaining the first target layout information.

[0084] The Monitor uses the first target layout information as control information and sends it to the management daemon node that is functioning correctly. This control information instructs the correct management daemon node to save the first target layout information and instructs the target node to activate the new master program. The correct management daemon node is the surviving MGR node. Upon receiving the first target layout information, the surviving MGR node reads the information to determine if it is the target node. If it was previously a backup MGR node but is now the target node, it activates the new master program. For example, it enters the initialization process to initialize MGR and all plugin services, providing MGR functionality externally. If it is not the target node, it saves the first target layout information and continues to act as a backup MGR node without making any modifications.

[0085] The above process is as follows Figure 2 As shown, the Monitor handles failures; whether it is the primary MGR node; if so, it re-elects a primary MGR, actively updates the mgrmap and pushes it to the surviving MGR nodes; if not, it actively updates the mgrmap and pushes it to the surviving MGR nodes, and replies with a message.

[0086] In this embodiment, the monitor node marks the management daemon of the faulty node in the management daemon layout information and determines the target node, thus obtaining the first target layout information. This allows the management daemon node whose management daemon is not faulty to determine whether it is the target node through the first target layout information and quickly perform a primary / backup management daemon switchover.

[0087] In some alternative implementations, after determining that the management daemon node that sent 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, mark the management daemon of the faulty node as faulty in the management daemon layout information to obtain the second target layout information;

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

[0090] Specifically, the management daemon layout information is, for example, mgrmap. After receiving the management daemon message sent by the MGR, the Monitor immediately updates the management daemon layout information. If the MGR service of the faulty node is not the primary MGR, the MGR service of the faulty node is marked as faulty in the management daemon layout information. After the processing is completed, a proposal is triggered to update the management daemon layout information to obtain the second target layout information.

[0091] After the Monitor completes its resolution, it sends the second target layout information to the management daemon node whose management daemon is functioning correctly, instructing the node to save the second target layout information. Upon receiving the second target layout information, the node saves it and continues to act as the backup MGR node without making any modifications. The above process is as follows... Figure 3 As shown, the standby MGR receives a new mgrmap; it determines whether to become the primary MGR; if not, it continues to run as the standby MGR.

[0092] In some alternative implementations, the method further includes:

[0093] Determine the preset service interface and encapsulate it into the monitor node. The monitor node is used to perceive the data transmitted by the preset service through the preset service interface, and the preset service is used to obtain the status information of the node and determine whether the node has failed based on the status information.

[0094] If the list of candidate nodes passed by the preset service is perceived from the preset service interface, the candidate nodes are determined according to the list of candidate nodes, where the candidate nodes are the nodes that have failed.

[0095] If the candidate node has a management daemon service, send a service exit message to the candidate node, instructing the candidate node to shut down the candidate node's management daemon;

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

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

[0098] Send the third target layout information to the management daemon node that is not faulty, and instruct the management daemon node that is not faulty to enable the management daemon to be started;

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

[0100] Send the fourth target layout information to the management daemon node that is not faulty, and instruct the management daemon node that is not faulty to save the fourth target layout information.

[0101] Specifically, in this embodiment, for abnormal failure scenarios such as network interruptions and node crashes / malfunctions, the MGR service on a single node cannot detect these scenarios. However, the high availability service of the distributed cluster can be relied upon to detect abnormal failures. Therefore, this embodiment introduces a fault handling mechanism based on the cluster's high availability service to achieve rapid failover of the MGR service in abnormal failure scenarios.

[0102] Pre-defined services are high-availability services in distributed clusters, such as CTDB and keepalive services. Their main function is to quickly detect (within seconds, typically around 2 seconds) node-level network outages, node crashes, and other abnormal failures. The pre-defined service interface is an interface that high-availability services can call. This interface is encapsulated in the Monitor for use by high-availability services.

[0103] The preset service obtains the status information of the nodes and determines whether the nodes have failed (such as network anomalies or node crashes) 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 nodes that have failed, which are the candidate nodes.

[0104] When the Monitor receives the candidate node list from the preset service interface, it reads the candidate node list (off_node_list), identifies the candidate nodes, and verifies the candidate nodes in off_node_list to determine whether they have the MGR (Management Daemon) service. Nodes without the MGR service are discarded, resulting in a list of faulty MGR nodes (off_mgr_node). If a candidate node has the Management Daemon service, a service exit message is sent to the candidate node, instructing it to shut down its Management Daemon.

[0105] The system determines whether the management daemon of a candidate node is the primary daemon. If so, it immediately updates the management daemon layout information. First, it marks 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 primary MGR, a new primary MGR is immediately elected. For example, after receiving a management daemon message, the Monitor adds the corresponding management daemon node information to `off_mgr_node`. During the `mgrmap` update process, the Monitor checks the faulty nodes. If any of them are primary MGR nodes, it sets the primary MGR switch flag `switch_mgr` to true and removes all `off_mgr_node` nodes from the current `mgrmap`, resulting in `pending_mgrmap`. `pending_mgrmap` contains management daemon nodes with normal MGR services. A new primary MGR is elected from `pending_mgrmap` as the target node. The management daemon layout information is then used to determine the target node containing the new primary MGR. After processing, a proposal is triggered to update the management daemon layout information, resulting in the third target layout information.

[0106] The third target layout information is sent to the management daemon node that is not experiencing a failure. Upon receiving the first target layout information, the management daemon node reads the first target layout information to determine if it is the target node. If it was previously a backup MGR node but is now the target node, it activates the new master program, for example, by entering the initialization process to initialize MGR and all plugin services, and providing MGR functionality externally. If it is not the target node, it saves the first target layout information and continues to act as a backup MGR node without any modifications.

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

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

[0109] In this implementation, a preset service quickly detects node failures and sends candidate nodes with potential failures to a monitor node. The monitor node then determines whether a management daemon service is the primary service for each candidate node and whether a switch to the primary service is necessary. This allows the monitor node to perform a primary / standby MGR service switchover even in the event of a node failure, improving the reliability and stability of the MGR service under different types of node failures and enhancing the storage system's resilience to 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. Although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0111] This embodiment provides a monitoring switching method that can be used to manage daemon nodes. Figure 5 This is a flowchart of a monitoring switching method according to an embodiment of the present invention, such as... Figure 5 As shown, the process includes the following steps:

[0112] Step S501: Determine the monitor node corresponding to the management daemon and connect the management daemon to the monitor node. The management daemon is contained in the management daemon node, and the management daemon node and the monitor node are located on different nodes.

[0113] Specifically, in distributed storage systems, to reduce the pressure on the Monitor from the cluster, the MGR service is introduced. The MGR service tracks runtime metrics and the current state of the cluster, taking over the monitoring and statistical functions originally belonging to the Monitor, such as basic query command responses and message processing reported by OSDs (Object Storage Devices). Therefore, the monitoring switching method in this application involves switching or processing the MGR service; for example, switching the active MGR service when the node hosting the MGR service fails.

[0114] For proactive failure scenarios, such as node shutdown or MGR (Management Daemon) service termination, this embodiment introduces two mechanisms: when the MGR service starts, it prioritizes connecting to non-local Monitor nodes; the MGR service proactively captures failures and notifies the Monitor when a failure occurs, enabling the Monitor to quickly detect MGR service failures.

[0115] During the MGR service startup process of selecting a Monitor and establishing a connection, a screening mechanism is added to prioritize connecting to Monitors outside the local node. Prioritizing connections to non-local Monitors ensures that fault messages sent by MGR can be quickly and accurately delivered to the Monitor in the event of a failure. If MGR connects to the local Monitor service, when the node shuts down, MGR will send the message to the local Monitor, but that Monitor will also be processing the fault, thus failing to complete the processing of the MGR fault message.

[0116] Step S502: 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 faulty node based on the management daemon message.

[0117] Specifically, an MGR service fault capture module is added to the MGR service, which selects based on the fault signal. In this embodiment, the MGR service fault capture module mainly captures signals of active faults. A new management daemon message, such as the MMGRDown message, is also added, used by MGR to send fault information to the Monitor.

[0118] When the Management daemon (MGR) and the Monitor module are connected, when the MGR service fault capture module detects an active failure in the MGR service or the management daemon node where the MGR service resides, the MGR service captures the failure, encapsulates the failure type into a newly added management daemon message, such as an MMGRDown message, and sends it to the Monitor service, actively notifying the Monitor of the failure information. It then waits for a response from the Monitor service before continuing the service exit process.

[0119] Step S503: Upon receiving a service exit message, shut down the management daemon. The service exit message is generated by the monitor node upon receiving a management daemon message and determining that the management daemon is the main program.

[0120] Specifically, after receiving the management daemon message from the MGR, the Monitor immediately performs a mgrmap (management daemon layout information) change. This involves: first, marking the MGR service of the faulty node as faulty; if the faulty node is the primary MGR node, immediately electing a new primary MGR; and then triggering a proposal to update the mgrmap. After updating the mgrmap, the Monitor processes the wait_for_finish_propose queue. If there are pending MMGRDown messages in the queue, it replies with a service exit message to the faulty node, such as an MMGRDown message instructing the faulty node to shut down its management daemon.

[0121] If the management daemon is a failed node and receives a service exit message, the failed node will then proceed with the exit operations of the remaining MGR processes until the MGR service on the failed node is shut down. The above process is as follows: Figure 2 As shown, reply with a message; release resources and exit the process.

[0122] The monitoring switchover method provided in this embodiment generates a management daemon message and actively sends it to the monitor node when the management daemon fails. This enables the monitor node to identify the faulty node and promptly determine the target node, shortening the time required for the monitor node to identify the faulty node. The monitor node instructs the faulty node to exit the management daemon and instructs the target node to start a new master program, completing the master-slave management daemon switchover. This solves the problem of slow master-slave MGR switchover, which causes temporary unavailability of upper-layer software and cluster statistics services, affecting the stability and reliability of the storage system.

[0123] In some alternative implementations, the method further includes:

[0124] If the management daemon is not faulty and the first target layout information is received, determine whether the management daemon node is the target node based on the first target layout information. The management daemon of the target node is the new master program. The first target layout information is obtained by the monitor node after 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 when the management daemon of the faulty node is the master program.

[0125] If the management daemon node is the target node, then start the new main program on the target node.

[0126] Specifically, after receiving the management daemon message sent by the MGR, the Monitor immediately updates the management daemon layout information. First, it marks the MGR service of the faulty node as faulty in the management daemon layout information. Then, the Monitor determines the target node containing the new primary MGR in the management daemon layout information. After processing, it triggers a proposal to update the management daemon layout information and obtains the first target layout information.

[0127] The Monitor uses the first target layout information as control information and sends it to the management daemon node that is not experiencing a failure. The management daemon node that is not experiencing a failure is the live MGR node. Upon receiving the first target layout information, the live MGR node reads the information to determine if it is the target node. If it was previously a backup MGR node but is now the target node, it activates the new master program. For example, it enters the initialization process to initialize the MGR and all plugin services, provides the master MGR service externally, and maintains management and display functions for some cluster states.

[0128] The above process is as follows Figure 3 As shown, the standby MGR receives a new mgrmap; it determines whether it should become the primary MGR; if so, it initializes the MGR and all plugin services and provides services to the outside world.

[0129] In some optional implementations, the monitor node corresponding to the management daemon is determined, including:

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

[0131] Based on the target address information and monitor node layout information, identify the monitor nodes whose address information differs from the target address information, and designate these monitor nodes as the monitor nodes corresponding to the management daemon.

[0132] Specifically, this embodiment introduces a mechanism for active fault scenarios: when the MGR service starts, it prioritizes connecting to a Monitor node that is not on the local node. This is to prevent the MGR service from failing if the Monitor is on the same node and is also processing the fault, thus failing to complete the processing of the MGR fault message.

[0133] Retrieve the target address information corresponding to the management daemon, such as the IP (Internet Protocol) information of the node where the MGR service resides. Retrieve the monitor node layout information (monmap), which records the monitors included in the distributed system and the address information of the nodes where the monitors reside, such as the IP information of the nodes where the monitors reside.

[0134] Based on the target address information and monitor node layout information, identify monitor nodes whose address information differs from the target address information. For example, identify a monitor whose IP address is different from the IP address of the node where the MGR service is located. Designate the monitor node with the different address information as the monitor node corresponding to the management daemon and establish its connection with the MGR service.

[0135] In this embodiment, a Monitor that is not on the same node as the MGR service is determined based on the target address information and the monitor node layout information. This avoids the situation where the Monitor on the same node cannot complete the processing of MGR failure messages after the node where the MGR service is located fails, thereby improving the reliability and stability of the primary and backup MGR switchover.

[0136] In some alternative implementations, the Monitor switching process for primary and backup 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 this 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 application's connection address to a domain name.

[0139] Step A3: After identifying the faulty node based on the management daemon message, Monitor determines the target node and changes the MEMBER_ROLE field in the replication_group_members table of the target node's MySQL database 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 changes to the PRIMARY field, it indicates a switchover of the primary node, from node A to node B. A master-slave database switchover is then required, synchronizing the data from node A's database to node B's database and enabling node B's database as the primary database.

[0141] Step A4: The target node checks 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 switchover has been completed, and the new master database, i.e., the database of node B, can be opened, and the MGR service of the target node can be started as the master MGR service. If it is not turned off, wait until the read_only parameter is turned off before opening the new master database and starting the MGR service of the target node as the master MGR service.

[0142] Specifically, when the primary database is switched, the original primary database becomes a secondary database, and any one of the multiple secondary databases then becomes the new primary database. At this point, the domain name will inevitably no longer correspond to the new primary database, therefore step A5 is executed.

[0143] Step A5: Monitor modifies the current IP address to ensure that the current IP address corresponds to the domain name.

[0144] In step A6, the Monitor instructs the application to automatically reconnect, relocate to the new IP address via the domain name, and complete the switchover of the primary and backup MGR services.

[0145] In this implementation, if the management daemon fails, a management daemon message is generated and proactively sent to the monitor node, shortening the time it takes for the monitor node to identify the failed node. The monitor instructs the target node to complete the primary / standby database switch by changing the MEMBER_ROLE field to the PRIMARY field and sets the target node's MGR service as the primary MGR service, thus completing the primary / standby MGR service switch. This improves the reliability and stability of the MGR service in the storage system under different types of node failures, enhancing the storage system's ability to withstand risks.

[0146] This embodiment also provides a monitoring switching device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

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

[0148] The first determining unit 601 is used to determine, when the management daemon is connected to the monitor node, that the management daemon node that sent the management daemon message is a faulty node if a management daemon message sent by the management daemon node is received. The management daemon is contained in the management daemon node, the management daemon message is generated when the management daemon fails, and the management daemon node and the monitor node are located on different nodes.

[0149] The 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 the target node if the management daemon of the faulty node is the main program, and send control information to the target node to instruct the target node to enable the 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, instructing the target node to enable a new main program, including:

[0152] In the management daemon layout information, the management daemon of the faulty node is marked as faulty, and the target node is determined in the management daemon layout information to obtain the first target layout information, wherein the management daemon of the target node is the new main program;

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

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

[0155] The unit is used 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 to obtain the second target layout information.

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

[0157] In some alternative embodiments, the device further includes:

[0158] The encapsulation unit is used to determine the preset service interface and encapsulate the preset service interface to the monitor node. The monitor node is used to perceive the data transmitted by the preset service through the preset service interface. The preset service is used to obtain the status information of the node and determine whether the node has failed based on the status information.

[0159] The third determining unit is used to determine candidate nodes based on the candidate node list when the candidate node list is perceived from the preset service interface, wherein the candidate node is a node that has failed.

[0160] The fifth sending unit is used to send a service exit message to the candidate node when the candidate node has a management daemon service, instructing the candidate node to close the candidate node's management daemon.

[0161] The first judgment unit is used to determine whether the management daemon of the candidate node is the main program;

[0162] The first marking unit is used to mark the management daemon of the candidate node as faulty and determine the management daemon to be started in the management daemon layout information if the condition is met, so as to obtain the third target layout information.

[0163] The sixth sending unit is used to send the third target layout information to the management daemon node where the management daemon is not faulty, and to instruct the management daemon node where the management daemon is not faulty to enable the management daemon to be started;

[0164] The second marking unit is used to mark the management daemon of the candidate node as faulty in the management daemon layout information if it is not, so as to obtain the fourth target layout information.

[0165] The seventh sending unit is used to send the fourth target layout information to the management daemon node where the management daemon is not faulty, and to instruct the management daemon node where the 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, it includes:

[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 contained in the management daemon node and the management daemon node is different from the monitor node.

[0168] The third sending unit 702 is used to generate a management daemon message and send the management daemon message to the monitor node if the management daemon fails. The monitor node is used to determine that the management daemon node is a faulty node based on the management daemon message.

[0169] Shutdown unit 703 is used to shut down the management daemon upon receiving a service exit message, wherein the service exit message is generated by the monitor node upon receiving a management daemon message and determining that the management daemon is the main program.

[0170] In some alternative embodiments, the device further includes:

[0171] The second judgment unit is used to determine whether the management daemon node is the target node based on the first target layout information when the management daemon has not failed and the first target layout information has been received. The management daemon of the target node is the new main program. The first target layout information is obtained by the monitor node after 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 when the management daemon of the faulty node is the main program.

[0172] The startup unit is used to start a new main program on 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] Obtain the target address information and monitor node layout information corresponding to the management daemon;

[0175] Based on the target address information and monitor node layout information, identify the monitor nodes whose address information differs from the target address information, and designate these monitor nodes as the monitor nodes corresponding to the management daemon.

[0176] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

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

[0178] This invention also provides a computer device having the above-described features. Figure 6 or Figure 7 The monitoring switching device shown.

[0179] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 8 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 8 Take a processor 10 as an example.

[0180] Processor 10 may be a central processing unit, a network processor, or a combination thereof. 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 (FPGA), a general-purpose array logic (GPA), or any combination thereof.

[0181] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0182] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

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

[0184] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0185] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0186] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0187] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall 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 includes: When the management daemon is connected to the monitor node, if a management daemon message is received from the management daemon node, the management daemon node that sent the management daemon message is determined to be a faulty node. The management daemon is contained 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. Send a service exit message to the faulty node, instructing the faulty node to shut down its management daemon; If the management daemon of the faulty node is the main program, determine the target node, send control information to the target node, and instruct the target node to enable the new main program, wherein the management daemon of the target node is the new main program; Sending 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; using the first target layout information as the control information, sending the control information 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 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.

2. The method according to claim 1, characterized in that, After determining that the management daemon node that sent 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, mark the management daemon of the faulty node as faulty in the management daemon layout information to obtain the second target layout information; The second target layout information is sent to the management daemon node where the management daemon is not faulty, and the management daemon node where the management daemon is not faulty is instructed to save the second target layout information.

3. The method according to claim 1, characterized in that, The method further includes: A preset service interface is determined and encapsulated into the monitor node. The monitor node is used to perceive the data transmitted by the preset service through the preset service interface. The preset service is used to obtain the status information of the node and determine whether the node has failed based on the status information. If the candidate node list transmitted by the preset service is perceived from the preset service interface, a candidate node is determined according to the candidate node list, wherein the candidate node is a node that has failed. If the candidate node has a management daemon service, send the service exit message to the candidate node, instructing the candidate node to close the candidate node's management daemon; Determine whether the management daemon of the candidate node is the main program; If so, mark the management daemon of the candidate node as faulty and determine the management daemon to be started in the management daemon layout information to obtain the third target layout information; The third target layout information is sent to the management daemon node where the management daemon is not faulty, instructing the management daemon node where the management daemon is not faulty to enable the management daemon to be started; If not, mark the management daemon of the candidate node as faulty in the management daemon layout information to obtain the fourth target layout information; The fourth target layout information is sent to the management daemon node that is not malfunctioning, instructing the management daemon node that is not malfunctioning to save the fourth target layout information.

4. A monitoring switching method, characterized in that, The method is applied to managing daemon nodes, and the method includes: Identify the monitor node corresponding to the management daemon and connect the management daemon to the monitor node, wherein the management daemon is contained 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 faulty node based on the management daemon message; Upon receiving a service exit message, the management daemon is shut down, wherein the service exit message is generated by the monitor node upon receiving the management daemon message and determining that the management daemon is the main program.

5. The method according to claim 4, characterized in that, The method further includes: If the management daemon does not malfunction and the first target layout information is received, the monitor node determines whether the management daemon node is a target node based on the first target layout information. The management daemon of the target node is a new main program. The first target layout information is obtained by the monitor node after 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 when the management daemon of the faulty node is the main program. If the management daemon node is the target node, then the new main program on the target node is started.

6. The method according to claim 4, characterized in that, The process of determining the monitor node corresponding to the management daemon includes: Obtain the target address information and monitor node layout information corresponding to the management daemon; Based on the target address information and the monitor node layout information, monitor nodes whose address information is different from the target address information are determined, and the monitor nodes whose address information is different from the target address information are used as the monitor nodes corresponding to the management daemon.

7. A monitoring switching device, characterized in that, The device is deployed on a monitor node, and the device includes: The first determining unit is configured to, when the management daemon is connected to the monitor node, determine that the management daemon node sending the management daemon message is a faulty node if it receives a management daemon message sent by the management daemon node, wherein the management daemon is contained 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. The 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; The second sending unit is configured to, if the management daemon of the faulty 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; The second sending unit sends control information to the target node, instructing the target node to enable a new main program, including: 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; using the first target layout information as the control information, sending the control information 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 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.

8. A monitoring switching device, characterized in that, The device is deployed on a management daemon node, and the device includes: The second determining unit 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 contained in the management daemon node, and the management daemon node is different from the node where the monitor node is located; The third sending unit is configured to generate a management daemon message and send the management daemon message to the monitor node if the management daemon fails, wherein the monitor node is configured to determine that the management daemon node is a faulty node based on the management daemon message; The shutdown unit is used to shut down the management daemon upon receiving a service exit message, wherein the service exit message is generated by the monitor node upon receiving the management daemon message and determining that the management daemon is the main program.

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

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the monitoring switching method according to any one of claims 1 to 6.

Images