Arbitration system and arbitration method

Abstract

The application discloses an arbitration system and method, relates to the fields of cloud computing and super fusion, and comprises a plurality of servers connected through a switch, and at least one server in the plurality of servers is internally provided with a target arbitration component, wherein the target arbitration component is used for receiving first heartbeat signals sent by the plurality of servers based on at least one time window, and monitoring running states of the plurality of servers according to a receiving condition of the first heartbeat signals received in the at least one time window; whether there is a fault server in the plurality of servers is determined according to the running states, and a target server is determined in the plurality of servers in the case that it is determined that there is a fault server in the plurality of servers, wherein the target server is used for performing a data migration operation on the fault server, and the target server is a server with a normal state.

Description

Technical Field

[0001] This application relates to the fields of cloud computing and hyperconvergence, and in particular to arbitration systems and arbitration methods. Background Technology

[0002] With the development of cloud computing and big data technologies, the application of hyperconverged systems has become increasingly widespread. However, hyperconverged systems in related technologies require at least three nodes, including an arbitration box or personal computer (PC), to achieve arbitration. However, in scenarios with low requirements for computing and storage resources, this three-node configuration leads to resource waste and increased costs, which limits its application in some small-scale scenarios.

[0003] There is no effective solution yet to address the resource waste caused by the requirement that hyperconverged systems in related technologies require arbitration through at least three nodes, including PCs or arbitration boxes. Summary of the Invention

[0004] This application provides an arbitration system and arbitration method to at least address the problem of resource waste caused by hyperconverged systems in related technologies requiring arbitration through at least three nodes, including a PC or arbitration box.

[0005] This application provides an arbitration system, comprising: multiple servers connected via a switch, at least one of the multiple servers having a target arbitration component installed therein; wherein: the target arbitration component is configured to receive a first heartbeat signal sent by the multiple servers based on at least one time window, and monitor the operating status of the multiple servers based on the reception status of the first heartbeat signal within the at least one time window; determine whether there is a faulty server among the multiple servers based on the operating status, and if a faulty server is determined among the multiple servers, determine a target server among the multiple servers, wherein the target server is configured to perform a data migration operation on the faulty server, and the target server is a server whose operating status is normal.

[0006] This application also provides an arbitration method applied to a target arbitration component, wherein the target arbitration component is installed inside at least one of a plurality of servers connected by a switch, comprising: receiving a first heartbeat signal sent by the plurality of servers based on at least one time window, and monitoring the operating status of the plurality of servers based on the reception of the first heartbeat signal within the at least one time window; determining whether there is a faulty server among the plurality of servers based on the operating status, and if a faulty server is determined among the plurality of servers, determining a target server among the plurality of servers, wherein the target server is used to perform data migration operations on the faulty server, and the target server is a server whose operating status is normal.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the arbitration method described above when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described arbitration method.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described arbitration method.

[0010] In this application, multiple servers are connected via a switch. At least one of the servers has a target arbitration component installed internally. This target arbitration component is used to: receive first heartbeat signals from the multiple servers based on at least one time window, and monitor the operating status of the multiple servers based on the reception of the first heartbeat signals within the at least one time window; if a faulty server is determined based on the operating status, a target server is identified among the multiple servers, so that the target server performs a data migration operation on the faulty server. In other words, this application can achieve arbitration operations on multiple servers using multiple servers and the target arbitration component installed internally in at least one server. According to this application, the resource waste caused by the need for at least three nodes, including a PC or arbitration box, in hyperconverged systems in related technologies can be solved, thereby achieving arbitration using only multiple servers and the target arbitration system installed internally in at least one server, saving resources. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is an architecture diagram of an arbitration system according to an embodiment of this application;

[0013] Figure 2 This is a diagram of the hyperconverged minimal deployment topology in related technologies;

[0014] Figure 3 This is a framework diagram of a hyperconverged minimal deployment system based on a server BMC as an arbitration node, according to an optional embodiment of this application;

[0015] Figure 4 This is a flowchart of a hyperconverged minimal deployment method based on a server BMC as an arbitration node, according to an optional embodiment of this application;

[0016] Figure 5 This is a flowchart of an arbitration method according to an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0018] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0019] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to specific embodiments.

[0020] This embodiment provides an arbitration system. Figure 1 This is an architecture diagram of an arbitration system according to an embodiment of this application, such as... Figure 1 As shown, the system includes:

