Method and apparatus for determining master device of load balancing cluster

Abstract

The application relates to a method and device for determining a master device of a load balancing cluster. The method comprises the following steps: monitoring the running states of each load balancing device in the load balancing cluster; adjusting the VRRP priority of each load balancing device according to the fault type corresponding to the running state; triggering a master backup election process when the master device fails and the corresponding VRRP priority is reduced to a preset priority interval; determining a target device according to the VRRP priority of each load balancing device and a preset arbitration rule; and determining the target device as the master device. The method and device for determining the master device of the load balancing cluster introduce a fault grading degradation mechanism and a unique arbitration rule in a VRRP non-preemption mode, ensure that the load balancing cluster can still uniquely determine a device with a relatively optimal health condition as the master device when all the devices fail, and fundamentally avoid service interruption caused by multi-master conflict.

Description

Technical Field

[0001] This application relates to the field of computer information processing, and more specifically, to a method and apparatus for determining the master device of a load balancing cluster. Background Technology

[0002] Load balancing clusters use virtual service policies to associate VRRP policies to achieve primary / standby negotiation. In non-preemptive VRRP mode, when the primary device detects a failure, if it lowers its priority to a non-zero value, it will not trigger a standby device re-election. The standby device will only trigger an election when it receives a VRRP packet with a priority of 0. Based on this mechanism, in existing technical solutions, after a primary device fails, it usually lowers its own VRRP priority directly to 0 to force a primary / standby switchover.

[0003] However, priority 0 has a special meaning in the VRRP protocol, representing that the current master device voluntarily relinquishes its election right. The backup device receiving this message will immediately trigger a re-election. In a load balancing cluster, when all devices fail, the VRRP priority of all devices may drop to 0. At this time, the cluster cannot complete the election normally, all devices switch to master and each send gratuitous ARP packets, causing frequent MAC address table entries to drift, and service traffic to repeatedly switch between multiple devices, ultimately resulting in service interruption.

[0004] Therefore, a new method and device for determining the master device of a load balancing cluster is needed.

[0005] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] In view of this, this application provides a method and apparatus for determining the master device of a load balancing cluster. By introducing a fault classification and degradation mechanism and a unique arbitration rule in the VRRP non-preemptive mode, it ensures that the load balancing cluster can still uniquely determine the device with the relatively best health status as the master device when all members fail, thereby fundamentally avoiding service interruption caused by multi-master conflicts.

[0007] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0008] According to one aspect of this application, a method for determining the master device of a load balancing cluster is proposed. The method includes: monitoring the operating status of each load balancing device in the load balancing cluster; adjusting the VRRP priority of each load balancing device according to the fault type corresponding to the operating status; triggering a master-slave election process when the master device fails and the corresponding VRRP priority drops to a preset priority range; determining a target device according to the VRRP priority of each load balancing device and a preset arbitration rule; and determining the target device as the master device.

[0009] In one exemplary embodiment of this application, adjusting the VRRP priority of each load balancer according to the fault type corresponding to the operating state includes: identifying the fault type corresponding to each load balancer; determining a VRRP priority adjustment strategy according to the service impact degree corresponding to the fault type; and adjusting the VRRP priority of each load balancer according to the VRRP priority adjustment strategy.

[0010] In one exemplary embodiment of this application, determining a VRRP priority adjustment strategy based on the service impact level corresponding to the fault type includes: when the fault is a first type of fault, reducing the VRRP priority to a first priority value, wherein the first type of fault is a fault where the device's processing capacity is limited but the basic forwarding function is available; when the fault is a second type of fault, reducing the VRRP priority to a second priority value, wherein the second type of fault is a fault that affects the normal transmission and reception of service packets; both the first priority value and the second priority value are within the priority range of 1 to 10, and the first priority value is greater than the second priority value.

[0011] In one exemplary embodiment of this application, when the primary device fails and the corresponding VRRP priority drops to a preset priority range, a primary / standby election process is triggered, including: when the standby device receives a VRRP message sent by the primary device, determining whether the VRRP priority carried in the VRRP message is within the preset priority range; if so, the primary / standby election process is triggered.

