IPv6-oriented distributed DNS load balancing optimization method

Abstract

The invention belongs to the field of DNS (Domain Name Server) domain name resolution, and particularly relates to an IPv6 (Internet Protocol Version 6)-oriented distributed DNS load balancing optimization method. An existing distributed DNS (Domain Name Server) system has the problems that the analysis delay is increased, the communication overhead is too high and the service stability is reduced due to unbalanced server load when facing massive address space and dynamic flow distribution in an IPv6 (Internet Protocol Version 6) environment, and the requirements of scenes such as a smart power grid and the Internet of Things on efficient domain name analysis are difficult to meet. Therefore, by optimizing the distribution and migration decision of the DNS request, the weight is dynamically adjusted by adopting a multi-objective optimization and Jaya improved genetic algorithm, and the global load balancing is realized. In addition, the invention further provides a staged migration strategy, the complexity and the communication overhead are reduced, and the stability and the efficiency of the DNS service are improved. The method has the advantages that the analysis delay is remarkably reduced, the request processing efficiency is improved, and an efficient and reliable solution is provided for the distributed DNS service of a power grid company in a smart power grid and Internet of Things scene.

Description

Technical Field

[0001] The present invention belongs to the technical field of DNS domain name resolution, and particularly relates to an optimized method for distributed DNS load balancing for IPv6. Background Art

[0002] With the rapid development of the Internet, the IPv4 address resources are gradually exhausted. As the next-generation Internet protocol, IPv6 has become the mainstream trend of global network development with its huge address space, higher security, and better network performance. In power grid companies, the wide application of smart grids and the Internet of Things has led to an exponential growth in the number of devices, and the traditional IPv4 network can no longer meet the needs of unique device identification and efficient communication. The introduction of IPv6 not only solves the problem of insufficient address resources but also provides technical support for network architecture optimization and service performance improvement.

[0003] The Domain Name System (DNS) is one of the core infrastructures of the Internet and is responsible for resolving domain names into IP addresses, which is a key link in network communication. However, in the power grid Internet of Things, there are a large number of nodes and various types of devices (such as smart meters, sensors, controllers, etc.), which require frequent communication and efficient addressing. Therefore, a naming service similar to DNS, called the Object Name Service (ONS), is introduced. ONS is mainly oriented to the Internet of Things scenario and can provide unique identification and efficient access path resolution for a large number of nodes. Compared with traditional DNS, ONS needs to handle a large number of instantaneous requests in the Internet of Things, such as power grid scheduling, device status updates, or emergencies (such as fault recovery), which poses higher requirements for the high-concurrency processing ability of the system. For the sake of simplicity in narration, DNS and ONS will be uniformly described as DNS in the following text of this article. However, it should be clear that the DNS service in the power grid Internet of Things actually includes the functional extension of ONS and is optimized specifically for the Internet of Things scenario.

[0004] With the continuous expansion of the network scale of power grid companies, the traditional centralized DNS architecture has gradually exposed performance bottlenecks and is difficult to meet the requirements of high concurrency, low latency, and high reliability. The distributed DNS architecture can effectively improve the resolution efficiency, reduce network latency, and enhance the disaster tolerance of the system by deploying DNS servers on multiple nodes, becoming the main direction for optimizing DNS services in power grid companies. In the distributed DNS architecture, load balancing is a key factor affecting system performance. Traditional load balancing methods (such as round-robin, random allocation) are difficult to adapt to the complex network environment and dynamic traffic demands of power grid companies. Especially in the IPv6 environment, the expansion of the address space and the change of traffic patterns pose higher requirements for DNS load balancing. In addition, the special requirements of the power grid company's network further exacerbate the challenges of DNS service optimization. The smart grid involves multiple links such as power generation, transmission, distribution, and power consumption, with a wide variety of devices, including smart meters, sensors, controllers, etc. Frequent communication is required between these devices, so there are a large number of concurrent requests in the power grid. Especially during peak hours or emergencies (such as power dispatching, fault recovery), server load imbalance is likely to occur.