[0021] Multiple servers 12 are connected via a switch, and at least one of the servers has a target arbitration component 14 installed inside, wherein:

[0022] The target arbitration component 14 is used to receive a first heartbeat signal sent by the plurality of servers based on at least one time window, and monitor the operating status of the plurality of servers according to the reception status of the first heartbeat signal received within the at least one time window; determine whether there is a faulty server among the plurality of servers according to the operating status, and if it is determined that there is a faulty server among the plurality of servers, determine a target server among the plurality of servers, wherein the target server is used to perform data migration operation on the faulty server, and the target server is a server whose operating status is normal.

[0023] As described in the above system, this application connects multiple servers via a switch. At least one of the servers has a target arbitration component installed internally. This target arbitration component is used to: receive first heartbeat signals from the multiple servers based on at least one time window, and monitor the operating status of the multiple servers based on the reception of the first heartbeat signals within the at least one time window; if a faulty server is determined based on the operating status, a target server is identified among the multiple servers, so that the target server performs data migration operations on the faulty server. In other words, this application can achieve arbitration operations on multiple servers through multiple servers and the target arbitration component installed internally in at least one server. According to this application, the resource waste caused by the need for at least three nodes, including a PC or arbitration box, in hyperconverged systems in related technologies can be solved. Arbitration can be achieved using only multiple servers and the target arbitration system installed internally in at least one server, thus saving resources.

[0024] Optionally, the server can proactively send the first heartbeat signal to the target arbitration node, or it can passively send the first heartbeat signal to the target arbitration node. Specifically:

[0025] 1) Passively sending the first heartbeat signal:

[0026] The at least one server is configured to: upon receiving a second heartbeat signal sent by the target arbitration component at a first time point, send a response signal to the target arbitration component within a time window corresponding to the first time point, wherein the first heartbeat signal includes the response signal, and the at least one time window includes the time window corresponding to the first time point.

[0027] Understandably, after receiving the second heartbeat signal from the target arbitration component at a specific moment (e.g., the first time point), the server will proactively return a response signal to the target arbitration component within a preset time window corresponding to the first time point. Upon receiving the response signal, the target arbitration component can determine that it has received at least one first heartbeat signal from the server.

[0028] For example, the target arbitration node sends a heartbeat packet to server A at 10.5 seconds, which carries the token value "T12345" (the heartbeat packet is the second heartbeat signal); after receiving the heartbeat packet, server A determines that it is a valid heartbeat request, and then immediately sends back a response packet containing "T12345" (i.e., the response signal) to the target arbitration node within the time window of 10.5 seconds to 10.8 seconds (e.g., a 300ms window).

[0029] 2) Actively send the first heartbeat signal:

[0030] The at least one server is further configured to: set the trigger period of a timer within the at least one server according to the at least one time window; and send the first heartbeat signal to the target arbitration component within each trigger period.

[0031] Understandably, the server dynamically adjusts the trigger period of its internal timer by setting a time window, thereby controlling the frequency of sending heartbeat signals to the target arbitration component. For example, when two servers have just been deployed, the network environment is stable, and the system load is low, a longer time window can be set (such as assessing the network status every 60 seconds). In this case, the timer trigger period is set to send a heartbeat signal every 10 seconds. When network fluctuations are detected or a server experiences a slight response delay, the target arbitration component can automatically shorten the time window (such as assessing every 15 seconds) and adjust the timer trigger period to send a heartbeat every 5 seconds.

[0032] This application ensures that the target arbitration component can promptly detect the node's liveness status, while also reducing the consumption of network bandwidth and BMC processing resources.

[0033] Optionally, the target arbitration component is further configured to: determine that the first server's operating status is normal within the first time window when a first heartbeat signal is received from the first server among the plurality of servers within a first time window, wherein the at least one time window includes the first time window; determine a target number of times the second server's first heartbeat signal is not received within a second time window of the at least one time window when a first heartbeat signal is not received from the second server among the plurality of servers within a second time window of the at least one time window, wherein the multiple time windows of the first time period include the second time window; and determine that the second server's operating status is abnormal when the target number is determined to be greater than or equal to a preset number threshold, and identify the second server in the abnormal state as a faulty server.

[0034] Understandably, the target arbitration component can divide time into multiple consecutive time windows, each corresponding to a heartbeat detection cycle. For example, each time window can be set to 5 seconds, receiving the first heartbeat signal from the server every 5 seconds. When the first server successfully sends a heartbeat signal within a certain time window (e.g., 10:00:00–10:00:05) and it is received by the target arbitration component, the target arbitration component determines that the server is in normal operating condition within that window.