[0012] In one exemplary embodiment of this application, triggering the primary / backup election process includes: the backup device initiating a VRRP re-election to re-determine the primary device.

[0013] In one exemplary embodiment of this application, determining a target device based on the VRRP priority of each load balancing device and a preset arbitration rule includes: determining at least one candidate device based on the VRRP priority of each load balancing device; and determining the target device from the at least one candidate device according to the preset arbitration rule.

[0014] In one exemplary embodiment of this application, determining the target device from the at least one candidate device according to a preset arbitration rule includes: when multiple candidate devices have the same highest VRRP priority, obtaining the device identifier corresponding to each candidate device; comparing the device identifiers; and determining the candidate device corresponding to the device identifier with the largest comparison result as the target device.

[0015] In one exemplary embodiment of this application, the device is identified as the source address of the VRRP message.

[0016] In one exemplary embodiment of this application, determining the target device based on the device identifier includes: converting the source address of each VRRP packet into a corresponding integer value; performing a size comparison based on the integer values; and selecting the candidate device corresponding to the largest integer value as the target device.

[0017] According to one aspect of this application, a master device determination apparatus for a load balancing cluster is proposed. The apparatus includes: a monitoring module for monitoring the operating status of each load balancing device in the load balancing cluster; an adjustment module for adjusting the VRRP priority of each load balancing device according to the fault type corresponding to the operating status; an election module for triggering a master-slave election process when the master device fails and the corresponding VRRP priority drops to a preset priority range; an arbitration module for determining a target device according to the VRRP priority of each load balancing device and a preset arbitration rule; and a determination module for determining the target device as the master device.

[0018] According to one aspect of this application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the method as described above.

[0019] According to one aspect of this application, a computer-readable medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described above.

[0020] According to the load balancing cluster master device determination method and apparatus of this application, the operating status of each load balancing device in the load balancing cluster is monitored; the VRRP priority of each load balancing device is adjusted according to the fault type corresponding to the operating status; when the master device fails and the corresponding VRRP priority drops to a preset priority range, a master-slave election process is triggered; the target device is determined according to the VRRP priority of each load balancing device and a preset arbitration rule; the method of determining the target device as the master device is achieved by introducing a fault classification and degradation mechanism and a unique arbitration rule in the VRRP non-preemptive mode, ensuring that the load balancing cluster can still uniquely determine the device with the relatively optimal health status as the master device when all devices fail, fundamentally avoiding service interruption caused by multi-master conflicts.

[0021] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0022] The above and other objects, features, and advantages of this application will become more apparent from the detailed description of exemplary embodiments with reference to the accompanying drawings. The drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0023] Figure 1 This is a flowchart illustrating a method for determining the master device of a load balancing cluster according to an exemplary embodiment.

[0024] Figure 2 This is a flowchart illustrating a method for determining the master device of a load balancing cluster according to another exemplary embodiment.

[0025] Figure 3 This is a flowchart illustrating a method for determining the master device of a load balancing cluster according to another exemplary embodiment.

[0026] Figure 4 This is a block diagram illustrating a master device determination apparatus for a load balancing cluster according to an exemplary embodiment.

[0027] Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0028] Figure 6 This is a block diagram illustrating a computer-readable medium according to an exemplary embodiment. Detailed Implementation

[0029] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0030] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0031] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0032] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0033] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of this application. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0034] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing this application, and therefore cannot be used to limit the scope of protection of this application.

[0035] The technical abbreviations used in this application are explained as follows: VRRP, or Virtual Router Redundancy Protocol, is used to ensure uninterrupted service and high router reliability when the primary router fails, allowing backup routers to smoothly take over and switch to primary status. A group of VRRP virtual routers consists of one primary router and multiple backup routers. Only the primary router sends VRRP messages periodically. Backup routers monitor the primary router's status through these VRRP messages. If the primary router fails, the remaining backup routers renegotiate and elect a new primary router to take over the service.

