Использование nginx для балансировки нагрузки. настройка upstream для распределения http-запросов

Health checks

Я предлагаю рассматривать health checks как оптимизацию процесса выбора «живого» сервера. Это ни в коем случае не дает никаких гарантий. Соответственно, в ходе выполнения пользовательского запроса мы с большей вероятностью будем попадать только на «живые» серверы. Балансировщик регулярно обращается по определенному URL, сервер ему отвечает: «Я жив и готов».

Health checks: с точки зрения бэкенда

С точки зрения бэкенда можно сделать интересные вещи:

Проверить готовность к работе всех нижележащих подсистем, от которых зависит работа бэкенда: установлено нужное количество соединений с базой данных, в пуле есть свободные коннекты и т.д., и т.п.
На Health checks URL можно повесить свою логику, если используемый балансировщик не особо интеллектуальный (допустим, вы берете Load Balancer у хостера). Сервер может запоминать, что «за последнюю минуту я отдал столько-то ошибок — наверное, я какой-нибудь „неправильный“ сервер, и последующие 2 минуты я буду отвечать „пятисоткой“ на Health checks. Таким образом сам себя забаню!» Это иногда очень спасает, когда у вас неконтролируемый Load Balancer.
Как правило, интервал проверки около секунды, и нужно, чтобы Health check handler не убил ваш сервер. Он должен быть легким.

Health checks: имплементации

Как правило, здесь все у всех всё примерно одинаково:

Request;
Timeout на него;
Interval, через который мы делаем проверки. У навороченных прокси есть jitter, то есть некая рандомизация для того, чтобы все Health checks не приходили на бэкенд одномоментно, и не убивали его.
Unhealthy threshold — порог, сколько должно пройти неудачных Health checks, чтобы сервис пометить, как Unhealthy.
Healthy threshold — наоборот, сколько удачных попыток должно пройти, чтобы сервер вернуть в строй.
Дополнительная логика. Вы можете разбирать Check status + body и пр.

Nginx реализует функции Health check только в платной версии nginx+.

Отмечу особенность Envoy, у него есть Health check panic mode. Когда мы забанили, как «нездоровые», больше, чем N% хостов (допустим, 70%), он считает, что все наши Health checks врут, и все хосты на самом деле живы. В совсем плохом случае это поможет вам не нарваться на ситуацию, когда вы сами себе прострелили ногу, и забанили все серверы. Это способ еще раз подстраховаться.

Возможности Win2k3

Вообще говоря, одни кластеры предназначены для повышения доступности данных,
другие — для обеспечения максимальной производительности. В контексте статьи нас
будут интересовать MPP (Massive Parallel Processing) — кластеры, в
которых однотипные приложения выполняются на нескольких компьютерах, обеспечивая
масштабируемость сервисов. Существует несколько технологий, позволяющих
распределять нагрузку между несколькими серверами: перенаправление трафика,трансляция адресов, DNS Round Robin, использование специальных
программ, работающих на прикладном уровне, вроде веб-акселераторов. В
Win2k3, в отличие от Win2k, поддержка кластеризации заложена изначально и
поддерживается два типа кластеров, отличающихся приложениями и спецификой
данных:

1. Кластеры NLB (Network Load Balancing) — обеспечивают
масштабируемость и высокую доступность служб и приложений на базе протоколов TCP
и UDP, объединяя в один кластер до 32 серверов с одинаковым набором данных, на
которых выполняются одни и те же приложения. Каждый запрос выполняется как
отдельная транзакция. Применяются для работы с наборами редко изменяющихся
данных, вроде WWW, ISA, службами терминалов и другими подобными сервисами.

2. Кластеры серверов – могут объединять до восьми узлов, их главная
задача — обеспечение доступности приложений при сбое. Состоят из активных и
пассивных узлов. Пассивный узел большую часть времени простаивает, играя роль
резерва основного узла. Для отдельных приложений есть возможность настроить
несколько активных серверов, распределяя нагрузку между ними. Оба узла
подключены к единому хранилищу данных. Кластер серверов используется для работы
с большими объемами часто изменяющихся данных (почтовые, файловые и
SQL-серверы). Причем такой кластер не может состоять из узлов, работающих под
управлением различных вариантов Win2k3: Enterprise или Datacenter (версии Web и
Standart кластеры серверов не поддерживают).

В Microsoft Application Center 2000 (и только) имелся еще один вид
кластера — CLB (Component Load Balancing), предоставляющий возможность
распределения приложений COM+ между несколькими серверами.