[0035] If the second server fails to send a first heartbeat signal within another time window (e.g., 10:00:30–10:00:35), the target arbitration component will not immediately determine it as a fault, but will instead enter the cumulative statistics phase. The target arbitration component will backtrack to a preset first time period, such as 30 seconds, which contains 6 time windows (each 5 seconds). If the second server's heartbeat signal is not received 4 times within these 6 windows, the cumulative target count is 4.

[0036] At this point, the target arbitration component compares the target number of attempts with a preset threshold. Assuming the threshold is set to 3, meaning that an abnormality is determined only after three consecutive or cumulative absences of heartbeats, four attempts exceed the threshold. Therefore, the target arbitration component confirms that the server has been continuously disconnected during this first time period, its operational status is abnormal, and it is subsequently marked as a faulty server.

[0037] This application ensures that occasional anomalies such as network jitter, brief process blockages, and electromagnetic interference will not lead to unintended shutdowns or failovers. Arbitration is only triggered when there is a continuous loss of connection over multiple consecutive time windows, significantly reducing the false failure rate.

[0038] Optionally, the target arbitration component is further configured to: upon determining that there are normal servers and faulty servers among the plurality of servers, send a remote shutdown command to the faulty server to shut down the faulty server; determine the target server among the normal servers among the plurality of servers, and send a first notification message to the target server to enable the target server to perform a data migration operation on the faulty server, wherein the first notification message is a message notifying the normal servers among the plurality of servers that the faulty server has been shut down.

[0039] Understandably, after identifying a faulty server, the target arbitration component will not immediately notify other nodes to perform data migration. Instead, it will prioritize sending a remote shutdown command to the faulty server. This remote shutdown command is issued via the IPMI protocol built into the BMC, directly affecting the faulty server's hardware power management module, forcibly cutting off its system power supply or triggering a safe shutdown process. For example, if a server becomes unresponsive due to kernel deadlock or network isolation, but its BMC still maintains communication capabilities, the target arbitration component can immediately send a remote shutdown command to that server's BMC, ensuring its operating system completely stops running and preventing it from continuously occupying shared storage resources or causing data write conflicts due to a seemingly dead state.

[0040] After the failed server is successfully shut down, the target arbitration component immediately selects one of the remaining healthy servers as the target server and sends it a first notification message. The first notification message does not contain complex control commands; it only clearly conveys the status change information that the failed node has gone offline and been forcibly shut down. For example, when server A is a failed node and is shut down, the arbitration component sends a structured notification to server B. Upon receiving this notification, server B immediately triggers the resource reconstruction process of its local hyperconverged platform, such as activating virtual machine replicas, rebuilding distributed storage volumes, and updating cluster configuration tables, thereby achieving automatic business recovery.

[0041] Optionally, the target server is further configured to: upon receiving the first notification message, read the disk image corresponding to the faulty server from the shared memory of the plurality of servers, and migrate the virtual machine services corresponding to the faulty server to the target server according to the disk image.

[0042] Understandably, when the target server receives a notification from the target arbitration component that the failed server has been shut down, it will proactively read the disk image corresponding to the failed node from the cluster's shared storage and automatically migrate and restore the virtual machine's services based on this image. The disk image is a complete snapshot of the virtual machine, containing the operating system, applications, configuration files, and user data, and is the sole data source for service recovery. For example, suppose the system consists of two hyperconverged servers: Server A and Server B, sharing a software-defined distributed storage pool. Server A runs a critical business virtual machine VM1, whose operating system, application data, and configuration are stored in shared storage as disk image files (e.g., VM1.qcow2), and a synchronized copy of this image file is also maintained on Server B. When Server A is determined to be faulty and remotely shut down by the BMC arbitration component due to system crash or network isolation, Server B receives the first notification message that Server A is offline. At this moment, server B does not need to wait for user instructions. It immediately starts the recovery module of the local hyperconverged platform, scans the disk image files associated with server A in the shared storage, locates the latest image version of VM1, loads the image locally, creates a new virtual machine instance VM1_new, and automatically restores the network configuration, storage mount relationship and resource quota, so that the business can be brought back online within seconds.

