Using Network Address Translation to Implement Multi-Server Load Balancing_PHP Tutorial

Abstract: This article discusses the load balancing technology and load distribution strategy used by distributed network servers, and implements a load balancing gateway on FreeBSD based on network address translation, which is applied to our Internet network server to distribute the load to multiple servers. Sharing to solve the high load problem of CPU or I/O caused by a large number of concurrent accesses faced by Internet servers. In order to achieve the best load balancing effect, the load controller needs to allocate load according to the current CPU and I/O status of each server. This requires dynamically monitoring the load of the server and applying optimized load distribution strategies to achieve even load distribution. Purpose.

Keywords: Load balancing, network address translation, FreeBSD


1. Introduction

The rapid growth of the Internet has caused a rapid increase in the number of visits faced by multimedia network servers , the server needs to have the ability to provide a large number of concurrent access services, and the server's processing and I/O capabilities have become the bottleneck in providing services. Since the performance of a single server is always limited, multi-server and load balancing technology must be used to meet the needs of a large number of concurrent accesses.

The earliest load balancing technology is implemented through DNS. The same name is configured for multiple addresses in DNS, so the client querying this name will get one of the addresses, thus allowing different customers to access different servers to achieve load balancing [1]. DNS load balancing is a simple and effective method, but it cannot distinguish the differences between servers, nor can it reflect the current operating status of the server.

The reverse proxy server can forward requests to internal web servers. If the proxy server can forward requests evenly to multiple internal servers, load balancing can be achieved [2]. In the reverse proxy mode, an optimized load balancing strategy can be applied, and the most idle internal server is accessed each time to provide services. However, as the number of concurrent connections increases, the load on the proxy server itself becomes very large, and eventually the reverse proxy server itself will become a bottleneck of the service.

An address translation gateway that supports load balancing can map an external IP address to multiple internal IP addresses, and dynamically use one of the internal addresses for each TCP connection request to achieve load balancing [3]. Many hardware manufacturers integrate this technology into their switches as a function of their fourth layer switching. They generally use a load balancing strategy of random selection and selection based on the number of server connections or response time to distribute the load. However, the load controller implemented by hardware is not very flexible and cannot support more optimized load balancing strategies and more complex application protocols.

In addition to these three load balancing methods, some protocols internally support load balancing-related functions, such as redirection capabilities in the HTTP protocol, etc., but it depends on the specific protocol and therefore has a limited scope of use. Based on these existing load balancing technologies, we chose to use software to implement network address translation load balancing to make up for the inflexibility of the hardware load balancer, and applied optimized balancing strategies to achieve the best load sharing of back-end servers. Excellent status.


2. Load balancing strategy

In order to evenly distribute the load to multiple internal servers, a certain load balancing strategy needs to be applied. Traditional load balancing strategies do not take into account the different types of service requests, the different capabilities of the backend servers, and the uneven load distribution caused by random selection. In order to make the load distribution very even, it is necessary to apply a load balancing strategy that can correctly reflect the CPU and I/O status of each server [4].

There are various types of service requests initiated by customers. According to the resource requirements for processor, network and I/O, they can be simply divided into two different categories in order to apply different processing strategies. :



Static document request: such as ordinary text, images and other static multimedia data, which have little impact on the processor load, and the resulting disk I/O load is proportional to the size of the document. Proportional, mainly putting pressure on network I/O.


Dynamic document requests: More common requests often require pre-processing by the server, such as searching databases, compressing and decompressing multimedia files, etc. These requests require considerable processor and disk I/O resources. .


For static documents, each service process occupies roughly the same system resources, so the number of processes can be used to represent the system load. The dynamic document service requires additional processing, which occupies more system resources than processing static requests, so it needs to be represented by a weight. Such a simplest server load expression formula is:

where L is the load of the server, Ns is the number of static document service processes, Nd is the number of dynamic document service processes, and a is the relative number of each dynamic document service For the weight of static document service, you can choose between 10 and 100.

The limitation of server hardware is not considered in this formula. When the hardware limit is reached, the load of the server will increase significantly due to resource constraints. For example, due to the limitation of server memory size, some processes must be swapped to the hard disk, causing the system load to increase rapidly.Taking into account the system hardware limitations, the server load can be expressed as:

The newly added parameter Ll represents the limit of the normal load of the server, which should be set according to the hardware capabilities of each server itself. And b represents the weight used to limit the allocation of server tasks when the normal load is exceeded. It should be set to a value greater than Ll to represent the effect of hardware limitations. Usually in a server cluster, the weight of the server with worse hardware settings should be set larger to avoid that when all servers are overloaded, the server with the worst hardware will have the highest load. Therefore, b is inversely proportional to the hardware limit Ll of this server, so b can be set as:

Llmax is the Ll value of the server with the highest hardware configuration in the server cluster. After the load of each server is determined, the central server that controls load distribution can correctly distribute the load to the idlest server, thus preventing uneven load distribution like other load distribution strategies.


3. Implementation method and experimental results

Our server system consists of multiple FreeBSD systems connected using Fast Ethernet. Each backend server runs a daemon process to dynamically obtain its own load status, and the central control gateway implemented using FreeBSD refreshes the load of each server through these daemon processes to perform correct load distribution.

