A method, system, terminal and storage medium for maintaining a consensus cluster majority in a two-node cluster using migratable virtual consensus nodes

Abstract

The present application relates to the field of distributed consensus and high-availability cluster, and discloses a method, system, terminal and storage medium for maintaining a consensus cluster majority in a two-node cluster by using a migratable virtual consensus node, the method comprising: deploying a first consensus node on a first physical node, deploying a second consensus node on a second physical node, creating a virtual consensus node, saving the persistent state of the virtual consensus node to shared storage of the first and second physical nodes; forming a logical consensus cluster from the first consensus node, the second consensus node and the virtual consensus node; detecting a failure state of a current running host of the virtual consensus node, and when a failure of the host is detected, migrating or restarting the virtual consensus node on another surviving physical node according to the persistent state saved in the shared storage. The present application can maintain a majority consensus in a two-node system without adding a fixed third physical node.

Description

Technical Field

[0001] This invention relates to the field of distributed consensus and high-availability cluster technology, and in particular to a method, system, terminal, and computer-readable storage medium for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes. Background Technology

[0002] In distributed systems, distributed consensus algorithms and their variants typically rely on a majority of members to select the master node, commit writes, and change member configurations. To maintain a majority, the industry usually deploys an odd number of consensus members. However, dual-controller storage devices and some dual-machine server products are often limited by hardware form factor, cost, space, power consumption, or operational complexity, and often only have two physical nodes. Therefore, dual-controller storage devices are the preferred application in this application.

[0003] In scenarios with only two physical nodes, if the consensus service is run on each node separately, the system struggles to maintain majority commit conditions when either node fails or the link is interrupted. While existing technologies include witness disks, witness nodes, file witnesses, or cloud witnesses, these solutions tend to focus on cluster ownership determination or tie-breaking, failing to organically integrate consensus protocol state carrying, shared storage persistence, host migration switching, exclusive control, and recovery migration. Therefore, they still suffer from insufficient protocol participation, poor state continuity, and inadequate split-brain protection.

[0004] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0005] The main objective of this invention is to provide a method, system, terminal, and computer-readable storage medium for maintaining a majority in a consensus cluster using a portable virtual consensus node. This invention aims to solve the technical problems in existing dual-physical-node systems, such as difficulty in maintaining majority submission conditions, the inability of traditional witness schemes to support consensus protocol states, and insufficient state continuity after failover.

[0006] To achieve the above objectives, the present invention provides a method for maintaining a majority in a consensus cluster using portable virtual consensus nodes in a two-node cluster. The method includes the following steps: Deploy the first consensus node on the first physical node and save the first primary persistent state of the first consensus node to the first local storage. Deploy a second consensus node on the second physical node and save the second primary persistent state of the second consensus node to the second local storage; Create a virtual consensus node and save the persistent state of the virtual consensus node to the shared storage of the first physical node and the second physical node; The virtual consensus node's running host is determined by the high availability management module. The running host is either the first physical node or the second physical node, and the virtual consensus node runs on the running host. The first consensus node, the second consensus node, and the virtual consensus node are logically formed into a three-member consensus cluster. The system detects the fault status of the current running host of the virtual consensus node. When a fault is detected in the current running host, the system migrates or restarts the virtual consensus node on another surviving physical node according to the persistent status stored in the shared storage. This allows the corresponding consensus node and the virtual consensus node to run simultaneously on the other physical node, thus satisfying the majority submission condition.

[0007] Optionally, in the method of maintaining a majority of consensus clusters in a dual-node cluster using portable virtual consensus nodes, the virtual consensus nodes operate in any of the following forms: virtual machine, container, process group, service unit, or lightweight protocol proxy. The virtual consensus node is a protocol participant with limited functionality, used to participate in control plane operations under normal operating conditions. The control plane operations include: master node selection, voting confirmation, log metadata maintenance, member change confirmation, or snapshot coordination. The logically defined three-member consensus cluster is a Raft cluster, a Paxos cluster, or a majority-based variant consensus cluster.

[0008] Optionally, the method for maintaining a majority of consensus in a dual-node cluster using a migrateable virtual consensus node, wherein detecting the failure state of the current running host of the virtual consensus node, and when a failure of the current running host is detected, migrating or restarting the virtual consensus node on another surviving physical node according to the persistent state stored in the shared storage, specifically includes: A heartbeat detection mechanism is established between the first physical node and the second physical node, and the status information of the peer physical node is periodically obtained based on the heartbeat detection mechanism. Based on the status information, it is determined whether the heartbeat of the currently running host responds normally within a preset time. If it does not respond normally within the preset time, it is determined that the heartbeat loss event has occurred in the currently running host. After determining the heartbeat loss event, a detection operation is performed, which includes: detecting whether the consensus node process on the currently running host has exited incorrectly, detecting whether the access path of the persistent state stored in the shared storage is interrupted, and detecting whether the currently running host meets the preset fault determination conditions. When at least one of the detection operations is true, it is confirmed that the current running host has failed, a failover trigger signal is generated, and the virtual consensus node is migrated or restarted according to the failover trigger signal. In the Corosync implementation scenario, the heartbeat detection mechanism performs the following steps based on token ring ordered broadcast and membership protocol: The communication processes running on the first physical node and the second physical node form a logical ring. The token is passed cyclically between the communication processes in the logical ring in a predetermined order. The communication process that receives the token sends a message to be broadcast and then continues to forward the token. If the communication process does not receive or successfully forward the token within a predetermined time, a retransmission operation is performed. If multiple retransmissions fail, the corresponding physical node is determined to be abnormal and the cluster membership is updated to periodically obtain the status information of the peer physical node.

[0009] Optionally, the method for maintaining a majority of consensus in a dual-node cluster using portable virtual consensus nodes, wherein the migration or restart of the virtual consensus node is performed according to the failover trigger signal, further includes the following prior steps: In response to the fault switching trigger signal, perform an exclusive ownership confirmation operation on the shared storage; The exclusive ownership confirmation operation includes: confirming whether the current running host has lost write access to the shared storage, confirming whether the current running host is offline, confirming whether the current running host has been isolated, and confirming whether the corresponding service instance on the current running host has been terminated; When at least one of the ownership confirmation operations is true, it is determined that the exclusive ownership of the shared storage has been transferred to another surviving physical node; After determining that the exclusive ownership has been transferred, an instruction is issued to migrate or restart the virtual consensus node; The exclusive ownership confirmation operation is performed using at least one of the following methods: SCSI persistent reservation confirmation, distributed lock confirmation, lease confirmation, or isolation control.

