IPv6 DNS load balancing method based on bidirectional migration mechanism

Abstract

The invention provides an IPv6 (Internet Protocol Version 6) DNS (Domain Name Server) load balancing method based on a bidirectional migration mechanism, and aims to solve the problems of non-uniform request distribution, node overload, high response time delay, reduced service reliability and the like of DNS domain name resolution service of an existing power grid enterprise under the background of large-scale IPv6 deployment. A dynamic request scheduling scheme combining bidirectional migration and intelligent optimization is provided. Therefore, DNS domain name resolution requests are used as distribution units, multi-constraint modeling is adopted and an artificial bee colony optimization mechanism is introduced according to loads, health states and processing capacities, which are acquired in real time, of DNS servers, so that dynamic bidirectional migration and balanced distribution of the DNS resolution requests are realized. According to the method, the balance of loads among the nodes is remarkably improved, single-point overload and delay risks are effectively reduced, high availability and response efficiency of DNS services in a large-scale IPv6 environment are guaranteed, and the method is particularly suitable for key industries such as a power grid with extremely high requirements for stability and elasticity.

Description

Technical Field

[0001] This invention belongs to the field of DNS domain name resolution technology, specifically relating to an IPv6 DNS load balancing method based on a bidirectional migration mechanism. Background Technology

[0002] As power grid companies continue their intelligent and digital transformation, their core business systems and various application systems are increasingly reliant on network infrastructure. Key business scenarios such as the power Internet of Things, intelligent dispatching, data acquisition, and remote control are placing higher demands on the network's reliability and availability. To cope with the surge in the number of terminals, the sharp increase in business traffic, and the future sustainable development of the network, the power grid industry is vigorously promoting IPv6 upgrades to expand address resources, improve network security, and support more business innovations.

[0003] In the process of information technology construction in power grid enterprises, DNS (Domain Name System), as the infrastructure for network communication and service addressing, bears the high-concurrency resolution traffic of internal application systems and external collaborative systems. With the large-scale deployment of IPv6, massive terminal access and parallel operation of multiple data centers have become the norm, and the DNS system is facing unprecedented load pressure and performance challenges. However, most mainstream DNS load balancing methods are based on IPv4 environments and adopt unidirectional traffic scheduling or static allocation strategies, which are difficult to efficiently adapt to the complex needs of multiple central nodes and dynamically changing traffic in the IPv6 environment.

[0004] Specifically, existing DNS load balancing mechanisms generally suffer from uneven resource allocation, low node utilization, and slow emergency response when handling high traffic and multi-point coordination in IPv6 scenarios. This not only affects business continuity in power production scheduling and operation and maintenance but also poses risks to information security and system stability. Faced with this new development, how to achieve efficient dynamic scheduling of DNS requests in a large-scale IPv6 network environment has become a critical technical problem that power grid companies urgently need to solve.

[0005] As a dynamic traffic balancing technology, bidirectional migration can flexibly migrate resolution requests between different DNS service nodes by sensing node load information and network status in real time, achieving real-time dynamic adjustment of load. Traditional unidirectional migration strategies can only make limited adjustments between overloaded and lightly loaded nodes, making it difficult to adapt to highly dynamic and complex business environments. In contrast, bidirectional migration can comprehensively consider the load of the entire DNS service cluster, enabling intelligent forward and reverse migration of requests across the entire network. This avoids frequent single-point overload situations, effectively prevents new bottlenecks and migration jitter, and achieves truly persistent and global load balancing. It is more adaptable to the complex needs of large-scale IPv6 network environments, effectively improving server resource utilization, shortening resolution response latency, and enhancing disaster recovery capabilities, thereby improving the overall network infrastructure service level of the power grid industry.

[0006] Against this backdrop, this invention proposes an IPv6 DNS load balancing method based on a bidirectional migration mechanism. Using DNS domain name resolution requests as the allocation unit, and based on real-time collected data on the load, health status, and processing capacity of each DNS server, it employs multi-constraint modeling and introduces an artificial bee colony optimization mechanism to achieve dynamic bidirectional migration and balanced distribution of DNS resolution requests. Its innovation lies in the fact that this method not only allows DNS requests to be migrated from overloaded servers to lightly loaded servers, but also, when necessary, selects specific DNS requests from target servers to migrate to overloaded servers, thereby effectively preventing the recurrence of overload. This method effectively alleviates the performance bottleneck of existing methods in high-concurrency, distributed environments, providing strong support for the intelligent and high-availability of power grid company network architectures. Summary of the Invention

