С помощью существующего протокола единого входа OpenID Connect 4 страница

Параметр reuseport дает NGINX указание создать индивидуальный

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

26 v Глава 2. Высокопроизводительная балансировка нагрузки

ентом и сервером. reuseport работает только на ядрах Linux 3.9 и выше, DragonFly BSD и FreeBSD 12 и выше.

2.4. Методы балансировки нагрузки

Задача

Циклический (round-robin) метод балансировки нагрузки не подхо- дит для вашего варианта использования, потому что у вас разные рабо- чие нагрузки или пулы серверов.

Решение

Используйте один из методов балансировки нагрузки NGINX, такой как наименьшее количество подключений, наименьшее время, общее хеширование, хеширование IP или случайный метод:

upstream backend { least_conn;

server backend.example.com; server backend1.example.com;

}

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

Обсуждение

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

2.4. Методы балансировки нагрузки v 27

Циклический алгоритм

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

Наименьшее количество подключений

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

Наименьшее время

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

Общее хеширование

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

28 v Глава 2. Высокопроизводительная балансировка нагрузки

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

Случайный метод

Данный метод используется, чтобы дать NGINX команду выбрать произвольный сервер из группы, учитывая вес сервера. Необяза- тельный параметр two [method] указывает NGINX случайным обра- зом выбрать два сервера, а затем использовать предоставленный метод балансировки нагрузки для распределения нагрузки между ними. По умолчанию используется least_conn, если two передается без метода. Имя директивы для случайной балансировки нагруз- ки – random.

Хеширование IP-адреса

Этот метод работает только для HTTP. Он использует значение IP-адреса клиента в качестве самого хеширования. Несколько отличаясь от использования удаленной переменной в общем хе- шировании, этот алгоритм использует первые три октета адреса IPv4 или весь адрес IPv6 целиком. Метод гарантирует, что клиен- ты выставляются посредником на один и тот же вышестоящий сервер, до тех пор пока этот сервер доступен, что очень полез- но, когда состояние сеанса имеет значение и не обрабатывается общей памятью приложения. Этот метод также учитывает па- раметр weight при распределении значения хеша. Имя директи- вы – ip_hash.

2.5. Директива sticky cookie

Задача

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

Решение

Используйте директиву sticky cookie, чтобы дать указание NGINX Plus

создать и отслеживать куки:

2.6. Директива sticky learn v 29

upstream backend {

server backend1.example.com; server backend2.example.com; sticky cookie

affinity expires=1h

domain=.example.com httponly

secure path=/;

}

В этой конфигурации мы создаем и отслеживаем куки, который свя- зывает нижестоящего клиента с вышестоящим сервером. В этом при- мере файл куки носит название affinity. Он устанавливается для exa- mple.com со сроком истечения один час, его нельзя использовать на стороне клиента, можно отправлять только по протоколу HTTPS, и он действителен для всех путей.

Обсуждение

При использовании параметра cookie в директиве sticky создается куки при первом запросе, который содержит информацию о вышесто- ящем сервере. NGINX Plus отслеживает этот куки-файл, позволяя ему и дальше направлять последующие запросы на тот же сервер. Первый позиционный параметр для параметра cookie – имя куки-файла, кото- рый мы создадим и будем отслеживать. Другие параметры предлагают дополнительный контроль, информируя браузер о соответствующем использовании, например о времени истечения, домене, пути и воз- можности использования куки на стороне клиента либо можно ли пе- редавать его по незащищенным протоколам.

2.6. Директива sticky learn

Задача

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

Решение

Используйте директиву sticky learn для обнаружения и отслеживания куки, которые создаются восходящим приложением:

30 v Глава 2. Высокопроизводительная балансировка нагрузки

upstream backend {

server backend1.example.com:8080; server backend2.example.com:8081;

sticky learn

create=$upstream_cookie_cookiename lookup=$cookie_cookiename zone=client_sessions:2m;

}

В этом примере NGINX дано указание искать и отслеживать сеансы пу- тем поиска куки с именем COOKIENAME в заголовках ответа и осуществлять поиск существующих сеансов путем поиска того же куки в заголовках запросов. Это сходство сеанса хранится в зоне общей памяти размером 2 Мб, которая может отслеживать около 16 000 сеансов. Имя куки всег- да будет зависеть от приложения. Обычно используемые имена, такие как jsessionid или phpsessionid, – как правило, значения по умолчанию, установленные в приложении или конфигурации сервера приложений.

Обсуждение

Когда приложения создают собственные куки состояния сеанса, NGINX Plus может обнаружить их в ответах на запросы и отслеживать их. Этот тип отслеживания куки выполняется, если директиве sticky предоставлен параметр learn. Общая память для отслеживания куки указывается при использовании параметра zone с именем и размером. NGINX Plus направлен на поиск куки в ответе, полученном от выше- стоящего сервера через спецификацию параметра create, и ищет ранее зарегистрированную привязку к серверу, используя параметр lookup. Значением этих параметров являются переменные, предоставляемые модулем HTTP.

2.7. Директива sticky route

Задача

Вам необходим детальный контроль над вашими постоянными сеан- сами к вышестоящему серверу с помощью NGINX Plus.

Решение