[0043] Through the above technical solution, because the virtual machine's disk image is always kept synchronized and updated in shared storage, the target server reads the latest image version written before the failure, ensuring the integrity of the business state. Even if server A has non-persistent memory data at the moment of the crash, the hyperconverged platform typically uses log writing or cache synchronization mechanisms to ensure data consistency and avoid the loss of critical business data.

[0044] Optionally, the target arbitration component is further configured to, upon determining that there are normal servers and faulty servers among the plurality of servers, send a remote restart command to the faulty server to restart the faulty server, and to determine the target server among the normal servers among the plurality of servers and send a second notification message to the target server, wherein the second notification message is a message notifying the target server that the faulty server is restarting; the target server is configured to, upon receiving the second notification message, perform the data migration operation on the faulty server to manage the services managed by the faulty server; the target arbitration component is further configured to, upon determining that a third heartbeat signal sent by the faulty server is received within a second time period after sending the remote restart command, send a stop command to the target server to cause the target server to stop performing the data migration operation.

[0045] Understandably, when the target arbitration component detects that a server (such as server A) has failed to return a heartbeat signal for multiple consecutive time windows, and the cumulative number of failures reaches a preset threshold, it determines that the server is faulty. In this case, the arbitration component does not immediately notify other servers to take over the service. Instead, it sends a remote restart command to the faulty server's BMC (triggers a hardware-level reset via the IPMI protocol). The remote restart operation does not require operating system involvement; even if the server becomes completely unresponsive due to kernel crashes, driver deadlocks, or memory leaks, a hardware-level restart can still be achieved by forcibly powering down and then powering on again through the BMC.

[0046] Simultaneously with issuing the restart command, the target arbitration component immediately sends a second notification message to another normally functioning server (such as server B), stating "The faulty node is restarting." Upon receiving the second notification message, server B detects a potential risk to the system, monitors the virtual machine status in shared storage, reserves resources, and prepares a takeover contingency plan.

[0047] Subsequently, the target arbitration component enters a second observation period, which can be set to 60 to 120 seconds, sufficient to cover the firmware initialization, BIOS self-test, and operating system boot process of most servers. If, during the second period, the target arbitration component receives the third heartbeat signal again from the faulty server (Server A), it indicates a successful reboot and the system has returned to normal operation. At this point, the target arbitration component immediately sends a stop command to Server B, causing the second server to halt all data migration operations in preparation, avoiding unnecessary resource consumption and business redundancy.

[0048] Optionally, the target arbitration component is further configured to: trigger a self-reset operation when it is determined that all of the plurality of servers are faulty servers, so as to reset the manager configured with the target arbitration component in at least one server.

[0049] The target arbitration component is further configured to: determine whether a fourth heartbeat signal sent by the plurality of servers is received during a third time period if the manager has been reset, and to perform secondary arbitration on the plurality of servers based on the reception status of the fourth heartbeat signal received during the third time period.

[0050] Understandably, when two servers (or multiple servers) fail to respond to heartbeats for an extended period, the target arbitration component determines this as "both nodes are abnormal" based on preset rules. Without intervention, the hyperconverged system will enter a suspended state, resulting in complete service interruption. Therefore, the target arbitration component initiates a self-healing process: it performs a soft reset (e.g., restarting the arbitration component process, refreshing the network stack, and clearing the heartbeat cache) and starts a timer for the third time period. This third time period can be set to 30 to 90 seconds, covering the complete cycle of server hardware power-on, BMC initialization, operating system boot, and hyperconverged service startup. During this third time period, the target arbitration component continuously listens for a fourth heartbeat signal from the two servers. If one or both servers resume heartbeats within this window, it indicates that the previous "dual failure" was a misjudgment due to synchronization anomalies, such as: both servers restarting simultaneously due to power fluctuations; the network switch briefly losing power and then reconnecting, causing heartbeat packets to be delayed due to network latency; or the hyperconverged platform briefly pausing heartbeat transmission during upgrades or configuration changes.

[0051] To better understand the process of the arbitration system described above, the implementation architecture of the arbitration system will be further described below with reference to optional embodiments, but this is not intended to limit the technical solutions of the embodiments of this application.

