This article describes the Nginx load balancing strategy, removal and recovery configuration hash allocation principles consistency, and common failure nodes.

Source: Institute of Technology & Yixin Yixin payment and settlement technology team to share the first phase - Zhou Heng "Nginx minutiae" letter should pay settlement data Supply team, senior technical manager

Shared by: letter should be paid Zhou Heng settlement data Supply team, senior technical manager

Original starting in payment and settlement technology team recognized number: dangling pointers

Prequel Nginx topic (1): Nginx reverse proxy and the configuration details of one of the Nginx functions - reverse proxy. This article will focus on the function of the two Nginx - load balancing.

In order to increase the goodwill of load balancing, load balancing first understand what we can achieve.

Bind multiple server nodes together to provide a unified service entrance.
Failover, at the time of the accident, you can add a layer of safety and reduce losses.
Reduce operating complexity of on-line, on-line smooth. Operation and maintenance and development of the students are like.

Here's formal entry into the theme.

A, Nginx load balancing strategy

Load balancing is to request "balanced" allocated to multiple service node server. Here the "equilibrium" is based on actual needs and business scenarios given.

For Nginx, the request arrives Nginx, Nginx as a reverse proxy server, the absolute decision-making power, in accordance with the rules of the request is assigned to a node it knows, through this allocation, so that the amount requested all nodes need to be addressed state in a relatively average, thereby achieving load balancing.

Nginx supports load balancing strategy a lot, more focus on the following:

round robin (polling)
random (stochastic)
weight (weight)
fair (by long response time, three plug-in)
url_hash (url the hash value)
ip_hash (ip a hash value)
least_conn (minimum number of connections)

So many strategies, is not conducive to memory and choice, we might classify these common strategy, divide and technology, the easy pick.

The first to achieve the best

weight (weight)
random (stochastic)

Best practice, in fact, is the most common, the most common default configuration, of course, is the best configuration used to a certain extent. I do not know what manner of time, you can choose to use this type.

Needless to say polling. Random here, in fact, in the case of large number of requests, according to the theory of probability is equivalent to the round-robin fashion.

Polling Configuration Reference:

# Default configuration policy is polling 
upstream server_group { 
   Server backend1.example.com; 
   Server backend2.example.com; 
}

Random configuration Reference:

upstream server_group { 
   random; 
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

The second class of performance priority

weight (weight)
fair (by long response time, three plug-in)
least_conn (minimum number of connections)

Let node stronger business performance machines get more requests, which is a better allocation policy.

What is the better performance of the machine? This issue also has a lot of dimensions to consider.

Divided into high weight and low weight of the machine from the experience or hardware.
When the responding node in accordance with a request to determine the length of a multi-allocation request, an allocation request or less.
According to the number of connections on hold. The more the number of connections that are typically held more description of the processing task, and busiest, the request may be allocated to other processing machines.

Configuration Reference weight:

{server_group upstream 
    Server backend1.example.com weight = . 5 ; 
    # default weight is not configured. 1 
    Server backend2.example.com; 
}

Duration (Fair) in response to the reference configuration: need to add nginx-upstream-fair Nginx module compile time.

upstream server_group{
   fair;
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

Minimum number of connections (least_conn) Configuration Reference:

upstream server_group {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

The third category remained stable

ip_hash
url_hash

Many requests are stateful, on a request to which service node, the request also where machine. Such as common stateful session is one such business.

Here Nginx provided in accordance with the rules of the client ip hash mark as to assign users, url distribution of hash as indicated. In essence still have to find the user's request, the same elements pulled out, so that you can be assigned.

ip_hash Configuration Reference:

upstream server_group {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

url_hash Configuration Reference:

upstream server_group{
   hash $request_uri consistent;
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

Two, Nginx supports consistent hashing allocated

Nginx support distributed hash consistency, that is, the configuration consistent.

What is the consistency hash? Why introduce this mechanism? In a production environment, the service node would often increase or decrease occurs, even if such increases or decreases are passive, but also may have an impact hash distribution. How we can do to minimize the impact of it? At this hash consistency was invented.

Consistency hash solve two problems:

Special uneven distribution;
In addition to the change request node assigned to this node on impact, but also lead to other nodes on the request reassignment.

1) how to solve the problem of uneven distribution

The original copy of each node a virtual node N, and a name to the virtual node.

For example, that there are five nodes, when allocated often uneven, and now each node a virtual nodes N is 5 * N nodes, greatly reducing the uneven distribution of cases. Here we should talk about the problem of how to distribute.

2) how to solve the problem node changes

The basic idea of consistent hashing:

Defines a [0, (2 ^ 32) -1] value space. Corresponds to the length of a line taken from 0 to 2 ^ 32-1.
Map nodes on a line. Each node, including a virtual node, the value obtained by the hash algorithm are then mapped to the value range.

As shown below.

Calculated Hash value of the data. The key character string request a value obtained by hash algorithm, to find a position of the line segment, if the calculated value is greater than 2 ^ 32-1 is assumed to be zero. According to this rule, this is actually a line segment connected end to end to form a ring, the ring is also called hash.
Find the node belongs on the line segment data node. Along this line to find the right away from the nearest node, and the node as the home node of this data.

Hash impact on the consistency of change Next, look node.

Node Reduction: NodeA such as sudden failure, the original allocation to data on other nodes does not change, only the data on NodeA will be re-assigned to find their nearest point, thus reducing the number of hash redistribution. This is also consistent hash biggest advantage.
Node increase: such an amount of shaking by the request, the node needs to be increased to reduce the load. When a new node is added NodeE, NodeE and its virtual node group hash value based on the hash distribution ring. At this time, most of the data based on consistent hashing and then find the rules to which they belong Node node does not change, only those values calculated from NodeE find more recent data has changed, but the number is limited after all, reduced because of the increased impact of nodes.

Third, the failed node removal and recovery

Take a look at the classic configuration, and then explained in detail.

upstream server_group {
    server backend1.example.com ;
    server backend2.example.com  max_fails=3 fail_timeout=30s;
    server backup1.example.com  backup;
}

max_fails=number

This parameter determines how many times after the failure of the back-end request will suspend the service node, it is no longer to send a new request, the default value is 1. This parameter, together with the need to meet fail_timeout.

Off-topic: how to define failure, there are many types, because here mainly deal with HTTP proxy, so more attention proxy_next_upstream.

proxy_next_upstream: definition of the main service node when a situation occurs, the request is sent to other nodes, which is the definition of how counted as service node failure.

fail_timeout=time

Nginx finds that determines when the node is unavailable, how long to pause. Do not configure the default is 10s.

The above two parameters together to consider is this: When a request is sent to the Nginx found on this node fails three times, it will put this node removal, removal time is 30s, the 30s will once again send a request to this node .

backup

Similar to the switch statement default, when the primary node are hung up when the request will hit the backup node. This is the last of the reinforcements.

IV Summary

Since Nginx uses reverse proxy technology, for forwarding requests have absolute control over, so that the load balancing becomes possible.

This paper introduces the concept of load balancing, a detailed breakdown of the Nginx load balancing strategy, and provides a simple configuration reference. At the same time it introduces the principle of consistency hash of removal, and the common node failure and recovery. Next will introduce Nginx functions of the three --HTTP cache, so stay tuned.

Nginx topic (2): Nginx configuration and load balancing strategy