Analytic Nginx Load Balancing _nginx

Load balancing is an eternal topic for a large web site. With the rapid development of hardware technology, more and more load balancing hardware devices emerge, such as F5 Big-ip, Citrix netscaler, Radware, etc., although it can solve the problem, but its high price is often prohibitive, So load-balancing software is still the choice for most companies. Nginx as an up-and-comer of webserver, its excellent reverse agent function and flexible load balancing strategy have been widely concerned by the industry. This paper will introduce the Nginx load balancing strategy from the aspects of design realization and concrete application in the background of industrial production.

Keywords: nginx load Balancing Reverse proxy

1. Foreword

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

The first public version of Nginx was released in 2004, and the 1.0 version was released in 2011. It is characterized by high stability, strong function, low resource consumption, from its current market possession, Nginx and Apache Rob the market momentum. One feature that has to be mentioned is its load-balancing function, which has become a major reason for many companies to choose it. This article will introduce Nginx's built-in load balancing strategy and extended load balancing strategy from the point of view of source, take the actual industrial production as a case, compare each load balance strategy, provide reference for Nginx users.

2. SOURCE Analysis

Nginx's load-balancing strategy can be divided into two broad categories: built-in policies and extended policies. Built-in policies include weighted polling and IP hashes, which, by default, are compiled into the Nginx kernel, with only the parameters specified in the Nginx configuration. There are many extension strategies, such as fair, generic hash, consistent hash, etc., which are not compiled into the Nginx kernel by default. Since there is no intrinsic change to 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 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, so nginx uses the first deep search algorithm, is about to first the request will be assigned to the high weight of the machine, until the machine's weight down to lower than other machines, only to start to the request to the next high weight machine; When all the back-end machines are down, Nginx will immediately clear all the machine's logo bits into the initial state to avoid causing all the machines to be in a timeout state, causing the entire front end to be rammed.

Next look at the source code. The directory structure of the Nginx source code 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 where I added a note. First look at the important statement in the Ngx_http_upstream_round_robin.h:

From the name of the variable, we can roughly guess its effect. Among them, the difference between current_weight and weight is mainly the value of the former as the weight sorted, as the processing request will change dynamically, the latter is the configuration value, used to restore the initial state.

Next, look at the creation process for the poll, as shown in the following figure.

Here's a tried variable that needs to be explained. The tried records whether the server is currently being attempted to connect. He is a bitmap. If the number of servers is less than 32, all server states can be logged in only one int. If the number of servers is greater than 32, you need to request memory in the memory pool to store. Use of this bitmap array can refer to the following code:

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

2.2. IP Hash

IP Hash is another nginx built-in load-balancing strategy, and the process and polling are similar, except that some of the algorithms and specific policies change, as shown in the following illustration:

The core implementation of IP hash algorithm is as follows:

As you can see 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 consecutive different value, which is the hard limit of the algorithm. Protection is used for this nginx, and the algorithm degrades to polling when a usable 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 for the balance of the buried deep hidden dangers.

2.3. Fair

The fair policy is to extend the policy and not be compiled into the Nginx kernel by default. The principle is based on the response time of the backend server to determine the load situation, from which the lightest load of the machine to shunt. This strategy has a strong adaptability, but the actual network environment is often not so simple, so use caution.

2.4. Common hash, consistent hash

These two are also expansion strategy, in the specific implementation of some differences, common hash is relatively simple, you can nginx built-in variables for the key hash, consistent hash using the Nginx built-in consistent hash ring, can support memcache.

3. Comparative test

This test is mainly to compare the balance, consistency, disaster tolerance of each strategy, so as to analyze the differences, and give their respective application scenarios. In order to test Nginx load balancing strategy comprehensively and objectively, we used two test tools and tested in different scenarios to reduce the impact of environment on test results. First, the test tools, the test network topology and the basic test flow are briefly introduced.

3.1. Testing tools

3.1.1 Easyabc

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

3.1.2 Polygraph

Polygraph is a free performance testing tool for caching services, agents, switches, and other testing. It has a canonical configuration language PGL (polygraph Language) that provides powerful flexibility for the software. Its working principle is shown in the following illustration:

Polygraph provides the client side and the server side, the test target nginx between the two, the network interaction between the three HTTP protocol, just configure the ip+port can be. 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 that responds with a random sized static file generated at the requested URL. This is also a major reason to choose this test software: You can generate random URLs as key to nginx various hash strategies.

In addition, the polygraph also provides the log analysis tool, the function is quite rich, the interested schoolmate may refer to the appendix the related material.

3.2. Test environment

The test was run on 5 physical machines, in which the object was set up alone on a 8-core machine, and four 4 nuclear machines built the EASYABC, webserver piles and polygraph respectively, as shown in the following figure:

3.3. Test Plan

First, introduce the key test indicators:

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

Consistency: The same key request, whether can fall to the same machine

Disaster tolerance: If part of the back-end machine is dead, whether it can work properly

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

Scene 1 server_* are normal to provide services;

Scene 2 server_4 hang off, other normal;

Scene 3 server_3, server_4 hang off, other normal;

Scene 4 server_* are all back to normal service.

The above four scenarios will be in chronological order, each scene will be based on the previous scenario, the tested object does not have to do any action to maximize the simulation of the actual situation. In addition, considering the characteristics of the test tool itself, the test pressure on the easyabc is about 17000, the test pressure on the polygraph is about 4000. All of the above tests ensure that the tested objects are working correctly, and that there are no notice levels above (Alert/error/warn) logs, and server_* QPS is used for final policy analysis in each scene.

3.4. Test results

Table 1 and Figure 1 are the load conditions of the polling policy under both test tools. Comparisons between the two test tools show that the results are exactly the same, so you can eliminate the impact of the test tools. As can be seen from the graph, the polling strategy can satisfy the balance and disaster tolerance.

Tables 2 and 2 are the load conditions of the fair policy under the two test tools. The fair strategy is very much affected by the environment, and the results still have a very large jitter after eliminating the interference from the test tools. Intuitively speaking, this is completely out of balance. But from another point of view, it is precisely because of this adaptability to ensure that in a complex network environment can be used to do things. Therefore, in the application of industrial production before the need for a specific environment to do the testing work.

The following chart is a variety of hash strategies, the difference is only a hash key or a specific algorithm implementation, so do a comparison. In the actual test, it is found that there is a problem in common hash and consistency hash: when one of the back-end machines hangs, the original traffic on this machine is lost, but there is no such problem in the IP hash. As above the IP hash source analysis, when the IP hash is invalidated, it will degenerate into a polling policy, so there will be no loss of traffic. At this level, IP hash can also be viewed as an upgraded version of polling.

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

Figure 5 IP Hash Policy

The top 1/3 of the figure uses the polling policy, the middle segment uses an IP hash policy, and the second 1/3 is still the polling policy. It can be seen clearly that the balance 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 and other network nodes, these nodes bring the traffic is often the average user hundreds of times, and IP hash strategy is exactly according to IP to divide the traffic, so the consequences of this will naturally.

4. Summary and Outlook

Through the actual comparison test, we have validated the nginx of each load balancing strategy. The following methods are compared in terms of balance, consistency, disaster tolerance and applicable scenarios. (Click the picture to see the larger image)

The above source and the actual test data angle analysis explained the nginx load balanced strategy, and has given the various strategy suitable application scene. The analysis of this article is not difficult to find, no matter which strategy is not a panacea, in the specific scenario should choose which strategy depends to a certain extent on the user's familiarity with these strategies. It is hoped that the analysis and test data of this paper can be helpful to readers, and more and more good load balancing strategy output is expected.