Nginx для балансировки нагрузки в кластере docker » администрирование серверов

Введение

Ранее я подробно рассказывал о базовой настройке nginx и настройки его в качестве proxy сервера. Так же у меня есть подробная статья по настройке web сервера на базе Centos 7. Сегодня я расскажу о том, как настроить балансировку нагрузки с помощью nginx. Чаще всего это необходимо для балансировки нагрузки между бэкендами и обеспечения отказоустойчивости в работе web сервиса. Существуют различия в возможностях тонкой настройки балансировщика в бесплатной и платной версии nginx plus. Это один из первых моментов, где я столкнулся с тем, что мне стали необходимы функции платной версии, которых не было в бесплатной. Но цена nginx plus велика.

Я рассмотрю простой пример, где у нас в качестве web сервера выступает nginx, который распределяет запросы на три равноценных сервера. В случае выхода из строя одного из серверов, он все запросы будет адресовать оставшимся в работе серверам. Теоретически это должно проходить незаметно для клиентов. Практически же есть масса нюансов в работе этого инструмента. Постараюсь обо всем этом рассказать.

Две балансировки нагрузки

2.1 Поддержка протокола

Nginx работает на 7-м уровне сети и может использоваться для стратегий разгрузки самого http-приложения. Поддержка семиуровневой балансировки нагрузки протоколов HTTP и HTTPS. Для поддержки четырехуровневого протокола требуется сторонний подключаемый модуль ngx_tcp_proxy_module yaoweibin для реализации восходящего потока TCP.

Кроме того, сам nginx постепенно улучшает поддержку других протоколов:

nginx 1.4.0 официально поддерживает как Websocket, так и SPDY.
nginx 1.6.0 официально поддерживает SPDY 3.1
nginx 1.10.0 официально поддерживает HTTP / 2

В настоящее время последняя стабильная версия nginx — 1.10.2, а основная разрабатываемая версия — 1.11.5. Последняя версия Tengine унаследовала версию nginx 1.6.2.

2.2 Стратегия баланса

Стратегии балансировки нагрузки Nginx можно разделить на две категории: встроенные стратегии и расширенные стратегии. Встроенные стратегии включают взвешенный опрос и IP-хэш. По умолчанию эти две стратегии будут скомпилированы в ядро nginx. Вам нужно только указать параметры в конфигурации nginx. Существует множество стратегий расширения, таких как справедливый, общий хэш, согласованный хеш и т. Д., Которые по умолчанию не компилируются в ядро nginx.

Взвешенный круговой алгоритм Принцип опроса очень прост: сначала мы познакомимся с основным процессом опроса. Ниже представлена блок-схема обработки запроса:
На рисунке следует отметить два момента: во-первых, если алгоритм взвешенного циклического поиска можно разделить на первый глубокий поиск и первый широкий поиск, то nginx использует первый алгоритм глубокого поиска, который сначала распределяет все запросы между машинами с большим весом. Пока вес машины не упадет ниже, чем у других машин, она начинает распределять запрос на следующую машину с большим весом; во-вторых, когда все внутренние машины не работают, nginx немедленно сбрасывает биты флагов со всех машин, чтобы Начальное состояние — избежать того, чтобы все машины находились в состоянии тайм-аута, в результате чего весь интерфейс был забит.

ip hash IP hash — это еще одна стратегия балансировки нагрузки, встроенная в nginx. Процесс очень похож на опрос, за исключением того, что алгоритм и конкретные стратегии изменились, как показано на следующем рисунке:
Основная реализация алгоритма хеширования ip выглядит следующим образом:
Из кода видно, что значение хеш-функции связано не только с ip, но и с количеством внутренних машин. После тестирования вышеуказанный алгоритм может непрерывно генерировать 1045 взаимно различных значений, что является жестким пределом алгоритма. Для этого nginx использует механизм защиты: когда после 20 хешей не обнаруживаются доступные машины, алгоритм вырождается в режим опроса. Следовательно, по сути, алгоритм хеширования ip — это замаскированный алгоритм опроса. Если начальные значения хеширования двух IP-адресов совпадают, то запросы от этих двух IP-адресов всегда будут приходить на один и тот же сервер, что сбалансировано. Секс похоронил глубоко скрытую опасность.

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

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

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

session_sticky Эта стратегия заключается в том, что все запросы в рамках сеанса будут приходить на один и тот же узел. Его можно использовать в распределенной архитектуре, но когда узел «зависает», информация о сеансе будет потеряна одновременно. Если вы используете решение для синхронизации сеанса для синхронизации информации о сеансе со всеми узлами, затраты будут высокими. Используйте это решение осторожно. Nginx не поддерживает эту стратегию по умолчанию, tengine поддерживает:tengine.taobao.org/document_cn….