[0036] Priority: VRRP negotiates the primary and backup devices based on priority, ranging from 0 to 255. Higher values ​​indicate higher priority for switching to the primary. Priority 0 means the current primary device relinquishes the election, and the backup device, upon receiving this priority message, renegotiates for a new primary device. VRRP devices manage primary / backup switching by monitoring interface events such as UP / DOWN and address updates.

[0037] Preemption Mode: This determines whether a backup device preempts the master device, and is divided into preemption mode and non-preemption mode. In preemption mode, after recovering from a fault, the backup device returns to its original priority. If it receives a VRRP message with a lower priority than the master device, a re-election will be triggered. In non-preemption mode, after recovering from a fault, if the backup device receives a VRRP message with a lower priority than the master device, a re-election will not be triggered. However, if it receives a VRRP message with a priority of 0, a re-election will still be triggered.

[0038] Load balancing cluster: Multiple load balancing devices form a cluster, achieving high reliability through mechanisms such as VRRP. Virtual service policies on load balancing devices are associated with VRRP policies. When the VRRP associated with a virtual service is in the primary state, it sends ARP packets. If the primary device fails, the backup device switches to the primary VRRP state, and the virtual service associated with that VRRP sends gratuitous ARP updates to the switch's MAC address table, ensuring a seamless traffic switchover to the backup load balancing device.

[0039] Figure 1 This is a flowchart illustrating a method for determining the master device of a load balancing cluster according to an exemplary embodiment. The method 10 for determining the master device of a load balancing cluster includes at least steps S102 to S110.

[0040] like Figure 1 As shown, in S102, the operating status of each load balancing device in the load balancing cluster is monitored.

[0041] In this embodiment, the load balancing cluster consists of multiple load balancing devices. Each load balancing device establishes a primary / backup relationship through VRRP (Virtual Router Redundancy Protocol), with one load balancing device acting as the primary device and the others as backup devices. The primary device periodically sends VRRP advertisement messages, and the backup devices monitor the status of the primary device by listening to these VRRP advertisement messages.

[0042] For example, real-time data collection of resource operation status, service interface status, and service processing status of each load balancing device can be performed, and the fault type corresponding to each load balancing device can be identified based on the status information. A VRRP priority adjustment strategy can be determined based on the degree of service impact corresponding to the fault type. The VRRP priority of each load balancing device can be adjusted according to the VRRP priority adjustment strategy.

[0043] The resource operation status information may include system operation indicators such as CPU utilization and memory utilization; the service interface status information may include the UP / DOWN status of the service interface; and the service processing status information may include the service message reception status, service message forwarding status, and service processing capability status.

[0044] More specifically, faults are categorized based on their impact on service continuity. When a fault is classified as a Type I fault, its VRRP priority is reduced to a first priority value. Type I faults are those where device processing capacity is limited but basic forwarding functions are available. For example, if CPU utilization or memory utilization exceeds a preset threshold, the device can still complete basic service forwarding, but processing performance is affected. Therefore, the VRRP priority is reduced without immediately discontinuing service delivery.

[0045] When the fault is a type II fault, the VRRP priority is reduced to a second priority value. Type II faults are those that affect the normal transmission and reception of service packets. Examples include a service interface going down, a service port malfunctioning, or service traffic failing to be received and forwarded normally. These types of faults have a greater impact on the service than Type I faults and therefore receive a lower VRRP priority.

[0046] Both the first priority value and the second priority value are within the priority range of 1 to 10, with the first priority value being greater than the second priority value. For example, when a device experiences CPU or memory resource anomalies, the VRRP priority can be adjusted to 10; when a device experiences a service interface failure, the VRRP priority can be adjusted to 5. By adopting a method where different priorities correspond to different fault levels, a differentiated primary / backup election strategy based on device health status is implemented, ensuring that service traffic is preferentially handled by devices with relatively higher health levels.