[0007] This invention proposes an IPv6 DNS load balancing method based on a bidirectional migration mechanism. Its core is to use DNS domain name resolution requests as the allocation unit. Based on the real-time collected load, health status and processing capacity of each DNS server, multi-constraint modeling is adopted and an artificial bee colony optimization mechanism is introduced to realize dynamic bidirectional migration and balanced allocation of DNS resolution requests. This effectively avoids the risk of frequent single-point overload and latency of DNS servers, thereby ensuring the high availability and response efficiency of DNS services in a large-scale IPv6 environment.

[0008] 1. A DNS load balancing method based on a bidirectional migration mechanism, specifically implemented according to the following steps (e.g.) Figure 1 As shown):

[0009] Step 1: Monitor the DNS server request status;

[0010] Step 1.1: Collect request and server status data;

[0011] Step 1.1.1: Periodically collect the number of IPv6 resolution requests r of each DNS server. i Average processing latency D i Health Status A i wait.

[0012] Step 1.1.2: Set the time window T for status acquisition, and perform moving average and outlier filtering on each data item;

[0013] Step 1.2, Node load classification;

[0014] Step 1.2.1: Based on the sampled statistics, calculate the average number of requests r per unit time for all nodes. 平均 ;

[0015] Step 1.2.2, set the high load threshold λ high Low load threshold λ low ;

[0016] Steps 1, 2, and 3, if r i >λ high If r is overloaded, then node i is determined to be an "overloaded node"; if r is overloaded, then node i is determined to be an "overloaded node". i <λ low The node identified as a "lightly loaded node" is considered a "normal node".

[0017] Step 2, requesting reallocation triggering and preparation;

[0018] Step 2.1, determine the load balancing status;

[0019] Step 2.1.1: If the system has both "overloaded nodes" and "lightly loaded nodes" at the same time, then enter the load balancing optimization process and jump to step 2.2; otherwise, jump to step 1.

[0020] Step 2.2, Determine the set of requests to be optimized;

[0021] Step 2.2.1: Summarize the set of domain name resolution requests to be migrated on the "overloaded node". The set of requests to be allocated is denoted as R = {r1, r2, ..., r...} m}

[0022] Step 2.2.2, each parsing request r to be assigned j It includes attributes such as target domain name, priority, historical arrival rate, and target latency requirements.

[0023] Step 3: Model multi-constraint request allocation to ensure maximum load balance (as evenly as possible in request distribution), minimize overall average response latency, and minimize migration disturbances.

[0024] Step 4: Bidirectional migration scheduling of requests based on artificial bee colonies;

[0025] Step 4.1, global search using bee colony algorithm;

[0026] Step 4.1.1: Use the current request-node mapping as the initial honey source for the solution space;

[0027] Step 4.1.2, Hired Bee Phase: Attempt to migrate some high-priority requests between overloaded nodes and lightly loaded nodes, and synchronously migrate low-priority requests back to lightly loaded nodes to achieve bidirectional swapping;

[0028] Step 4.1.3, Observation phase: Evaluate the fitness of the solution (see step 5) and select a new solution with probability;

[0029] Step 4.1.4, Reconnaissance Bee Phase: Perturb the current allocation structure to escape local optima;

[0030] Step 4.2, refine the bidirectional migration mechanism: For each overloaded node, prioritize migrating high-load and latency-sensitive requests to the optimal light-load node; for the target light-load node, appropriately migrate some low-priority and non-critical business requests back to the original node or other nodes with moderate load.

[0031] Step 5: Select the optimal solution based on the fitness function to ensure that the load of all DNS server nodes is as balanced as possible, the migration cost is low, the latency is optimal, and the overall availability of the DNS cluster is not reduced due to the migration decision.

[0032] Step 6: Execute the request allocation scheme and provide adaptive feedback;

[0033] Step 6.1: Perform optimal allocation;

[0034] Step 6.1.1: Based on the optimal scheduling result, dynamically allocate the domain name resolution requests to each target node;

[0035] Step 6.1.2: Update the DNS resolution policy and update the load balancing configuration of each DNS server;

[0036] Step 6.2, continuous monitoring and feedback;