Мониторинг

Если Nginx считает, что бэкенд сервер недоступен, то временно перестает слать на него запросы. За это отвечает две директивы:

max_fails — задает количество неудачных попыток подключений, после которых бэкенд определенное время считается недоступным;Курс Executive Leadership англійською.

З тобою працюватиме Academic director & Program adviser у Google Девід Слокум.
Хочу на курс

fail_timeout — время, в течение которого сервер считается недоступным.

Параметры выглядят так:

upstream backend {

server backend1.somesite.com;
server backend2.somesite.com max_fails=3 fail_timeout=30s;
server backend3.somesite.com max_fails=2;

}

Параметры по умолчанию: 1 попытка, 10 секунд таймаута

Example of TCP and UDP Load-Balancing Configuration

This is a configuration example of TCP and UDP load balancing with NGINX:

In this example, all TCP and UDP proxy‑related functionality is configured inside the
block, just as settings for HTTP requests are configured in the
block.

There are two named
blocks, each containing three servers that host the same content as one another. In the
for each server, the server name is followed by the obligatory port number. Connections are distributed among the servers according to the
load‑balancing method: a connection goes to the server with the fewest number of active connections.

The three
blocks define three virtual servers:

The first server listens on port 12345 and proxies all TCP connections to the stream_backend group of upstream servers. Note that the
directive defined in the context of the module must not contain a protocol.

Two optional timeout parameters are specified: the
directive sets the timeout required for establishing a connection with a server in the stream_backend group. The
directive sets a timeout used after proxying to one of the servers in the stream_backend group has started.
The second server listens on port 53 and proxies all UDP datagrams (the parameter to the directive) to an upstream group called dns_servers. If the parameter is not specified, the socket listens for TCP connections.
The third virtual server listens on port 12346 and proxies TCP connections to backend4.example.com, which can resolve to several IP addresses that are load balanced with the Round Robin method.

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

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

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

Порядок ПО промежуточного слоя перенаправления заголовков

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

Кроме того, можно вызвать перед диагностикой:

Примечание

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

Централизованное хранение журналов приложений

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

access_log /var/log/nginx/access-10.0.0.1.log;
error_log /var/log/nginx/error-10.0.0.1.log;

Не забудьте организовать ротацию журналов — в общем каталоге это сделать несколько сложнее. Другой способ организации централизованного хранения записей журналов — отправлять их в общее хранилище, например, в Elasticsearch с помощью Filebeat и анализировать их в Kibana.

Deploy ARR and ‘URLRewrite’ for Load Balancing

ARR and URL rewrite are both IIS components, but you don’t need to install IIS yourself. You can if you wish, and then install URL Rewrite THEN ARR (In that order!) But it’s much simpler to download and use the ‘IIS Web Platform Installer‘.

Launch the Web Platform Installer, and do a search for URL > Select URL Rewrite > Add > Repeat the process, searching for ARR, and add Application Request Routing version 3, (Not the 2.5 version at the top!) > Next > Follow the wizard and complete the install.

Launch IIS Manager > Now you will see you have a new option ‘Server Farm‘ > Create Server Farm.

Give your server farm a name > Next > Add in all the ‘Back-end’ IIS servers > Finish.

You will get a pop-up asking if you want to create a URL rewrite rule. In this case we want a simple rewrite rule as we are doing plain old load balancing and we have no special requirements, so Select YES. (Only click No if you have specific rewrite requirements and you want to set them up manually).

Now test externally. WARNING don’t expect the page to ‘flip over’ every time, remember ARR is caching these web requests, and your browser will also be performing web page cashing, use a couple of browsers and wait a minute or two between refreshes to make sure that all the web servers are being used!.

Что такое 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-адреса отправителя запроса и весов серверов.

Установка MySQL

На следующей странице выбираем для скачивания mysql-installer-community:

В открывшемся окне кликаем по No thanks, just start my download:

Начнется загрузка файла для установки MySQL. Дожидаемся скачивания и запускаем установочный файл — в открывшемся окне выбираем Server only:

В следующем окне кликаем по Execute:

… и дожидаемся установки СУБД:

Откроется окно конфигурации MySQL — нажимаем Next:

Выбираем установку одиночного сервера MySQL:

Оставляем все значения по умолчанию для настроек сети:

Требуем сложные пароли:

Вводим дважды пароль для пользователя root:

* также, на данном этапе мы можем сразу добавить новых пользователей.