[0047] It should be noted that the priority range of 1 to 10 in this embodiment is used as a special priority range after a fault is triggered. Unlike the prior art that directly reduces the priority to 0, this embodiment avoids the problem of abnormal election caused by all devices being reduced to 0, thereby improving the availability of the cluster under complex fault scenarios.

[0048] In S104, the VRRP priority of each load balancing device is adjusted according to the fault type corresponding to the operating state.

[0049] In this embodiment, each load balancing device dynamically adjusts its VRRP priority based on the detected fault status and notifies other devices in the backup group of the current priority information via VRRP messages. When the device's operating status changes, the corresponding VRRP priority is updated synchronously to reflect the current service carrying capacity of the device.

[0050] In S106, when the primary device fails and the corresponding VRRP priority drops to the preset priority range, the primary / standby election process is triggered.

[0051] For example, when the standby device receives a VRRP message sent by the master device, it determines whether the VRRP priority carried in the VRRP message is within the preset priority range; if so, the master-standby election process is triggered.

[0052] In this embodiment, the preset priority range can be 1 to 10. When the standby device receives a VRRP message sent by the master device, it parses the Priority field in the message. When the VRRP priority corresponding to the Priority field is within the preset priority range, it indicates that the current master device has failed and its service carrying capacity has decreased. At this time, a new master-standby negotiation process is initiated.

[0053] More specifically, the backup device initiates a VRRP re-election to re-determine the primary device. This re-election process can be performed in non-preemptive VRRP mode. In non-preemptive mode, when the backup device receives a VRRP message with a priority higher than a preset priority range, it maintains its current state; when it receives a VRRP message with a priority within the preset priority range, it triggers a re-election, thereby achieving primary / backup switching in case of failure.

[0054] In S108, the target device is determined based on the VRRP priority of each load balancing device and the preset arbitration rules.

[0055] For example, at least one candidate device can be determined based on the VRRP priority of each load balancer; and the target device can be determined from the at least one candidate device according to a preset arbitration rule.

[0056] Specifically, the VRRP priorities of each load balancing device participating in the election are compared to determine the current highest VRRP priority; the device whose VRRP priority is equal to the highest VRRP priority is determined as a candidate device.

[0057] More specifically, when multiple candidate devices have the same highest VRRP priority, the device identifier corresponding to each candidate device is obtained; the device identifiers are compared; and the candidate device corresponding to the device identifier with the largest comparison result is determined as the target device.

[0058] In this embodiment, the device identifier can uniquely identify the corresponding load balancing device and is used for further arbitration when multiple candidate devices have the same priority, ensuring that the election result is unique.

[0059] In S110, the target device is determined to be the master device.

[0060] Once the target device is identified, its state is switched to primary state, and it assumes the service processing functions of the corresponding virtual service. Simultaneously, the target device sends ARP update information to the network, causing the switching equipment to update the corresponding MAC address table entries, thereby ensuring that service traffic is forwarded to the new primary device and achieving continuous service operation.

[0061] According to the method for determining the master device of the load balancing cluster in this application, the operating status of each load balancing device in the load balancing cluster is monitored; the VRRP priority of each load balancing device is adjusted according to the fault type corresponding to the operating status; when the master device fails and the corresponding VRRP priority drops to a preset priority range, a master-slave election process is triggered; the target device is determined according to the VRRP priority of each load balancing device and the preset arbitration rules; the method of determining the target device as the master device is achieved by introducing a fault classification and degradation mechanism and a unique arbitration rule in the non-preemptive VRRP mode, ensuring that the load balancing cluster can still uniquely determine the device with the relatively optimal health status as the master device when all devices fail, fundamentally avoiding service interruption caused by multi-master conflicts.

[0062] It should be clearly understood that this application describes how specific examples are formed and used, but the principles of this application are not limited to any details of these examples. Rather, based on the teachings of the disclosure of this application, these principles can be applied to many other embodiments.