[0010] Optionally, the method for maintaining a majority of consensus in a two-node cluster using a portable virtual consensus node further includes, after migrating or restarting the virtual consensus node on the other surviving physical node: A recovery verification operation is performed based on the persistent state stored in the shared storage so that the recovered virtual consensus node meets the protocol continuity requirements. The persistent state includes at least one of the following: term state, voting state, member configuration state, log metadata, log index, snapshot metadata, and recovery checkpoint, and the virtual consensus node does not carry out external business requests for the complete log text and data plane. The recovery verification operation includes at least one of the following: log consistency check, snapshot consistency check, term status check, voting status check, or recovery checkpoint verification.

[0011] Optionally, the method for maintaining a majority of consensus clusters in a dual-node cluster using portable virtual consensus nodes, wherein the step of performing a recovery verification operation based on the persistent state stored in the shared storage to ensure that the recovered virtual consensus nodes meet protocol continuity requirements, further includes: Under normal system conditions, the first consensus node is run on the first physical node, the second consensus node is run on the second physical node, and the virtual consensus node is run on either the first physical node or the second physical node, so that the first consensus node, the second consensus node and the virtual consensus node form a logical three-member consensus cluster. When a failure of the currently running host is detected and the virtual consensus node has completed migration or restart on another surviving physical node, it enters a degraded state. In the degraded state, the virtual consensus node and the consensus node deployed on the other physical node are simultaneously run on the other physical node, so that the other physical node has at least two logical consensus members under the condition of a single physical node, so as to satisfy the majority submission condition.

[0012] Optionally, the method for maintaining a majority in a consensus cluster using portable virtual consensus nodes in a two-node cluster further includes: When the currently running host recovers from a failure, the health status of the recovered physical nodes is detected; When the health status meets the preset recovery conditions, perform status synchronization or environment verification, and generate status synchronization result or environment verification result. Based on the state synchronization result or the environment verification result, determine whether to migrate the virtual consensus node back to the recovered physical node based on the migration strategy. The migration strategy is determined by at least one of load balancing, physical node priority, fault history, network quality, shared storage path quality, or manual management strategy.

[0013] Furthermore, to achieve the above objectives, the present invention also provides a system for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes, wherein the system for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes includes: The first consensus node deployment module is used to deploy the first consensus node on the first physical node and save the first primary persistent state of the first consensus node to the first local storage. The second consensus node deployment module is used to deploy the second consensus node on the second physical node and save the second primary persistent state of the second consensus node to the second local storage. A virtual consensus node creation module is used to create virtual consensus nodes and save the persistent state of the virtual consensus nodes to the shared storage of the first physical node and the second physical node; wherein, the running host of the virtual consensus node is determined by the high availability management module, the running host is the first physical node or the second physical node, and the virtual consensus node runs on the running host; The consensus cluster construction module is used to form a logical three-member consensus cluster by connecting the first consensus node, the second consensus node, and the virtual consensus node. The fault detection and switching module is used to detect the fault status of the current running host of the virtual consensus node. When the fault of the current running host is detected, the virtual consensus node is migrated or restarted on another surviving physical node according to the persistent status saved in the shared storage, so that the corresponding consensus node and the virtual consensus node run simultaneously on the other physical node to meet the majority submission condition.

[0014] Furthermore, to achieve the above objectives, the present invention also provides a terminal, wherein the terminal includes: a memory, a processor, and a program stored in the memory and executable on the processor for maintaining a majority of consensus in a two-node cluster using portable virtual consensus nodes. When the program for maintaining a majority of consensus in a two-node cluster using portable virtual consensus nodes is executed by the processor, it implements the steps of the method for maintaining a majority of consensus in a two-node cluster using portable virtual consensus nodes as described above.

[0015] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a program for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes, and when the program for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes is executed by a processor, it implements the steps of the method for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes as described above.

[0016] In this invention, a first consensus node is deployed on a first physical node, and its first primary persistent state is saved to a first local storage. A second consensus node is deployed on a second physical node, and its second primary persistent state is saved to a second local storage. A virtual consensus node is created, and its persistent state is saved to the shared storage of the first and second physical nodes. The first, second, and virtual consensus nodes form a logical three-member consensus cluster. The failure status of the current running host of the virtual consensus node is detected. When a failure is detected in the current running host, the virtual consensus node is migrated or restarted on another surviving physical node according to the persistent state saved in the shared storage. This allows the corresponding consensus node and the virtual consensus node to run simultaneously on the other physical node, satisfying the majority commit condition. This invention achieves the technical effects of maintaining the continuity of the majority commit capability of the consensus cluster, reducing the risk of split-brain, and improving the availability of the control plane of dual-control devices without adding a fixed third physical node. Attached Figure Description

[0017] Figure 1 This is a flowchart of a preferred embodiment of the method of maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes according to the present invention; Figure 2 This is a technical schematic diagram of the method for maintaining a majority of consensus clusters in a dual-node cluster using portable virtual consensus nodes, as described in this invention. Figure 3 This is a schematic diagram of the normal state deployment of the method of maintaining the majority of consensus clusters in a two-node cluster using portable virtual consensus nodes according to the present invention. Figure 4 This is a shared storage exclusive control timing diagram of the method for maintaining a majority of consensus clusters in a dual-node cluster using portable virtual consensus nodes, as described in this invention. Figure 5 This is a schematic diagram of single-node failover for the method of maintaining a majority of consensus clusters in a two-node cluster using a portable virtual consensus node, as described in this invention. Figure 6This is a structural diagram of a preferred embodiment of the system of the present invention that utilizes portable virtual consensus nodes to maintain the majority of consensus clusters in a two-node cluster; Figure 7 This is a structural diagram of a preferred embodiment of the terminal of the present invention. Detailed Implementation

[0018] This application provides a method, system, and terminal for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes. To make the objectives, technical solutions, and effects of this application clearer and more explicit, the following detailed description is provided with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit this application.

[0019] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0020] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0021] In existing dual-controller systems, if only two consensus members are deployed on two physical nodes respectively, the remaining nodes will struggle to meet the majority requirement when either node fails, impacting control plane operations such as configuration writing, metadata updates, lease renewals, and primary / standby switching. Existing witness disks or witness nodes primarily serve cluster ownership determination rather than acting as protocol-level consensus participants and state bearers, thus exhibiting shortcomings in consensus protocol continuity, state recovery integrity, and protocol context continuation after migration. The preferred embodiment of this invention describes a method for maintaining a consensus cluster majority in a dual-node cluster using portable virtual consensus nodes, such as... Figure 1 and Figure 2 As shown, the method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes includes the following steps: Step S10: Deploy the first consensus node on the first physical node and save the first primary persistent state of the first consensus node to the first local storage.