Устанавливаем СУБД как сервис и стартуем его:

Настройки готовы для применения — нажимаем Execute:

Дожидаемся применения настроек и кликаем по Next:

Настройка завершена:

Установка завершена — нажимаем Finish.

Сервер баз данных готов к использованию.

По умолчанию, PHP поддерживаем mysql — в этом можно убедиться на странице phpinfo, найдя раздел mysqlnd:

Ограничение количества соединений

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

Схожи ли обратный прокси и балансировщик нагрузки? Да, обратный прокси и регулятор нагрузки во многом похожи. Они оба могут использоваться для повышения производительности и доступности веб-сайта или приложения, а также для распределения трафика между несколькими серверами.

Самые сложные ошибки

Самые сложные ошибки — это те, которые неоднозначны.

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

Намного хуже, когда один серверов начинает вести себя непредсказуемо, например, сервер на все запросы отвечает ошибками, а на Health checks — HTTP 200.

Приведу пример из жизни.

У нас есть некий Load Balancer, 3 узла, на каждом из которых приложение и под ним Cassandra. Приложения обращаются ко всем экземплярам Cassandra, и все Cassandra взаимодействуют с соседними, потому что у Cassandra двухуровневая модель координатор и data noda.

Сервер Шредингера — один из них целиком: kernel: NETDEV WATCHDOG: eth0 (ixgbe): transmit queue 3 timed out.

Там произошло следующее: в сетевом драйвере баг (в интеловских драйверах они случаются), и одна из 64 очередей передачи просто перестала отправляться. Соответственно, 1/64 всего трафика теряется. Это может происходить до reboot, это никак не лечится.

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

Cassandra: coordinator -> nodes

У Cassandra, есть те самые спекулятивные ретраи (speculative retries), и эта ситуация отрабатывается очень легко. Есть небольшое повышение latency на 99 перцентиле, но это не фатально и в целом все работает.

App -> cassandra coordinator

Из коробки ничего не работает. Когда приложение стучится в Cassandra и попадает на координатор на «мертвом» сервере, никак это не отрабатывает, получаются ошибки, рост latency и т.д.

Попытаюсь в двух словах объяснить, как работает алгоритм Epsilon-greedy.

Есть задача о многоруком бандите (multi-armed bandit): вы находитесь в комнате с игровыми автоматами, у вас есть несколько монет, и вы должны за N попыток выиграть как можно больше.

Алгоритм включает две стадии:

Фаза «explore» — когда вы исследуете: 10 монеток тратите на то, чтобы определить, какой автомат лучше.
Фаза «exploit» — остальные монетки опускаются в лучший автомат.

Соответственно, маленькое количество запросов (10 — 30%) отправляются в round-robin просто на все хосты, считаем отказы, время ответа, выбираем лучшие. Потом 70 — 90% запросов посылаем на лучшие и обновляем свою статистику.

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

«Тонкая» настройка

Я назвал доклад «Тонкаянастройка» (англ. Fine tuning), потому что я подумал, что не все добираются до этой задачи, а стоило бы. Почему не добираются?

До этой задачи не все добираются, потому что, когда все работает, она не видна

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

Нужно много думать

Очень часто админ — тот человек, который настраивает балансировку — не в состоянии самостоятельно решить эту проблемы. Дальше мы посмотрим, почему.

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

Я утверждаю, что пора заниматься этой задачей по нескольким причинам:

Мир меняется, становится более динамичным, появляется много релизов. Говорят, что теперь правильно релизиться 100 раз в день, а релиз — это будущий факап с вероятностью 50 на 50 (прямо как вероятность встретить динозавра)
С точки зрения технологий тоже все очень динамично. Появился Kubernetes и другие оркестраторы. Нет старого доброго deployment, когда один бэкенд на каком-то IP выключается, накатывается обновление, и сервис поднимается. Сейчас в процессе rollout в k8s полностью меняется список IP апстримов.
Микросервисы: теперь все общаются по сети, а значит, нужно делать это надежно. Балансировка играет немаловажную роль.

Внешняя балансировка с помощью DNS

К настоящему моменту у вас должно быть настроено 3 сервера LEMP, при этом ваш сайт должен быть доступен по трем доменным именам — , , по протоколу HTTPS: . Как мы говорил ранее, у вас так же есть настроенный домен website.com, для которого созданы три записи типа A/AAAA:

;
;
.

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

Сертификат SSL для website.com