[0005] Therefore, the present invention proposes an IPv6-oriented distributed DNS load balancing optimization method, aiming to solve the performance bottleneck problem caused by server load imbalance in the distributed DNS system. By optimizing the allocation and migration decisions of DNS requests, this method adopts a multi-objective optimization method to unify migration cost, resolution delay, and load balancing into the decision-making model, and dynamically adjusts the weight parameters through an improved genetic algorithm to achieve global load balancing. Combining the address hierarchy and routing characteristics of IPv6, this method can significantly reduce DNS resolution delay and improve request processing efficiency in a dynamic traffic environment, providing an efficient and reliable solution for the large-scale distributed DNS services of power grid companies in the scenarios of smart grid and Internet of Things. Summary of the Invention

[0006] The present invention proposes an IPv6-oriented distributed DNS load balancing optimization method, the core of which is to optimize the allocation and migration decisions of DNS requests, adopt multi-objective optimization and an improved genetic algorithm of Jaya to dynamically adjust the weights, achieve global load balancing, and provide an efficient and reliable solution for the distributed DNS services of power grid companies in the scenarios of smart grid and Internet of Things.

[0007] The implementation of the present invention provides an IPv6-oriented distributed DNS load balancing optimization method, which specifically includes:

[0008] Step 1, initialize the DNS server set. According to the DNS server set C, initialize the candidate resolution request dictionary W, the load distribution L dist and the migration plan set M*;

[0009] Step 2, perform load detection on each DNS server, and calculate the load j fluctuation coefficient and load utilization rate λ of each DNS server C. When λ j is greater than the minimum threshold of the load utilization rate and j less than the maximum threshold of the fluctuation coefficient within consecutive T cycles, mark DNS server C as an overloaded server, and directly add it to the overloaded set O subsequently; j

[0010] Step 3, divide the DNS servers by calculating the load ratio into three groups: underloaded set U, stable set M, and overloaded set O;

[0011] Step 4, candidate resolution request selection. For each overloaded server C j ∈O, filter the associated resolution request set R j and add them to the candidate resolution request set W j one by one according to the priority evaluation until the load is relieved. Finally, store all candidate sets W j in the candidate resolution request dictionary W;

[0012] Step 5, adopt a multi-objective optimization and improved Jaya genetic algorithm to generate a request migration plan. First, dynamically optimize the weight parameters of the fitness function to achieve a flexible balance among multiple performance metrics for the migration strategy. After the weight adjustment is completed, use the improved genetic algorithm for global search and evolutionary iteration to find the optimal migration plan M* in the high-dimensional complex decision space. Among them, the multiple performance metrics include: migration cost, resolution delay, and load balancing;

[0013] Step 6, according to the generated migration plan M*, adopt a phased migration strategy to execute the migration plan. At the same time, ensure the consistency of the global DNS view through status synchronization among DNS servers;

[0014] Step 7, monitor the status changes of each DNS server. When it is detected that there are significant changes in the server load or traffic distribution, jump to Step 2 to continue load detection and optimization. Otherwise, jump to Step 8;

[0015] Step 8, end.

[0016] The optional multi-objective optimization and improved Jaya genetic algorithm is specifically implemented according to the following steps:

[0017] Step 1: According to the load detection results, determine the overloaded server set O and the lightly loaded server set U, initialize the candidate parsing request dictionary W as empty, and generate the initial migration plan set k = {k 1 , k 2 , …, k n}, where each group of plans focuses on different optimization goals;

[0018] Step 2: Considering the migration cost, parsing delay, and load imbalance degree comprehensively, define the fitness function F:

[0019] F = α·MRtotal + β·NRL + γ·Lbalance

[0020] where the meanings of the parameters are as follows:

[0021] MRtotal: Migration cost, representing the cost of migrating the parsing request from the overloaded server to the target server;

[0022] NRL: Network response latency, representing the change in latency of the parsing request after migration;

[0023] Lbalance: Load imbalance degree, representing the balance degree of the loads of each server after migration;

[0024] α, β, γ: Weight parameters of the fitness function;

[0025] Step 3: Dynamically adjust the weight parameters α, β, γ of the fitness function through the Jaya-improved genetic algorithm;

[0026] Step 3.1: Randomly generate N groups of weight combinations Q = {Q 1 , Q 2 , …, Q p};

[0027] Step 3.2: Calculate the average fitness value of each group of weight combinations on the initial migration plan set k;

[0028] Step 3.3: Find the optimal weight combination Q best and the worst weight combination Q worst ; among them, Q best is the lowest average fitness value, and Q worst is the highest average fitness value;

[0029] Step 3.4: Update the weight combination, and perform normalization processing on the updated weight combination; the update calculation is as follows:

[0030] Q p_new = Q p + r 1 ·(Q best - |Q p|)-r 2 ·(Q worst -|Q p |)

[0031] Among them, r 1 and r 2 are random numbers;

[0032] Step 3.5, after reaching the maximum number of iterations, output the optimal weight combination Q best ;

[0033] Step 4, according to the candidate parsing request dictionary W and the light-load server set U, generate Popsize initial migration plans and encode them as chromosomes. Each chromosome is an array of length m, where the array subscript represents the parsing request to be migrated, and the array value represents the corresponding target server, thereby representing the mapping relationship between all parsing requests to be migrated and the target servers;

[0034] Step 5, iteratively optimize the population to determine the optimal migration plan,

[0035] Step 5.1, retain the top 10% of the individuals with the best fitness values and directly enter the next generation;

[0036] Step 5.2, randomly select k individuals from the remaining population and select the one with the best fitness as the parent;

[0037] Step 5.3, according to the crossover probability P c , perform crossover on the parents to generate offspring. The crossover points are preferentially selected in the regions with lower fitness values. The crossover probability is dynamically adjusted and calculated as:

[0038] P c_new =P c ·(1 - t / max)

[0039] Among them, t is the current number of iterations, and max is the maximum number of iterations;

[0040] Step 5.4, according to the mutation probability P m , perform mutation on the offspring, randomly change one gene position. The mutation probability is dynamically adjusted and calculated as:

[0041] P m_new =P m ·(1 - t / max)

[0042] Among them, t is the current number of iterations, and max is the maximum number of iterations;

[0043] Step 5.4, combine the elite individuals and the offspring after crossover and mutation into a new population to avoid premature convergence and improve the search efficiency;

[0044] Step 6, when the maximum number of iterations is reached, return the solution M* with the highest fitness value as the optimal migration plan, where M* contains the target server allocation plan for each parsing request;

[0045] Step 7, end.

[0046] Optionally, the phased migration strategy is specifically implemented according to the following steps:

[0047] Step 1, perform preliminary migration preparations;

[0048] Step 1.1, according to the optimal migration plan M*, determine the set R of parsing requests to be migrated and the set C of target DNS servers;

[0049] Step 1.2, divide the set R of parsing requests into multiple subsets {R 1 , R 2 , …, R n} according to the priority and migration cost. Each subset corresponds to a migration stage, and the parsing requests in the high-latency area and on the servers with high load will be migrated first.

[0050] Step 1.3, synchronize the status information between the target DNS server and the source DNS server, including cache data and parsing records;

[0051] Step 2, perform phased migration;

[0052] Step 2.1, according to the divided subsets {R 1 , R 2 , …, R n}, migrate the parsing requests from the source DNS server to the target DNS server stage by stage;

[0053] Step 2.2, monitor the load change and network latency of the target DNS server in real time to ensure that the migration will not cause new overload problems. If the load of the target server is close to the threshold, suspend the migration or reallocate the parsing requests;

[0054] Step 3, update and synchronize the domain name parsing table;

[0055] Step 3.1, after each stage of migration is completed, update the global parsing table and remap the migrated parsing requests to the target DNS server;

[0056] Step 3.2, through the communication between DNS servers, synchronize the global view to avoid parsing failures caused by inconsistent parsing tables;

[0057] Step 4: Detect the load balancing situation of each DNS server to ensure that the load balancing degree Lbalance reaches the expected target. If it is found that there are still overload or latency problems with some servers, re - execute the load detection and optimize the migration plan;

[0058] Step 5: End.

[0059] Compared with the prior art, the advantages of the present invention are that it takes into account the address hierarchical and routing characteristics of IPv6, realizes global load balancing by dynamically optimizing DNS request allocation and migration decisions, significantly reduces the resolution latency and communication overhead, and improves the request processing efficiency and system stability. This method adopts a multi - objective optimization model and an improved genetic algorithm, which can dynamically adapt to traffic changes, reduce resource consumption, and is especially suitable for the large - scale distributed network requirements of the smart grid and Internet of Things scenarios of power grid companies, providing an efficient and reliable solution for DNS services. Brief Description of the Drawings

[0060] Figure 1 is the overall flowchart of the method of the present invention, namely the distributed DNS load balancing optimization method for IPv6.

[0061] Figure 2 is the flowchart of the multi - objective optimization and improved Jaya genetic algorithm in the method of the present invention.