[0022] In this embodiment, the first consensus node (R1) operates as a protocol instance fixedly bound to the first physical node. The first consensus node can be a fully functional node participating in Raft, Paxos (Raft and Paxos are distributed consensus algorithms) or their variants, and its primary persistent state is stored in the first local storage of the first physical node. The first local storage is a storage medium built into the first physical node, such as a local SSD (Solid State Drive), NVMe (Non-Volatile Memory Express) disk, SAS (Serial Attached SCSI), SCSI (Small Computer System Interface) disk, or a logical volume. The first primary persistent state includes complete logs, term information, voting information, and snapshot information to ensure that the first consensus node can restore the complete protocol context from local storage after a process restart or physical node restart.

[0023] Furthermore, the first consensus node writes the complete logs to the first local storage and saves the member configuration image in the first local storage so as to quickly obtain the cluster member view when the node recovers.

[0024] Step S20: Deploy the second consensus node on the second physical node and save the second primary persistent state of the second consensus node to the second local storage.

[0025] In this embodiment, the second consensus node (R2) operates as a protocol instance fixedly bound to the second physical node, forming a dual-physical-node deployment architecture with the first consensus node. The primary persistent state of the second consensus node is stored in the second local storage of the second physical node. The second local storage is a built-in storage medium of the second physical node, such as a local SSD, NVMe disk, SAS disk, or logical volume, and is independent of the first local storage. The second primary persistent state also includes complete logs, term information, voting information, and snapshot information to ensure that the second consensus node can independently recover the protocol state.

[0026] It is evident that the first consensus node and the second consensus node rely on the local storage of their respective physical nodes to achieve state persistence, without relying on shared storage as their primary persistence medium, thus forming the basis of a hybrid persistence architecture that combines local storage and shared storage.

[0027] Step S30: Create a virtual consensus node and save the persistent state of the virtual consensus node to the shared storage of the first physical node and the second physical node; wherein, the running host of the virtual consensus node is determined by the high availability management module, the running host is the first physical node or the second physical node, and the virtual consensus node runs on the running host.

[0028] In this embodiment, a virtual consensus node (R3) is created as a logical third consensus member. Unlike the first and second consensus nodes, which are fixedly bound to the first and second physical nodes respectively, the virtual consensus node does not correspond to any fixed physical server. The persistent state of the virtual consensus node is stored in shared storage, which can be accessed by both the first and second physical nodes.

[0029] Furthermore, the virtual consensus node is a protocol participant with limited functionality, used to participate in control plane operations under normal operating conditions. The control plane operations include: master node selection, voting confirmation, log metadata maintenance, member change confirmation, or snapshot coordination. The logically defined three-member consensus cluster is a Raft cluster, a Paxos cluster, or a majority-based variant consensus cluster.

[0030] In this embodiment, the virtual consensus node is configured as a protocol participant with limited functionality, distinguishing it from the first and second consensus nodes. The limited functionality means that the virtual consensus node only participates in the core operations necessary for the operation of the control plane protocol, without carrying out external business services in the data plane. Specifically, the control plane operations include at least one of the following: master node selection, vote confirmation, log metadata maintenance, member change confirmation, and snapshot coordination. For example, during the master node selection process, the virtual consensus node receives candidate requests, compares terms, and casts its vote according to protocol rules; its voting status is saved in a persistent state in shared storage. During the vote confirmation process, the virtual consensus node confirms the majority of log entries submitted by the master node, recording the submitted positions through persistent log metadata and log indexes.

[0031] Furthermore, taking a Raft cluster as an example, the first consensus node, the second consensus node, and the virtual consensus node together constitute a three-member Raft group. The virtual consensus node participates in election and log confirmation as a follower or candidate, but does not act as the master node to handle client write requests. For other variant protocols based on majority voting, the technical solution of this embodiment can also be applied simply by adapting the state structure and interaction logic of the virtual consensus node to the equivalent fields and processes of the corresponding protocol.

[0032] Furthermore, the shared storage can be shared block storage, specifically a shared SAS storage medium, a shared NVMe storage medium, or a shared logical volume built based on the aforementioned media.

[0033] The persistent state includes at least one of the following: term state, voting state, member configuration state, log metadata, log index, snapshot metadata, and recovery checkpoint. The virtual consensus node only stores the above-mentioned protocol metadata and does not store the complete business log text, thereby reducing the write load on shared storage while ensuring protocol continuity.

[0034] Furthermore, the host for the virtual consensus node is determined by the high availability management module. The high availability management module can select the host based on at least one of the following: node health status, resource occupancy status, preset priority, network link status, or shared storage path status. The high availability management module can be implemented using Pacemaker, CRM (Cluster Resource Manager), Corosync (Pacemaker, CRM, and Corosync are all cluster resource managers), or equivalent failover management software. After the host is determined, the virtual consensus node runs on the determined host and at any given time only runs on either the first physical node or the second physical node.

[0035] It is understood that in another implementation, the virtual consensus node runs as a virtual machine, with its disk image or state file stored in the shared storage. Alternatively, the virtual consensus node runs as a container, process group, service unit, or lightweight protocol proxy, with its persistent state stored in the shared storage via a file system or block device interface.

[0036] Step S40: Form a logical three-member consensus cluster by connecting the first consensus node, the second consensus node, and the virtual consensus node.

[0037] In this embodiment, based on the already deployed first consensus node, second consensus node, and the virtual consensus node with a determined running host, the three are logically assembled into a three-member consensus cluster (e.g., ...) through a consensus protocol. Figure 3(As shown). The logical three-member consensus cluster refers to a cluster with three valid protocol members from the perspective of the consensus protocol, capable of master node selection, log submission, and member configuration changes based on a majority vote mechanism. However, at the physical deployment level, these three logical members are only carried by two physical nodes: the first physical node and the second physical node. The first consensus node is fixed to run on the first physical node, and the second consensus node is fixed to run on the second physical node. The virtual consensus node runs on either the first or second physical node, depending on the determination of the high availability management module.

[0038] In other words, the logically three-member consensus cluster, under normal conditions, consists of three logical consensus members shared by two physical nodes. Virtual consensus nodes, as participants in the restricted-function protocol, participate in master node selection, voting confirmation, log metadata maintenance, configuration change confirmation, and snapshot coordination. They only participate in the majority-pledge-related processes in the control plane and do not directly handle external business requests from the data plane.