[0037] Step 6.2.1: Re-enter Step 1 to collect and evaluate the system status again, and realize the adaptive closed-loop optimization of the algorithm. If the program stops running, jump to Step 7.

[0038] Step 7, End.

[0039] The multi-constraint request allocation modeling mentioned in section 2.1 specifically involves establishing a scheduling target and constraint model, as follows:

[0040] Assume there are n DNS server nodes, m requests to be assigned, and a binary assignment variable x. ijThis indicates that the j-th request is assigned to the i-th node:

[0041]

[0042] Constraints:

[0043] (1) Uniqueness constraint: Each request is assigned to only one node.

[0044]

[0045] (2) Node capacity constraint: The total number of requests after allocation to each node shall not exceed the maximum capacity C. i

[0046]

[0047] (3) Processing delay constraint: The estimated average processing delay of each node shall not exceed the threshold D. i，max

[0048]

[0049] (4) Health constraint: Only requests are allowed to be assigned to healthy nodes.

[0050] A i =1,x ij ≠0

[0051] (5) Migration Disturbance Constraint: The total number of migration requests M in this round shall not exceed the set upper limit M. max

[0052]

[0053] The fitness function mentioned in section 3.1 is detailed below:

[0054] Let the system have n DNS servers, and the load on each node after the migration be l1, l2, ..., l n Average load l 平均 The fitness function can be set as a weighted combination of multiple objectives:

[0055] F = α·f balance +β·f cost +γ·f delay +δ·f avail

[0056] in:

[0057] α, β, γ, and δ are weighting factors, where α + β + γ + δ = 1, and can be adjusted according to actual business needs.

[0058] (1) Load uniformity measurement function

[0059]

[0060] ● The larger the value, the better. Take 1 for perfect load balance, and the smaller the value for uneven load.

[0061] (2) Migration cost function

[0062]

[0063] ●C mig This represents the total cost, including total traffic / bandwidth consumption, for this migration.

[0064] ●C max The maximum acceptable migration cost (can be set to a historical maximum or a business threshold);

[0065] The smaller the value of v, the better; 1 represents zero cost.

[0066] (3) Latency performance function. Overall average DNS response time after migration:

[0067]

[0068] vD avg，new Weighted average resolution latency for all DNS server nodes after migration;

[0069] ●D max The longest acceptable average response time;

[0070] The larger v is, the better;

[0071] (4) Cluster availability function, reflecting the proportion of unhealthy nodes after migration:

[0072]

[0073] ●N unhealthy This indicates the number of servers detected as having low health status (such as high load, service unavailability, or synchronization failure) after the migration.

[0074] Compared with existing technologies, the advantages of this invention lie in its ability to more dynamically and intelligently allocate and adjust resolution requests among DNS servers, achieving real-time bidirectional optimized allocation of resources. This method not only significantly improves the load balancing among nodes but also effectively reduces the risk of single-point overload and latency, thereby ensuring the high availability and response efficiency of DNS services in large-scale IPv6 environments. It is particularly suitable for critical industries such as power grids that have extremely high requirements for stability and resilience. Attached Figure Description

[0075] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0076] Figure 1 This is the overall flowchart of the method of the present invention, namely the IPv6 DNS load balancing method based on bidirectional migration mechanism;

[0077] Figure 2 This is a schematic diagram illustrating a specific implementation example of the bidirectional migration method of the present invention. It is not part of the invention itself, but is only used as an auxiliary illustration of the algorithm of the present invention.

[0078] Figure 3 This is a schematic diagram illustrating a traditional one-way migration implementation example. It is not part of the invention of this patent and is only used as an auxiliary illustration of the algorithm of this invention. Detailed Implementation

[0079] The present invention will now be described in detail with reference to the embodiments shown in the accompanying drawings. However, it should be noted that these embodiments are not intended to limit the present invention. Functions and methods performed by those skilled in the art based on these embodiments are all within the protection scope of the present invention.

[0080] This patent proposes an IPv6 DNS load balancing method based on a bidirectional migration mechanism, which is implemented according to the following steps (illustrated with examples):

[0081] The present invention will now be described in detail with reference to the embodiments shown in the accompanying drawings. However, it should be noted that these embodiments are not intended to limit the present invention. Functions and methods performed by those skilled in the art based on these embodiments are all within the protection scope of the present invention.

