Балансировка бэкендов с помощью Nginx

Балансировка нагрузки между несколькими приложениями, бэкендами и серверами является частью процесса оптимизации ресурсов, улучшения производительности и отказоустойчивости сервиса.

Nginx как load balancer

Этот веб-сервер считается одним из самых популярных и производительных решений, ведь имеет широчайший функционал и гибкость при настройке. Так что Nginx часто используется для балансировки нагрузки.

Подходов и реализаций несколько, но прежде проверьте наличие модуля ngx_http_upstream_module:

nginx -v
Все установленные и исключенные модули будут содержаться в выводе

Если же он отсутствует, то придется пересобрать Nginx, добавив этот модуль.

После этого можно приступать к настройке веб-сервера. Для включения балансировки добавьте директиву upstream (секция http) в файл конфигурации Nginx:

upstream backend {
server backend1.somesite.com;
server backend2.somesite.com;
server backend3.somesite.com;
}

Можно назначить несколько директив upstream

Теперь нужно указать перенаправление необходимой группы:

server {

location / {
proxy_pass http://backend;
}

}

Перенаправление также можно указать в директивах fastcgi_pass, memcached_pass, uwsgi_pass, scgi_pass

Кроме этого Nginx поддерживает дополнительные параметры и методы распределения нагрузки.

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

Nginx предлагает несколько методов балансировки нагрузки.

Round-robin

Веб-сервер по умолчанию распределяет запросы равномерно между бэкендами (но с учетом весов). Этот стандартный метод в Nginx, так что директива включения отсутствует.

least_conn

Запросы сначала отправляются бэкенду с наименьшим количеством активных подключений (но с учетом весов):

upstream backend {

least_conn;
server backend1.somesite.com;
server backend2.somesite.com;

}

Если количество активных соединений одинаково, то дополнительно используется метод round-robin

Hash и IP hash

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

Для каждого запроса Nginx вычисляет хэш, который состоит из текста, переменных веб-сервера или их комбинации, а затем сопоставляет его с бэкендами:

upstream backend {

hash $scheme$request_uri;
server backend1.somesite.com;
server backend2.somesite.com;
server backend3.somesite.com;

}

Для вычисления хэша используется схема (http или https) и полный URL

IP hash работает только с HTTP, это предопределенный вариант, в котором хэш вычисляется по IP-адресу клиента:

upstream backend {

ip_hash;
server backend1.somesite.com;
server backend2.somesite.com;
server backend3.somesite.com;

}

Если адрес клиента IPv4, то для хэша используется первые три октета, если IPv6, то весь адрес

Веса бэкендов

Если в стеке определенные бэкенды мощнее, чем другие, то пригодятся веса:

upstream backend {

server backend1.somesite.com weight=10;
server backend2.somesite.com weight=5;
server backend3.somesite.com;
server 192.0.0.1 backup;

}

По умолчанию веса равны 1

В этом примере из каждых 16 запросов первый бэкенд будет обрабатывать 10, второй 5, а третий 1. При этом бэкап-сервер будет получать запросы только если три основных бэкенда недоступны.

Мониторинг

Если Nginx считает, что бэкенд сервер недоступен, то временно перестает слать на него запросы. За это отвечает две директивы:

• max_fails — задает количество неудачных попыток подключений, после которых бэкенд определенное время считается недоступным;
• fail_timeout — время, в течение которого сервер считается недоступным.

Параметры выглядят так:

upstream backend {

server backend1.somesite.com;
server backend2.somesite.com max_fails=3 fail_timeout=30s;
server backend3.somesite.com max_fails=2;

}

Параметры по умолчанию: 1 попытка, 10 секунд таймаута

Самое главное

Выбор подходящего метода балансировки позволит сделать более равномерно распределить нагрузку. Не забывайте о весах бэкендов, мониторинге и отказоустойчивости серверов.

Этот текст был написан несколько лет назад. С тех пор упомянутые здесь инструменты и софт могли получить обновления. Пожалуйста, проверяйте их актуальность.