[0039] Taking the Raft protocol as an example, the first consensus node, the second consensus node, and the virtual consensus node each have independent member identifiers. During cluster startup or member changes, they identify each other and establish communication relationships through a configuration change protocol, forming a three-member Raft group. Within this group, any member can become a master node, follower, or candidate. The three members jointly maintain the term number and log index. The master node needs to obtain log replication confirmation from at least two members, including itself, before it can submit log entries. Since the first physical node and the second physical node respectively host the first consensus node and the second consensus node, and the virtual consensus node is hosted by one of them, under normal system conditions, the two physical nodes jointly host the logical three-member consensus cluster.

[0040] It is understandable that in another implementation, the logical three-member consensus cluster is a variant consensus cluster based on majority voting, with three members and a majority threshold of two, and virtual consensus nodes participate in voting and confirmation in a manner defined by the protocol.

[0041] Step S50: Detect the fault status of the current running host of the virtual consensus node. When the fault of the current running host is detected, according to the persistent status saved in the shared storage, migrate or restart the virtual consensus node on another surviving physical node, so that the corresponding consensus node and the virtual consensus node run simultaneously on the other physical node to meet the majority submission condition.

[0042] The process of detecting the fault status of the current running host of the virtual consensus node, and when a fault is detected in the current running host, migrating or restarting the virtual consensus node on another surviving physical node according to the persistent state stored in the shared storage, specifically includes: A heartbeat detection mechanism is established between the first physical node and the second physical node, and the status information of the peer physical node is periodically obtained based on the heartbeat detection mechanism. Based on the status information, it is determined whether the heartbeat of the currently running host responds normally within a preset time. If it does not respond normally within the preset time, it is determined that the heartbeat loss event has occurred in the currently running host. After determining the heartbeat loss event, a detection operation is performed, which includes: detecting whether the consensus node process on the currently running host has exited incorrectly, detecting whether the access path of the persistent state stored in the shared storage is interrupted, and detecting whether the currently running host meets the preset fault determination conditions. When at least one of the detection operations is true, it is confirmed that the currently running host has failed, a failover trigger signal is generated, and the virtual consensus node is migrated or restarted according to the failover trigger signal.

[0043] In this embodiment, a heartbeat detection mechanism is established between the first physical node and the second physical node. This heartbeat detection mechanism is used to periodically acquire the status information of the peer physical node. The status information includes, but is not limited to, whether the peer physical node is alive, whether the consensus node process running on the peer physical node is responding normally, and whether the shared storage path is reachable.

[0044] Furthermore, based on the periodically acquired status information, it is determined whether the heartbeat of the currently running host responds normally within a preset time. The preset time can be configured based on factors such as cluster size, network latency, and fault tolerance time. If the currently running host fails to respond normally to the heartbeat within the preset time, the system determines that a heartbeat loss event has occurred. A heartbeat loss event is a prerequisite for triggering subsequent fault confirmation procedures; it is not directly equivalent to a physical node failure, thus avoiding unnecessary switching operations caused by momentary network jitter or brief process blocking.

[0045] After determining the heartbeat loss event, further detection operations are performed to confirm the authenticity and scope of the fault. The detection operations include at least one of the following: detecting whether the consensus node process on the currently running host has exited incorrectly; detecting whether the access path to the persistent state stored in the shared storage is interrupted; and detecting whether the currently running host meets preset fault determination conditions. Specifically, detecting whether the consensus node process has exited incorrectly can be achieved by monitoring the process identifier or querying the service management interface; detecting whether the shared storage access path is interrupted can be accomplished by testing read / write operations or checking the block device status; preset fault determination conditions may include the number of consecutive heartbeat loss events, I / O error rate thresholds, or system resource exhaustion indicators. By combining multiple detection operations, transient anomalies and persistent faults can be distinguished, reducing the probability of false positives.

[0046] When at least one of the detection operations yields a positive result, a failure is confirmed in the currently running host, and a failover trigger signal is generated. This failover trigger signal serves as the direct input for the high availability management module to execute subsequent failover actions, notifying the high availability management module to initiate the migration or restart process of the virtual consensus node.

[0047] Furthermore, in a Corosync-based implementation scenario, the heartbeat detection mechanism performs the following steps based on token ring ordered broadcast and membership protocol: The communication processes running on the first physical node and the second physical node form a logical ring. The token is passed cyclically between the communication processes in the logical ring in a predetermined order. The communication process that receives the token sends a message to be broadcast and then continues to forward the token. If the communication process does not receive or successfully forward the token within a predetermined time, a retransmission operation is performed. If multiple retransmissions fail, the corresponding physical node is determined to be abnormal and the cluster membership is updated to periodically obtain the status information of the peer physical node.

[0048] Understandably, when the high availability management module uses Corosync as its cluster communication and membership management framework, the aforementioned heartbeat detection mechanism is implemented based on Totem Token Heartbeat (a token ring ordered broadcast and membership protocol, the core underlying protocol of Corosync): communication processes running on the first and second physical nodes form a logical ring, and tokens are passed cyclically among the communication processes in the logical ring according to a predetermined order. A communication process that receives a token sends a message to be broadcast and then forwards the token to the next communication process. If a communication process does not receive a token or fails to forward the token within a predetermined time, the system prioritizes triggering a token retransmission operation; if multiple retransmissions fail consecutively, the physical node where the communication process resides is determined to be abnormal, and the cluster membership is updated accordingly, triggering a cluster reconfiguration process. Based on the above token passing and timeout retransmission mechanism, the system can periodically obtain the status information of the peer physical nodes and effectively distinguish between node failures and network link failures.

[0049] Furthermore, the step of migrating or restarting the virtual consensus node based on the fault switching trigger signal further includes: In response to the fault switching trigger signal, perform an exclusive ownership confirmation operation on the shared storage; The exclusive ownership confirmation operation includes: confirming whether the current running host has lost write access to the shared storage, confirming whether the current running host is offline, confirming whether the current running host has been isolated, and confirming whether the corresponding service instance on the current running host has been terminated; When at least one of the ownership confirmation operations is true, it is determined that the exclusive ownership of the shared storage has been transferred to another surviving physical node; After determining that the exclusive ownership has been transferred, an instruction is issued to migrate or restart the virtual consensus node; The exclusive ownership confirmation operation is performed using at least one of the following methods: SCSI persistent reservation confirmation, distributed lock confirmation, lease confirmation, or isolation control.