[0063] Figure 2 This is a flowchart illustrating a method for determining the master device of a load balancing cluster according to another exemplary embodiment. Figure 2 The process shown in step 20 is... Figure 1 The process shown in the diagram is described in detail in step S108, "Determine the target device based on the VRRP priority of each load balancing device and the preset arbitration rules".

[0064] like Figure 2 As shown, in S202, at least one candidate device is determined based on the VRRP priority of each load balancing device. Specifically, the VRRP priorities of all participating devices are compared, the highest VRRP priority is obtained, and the device with the highest VRRP priority is determined as a candidate device.

[0065] In S204, when multiple candidate devices have the same highest VRRP priority, the device identifier corresponding to each candidate device is obtained.

[0066] In S206, comparisons are made based on the device identifier. The device identifier is the source address of the VRRP message. The VRRP protocol stipulates that when multiple devices have the same priority, the source addresses of the messages can be further compared to determine the final master device. Therefore, this embodiment uses the VRRP message source address as the arbitration basis to ensure the uniqueness of the election result.

[0067] In S208, the candidate device corresponding to the device identifier with the largest comparison result is determined as the target device. Specifically, the source address of each VRRP message is converted into a corresponding integer value; a size comparison is performed based on the integer values; and the candidate device corresponding to the largest integer value is selected as the target device.

[0068] By using the above method, even if multiple devices in the load balancing cluster fail at the same time and their corresponding VRRP priorities all drop to the preset priority range, a unique master device can still be determined based on priority and source address arbitration mechanism. This avoids MAC address drift, repeated traffic switching and service interruption caused by multiple devices switching to master status at the same time, thereby improving the reliability and stability of the load balancing cluster.

[0069] Figure 3 This is a flowchart illustrating a method for determining the master device of a load balancing cluster according to another exemplary embodiment. Figure 3 The process shown in step 30 is... Figure 1 The process is described in detail below. This application proposes a method for determining the master device of a load balancing cluster, applicable to load balancing clusters that use VRRP (Virtual Router Redundancy Protocol) to establish a master-slave relationship, and particularly suitable for master-slave election scenarios in VRRP non-preemptive mode. By optimizing the VRRP priority adjustment mechanism and master-slave election mechanism under fault conditions, reliable determination of the master device is achieved under complex fault scenarios, improving the service continuity and system stability of the load balancing cluster.

[0070] In existing technologies, under VRRP non-preemptive mode, when the primary device fails, it typically triggers a switchover by lowering its VRRP priority to 0. VRRP priority 0 is a special priority defined by the protocol, indicating that the current primary device actively relinquishes its primary status and triggers the backup device to re-participate in the primary / backup election. However, in a load-balanced cluster environment, when multiple devices fail simultaneously, multiple devices may all lower their VRRP priorities to 0. Since multiple devices meet the re-election conditions, this can easily lead to multiple devices simultaneously entering the primary state, resulting in multi-primary conflicts. Furthermore, multiple devices simultaneously sending ARP update packets can cause frequent MAC address table entries to drift in the switching network, causing service traffic to repeatedly switch between different devices, ultimately leading to service interruption.

[0071] Furthermore, in actual operation, the impact of different faults on the service carrying capacity of equipment varies significantly. For example, some faults only lead to a decrease in equipment processing performance, but the equipment can still maintain basic service forwarding capabilities; while other faults will directly affect the normal reception and forwarding of service traffic. If a uniform priority degradation strategy is adopted, it will not be able to accurately reflect the actual service carrying capacity of different devices, which may result in service traffic being scheduled to devices with more severe faults, thus reducing the overall service quality of the cluster.

[0072] To address the aforementioned issues, this application proposes a dynamic VRRP priority adjustment mechanism based on fault type. During operation, the load balancing device continuously monitors its own operational status. When a fault is detected, the VRRP priority is dynamically adjusted according to the fault type and its corresponding service impact. Unlike existing technologies that directly reduce the priority to 0, this application adjusts the VRRP priority to a preset priority range. This preserves the priority differences between devices while triggering a primary / backup re-election, ensuring that the actual service carrying capacity of each device is reflected in subsequent election processes.

