Nginx Load Balancing

Summary : For a large web site, load Balancing is an eternal topic. With the rapid development of hardware technology, more and more load balancing hardware devices emerge, such as F5 big-IP, Citrix NetScaler, Radware and so on, although can solve the problem, but its high price is often prohibitive, So load balancing software is still the perfect choice for most companies. Nginx as a rising star of webserver, its excellent reverse proxy function and flexible load balancing strategy has been widely concerned by the industry. This article will take the industrial production as the background, from the design realization and the concrete application and so on detailed introduction the Nginx load Balancing strategy.

keyword : nginx load Balancer Reverse Proxy

1. Preface

With the explosive growth of Internet information, load balancing (load balance) is no longer a very unfamiliar topic, as the name implies, load balancing is to distribute load to different service units, not only to ensure the availability of services, but also ensure that the response is fast enough to give users a good experience. Fast-growing traffic and data flow have spawned a wide range of load-balancing products, and many professional load-balancing hardware provides good functionality, but is expensive, which makes load-balancing software popular, and Nginx is one of them.

The first public version of Nginx was released in 2004 and released in 2011 in 1.0. It is characterized by high stability, powerful functions, low resource consumption, from its current market occupies, Nginx big and Apache Rob the market momentum. One feature that has to be mentioned is its load balancing function, which is the main reason why many companies choose it. This paper introduces Nginx's built-in load balancing strategy and extended load balancing strategy from the source point of view, and compares each load balancing strategy with the actual industrial production as a reference for Nginx users.

2. Source Code Analysis

Nginx's load balancing strategy can be divided into two categories: built-in policies and extension strategies. Built-in policies include weighted polling and IP hashes, which, by default, are compiled into the Nginx kernel, simply by specifying the parameters in the Nginx configuration. There are many extension strategies, such as fair, universal hash, consistent hash, etc., by default not compiled into the Nginx kernel. Since there is no intrinsic change in the load-balanced code in the Nginx version upgrade, the following will take the nginx1.0.15 stable version as an example to analyze each strategy from the source point of view.

2.1. Weighted polling (weighted round robin)

The principle of polling is very simple, first we introduce the basic process of polling. The following is a flowchart for processing a request:

There are two points to note, first, if the weighted polling algorithm can be divided into the first deep search and the first wide search, then Nginx is the first deep search algorithm, will be the first to assign the request to a high-weight machine, until the machine's weight down to lower than other machines, only to begin to divide the request to the next high-weight machine; When all the back-end machines are down, Nginx will immediately clear all the machine's flag bits to the original state, to avoid causing all the machines to be in a timeout state, causing the entire front end to be compacted.

Next look at the source code. Nginx source directory structure is very clear, the weighted polling path is nginx-1.0.15/src/http/ngx_http_upstream_round_robin. [C|h], on the basis of the source code, for important, difficult to understand the place I added a note. First look at the important statements in the Ngx_http_upstream_round_robin.h:

From the name of the variable, we can roughly guess its effect. The difference between current_weight and weight is that the former is the value of the weighted sort, and as the processing request changes dynamically, the latter is the configuration value that is used to restore the initial state.

Next look at the creation process of the poll, as shown in the code.

Here's a tried variable that needs to be explained. The tried records whether the server is currently trying to connect. He is a bitmap. If the number of servers is less than 32, you can record all server states in one int. If the number of servers is greater than 32, you need to request memory in the memory pool for storage. The use of this bitmap array can be referenced in the following code:

Finally, the actual strategy code, logic is very simple, code implementation is only 30 lines, directly on the code.

2.2. IP Hash

The IP hash is another load-balancing strategy built into Nginx, and the process and polling are similar, except that the algorithms and specific strategies are somewhat different, as shown in:

The core implementation of the IP hash algorithm is as follows:

As can be seen from the code, the hash value is related to both IP and the number of back-end machines. After testing, the algorithm can produce 1045 mutually dissimilar value, which is the hard limit of the algorithm. This nginx uses the protection mechanism, the algorithm degrades into polling when the available machine is still not found after 20 hashes. Therefore, in essence, the IP hash algorithm is a disguised polling algorithm, if the initial hash value of two IP is exactly the same, then the request from the two IP will always fall on the same server, which is a deep hidden danger of equalization.

2.3. Fair

The fair policy is an extended policy that is not compiled into the Nginx kernel by default. The principle is to determine the load according to the response time of the back-end server, from which the lightest-load machine is selected for diversion. This strategy has a strong self-adaptability, but the actual network environment is often not so simple, so use caution.

2.4. Universal hash, consistent hash

These two are also extended strategy, in the specific implementation of some differences, the general hash is relatively simple, can be built into the Nginx variables for the key hash, consistent hash using the Nginx built-in consistency hash ring, can support memcache.

3. Contrast test

In order to compare the equilibrium, consistency and disaster tolerance of each strategy, this test analyzes the differences, and gives the respective application scenarios accordingly. In order to fully and objectively test Nginx's load balancing strategy, we used two test tools and tested them in different scenarios to reduce the impact of the environment on the test results. First, the test tools, the test network topology, and the basic test flow are introduced briefly.