[0050] In this embodiment, after receiving the failover trigger signal but before actually migrating or restarting the virtual consensus node, an exclusive ownership confirmation operation needs to be performed on the shared storage. This pre-emptive step aims to prevent the virtual consensus node from being activated simultaneously on both the first and second physical nodes, thereby avoiding potential data corruption and state conflicts in dual-master or split-brain scenarios.

[0051] Specifically, the exclusive ownership confirmation operation includes confirming whether the currently running host has lost write access to the shared storage. For example, the system can determine whether the original host still holds a valid write handle by checking the persistent reservation status or file lock status of the shared storage device. If the original host's persistent reservation has been released, the write lease has expired, or the corresponding I / O channel has been blocked, it can be determined that the original host has lost its ability to write to the shared storage. Simultaneously, the exclusive ownership confirmation operation also includes confirming whether the currently running host is offline. Offline status confirmation is based on the status information of the aforementioned heartbeat detection mechanism, such as if the heartbeat loss event has continuously exceeded a preset offline determination threshold, or if the cluster membership has marked the original host as an offline member.

[0052] Furthermore, the exclusive ownership confirmation operation also includes confirming whether the currently running host has been isolated. Isolation control can be achieved through STONITH or I / O isolation operations. The STONITH (Shoot The Other Node In The Head) operation ensures that the original host cannot continue to interfere with shared storage or cluster communication by cutting off the original host's power, restarting the original host, or sending a forced termination command. The I / O isolation operation blocks the original host's access path at the storage network layer, preventing it from continuing to write data to shared storage.

[0053] The exclusive ownership confirmation operation also includes confirming whether the corresponding service instance on the currently running host has been terminated. The system can confirm whether the virtual consensus node instance on the original host has stopped running by querying the service management interface or process monitoring status.

[0054] When at least one of the above confirmation operations yields a positive result, the system determines that exclusive ownership of the shared storage has been transferred to another surviving physical node. Under this condition, the surviving physical node gains exclusive access to the shared storage, enabling it to securely read the persistent state of the virtual consensus node and restart the node instance thereon. After determining that exclusive ownership has been transferred, the high availability management module issues an instruction to migrate or restart the virtual consensus node, formally triggering the recovery process of the virtual consensus node on the surviving physical node.

[0055] The exclusive ownership confirmation operation can be implemented using SCSI persistent reservation confirmation, distributed lock confirmation, lease confirmation, or isolation control. For example, when the exclusive ownership confirmation operation is performed using distributed lock confirmation, the system maintains a distributed lock file in a pre-agreed location in the shared storage. Only after the surviving physical node confirms that the original host lock file has been released or forcibly preempts the lock file can it continue with subsequent operations.

[0056] like Figure 4As shown, in a preferred embodiment, the shared storage exclusive ownership confirmation process is explained in a modular form: When the health detection and failover determination module detects and confirms a failure in the current running host, it sends a failover trigger signal to the high availability management module. Upon receiving the failover trigger signal, the high availability management module sends an exclusive ownership confirmation command to the shared storage exclusive control module. The shared storage exclusive control module then initiates an exclusive ownership confirmation operation on the shared storage, specifically including: confirming whether the current running host has lost write access to the shared storage, confirming whether the current running host is offline, confirming whether the current running host has been isolated by fencing operations, and confirming whether the corresponding service instance on the current running host has been terminated.

[0057] During the confirmation operation, the shared storage exclusive control module can block access to the shared storage through methods such as SCSI persistent reservation preemption, distributed lock preemption, lease confirmation, or issuing fencing commands to the current running host. If the current running host is offline or fencing is successful, it will lose write permissions to the shared storage.

[0058] When at least one of the above confirmation operations is confirmed as positive, the shared storage exclusive control module determines that the exclusive ownership of the shared storage has been transferred to another surviving physical node and returns an exclusive ownership confirmation signal to the high availability management module. Upon receiving this signal, the high availability management module issues an instruction to the other surviving physical node to migrate or restart the virtual consensus node. The other surviving physical node then resumes the operation of the virtual consensus node based on the persistent state saved in the shared storage.

[0059] Furthermore, the process of migrating or restarting the virtual consensus node on another surviving physical node further includes: A recovery verification operation is performed based on the persistent state stored in the shared storage so that the recovered virtual consensus node meets the protocol continuity requirements. The persistent state includes at least one of the following: term state, voting state, member configuration state, log metadata, log index, snapshot metadata, and recovery checkpoint, and the virtual consensus node does not carry out external business requests for the complete log text and data plane. The recovery verification operation includes at least one of the following: log consistency check, snapshot consistency check, term status check, voting status check, or recovery checkpoint verification.

[0060] In this embodiment, after a virtual consensus node completes migration or restart, the system first performs a recovery verification operation based on the persistent state stored in shared storage. The purpose is to ensure that the protocol state carried by the recovered virtual consensus node remains consistent with the current consensus cluster, avoiding anomalies such as log rollback, term conflicts, or vote splits caused by state discontinuity.

[0061] The persistent state is stored in shared storage and includes at least one of the following: term status, voting status, member configuration status, log metadata, log index, snapshot metadata, and recovery checkpoint. Virtual consensus nodes do not carry the complete log text; they only store log metadata to track commit progress and participate in majority confirmation. The complete log is maintained locally by the first and second consensus nodes, thereby reducing the write load on shared storage and making migration more lightweight and efficient.

[0062] Further, the step of performing a recovery verification operation based on the persistent state stored in the shared storage to ensure that the recovered virtual consensus node meets the protocol continuity requirements, further includes: Under normal system conditions, the first consensus node is run on the first physical node, the second consensus node is run on the second physical node, and the virtual consensus node is run on either the first physical node or the second physical node, so that the first consensus node, the second consensus node and the virtual consensus node form a logical three-member consensus cluster. When a failure of the currently running host is detected and the virtual consensus node has completed migration or restart on another surviving physical node, it enters a degraded state. In the degraded state, the virtual consensus node and the consensus node deployed on the other physical node are simultaneously run on the other physical node, so that the other physical node has at least two logical consensus members under the condition of a single physical node, so as to satisfy the majority submission condition.

[0063] like Figure 5 As shown, it is understandable that after the recovery verification operation is completed and the virtual consensus nodes meet the protocol continuity requirements, the member distribution methods in the normal state and the degraded state should be distinguished according to the current operating status: Under normal system conditions, the first consensus node runs on the first physical node, the second consensus node runs on the second physical node, and the virtual consensus node is determined by the high availability management module to run on either the first or second physical node. Together, these three constitute a logical three-member consensus cluster. In this state, the two physical nodes jointly host three logical consensus members, and the cluster possesses full majority-push capability.

