This article summarizes the implementation methods of 6 load balancing technologies (summary)

Load balancing is a commonly used device in server cluster deployment. When the performance of a machine cannot meet the growth needs of the business, instead of looking for a machine with better performance, load balancing and clustering are used to meet the growth needs of customers.

The implementation of load balancing technology is mainly divided into the following categories:

• HTTP Redirect Payload
• DNS domain name resolution load
• Reverse proxy load
• IP load (NAT load and IP tunnel load)
• Direct Routing (LVS-DR)
• IP Tunnel (LVS-TUN)

Load balancing cannot be narrowly understood as allocating the same amount of workload to all actual servers, because the carrying capacity of multiple servers is different. This may be reflected in differences in hardware configuration and network bandwidth, or it may be because a server has multiple functions. What we call "balance" means that we hope that all servers will not be overloaded and can function to the maximum extent.

http redirect

When an http proxy (such as a browser) requests a URL from a 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 requesting this new URL to complete the automatic jump.

Performance drawbacks:

1. Throughput rate limit

The throughput of the primary site servers is evenly distributed to the transferred servers.

Now assume that the RR (Round Robin) scheduling strategy is used, and the maximum throughput of the sub-server is 1000 reqs/s, then the throughput of the main server must reach 3000 reqs/s to fully utilize the three sub-servers. If there are 100 sub-servers, then you can imagine how much the throughput of the main server will be.

On the contrary, if the maximum throughput of the main service is 6000 reqs/s, then the average throughput distributed to the sub-servers is 2000 reqs/s, and the current maximum throughput of the sub-servers is 1000 reqs/s, so the number of sub-servers must be increased to 6 to meet the requirement.

2. Different redirect access depths

Some redirect a static page, some redirect a complex dynamic page, so the actual server load difference is unpredictable, and the main site server knows nothing about it. Therefore, it is not a good idea to use the redirection method for load balancing on the entire site.

We need to weigh the overhead of transferring the request and the overhead of processing the actual request. The smaller the former is relative to the latter, the greater the meaning of redirection, such as downloading.

You can try many mirror download sites and you will find that most downloads use Location for redirection.

DNS Load Balancing

DNS is responsible for providing domain name resolution services. When accessing a site, you actually first need to obtain the IP address pointed to by the domain name through the DNS server of the site's domain name. During this process, the DNS server completes the mapping of the domain name to the IP address.

Similarly, such mapping can also be one-to-many. At this time, the DNS server acts as a load balancing scheduler. It is like the http redirection conversion strategy, distributing user requests to multiple servers, but its implementation mechanism is completely different.

Use the dig command to view 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 served as the main site.

But the difference is that as a scheduler, there is almost no need to worry about the performance of the DNS server itself.

Because DNS records can be cached by the user's browser or the Internet access service provider's DNS servers at all levels, resolution will only be requested from the domain name's DNS server again when the cache expires.

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 based on user IP. The DNS server can search all available A records for the server closest to the user.

2. Dynamic DNS: Update the DNS server in time every time the IP address changes. Of course, due to caching, a certain delay is inevitable.

insufficient:

1. No user can directly see which actual server the DNS resolves to, which brings inconvenience to the debugging of server operation and maintenance personnel.

2. Limitations of the strategy. For example, you cannot introduce the context of HTTP requests into the scheduling strategy. In the load balancing system based on HTTP redirection introduced earlier, the scheduler works at the HTTP level. It can fully understand the HTTP request and design the scheduling strategy according to the application logic of the site, such as reasonable filtering and transfer according to different requested URLs.

3. If you want to adjust the scheduling strategy based on the real-time load differences of the actual servers, this requires the DNS server to analyze the health status of each server during each resolution operation. For DNS servers, this kind of custom development has a high threshold, not to mention that most sites only use third-party DNS services.

4. DNS record cache. The caches of different programs on DNS servers at all levels of nodes will make you dizzy.

5. Based on the above points, the DNS server cannot complete the workload balancing distribution very well. Finally, whether to choose DNS-based load balancing depends entirely on your needs.

Reverse proxy load balancing

This is definitely something everyone has come into contact with, because almost all mainstream Web servers are keen to support reverse proxy-based load balancing. Its core job is to forward HTTP requests.

Compared with the previous HTTP redirection and DNS resolution, the reverse proxy dispatcher plays the role of a 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 to achieve the effect of more work for those who are more capable.

2. The reverse proxy server has high requirements for concurrent processing capabilities because it works at the HTTP level.

3. The forwarding operation of the reverse proxy server itself requires a certain amount of overhead, such as creating threads, establishing a TCP connection with the back-end server, receiving processing results returned by the back-end server, analyzing HTTP header information, and frequent switching between user space and kernel space.