3.1 Gateway that supports load balancing

Under the FreeBSD system, the divert interface is provided to support network address translation capabilities. IP data packets are sent to the divert interface through the ipfw filtering function of the system kernel, so that the external daemon natd can receive the original data packets, process them, and then send them back to the system kernel for normal IP distribution [5].

Therefore, according to the address translation structure of FreeBSD, you can create your own network address translation daemon to support the load balancing function, so that the FreeBSD system can be used as a gateway that supports load balancing. Because it is implemented in software, it can easily support non-standard protocols and apply optimized load balancing strategies, and has great flexibility.

3.2 Experiments and Analysis

To test the usability of this implementation, we conducted our test experiments on the most common HTTP protocols. In order to distinguish different request types, three different types of tests were designed to test different aspects of performance.



Dynamic document generated by CGI program: used to test the load balancing status of the server's processing capabilities.


Small static document: Use a smaller static document to test the load balancing status under frequent connections;


Large static document: Use a larger document , test the load balancing status of disk and network I/O;


The test results are based on the performance of a single server completing requests per second, showing the types of load balancing per second when using multiple servers The ratio of completed requests to the baseline number of requests.



Figure 1: Load balancing performance



The first curve a in the above figure is for processing dynamic document requests. As the number of servers increases, its performance increases exponentially; while the second curve b is for processing small-size static document requests, the performance improvement is not obvious when using three servers; while processing large-size static document requests The third curve c has almost no performance change. In order to find the reason why the load balancing system cannot reach the ideal state, we examined the utilization of server resources:

Table 1. Utilization of server resources


Processing type
Load Balancing Gateway
Server 1
Server 2
Server 3

a
53%
97%
95%
98%

b
76%
43%
39%
41%

c
94%
32%
31%
35%




As can be seen from this table, when processing dynamic document a, all three servers are running at full speed and the load is evenly distributed. This is an ideal state. When processing static document types b and c, although the load is evenly distributed among the three servers, each server is not running at full speed. Especially when processing large-size documents, the natd process in the load balancing device occupies most of the processing resources. Since all network traffic must be converted through it, the load on the natd process increases when the number of network traffic and concurrent connections is considerable. When using different numbers of backend servers in the experiment, the actual network bandwidth flowing through the load balancing gateway is:

Table 2: Bandwidth of the server cluster when serving large-size documents


servers Quantity
1 unit
2 units
3 units

Network speed (Kb/s)
10042.14
11015.10
11442.67




It can be seen that the bandwidth is limited to about 10MB/s. Obviously this is the bandwidth limit of the load balancing process used in this test. In fact, the program uses a linked list to maintain the status of network address translation, which greatly limits Its network performance can be further improved by improving hardware performance and improving algorithms.


4. Discussion

As can be seen from the above experiment, the load balancer based on network address translation can effectively solve the CPU and disk I/O load on the server side. However, The performance of the load balancer itself is limited by network I/O and has certain bandwidth limitations under certain hardware conditions. However, this bandwidth limit can be increased by improving the algorithm and improving the performance of the hardware running the load balancing program. It can also be seen that different service types occupy different server resources. The load measurement strategy we use is to use the same load for evaluation, which is suitable for most conditions. However, the best way is to target different Resources, such as CPU, disk I/O or network I/O, monitor server load respectively, and the central controller selects the most appropriate server to distribute customer requests. Our future work will start from these two aspects to improve this load balancing controller.


References:


[1] E.Kata, M.Butler, and R. McGrath. A scalable HTTP server: the ncsa prototype. Computer Networks and ISDN systems. 1994. Vol 27, P155-164

[2] Ralf S.Engelschall. Load Balancing Your Web Site. Web Techniques Magazine (http://www.WebTechniques.com), May 1998. vol. 3, iss.5

[3] CICSO. LocalDirector Documents. http://www.cisco.com, 1997

[4] H.Zhu. T.Yang, Q.Zheng , D.Watson, O.H.Ibarra, andT.Smith, Adaptive load sharing for clustered digital library servers. Technical Report, CS, UCSB, 1998.

[5] FreeBSD core team. natd and divert manual pages. http ://www.freebsd.org. 1995



Implement a load balancing gateway by NAT


Wang, Bo

NongYe Road 70 , ZhengZhou, 450002, P.R.China

wb@email.online.ha.cn


Abstract: This paper investigates load balancing techniques and strategies, and implements a load balancing gateway based NAT for our Internet servers. The Internet servers involve the high load of CPU and I/O by simultaneous access requests, the symmetrical clustered servers can distribute the server load to solve the problem. To balance the load in the best way, the gateway distributes the load according to the status of server's CPU and I/O. The gateway must monitor every server's load and apply the best scheme to deliver every request, so it can provide the high performance for Internet services.

Keywords: load balancing, NAT, FreeBSD

http://www.bkjia.com/PHPjc/316165.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/316165.htmlTechArticleAbstract: This article explores the load balancing technology and load distribution strategy used by distributed network servers, and based on network addresses Conversion implements a load balancing gateway on FreeBSD, applied to me...