[0062] Figure 3 is a schematic diagram before the migration execution of a specific implementation example of the method of the present invention. It is not the content of this patent invention and is only used as an auxiliary explanation of the algorithm of the present invention.

[0063] Figure 4 is a schematic diagram during the migration execution of a specific implementation example of the method of the present invention. It is not the content of this patent invention and is only used as an auxiliary explanation of the algorithm of the present invention.

[0064] Figure 5 is a schematic diagram after the migration execution of a specific implementation example of the method of the present invention. It is not the content of this patent invention and is only used as an auxiliary explanation of the algorithm of the present invention. Detailed Description of the Preferred Embodiments

[0065] The present invention will be described in detail below in conjunction with the embodiments shown in the drawings. However, it should be noted that these embodiments are not limitations on the present invention, and the functions and methods made by those of ordinary skill in the art according to these embodiments all fall within the protection scope of the present invention.

[0066] As Figure 3 shown, a power grid company has deployed a distributed DNS system to support the domain name resolution services of smart grid and Internet of Things devices. The system contains 5 DNS servers, namely C 1 、C 2 、C3 , C 4 , C 5 , are respectively responsible for the parsing requests of regions 1, 2, 3, 4, and 5. Therefore, in this system, the client (such as PC, mobile phone, Internet of Things device, etc.) sets a fixed DNS server through static configuration or dynamic acquisition (such as DHCP) to send domain name resolution requests. Taking Figure 3 as an example, the client requests in region 1 are sent to server C 1 , the client requests in region 2 are sent to server C 2 , the client requests in region 3 are sent to server C 3 , the client requests in region 4 are sent to server C 4 , and the client requests in region 5 are sent to server C 5 . However, this fixed configuration method has significant limitations: during peak hours, some DNS servers may be overloaded due to a surge in requests, while other servers are underloaded, resulting in uneven overall resource utilization of the system and unable to achieve dynamic load balancing.

[0067] To solve this problem, the system newly adds a DNS server cluster management device to dynamically migrate DNS requests according to the real-time load status of DNS servers (such as load utilization rate, response latency, etc.). When it detects that a server is overloaded, the management device will trigger the load balancing optimization process. Taking Figure 3 as an example, servers C 1 , C 3 are overloaded during peak hours, while other servers C 4 , C 5 are underloaded. At this time, requests R 1 , R 1.1 originally assigned to C 1.2 at the same time and requests R 3 , R 3.1 originally assigned to C 3.2 need to be migrated. Through the distributed DNS load balancing optimization method for IPv6 proposed by the present invention, the system dynamically adjusts the allocation of parsing requests, migrates some requests to servers with lower loads, thereby effectively alleviating the overload problem and improving the overall performance and resource utilization efficiency of the system. The method is implemented according to Figure 1 the method steps as follows (illustrated with examples):

[0068] Step 1, according to the DNS server set C, initialize the candidate parsing request dictionary W to be empty, the load distribution L dist and the migration plan set M*, and the initial load distribution is as follows:

[0069] ·C 1 : 85% (overloaded)

[0070] ● C 2 : 60% (stable)

[0071] ● C 3 : 90% (overload)

[0072] ● C 4 : 40% (underload)

[0073] ● C 5 : 30% (underload)

[0074] Step 2, perform load detection on each DNS server. Calculate the load j fluctuation coefficient and load utilization rate λ of each DNS server C j . It is detected that the loads of C 1 and C 3 are 85% and 90% respectively, exceeding the load threshold of 80%, and the fluctuation coefficient is lower than the maximum fluctuation coefficient threshold of 10%. Therefore, mark C 1 and C 3 as overloaded servers and add them to the overload set O = {C 1 , C 3}.

[0075] Step 3, divide the DNS servers by calculating the load ratio. According to the load ratio, divide the servers into three categories:

[0076] ● Overload set O: {C 1 , C 3}.

[0077] ● Stable set M: {C 2}.

[0078] ● Underload set U: {C 4 , C 5}.

[0079] Step 4, candidate resolution request selection. For the overloaded servers C 1 and C 3 , filter the associated resolution request sets R 1 and R 3 , and evaluate the candidate resolution requests according to the priority: For C 1 , filter some requests R 1.1 , R 1.2 in R1 and add them to the candidate resolution request set W 1 , until the load of C 1 is reduced to below 80%; For C 3 , filter R3 Part of the request R 3.1 、R 3.2 is added to the candidate parsing node set W3 until C 3 The load is reduced to less than 80%. Finally, the candidate parsing request dictionary W = {W 1 ,W 3}.