2.2 Пример конфигурации

HTTP

Для более конкретной конфигурации nginx, пожалуйста, обратитесь к:github.com/superhj1987…
TCP — ngx_tcp_proxy_module

Шаг 4. Развертывание служб на swarm

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

C:\temp> docker stop
C:\temp> docker rm

1 2	C\temp>docker stop C\temp>docker rm

Далее мы будем использовать образ контейнеров web_1 и web_2, которые мы создали на предыдущих этапах этого упражнения, чтобы развернуть две контейнерные службы для нашего swarm кластера.

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

C:\ > docker service create —name=s1 —publish mode=host,target=80 —endpoint-mode dnsrr web_1 powershell -command {echo sleep; sleep 360000;}

1	C\>docker service create—name=s1—publish mode=host,target=80—endpoint-modednsrrweb_1powershell-command{echo sleep;sleep360000;}

C:\ > docker service create —name=s2 —publish mode=host,target=80 —endpoint-mode dnsrr web_2 powershell -command {echo sleep; sleep 360000;}

1	C\>docker service create—name=s2—publish mode=host,target=80—endpoint-modednsrrweb_2powershell-command{echo sleep;sleep360000;}

Теперь вы должны запустить две службы, s1 и s2. Вы можете просмотреть их статус, выполнив следующую команду на вашем диспетчере swarm:

C:\ > docker service ls

1	C\>docker service ls

Кроме того, вы можете просмотреть информацию о экземплярах контейнера, которые определяют конкретную службу, со следующими командами (где именем проверяемой службы (например, или ):

# List all services
C:\ > docker service ls
# List info for a specific service
C:\ > docker service ps

1
2
3
4

# List all services

C\>docker service ls

# List info for a specific service

C\>docker service ps

(Необязательно) Масштабируйте свои службы

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

C:\ > docker service scale =
# e.g. docker service scale s1=3

1 2	C\>docker service scale= # e.g. docker service scale s1=3

Nginx как load balancer

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

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

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

Если же он отсутствует, то придется пересобрать 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;
}

}

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

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

Установка Nginx под Linux

Итак, предполагается, что есть только что установленная операционная система Ubuntu 18.04 LTS без графического интерфейса пользователя.

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

sudo apt update

В выводе результата команды можно увидеть, что доступны обновления. Рекомендуются их обновить с помощью команды (подсказка «Run ‘apt list –upgradable’»):

sudo apt upgrade

По завершению обновления пакетов приложений можно приступить к установке непосредственно веб-сервера.

Нужно выполнить команду команду:

sudo apt install nginx

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

Далее нужно проверить, что помимо самой установки, веб-сервер запустился и готов обрабатывать запросы (для данной команды использование sudo не обязательно):

service nginx status

В ответ можно увидеть, что состояние службы active (running). Это значит, что веб-сервер работает в штатном режиме, и можно переходить к настройке трансляции запросов либо к генерации самоподписанного сертификата (если в этом есть необходимость).

Кластерная файловая система GlusterFS для статических файлов

Для обеспечения мгновенной доступности статического контента и упрощения доступа к нему можно использовать различные подходы. Если ваш хостинг-провайдер предлагает высокодоступное хранилище, доступное по протоколу Swift или S3, разумно использовать его, храня данные вне серверов. Если ваш сайт поддерживает такое решение, рекомендуем использовать его. В этом случае вы можете просто пропустить данный раздел.

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

Синхронизация с помощью rsync, inosync. Методы широко применяются, но имеют основной недостаток, связанный с возможным рассогласованием или потерей файлов, которые на момент отказа еще не были синхронизированы. Кроме того, в зависимости от объемов хранимых данных и типов хранимых файлов, данный подход часто может быть неосуществим практически.

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

Высокая доступность с помощью распределенной файловой системы. Этот подход немного сложнее в настройке и управлении, однако гарантирует одинаковую доступность файлов и каталогов.

Мы рассмотрим способ синхронизации для сессий PHP и обеспечение высокой доступности для статических файлов с помощью высокодоступной распределенной системы GlusterFS с трехкратной репликацией данных.

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

При настройке GlusterFS ожидается, что все серверы соединены по внутренней сети 10.0.0.0/24 и имеют адреса 10.0.0.1, 10.0.02, 10.0.03. Если у вас другие адреса, измените настройки, приведенные в инструкции соответствующим образом.

Для дальнейшей настройки GlusterFS перейдите в наше руководство по настройке для трехузлового кластера. В руководстве приведены инструкции для CentOS 7, Debian 9, Ubuntu 16.04 или 18.04.

После успешного завершения настройки GlusterFS создайте каталог и добавьте в запись вида:

/mnt/gluster /var/www/website.com/assets none bind,_netdev,default 0 0

В общем случае, мы не рекомендуем размещать сам код сайта в распределенной файловой системе. Специфические системные вызовы, которые используют движки, могут снизить производительность для таких сред, которые на лету автоматически определяют изменения и применяют их — например, PHP-FPM. С другой стороны, если после чтения кода обращение к файловой системе не происходит, можно легко использовать хранение кода в GlusterFS.

Проблемы балансировки нагрузки

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

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

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

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

proxy_connect_timeout — задаёт таймаут для установления соединения с проксированным сервером. При отсутствии ответа за указанное время сервер будет считаться неработающим. Дефолтное значение 60 секунд. Это очень много, если у вас большие нагрузки. За минуту скопится огромное количество висящих соединений, которые мог бы обработать другой бэкенд.
proxy_read_timeout — задаёт таймаут при чтении ответа проксированного сервера. Дефолт тоже 60 секунд. Чаще всего имеет смысл уменьшить значение.

Пять Тенгин

Tengine — это серверное программное обеспечение, разработанное Taobao на основе открытого исходного кода nginx. Помимо унаследованных характеристик nginx, оно предоставляет некоторые функции, доступные только в коммерческой версии nginx. В основном синхронизированная с обновлением nginx, последняя версия унаследовала стабильную версию nginx 1.6.2.

5.1 Особенности

Особенности тенгина включают, но не ограничиваются:

Более удобный дисплей информации об эксплуатации и обслуживании
Механизм загрузки динамического модуля
Автоматически устанавливать количество процессов и привязывать соответствие ЦП к количеству ЦП
Более удобные параметры командной строки, такие как список скомпилированных модулей, поддерживаемые инструкции и т. Д.
Более мощные возможности балансировки нагрузки, включая модуль согласованного хеширования, модуль сохранения сеанса и активную проверку работоспособности на внутреннем сервере, а также автоматический переход в онлайн и офлайн в зависимости от статуса сервера
Поддержка динамического языка сценариев Lua. Расширенные функции очень эффективны и просты
Поддержка механизма входного фильтра. С помощью этого механизма удобнее писать брандмауэр веб-приложений.

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

Что касается балансировки нагрузки, Tengine имеет следующие характеристики, которые в основном компенсируют недостатки nginx в балансировке нагрузки:

Поддержка согласованного модуля хеширования
Модуль сохранения сеанса
Активная проверка работоспособности внутреннего сервера.
Добавлен механизм, при котором тело запроса не кешируется на диск

Настройка HAProxy под ваш сервер

Теперь добавьте следующие каталоги и файл статистики для записей HAProxy:

Создайте символьную ссылку для двоичных файлов, чтобы вы могли запускать команды HAProxy от имени обычного пользователя:

Если вы хотите добавить прокси-сервер в систему в качестве службы, скопируйте файл haproxy.init из examples в свой каталог /etc/init.d. Отредактируйте права доступа к файлу, чтобы скрипт выполнялся, а затем перезагрузите демон systemd:

В целях удобства также рекомендуется добавить нового пользователя для запуска HAProxy:

После этого вы можете еще раз проверить номер установленной версии с помощью следующей команды:

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

Наконец, файрвол в CentOS 8 по умолчанию довольно рестриктивен для этого проекта. Используйте следующие команды, чтобы разрешить необходимые службы и перезагрузить файрвол:

Переадресация схемы для Linux и обратных прокси-серверов не IIS

Приложения, вызывающие UseHttpsRedirection и UseHsts, помещают сайт в бесконечный цикл при развертывании в Службе приложений Azure Linux, виртуальной машине Linux в Azure или за любыми другими обратными прокси-серверами, помимо IIS. TLS завершается обратным прокси-сервером, и Kestrel не знает о правильной схеме запроса. OAuth и OIDC также не работают в этой конфигурации, поскольку создают неверные перенаправления. UseIISIntegration добавляет и настраивает ПО промежуточного слоя переадресованных заголовков при работе за IIS, но для Linux (интеграция с Apache или Nginx) нет аналогичной автоматической конфигурации.

Для переадресации схемы с прокси-сервера, когда используется не IIS, добавьте и настройте ПО промежуточного слоя перенаправленных заголовков. В используйте следующий код:

Шаг 3. Присоединение хостов к swarm

В результате предыдущих шагов на одной из ваших хост-машин должен быть образ контейнера nginx, а на остальных хостах должны быть образы веб-сервера «web_1» и «web_2». На этом этапе мы присоединимся к последним узлам кластера swarm.

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

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

Замените IP-адресом вашего хоста

C:\temp> docker swarm init —advertise-addr = —listen-addr : 2377

