"Go" LVS Load Balancer Session Solution Persistent connection

Original address: http://minux.blog.51cto.com/8994862/1744761

1. What is a persistent connection? 1.1 in LVs, persistent connections are used to ensure that the same server is located when requested from the same user. 2. Why is a persistent connection used? 2.1 Cookie/session mechanism of the simple description: In the Web Service communication, HTTP itself is a stateless protocol, can not identify the user source, there is a problem, when the user in a Web site browse a page and jump to the B page, then the server thinks B page is a new user request, Your previous login information has been lost, headache. In order to record the user's session information, our developer has provided the cookie/session mechanism on the client/server side software, when you visit the website, the server side establishes a session area, and establishes a cookie to bind with this session, Send the information to your browser. This way, as long as your cookie exists, the server side of the session exists, then when you open the new page, the server will still know you! 2.2 cookie/session problems caused by load balancing: The server needs to rely on Session/cookie to mark the user's session, which is fine.  However, when you are doing load balancing, there is a problem. We still assume a scenario: an e-commerce website in order to achieve more user access, provided a, b two servers, and in front of the LVS load balancing. A user opens a shopping site, selects a piece of clothing, and joins the shopping cart (the action behind this is that the LVS load balancer accepts the user request and distributes it to the selected server and adds a piece of clothing to the session).  When the user opens the second page, a hat is selected and added to the cart (the action behind this is that the LVS load balancer accepts the user request, calculates it, sends it to the selected server, and adds a hat record to the session). Now you may have found that the problem, because LVs is a four-tier load balancer, only according to Ip:port to distribute data packets, not to ensure that the same user according to the session to the same server, that is, the first time the user was assigned to a server, And the second may be assigned to the B server, but B server does not have a server user session record, directly resulting in this example of users found their shopping cart without the previous clothes, and only a hat. This is unacceptable. To avoid the above problems, there are generally three scenarios in the production environment: 2.2.1 Sends requests from the same user to the same server 2.2.2 The session information is shared within the server cluster, each server holds session information for the entire cluster  2.2.3 set up a session storage pool where all session information is saved to the storage pool Obviously, the first scenario is the simplest and most resource-efficient, and the persistent connection and SH algorithm are two ways to implement the first scenario. Since the application of SH is not too much, we just introduce the difference between it and the persistent connection, others do not tell, interested friends can find the information on their own. 3. LVS's SH algorithm and persistent connection: The SH algorithm is all called the source hash (the Origin address hash), and the function of the persistent connection is "forwarding the request from the same IP to the same server", thus guaranteeing the problem of session location. The difference between the two is: (1) SH algorithm: The SH algorithm, the SH algorithm will automatically maintain a hash table in the kernel, this hash table with each request of the source IP address hash computed value as a key, the request to the address of the RS reached as a value. In subsequent requests, each request passes through this Hashtable, and if the request has a key value in the hash table, direct to a specific RS, if not, it will be reborn into a key value so that subsequent requests are directed.  However, this method is more fuzzy in the time record (according to the TCP connection time length calculation), and it is the algorithm itself, so it is not very ideal to separate the algorithm. (2) Persistent Connection: This method realizes that regardless of the scheduling method used, the persistent connection function can guarantee within the specified time range, the request from the same IP will always be directed to the same RS, you can also bind a variety of services after the unified scheduling. In more detail, when the user requests to reach the director. Regardless of the scheduling method, you can implement a request for the same service to always be directed to the same RS within a specified time range. There is a LVS persistent connection template in the director, which records the source of each request, the RS scheduled to, the length of maintenance, and so on, so when the new request comes in, first check if there is a record in this template (there is a built-in time limit, such as a limit of 300 seconds, When there is still user access at 300 seconds, the persistent connection template will increase the time by two minutes, then count, and so on, and so on, each time only 2 minutes longer, if the record does not time out, use the RS pointed to by the record, if it is a time-out record or a new request, the scheduling algorithm will be dispatched to a specific RS Then add the scheduled records to this table. This does not conflict with the SH algorithm, and the LVS persistent connection checks the back-end RS for load conditions when a new request is reached, which is the more granular scheduling and session hold method.  4. Three types of durable connection for LVS: (1) PCC: persistent per client; All requests from the same client are directed to the previously selected RS; that is, the assigned server is always the same as long as the IP is the same. (2) Ppc: persistent per port; The request from the same client for the same service (port) is always directed to the previously selected Rs. For example, a user from the same IP first accesses the cluster's 80 port assigned to a server, and Port 25th is assigned to the B server.  When this user continues to access the 80 port still assigned to a server, Port 25th is still assigned to the B server. (3) PFMC: Persistent firewall tag connection; the request from the same client for the specified service (port) is always directed to this selected RS, but it can define two unrelated ports as a clustered service, for example: 80 ports for merging HTTP and 443 ports for HTTPS defined as the same Cluster service When the user first accesses the 80 port assigned to a server, the second access to port 443 is still assigned to the a server. 5. Define LVS Persistent Connection: The persistent connection capability of LVS needs to be defined on the Cluster service, using the-P timeout option. 5.1 definition ppc:1[[email protected] ~]# ipvsadm-at 172.16.10.1:80-s rr-p 300 The above command means: Add a Cluster service as 172.16.10.1:80, using the scheduling algorithm for RR, the retention time for persistent connections is 300 seconds. When there is no request for more than 300 seconds, the persistent connection template for the LVS is emptied. 5.2 Definition pcc:123[[email protected] ~]# ipvsadm-a-T 192.168.1.200:0-S rr-p 600[[email protected] ~]# ipvsadm-a -T 192.168.1.200:0-R 192.168.1.10-g-W 2[[email protected] ~]# ipvsadm-a-T 192.168.1.200:0-R 192.168.1.20-g-W 15.3 definition pfmc:123456##### #PNMPP是通过路由前给数据包打标记来实现的 [[email protected] ~]# iptables-t mangle-a prerouting-d 192.168.1.200-eth0-p TCP--dport 80-j MARK--set-mark 3[[email protected] ~]# iptables-t mangle-a prerouting-d 192.168.1.200-eth0 -P TCP--dport 443-j MARK--set-mark 3[[email protected] ~]# ipvsadm-a-F 3-s rr-p 600[[email protected] ~] # ipvsadm-a-F 3-r 192.168.1.10-g-W 2[[email protected] ~]# ipvsadm-a-F 3-r 192.168.1.20-g-W 2

　　

"Go" LVS Load Balancer Session Solution Persistent connection