[0080] Step 5, use the multi-objective optimization and Jaya-improved genetic algorithm to generate a request migration plan, that is Figure 2 the method steps of. According to the candidate parsing request dictionary W, construct the migration plan set M*. By dynamically adjusting the weight parameters of the fitness function, use the improved genetic algorithm for global search and evolutionary iteration to generate the optimal migration plan:

[0081] ● Migrate R 1.1 from C 1 to C 5 .

[0082] ● Migrate R 1.2 from C 1 to C 4 .

[0083] ● Migrate R 3.1 from C 3 to C 5 .

[0084] · Migrate R 3.2 from C 3 to C 4 .

[0085] Step 6, according to the generated migration plan M*, adopt a phased migration strategy to execute the migration plan and update the relevant parsing tables. At the same time, through the status synchronization between DNS servers, ensure the consistency of the global DNS view, as Figure 4 shown, complete the following migrations:

[0086] ● Migration stage 1: Migrate R 3.1 to C 5 , and synchronously update the parsing table of C 5 .

[0087] ● Migration stage 2: Migrate R 1.1 to C 5 , and synchronously update the parsing table of C 5 .

[0088] ● Migration stage 3: Migrate R 3.2 to C 4 , and synchronously update the parsing table of C 4 .

[0089] ● Migration Phase 4: Migrate R 1.2 to C 4 , and synchronously update the parsing table of C 4 .

[0090] Step 7, monitor the status changes of each DNS server. As Figure 5 shown, when it is detected that the loads of C 1 and C 3 have recovered to below 80%, and no new overload phenomena occur in other servers C 4 , C 5 either, this round of optimization is completed.

[0091] Step 8, end.

[0092] The series of detailed descriptions listed above are only specific descriptions of the feasible implementation manners of the present invention, and they are not intended to limit the protection scope of the present invention. Any equivalent implementation manners or modifications made without departing from the technical spirit of the present invention should be included in the protection scope of the present invention.

[0093] For those skilled in the art, it is obvious that the present invention is not limited to the details of the above-described exemplary embodiments, and can be implemented in other specific forms without departing from the spirit or basic characteristics of the present invention. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-limiting. The scope of the present invention is defined by the appended claims rather than the above description. Therefore, it is intended to embrace all changes falling within the meaning and scope of the equivalent elements of the claims in the present invention.

Claims

1. A distributed DNS load balancing optimization method is implemented according to the following steps: Step 1: Initialize the DNS server set. According to the DNS server set C, initialize the candidate resolution request dictionary W and load distribution L. dist and the set of migration schemes M*; Step 2: Perform load detection on each DNS server and calculate the C j Load Volatility and load utilization λ j , when λ is satisfied in T consecutive cycles j Greater than the minimum load utilization threshold and When the fluctuation coefficient is less than the maximum threshold, DNS server C j Mark as an overloaded server and add it to the overload set O directly later; Step 3, divide the DNS servers into three groups: underload set U, stable set M, and overload set O by calculating the load ratio; Step 4: Candidate resolution request selection, for each overloaded server C j ∈O, filter the set of resolution requests R associated with it j , and add them one by one to the candidate resolution request set W according to the priority evaluation. j , until the load is relieved, and finally all candidate sets W j Stored in the candidate parsing request dictionary W; Step 5: Generate a request migration plan using multi-objective optimization and Jaya's improved genetic algorithm. First, dynamically optimize the weight parameters of the fitness function so that the migration strategy can achieve a flexible balance between multiple performance indicators. After the weight adjustment is completed, use the improved genetic algorithm to perform global search and evolutionary iteration to find the optimal migration plan M* in a high-dimensional and complex decision space. The multiple performance indicators include: migration cost, resolution delay and load balancing; Step 6: According to the generated migration plan M*, a phased migration strategy is adopted to execute the migration plan. Meanwhile, the consistency of the global DNS view is ensured through state synchronization between DNS servers. Step 7: monitor the status changes of each DNS server. When a significant change in server load or traffic distribution is detected, jump to step 2 to continue load detection and optimization. Otherwise, jump to step 8. Step 8, end.