[0052] To ensure system reliability and consistency, the mainstream deployment method for hyperconverged systems in related technologies is still a three-node deployment. However, in some application scenarios, the utilization requirements for computing and storage resources are not high, but system reliability and consistency are still required. To lower the deployment threshold of hyperconverged systems, a two-node plus arbitrator node deployment method has emerged. However, the arbitrator node in this method is mostly an arbitrator box or PC, and other hardware facilities are also required. The Baseboard Management Controller (BMC) built into the server itself is a management chip on the server motherboard, configured with corresponding memory and hard disk resources, responsible for monitoring and controlling the server's operating status. Since the BMC is usually independent of the server's operating system, it can continue to operate even if the server fails.

[0053] Figure 2 It is a hyperconverged minimal deployment topology diagram in related technologies, such as Figure 2 As shown:

[0054] The mainstream approach to minimal hyperconverged infrastructure (HCI) deployment in related technologies still uses low-spec servers, PCs, or arbitration boxes (similar to the lowest-spec PCs) as arbitration nodes to achieve a 2+1 deployment. The other two nodes provide the computing and storage resources required after the HCI deployment is complete. Specifically, HCI Server 1 and HCI Server 2, along with the PC / box (arbitration box), are connected to the management network switch. The HCI Server's management port and the PC or box's network port are connected to the management network, achieving a three-node deployment in a practical sense. However, this technical solution leads to resource waste and increased costs.

[0055] To address the aforementioned issues, this application proposes an optional embodiment of a hyperconverged minimal deployment method based on a server-side BMC as the arbitration node. This method leverages the BMC as an independent minimal system with its complete hardware resources to meet the hardware requirements of the arbitration node. Simultaneously, it fully utilizes the BMC's server maintenance and operation functions to directly recover from abnormal scenarios. Specifically:

[0056] Figure 3 This is a framework diagram of a hyperconverged minimal deployment system based on a server BMC as the arbitration node, according to an optional embodiment of this application. Figure 3 As shown:

[0057] Two hyperconverged servers (i.e., multiple servers) serve as two physical nodes in the hyperconverged system.

[0058] Each hyperconverged server contains: BMC, SERVER, Central Processing Unit (CPU), Memory (MEM), Redundant Array of Independent Disks (RAID), Solid State Drive (SSD), Hard Disk Drive (HDD), and Network Interface Card (NIC).

[0059] Each BMC on a hyperconverged server can be configured with an arbitration component. One of the BMCs on the hyperconverged server can be selected as the third node (arbitration node). All three nodes can communicate with the management network switch through their respective independent network cards.

[0060] Figure 4 This is a flowchart of a hyperconverged minimal deployment method based on a server BMC as the arbitration node, according to an optional embodiment of this application, applied to... Figure 3 In the system, such as Figure 4As shown:

[0061] Step S401, hyperconverged server deployment;

[0062] Two hyperconverged servers are used to deploy hyperconverged software and configure network information.

[0063] Enables the registration and integration of the BMC system in the hyperconverged environment, and displays it as a node in the hyperconverged system, with information such as the node's unique identifier and IP address.

[0064] Step S402, BMC initialization configuration;

[0065] Initialize and configure the BMC (Browser Management Center) of the two hyperconverged servers, including network configuration. Ensure communication with the management network of the two hyperconverged nodes. Install the arbitration component into the BMC system and configure the IP information of the hyperconverged nodes to communicate with it. The BMC system will be in a running state from the moment the servers are powered on.

[0066] Step S403, Arbitration component configuration;

[0067] Arbitration components are installed in both BMC systems, and the network information configured on the two hyperconverged servers is recorded in the arbitration components.

[0068] The arbitration component can perform abnormal scenario maintenance based on the results of heartbeat detection of the hyperconverged node status. When abnormal scenarios such as operating system freeze, apparent death, or network interruption are detected in the hyperconverged node, the abnormal node can be remotely powered on, powered off, or restarted through the Intelligent Platform Management Interface (IPMI) command.

[0069] Step S404: Build the hyperconverged system;

[0070] A hyperconverged system is built using the network and disk resources of two hyperconverged servers.

[0071] Step S405: Register the BMC arbitration node for hyperconverged infrastructure;

[0072] Select one of the two BMCs as the arbitration node (the arbitration component that serves as the arbitration node is the target arbitration component), register and add the arbitration node in the hyperconverged system, so that it can be displayed as a three-node system together, and start the arbitration function of the arbitration node.

[0073] This means that the arbitration component running on the BMC system implements the arbitration function for hyperconverged nodes through heartbeat detection. The arbitration component performs heartbeat detection on the hyperconverged nodes recorded, including the sending of heartbeat packets and the recording of the heartbeat response time. The BMC system performs arbitration based on the heartbeat detection results, including determining the status of the node (normal, abnormal, etc.), and notifies the hyperconverged node of the arbitration result by sending a notification message.

