Nginx балансировка нагрузки

Проксирование траффика на группу серверов

При помощи директивы upstreams можно определить группу серверов-участников, которые будут принимать участие в балансировке нагрузки. В данном случае пусть это будет три сервера

http {
 upstream backend {
 server backend1.example.com;
 server backend2.example.com;
 server 192.0.0.1 backup;
 }
}

При помощи директивы proxy_pass (или fastcgi_pass, memcached_pass, uwsgi_pass, scgi_pass) осуществляется проксирование на сервера из группы backend

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

Итоговый конфиг выглядит следующим образом: равномерное распредиление нагруки между серверами backend1 и backend2. Сервер 192.0.0.1 остается резервным и не вступает в процесс балансировки пока считаются доступными другие сервера

http {
 upstream backend {
 server backend1.example.com;
 server backend2.example.com;
 server 192.0.0.1 backup;
 }
 server {
 location / {
 proxy_pass http://backend;
 }
 }
}

Выбор метода балансировки

В свободной версии NGINX поддерживается четыре метода балансировки:

• round-robin
• least_conn
• ip_hash
• hash

round-robin

Данный метод используется по-умолчанию (нет директивы, которая бы его включала). Запросы распределяются между серверами группы равномерно. Учитывается вес сервера (по-умолчанию вес равен 1)

upstream backend {
 server backend1.example.com;
 server backend2.example.com;
}

least_conn

Запросы уходят на сервер с минимальным количеством активных соединений. Учитывается вес сервера

upstream backend {
 least_conn;

 server backend1.example.com;
 server backend2.example.com;
}

ip_hash

Сервер к которому отправятся запросы определяется на основании IP адреса клиента. Для вычисления хеш-функции используются первые три октета IPv4-адреса либо весь IPv6-адрес. Этот метод гарантирует то, что запросы конкретного клиента попадут на конкретный сервер

upstream backend {
 ip_hash;

 server backend1.example.com;
 server backend2.example.com;
}

Если же один из серверов группы нужно временно вывести из эксплуатации, то его можно пометить параметром down. В таком случае запрос клиента автоматически пойдет на следующий сервер группы

upstream backend {
 server backend1.example.com;
 server backend2.example.com;
 server backend3.example.com down;
}

hash

Сервер, на который пойдет запрос определяется ключом клиента, который может быть текстом, переменной или их комбинацией. Например, ключ может быть IP адресом и портом клиента или URI

upstream backend {
 hash $request_uri consistent;

 server backend1.example.com;
 server backend2.example.com;
}

Параметр consistent включает метод консистентного кеширования ketama. Это значит, что при добавлении или удалении сервера из группы на другие серверы будет перераспределено минимальное число ключей

Вес сервера

По-умолчанию вес каждого сервера в группе одинаков и равен 1. Также по-умолчанию NGINX использует метод балансировки round-robin. Изменим вес одного из серверов группы (определяется параметром weight)

upstream backend {
 server backend1.example.com weight=5;
 server backend2.example.com;
 server 192.0.0.1 backup;
}

В данном случае backend1 получил вес 5. Другие два сервера имеют вес по-умолчанию равный 1. При такой конфигурации 5 запросов уходят на backend1 и 1 запрос на backend2 и т.д.

Как сконфигурить nginx, чтобы он всегда кидал на пеpвый бэкенд сеpвеp, и только в случае аваpии на пеpвом, кидал на втоpой?

upstream static
 {
  ip_hash;
  server 10.0.0.101;
  server 10.0.0.102;
  server 10.0.0.103;
  server 10.0.0.104;
  server 10.1.1.100 backup;
 }
server
 {
  # ...
  server_name "static.example.net";
  location /
  {
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_pass http://static;
  }
 }

Александр Черных

• Системный администратор с 2000 года
• Участник Freelancehunt, Хабр Q&A, cyberforum
• Кейсы