[0082] This invention belongs to the field of DNS domain name resolution, specifically relating to an IPv6 DNS load balancing method based on a bidirectional migration mechanism. Its innovation lies in the fact that this method not only allows DNS requests to be migrated from overloaded servers to lightly loaded servers, but also, when necessary, selects specific DNS requests from target servers to migrate to overloaded servers, thereby effectively preventing the recurrence of overload. Furthermore, this invention incorporates multi-dimensional constraints such as node capacity, latency thresholds, and health to ensure the rationality of allocation decisions and high system availability.

[0083] Compared with existing technologies, the advantages of this invention lie in its ability to more dynamically and intelligently allocate and adjust resolution requests among DNS servers, achieving real-time bidirectional optimized allocation of resources. This method not only significantly improves the load balancing among nodes but also effectively reduces the risk of single-point overload and latency, thereby ensuring the high availability and response efficiency of DNS services in large-scale IPv6 environments. It is particularly suitable for critical industries such as power grids that have extremely high requirements for stability and resilience.

[0084] This patent proposes an IPv6 DNS load balancing method based on a bidirectional migration mechanism, which is implemented according to the following steps (illustrated with examples):

[0085] like Figure 3 As shown, in a provincial power grid monitoring center, an IPv6 DNS cluster provides large-scale domain name resolution services for substations, distribution networks, smart power terminals, and dispatching systems across various regions. The platform deploys six DNS server nodes (DNS-1 to DNS-6), responsible for domain name resolution for local terminals and distributed data acquisition devices. These nodes serve smart data acquisition systems in different counties and cities, with significant peak-valley variations in workload. The cluster has long employed a traditional "one-way migration" strategy (i.e., only migrating requests from overloaded nodes to the lightest-loaded node), but this frequently results in new overloads after migration and severe migration jitter, affecting the continuity of power grid services and dispatch coordination. To optimize system performance, the bidirectional migration mechanism proposed in this invention is adopted, enabling global collaborative optimization of each request allocation. This breaks the limitations of frequent new overloads under traditional one-way migration, truly achieving intelligent, elastic, and stable dispatching of large-scale DNS services for the power grid, providing a solid guarantee for intelligent power dispatching and the safe operation of terminals.

[0086] Step 1: Monitor the DNS server request status;

[0087] Step 1.1: Collect request and server status data;

[0088] Step 1.1.1, collect the following data:

[0089]

[0090] Step 1.1.2: Use a 5-minute sliding window to perform mean and outlier handling; the current data is valid.

[0091] Step 1.2, Node load classification;

[0092] Step 1.2.1, Calculate the average number of requests:

[0093] r 平均 = (109000 + 101000 + 63000 + 51000 + 34000 + 27000) / 6 = 64167

[0094] Step 1.2.2, set the high load threshold λ high =100000, low load threshold λ low =40000;

[0095] Step 1.2.3 Classify them according to the number of server requests:

[0096] Overloaded servers: DNS-1, DNS-2;

[0097] "Normal" servers: DNS-3, DNS-4;

[0098] Lightly loaded servers: DNS-5, DNS-6;

[0099] Step 2, requesting reallocation triggering and preparation;

[0100] Step 2.1: Determine if both "overloaded" and "lightly loaded" nodes exist simultaneously, and trigger load balancing optimization;

[0101] Step 2.2, Determining the set of requests to be optimized: Summarize the requests to be migrated, and prioritize high-priority and latency-critical business flows from overloaded nodes. In this example, DNS-1 and DNS-2 select 30,000 and 20,000 indivisible urgent business flows as migration candidates, respectively, to obtain the candidate set R = {DNS-1: 30,000, DNS-2: 20,000}. Each request carries a business attribute tag, including the target domain name, priority, arrival rate, and latency requirements, etc.

[0102] Step 3: Multi-constraint request assignment modeling, establishing assignment variable x ij Assume that the uniqueness, capacity, delay, health, and disturbance constraints are all satisfied;

[0103] Step 4: Bidirectional migration scheduling of requests based on artificial bee colonies;

[0104] Step 4.1, global search using bee colony algorithm;

[0105] Step 4.1.1: Using the current request-node allocation as the initial honey source, then migrate 30,000 and 20,000 requests from overloaded nodes to lightly loaded nodes: DNS-1→DNS-5, DNS-2→DNS-6;