[0073] like Figure 3 As shown, in S302, in non-preemptive mode, the cluster standby machine receives VRRP messages.

[0074] In S304, the priority is set to whether it is greater than 10. Specifically, the preset priority range can be set to 1 to 10. When the device detects that the CPU utilization exceeds a preset threshold or the memory utilization exceeds a preset threshold, it indicates that the device's processing capacity is limited, but the basic forwarding function is still normal. At this time, the VRRP priority can be adjusted to the first priority value, such as 10. When the device detects that the service interface is abnormal, the service port is down, or the service traffic cannot be sent or received normally, it indicates that the device's service processing capacity is significantly affected. At this time, the VRRP priority can be adjusted to the second priority value, such as 5. The first priority value is greater than the second priority value, so that different fault levels correspond to different VRRP priorities.

[0075] Through the aforementioned hierarchical priority adjustment mechanism, even if multiple load balancing devices fail simultaneously, each device can still maintain a different priority level according to the severity of the failure. This allows subsequent primary / backup elections to prioritize devices with less impact from the failure and relatively stronger service carrying capacity as the primary device, thus achieving a preferred carrying strategy in failure scenarios.

[0076] Furthermore, to ensure the stability of the primary / standby relationship, the preset priority range is only used as the result of automatic adjustment after a fault is triggered. During system configuration, it is not allowed to manually configure the VRRP priority to fall within the preset priority range, thereby avoiding the possibility of the device mistakenly triggering a primary / standby switchover due to configuration errors, which would affect the stable operation of the cluster.

[0077] In S306, the priority is compared with the priority of the local VRRP policy.

[0078] On the standby device side, when a VRRP message sent by the primary device is received, the VRRP priority carried in the VRRP message is checked. When the VRRP priority is within the preset priority range, it is considered that the current primary device has failed and its service carrying capacity has decreased, and a new primary / standby election process is triggered. When the VRRP priority is higher than the preset priority range, the current primary / standby relationship is maintained, and no re-election is initiated, thereby avoiding system instability caused by frequent switching.

[0079] In S308, the VRRP message source address is compared with the local VRRP packet sending source address.

[0080] In S310, the cluster standby machine triggers an election.

[0081] During the primary / standby election process, the VRRP priorities of each load balancer are first compared, and the device with the highest VRRP priority is identified as the candidate device. If only one device with the highest priority exists, it is directly identified as the new primary device; if multiple devices have the same highest VRRP priority, an arbitration process is further executed.

[0082] Specifically, the device identifier corresponding to each candidate device is obtained, and a comparison operation is performed based on the device identifier. In one embodiment, the device identifier is the source address of the VRRP packet. After converting the source addresses of the VRRP packets corresponding to each candidate device into integer values, their sizes are compared, and the device with the largest integer value is determined as the master device.

[0083] Through the aforementioned arbitration mechanism, even if all devices in the load balancing cluster fail and their corresponding VRRP priorities are all within the preset priority range, a unique master device can still be determined based on the VRRP priority and device identifier. Priority comparison reflects the severity of device failure, while device identifier comparison resolves election conflicts when priorities are the same, thus ensuring that only one master device exists in the cluster at any given time and avoiding issues such as multi-master conflicts, MAC address drift, and traffic fluctuations.

[0084] In S312, the state is maintained as standby.

[0085] This application introduces a VRRP priority dynamic adjustment mechanism based on fault type, a fault state triggering mechanism, and an arbitration mechanism based on device identifier, thereby achieving reliable determination of the master device of the load balancing cluster under complex fault scenarios and improving the fault tolerance, adaptability, and business robustness of the load balancing cluster.

[0086] Those skilled in the art will understand that all or part of the steps of the above embodiments are implemented as a computer program executed by a CPU. When the computer program is executed by the CPU, it performs the functions defined by the method provided in this application. The program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk.