Если вы используете купленный сертификат, то все, что вам необходимо сделать — копировать виртуальный хост Nginx, созданный для , заменить в нем на , а сертификат Let’s Encrypt на приобретенный вами.

Если вы планируете для сайта использовать сертификат Let’s Encrypt, то, опять же, скопируйте виртуальный хост Nginx, получите для него SSL-сертификат точно так же, как было описано в по настройке LEMP-сервера.

Устранение неполадок

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

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

Можно сделать запись в журналы, а не в текст ответа. Запись в журналы позволяет сайту нормально работать во время отладки.

Для записи в журналы, а не в текст ответа, сделайте следующее:

Внедрите в класс как описано в разделе .
Поместите следующее встроенное ПО промежуточного слоя сразу после вызова UseForwardedHeaders в .

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

Удаленный IP-адрес из исходного запроса должен совпадать с записью в списке или , чтобы происходила обработка заголовков переадресации. Это позволяет избежать некоторых методов спуфинга, отклоняя запросы от ненадежных прокси-серверов пересылки. В журнале указываются адреса неизвестных обнаруженных прокси-серверов:

В приведенном выше примере указан прокси-сервер с адресом 10.0.0.100. Если сервер является доверенным прокси-сервером, добавьте его IP-адрес в (или добавьте доверенную сеть в ) в файле . Дополнительные сведения см. в разделе .

Важно!

Переадресацию заголовков следует разрешить только доверенным прокси-серверам и сетям. В противном случае будут возможны атаки подмены IP-адресов.

Шаг 2. Создание образа для двух контейнеризованных веб-служб IIS

На этом этапе мы создадим образ контейнеров для двух простых веб-приложений на базе IIS. Позже мы будем использовать эти изображения для создания двух служб докеров.

Примечание. Выполните инструкции в этом разделе на одном из узлов контейнера, которые вы намереваетесь использовать в качестве swarm.

Построение общего образа веб-сервера IIS

На моем личном репо GitHub я сделал простой файл Dockerfile, который можно использовать для создания образа веб-сервера IIS. Dockerfile просто включает роль веб-сервера IIS в контейнере microsoft/windowsservercore. Загрузите файл Dockerfile отсюда и сохраните его в каком-либо месте (например, C:\temp\iis) на одной из хост-машин, которые вы планируете использовать в качестве узла swarm. С этого места создайте образ, используя следующую команду:

C:\temp\iis> docker build -t iis-web.

1	C\temp\iis>docker build-tiis-web.

(Необязательно) Убедитесь, что готов образ веб-сервера IIS

Сначала запустите контейнер:

C:\temp> docker run -it -p 80:80 iis-web

1	C\temp>docker run-it-p8080iis-web

Затем используйте команду docker, чтобы убедиться, что контейнер работает. Запишите его идентификатор. Идентификатором вашего контейнера является значение В следующей команде.

Получить IP-адрес контейнера:

C:\temp>docker exec <code></code> ipconfig

1	C\temp>docker exec<code></code>ipconfig

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

Сборка двух пользовательских образов веб-сервера IIS

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

Сначала создайте на хост-компьютере простой файл с именем index_1.html. В файла любой текст. Например, файл index_1.html может выглядеть так:

Теперь создайте второй файл index_2.html. Опять же, в файла любой текст. Например, файл index_2.html может выглядеть так:

Теперь мы будем использовать эти HTML документы для создания двух пользовательских образов веб-сервисов.

Если созданный экземпляр контейнера iis-web еще не запущен, запустите новый, затем получите идентификатор контейнера, используя:

C:\temp> docker exec ipconfig

1	C\temp>docker exec ipconfig

Теперь скопируйте файл index_1.html со своего хоста на экземпляр контейнера IIS, который запущен, используя следующую команду:

C:\temp> docker cp index_1.html : C:\inetpub\wwwroot\index.html

1	C\temp>docker cp index_1.htmlC\inetpub\wwwroot\index.html

Затем остановите и зафиксируйте контейнер в его текущем состоянии. Это создаст образ контейнера для первой веб-службы. Давайте назовем это первый образ, «web_1».

C:\> docker stop
C:\> docker commit web_1

1 2	C\>docker stop C\>docker commit web_1

Теперь запустите контейнер снова и повторите предыдущие шаги, чтобы создать второй образ веб-службы, на этот раз используя файл index_2.html. Сделайте это, используя следующие команды:

C:\> docker start
C:\> docker cp index_2.html :C:\inetpub\wwwroot\index.html
C:\> docker stop
C:\> docker commit web_2

