Nginx is a popular web server that can be configured as a simple yet powerful load-balancer to improve our resource availability and efficiency. Nginx works as a single entry point to a distributed web application working on multiple separate servers.
BASICS LOAD-BALANCING TECHNIQUES
Here we refer mainly to six basic load-balancing techniques that are used as a load balancer.Round robin , hash ,ip hash , Least Connections , Least Time and random.
- ROUND ROBIN
Round robin load balancing is a simple way to distribute client requests across a group of servers. A client request is forwarded to each server in turn. The algorithm instructs the load balancer to go back to the top of the list and repeats again.
For example
Round robin network load balancing rotates connection requests among web servers in the order that requests are received. Assume that we have a group of three servers : Server1,Server2, and Server 3
• The first request is sent to Server 1
• The second request is sent to Server 2
• The third request is sent to Server 3
upstream backend {
server1;
server2;
server3;
}
server {
server_name www.example.com;
location / {
proxy_pass http://backend;
}
}
sample configuration of the backend upstream group, the load balancer sends the first three connection requests to Server1, Server2, and Server3 in order, the fourth to Server1, the fifth to Server2, and so on.
(Round robin is most useful when servers are of equal specification and there are not many persistent connections.)
WEIGHTED ROUND ROBIN
Weighted Round Robin builds on the simple Round-robin load balancing algorithm to account for differing application server characteristics. The administrator assigns a weight to each application server based on criteria of their choosing to demonstrate the application server’s traffic-handling capability.
If server1 is twice as powerful as server2 (and server 3), server1 is provisioned with a higher weight and server 2 and 3 get the same weight.
- HASH
With the Hash method, for each request the load balancer calculates a hash that is based on the combination the server to which a request is sent is determined from a user‑defined key which can be a text string, variable, or a combination and associates the hash with one of the servers. It sends all requests with that hash to that server, so this method establishes a basic kind of session persistence.
For example
the hash directive uses the scheme (http or https) and full URI of the request as the basis for the hash:
upstream backend {
hash $scheme$request_uri;
server 1;
server 2;
server 3;
}
server {
server_name www.example.com;
location / {
proxy_pass http://backend;
}
}
- IP HASH
The IP address of the client determines which server receives the request.You set it with the ip_hash directive.
For example,
upstream backend {
ip_hash;
server 1;
server 2;
server 3;
}
server {
server_name www.example.com;
location / {
proxy_pass http://backend;
}
}
In this case, either the first three octets of the IPv4 address or the whole IPv6 address are used to calculate the hash value. The method guarantees that requests from the same address get to the same server unless it is not available.
- LEAST CONNECTIONS
A request is sent to the server with the least number of active connections, with server weights taken into consideration.We can configure it with the least_conn directive.
For example,
upstream backend {
least_conn;
server 1;
server 2;
server 3;
}
server {
server_name www.example.com;
location / {
proxy_pass http://backend;
}
}
Most useful when there are a large number of constant connections in the traffic unevenly distributed between the servers.
- LEAST TIME (NGINX Plus only)
For each request, nginx plus selects the server with the lowest average latency and the lowest number of active connections, where the lowest average latency is calculated based on which of the following parameters to the least_time directive is included:
header – Time to receive the first byte from the server
last_byte – Time to receive the full response from the server
last_byte inflight – Time to receive the full response from the server, taking into account incomplete requests.
upstream backend {
least_time (header | last_byte);
server 1;
server 2;
server 3;
}
server {
server_name www.example.com;
location / {
proxy_pass http://backend;
}
}
least_time=header (NGINX Plus) – The least average time to receive the response header from the server.
- Random
Each request will be passed to a randomly selected server. If the two parameter is specified, first, NGINX randomly selects two servers taking into account server weights, and then chooses one of these servers using the specified method:
- least_conn – The least number of active connections
- least_time=header (NGINX Plus) – The least average time to receive the response header from the server ($upstream_header_time )
- least_time=last_byte (NGINX Plus) – The least average time to receive the full response from the server ($upstream_response_time )
upstream backend {
two least_time=last_byte;
server 1;
server 2;
server 3;
}
server {
server_name www.example.com;
location / {
proxy_pass http://backend;
}
}
The Random load balancing method should be used for distributed environments where multiple load balancers are passing requests to the same set of backends. For environments where the load balancer has a full view of all requests, use other load balancing methods, such as round robin, least connections and least time.
SUMMARY
We can choose Nginx load-balancing based on our site’s traffic pattern . Load balancing can do more than just act as a network traffic cop. Software load balancers provide benefits like predictive analytics that determine traffic bottlenecks before they happen. As a result, the software load balancer gives an organization actionable insights. These are key to automation and can help drive business decisions.
