1、 The difference in principle between four layer and seven layer load balancing
Four layers of load balancing work in four layers of OSI model, namely the transport layer. Four layer load balancing can only forward the request according to the target address and source address in the message, but can’t modify or judge the specific type of the requested resource, and then forward it to the server to process the request through the internal scheduling algorithm of load balancing. Four layer load balancing simply provides a reliable connection from the terminal to the terminal, and forwards the request to the back end. The connection is the same from the beginning to the end. LVS is a typical four layer load balancing.
Seven layer load balancing works in the seventh layer of the OSI model, namely the application layer. Therefore, seven layer load balancing can be based on the requested application layer information, for example, it can be allocated to the back-end server according to the requested resource type, rather than the IP and port selection. The function of seven layer load balancing is more abundant and flexible, and it can also make the whole network more intelligent. As shown in the figure above, the connections at both ends of layer 7 load balancing (facing the client and server) are independent.
In short, four layer load balancing is based on IP + port. Seven layer load balancing is realized through application layer resources.
2、 Comparison of common load balancing software
1. It has strong anti load ability and high performance, which can reach 60% of F5 hardware; it consumes less memory and CPU resources
2. Working in the network layer 4, it forwards (only for distribution) through VRRP protocol. The specific traffic is processed by Linux kernel, so there is no traffic generation.
2. It has good stability and reliability, and has a perfect hot standby scheme of its own (such as LVS + preserved)
3. It has a wide range of applications and works in four layers, so it can do load balancing for all applications without considering the specific applications to be processed;
4. Regular processing is not supported, and dynamic static separation is not allowed.
5. Support load balancing algorithms: RR (round robin), WRR (weighted round robin), LC (minimum connection), WLC (weighted minimum connection)
6. The configuration is complex, network dependent and stable.
1. Working on the 7 layers of the network, we can do some shunting strategies for HTTP applications, such as domain name and directory structure;
2. Nginx has a relatively small dependence on the network. Theoretically, it can ping the communication to perform the load function;
3. Nginx is easy to install and configure and easy to test;
4. It can also bear high load pressure and is stable, and generally can support more than 10000 times of concurrency;
5. For the health check of back-end server, only port detection is supported, not URL detection;
6. The asynchronous processing of the request by nginx can help the node server reduce the load;
7. Nginx can only support HTTP, HTTPS and email protocols, so it has a small scope of application;
8. It does not support direct session holding, but can be solved by IP hash;
9. Support load balancing algorithms: Round Robin (round robin), weight Round Robin (weighted round robin), IP hash (IP hash);
10. Nginx can also be used as a web server or cache function;
1. Support two proxy modes: TCP (four layers) and HTTP (seven layers), support virtual host;
2. It can supplement some disadvantages of nginx, such as session maintenance, cookie guidance, etc;
3. Support URL detection back-end server problem detection will be very helpful;
4. More load balancing strategies such as dynamic round robin, weighted source hash, weighted URL hash and weighted parameter hash have been implemented;
5. In terms of efficiency, haproxy has better load balancing speed than nginx;
6. Haproxy can load balance mysql, detect and load balance the back-end DB nodes;
9. Support load balancing algorithms: Round Robin, weight Round Robin, source, RI (request URL), RDP cookie (based on cookie);
10. Can’t be a web server or a cache.