[0064] When a failure is detected in the current host of a virtual consensus node, and the virtual consensus node has already been migrated or restarted on another surviving physical node, the system enters a degraded state. In the degraded state, the original consensus node and the migrated virtual consensus node run simultaneously on the other surviving physical node, ensuring that the physical node hosts at least two logical consensus members under single-physical-node conditions. Since two logical consensus members meet the majority threshold requirement for a three-member cluster, the cluster can continue to perform control plane operations such as master node election and log commits in the degraded state, thereby maintaining the availability of the consensus cluster.

[0065] Furthermore, the method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes further includes: When the currently running host recovers from a failure, the health status of the recovered physical nodes is detected; When the health status meets the preset recovery conditions, perform status synchronization or environment verification, and generate status synchronization result or environment verification result. Based on the state synchronization result or the environment verification result, determine whether to migrate the virtual consensus node back to the recovered physical node based on the migration strategy. The migration strategy is determined by at least one of load balancing, physical node priority, fault history, network quality, shared storage path quality, or manual management strategy.

[0066] In this embodiment, when the fault of the currently running host is recovered, the system executes a migration strategy to determine the final ownership of the virtual consensus node.

[0067] Specifically, when the currently running host recovers from a failure, the system first checks the health status of the recovered physical nodes. The health status includes the status of the heartbeat links between nodes, the availability of the shared storage path, the health of the local storage, and the running status of the service processes. When the health status meets preset recovery conditions, the system performs state synchronization or environment verification to confirm that the recovered physical nodes are consistent with the current cluster state and generates corresponding state synchronization or environment verification results.

[0068] Subsequently, the recovery migration and rebalancing module determines whether to migrate the virtual consensus node back to the recovered physical node based on the state synchronization result or the environment verification result, combined with the migration strategy. The migration strategy is determined based on at least one of load balancing, physical node priority, fault history, network quality, shared storage path quality, or manual management strategies. For example, if the migration strategy prioritizes restoring the original topology and the recovered physical node is in good health, the system will migrate the virtual consensus node back; if the migration strategy is based on load balancing considerations and the currently surviving physical node has a low load, the system can retain the virtual consensus node on the current running host. Therefore, this invention can flexibly determine the final destination of the virtual consensus node after fault recovery based on the actual state and preset strategies, achieving a smooth switch between normal, degraded, and recovered states.

[0069] The present invention has the following beneficial effects: (1) Achieve majority consensus in a two-node system without adding a fixed third physical node.

[0070] (2) Avoid the problem of insufficient support for protocol state in traditional passive witness schemes.

[0071] (3) The continuous recovery of virtual consensus nodes is achieved through persistent state in shared storage, reducing the risk of state loss after switching.

[0072] (4) Reduce the risk of split brain and double activation by heartbeat-based fault detection, exclusive control and fault switching sequence constraints.

[0073] (5) The hierarchical persistence structure of local storage plus shared block storage balances performance and majority availability.

[0074] Furthermore, such as Figure 6 As shown, based on the above method for maintaining a majority in a consensus cluster using portable virtual consensus nodes, the present invention also provides a system for maintaining a majority in a consensus cluster using portable virtual consensus nodes, wherein the system for maintaining a majority in a consensus cluster using portable virtual consensus nodes includes: The first consensus node deployment module 51 is used to deploy the first consensus node on the first physical node and save the first primary persistent state of the first consensus node to the first local storage. The second consensus node deployment module 52 is used to deploy the second consensus node on the second physical node and save the second primary persistent state of the second consensus node to the second local storage. The virtual consensus node creation module 53 is used to create virtual consensus nodes and save the persistent state of the virtual consensus nodes to the shared storage of the first physical node and the second physical node; wherein, the running host of the virtual consensus node is determined by the high availability management module, the running host is the first physical node or the second physical node, and the virtual consensus node runs on the running host; The consensus cluster construction module 54 is used to form a logical three-member consensus cluster by connecting the first consensus node, the second consensus node and the virtual consensus node. The fault detection and switching module 55 is used to detect the fault status of the current running host of the virtual consensus node. When the fault of the current running host is detected, the virtual consensus node is migrated or restarted on another surviving physical node according to the persistent status saved in the shared storage, so that the corresponding consensus node and the virtual consensus node run simultaneously on the other physical node to meet the majority submission condition.

[0075] Furthermore, such as Figure 7 As shown, based on the above-described method and system for maintaining a majority of consensus clusters in a dual-node cluster using portable virtual consensus nodes, the present invention also provides a terminal, which includes a processor 10, a memory 20, and a display 30. Figure 7 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0076] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard disk or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores a program 40 for maintaining a majority in a consensus cluster using a portable virtual consensus node. This program 40 can be executed by the processor 10, thereby implementing the method of maintaining a majority in a consensus cluster using a portable virtual consensus node in a dual-node cluster as described in this application.

[0077] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the method of maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes.

[0078] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The components of the terminal communicate with each other via a system bus.

[0079] In one embodiment, when processor 10 executes program 40 in memory 20 that maintains a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes, the following steps are performed: Deploy the first consensus node on the first physical node and save the first primary persistent state of the first consensus node to the first local storage. Deploy a second consensus node on the second physical node and save the second primary persistent state of the second consensus node to the second local storage; Create a virtual consensus node and save the persistent state of the virtual consensus node to the shared storage of the first physical node and the second physical node; The virtual consensus node's running host is determined by the high availability management module. The running host is either the first physical node or the second physical node, and the virtual consensus node runs on the running host. The first consensus node, the second consensus node, and the virtual consensus node are logically formed into a three-member consensus cluster. The system detects the fault status of the current running host of the virtual consensus node. When a fault is detected in the current running host, the system migrates or restarts the virtual consensus node on another surviving physical node according to the persistent status stored in the shared storage. This allows the corresponding consensus node and the virtual consensus node to run simultaneously on the other physical node, thus satisfying the majority submission condition.

[0080] The virtual consensus node operates in any of the following forms: virtual machine, container, process group, service unit, or lightweight protocol proxy. The virtual consensus node is a protocol participant with limited functionality, used to participate in control plane operations under normal operating conditions. The control plane operations include: master node selection, voting confirmation, log metadata maintenance, member change confirmation, or snapshot coordination. The logically defined three-member consensus cluster is a Raft cluster, a Paxos cluster, or a majority-based variant consensus cluster.