2. According to the method shown in claim 1, the multi-objective optimization and Jaya improved genetic algorithm are specifically implemented according to the following steps: Step 1: According to the load detection results, determine the overloaded server set O and the lightly loaded server set U, initialize the candidate resolution request dictionary W to be empty, and generate the initial migration solution set k = {k1, k2, ..., k n }, each group of solutions focuses on different optimization goals; Step 2: Considering migration cost, resolution delay and load imbalance, define the fitness function F: F=α·MRtotal+β·NRL+γ·Lbalance in, The meaning of each parameter is as follows: MRtotal migration cost, which represents the cost of migrating a resolution request from an overloaded server to a target server; NRL: Network Response Latency, which indicates the latency change of resolution requests after migration; Lbalance: load imbalance, indicating the load balance of each server after migration; α, β, γ: weight parameters of the fitness function; Step 3, dynamically adjust the weight parameters α, β, and γ of the fitness function through Jaya's improved genetic algorithm; Step 3.1, randomly generate N groups of weight combinations Q = {Q1, Q2, ..., Q p }; Step 3.2, calculate the average fitness value of each weight combination on the initial migration scheme set k; Step 3.3, find the optimal weight combination Q best and the worst weight combination Q worst ; Among them, Q best is the minimum average fitness value, Q worst is the highest average fitness value; Step 3.4, update the weight combination, and normalize the weight combination after updating; the update calculation is as follows: Q p_new =Q p +r1·(Q best -|Q p |)-r2·(Q worst -|Q p |) Among them, r1 and r2 are random numbers; Step 3.5: After reaching the maximum number of iterations, output the optimal weight combination Q best ; Step 4: Generate Popsize initial migration plans based on the candidate resolution request dictionary W and the light-load server set U, and encode them into chromosomes. Each chromosome is an array of length m. The array subscript represents the resolution request to be migrated, and the array value represents the corresponding target server, thereby representing the mapping relationship between all resolution requests to be migrated and the target server. Step 5: Iteratively optimize the population and determine the optimal migration plan. Step 5.1, retain the top 10% of individuals with the best fitness values ​​and directly enter the next generation; Step 5.2, randomly select k individuals from the remaining population and select the one with the best fitness as the parent; Step 5.3, according to the crossover probability P c , cross the parent generation to generate offspring, the crossover point will give priority to the area with lower fitness value, and the crossover probability will be dynamically adjusted and calculated as: P c_new =P c ·(1-t / max) Among them, t is the current iteration number, and max is the maximum iteration number; Step 5.4, according to the mutation probability P m , mutate the offspring, randomly change a gene position, and dynamically adjust the mutation probability to be calculated as: P m_new =P m ·(1-t / max) Among them, t is the current iteration number, and max is the maximum iteration number; Step 5.4, combine the elite individuals and the offspring after crossover mutation into a new population to avoid premature convergence and improve search efficiency; Step 6: When the maximum number of iterations is reached, the solution M* with the highest fitness value is returned as the optimal migration solution, where M* contains the target server allocation solution for each resolution request; Step 7, end.

3. According to the method of claim 1, the phased migration strategy is implemented specifically according to the following steps: Step 1: Prepare for the initial migration. Step 1.1, according to the optimal migration plan M*, determine the set of resolution requests R and the set of target DNS servers C that need to be migrated; Step 1.2: divide the resolution request set R into multiple subsets {R1, R2, …, R n Each subset corresponds to a migration phase, which will prioritize the migration of resolution requests in high-latency areas and resolution requests on servers with high loads; Step 1.3, synchronizing the status information between the target DNS server and the source DNS server, including cache data and resolution records; Step 2, stage execution migration; Step 2.1, according to the partitioned subsets {R1, R2, ..., R n }, migrate the resolution request from the source DNS server to the target DNS server stage by stage; Step 2.2: Monitor the load changes and network latency of the target DNS server in real time to ensure that the migration does not cause new overload problems. If the target server load approaches the threshold, suspend the migration or reallocate the resolution requests. Step 3: Update and synchronize the domain name resolution table; Step 3.1, after each stage of migration is completed, update the global resolution table and remap the migrated resolution request to the target DNS server; Step 3.2: Synchronize the global view through communication between DNS servers to avoid resolution failures caused by inconsistent resolution tables. Step 4: Check the load balancing status of each DNS server to ensure that the load balancing degree Lbalance reaches the expected target. If it is found that some servers are still overloaded or delayed, re-execute the load test and optimize the migration plan; Step 5, end.

Images