1	C\temp>docker swarm init—advertise-addr=—listen-addr2377

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

Замените IP-адресом вашего хоста (то есть которое вы использовали для инициализации swarm узла-менеджера)
Замените рабочим -токеном, (вы также можете получить токен рабочего- )

C:\temp> docker swarm join —token :2377

1	C\temp>docker swarm join—token2377

Теперь ваши узлы настроены на формирование swarm кластера ! Состояние узлов можно увидеть, выполнив следующую команду на управляющем узле:

C:\temp> docker node ls

1	C\temp>docker node ls

Другие сценарии использования прокси-сервера и подсистемы балансировки нагрузки

Если не используется при размещении , ПО промежуточного слоя перенаправления заголовков не включается по умолчанию. ПО промежуточного слоя перенаправления заголовков нужно включить, чтобы приложение могло обрабатывать перенаправленные заголовки с UseForwardedHeaders. После включения ПО промежуточного слоя, если не задан параметр ForwardedHeadersOptions, для свойства по умолчанию устанавливается значение ForwardedHeaders.None.

В ПО промежуточного слоя с ForwardedHeadersOptions настройте перенаправление заголовков и в . Вызовите метод UseForwardedHeaders в , прежде чем вызывать другое ПО промежуточного слоя:

Примечание

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

Различные алгоритмы балансировки нагрузки.

Указание серверов в разделе бэкенда позволяет HAProxy использовать эти серверы для балансировки нагрузки в соответствии с алгоритмом циклического перебора, когда это возможно.

Алгоритмы балансировки используются для определения того, на какой сервер в бэкенде передается каждое соединение. Вот некоторые из полезных опций:

Roundrobin: каждый сервер используется по очереди в соответствии со своим весом. Это самый плавный и честный алгоритм, когда время обработки серверами остается равномерно распределенным. Этот алгоритм является динамическим, что позволяет регулировать вес сервера на лету.
Leastconn: выбирается сервер с наименьшим количеством соединений. Циклический перебор выполняется между серверами с одинаковой нагрузкой. Использование этого алгоритма рекомендуется для длинных сеансов, таких как LDAP, SQL, TSE и т. д., но он не очень подходит для коротких сеансов, таких как HTTP.
First: первый сервер с доступными слотами для подключения получает соединение. Серверы выбираются от самого низкого числового идентификатора до самого высокого, который по умолчанию соответствует положению сервера в ферме. Как только сервер достигает значения maxconn, используется следующий сервер.
Source: IP-адрес источника хешируется и делится на общий вес запущенных серверов, чтобы определить, какой сервер будет получать запрос. Таким образом, один и тот же IP-адрес клиента будет всегда доставаться одному и тому же серверу, в то время как серверы остаются неизменными.

Что такое HAProxy?

HAProxy, или High Availability Proxy, является программным балансировщиком нагрузки TCP/HTTP. Он распределяет рабочую нагрузку по серверам для обеспечения максимальной производительности и оптимизации использования ресурсов. HAProxy поддерживает гибко настраиваемые методы проверки доступности, обработки отказов и восстановления после них.

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

В одном из вариантов настройки HAProxy устанавливается на каждом сервере приложений, выполняющем запросы к базе данных. Такой вариант отлично подходит при наличии нескольких серверов, что позволяет контролировать нагрузку и скрыть организацию кластера СУБД. Приложение подключается к локальному HAProxy (например, устанавив mysql-соединение на 127.0.0.1:3306) и может получить доступ ко всем серверам базы данных. Веб-сервер и HAProxy вместе образуют рабочий блок, поэтому веб-сервер не будет работать, если HAProxy недоступен.

Использование HAProxy для балансировки нагрузки дает следующие преимущества:

Все приложения получают доступ к кластеру через указанные IP-адреса. Внутренняя топология кластера базы данных скрывается за HAProxy.
Соединения MySQL распределены между доступными узлами БД.
Можно добавлять или удалять узлы базы данных без необходимости внесения каких-либо изменений в приложения.
Как только достигается максимальное количество соединений с базой данных, новые соединения ставятся в очередь. Это удобный способ ограничения количества запросов на соединение с базой данных, обеспечивающий защиту от перегрузки.

ClusterControl поддерживает развертывание HAProxy из пользовательского интерфейса, поддерживая стандартные алгоритмы балансировки, предоставляемые HAProxy:

Round Robin. Каждый сервер получает запросы пропорционально своему весу, при этом веса серверов могут меняться на лету.
Least Connection. Выбирается сервер с наименьшим количеством активных соединений.
Source Hash Scheduling. Сервер для соединения назначается на основе хэша IP-адреса отправителя запроса и весов серверов.