Analytic Nginx Load Balancing

absrtact : For a large web site, load Balancing is the 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, 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