Although this part of time is not long, when the backend server processes the request in a very short time, the forwarding overhead becomes particularly prominent. For example, if you are requesting static files, it is more appropriate to use the DNS-based load balancing method introduced earlier.

4. The reverse proxy server can monitor the backend server, such as system load, response time, availability, number of TCP connections, traffic, etc., and adjust the load balancing strategy based on these data.

5. The reflective proxy server allows all user requests within a session cycle to be forwarded to a specific backend server (sticky session). The benefits of this are: first, maintaining local access to the session; second, preventing the waste of dynamic memory cache resources on the backend server.

IP Load Balancing (LVS-NAT)

Because the reverse proxy server works at the HTTP layer, its own overhead has severely restricted its scalability, thereby 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 IP data packets sent and change 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. These tables contain rules for controlling packet filtering.

Fortunately, Linux provides iptables to insert, modify, and delete filter tables. What is even more exciting is that the Linux 2.6.x kernel has a built-in IPVS module, which works similarly to the Netfilter module, but is more focused on achieving IP load balancing.

To know whether your server kernel has the IPVS module installed, you can

Output means IPVS has been 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).

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), least connection with weight (WLC), shortest expected 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 IP is required), -r is followed by the internal IP and port of the actual server, -m means using NAT to forward data packets

Run ipvsadm -L -n to view the status of the actual server. That's it.

Experiments have shown the use of a NAT-based load balancing system. A NAT server acting as a dispatcher can boost throughput to a new level, almost twice that of a reverse proxy server, largely due to the lower overhead of request forwarding in the kernel.

However, once the requested content is too large, the overall throughput of load balancing is not much different whether it is based on reverse proxy or NAT. This shows that for content with high overhead, it is worth considering using a simple reverse proxy to build a load balancing system.

Such a powerful system still has its bottleneck, which is the network bandwidth of the NAT server, including the internal network and the external network.

Of course, if you have money, you can spend money to buy a Gigabit switch or a 10 Gigabit switch, or even a load balancing hardware device, but if you are a loser, what can you do?

A simple and effective way is to mix NAT-based clusters with the previous DNS, such as a cluster of 5 100Mbps export 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 regional access.

Such a configuration is sufficient for most businesses, but for large-scale sites that provide services such as downloads or videos, the NAT server is still not good enough.

Direct Routing (LVS-DR)

NAT works at the transport layer (layer 4) of the network layered model, while direct routing works at the data link layer (layer 2), which seems to be more powerful.

It forwards the data packet to the actual server by modifying the destination MAC address of the data packet (without modifying the destination IP). The difference is that the response data packet of the actual server will be sent directly to the client without going through the scheduler.

1. Network settings

Here we assume a load balancing scheduler, two actual servers, and purchase three external IP addresses, one for each machine. The default gateways of the three machines need to be the same, and finally set the same IP alias. Here we assume the alias is 10.10.120.193.

In this way, the dispatcher will be accessed through the IP alias 10.10.120.193, and you can point the site's domain name to this IP alias.

2. Add the IP alias to the loopback interface lo

This is to prevent the actual server from looking for other servers with this IP alias. Run in the actual server:

In addition, you need to prevent the actual server from responding to ARP broadcasts for IP aliases from the network. To do this, you also need to execute:

• 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 completed, 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 forwarding packets using direct routing

The biggest advantage of LVS-DR over LVS-NAT is that LVS-DR is not limited by the scheduler bandwidth. For example, assuming that the three servers have a WAN switch export bandwidth limited to 10Mbps, there is no speed limit on the LAN switch connecting the scheduler and the two actual servers.

Well, using LVS-DR can theoretically achieve a maximum export bandwidth of 20Mbps, because its actual server response data packet can be sent directly to the user end without passing through the scheduler, so it has nothing to do with the export bandwidth of the scheduler, but only with its own.

If LVS-NAT is used, the cluster can only use a maximum bandwidth of 10 Mbps. Therefore, for services where the number of response packets far exceeds the number of request packets, the scheduler's overhead for transferring requests should be reduced, which will improve the overall scalability and ultimately rely more on WAN egress bandwidth.

In general, LVS-DR is suitable for building a scalable load balancing system. It has excellent performance whether it is a Web server, a file server, or a video server. The prerequisite is that you must purchase a series of legal IP addresses for the actual server.

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 user end directly.

Currently, most Linux supports it and can be implemented with LVS, called LVS-TUN. Unlike LVS-DR, the actual server and the scheduler may not be in the same WANt 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 between them depends on your network deployment needs. Because LVS-TUN can deploy actual servers in different regions as needed and transfer requests based on the principle of proximity, if you have similar needs, you should choose LVS-TUN.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.