3.1. Test tools3.1.1 Easyabc

EASYABC is the company's internal development of performance testing tools, using the Epool model to achieve, simple and easy to use, can simulate the get/post request, limit the situation can provide tens of thousands of pressure, in the company has been widely used. Since the object being tested is a reverse proxy server, it is necessary to build a post server at the back end, where Nginx is used as a pile webserver to provide the most basic static file service.

3.1.2 Polygraph

Polygraph is a free performance testing tool that is known for testing caching services, proxies, switches, and more. It has the canonical configuration language PGL (polygraph Language), which provides the software with great flexibility. It works as shown in the following:

Polygraph provides client side and server side, put the test target nginx between the two, the network interaction between the three go HTTP protocol, only need to configure Ip+port. The client side can configure the number of virtual robot and the rate of each robot request, and initiate a random static file request to the proxy server, and the server will respond with a random-sized static file generated at the requested URL. This is also a major reason to choose this test software: can generate random URLs as nginx various hash strategy key.

In addition, polygraph also provides a log analysis tool, the function is rich, interested students can refer to the relevant materials in the appendix.

3.2. Test environment

The test was run on 5 physical machines, where the object was built on a single 8-core machine, and four 4-core machines were easyabc, webserver piles and polygraph, as shown:

3.3. Test Plan

First, the following key test indicators are introduced:

equalization : Whether the request can be sent evenly to the backend

consistency : Whether a request from the same key can fall to the same machine

Disaster Tolerance : When a part of the back-end machine hangs, whether it can work properly

Guided by the above indicators, we tested the following four test scenarios using EASYABC and polygraph, respectively:

Scene 1 server_* all normal service;

Scene 2 server_4 hanging off, other normal;

Scene 3 server_3, server_4 hanging off, other normal;

Scenario 4 server_* is restored to normal service.

The above four scenarios will be in chronological order, each of which will be based on the previous scenario, and the tested object does not need to do anything to simulate the situation to the fullest extent. In addition, considering the characteristics of the test tool itself, the test pressure on the easyabc at about 17000, polygraph on the test pressure of about 4000. All of the above tests ensure that the tested objects work properly and that no logs of any notice level or above (Alert/error/warn) are present, and the server_* QPS is recorded in each scenario for final policy analysis.

3.4. Test results

Table 1 and Figure 1 are the load scenarios for the polling strategy under both test tools. Comparison of the test results under the two test tools shows that the results are exactly the same, so the impact of the test tools can be ruled out. As can be seen from the chart, the polling strategy can be well satisfied for both equalization and disaster tolerance. (Click the image to see a larger image)

Table 2 and Figure 2 are the load conditions for the fair strategy under both test tools. The fair strategy is greatly affected by the environment, and the result is still very large jitter after the interference of the test tool is excluded. Intuitively, this does not satisfy the equilibrium at all. But from another point of view, it is precisely because of this self-adaptability to ensure that in a complex network environment can be used to do things. Therefore, before applying to industrial production, it is necessary to do the testing work in the specific environment. (Click the image to see a larger image)

The table is a variety of hash strategies, the difference is only the hash key or the specific algorithm implementation, so do a comparison. The actual test found that the general hash and consistency hash have a problem: when a back end of the machine hangs, the original fall to this machine traffic will be lost, but in the IP hash there is no such problem. As above, the IP hash source analysis, when the IP hash fails, will degenerate into a polling policy, so there will be no loss of traffic situation. At this level, IP hash can also be viewed as an upgraded version of polling. (Click the image to see a larger image)

Figure 5 is the IP hash policy, IP hash is the Nginx built-in strategy, can be seen as a special case of the first two strategies: the Source IP as key. Since the test tool does not facilitate the simulation of requests under a mass of IP, it is analyzed here on the actual situation of the line, as shown in:

Figure 5 IP Hash Policy

The first 1/3 uses the polling policy, the middle segment uses the IP hash policy, and the last 1/3 is the polling policy. It can be seen clearly that the equalization of IP hash has a big problem. The reason is not difficult to analyze, in the actual network environment, there are a large number of university export router IP, Enterprise export router IP network nodes, these nodes bring the traffic is often the average user hundreds of times, and the IP hash strategy is precisely in accordance with the IP to divide traffic, so the result is naturally.

4. Summary and Outlook

Through the actual contrast test, we verify the various load balancing strategies of nginx. The following is a comparison of strategies in terms of balance, consistency, disaster tolerance, and applicable scenarios. (Click the image to see a larger image)

Above from the source code and the actual test data angle analysis explained the nginx load balanced strategy, and has given the various strategies suitable application scenario. Through the analysis of this article it is not difficult to find out, no matter which strategy is not the balm, in the specific scenario should choose which strategy depends on the user's familiarity with these strategies to a certain extent. It is hoped that the analysis and test data of this paper can help readers, and more and more, more and more better load balancing strategy output.

5. References

Http://wiki.nginx.org/HttpUpstreamConsistentHash

Http://wiki.nginx.org/HttpUpstreamFairModule

Http://wiki.nginx.org/HttpUpstreamRequestHashModule

http://www.web-polygraph.org/

http://nginx.org/

by changming

Nginx Load Balancing