Let's start by understanding the so-called "equilibrium"
It cannot be narrowly understood as assigning the same amount of workload to all actual servers, because the carrying capacity of multiple servers is different, which may be reflected in the difference in hardware configuration and network bandwidth, or because a certain server has multiple roles. What we call "balanced" means that we hope that all servers are not overloaded and can function to the greatest extent possible.
1. http redirection
When an HTTP proxy (such as a browser) requests a URL from the web server, the web server can return a new URL through the Location tag in the HTTP response header. This means that the HTTP proxy needs to continue to request this new URL to complete the automatic jump.
Performance flaws:
1. Throughput limit
The throughput of the primary site server is evenly distributed to the servers being moved. Now suppose that the RR (Round Robin) scheduling strategy is used, the maximum throughput rate of the sub-server is 1000reqs/s, then the throughput rate of the main server must reach 3000reqs/s to fully play the role of the three sub-servers, then if there are 100 sub-servers, then Can the throughput rate of the main server be conceivably large? On the contrary, if the maximum throughput rate of the main service is 6000reqs/s, then the average throughput rate allocated to the subservers is 2000reqs/s, and the maximum throughput rate of the current subservers is 1000reqs/s, so the number of subservers must be increased. Increase to 6 to meet.
2. Different depth of redirection access
Some redirect a static page, and some redirect a complex dynamic page, so the load difference of the actual server is unpredictable, but the main site server does not know anything. Therefore, it is not very good to use the redirection method for load balancing on the entire site.
We need to balance the overhead of transferring the request with the overhead of processing the actual request. The smaller the former is relative to the latter, the more meaningful the redirection is, such as downloading. You can go to many mirror download sites to try, and you will find that the basic downloads are redirected using Location.
2. DNS load balancing
DNS is responsible for providing domain name resolution services. When visiting a site, in fact, it is first necessary to obtain the IP address pointed to by the domain name through the DNS server of the domain name of the site. In this process, the DNS server completes the mapping from the domain name to the IP address. Similarly, this mapping can also be one-to-many. At this time, the DNS server acts as a load balancing scheduler. It distributes user requests to multiple servers just like the http redirection conversion strategy, but its implementation The mechanism is completely different.
Use the dig command to see the DNS settings of "baidu"
It can be seen that baidu has three A records
Compared with http redirection, DNS-based load balancing completely saves the so-called main site, or the DNS server has already acted as the main site. But the difference is that, as a scheduler, the performance of the DNS server itself is almost nothing to worry about. Because DNS records can be cached by the user's browser or the DNS servers at all levels of the Internet access service provider, only when the cache expires will the DNS server for the domain name be re-requested for resolution. It is also said that DNS does not have the throughput limit of http, and theoretically, the number of actual servers can be increased indefinitely.
characteristic:
1. Intelligent analysis can be performed according to the user IP. The DNS server can look for the one closest to Yongji among all available A records.
2. Dynamic DNS: The DNS server is updated in time every time the IP address changes. Of course, because of the cache, a certain delay is inevitable.
insufficient:
1. No user can directly see which actual server DNS resolves to, and the debugging of server operation and maintenance personnel brings inconvenience.
2, the limitations of the strategy. For example, you cannot introduce the context of the HTTP request into the scheduling strategy, but in the load balancing system based on HTTP redirection introduced above, the scheduler works at the HTTP level, and it can fully understand the HTTP request and design according to the application logic of the site Scheduling strategies, such as reasonable filtering and transfer based on requesting different URLs.
3. If you want to adjust the scheduling strategy according to the real-time load difference of the actual server, this requires the DNS server to analyze the health status of each server during each resolution operation. For the DNS server, this custom development has a high threshold. Not to mention that most sites just use third-party DNS services.
4. DNS record cache, the cache of different programs of DNS servers of nodes at all levels will make you dizzy.
5. Based on the above points, the DNS server cannot achieve a balanced workload distribution. Finally, whether to choose a DNS-based load balancing method depends entirely on your needs.
3. Reverse proxy load balancing
This must be touched by everyone, because almost all mainstream web servers are keen to support load balancing based on reverse proxy. Its core job is to forward HTTP requests.
Compared with the previous HTTP redirection and DNS resolution, the scheduler of the reverse proxy plays the role of the middleman between the user and the actual server:
1. Any HTTP request to the actual server must go through the scheduler
2. The scheduler must wait for the HTTP response from the actual server and feed it back to the user (the first two methods do not require scheduling feedback, the actual server sends it directly to the user)
characteristic:
1. Rich scheduling strategies. For example, different weights can be set for different actual servers, so as to achieve the effect of more work for those who are capable.
2. The concurrent processing capability of the reverse proxy server is high, because it works at the HTTP level.
3. The forwarding operation of the reverse proxy server itself requires a certain overhead, such as creating threads, establishing a TCP connection with the back-end server, receiving the processing results returned by the back-end server, analyzing HTTP header information, frequent user space and kernel space Switching, etc. Although this part of the time is not long, when the backend server has a very short time to process the request, the forwarding overhead is particularly prominent. For example, when requesting static files, it is more suitable to use the DNS-based load balancing method described above.
4. The reverse proxy server can monitor the back-end servers, such as system load, response time, availability, number of TCP connections, traffic, etc., so as to adjust the load balancing strategy according to these data.
5. The reflective proxy server can allow users to always forward all requests in a session cycle to a specific back-end server (sticky session). The advantage of this is to maintain the local access of the session, and the second is to prevent the back-end server. The dynamic memory cache is a waste of resources.
4. IP Load Balancing (LVS-NAT)
Because the reverse proxy server works at the HTTP layer, its own overhead has severely restricted scalability, thus limiting its performance limit. Is it possible to achieve load balancing below the HTTP level?
NAT server: It works at the transport layer, it can modify the sent IP data packets and modify the destination address of the data packets to the actual server address.
Starting from the Linux 2.4 kernel, its built-in Neftilter module maintains some packet filtering tables in the kernel, which contain rules for controlling packet filtering. Fortunately, Linux provides iptables to perform operations such as inserting, modifying and deleting filter tables. What is even more exciting is that the IPVS module is built into the Linux2.6.x kernel, and its work is of the same type as the Netfilter module, but it is more focused on implementing IP load balancing.
To know if your server kernel has the IPVS module installed, you can
Having the output means that IPVS is installed. The management tool of IPVS is ipvsadm, which provides a command-line-based configuration interface, through which a load balancing system can be quickly implemented. This is the famous LVS (Linux Virtual Server, Linux virtual server).
1. Open the packet forwarding option of the scheduler
echo 1 > /proc/sys/net/ipv4/ip_forward
2. Check whether the actual server has used the NAT server as its default gateway, if not, add
route add default gw xx.xx.xx.xx
3. Use ipvsadm configuration
ipvsadm -A -t 111.11.11.11:80 -s rr
Add a virtual server, -t is followed by the server's external network ip and port, -s rr refers to the RR scheduling strategy using simple polling (this is a static scheduling strategy, in addition, LVS also provides a series of dynamic Scheduling strategies such as Least Connection (LC), Weighted Least Connection (WLC), Shortest Expected Time Delay (SED), etc.)
ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m
ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m
Add two actual servers (no external network ip is required), -r is followed by the internal network ip and port of the actual server, -m indicates that NAT is used to forward data packets
Run ipvsadm -L -n to see the status of the actual server. This is done.
Experiments demonstrate the use of a NAT-based load balancing system. A NAT server acting as a scheduler can boost throughput to new heights, almost more than double that of a reverse proxy server, mostly due to the lower overhead of request forwarding in the kernel. However, once the requested content is too large, whether it is based on reverse proxy or NAT, the overall throughput of load balancing is not much different, which means that for content with high overhead, a simple reverse proxy is used to build load balancing The system is worth considering.
Such a powerful system still has its bottleneck, which is the network bandwidth of the NAT server, including internal and external networks. Of course, if you are not short on money, you can spend money to buy Gigabit switches or 10 Gigabit switches, or even load balancing hardware equipment, but if you are a diaosi, what should you do?
A simple and effective way is to mix the NAT-based cluster with the previous DNS, such as five clusters with 100Mbps outbound broadband, and then use DNS to evenly direct user requests to these clusters. At the same time, you can also use DNS intelligent resolution to achieve Access to the nearest region. Such a configuration is sufficient for most businesses, but for large-scale sites that provide services such as downloads or video, the NAT server is not good enough.
5. Direct Routing (LVS-DR)
NAT works at the transport layer (the fourth layer) of the network layering model, while direct routing works at the data link layer (the second layer), which seems to be more awkward. It forwards the packet to the actual server by modifying the destination MAC address of the packet (without modifying the destination IP). The difference is that the actual server's response packet will be sent directly to the client without going through the scheduler.
1. Network settings
It is assumed here that one load balancing scheduler and two actual servers purchase three external network IPs, one for each machine. The default gateways of the three machines need to be the same, and finally the same IP alias is set. Here, the alias is assumed to be 10.10.120.193 . In this way, the scheduler will be accessed through the IP alias 10.10.120.193, and you can point your site's domain name to this IP alias.
2. Add the ip alias to the loopback interface lo
This is so that the actual server doesn't go looking for other servers with this IP alias, run in the actual server:
Also to prevent the actual server from responding to ARP broadcasts for IP aliases from the network, do:
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "1" > /proc/sys/net/ipv4/conf/all/arp_announce
After the configuration is complete, you can use ipvsadm to configure the LVS-DR cluster
ipvsadm -A -t 10.10.120.193:80 -s rr
ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g
ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g
-g means to use direct routing to forward packets
The biggest advantage of LVS-DR compared to LVS-NAT is that LVS-DR is not limited by the bandwidth of the scheduler. For example, assuming that the bandwidth of the three servers at the WAN switch exit is limited to 10Mbps, as long as the connection between the scheduler and the two actual servers is limited There is no speed limit on the LAN switch. Then, the maximum output bandwidth of 20Mbps can theoretically be achieved by using LVS-DR, because the response data packet of its actual server can be sent directly to the user without going through the scheduler, so it is related to the scheduler. It doesn't matter if you export broadband, only your own. However, if LVS-NAT is used, the cluster can only use a maximum bandwidth of 10Mbps. Therefore, the more the response packet far exceeds the service of the request packet, the more the overhead of the scheduler transfer request should be reduced, the more the overall scalability can be improved, and the more dependent on the WAN egress bandwidth.
In general, LVS-DR is suitable for building a scalable load balancing system, whether it is a web server or a file server, as well as a video server, it has excellent performance. The premise is that you must purchase a series of legitimate IP addresses for the actual device.
6. IP Tunnel (LVS-TUN)
Request forwarding mechanism based on IP tunnel: The IP data packet received by the scheduler is encapsulated in a new IP data packet and forwarded to the actual server, and then the response data packet of the actual server can reach the client directly. At present, most of Linux supports it, and it can be implemented with LVS, which is called LVS-TUN. Unlike LVS-DR, the actual server and the scheduler can not be in the same WANt network segment. The scheduler forwards requests to the actual server through IP tunneling technology. , so the actual server must also have a valid IP address.
In general, both LVS-DR and LVS-TUN are suitable for web servers with asymmetric responses and requests. How to choose from them depends on your network deployment needs, because LVS-TUN can deploy the actual server as needed. Different regions, and transfer requests according to the principle of nearest access, so if you have similar needs, you should choose LVS-TUN.
https://my.oschina.net/u/3341316/blog/877206