[0106] Step 4.1.2: Generate the Migration Request Suggestion Table for Hired Bees;

[0107] Step 4.1.3: Observe the bees to find a more balanced load solution;

[0108] Step 4.1.4: The scout bee disturbs the plan and weighs the new migration;

[0109] Step 4.2 Bidirectional migration refinement: To avoid "light load turning into new overload" caused by unidirectional migration, the swarm synchronously explores "reverse migration" opportunities: Select 10,000 non-divisible periodic statistical requests from DNS-5 and DNS-6 with the lowest priority, and migrate them back to DNS-1 and DNS-2 (where the current load is moderate).

[0110] The proposed solution is as follows (50,000 overloaded nodes migrate out, requesting priority to be transferred to resilient, lightly loaded nodes; 20,000 lightly loaded nodes proactively migrate back to "quasi-normal" nodes to ensure they do not become overloaded):

[0111] DNS-1 migrates out 30000, DNS-5 receives;

[0112] DNS-2 migrates out 20000, DNS-6 receives it;

[0113] DNS-5 migrates 10000 back to DNS-1, and DNS-6 migrates 10000 back to DNS-2.

[0114] Step 5: Fitness calculation and optimal allocation scheme;

[0115] Calculated step-by-step based on the fitness function F:

[0116] Calculate the load balance of all nodes;

[0117] Assess the total cost of the migration request / the "disturbance" to the cluster;

[0118] Estimate the average latency variation and the service priority fulfillment rate;

[0119] Check health restrictions.

[0120] The output execution allocation scheme demonstrates better load balancing than the unmigrated scheme, with lightly loaded nodes not being overloaded, all servers being healthy, and the scheme exhibiting high adaptability. The node allocation is as follows (after migration and relocation):

[0121]

[0122]

[0123] Step 6: Execute the allocation plan and provide feedback;

[0124] Step 6.1: Schedule the specific allocation, configure the DNS resolution policy and allocation table, and dynamically allocate all migration / return requests to the target node;

[0125] Step 6.2, Continuous monitoring and feedback: During peak business periods, DNS-5 / 6 reserved space allows for flexible re-migration, and no single point of overload occurred subsequently. The entire network DNS remained stable, migration was flexible, and business continuity was ensured.

[0126] Step 7, End.

[0127] Figure 2 As an example illustrating the drawbacks of the one-way migration method: If only one-way migration is used (without allowing back migration), when peak periods arrive, the lightly loaded nodes (such as DNS-5 and DNS-6) that are "migrated in" will become new overloaded nodes due to overcrowding, and repeated migrations will create single-point jitter. Specific results example:

[0128] After DNS-1 migrated 30,000 to DNS-5, the DNS-5 load became 64,000. After DNS-2 migrated 20,000 to DNS-6, the DNS-6 load became 47,000.

[0129] If the DNS-5 local traffic suddenly increases by 40,000 in the next cycle, it will instantly reach 104,000, becoming a new overload, and then there will be no lightly loaded servers available for migration.

[0130] Furthermore, if only one-way migration is performed, there may be no empty nodes available afterward, and the cluster may fall into a migration dead loop.

[0131] The detailed descriptions listed above are merely specific descriptions of feasible embodiments of the present invention, and are not intended to limit the scope of protection of the present invention. All equivalent embodiments or modifications made without departing from the spirit of the present invention should be included within the scope of protection of the present invention.

[0132] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, it is intended that all variations falling within the meaning and scope of equivalents of the claims be included within the present invention.

Claims