[0074] Step S406: Minimum deployment complete.

[0075] Complete the "2+1" minimal deployment of hyperconverged infrastructure.

[0076] In other words, firstly, the necessary network configuration and arbitration component installation of the server's BMC are required to ensure it can fulfill the role of an arbitration node. Secondly, the network IP of the hyperconverged server node is recorded on the arbitration component. The arbitration algorithm runs normally on the BMC system through the arbitration component. The two hyperconverged server nodes send heartbeat information periodically, and the arbitration node can make arbitration decisions according to predetermined rules. Then, the BMC needs to be integrated into the hyperconverged system, and this node needs to be marked as the arbitration node in the hyperconverged system. The hyperconverged system needs to support modifying system configuration files and adding BMC support. Finally, for hyperconverged server nodes that are detected as abnormal, the arbitration node notifies the peer BMC or the current BMC to perform node maintenance operations (shutdown, restart, etc.) by setting timeout times.

[0077] The arbitration algorithm is implemented as follows: the hyperconverged server node periodically sends a heartbeat signal to the BMC arbitration node (e.g., once every 5 seconds). If no response is received after the set timeout period (e.g., 10 seconds), the target node is considered to be faulty. Receiving a heartbeat indicates that the node is alive. If no heartbeat is received, the arbitration process is initiated. The fault is further confirmed by combining the cumulative failure detection (the percentage of timeouts within the statistical period).

[0078] If one of the two hyperconverged server nodes is normal and the other is faulty, maintenance operations (shutdown or restart) are performed on the faulty node, and the normal node takes over the services of the faulty node to ensure business continuity.

[0079] If both hyperconverged server nodes are detected as faulty nodes, the BMC of the arbitration node will be reset. If the heartbeat information of both hyperconverged server nodes is still abnormal after the reset, no action will be taken.

[0080] In one optional embodiment, the hyperconverged minimal deployment method based on the server BMC as the arbitration node can be implemented as follows:

[0081] Two hyperconverged servers are deployed with hyperconverged software, configured with IP addresses 192.168.1.1 and 192.168.1.2. The BMC (Browser Management Center) of both hyperconverged servers is initialized and configured, with Internet Protocol (IP) settings of 192.168.1.3 and 192.168.1.4. Arbitration components are installed in both BMC systems, and the network information configured on the two hyperconverged servers (192.168.1.1 and 192.168.1.2) is recorded in the arbitration components of the two BMCs. The hyperconverged system is built on nodes 192.168.1.1 and 192.168.1.2, with 192.168.1.3 selected as the arbitration node. The arbitration node is registered and added to the hyperconverged system, enabling it to be displayed as a three-node system. The arbitration function is then activated, completing the minimal deployment.

[0082] In summary, the optional embodiments of this application include a BMC arbitration initialization module, an arbitration algorithm module, a hyperconverged infrastructure configuration module, and a BMC maintenance control module. The BMC arbitration initialization module initializes the BMC system and installs the arbitration component, sets network parameters such as the BMC IP address, gateway, and subnet mask to ensure communication with the management network of the two hyperconverged nodes, installs the arbitration component into the BMC system, and sets the IP information of the hyperconverged nodes with which it communicates. The BMC system remains in a running state from the moment the server is powered on. The arbitration algorithm module runs on the arbitration component within the BMC system, implementing arbitration functionality for the hyperconverged nodes through heartbeat detection. The hyperconverged infrastructure configuration module registers and integrates the BMC system within the hyperconverged environment, displaying it as a node with a unique identifier and IP address. The BMC maintenance control module performs maintenance for abnormal scenarios based on the hyperconverged node status detected by heartbeat detection, including remote power-on, power-off, and restart.

[0083] Through the optional embodiments of this application, the BMC system, independent of the server's operating system and continuously running upon power-on, provides a foundation for hyperconverged node arbitration. By using the server's BMC system as the arbitration node for a two-node hyperconverged system, and combining it with the arbitration algorithm, a two-node deployment of the hyperconverged system is achieved. Furthermore, when the arbitration detects an anomaly in a hyperconverged node, the maintenance and operation capabilities of the BMC can be fully utilized to directly perform shutdown or restart operations on the abnormal hyperconverged node, thereby achieving system recovery.

