Использование 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. Он позволяет справедливее распределять нагрузку между экземплярами приложения в ситуациях, когда обработка некоторых запросов занимает больше времени.

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

Балансировка нагрузки по наименьшему числу соединений в nginx активируется при использовании директивы least_conn в конфигурации группы серверов:

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

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

Еще один способ балансировки нагрузки — least-time. Он выбирает сервер с наименьшим средним временем ответа и наименьшим количеством активных соединений, учитывая запросы, находящиеся в обработке.

При балансировке нагрузки по наименьшему времени nginx выбирает сервер на основе параметра, указанного в директиве least_time:

• header — время до получения первого байта от сервера,
• last_byte — время до получения полного ответа от сервера,
• last_byte inflight — время до получения полного ответа от сервера с учетом незавершенных запросов.

Балансировка нагрузки по наименьшему времени в nginx активируется при использовании директивы least_time в конфигурации группы серверов:

    upstream myapp1 {
        least_time header;
        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.

В последних версиях nginx веса также можно использовать с балансировкой нагрузки least-connected и ip-hash.

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

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

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

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

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

Наконец, подписки на платный NGINX Plus включают балансировку нагрузки приложений, проверки их работоспособности, мониторинг активности и перенастройку групп серверов на лету.