Используйте директиву sticky с параметром route, чтобы применить переменные относительно запроса на маршрут:

2.7. Директива sticky route v 31

map $cookie_jsessionid $route_cookie {

~.+\.(?P<route>\w+)$ $route;

}

map $request_uri $route_uri {

~jsessionid=.+\.(?P<route>\w+)$ $route;

}

upstream backend {

server backend1.example.com route=a; server backend2.example.com route=b;

sticky route $route_cookie $route_uri;

}

В этом примере вы пытаетесь извлечь идентификатор сеанса Java, сначала из куки устанавливая соответствие самого идентификатора сеанса Java некой переменной при помощи самого первого блока map, а затем путем поиска в URI запроса параметра с именем jsessionid, устанавливая соответствие полученного значения переменной при по- мощи второго блока map. Директива sticky с параметром route передает любое количество переменных. Первое ненулевое или непустое значе- ние берется для маршрута. Если используется файл jsessionid, запрос направляется на backend1; если используется параметр URI, запрос нап- равляется на backend2. Хотя этот пример основан на распространенном идентификаторе сеанса Java, то же самое применительно и к другой технологии сеанса, такой как phpsessionid, или любому гарантированно- му уникальному идентификатору, который ваше приложение генери- рует для идентификатора сеанса.

Обсуждение

Иногда вам может потребоваться направить трафик на конкретный сервер, располагая при этом более детальным контролем. Параметр route для директивы sticky создан для достижения этой цели. Sticky route обеспечивает более эффективный контроль, фактическое отслежива- ние и связываемость в отличие от алгоритма балансировки нагрузки с общим хешированием. Сначала клиент направляется в вышестоящий сервер на основе указанного маршрута, а затем последовательные зап- росы будут содержать информацию о маршрутизации в куки или URI. Sticky route принимает ряд позиционных параметров, которые оцени-

32 v Глава 2. Высокопроизводительная балансировка нагрузки

ваются. Первая непустая переменная используется для маршрутизации на сервер. Блоки map могут использоваться для выборочного анализа переменных и сохранения их в качестве других переменных, которые будут использоваться в маршрутизации. По сути, директива sticky route создает сеанс внутри зоны общей памяти NGINX Plus для отслеживания любого идентификатора сеанса клиента, указанного вами для выше- стоящего сервера, последовательно доставляя запросы с этим иденти- фикатором сеанса тому же вышестоящему серверу, что и его исходный запрос.

2.8. Осушение соединения

Задача

Вам необходимо аккуратно удалить серверы для обслуживания или по другим причинам, продолжая обслуживать сеансы с помощью NGINX Plus.

Решение

Используйте параметр drain через API NGINX Plus, подробно описан- ный в главе 5, чтобы NGINX прекратил отправлять новые подключения, которые еще не отслеживаются:

$ curl -X POST -d '{"drain":true}' \

' http://nginx.local/api/3/http/upstreams/backend/servers/0'

{

"id":0, "server":"172.17.0.3:80",

"weight":1, "max_conns":0, "max_fails":1, "fail_timeout": "10s","slow_start": "0s",

"route":"", "backup":false, "down":false, "drain":true

}

2.9. Пассивные проверки работоспособности v 33

Обсуждение

Когда состояние сеанса хранится локально на сервере, соединения и постоянные сеансы должны быть очищены перед его удалением из пула. Осушение соединений – это процесс, который позволяет естест- венным образом завершаться сеансам сервера по истечении времени, прежде чем удалять сам сервер из соответствующего пула восходящего потока. Можно настроить осушение для конкретного сервера, добавив параметр drain в директиву server. Когда задан параметр drain, NGINX Plus прекращает отправку новых сеансов на этот сервер, но позволяет текущим сеансам продолжать обслуживаться в течение продолжитель- ности их сеанса. Вы также можете переключить конфигурацию, добавив параметр drain в директиву вышестоящего сервера.

2.9.

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

Задача

Вам необходимо выполнить пассивную проверку работоспособности вышестоящих серверов.

Решение

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

upstream backend {

server backend1.example.com:1234 max_fails=3 fail_timeout=3s; server backend2.example.com:1234 max_fails=3 fail_timeout=3s;

}

В этой конфигурации мы пассивно отслеживаем работоспособность, устанавливая для директивы max_fails значение, равное трем, а для fail_ timeout – три секунды. Эти параметры директив работают одинаково и в потоковых, и HTTP-серверах.

Обсуждение

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

34 v Глава 2. Высокопроизводительная балансировка нагрузки

ны по умолчанию; упомянутые здесь параметры позволяют настроить их поведение. Мониторинг работоспособности важен для всех видов балансировки нагрузки, не только с точки зрения взаимодействия с пользователем, но и для обеспечения непрерывности бизнеса. NGINX выполняет пассивный мониторинг вышестоящих серверов HTTP, TCP и UDP, чтобы убедиться, что они работоспособны.

2.10. Активные проверки работоспособности

Задача

Вам необходимо выполнить активную проверку работоспособности ваших вышестоящих серверов с помощью NGINX Plus.

Дата добавления: 2021-01-21; просмотров: 135; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 1 2 345 6 7 8 9 10 Следующая ⇒

Мы поможем в написании ваших работ!