1
2
3
4

C\>docker start

C\>docker cp index_2.htmlC\inetpub\wwwroot\index.html

C\>docker stop

C\>docker commit web_2

Теперь вы создали образы для двух уникальных веб-сервисов; Если вы просматриваете образ Докера на вашем хосте, запустив , вы должны увидеть, что у вас есть два новых образа контейнера — «web_1» и «web_2».

Поместите образ контейнера IIS на все ваши хосты swarm

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

Вариант 1. Повторите описанные выше шаги, чтобы создать контейнеры «web_1» и «web_2» на втором узле.Вариант 2 : вставьте образ в ваш репозиторий в Docker Hub, затем подтяните их на дополнительные хосты.

Задержки, лимиты и таймауты

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

Изменить поведение лимитов и ограничений при балансировке можно с помощью опций:

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

Синтаксис:

server <имя сервера> max_fails=<число попыток> fail_timeout=<числовой показатель времени><еденица времени>;

В нашем примере мы преобразуем настройку так:

vi /etc/nginx/conf.d/upstreams.conf

upstream dmosk_backend {
server 192.168.10.10 weight=100 max_conns=1000;
server 192.168.10.11 weight=10 max_fails=2 fail_timeout=90s;
server 192.168.10.12 max_fails=3 fail_timeout=2m;
server 192.168.10.13 backup;
}

* в итоге:

сервер 192.168.10.10 будет принимать на себя, максимум, 1000 запросов.
сервер 192.168.10.10 будет иметь настройки по умолчанию.
если на сервер 192.168.10.11 будет отправлено 2-е неудачные попытки отправки запроса, то в течение 90 секунд на него не будут отправлять новые запросы.
сервер 192.168.10.12 будет недоступен в течение 2-х минут, если на него будут отправлены 3 неудачных запроса.

Шаг 6. Посмотрим на балансировщик нагрузки в действии

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

При доступе с хост-машины NGINX: Введите IP-адрес контейнера nginx, запущенного на машине, в адресную строку браузера. (Это значение выше).
При доступе с другого хоста (с сетевым доступом к хост-машине NGINX): Введите IP-адрес хоста NGINX в адресную строку браузера.

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

Теперь нажмите обновить страницу. Возможно, вам придется обновлять несколько раз, но после нескольких раз вы должны увидеть другую HTML-страницу, созданную на шаге 2.

Если вы продолжаете обновлять, вы увидите две разные HTML-страницы, которые вы использовали для определения служб, web_1 и web_2, доступ к которым осуществляется по круговой схеме (round-robin — это стратегия балансировки нагрузки по умолчанию для NGINX, но есть и другие ). Анимированное изображение ниже продемонстрировало поведение, которое вы должны увидеть.

Напоминаем, что ниже представлена полная конфигурация со всеми тремя узлами. Когда вы обновляете представление своей веб-страницы, вы повторно обращаетесь к узлу NGINX, который распределяет ваш запрос GET к конечным точкам контейнера, запущенным на узлах swarm. Каждый раз, когда вы повторно отправляете запрос, балансировщик нагрузки имеет возможность маршрутизировать вас к другой конечной точке, в результате чего ваш сайт будет обслуживаться на другой веб-странице в зависимости от того, был ли ваш запрос перенаправлен на конечную точку S1 или S2.

Модуль Upstream

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

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

В данный файл необходимо добавить конфигурации балансировки нагрузки.

Для начала внесите модуль upstream, что выглядит так:

Затем нужно сослаться на модуль в конфигурации:

server {
location / {
proxy_pass http://backend;
}
}

После этого перезапустите nginx:

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

Журналирование событий

Как уже говорилось, компонент «Балансировка нагрузки сети» записывает все
действия и изменения кластера в журнал событий Windows. Чтобы их увидеть,
выбираем «Просмотр событий – Система», к NLB относятся сообщения WLBS (от
Windows Load Balancing Service, как эта служба называлась в NT). Кроме того, в
окне диспетчера выводятся последние сообщения, содержащие информацию об ошибках
и обо всех изменениях в конфигурации. По умолчанию эта информация не
сохраняется. Чтобы она записывалась в файл, следует выбрать «Параметры –>
Параметры журнала», установить флажок «Включить ведение журнала» и указать имя
файла. Новый файл будет создан в подкаталоге твоей учетной записи в Documents
and Settings.

Для чего нужен кластер

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

Заключение

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

Спасибо за чтение!

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.