[0084] Figure 5 This is a flowchart of an arbitration method according to an embodiment of this application; as follows: Figure 5As shown, this method is applied to a target arbitration component, wherein the target arbitration component is installed inside at least one of a plurality of servers connected via a switch, and includes the following process:

[0085] Step S502: Receive the first heartbeat signal sent by the plurality of servers based on at least one time window, and monitor the operating status of the plurality of servers according to the reception status of the first heartbeat signal received within the at least one time window;

[0086] Step S504: Determine whether there is a faulty server among the plurality of servers based on the operating status, and if it is determined that there is a faulty server among the plurality of servers, determine a target server among the plurality of servers, wherein the target server is used to perform data migration operation on the faulty server, and the target server is a server whose operating status is normal.

[0087] In this application, multiple servers are connected via a switch, and at least one of the servers has a target arbitration component installed internally. The method of this application embodiment can receive first heartbeat signals sent by multiple servers based on at least one time window, and monitor the operating status of the multiple servers based on the reception of the first heartbeat signals within the at least one time window; if it is determined based on the operating status that a faulty server exists among the multiple servers, a target server is identified among the multiple servers, so that the target server performs a data migration operation on the faulty server. That is, this application can achieve arbitration operations on multiple servers through multiple servers and a target arbitration component installed internally in at least one server. According to this application, the resource waste caused by the need for at least three nodes, including a PC or arbitration box, in hyperconverged systems in related technologies can be solved, thereby achieving arbitration only through multiple servers and a target arbitration system installed internally in at least one server, saving resources.

[0088] In an exemplary embodiment, step S502 above, which involves receiving the first heartbeat signal sent by the plurality of servers based on at least one time window, further includes: sending a second heartbeat signal to at least one server at a first time point, so that the at least one server, upon receiving the second heartbeat signal, sends a response signal to the target arbitration component within the time window corresponding to the first time point, wherein the first heartbeat signal includes the response signal, and the at least one time window includes the time window corresponding to the first time point.

[0089] In an exemplary embodiment, step S504, which determines whether there is a faulty server among the plurality of servers based on the operating state, further includes: if a first heartbeat signal is received from a first server among the plurality of servers within a first time window, determining that the operating state of the first server within the first time window is normal, wherein the at least one time window includes the first time window; if no first heartbeat signal is received from a second server among the plurality of servers within a second time window of the at least one time window, determining a target number of times that the first heartbeat signal is not received from the second server within a plurality of time windows in a first time period, wherein the plurality of time windows in the first time period includes the second time window; and if the target number is determined to be greater than or equal to a preset number threshold, determining that the operating state of the second server is abnormal, and identifying the second server in the abnormal state as a faulty server.

[0090] In one exemplary embodiment, the method further includes: if it is determined that there are normal servers and faulty servers among the plurality of servers, sending a remote shutdown command to the faulty server to shut down the faulty server; determining the target server among the normal servers among the plurality of servers, and sending a first notification message to the target server to cause the target server to perform a data migration operation on the faulty server, wherein the first notification message is a message notifying the normal servers among the plurality of servers that the faulty server has been shut down.

[0091] In one exemplary embodiment, the method further includes: if it is determined that there are normal servers and faulty servers among the plurality of servers, sending a remote restart command to the faulty server to restart the faulty server; and determining the target server among the normal servers among the plurality of servers and sending a second notification message to the target server, so that the target server can perform the data migration operation on the faulty server upon receiving the second notification message, in order to manage the services managed by the faulty server, wherein the second notification message is a message notifying the target server that the faulty server is restarting; and if a third heartbeat signal sent by the faulty server is received within a second time period after the remote restart command is sent, sending a stop command to the target server, so that the target server stops performing the data migration operation.

[0092] In one exemplary embodiment, the method further includes: if it is determined that all of the plurality of servers are faulty servers, triggering a self-reset operation to reset the manager configured with the target arbitration component in at least one server.

[0093] In one exemplary embodiment, the method further includes: if it is determined that the manager has completed a reset, determining whether a fourth heartbeat signal sent by the plurality of servers is received within a third time period, and performing secondary arbitration on the plurality of servers based on the reception status of the fourth heartbeat signal received within the third time period.

[0094] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps described in the arbitration method embodiments above.

[0095] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute the steps described in the arbitration method embodiments above.

[0096] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0097] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the above-described arbitration method embodiments.

[0098] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the arbitration method embodiments above.