[0081] The step of detecting the fault status of the current running host of the virtual consensus node, and when a fault is detected in the current running host, migrating or restarting the virtual consensus node on another surviving physical node according to the persistent status stored in the shared storage, specifically includes: A heartbeat detection mechanism is established between the first physical node and the second physical node, and the status information of the peer physical node is periodically obtained based on the heartbeat detection mechanism. Based on the status information, it is determined whether the heartbeat of the currently running host responds normally within a preset time. If it does not respond normally within the preset time, it is determined that the heartbeat loss event has occurred in the currently running host. After determining the heartbeat loss event, a detection operation is performed, which includes: detecting whether the consensus node process on the currently running host has exited incorrectly, detecting whether the access path of the persistent state stored in the shared storage is interrupted, and detecting whether the currently running host meets the preset fault determination conditions. When at least one of the detection operations is true, it is confirmed that the current running host has failed, a failover trigger signal is generated, and the virtual consensus node is migrated or restarted according to the failover trigger signal. In the Corosync implementation scenario, the heartbeat detection mechanism performs the following steps based on token ring ordered broadcast and membership protocol: The communication processes running on the first physical node and the second physical node form a logical ring. The token is passed cyclically between the communication processes in the logical ring in a predetermined order. The communication process that receives the token sends a message to be broadcast and then continues to forward the token. If the communication process does not receive or successfully forward the token within a predetermined time, a retransmission operation is performed. If multiple retransmissions fail, the corresponding physical node is determined to be abnormal and the cluster membership is updated to periodically obtain the status information of the peer physical node.

[0082] The step of migrating or restarting the virtual consensus node based on the fault switching trigger signal further includes, before: In response to the fault switching trigger signal, perform an exclusive ownership confirmation operation on the shared storage; The exclusive ownership confirmation operation includes: confirming whether the current running host has lost write access to the shared storage, confirming whether the current running host is offline, confirming whether the current running host has been isolated, and confirming whether the corresponding service instance on the current running host has been terminated; When at least one of the ownership confirmation operations is true, it is determined that the exclusive ownership of the shared storage has been transferred to another surviving physical node; After determining that the exclusive ownership has been transferred, an instruction is issued to migrate or restart the virtual consensus node; The exclusive ownership confirmation operation is performed using at least one of the following methods: SCSI persistent reservation confirmation, distributed lock confirmation, lease confirmation, or isolation control.

[0083] The process of migrating or restarting the virtual consensus node on another surviving physical node further includes: A recovery verification operation is performed based on the persistent state stored in the shared storage so that the recovered virtual consensus node meets the protocol continuity requirements. The persistent state includes at least one of the following: term state, voting state, member configuration state, log metadata, log index, snapshot metadata, and recovery checkpoint, and the virtual consensus node does not carry out external business requests for the complete log text and data plane. The recovery verification operation includes at least one of the following: log consistency check, snapshot consistency check, term status check, voting status check, or recovery checkpoint verification.

[0084] The step of performing a recovery verification operation based on the persistent state stored in the shared storage to ensure that the recovered virtual consensus node meets the protocol continuity requirements further includes: Under normal system conditions, the first consensus node is run on the first physical node, the second consensus node is run on the second physical node, and the virtual consensus node is run on either the first physical node or the second physical node, so that the first consensus node, the second consensus node and the virtual consensus node form a logical three-member consensus cluster. When a failure of the currently running host is detected and the virtual consensus node has completed migration or restart on another surviving physical node, it enters a degraded state. In the degraded state, the virtual consensus node and the consensus node deployed on the other physical node are simultaneously run on the other physical node, so that the other physical node has at least two logical consensus members under the condition of a single physical node, so as to satisfy the majority submission condition.

[0085] The method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes further includes: When the currently running host recovers from a failure, the health status of the recovered physical nodes is detected; When the health status meets the preset recovery conditions, perform status synchronization or environment verification, and generate status synchronization result or environment verification result. Based on the state synchronization result or the environment verification result, determine whether to migrate the virtual consensus node back to the recovered physical node based on the migration strategy. The migration strategy is determined by at least one of load balancing, physical node priority, fault history, network quality, shared storage path quality, or manual management strategy.

[0086] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a program for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes, and the program for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes, when executed by a processor, implements the steps of the method for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes as described above.

[0087] In summary, this invention provides a method, system, terminal, and storage medium for maintaining a majority in a consensus cluster in a dual-node cluster using a migrateable virtual consensus node. The method includes: deploying a first consensus node on a first physical node and saving its first primary persistent state to a first local storage; deploying a second consensus node on a second physical node and saving its second primary persistent state to a second local storage; creating a virtual consensus node and saving its persistent state to shared storage between the first and second physical nodes; forming a logical three-member consensus cluster from the first, second, and virtual consensus nodes; detecting the failure status of the current host of the virtual consensus node; and, when a failure is detected, migrating or restarting the virtual consensus node on another surviving physical node based on the persistent state saved in the shared storage, so that the corresponding consensus node and the virtual consensus node run simultaneously on the other physical node to satisfy the majority submission condition. This invention achieves the technical effects of maintaining the continuity of the majority submission capability of the consensus cluster without adding a fixed third physical node, reducing the risk of split-brain, and improving the availability of the control plane of dual-control devices.

[0088] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal 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 terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0089] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0090] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A method for maintaining a majority consensus in a two-node cluster using portable virtual consensus nodes, characterized in that, The method for maintaining a majority consensus in a two-node cluster using portable virtual consensus nodes includes: Deploy the first consensus node on the first physical node and save the first primary persistent state of the first consensus node to the first local storage. Deploy a second consensus node on the second physical node and save the second primary persistent state of the second consensus node to the second local storage; Create a virtual consensus node and save the persistent state of the virtual consensus node to the shared storage of the first physical node and the second physical node; The virtual consensus node's running host is determined by the high availability management module. The running host is either the first physical node or the second physical node, and the virtual consensus node runs on the running host. The first consensus node, the second consensus node, and the virtual consensus node are logically formed into a three-member consensus cluster. The system detects the fault status of the current running host of the virtual consensus node. When a fault is detected in the current running host, the system migrates or restarts the virtual consensus node on another surviving physical node according to the persistent status stored in the shared storage. This allows the corresponding consensus node and the virtual consensus node to run simultaneously on the other physical node, thus satisfying the majority submission condition.

