Тема Nginx (2): стратегия балансировки нагрузки Nginx и ее конфигурация

Nginx

В этой статье представлена ​​стратегия балансировки нагрузки Nginx, принцип согласованного распределения хэшей и общая конфигурация удаления и восстановления неисправных узлов.

Источник статьи: Технологический институт CreditEase и команда CreditEase по платежам и расчетам. Обмен технологиями, этап 1 — Чжоу Хэн, старший технический менеджер группы данных Octagon по платежам и расчетам CreditEase, «Подробности Nginx»

Участник: Чжоу Хэн, старший технический менеджер группы данных Octagon, CreditEase Payment and Settlement

Оригинальный текст был впервые опубликован на официальном аккаунте технической команды по платежам и расчетам: wild pointer

ПриквелТема Nginx (1): Обратный прокси-сервер Nginx и его конфигурацияПодробно знакомит с одной из функций Nginx — обратным прокси. В этой статье речь пойдет о второй особенности Nginx — балансировке нагрузки.

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

  • Свяжите несколько серверных узлов вместе, чтобы обеспечить унифицированную запись службы.
  • Аварийное переключение в случае аварии может добавить уровень страховки для снижения потерь.
  • Уменьшите сложность онлайн-операций и обслуживания и обеспечьте плавный онлайн-запуск. Студентам, занимающимся эксплуатацией, техническим обслуживанием и развитием, это нравится.

В тему официально входит следующее.

1. Стратегия балансировки нагрузки Nginx

Балансировка нагрузки заключается в «сбалансированном» распределении запросов на несколько серверов бизнес-узлов. «Баланс» здесь основан на реальном сценарии и потребностях бизнеса.

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

Nginx поддерживает множество стратегий балансировки нагрузки, основные из которых следующие:

  • по-круговой
  • случайный (случайный)
  • вес (вес)
  • честный (по времени отклика, сторонний плагин)
  • url_hash (хеш-значение URL-адреса)
  • ip_hash (хеш-значение ip)
  • наименьший_конн (наименьшее количество соединений)

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

Категория 1 Лучшая реализация

  • вес (вес)
  • случайный (случайный)

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

Голосование само собой разумеется. Случайность здесь фактически эквивалентна методу опроса по теории вероятностей в случае большого количества запросов.

Справочник по конфигурации опроса:

#默认配置就是轮询策略
upstream server_group {
   server backend1.example.com;
   server backend2.example.com;
}

Ссылка на случайную конфигурацию:

upstream server_group { 
   random; 
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

Приоритет производительности второй категории

  • вес (вес)
  • честный (по времени отклика, сторонний плагин)
  • наименьший_конн (наименьшее количество соединений)

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

Чем машина лучше? Эта проблема также имеет много аспектов.

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

Ссылка на конфигурацию веса:

upstream server_group {
    server backend1.example.com weight=5;
    #默认为不配置权重为1
    server backend2.example.com;
}

Справка по настройке времени отклика (справедливая): модуль nginx-upstream-fair необходимо добавить при компиляции nginx.

upstream server_group{
   fair;
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

Справочник по конфигурации минимального соединителя (Least_conn):

upstream server_group {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

Третья категория остается стабильной

  • ip_hash
  • url_hash

Многие запросы имеют состояние: какой бизнес-узел был запрошен в прошлый раз и какая машина запрошена в этот раз. Например, обычная сессия — это такой бизнес с отслеживанием состояния.

Здесь Nginx предоставляет правила присвоения идентификатора пользователя по хешу ip клиента и хешу url в качестве маркера назначения. По сути, по-прежнему необходимо найти неизмененные элементы в запросе пользователя и извлечь их, чтобы их можно было выделить.

Ссылка на конфигурацию ip_hash:

upstream server_group {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

ссылка на конфигурацию url_hash:

upstream server_group{
   hash $request_uri consistent;
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

2. Nginx поддерживает последовательное хеширование для раздачи.

NGINX поддерживает согласованные хеш-распределение, то есть в соответствии с конфигурацией.

Что такое последовательный хэш? Зачем внедрять этот механизм? В производственной среде количество бизнес-узлов часто увеличивается или уменьшается. Даже если это увеличение или уменьшение является пассивным, оно также может повлиять на распределение хэшей. Как мы можем минимизировать влияние? Именно здесь изобретается последовательное хеширование.

Согласованное хеширование решает две проблемы:

  • Распределение особенно неравномерно;
  • В дополнение к влиянию на запросы, назначенные этому узлу, изменения узла также вызовут перераспределение запросов на другие узлы.

1) Как решить проблему неравномерного распределения

Скопируйте каждый из исходных узлов из N виртуальных узлов и дайте этим виртуальным узлам имя.

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

2) Как решить проблему смены узла

Основная идея последовательного хеширования:

  • Определите пространство значений [0, (2 ^ 32) -1]. Эквивалентно принимать линейный сегмент длиной от 0 до 2 ^ 32-1.
  • Узел сопоставляется с сегментом линии. Каждый узел, включая виртуальный узел, получает значение с помощью алгоритма хеширования, а затем сопоставляется с этим диапазоном интервалов значений.

Как показано ниже.

  • Вычислите хеш-значение данных. Используйте алгоритм хеширования, чтобы получить значение ключевой строки в запросе и найти позицию в сегменте строки. Если вычисленное значение больше 2^32-1, оно считается равным 0. В соответствии с этим правилом отрезок линии фактически соединяется конец к концу, образуя кольцо, поэтому его также называют хеш-кольцом.
  • Узел данных находит исходный узел на линейном сегменте. Найдите ближайший узел вдоль сегмента линии справа и используйте этот узел в качестве домашнего узла этих данных.

Давайте посмотрим на влияние изменений узла на непротиворечивый хэш.

  • Сокращение узлов: например, если NodeA внезапно выйдет из строя, данные, изначально выделенные для других узлов, не изменятся. Только данные, выделенные для NodeA, найдут ближайшую к ним точку, тем самым уменьшив количество перераспределений хэша. Это также самое большое преимущество последовательного хэширования.
  • Увеличение узла: Например, сейчас объем запросов дрожит, и необходимо увеличить нагрузку на узел, чтобы уменьшить нагрузку. Когда добавляется новый узел NodeE, узел NodeE и его группа виртуальных узлов распределяются в кольце хеширования в соответствии со значением хеш-функции. В это время большая часть данных не будет меняться в соответствии с правилом согласованного хеширования, чтобы найти узел Node, которому он принадлежит.Рассчитываются только те значения, чтобы обнаружить, что данные, расположенные ближе к NodeE, изменились, но число ограничено ведь, уменьшаясь за счет увеличения узлов.

3. Удаление и восстановление неисправных узлов

Давайте сначала рассмотрим классическую конфигурацию, а затем объясним ее подробно.

upstream server_group {
    server backend1.example.com ;
    server backend2.example.com  max_fails=3 fail_timeout=30s;
    server backup1.example.com  backup;
}

max_fails=number

Этот параметр определяет, сколько раз произойдет сбой бэкэнда запросов, и бизнес-узел будет приостановлен, и на него не будут отправляться новые запросы.Значение по умолчанию — 1. Этот параметр необходимо использовать вместе с fail_timeout.

Не по теме: как определить отказ, есть много типов, здесь, потому что он в основном имеет дело с HTTP-прокси, поэтому больше сосредоточьтесь на proxy_next_upstream.

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

fail_timeout=time

Определяет, как долго делать паузу, когда Nginx определяет, что этот узел недоступен. Если не настроено, по умолчанию 10 с.

Вышеуказанные два параметра объединены для рассмотрения: когда Nginx обнаружит, что запрос, отправленный на этот узел, не прошел 3 раза, он удалит узел.Время удаления составляет 30 с, и запрос будет снова отправлен на этот узел через 30 с.

backup

Как и в операторе switch по умолчанию, когда основные узлы не работают, запрос будет отправлен на резервный узел. Это последний спасатель.

4. Резюме

Поскольку Nginx использует технологию обратного прокси-сервера, он полностью контролирует пересылку запросов, что делает возможной балансировку нагрузки.

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

Категории