Linux Enterprise Cluster notes-CH11 LVS introduction Theory

1. This chapter introduces some related concepts, scheduling policies, and cluster architecture types of LVS. The next chapter begins to explain the LVS-NAT Cluster

2. Since Linux kernel 2.4.23, we have added a feature called IP Virtual Server (ipvs), which allows us to use a Linux machine as a Load balancer. LVS is a good software for building a Linux load balance cluster.

3. LVS address name conventions. Here we will introduce the proprietary names of various IP addresses mentioned in LVS. In fact, we can see the figure below: See appendix 1.

OK, you can understand the meaning of these IP addresses from the figure:

Virtual IP (VIP) Address
The IP address the Director uses to offer services to client computers

Real IP (RIP) Address
The IP address used on the cluster nodes ctor's IP (DIP) Address

Director's IP (DIP) Address
The IP address the Director uses to connect to the D/rip Network

Client computer's IP (CIP) Address
The IP address assigned to a client computer that it uses as a source IP address for requests sent to the Cluster

4. LVS support load balance a total of three ways: LVS-NAT, LVS-DR, LVS-TUN, this book focuses on the LVS-DR, LVS-TUN don't talk, LVS-NAT simple explanation. In fact, LVS-TUN is also good, there is information on the Internet, he is through the IP tunneling technology to do, and VPN is a bit like.

5. LVS-NAT, first look at this figure: see annex 1

We can see that all requests and responses must pass through the Load balancer, which is undoubtedly a bottleneck. Therefore, this architecture is generally used on a small scale because it is easy to build. The main features are as follows:

(1) cluster nodes and Director (Load balancer) must be in the same network segment.
(2) Generally, false IP addresses are allocated to cluster nodes, such as 192. x.
(3) Director architecture request and Response Information
(4) In general, the dip of director is the gateway IP address of cluster nodes.
(5) In this architecture, director can remap a port. For example, you can map a port 80 request from the client to port 8080 on a node in the cluster. (Iptable, naturally)
(6) The OS of cluster nodes can be freely selected.
(7) botctor is the bottleneck of the entire system.

6. LVS-DR, see the figure first: attachment 2

As shown in the figure, the cluster node directly returns the request to the client. This architecture has the following features:

(1) The cluster node and director must be in the same network segment.
(2) the IP address of cluster nodes is not necessarily a false IP address.
(3) director only needs to handle the request
(4) cluster nodes generally do not use ctor as their gateway
(5) Director cannot remap the port
(6) The OS of the cluster node can be different.
(7) LVS-DR can accept more loads than LVS-NAT

7. LVS-TUN, see figure: attachment 3

It can be seen from the figure that, unlike the LVS-DR, the IP tunneling technology is used here, this technology is to package a package in another package, this way, after the receiver unlocks the package and obtains the real package, it can directly establish a connection with the address in the package, have a similar image with the VPN, and have a special detailed article on the LVS official Chinese site. This architecture has the following features:

(1) cluster node and director do not need to be in a network segment. Because IP tunneling is used, IP addresses of two different network segments can communicate directly. Therefore, this is the loose architecture. Director and cluster nodes may be on the Internet. Unlike the first two, Director and cluster nodes are both in one LAN.
(2) RIP cannot be a false IP address.
(3) director only needs to process the request
(4) response information cannot pass through director. In other words, Director cannot be the gateway of cluster nodes.
(5) Director cannot remap the port
(6) The cluster nodes operating system must support IP tunneling protocol.

8. LVS scheduling methods. first, we will introduce fixed (or non-dynamic) scheduling methods. this is actually a type of scheduling algorithm. Their common feature is static. Once defined, there will be no logical processing based on the specific situation. This is a rigid Task Based on the scheduling definition. For example, these algorithms are of the fixed type:

(1) round-robin (RR) -- when a request arrives, Director selects the next server from the list of round-robin servers to accept the request, no matter whether the server is heavy or too many connections at present, it simply selects the server down in the list and returns it at the end.

(2) Weighted Round-Robin (WRR) -- Based on RR, assign a weight to each server in the cluster to indicate the performance of the machine. For example, a server with weight 2 can accept two requests, while a machine with weight 1 can only accept one request. Of course, if weight is 0, director will never submit the request to him. Note that it is useful to set weight to 0 even in Dynamic Scheduling Policies, if you want to maintain a machine and do not want it to accept the request for the moment, set its weight to 0.

(3) Destination hashing. Each request has a destination IP address. In this scheduling algorithm, requests with the same destination IP address are scheduled to the server in the same cluster. This scheduling algorithm is especially useful when the servers in the cluster are both proxy or cache servers, because these servers have cache for these destination IP addresses and can quickly process the requests.

(4) Source hashing. this method can be used when the Director needs to be sure the Reply packets are sent back to the same router or firewall that the requests came from. this scheduling method is normally only used when the Director has more than one physical network connection, so that the director knows which firewall or router to send the reply packet back through to reach the proper client computer.