[0099] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0100] The arbitration system and arbitration method provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. An arbitration system, characterized in that, include: Multiple servers are connected via a switch, and at least one of these servers has a target arbitration component installed internally, wherein: The target arbitration component is configured to receive a first heartbeat signal sent by the plurality of servers based on at least one time window, and monitor the operating status of the plurality of servers based on the reception status of the first heartbeat signal within the at least one time window; determine whether there is a faulty server among the plurality of servers based on the operating status, and if a faulty server is determined among the plurality of servers, determine a target server among the plurality of servers, wherein the target server is configured to perform data migration operation on the faulty server, and the target server is a server whose operating status is normal.

2. The arbitration system according to claim 1, characterized in that, The at least one server is used for: Upon receiving the second heartbeat signal sent by the target arbitration component at a first time point, a response signal is sent to the target arbitration component within the time window corresponding to the first time point, wherein the first heartbeat signal includes the response signal, and the at least one time window includes the time window corresponding to the first time point.

3. The arbitration system according to claim 1, characterized in that, The at least one server is also used for: The trigger period of the timer in the at least one server is set according to the at least one time window; The first heartbeat signal is sent to the target arbitration component during each trigger cycle.

4. The arbitration system according to claim 1, characterized in that, The target arbitration component is also used for: If a first heartbeat signal is received from the first server among the plurality of servers within a first time window, the operating status of the first server within the first time window is determined to be normal, wherein the at least one time window includes: the first time window; If a first heartbeat signal is not received from the second server among the plurality of servers within a second time window of the at least one time window, a target number of times the first heartbeat signal is not received from the second server within a plurality of time windows in a first time period is determined, wherein the plurality of time windows in the first time period include: the second time window; If the target number of times is determined to be greater than or equal to a preset number of times threshold, the operating state of the second server is determined to be abnormal, and the second server in the abnormal state is determined to be a faulty server.

5. The arbitration system according to claim 1, characterized in that, The target arbitration component is also used for: If it is determined that there are normal servers and faulty servers among the plurality of servers, a remote shutdown command is sent to the faulty server to shut it down; The target server is determined from the normal servers among the plurality of servers, and a first notification message is sent to the target server to enable the target server to perform a data migration operation on the faulty server, wherein the first notification message is a message notifying the normal servers among the plurality of servers that the faulty server has been shut down.

6. The arbitration system according to claim 5, characterized in that, The target server is also used for: Upon receiving the first notification message, the disk image corresponding to the faulty server is read from the shared memory of the plurality of servers, and the virtual machine service corresponding to the faulty server is migrated to the target server according to the disk image.

7. The arbitration system according to claim 1, characterized in that, include: The target arbitration component is further configured to, when determining that there are normal servers and faulty servers among the plurality of servers, send a remote restart command to the faulty server to restart the faulty server, and determine the target server among the normal servers among the plurality of servers and send a second notification message to the target server, wherein the second notification message is a message notifying the target server that the faulty server is restarting; The target server is configured to perform the data migration operation on the faulty server upon receiving the second notification message, so as to manage the services managed by the faulty server. The target arbitration component is further configured to send a stop command to the target server if it receives a third heartbeat signal from the faulty server within a second time period after determining that the remote restart command has been sent, so that the target server stops performing the data migration operation.

8. The arbitration system according to claim 1, characterized in that, The target arbitration component is also used for: If it is determined that all of the servers are faulty servers, a self-reset operation is triggered to reset the manager of at least one server that is configured with the target arbitration component.

9. The arbitration system according to claim 8, characterized in that, The target arbitration component is also used for: If it is determined that the manager has been reset, it is determined whether a fourth heartbeat signal sent by the plurality of servers is received within the third time period, and a second arbitration is performed on the plurality of servers based on the reception status of the fourth heartbeat signal received within the third time period.

10. An arbitration method, characterized in that, An application to a target arbitration component, wherein the target arbitration component is installed inside at least one of a plurality of servers connected via a switch, including: The system receives first heartbeat signals sent by the plurality of servers based on at least one time window, and monitors the operating status of the plurality of servers based on the reception status of the first heartbeat signals received within the at least one time window. Based on the operating status, determine whether there is a faulty server among the plurality of servers, and if it is determined that there is a faulty server among the plurality of servers, determine a target server among the plurality of servers, wherein the target server is used to perform data migration operation on the faulty server, and the target server is a server whose operating status is normal.

Images