Configuring Load Balancing

1. Defining Upstream Block

Directive	Values	Description
upstream	`name`	Name of the upstream group
server	`address`	Address of the server in the upstream group
weight	`number`	Weight for load balancing (default: 1)
max_fails	`number`	Number of unsuccessful attempts to communicate with the server (default: 1)
fail_timeout	`time`	Time during which the specified number of unsuccessful attempts must occur (default: 10s)
backup	`none`	Mark server as backup (used only if primary servers are unavailable)
down	`none`	Mark server as permanently down (not used in load balancing)

Example: Basic upstream block

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

Example: Upstream with weight and failover

upstream api_backend {
    server 192.168.1.10:8080 weight=3 max_fails=2 fail_timeout=30s;
    server 192.168.1.11:8080 weight=2 max_fails=2 fail_timeout=30s;
    server 192.168.1.12:8080 backup;
}

2. Adding Backend Servers

Directive	Description	Example
upstream	Defines a group of backend servers	`upstream backend { server 192.168.1.10:8080; }`
server	Specifies a backend server in the upstream group	`server 192.168.1.10:8080 weight=3;`

Example: Basic Upstream Configuration

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

Example: Upstream with Weighted Servers

upstream backend {
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 weight=1;
}

Note: The weight parameter affects how many requests each server receives. Higher weights receive more traffic.

3. Using Round Robin

Directive	Description	Example
upstream	Defines a group of servers to be load balanced	`upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; }`
server	Specifies a server in the upstream group	`server 192.168.1.10:8080 weight=3;`
weight	Sets the weight for load balancing (default is 1)	`server 192.168.1.10:8080 weight=3;`

Example: Round Robin Load Balancing Configuration

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

Note: In round robin, each request is passed to the next server in the list in a cyclic manner.

4. Configuring Least Connections

Directive	Values	Description
least_conn	`on`	Enables least connections load balancing algorithm

Example: Least Connections Configuration

upstream backend {
    least_conn;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

5. Using IP Hash

Directive	Values	Description
ip_hash	`on`	Enables IP hash load balancing algorithm

Example: Basic IP Hash Configuration

upstream backend {
    ip_hash;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

Note: The ip_hash directive uses the client's IP address to determine which server to route the request to, ensuring that requests from the same IP are consistently directed to the same backend server.

Warning: If a server in the upstream group goes down, the distribution of requests to remaining servers may change, potentially causing uneven load or session inconsistency.

6. Implementing Hash Method

Directive	Values	Description
ip_hash	`on`	Uses the client's IP address to determine which server to route to
hash	`$request_uri` or `$http_<header>`	Hashes the specified variable to determine server selection
hash_bucket_size	`32k` or `64k`	Sets the size of hash buckets (default 32k)

Example: Using ip_hash for session persistence

upstream backend {
    ip_hash;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

Example: Using hash with custom variable

upstream api_upstream {
    hash $request_uri consistent;
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080 weight=1;
}

server {
    listen 80;
    location /api {
        proxy_pass http://api_upstream;
    }
}

Note: The ip_hash method ensures that requests from the same client IP address are consistently routed to the same server, which is useful for session persistence.

Warning: If a server in the upstream group goes down, clients assigned to that server may experience issues due to session inconsistency.

7. Setting Server Weights

Directive	Values	Description
weight	`number`	Sets the weight of a server in a group, affecting load distribution. Higher weights get more requests.

Example: Configuring server weights in an upstream block

upstream backend {
    server 192.168.1.10:80 weight=3;
    server 192.168.1.11:80 weight=2;
    server 192.168.1.12:80 weight=1;
}

Note: Weights are used in conjunction with the ip_hash or least_conn load balancing methods to influence how traffic is distributed among servers.

8. Marking Servers as Backup

Directive	Description	Values	Default
backup	Marks a server as backup	`on`, `off`	`off`

Example: Backup Server Configuration

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080 backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

Note: Backup servers are only used when all non-backup servers are unavailable.

9. Setting Server as Down

Directive	Values	Description
down	`down`	Marks the server as permanently unavailable. The server will not receive any requests.

Example: Marking a server as down in an upstream block

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080 down;
    server 192.168.1.12:8080;
}

10. Configuring Max Fails

Directive	Values	Description
proxy_next_upstream_tries	`integer`	Number of attempts to try a different upstream server if the current one fails. Default is 0 (no retries).
proxy_next_upstream_timeout	`time`	Time limit for trying upstream servers. Default is 0 (no timeout).
max_fails	`integer`	Number of failed requests to an upstream server before it is marked as unavailable. Default is 1.
fail_timeout	`time`	Time during which the specified number of failures must occur for a server to be marked as unavailable. Default is 10s.

Example: Configuring max_fails and fail_timeout

upstream backend {
    server 192.168.1.10:80 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:80 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:80 max_fails=3 fail_timeout=30s;
}

location / {
    proxy_pass http://backend;
}

11. Enabling Slow Start

Slow start is a technique used to gradually increase the load on backend servers during startup or after a server has been restarted. This helps prevent overwhelming the server with too many requests at once, which can lead to performance degradation or even server crashes.

Directive	Description	Default Value	Example
slow_start	Specifies the duration during which the server will gradually increase its load.	0	`slow_start = 60s;`

Example: Configuring Slow Start for a Backend Server

upstream backend {
    server 192.168.1.10:8080 weight=1 max_fails=3 fail_timeout=30s slow_start=60s;
    server 192.168.1.11:8080 weight=1 max_fails=3 fail_timeout=30s slow_start=60s;
}

Note: The slow_start directive is available in Nginx version 1.13.0 and later.

12. Using Keepalive Connections

Directive	Values	Description
keepalive_timeout	`65s`	Timeout for keepalive connections in seconds. Default is 75s.
keepalive_requests	`100`	Maximum number of requests allowed per keepalive connection. Default is 100.
keepalive_disable	`none`	Disables keepalive for specific user agents. Example: `msie6`.

Example: Configuring Keepalive in Nginx

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    keepalive 32;
}

server {
    listen 80;
    location /api/ {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Note: Setting proxy_set_header Connection ""; ensures that the Connection header is not passed to the backend server, allowing keepalive to function properly.