9. dynamic Scheduling Method. the biggest difference from static scheduling policies is that in the dynamic scheduling algorithm, LVS records the number of active and inactive connections of each server in the cluster, determine the server to which the next request is sent based on the current load of each server. An active connection means that a TCP session is kept in the open (established State) State. For example, telnet and SSH will remain open until the user exits. An Inactive connection, that is, a connection that is not in the establish State. Generally, if you close the connection (send a FIN packet), timeout will lead to an inactive connection, LVS will keep a connection in ipvs table, even if the connection has been dropped, this is because if the connection needs to be established in a short time, it can be directly established, good performance (both director and cluster node do this ).

10. OK. The first dynamic scheduling policy is least-connection (LC ). The logic of this scheduling policy is as follows. As the name suggests, the request with the least connection is processed. When a connection arrives, ctor times the current active connection of each node on the cluster node by 256, and then adds the number of inactive connections on each node to obtain a value, the server with the smallest value processes the request.

11. weighted Least-connection (wlc ). the wlc scheduling policy is the same as that of LC, except that the overload value calculated in the LC scheduling method is divided by the weight of each machine to obtain a new value, the machine with the smallest value processes the request. If the values are the same, LVS selects the first machine in the server list to process the request. It is a policy that combines weight and LC policies. Note that this is the default scheduling policy of LVS, because this policy can indeed cope with many occasions.

12. shortest expected delay (SED ). the SED method is recently added to the LVS scheduling policy. This method is slightly better than the wlc method, especially when many connections are processed for TCP persistent connections (such as large batch job, SSH or telnet is always on ). The algorithm is as follows: the number of active connections on each server is + 1, and then divided by the weight on each server. The server with the smallest value processes the request. Note that this algorithm does not consider inactive connection (that is why this algorithm is particularly suitable for many TCP persistent connection scenarios ), in addition, he adds 1 to the active connection to simulate the scenario where the machine accepts the new connection. Consider this example. If the algorithm does not add 1 to the active connection, for example, we have two machines, one is 1, ten are active connections, and the other is 3, there are 30 active connections. If 1 is not added, the value calculated by the two machines in this algorithm is 10. Then, LVS selects the first server in the server list to process the request, i'm not sure which server it is. But after 1 is added, the number of Weight machines whose weight is 1 is 10, but that of Weight machines whose weight is 3 is 10.34, it is obviously reasonable to process the request from the machine with weight.

However, this algorithm has a defect: when some servers have no load, the request will not be scheduled, for example, two servers, one weight is 1, however, there is currently no active connection. One weight is 3 and there is currently an active connection. A request is sent. According to the algorithm, weight is 1 and the value is 1, if weight is a 3 machine, it is unreasonable to calculate whether weight is 0.67 -- or weight is a 3 machine to process the request. Therefore, we should make the machine without active connection process the request. Based on this, the following scheduling policy (NQ) was born.

13. Never Queue (NQ ). This policy is an improvement on sed. It stipulates that if there is no active connection on a machine, the request will be scheduled to this machine regardless of the value calculated by sed.

14. locality-based least-connection (lblc ). this scheduling policy is based on the proxy/cache server. It is a bit like destination hashing in a static policy. It is like this. When a request (request a specific IP address, such as a web server) at the first time, LVS selects a proxy server (for example, this server is called a) to process the request according to the wlc (which should be a slightly modified wlc algorithm) algorithm, when the next request comes over (of course, the request destination is the same, it is the Web server), then LVS will directly process the request to this server. This can effectively improve the request cache hit rate and request processing performance. Of course, this cannot be solved all the time. When LVS finds that the wlc value of server a is twice the minimum wlc value, LVS will dispatch the request to the server with the smallest value of the wlc (assuming B) for processing, and then such requests will be processed by the server B, which repeats in a loop.

15. locality-based least-connection with replication Scheduling (lblcr ). this algorithm also makes some improvements to lblc. It creates a set of proxy servers, in which a batch of proxy servers can process the same request with the same destination, LVS selects the server with the least active connection from this set to process the request. The process is like this. The request comes first. According to the lblc algorithm, a server a processes the request. When the wlc of server a is twice the minimum wlc, according to the lblc algorithm, the new minimum wlc server B starts to accept requests. However, in lblcr, the new server B is added to the set and listed together with server, then B starts to process the request (because B's active connection is still the least), so many machines will be listed in this set. When will the proxy server be deleted from the set? Yes. When LVS finds that the server list in this set has not changed within six minutes (this means that no server is added or deleted within six minutes, these six minutes are always carried by the servers in this set), LVS will delete the server with the most active connections from the set.

OK. In this chapter, the scheduling policy of LVS is quite exciting. You can come back to it frequently in practice and have a better understanding of LVS.