2. The method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes according to claim 1, characterized in that, The virtual consensus node operates in any of the following forms: virtual machine, container, process group, service unit, or lightweight protocol proxy. The virtual consensus node is a protocol participant with limited functionality, used to participate in control plane operations under normal operating conditions. The control plane operations include: master node selection, voting confirmation, log metadata maintenance, member change confirmation, or snapshot coordination. The logically defined three-member consensus cluster is a Raft cluster, a Paxos cluster, or a majority-based variant consensus cluster.

3. The method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes according to claim 1, characterized in that, The process of detecting the fault status of the current running host of the virtual consensus node, and when a fault is detected in the current running host, migrating or restarting the virtual consensus node on another surviving physical node according to the persistent state stored in the shared storage, specifically includes: A heartbeat detection mechanism is established between the first physical node and the second physical node, and the status information of the peer physical node is periodically obtained based on the heartbeat detection mechanism. Based on the status information, it is determined whether the heartbeat of the currently running host responds normally within a preset time. If it does not respond normally within the preset time, it is determined that the heartbeat loss event has occurred in the currently running host. After determining the heartbeat loss event, a detection operation is performed, which includes: detecting whether the consensus node process on the currently running host has exited incorrectly, detecting whether the access path of the persistent state stored in the shared storage is interrupted, and detecting whether the currently running host meets the preset fault determination conditions. When at least one of the detection operations is true, it is confirmed that the current running host has failed, a failover trigger signal is generated, and the virtual consensus node is migrated or restarted according to the failover trigger signal. In the Corosync implementation scenario, the heartbeat detection mechanism performs the following steps based on token ring ordered broadcast and membership protocol: The communication processes running on the first physical node and the second physical node form a logical ring. The token is passed cyclically between the communication processes in the logical ring in a predetermined order. The communication process that receives the token sends a message to be broadcast and then continues to forward the token. If the communication process does not receive or successfully forward the token within a predetermined time, a retransmission operation is performed. If multiple retransmissions fail, the corresponding physical node is determined to be abnormal and the cluster membership is updated to periodically obtain the status information of the peer physical node.

4. The method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes according to claim 3, characterized in that, The step of migrating or restarting the virtual consensus node based on the fault switching trigger signal further includes: In response to the fault switching trigger signal, perform an exclusive ownership confirmation operation on the shared storage; The exclusive ownership confirmation operation includes: confirming whether the current running host has lost write access to the shared storage, confirming whether the current running host is offline, confirming whether the current running host has been isolated, and confirming whether the corresponding service instance on the current running host has been terminated; When at least one of the ownership confirmation operations is true, it is determined that the exclusive ownership of the shared storage has been transferred to another surviving physical node; After determining that the exclusive ownership has been transferred, an instruction is issued to migrate or restart the virtual consensus node; The exclusive ownership confirmation operation is performed using at least one of the following methods: SCSI persistent reservation confirmation, distributed lock confirmation, lease confirmation, or isolation control.

5. The method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes according to claim 1, characterized in that, The process of migrating or restarting the virtual consensus node on another surviving physical node further includes: A recovery verification operation is performed based on the persistent state stored in the shared storage, so that the recovered virtual consensus node meets the protocol continuity requirements; The persistent state includes at least one of the following: term state, voting state, member configuration state, log metadata, log index, snapshot metadata, and recovery checkpoint, and the virtual consensus node does not carry out external business requests for the complete log text and data plane. The recovery verification operation includes at least one of the following: log consistency check, snapshot consistency check, term status check, voting status check, or recovery checkpoint verification.

6. The method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes according to claim 5, characterized in that, The step of performing a recovery verification operation based on the persistent state stored in the shared storage, so that the recovered virtual consensus node meets the protocol continuity requirements, further includes: Under normal system conditions, the first consensus node is run on the first physical node, the second consensus node is run on the second physical node, and the virtual consensus node is run on either the first physical node or the second physical node, so that the first consensus node, the second consensus node and the virtual consensus node form a logical three-member consensus cluster. When a failure of the currently running host is detected and the virtual consensus node has completed migration or restart on another surviving physical node, it enters a degraded state. In the degraded state, the virtual consensus node and the consensus node deployed on the other physical node are simultaneously run on the other physical node, so that the other physical node has at least two logical consensus members under the condition of a single physical node, so as to satisfy the majority submission condition.

7. The method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes according to claim 1, characterized in that, The method for maintaining a majority consensus in a dual-node cluster using portable virtual consensus nodes further includes: When the currently running host recovers from a failure, the health status of the recovered physical nodes is detected; When the health status meets the preset recovery conditions, perform status synchronization or environment verification, and generate status synchronization result or environment verification result. Based on the state synchronization result or the environment verification result, determine whether to migrate the virtual consensus node back to the recovered physical node based on the migration strategy. The migration strategy is determined by at least one of load balancing, physical node priority, fault history, network quality, shared storage path quality, or manual management strategy.

8. A system for maintaining a majority consensus in a two-node cluster using portable virtual consensus nodes, characterized in that, The system that utilizes portable virtual consensus nodes to maintain a majority consensus in a two-node cluster includes: The first consensus node deployment module is used to deploy the first consensus node on the first physical node and save the first primary persistent state of the first consensus node to the first local storage. The second consensus node deployment module is used to deploy the second consensus node on the second physical node and save the second primary persistent state of the second consensus node to the second local storage. A virtual consensus node creation module is used to create virtual consensus nodes and save the persistent state of the virtual consensus nodes to the shared storage of the first physical node and the second physical node; wherein, the running host of the virtual consensus node is determined by the high availability management module, the running host is the first physical node or the second physical node, and the virtual consensus node runs on the running host; The consensus cluster construction module is used to form a logical three-member consensus cluster by connecting the first consensus node, the second consensus node, and the virtual consensus node. The fault detection and switching module is used to detect the fault status of the current running host of the virtual consensus node. When the fault of the current running host is detected, the virtual consensus node is migrated or restarted on another surviving physical node according to the persistent status saved in the shared storage, so that the corresponding consensus node and the virtual consensus node run simultaneously on the other physical node to meet the majority submission condition.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and a program stored in the memory and executable on the processor for maintaining a majority of consensus in a two-node cluster using a portable virtual consensus node. When the program for maintaining a majority of consensus in a two-node cluster using a portable virtual consensus node is executed by the processor, it implements the steps of the method for maintaining a majority of consensus in a two-node cluster using a portable virtual consensus node as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes. When the program for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes is executed by a processor, it implements the steps of the method for maintaining a majority of consensus clusters in a two-node cluster using portable virtual consensus nodes as described in any one of claims 1-7.

Images