Выбор техники балансировки нагрузки NGINX Plus

Тестирование является наиболее простым, если все серверы имеют одинаковую емкость. Если нет, вам нужно установить вес сервера, чтобы машины с большей емкостью получали больше запросов. См.  Настройка весов, когда серверы не идентичны  ниже.

Некоторые метрики для проверки во время тестирования:

• Загрузка процессора и памяти. Посмотрите на процент использования общей емкости как для процессора, так и для памяти. Если не все серверы загружены одинаково, трафик распределяется неэффективно.
• Время отклика сервера — если время для одних серверов постоянно больше, чем для других, то каким-то образом «более тяжелые» запросы (требующие больших вычислений или обращений к базе данных или другим службам) перенаправляются на них несбалансированным образом. Попробуйте отрегулировать веса, потому что их отсутствие может вызвать дисбаланс, а не проблему с техникой балансировки нагрузки.
• Общее время ответа клиенту. Опять же, для некоторых серверов постоянно увеличивается время, которое позволяет предположить, что они получают непропорционально большую долю отнимающих много времени запросов. И снова, вы можете попробовать настроить вес, чтобы увидеть, если это устраняет проблему.
• Ошибки и неудачные запросы. Необходимо убедиться, что количество неудачных запросов и других ошибок не превышает обычного для вашего сайта, в противном случае вы тестируете условия ошибок вместо реалистичного трафика. Для некоторых ошибок (таких как код ответа HTTP  404 Not Found) время ответа может быть намного быстрее, чем если бы сервер должен был получить запрошенный файл; с помощью алгоритмов балансировки нагрузки Least Connections и Least Time это может привести к тому, что балансировщик нагрузки выберет сервер, который на самом деле не работает должным образом.

Плюсы, минусы и варианты использования

Итак, теперь давайте рассмотрим преимущества и недостатки каждого метода распределения нагрузки и опишем некоторые варианты использования, для которых они особенно подходят. Мы обсудим их в порядке повышения пригодности для большинства случаев использования. В качестве быстрого предварительного просмотра: мы считаем, что Least Connections (а для NGINX Plus и Least Time) — лучший выбор для самого широкого диапазона вариантов использования.

Хеш и IP Хеш

Методы балансировки нагрузки Hash и IP Hash создают фиксированную связь между клиентским запросом данного типа (записанным в хэш-значении) и определенным сервером. Вы можете распознать это как постоянство сеанса — все запросы с данным значением хеша всегда отправляются на один и тот же сервер.

Самый большой недостаток этих методов заключается в том, что они не гарантируют равномерное распределение запросов по серверам, не говоря уже о равномерной балансировке нагрузки. Алгоритм хэширования равномерно делит набор всех возможных значений хеш-функции на «сегменты», по одному на сервер в группе восходящего потока, но нет никакого способа предсказать, будут ли фактически выполняемые запросы иметь хэши, которые будут равномерно распределены. Предположим, например, что десять клиентов получают доступ к сайту, и алгоритм хеширования IP связывает хеш для семи IP-адресов с  web1 , один с  web2 , а два с  web3 . Сервер  web1  получает в два раза больше запросов, чем другие серверы вместе взятые.

Поэтому имеет смысл использовать Hash или IP Hash, если польза от поддержки сеансов перевешивает возможные негативные последствия несбалансированной нагрузки. Это единственная форма сохранения сеанса в NGINX. NGINX Plus предоставляет три других   механизма сохранения сеанса, которые являются более сложными и работают в сочетании с фактической балансировкой нагрузки (вы настраиваете их с помощью  sticky директивы). Но вы можете выбрать Hash или IP Hash даже с NGINX Plus, потому что эти три механизма не работают в следующих случаях:

• Приложение браузера или клиента не принимает файлы cookie, и приложение не может работать с механизмами сохранения сеанса без файлов cookie. Используйте метод IP-хеша, чтобы связать каждого клиента (в частности, его IP-адрес) с конкретным сервером.
• Вы хотите каждый раз отправлять запросы на данный URL на один и тот же сервер, чтобы воспользоваться преимуществами кэширования на самом сервере. Используйте метод Hash с  $request_uri переменной, чтобы каждый раз получать файл с одного и того же сервера. Например, предположим, что вы знаете, что для обслуживания определенного   файла .php требуется несколько трудоемких обращений к базе данных, но извлеченные данные изменяются не часто и поэтому кэшируются. Если вы перенаправляете все запросы на файл на один и тот же сервер, только первый клиент испытывает длительную задержку из-за вызовов базы данных. Для всех последующих клиентов данные быстро извлекаются из кэша. Другое преимущество состоит в том, что только один сервер должен кэшировать этот конкретный набор данных. Поскольку вы не заканчиваете кеширование одинаковых данных на каждом сервере, вы можете использовать меньшие кеши.

Есть несколько случаев, когда хэш IP — и хэш, когда IP-адрес клиента находится в ключе — не работают:

• Когда IP-адрес клиента может измениться во время сеанса, например, когда мобильный клиент переключается из сети Wi-Fi в сотовую сеть.
• Когда запросы от большого количества клиентов проходят через прямой прокси, потому что IP-адрес прокси используется для всех из них.

Хеши являются детерминированными (алгоритм хеширования каждый раз дает одинаковые результаты). Это имеет пару положительных побочных эффектов: все экземпляры NGINX Plus или NGINX в запросах на балансировку нагрузки развертывания выполняются одинаковым образом, и сопоставление между хешем и сервером сохраняется при перезапусках балансировщика нагрузки. (Это фактически пересчитывается после перезапуска, но, поскольку результат всегда один и тот же, он эффективно сохраняется.)

On the other hand, changing the set of upstream servers usually forces recalculation of at least some of the mappings, breaking session persistence. You can reduce the number of recalculated mappings somewhat:

• For the Hash method, include the consistent parameter to the hash directive; NGINX Plus uses theketama hashing algorithm, which results in less remapping.
• For the IP Hash method, when you remove a server from the upstream group temporarily, add thedown parameter to its server directive, as for web2 in the following example. The mappings are not recalculated, on the assumption that the server will return to service soon.

  upstream backend {
      ip_hash;
  
      server web1;
      server web2 down;
      server web3;
  }

upstream backend {
    server web1 weight=6;
    server web2 weight=3;
    server web3;
}