Linux server cluster system (4)
content:
Foreword
Connection scheduling algorithm in the kernel
Dynamic feedback load balancing algorithm
summary
Reference
About author
related information:
1.LVS project introduction
2.LVS cluster architecture
3. IP load balancing technology of LVS cluster
In the Linux area:
Tutorial
Tools & products
Code and patch
article
Wensong@linux-vs.org in May 2002 in May 2002
This paper mainly tells the various connection scheduling algorithms implemented in the IP load balancing software IPvs in the LVS cluster. The service time for the request is large, give a dynamic feedback load balancing algorithm, which combines the weighting connection scheduling algorithm in the kernel, adjusts the weight of the server based on dynamic feedback back, to further avoid the load between the server balance.
1. In the previous article, we mainly tell the three IP load balancing technologies implemented in the LVS cluster. They mainly solve the system's scalability and transparency issues, how to deliver the request to request efficiently through the load scheduler Different servers are executed, making a cluster system consisting of multiple independent computers into a virtual server; when the client application interacts with the cluster system, just interact with a high-performance server. This article will mainly describe the load scheduling policies and algorithms on the load scheduler, how to schedule the request stream to each server, so that each server maintains load balancing as much as possible. The article is mainly composed of two parts. The first part describes the various connection scheduling algorithms implemented in the IP load balancing software IPvs in the kernel; the second part gives a dynamic feedback load balancing algorithm, which combines the weighted connection scheduling algorithm in the kernel. Dynamically feedback back load information to adjust the weight of the server to further avoid load imbalance between servors. In the following description, the data communication between the customer's socket and the server's socket is connected, regardless of the use of TCP or the UDP protocol. For the scheduling of UDP data packets, the IPVS scheduler also sets the scheduling record and sets the timeout value (such as 5 minutes); UDP data packets from the same address (IP address and port) within the set time Scheder to the same server. 2. The load equalization scheduling of the connection scheduling algorithm in the kernel is in the kernel. In the HTTP protocol (non-lasting), each object is acquired from the web server to create a TCP connection. The different requests of the same user will be scheduled to different servers, so this fine-grained scheduling can be somewhat. Avoiding a single user access to the load imbalance between servers. In the connection scheduling algorithm in the kernel, IPVS has achieved the following eight scheduling algorithms:
Round-Robin Scheduling
Weighted Round-Robin Scheduling)
Least-Connection Scheduling
Weighted Least-Connection Scheduling
Locality-based Least Connections Scheduling Based on Partial Link
Local-based Local Link (Locality-based Least Connections with Replication Scheduling)
Destination Hashing Scheduling
Source Hashing Scheduling
Below, let's first introduce the working principle and algorithm process of these eight connection scheduling algorithms, which will describe how to use them in future articles. 2.. Round Robin Scheduling Algorithm is a server that scheders a request scheduling in the way, that is, each dispatch executes I = (i 1) mod n, and selects the third server. . The advantage of the algorithm is its simpleness, it does not need to record all the status of all current connections, so it is a stateless schedule. When system implementation, we introduce an additional condition that when the weight of the server is zero, it indicates that the server is not available without being scheduled. The purpose of this is to cut the server (such as blocking server failures and system maintenance) while maintaining consistent with other weighted algorithms. Therefore, the algorithm must be made accordingly, its algorithm process is as follows:
Wheed call scheduling algorithm process
Suppose there is a set of servers s = {S0, S1, ..., SN-1}, one indicating that the variable i means the last selection
The server, W (Si) represents the weight of the server Si. The variable I is initialized to N-1, where n> 0.
J = I;
Do {
J = (J 1) mod n;
IF (w (sj)> 0) {
i = j;
Return Si;
}
} while (j! = i);
Return NULL;
The wheel scheduling algorithm assumes that all server processing performance is the same, regardless of the current connection and response speed of the server. This algorithm is relatively simple, and it is not applicable to the case where the processing performance in the server group is not a larger time to request a relatively large change, the wheel call scheduling algorithm can cause load imbalance between servers. Although the Round-Robin DNS method is also parsing a domain name to multiple IP addresses in a manner, the scheduling particle size of the rotation DNS method is based on each domain name server, the domain name server is resolved by the domain name. Analyze the domain names, which can cause serious imbalance between the load between servors. Here, the particle size of the IPVS Wheed Scheduling Algorithm is based on each connection. Different connections of the same user will be scheduled to different servers, so this fine-grained rotation scheduling is more advantageous than the DNS rotation. 2.2. Weighted Round-Robin Scheduling Algorithm can solve the case where the server is different, which represents the processing performance of the server with the corresponding weight, and the server's default weight is 1. Suppose the weight of the server A is 1, B is 2, and the processing performance of the server B is twice the processing performance of the server B. The weighted rotation scheduling algorithm is the high and rotation request request to each server by the weight value. A server that has high weight is received first, with a high weight server comparable server to handle more connections, and the server of the same weight processing the same number of connections. The weighted rotation scheduling algorithm process is as follows:
Weighted rotation scheduling algorithm process
It is assumed that there is a set of servers S = {S0, S1, ..., SN-1}, W (Si) to represent server Si weight, one
Indicates the variable i to indicate the last selection server, indicating that the variable CW represents the weight of the current scheduling, max (s)
Represents the maximum weight value of all servers in the set S, GCD (s) represents the largest of all server weights in the set S
common divisor. The variable I is initialized to -1, and CW is initialized to zero.
While (true) {
I = (i 1) mod n;
IF (i == 0) {
CW = CW - GCD (s);
IF (CW <= 0) {
CW = max (s);
IF (cw == 0)
Return NULL;
}
}
IF (w (si)> = CW)
Return Si;
}
For example, three servers A, B, and C have weights 4, 3, and 2, respectively, in one scheduling period (MOD SUM (W (SI))) scheduling sequence is AababcABC. The weighted rotation scheduling algorithm is also relatively simple and efficient. When the service time of the requested service is large, the separate weighting rotation scheduling algorithm will still lead to load imbalances between servors. From the above algorithm process, we can see that the server is not scheduled when the weight of the server is zero; when all the weights of all servers are zero, that is, for any I has W (Si) = 0, then no Any server is available, the algorithm returns NULL, and all new connections will be lost. The weighted rotation scheduling also does not need to record all current connections, so it is also a stateless schedule. 2.3. The minimum connection scheduling minimum connection scheduling is the server that distributes the new connection request to the current connection number. The minimum connection scheduling is a dynamic scheduling algorithm that estimates the load of the server through the number of connections currently active through the server. The scheduler needs to record the number of connections that each server has established, and when a request is scheduled to a server, the number of connections plus 1; when the connection is aborted or timeout, its connection is reduced. When the system is implemented, we also introduce when the weight of the server is zero, indicating that the server is not available without being scheduled, and its algorithm process is as follows:
Minimum connection scheduling algorithm process
It is assumed that there is a set of servers S = {S0, S1, ..., SN-1}, W (Si) to represent server Si weight,
C (Si) represents the current connection number of the server Si.
For (m = 0; m ) {
IF (w (sm)> 0) {
For (i = m 1; i IF (w (si) <= 0) CONTINUE; IF (c (Si) m = i; } Return SM; } } Return NULL; When each server has the same processing performance, the minimum connection scheduling algorithm can slide the request distribution that the load change is large to each server, and the request for all processing time cannot be sent to the same server. However, when the processing capability of each server is not ideal, the algorithm is not ideal because the TCP connection process will enter the TIME_WAIT state, TCP's TIME_WAIT is generally 2 minutes, and the connection also occupies the resources of the server, so this situation will occur The server with high performance has been processed, the connection is in the TIME_WAIT state, and the server with low performance is busy with the received connection, and constantly receives a new connection request. 2.4. Weighted minimum connection Scheduling Weighted LevelTed Least-Connection Scheduling Algorithm is a minimum connection scheduling superchard, and each server uses the corresponding weight to denoted its processing performance. The default weight of the server is 1, and the system administrator can dynamically set the weight of the server. Weighted minimal connection scheduling When the new connection is scheduled, it will make the server's established connections and their weights. The algorithm flow of the weighted minimum connection scheduling is as follows: Algorithm flow of weighted minimum connection scheduling It is assumed that there is a set of servers S = {S0, S1, ..., SN-1}, W (Si) to represent server Si weight, C (Si) represents the current connection number of the server Si. The sum of all servers current connections is CSUM = σC (Si) (i = 0, 1, .., N-1). The current new connection request will be sent to the server SM, When and only when the server SM satisfies the following conditions (C (SM) / CSUM) / W (SM) = min {(c (Si) / CSUM) / W (Si)} (i = 0, 1,., N-1) where W (Si) is not zero Since CSUM is a constant in this round of findings, the judgment condition can be simplified C (SM) / W (SM) = min {C (Si) / W (Si)} (i = 0, 1,., N-1) Where W (Si) is not zero Since the CPU cycle required by division is more than the multiplication, floating point divisions are not allowed in the Linux core, the server The weight is greater than zero, so the judgment C (SM) / W (SM)> C (Si) / W (Si) can be further optimized C (SM) * W (Si)> C (Si) * W (SM). At the same time, the server is not adjusted when the weight of the server is zero. degree. Therefore, the algorithm only does the following process. For (m = 0; m ) { IF (w (sm)> 0) { For (i = m 1; i IF (C (SM) * W (Si)> C (Si) * W (SM)) m = i; } Return SM; } } Return NULL; 2.5. Local-based link scheduling based on locality-based link scheduling (LBLC) algorithm is a load balancing schedule for request packets, which is currently mainly used for Cache clusters System, because the destination IP address of the client request message in the Cache cluster changes. Here, it is assumed that any backend server can handle any request. The design object of the algorithm is to raise the request for the same target IP address to the same server in the case of the server's load base balance. Main memory cache hits, so that the processing capability of the entire cluster system. The LBLC scheduling algorithm first finds the server recently used by the target IP address based on the requesting target IP address. If the server is available and not overloaded, the request is sent to the server; if the server does not exist, or the server is overloaded and the server At its half of the workload, use the principle of "minimum link" to select an available server to send the request to the server. The detailed process of this algorithm is as follows: LBLC scheduling algorithm process It is assumed that there is a set of servers S = {S0, S1, ..., SN-1}, W (Si) to represent server Si weight, C (Si) represents the current connection number of the server Si. ServerNode [DEST_IP] is an associated variable, indicating The target IP address corresponds to the server node, which is generally achieved by the Hash table. WLC (s) The weighted minimum connection server in the collection S, that is, the front weighted minimum connection schedule. Now for the current system time. IF (ServerNode [dest_ip] is null) THEN { N = WLC (s); IF (n ull). ServerNode [dest_ip] .server = n; } else { n = servernode [dest_ip] .server; IF ((n is dead) or (C (n)> w (n) and There is a node m with c (m) N = WLC (s); IF (n ull). ServerNode [dest_ip] .server = n; } } ServerNode [dest_ip] .lastuse = now; Return n; In addition, the associated variable servernode [dest_ip] is to be recycled, and the expired target IP address to the server association is reclaimed by the Garbage Collection. The expired association refers to what current time (when implemented, using system clock beats Jiffies) minus the recent use time exceeding the set period of time, the default set period of 24 hours is 24 hours. 2.6. Local least link scheduling with copying based on local minimal link scheduling (LBLCR) algorithm is also a load balancing of the target IP address, which is currently mainly used for Cache. Cluster system. It is different from the LBLC algorithm that it is to maintain mapping from a target IP address to a set of servers, while the LBLC algorithm maintains mapping from a target IP address to a server. For a "hot" service request, a Cache server may be busy to process these requests. At this time, the LBLC scheduling algorithm will select a Cache server from all Cache servers, and map the "Hot" site to this Cache server. Soon this Cache server will overload, Repeat the above process to select a new Cache server. This may cause the image of the "hot" site to appear on all Cache servers, which reduces the efficiency of the Cache server. The LBLCR scheduling algorithm maps the "hot" site to a set of Cache servers (server collection), when the request load in the "Hot" site increases, add the Cache server in the collection to handle growing loads; "The number of requests for the site is reduced, and the number of Cache servers in the collection will be reduced. In this way, the image of the "hot" site is unlikely to appear on all Cache servers to provide the efficiency of the Cache cluster system. The LBLCR algorithm first identies the server group corresponding to the target IP address according to the requesting target IP address; selecting a server from the server group according to the principle of "minimum connection", if the server is not overloaded, send the request to the server; The server is overloaded; then press the "minimum connection" principle from the entire cluster, add the server to the server group and send the request to the server. At the same time, when the server group has not been modified for some time, the most busy server is removed from the server group to reduce the degree of replication. The process of the LBLCR scheduling algorithm is as follows: LBLCR scheduling algorithm process It is assumed that there is a set of servers S = {S0, S1, ..., SN-1}, W (Si) to represent server Si weight, C (Si) represents the current connection number of the server Si. ServerSet [dest_ip] is an associated variable, indicating The server collection corresponding to the target IP address is generally achieved by the Hash table. WLC (s) The weighted minimum connection server in the collection S, that is, the front weighted minimum connection scheduling; WGC (S) is shown The weighted maximum connection server in the collection S is set. Now for the current system time, LastMod indicates the recent collection of collections. The modification time, t is the set time to adjust the collection. IF (ServerSet [dest_ip] is null) THEN { N = WLC (s); IF (n ull). Add N INTO ServerSet [dest_ip]; } else { n = WLC (ServerSet [dest_ip]); IF ((N is des "or (n is dead) OR (C (n)> w (n) and There is a node m with c (m) N = WLC (s); IF (n ull). Add N INTO ServerSet [dest_ip]; Else IF (| ServerSet [DEST_IP] |> 1 and Now - serverset [dest_ip] .lastmod> T). { M = WGC (ServerSet [dest_ip]); REMOVE M from ServerSet [dest_ip]; } } ServerSet [DEST_IP] .lastuse = NOW; IF (ServerSet [dest_ip] Changed) THEN ServerSet [dest_ip] .lastmod = now; Return n; In addition, the associated variable serverSet [dest_ip] also has periodic garbage collection (Garbage Collection), and the expired target IP address to the server association is reclaimed. The expired association refers to what current time (system clock beats jiffies) subtracts the recent use time (LastUse) exceeding the set period of time, the default set period of 24 hours. 2.7. Destination Hash Scheduling Algorithm is also a load balancing of the target IP address, but it is a static mapping algorithm that maps a target IP address mapping through a hash function. To a server. The target address hash scheduling algorithm first identies the corresponding server from the static allocated hash table according to the requested target IP address, and if the server is available and not overloaded, the server is sent to the server. Otherwise return empty. The process of this algorithm is as follows: Target address hash scheduling algorithm process It is assumed that there is a set of servers S = {S0, S1, ..., SN-1}, W (Si) to represent server Si weight, C (Si) represents the current connection number of the server Si. ServerNode [] is a bucket of 256 buckets HASH table, in general, the number of servers will be less than 256, and of course the size of the table is also adjustable. The initialization of the algorithm is placed in the servers, looped into the ServerNode table. If the server The number of connections is greater than 2 times, the server has been overloaded. n = servernode [hashkey (dest_ip)]; IF ((n is dead) or (W (n) == 0) or (C (n)> 2 * w (n))))))? Return NULL; Return n; At the time of implementation, we adopt a multiplier Hash function, by multiplying the numbers to achieve a more uniform distribution as much as possible. The number of multiplier Hash functions used is as follows: Proud number multiplication HASH function Static Inline Unsigned Hashkey (unsigned int des_ip) { RETURN (DEST_IP * 2654435761UL) & hash_tab_mask; } Among them, 2654435761UL is 2 to 2 ^ 32 (4294967296) indirectly near gold segmentation, (SQRT (5) - 1) / 2 = 0.618033989 2654967296 = 0.6180339872.8. Source Hash Scheduling Algorithm is opposite to the target address hashing scheduling algorithm, as a Hash Key, based on the source IP address of the request Find the corresponding server from the static allocated hash, if the server is available and not overloaded, send the request to the server, otherwise return empty. It uses the hash function to the target address hash scheduling algorithm. Its algorithm process is similarities with the target address hashing scheduling algorithm, in addition to replacing the requested target IP address to the request source IP address, here, the unity is not described. In practical applications, source address hashing scheduling and target address hashing scheduling can be used in a firewall cluster, which can ensure the unique entry of the entire system. 3. Dynamic feedback load balancing algorithm Dynamic feedback Load balancing algorithm Consider the real-time load and response of the server, constantly adjust the proportion of server processing requests to avoid having a large number of requests when some servers are overloaded, thereby increasing the throughput of the entire system. Figure 1 shows the working environment of the algorithm, running the Monitor daemon process on the load scheduler, Monitor daemon to monitor and collect load information of each server. Monitor daemon can calculate a comprehensive load value based on multiple load information. Monitor Daemon calculates a new weight value of each server, and the current weight, if the difference between the new weight and the difference of the current weight is greater than the set threshold, Monitor daemon sets the server's weight to the kernel. In IPVS scheduling in the IPvs, the connection scheduling in the kernel generally uses the weighted wheel scaffinal or the weighted minimum connection scheduling algorithm. Figure 1: Working environment for dynamic feedback load balancing algorithm 3.1. Connection Scheduling When the customer has access to network access through the TCP connection, the time and calculation resources required for the service are more different, depending on many factors. For example, it depends on the requested service type, the current network bandwidth, and the current server resource utilization. Some load comparison requests require computational intensive queries, database access, long response data streams; and load relatively light requests only need to read an HTML page or make simple calculations. Don't cause the processing time to cause the tilt (SKEW) that servers, that is, the load is unbalanced between the server. For example, there is a web page with a, b, c, and d files, where D is a large image file, and the browser needs to create four connections to take these files. When multiple users accessed the page at the same time through the browser, the most extreme case is that all D files are sent to the same server. Therefore, there may be such a situation, some servers have been overloaded, while other servers are basically idle. At the same time, some servers have been busy, have a long request queue, and constantly receive new requests. Conversely, this will lead to customers for a long time, and it feels poor service quality. 3.1.1. Simple connection scheduling Simple connection scheduling may cause the server to incline the server. In the above example, if the rotation scheduling algorithm is used, and there is a server that exactly four servers in the cluster, there must be a server that always receives the D file. This scheduling policy will result in a low utilization of the entire system resource, because some resources are used in the long-term time of the customer, while other resources are idle. 3.1.2. Characteristics of actual TCP / IP traffic [1] Description Network traffic is in a wave of wavy, and there will be a large traffic accepted after a long time, and then a small traffic, so follow Waves happen as periodically. Documents [2, 3, 4, 5] revealed that there is a self-similar feature in WAN and LANs, and there is also self-similarity in the web access stream. This requires a dynamic feedback mechanism, using the status of the server group to deal with the self-similarity of the access stream. 3.2. Dynamic feedback load balancing mechanism TCP / IP traffic is popular, saying that there are many shortcomings and some long transactions, while long transactions have a higher proportion of workload. Therefore, we want to design a load balancing algorithm to avoid long-term requests to be allocated to some machines, but to split the distribution of burr into relatively uniform distribution as much as possible. We propose a dynamic feedback load balancing mechanism to control the allocation of the new connection, thereby controlling the load of each server. For example, the weighted robe scheduling algorithm is used in the core of the IPVS scheduler to schedule a new request connection; run Monitor daemon in the user space of the load scheduler. Monitor Daemon monitors and collects load information of each server, and calculates an integrated load value based on multiple load information. Monitor daem calculates a new value of the integrated load value of each server and the current weight. When the integrated load value indicates that the server is relatively busy, the newly calculated weight is smaller than its current weight, so that the number of requests newly assigned to the server will be less. When the integrated load value indicates that the server is in low utilization, the newly calculated weight is larger than its current weight, and the number of requests to the server is added to the server. If the difference between the new weight and the current weight is greater than the set thix, Monitor Daemon sets the weight of the server to IPvs dispatch in the kernel. After a certain time interval (such as 2 seconds), Monitor daemon queries the case of each server and adjusts the weight of the server accordingly; this is performed periodically. It can be said that this is a negative feedback mechanism that allows the server to maintain a better utilization. In the weighted wheel scheduling algorithm, when the weight of the server is zero, the established connection will continue to get the server's service, and the new connection will not be assigned to the server. The system administrator can set the weight of a server to zero, so that the server is quiet. When the existing connection is over, he can cut the server and maintain it. Maintenance work is indispensable to the system, such as hardware upgrade and software update, etc., zero weight makes the server quiet function. Therefore, in the dynamic feedback load balancing mechanism we must ensure that the function is not adjusted to the server's weight when the server's weight is zero. 3.3. Integrated load When calculating integrated load, we mainly use two major class load information: enter the indicator and server metrics. The input indicator is collected on the scheduler, and the server indicator is a variety of load information on the server. We use integrated loads to reflect the current relatively exact load conditions of the server. For different applications, there will be different load conditions. Here we introduce the coefficients of each load information to indicate that each load information is tight in the integrated load. The system administrator adjusts the coefficients of each load information based on the needs of different applications. In addition, the system administrator sets the time interval for collecting load information. The input indicator is mainly the proportion of the server receives the number of new connections and the average connections in unit time, which is collected on the scheduler, so this indicator is an estimate of the server load condition. A counter receiving the number of connections on the scheduler is received. For the server Si, the counter values CI1 and CI2 at time T1 and T2 can be obtained, and the number of new connections received in the time interval T2-T1 is received. Ni = Ci2 - Ci1. Thus, obtaining a set of servers in the time interval T2-T1 server Si receives a new connection number {ni}, the server Si's input metrics INPUTI have received the average connection number of new connections and N servers, and its formula is The server indicator mainly records various load information of the server, such as the server current CPU load Loadi, server current disk usage DI, current memory utilization MI and current processes number PI. There are two ways to get this information; one is to run the SNMP (Simple Network Management Protocol "service process on all servers, and the Monitor daemon on the scheduler gets this information through SNMP; the other is in the server The Agent that implements and runs the collection information is reported to Monitor daemon by Agent. If the server does not respond within the set time interval, Monitor Daemon believes that the server is unreachable, set the server in the scheduler to zero, and no new connection is again assigned to the server; if it is next The server has a response and adjusts the weight of the server. The data is processed, and it falls within the [0, ∞) interval, 1 indicates that the load is just, and the server is overloaded, less than 1 means that the server is in a low load state. The adjusted data has DISKI, MEMORYI, and Processi. Another important server indicator is a response time of the service provided by the server, which is better to reflect the processing time of the length and request of the request waiting queue on the server. The Monitor Daemon on the scheduler measures its response time as the service provided by the client access server. For example, the test is delayed from a web server, and Monitor daemon sends a "Get /" request to each server and then logs the response time. If the server does not respond within the set time interval, Monitor Daemon believes that the server is unreachable, and the server in the scheduler is set to zero. Similarly, we adjust the response time as above to get the responsei. Here, we introduce a group of coefficient ri that can dynamically adjust to represent the importance of each load parameter, where σRI = 1. The integrated load can be calculated by the following formula: For example, in a web server cluster, we use the following factors {0.1, 0.3, 0.1, 0.1, 0.1, 0.3}, and believe that the server's CPU load and request response time are important than other parameters. If the current coefficient ri does not reflect the application's load, the system administrator can constantly correct the coefficient until a set of coefficients close to the current application. In addition, regarding the setting of the query time interval, although a short interval can reflect the load of each server, it is often queried (such as 1 second several times) will bring a certain load to the scheduler and server, such as Frequent Monitor daemon has certain overhead in the scheduler, and the server indicator will bring a certain overhead. So, there is a compromise here, we generally recommend setting the intervals between 5 to 20 seconds. 3.4. Weight Calculation When the server is in use in the cluster system, the system administrator sets an initial weight default_weighti to the server, and this weight is also used in the IPVS schedule of the kernel. The weight is then adjusted as the server load changes. In order to avoid the weight becomes a big value, we make a limit for the range of weight [default_weighti, scale * default_weighti], scale is adjustable, its default value is 10. Monitor daem is running periodically. If DEFAULT_WEIGHTI is not zero, the load parameters of the server are queried, and the integrated load value aggregate_loadi is calculated. We introduce the following weight calculation formulas, adjust its weight based on the integrated load value of the server. In the formula, 0.95 is the system utilization we want, A is an adjustable coefficient (the default is 5). When the integrated load value is 0.95, the server weight is constant; when the integrated load value is greater than 0.95, the weight becomes smaller; when the integrated load value is less than 0.95, the weight becomes large. If the new weight is greater than Scale * Default_Weighti, we set new weights to scale * default_weighti. If the difference between the new weight and the current weight exceeds the set threshold, the new weight is set to the IPvs scheduling parameters in the kernel, otherwise avoid interrupting the overhead of IPvs scheduling. We can see that this is a negative feedback formula, which will adjust the weight to a stable point. When the system reaches the ideal utilization rate, the weight is constant. In actual use, if the weight of all servers is less than their default_weight, then the entire server cluster is in an overloaded state. At this time, you need to add a new server node to the cluster to handle partial loads; contrary, if all servers The weight is close to Scale * Default_Weight, then the load of the current system is relatively light. 3. Implementation Example We implemented a simple dynamic feedback load balancing algorithm in Redhat Cluster Management Tools Piranha [6]. In the integrated load, it only considers the server's CPU load (Load Average), using the following formula to adjust: The server weight adjustment interval is [Default_Weighti, 10 * default_weighti], A is default_weighti / 2, and the values adjusted by the weight are default_weighti /4.1 is the system utilization you want to achieve. Piranha queries the CPU load of each server every 20 seconds to perform weight calculations and adjustments. 4. Small junction mainly tells eight connection scheduling algorithms implemented in the IP virtual server in the kernel: Round-Robin Scheduling Weighted Round-Robin Scheduling minimum connection scheduling (Least-connection Scheduling) Weighted Least-Connection Scheduling Locality-based Least Connections Scheduling Based on Partial Link Local-based Local Link (Locality-based Least Connections with Replication Scheduling) Destination Hashing Scheduling Source Hashing Scheduling Because the service time difference between the request is large, the connection scheduling algorithm in the kernel makes it easy to run the server. To this end, a dynamic feedback load balancing algorithm is given, and the weighted connection scheduling algorithm in the kernel is given, according to the load information of the dynamic feedback, adjust the ratio of the server to process the number of requests between the server, thereby avoiding the server between servers The load is unbalanced. Dynamic feedback load algorithms can better avoid the tilt of the server, improve the resource efficiency of the system, thereby increasing the throughput of the system. The founder and major developers of the author of the author of the author, the open source and Linux core developers, the famous Linux Cluster Project - LiVS (Linux Virtual Server) founders and major developers. He is currently working in national parallel and distributed processing key labs, mainly engaged in cluster technology, operating system, object storage and database research. He has been spending a lot of time in the development of free software, and this is fun.