1. A method for IPv6 DNS load balancing based on a bidirectional migration mechanism, comprising: Step 1: Monitor the DNS server request status; Step 1.1: Collect request and server status data; Step 1.1.1, periodically collect the number of IPv6 resolution requests r of each DNS server i , average processing delay D i , health status A i , etc. Step 1.1.2: Set the time window T for status acquisition, and perform moving average and outlier filtering on each data item; Step 1.2, Node load classification; Step 1.2.1, according to the sampling statistics value, calculate the average number of requests per unit time r of all nodes 平均 ; Step 1.2.2, set high load threshold λ high , low load threshold λ low ; Step 1.2.3, if r i > λ high , then node i is determined as an overload node; if r i < λ low , it is determined as a light load node, and the rest are normal nodes; Step 2, requesting reallocation triggering and preparation; Step 2.1, determine the load balancing status; Step 2.1.1: If the system has both overloaded and lightly loaded nodes, then proceed to the load balancing optimization process and jump to step 2.2; otherwise, jump to step 1. Step 2.2, Determine the set of requests to be optimized; Step 2.2.1, aggregate the domain name resolution request set to be migrated on the overloaded node, and the request set to be allocated is denoted as R = {r1, r2, …, r m} Step 2.2.2, each to-be-assigned resolution request r j With attributes: target domain name, priority, historical arrival rate, target latency requirement, etc. Step 3: Model multi-constraint request allocation to ensure maximum load balancing, make request allocation as even as possible, minimize overall average response latency, and keep migration disturbances as low as possible. Step 4: Bidirectional migration scheduling of requests based on artificial bee colonies; Step 4.1, global search using bee colony algorithm; Step 4.1.1: Use the current request-node mapping as the initial honey source for the solution space; Step 4.1.2, Hired Bee Phase: Attempt to migrate some high-priority requests between overloaded nodes and lightly loaded nodes, and synchronously migrate low-priority requests back to lightly loaded nodes to achieve bidirectional swapping; Step 4.1.3, Observation phase: Evaluate the fitness of the proposed solution and select a new solution based on probability; Step 4.1.4, Reconnaissance Bee Phase: Perturb the current allocation structure to escape local optima; Step 4.2, refine the bidirectional migration mechanism: For each overloaded node, prioritize migrating high-load and latency-sensitive requests to the optimal light-load node; for the target light-load node, appropriately migrate some low-priority and non-critical business requests back to the original node or other nodes with moderate load. Step 5: Select the optimal solution based on the fitness function to ensure that the load of all DNS server nodes is as balanced as possible, the migration cost is low, the latency is optimal, and the overall availability of the DNS cluster is not reduced due to the migration decision. Step 6: Execute the request allocation scheme and provide adaptive feedback; Step 6.1: Perform optimal allocation; Step 6.1.1: Based on the optimal scheduling result, dynamically allocate the domain name resolution requests to each target node; Step 6.1.2: Update the DNS resolution policy and update the load balancing configuration of each DNS server; Step 6.2, continuous monitoring and feedback; Step 6.2.1: Re-enter Step 1 to collect and evaluate the system status again, and realize the adaptive closed-loop optimization of the algorithm. If the program stops running, jump to Step 7. Step 7, End.

2. The IPv6 DNS load balancing method based on a bidirectional migration mechanism according to claim 1, wherein, Multi-constraint request allocation modeling, specifically establishing a scheduling target and constraint model, as follows: Assume that there are n DNS server nodes, m requests to be allocated, binary allocation variable x ij denotes that the jth request is allocated to the ith node: Constraints: Uniqueness constraint: Each request is assigned to only one node. Node capacity constraint: total request amount after allocation of each node does not exceed maximum carrying capacity C i Processing latency constraint: The estimated average processing latency of each node does not exceed the threshold D. i，max Health constraint: Only requests are allowed to be assigned to healthy nodes. A i =1,x ij ≠0; Migration Disturbance Constraint: The total number of migration requests M in this round shall not exceed the set upper limit M. max 3. The IPv6 DNS load balancing method based on a bidirectional migration mechanism according to claim 1, wherein, The fitness function is as follows: Let the system have n DNS servers, and the load on each node after the migration be l1, l2, ..., l n Average load l 平均 The fitness function can be set as a weighted combination of multiple objectives: F=α·f balance +β·f cost +γ·f delay +δ·f avail ; in: α, β, γ, and δ are weighting factors, where α + β + γ + δ = 1, and can be adjusted according to actual business needs. Load uniformity measurement function: The larger the value, the better. A value of 1 is used for perfect load balance, and the smaller the value is for uneven load. Migration cost function: C mig This represents the total cost, including total traffic / bandwidth consumption, for this migration. C max The maximum acceptable migration cost can be set to the historical maximum value or a business threshold; the smaller the better, 1 represents zero cost. Latency performance function; Overall DNS average response latency after migration: D avg，new Weighted average resolution latency for all DNS server nodes after migration; D max The longest acceptable average response time; The bigger the better; Cluster availability function, reflecting the proportion of unhealthy nodes after migration: N unhealthy This indicates the number of servers with low health status detected after the migration.

Images