[0087] Furthermore, it should be noted that the above figures are merely illustrative representations of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0088] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0089] Figure 4 This is a block diagram illustrating a master device determination apparatus for a load balancing cluster according to an exemplary embodiment. Figure 4 As shown, the master device determination device 40 of the load balancing cluster includes: a monitoring module 402, an adjustment module 404, an election module 406, an arbitration module 408, and a determination module 410.

[0090] Monitoring module 402 is used to monitor the operating status of each load balancing device in the load balancing cluster; The adjustment module 404 is used to adjust the VRRP priority of each load balancer according to the fault type corresponding to the operating status; the adjustment module 404 is also used to identify the fault type corresponding to each load balancer; determine the VRRP priority adjustment strategy according to the service impact degree corresponding to the fault type; and adjust the VRRP priority of each load balancer according to the VRRP priority adjustment strategy.

[0091] The election module 406 is used to trigger the primary / standby election process when the primary device fails and the corresponding VRRP priority drops to a preset priority range; when the standby device receives a VRRP message sent by the primary device, the election module 406 is also used to determine whether the VRRP priority carried in the VRRP message is within the preset priority range; if so, the primary / standby election process is triggered.

[0092] Arbitration module 408 is used to determine the target device according to the VRRP priority of each load balancing device and the preset arbitration rules; arbitration module 408 is also used to determine at least one candidate device according to the VRRP priority of each load balancing device; and to determine the target device from the at least one candidate device according to the preset arbitration rules.

[0093] The determination module 410 is used to determine the target device as the master device.

[0094] According to the master device determination device of the load balancing cluster in this application, the operating status of each load balancing device in the load balancing cluster is monitored; the VRRP priority of each load balancing device is adjusted according to the fault type corresponding to the operating status; when the master device fails and the corresponding VRRP priority drops to a preset priority range, a master-slave election process is triggered; the target device is determined according to the VRRP priority of each load balancing device and the preset arbitration rules; the method of determining the target device as the master device is to introduce a fault classification and degradation mechanism and a unique arbitration rule in the VRRP non-preemptive mode, so as to ensure that the load balancing cluster can still uniquely determine the device with the relatively optimal health status as the master device when all devices fail, fundamentally avoiding service interruption caused by multi-master conflicts.

[0095] Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0096] The following reference Figure 5 To describe an electronic device 500 according to this embodiment of the present application. Figure 5 The electronic device 500 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0097] like Figure 5 As shown, the electronic device 500 is presented in the form of a general-purpose computing device. The components of the electronic device 500 may include, but are not limited to: at least one processing unit 510, at least one storage unit 520, a bus 530 connecting different system components (including storage unit 520 and processing unit 510), a display unit 540, etc.

[0098] The storage unit stores program code that can be executed by the processing unit 510, causing the processing unit 510 to perform the steps described in this specification according to various exemplary embodiments of this application. For example, the processing unit 510 can perform actions such as... Figure 1 , Figure 2 , Figure 3 The steps are shown in the figure.

[0099] The storage unit 520 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 5201 and / or a cache storage unit 5202, and may further include a read-only memory unit (ROM) 5203.

[0100] The storage unit 520 may also include a program / utility 5204 having a set (at least one) program module 5205, such program module 5205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0101] Bus 530 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0102] Electronic device 500 can also communicate with one or more external devices 500' (e.g., keyboard, pointing device, Bluetooth device, etc.), enabling users to communicate with devices that interact with electronic device 500, and / or any device (e.g., router, modem, etc.) that allows electronic device 500 to communicate with one or more other computing devices. This communication can be performed via input / output (I / O) interface 550. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 560. Network adapter 560 can communicate with other modules of electronic device 500 via bus 530. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0103] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software, or by combining software with necessary hardware. Therefore, as... Figure 6 As shown, the technical solution according to the embodiments of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) or on a network, and includes several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the above-described method according to the embodiments of this application.

