Использование nginx в качестве балансировщика нагрузки HTTP

• Методы балансировки нагрузки
• Настройка балансировки нагрузки по умолчанию
• Балансировка нагрузки с учетом наименьшего количества подключений
• Сохранение сеансов
• Балансировка нагрузки с весами
• Проверки работоспособности
• Дополнительная информация

Введение

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

Nginx можно использовать в качестве эффективного балансировщика нагрузки HTTP для распределения трафика по нескольким серверам приложений и повышения производительности, масштабируемости и надёжности веб-приложений.

Методы балансировки нагрузки

В nginx поддерживаются следующие механизмы (или методы) балансировки нагрузки:

• round-robin — запросы к серверам приложений распределяются по кругу,
• least-connected — следующий запрос назначается серверу с наименьшим количеством активных подключений,
• ip-hash — для определения сервера для следующего запроса используется хэш-функция (на основе IP-адреса клиента).

Настройка балансировки нагрузки по умолчанию

Простейшая конфигурация балансировки нагрузки с помощью nginx может выглядеть следующим образом:

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

В приведённом примере три экземпляра одного и того же приложения работают на srv1-srv3. Если метод балансировки нагрузки не указан явно, по умолчанию используется round-robin. Все запросы перенаправляются на группу серверов myapp1, и nginx применяет HTTP-балансировку нагрузки для распределения запросов.

Реализация обратного прокси в nginx включает балансировку нагрузки для HTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached и gRPC.

Для настройки балансировки нагрузки для HTTPS вместо HTTP просто используйте «https» в качестве протокола.

При настройке балансировки нагрузки для FastCGI, uwsgi, SCGI, memcached или gRPC используйте соответственно директивы fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass и grpc_pass.

Балансировка нагрузки с учетом наименьшего количества подключений

Другой метод балансировки нагрузки — least-connected. Он позволяет более справедливо распределять нагрузку на экземпляры приложения в ситуациях, когда обработка некоторых запросов занимает больше времени.

С least-connected балансировкой nginx старается не перегружать занятые серверы приложения чрезмерным количеством запросов, вместо этого распределяя новые запросы по менее загруженным серверам.

Балансировка нагрузки least-connected в nginx активируется при использовании директивы least_conn в конфигурации группы серверов:

    upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

Сохранение сеансов

Обратите внимание, что при использовании балансировки round-robin или least-connected последующий запрос клиента может быть направлен на другой сервер. Нет гарантии, что один и тот же клиент всегда будет направлен на один и тот же сервер.

Если требуется привязка клиента к определённому серверу приложения (то есть сделать сеанс клиента «привязанным» или «постоянным»), можно использовать механизм балансировки ip-hash.

При использовании ip-hash IP-адрес клиента используется в качестве ключа хэширования для определения сервера в группе серверов, который следует выбрать для запросов клиента. Этот метод гарантирует, что запросы от одного и того же клиента всегда будут направлены на один и тот же сервер, за исключением случаев, когда этот сервер недоступен.

Для настройки балансировки ip-hash достаточно добавить директиву ip_hash в конфигурацию группы серверов (upstream):

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Балансировка нагрузки с весами

Также можно ещё больше влиять на алгоритмы балансировки нагрузки nginx с помощью весов серверов.

В приведённых выше примерах веса серверов не настраиваются, что означает, что все указанные серверы считаются одинаково подходящими для конкретного метода балансировки.

В частности, при использовании round-robin это также означает более или менее равномерное распределение запросов по серверам — при условии достаточного количества запросов и при единообразной обработке и достаточно быстром завершении запросов.

Когда параметр weight задаётся для сервера, вес учитывается при принятии решения о балансировке нагрузки.

    upstream myapp1 {
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
    }

В этой конфигурации каждый 5-й новый запрос будет распределяться между экземплярами приложения следующим образом: 3 запроса будут направлены на srv1, один запрос на srv2 и ещё один — на srv3.

Аналогично, веса можно использовать с методами least-connected и ip-hash в последних версиях nginx.

Проверки работоспособности

Реализация обратного прокси в nginx включает встроенные (или пассивные) проверки работоспособности серверов. Если ответ от конкретного сервера завершается ошибкой, nginx помечает этот сервер как нерабочий и старается не выбирать его для последующих входящих запросов в течение некоторого времени.

Директива max_fails задаёт количество последовательных неудачных попыток связи с сервером, которые должны произойти в течение fail_timeout. По умолчанию max_fails устанавливается в 1. При значении 0 проверки работоспособности для данного сервера отключены. Параметр fail_timeout также определяет, как долго сервер будет помечен как нерабочий. После интервала fail_timeout, следующего за отказом сервера, nginx начнёт плавно проверять сервер с помощью запросов активного клиента. Если проверки прошли успешно, сервер помечается как рабочий.

Дополнительная информация

Кроме того, существуют дополнительные директивы и параметры, контролирующие балансировку нагрузки серверов в nginx, например, proxy_next_upstream, backup, down и keepalive. Более подробная информация доступна в нашей документации.

И, наконец, балансировка нагрузки приложения, проверки работоспособности приложения, мониторинг активности и переконфигурация групп серверов на лету доступны в рамках подписок NGINX Plus.