LVS Scheduling algorithm-Personal understanding

1. LVs Scheduling Algorithm

There are two types of LVS scheduling algorithms: Static algorithm and dynamic algorithm.

1.1. Static algorithm

Scheduling is based only on the algorithm itself, regardless of the actual connection and load of the backend real server.

1.1.1 Polling (RR)--round Robin

The load scheduler shifts user requests sequentially to the back-end real servers.

It treats each real server equally, regardless of the actual number of connections and system load on the server. The weight value is the same, and a weight value of 0 indicates that the real server is unavailable.

1.1.2 Weighted Polling (WRR)--weighted Round Robin

The load scheduler will determine the performance of the backend real server based on the weight value, prioritizing the request to a real server with better backend performance.

If host A has a weight value of 2, Host B has a weight value of 1, then host A is twice times the performance of B, the dispatch order becomes AAB, and a weight value of 0 indicates that the real server is unavailable.

1.1.3 Source Address hash (SH) --source Hash

This scheduling algorithm is typically used in a Web cluster that requires session retention.

When requested by the user, the load scheduler forwards requests from the same source IP to the same real server for processing.

When the user first requests, the load scheduler forwards the request to the back-end real server in order based on the polling algorithm, and forwards the source ip+ of the user request to the backend's real server correspondence to a hash table (hash table) in the form of a hash key = value, which, when the user requests again, The Load Scheduler distributes the request to the same real server on the backend based on the requested source IP, which matches the corresponding relationship in the hash table. If the backend's real server is overloaded or unavailable, it will return null.

1.1.4 Destination Address hash (DH) --destination Hash

When requested by the user, the load scheduler always sends the request to the real server that is the target IP of the real server.

If the backend's real server is overloaded or unavailable, it will return null.

This scheduling algorithm is generally used in the backend real server for the cache server scenario, we want to all the requests can always match to the cache, through the cache server directly return the response to the user, this scheduling algorithm basically loses the sense of load balancing, basically do not use.

1.2. Dynamic algorithm

According to the algorithm and the current load state of the real server scheduling.

1.2.1 Minimum Connection (LC)--least Connection

The load Scheduler assigns user requests to a real server with the fewest back-end connections;

When all the real server connections are 0, the request is forwarded to the backend in order of polling;

The load Scheduler records the number of connections that each real server has established, and when a request is dispatched to a real server on the backend, the number of active connections (active) +1, when the connection is aborted or timed out, the number of active connections-1, the Inactive connection (InActive) + 1, when an inactive connection exceeds the idle wait time, then-1. A weight value of 0 indicates that the real server is not available.

1.2.2 Weighted Minimum Connection (WLC) -- Weighted Least Connection

The load Scheduler assigns user requests to a real server with the fewest back-end connections and the best performance;

When all of the true server connections are 0, the request is forwarded to the backend in order, regardless of the weight value size, in accordance with polling.

The load Scheduler records the number of connections that each real server has established, and it can also determine the performance of real servers by weighting values.

1.2.3 Minimum expected delay (SED) --shortest expected Delay scheduling

The load Scheduler assigns user requests to a real server with the fewest back-end connections and the best performance;

When all the real server connections are 0, the performance of the real server is judged based on the weight value, and the request is forwarded to the backend.

The SED algorithm compensates for the insufficiency of the WLC algorithm.

1.2.4 Never Queue (NQ) --never Queue

In the host a weight value of 1, Host B weight value of 5 environment, if according to the SED algorithm allocation request, then the first 4 requests will be given to host a processing, and Host B is idle state, this is not what we expect to see, so the NQ algorithm is the improvement of the SED algorithm;

When all the real server connections are 0, the real server performance is judged according to the weight value, and the request is forwarded to the backend;

When there is a new user request, there is a real server active connection number of 0 o'clock, it will be forwarded immediately, without waiting for the queue;

When all the real servers are processing the connection, the load scheduler allocates user requests to the real servers with the fewest back-end connections and the best performance.

1.2.5 Minimum connection based on locality (LBLC) -- locality Based Least Connections

This algorithm is the improvement of the DH algorithm, generally also used in the backend real server is the cache server scenario, make up the DH algorithm deficiencies, in fact, is not commonly used, can achieve high availability of back-end cache server.

When requested by the user, the load scheduler always sends the request to the real server that is the target IP of the real server.

If the backend's real server is overloaded or unavailable, the request is forwarded to the available real server with the least connection back-end.

1.2.6 minimum locality-based connection with replication (LBLCR) -- Locality Based Least Connections with Replication

The LBLCR algorithm is an upgraded version of the LBLC algorithm. LBLC maintains a real server for the target, while LBLCR maintains a set of real servers for target load balancing, which is currently used primarily for cache clusters.

When requested by the user, the load scheduler finds a server processing request with the fewest number of connections from a set of real servers.

If the server is overloaded, the load scheduler will select a server from the real server according to the minimum number of connections, add it to the group and process the request, and when the group has not changed for some time, the busiest real server will be removed from the group.

LVS Scheduling algorithm-Personal understanding