[0104] The software product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0105] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0106] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0107] The aforementioned computer-readable medium carries one or more programs. When these programs are executed by a device, the computer-readable medium performs the following functions: monitoring the operating status of each load balancing device in the load balancing cluster; adjusting the VRRP priority of each load balancing device according to the fault type corresponding to the operating status; triggering a master / slave election process when the master device fails and the corresponding VRRP priority drops to a preset priority range; determining a target device according to the VRRP priority of each load balancing device and a preset arbitration rule; and determining the target device as the master device.

[0108] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0109] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0110] Exemplary embodiments of this application have been specifically shown and described above. It should be understood that this application is not limited to the detailed structures, arrangements, or implementation methods described herein; rather, this application is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A method for determining the master device of a load balancing cluster, characterized in that, include: Monitor the operating status of each load balancing device in the load balancing cluster; Adjust the VRRP priority of each load balancer based on the fault type corresponding to the operating status; When the primary device fails and the corresponding VRRP priority drops to the preset priority range, the primary / standby election process is triggered. The target device is determined based on the VRRP priority and preset arbitration rules of each load balancer. The target device is identified as the master device.

2. The method as described in claim 1, characterized in that, Adjusting the VRRP priority of each load balancer based on the fault type corresponding to the operating status includes: Identify the fault types corresponding to each load balancing device; The VRRP priority adjustment strategy is determined based on the degree of business impact corresponding to the fault type. Adjust the VRRP priority of each load balancing device according to the VRRP priority adjustment strategy.

3. The method as described in claim 2, characterized in that, The VRRP priority adjustment strategy is determined based on the degree of service impact corresponding to the fault type, including: When the fault is a first type of fault, the VRRP priority is reduced to the first priority value, wherein the first type of fault is a fault in which the device's processing capacity is limited but the basic forwarding function is available; When the fault is a second type of fault, the VRRP priority is reduced to the second priority value, wherein the second type of fault is a fault that affects the normal sending and receiving of service packets; Both the first priority value and the second priority value are within the priority range of 1 to 10, and the first priority value is greater than the second priority value.

4. The method as described in claim 1, characterized in that, When the primary device fails and the corresponding VRRP priority drops to a preset priority range, a primary / standby election process is triggered, including: When the backup device receives a VRRP message sent by the master device, it determines whether the VRRP priority carried in the VRRP message is within the preset priority range; If so, the primary / backup election process is triggered.

5. The method as described in claim 4, characterized in that, Triggering the primary / standby election process includes: The backup device initiates a VRRP re-election to re-determine the master device.

6. The method as described in claim 1, characterized in that, The target device is determined based on the VRRP priority and preset arbitration rules of each load balancer, including: At least one candidate device is determined based on the VRRP priority of each load balancer; The target device is determined from the at least one candidate device according to the preset arbitration rules.

7. The method as described in claim 6, characterized in that, Determining the target device from the at least one candidate device according to preset arbitration rules includes: When multiple candidate devices have the same highest VRRP priority, obtain the device identifier corresponding to each candidate device; Comparison based on the device identifier; The candidate device corresponding to the device with the largest comparison result is identified as the target device.

8. The method as described in claim 7, characterized in that, The device identifier is the source address of the VRRP message.

9. The method as described in claim 7, characterized in that, Determining the target device based on comparisons using the device identifier includes: Convert the source address of each VRRP message to its corresponding integer value; Compare the sizes based on the integer values; The candidate device corresponding to the largest integer value is selected as the target device.

10. A device for determining the master device of a load balancing cluster, characterized in that, include: The monitoring module is used to monitor the operating status of each load balancing device in the load balancing cluster. The adjustment module is used to adjust the VRRP priority of each load balancing device according to the fault type corresponding to the operating status; The election module is used to trigger the primary / standby election process when the primary device fails and the corresponding VRRP priority drops to a preset priority range. The arbitration module is used to determine the target device based on the VRRP priority of each load balancer and the preset arbitration rules; The determination module is used to determine the target device as the master device.

Images