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

Thank you for reading this post, don't forget to subscribe!

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

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

Задача

Вам требуется распределить нагрузку между двумя или более серверами HTTP.

Решение

Для выполнения балансировки по серверам HTTP воспользуйтесь модулем HTTP NGINX применив блок upstream:

[codesyntax lang="php" blockstate="collapsed"]

upstream backend {
    server 10.10.12.45:80     weight=1;
    server app.example.com:80 weight=2;
}
server {
    location / {
        proxy_pass http://backend;
    }
}

upstream backend {

server 10.10.12.45:80 weight=1;

server app.example.com:80 weight=2;

}

server {

location / {

proxy_pass http://backend;

}

[/codesyntax]

Данная настройка выполняет балансировку нагрузки по двум серверам HTTP с портом 80. Значение параметра weight инструктирует NGIN о необходимости передавать в два раза больше подключений на второй сервер, причём значением по умолчанию для weight является 1.

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

Каждый получатель в восходящем потоке определяется в пуле восходящего потока соответствующей директивой server. Эта директива server предоставляет некий сокет Unix, IP адрес или какой- то FQDN, совместно с неким числом необязательных параметров. Данные необязательные параметры дают дополнительное управление имеющимися маршрутами или запросами. Эти параметры содержат значение веса соответствующего сервера в своём алгоритме балансировки; будет ли пребывать данные сервер в режиме ожидания (standby), доступным или не доступным; а также как определять что сервер недоступен. NGINX Plus определяет целый ряд прочих удобных параметров, таких как ограничение на подключение к данному серверу, расширенный контроль разрешения DNS, а также возможность медленного наращивания числа подключений к некому серверу после его запуска.

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

Задача

Вам требуется выполнить балансировку нагрузки между двумя или более серверами TCP.

Решение

Для балансировки нагрузки по серверам TCP воспользуйтесь модулем steam NGINX применив блок upstream:

[codesyntax lang="php" blockstate="collapsed"]

stream {
    upstream mysql_read {
        server read1.example.com:3306 weight=5;
        server read2.example.com:3306;
        server 10.10.12.34:3306 backup;
    }

    server {
        listen 3306;
        proxy_pass mysql_read;
    }
}

stream {

upstream mysql_read {

server read1.example.com:3306 weight=5;

server read2.example.com:3306;

server 10.10.12.34:3306 backup;

}

server {

listen 3306;

proxy_pass mysql_read;

}

[/codesyntax]

Соответствующий блок server в данном примере инструктирует NGINX выполнять ожидание по порту TCP 3306 и выполнять балансировку нагрузки между двумя репликами на чтение базы данных MySQL и приводит в списке другой в качестве резервной копии, в который будет передаваться обмен если указанные первичные будут остановлены. Эти настройки не будут добавляться в папку conf.d, поскольку эта папка вложена в http block; вместо этого вам следует создать иную папку с названием stream.conf.d, открыть блок stream в соответствующем файле nginx.conf и вложить эту новую папку для настройки stream.

Балансировка нагрузки TCP определяется соответствующим модулем NGINX stream. Этот модуль stream, как и обсуждавшийся модуль HTTP, позволяет вам определять пулы серверов восходящего потока и настраивать некий ожидающий сервер. При настройке некого сервера на ожидание (listen) определённого порта, вы должны определить то значение порта, по которому выполняется ожидание, или, что не обязательно, некий адрес и порт. Здесь может быть определён получатель, причём либо это будет обратный посредник (прокси) на другой адрес, либо некий восходящий пул ресурсов.

Такой восходящий поток для балансировки нагрузки TCP во многом аналогичен восходящему потоку для HTTP, в том что он определяет восходящие ресурсы как серверы, настраиваемые сокетами Unix, IP , либо полностью определённым именем домена (FQDN, fully qualified domain name), а также веса сервера, максимального числа подключений, решателей DNS, и периодов вывода в рабочий режим; а также того, активен ли сервер, отключён ли, либо пребывает в режиме резервной копии.

NGINX Plus предлагает для балансировки нагрузки TCP даже дополнительные свойства. Такие предлагаемые NGINX Plus расширенные свойства могут быть представлены на протяжении данной книги. Проверки жизнеспособности для всех балансировок нагрузки будут обсуждены в этой главе позднее.

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

Задача

Вам требуется распределить балансировку нагрузки между двумя или более серверами UDP.

Решение

Для балансировки нагрузки по серверам UDP воспользуйтесь модулем steam NGINX применив блок upstream, определяемый как udp:

[codesyntax lang="php" blockstate="collapsed"]

stream {
    upstream ntp {
        server ntp1.example.com:123 weight=2;
        server ntp2.example.com:123;
    }

    server {
        listen 123 udp;
        proxy_pass ntp;
    }
}

stream {

upstream ntp {

server ntp1.example.com:123 weight=2;

server ntp2.example.com:123;

}

server {

listen 123 udp;

proxy_pass ntp;

}

[/codesyntax]

Этот раздел настраивает балансировку нагрузки между двумя серверами NTP (Network Time Protocol) восходящего потока, которые применяют протокол UDP. Определение балансировки нагрузки UDP является примером использования параметра udp в соответствующей директиве listen.

Если соответствующая служба поверх вашей балансировки нагрузки требует обратной отправки множества пакетов и далее между клиентом и сервером, вы можете определить соответствующий параметр reuseport. Примерами такого типа служб являются OpenVPN, Voice over Internet Protocol (VoIP), решения виртуальных рабочих мест и DTLS (Datagram Transport Layer Security). Ниже приводится пример использования NGINX для обработки соединений Open VPN и их посредничества (прокси) для запущенной локально службы Open VPN:

[codesyntax lang="php" blockstate="collapsed"]

stream {
    server {
        listen 1195 udp reuseport;
        proxy_pass 127.0.0.1:1194;
    }
}

stream {

server {

listen 1195 udp reuseport;

proxy_pass 127.0.0.1:1194;

}

[/codesyntax]

Вы можете спросить, "Зачем мне применять некую балансировку нагрузки, когда я могу иметь в записи DNS A или SRV множества хостов?" Ответ состоит в том, что это не просто альтернативные алгоритмы балансировки, которыми мы можем осуществлять балансировку, но мы также можем выполнять балансировку и поверх самих серверов DNS. Службы UDP составляют множество тех служб, от которых мы зависим в сетевых системах, таких как DNS, NTP и VoIP. Балансировка нагрузки UDP может быть не распространена для некоторых из них, но просто полезна в общем мире масштабирования.

В точности так же как это имеет место и для TCP, вы можете обнаружить балансировку нагрузки UDP в модуле stream, причём в целом она настраивается так же. Основное отличие состоит в том, что соответствующая директива listen определяет что её сокет открыт для работы с дейтаграммами. При работе с дейтаграммами имеются некие иные директивы, которые могут применяться когда они не укладываются в TCP, такие как директива proxy_response, которая задаёт для NGINX сколько ожидаемых откликов может быть отправлено от её сервера восходящего потока. По умолчанию оно не ограничено до тех пор пока не достигается предел proxy_timeout.

Устанавливаемый параметр reuseport инструктирует NGINX о необходимости создания некого индивидуального порта ожидания для каждого процесса исполнителя. Это делает возможным для имеющегося ядра распределять входящие подключения между процессами исполнителей для обработки множества пакетов, отправляемых между клиентом и сервером. Данная функциональность reuseport работает только в ядрах Linux 3.9 и выше, DragonFly BSD, а также FreeBSD 12 и выше.

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

Задача

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

Решение

Воспользуйтесь одним из таких методов балансировки нагрузки NGINX как методов наименьших подключений (least connections), наименьшего времени (least time), общего хэширования (generic hash), хэширования IP (IP hash), или случайного (random):

[codesyntax lang="php" blockstate="collapsed"]

upstream backend {
    least_conn;
    server backend.example.com;
    server backend1.example.com;
}

upstream backend {

least_conn;

server backend.example.com;

server backend1.example.com;

}

[/codesyntax]

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

Не все обслуживания запросов или пакетов несут равные веса. Исходя из этого, карусельный метод, или даже взвешенный карусельный метод, применявшийся в предыдущих примерах, не будут соответствовать всем приложения или потокам обмена. Дополнительно к возможности выбора таких алгоритмов или методов балансировки нагрузки вы также можете и настраивать их. Для пулов восходящих потоков HTTP, TCP и UDP доступны следующие методы балансировки нагрузки:

Карусельный: Это устанавливаемый по умолчанию метод балансировки нагрузки, который распределяет запросы в порядке своего списка серверов в соответствующем восходящем пуле. Для некого взвешенного карусельного метода вы также можете принимать во внимание вес, который может применяться когда разнятся ёмкости соответствующих серверов восходящего потока. Чем больше целочисленное значение для такого веса, тем более предпочтителен будет этот сервер в данном карусельном методе. Соответствующий алгоритм, стоящий за весом это просто статистическая вероятность некого взвешенного среднего.
Наименьшее подключение: Данный метод балансирует нагрузку выступая посредником для текущего запроса к тому серверу восходящего потока, который имеет наименьшее число открытых подключений. Метод наименьших подключений, так же как и карусельный, принимает во внимание веса при определении того в какой из серверов отправлять данное подключение. Эта директива имеет название least_conn.
Наименьшее время: Доступный только в NGINX PLUS, метод наименьшего времени является родственным методу наименьших подключений в том, что он выступает посредником для того сервера, у которого наименьшее число подключений, но при этом предпочтение отдаётся серверу с наименьшим значением среднего времени обработки запросов. Данный метод один из самых искушённых алгоритмов балансировки нагрузки и соответствует потребностям веб приложений с высокой производительностью. Данный алгоритм дополнительно оценивает наименьшее время соединения, поскольку некое меньшее число подключений не обязательно означает самый быстрый отклик. Для данной директивы необходимо определять параметр header или last_byte. Когда определён header, используется время на получения отклика от заголовка. Когда определён last_byte, применяется значение времени для получения полного отклика. Названием этой директивы является least_time.
Общее хэширование: Сам администратор определяет некий хэш для заданного текста, переменных запроса или времени исполнения, либо и того и другого. NGINX распределяет имеющуюся нагрузку по всем серверам предоставляя некий хэш для значения текущего запроса и размещая его в серверах восходящего потока. Данный метод очень полезен когда вам требуется больше контроля над тем куда отправляются запросы или для определения того какой из серверов восходящего потока будет скорее всего кэшировать эти данные. Обратите внимание, что при добавлении или удалении сервера из пула хэшированные запросы будут перераспределяться. Этот алгоритм имеет некий необязательный параметр, consistent, для минимизации эффекта перераспределения. Эта директива имеет название hash.
Случайное: Этот метод применяется чтобы предписать NGINX для выбора случайным образом сервера из определённой группы, принимая во внимание веса серверов. Не обязательный параметр two [method] указывает NGINX на необходимость случайным образом выбирать два сервера, а затем применять предоставляемый им метод балансировки нагрузки для балансирования между этими двумя. Если two передаётся без какого бы то ни было метода, по умолчанию применяется least_conn. Значением имени для случайной балансировки нагрузки является random.
Хэширование IP: Этот метод работает только для HTTP. Хэш IP применяет значение адреса IP клиента в качестве самого хеширования. Слегка отличаясь от применения соответствующей удалённой переменной в неком общем хэшировании, данный алгоритм использует первые три октета некого IPv4 адреса либо весь адрес IPv6 целиком. Этот метод гарантирует что клиенты выставляются посредником на один и тот же сервер восходящего потока пока доступен этот самый сервер, что очень полезно в том случае, когда имеет значение состояние сеанса и оно не обрабатывается общей памятью данного приложения. Этот метод также учитывает значение параметра weight при распределении значения хэша. Именем директивы является ip_hash.

Клейкие куки

Задача

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

Решение

Воспользуйтесь директивой sticky cookie (клейких куки) NGINX Plus для создания и отслеживания куки:

[codesyntax lang="php" blockstate="collapsed"]

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    sticky cookie
        affinity
        expires=1h
        domain=.example.com
        httponly
        secure
        path=/;
}

upstream backend {

server backend1.example.com;

server backend2.example.com;

sticky cookie

affinity

expires=1h

domain=.example.com

httponly

secure

path=/;

}

[/codesyntax]

Данная конфигурация создаёт и отслеживает некий куки, который связывает подлежащего клиента с сервером верхнего уровня. В данном примере этот куки, именуемый как affinity, устанавливается для example.com, со сроком истечения действия в один час, причём не может потребляться стороной клиента, может отправляться исключительно через HTTPS и действует для всех путей.

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

Обучения наклейкам NGINX Plus

Задача

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

Решение

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

[codesyntax lang="php" blockstate="collapsed"]

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;
}

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;

}

[/codesyntax]

Данный пример инструктирует NGINX отыскивать и отслеживать сеансы, просматривая куки с именем COOKIENAME в заголовках отклика, и определять существующие сеансы находя тот же самый куки в заголовках запросов. Такое родство (affinity) сеаснов хранится в разделяемой зоне памяти в 2 МБ, что позволяет отслеживать приблизительно 16 000 сеансов. Само название куки всегда будет определяться приложением. Внутри соответствующего приложения или настроек сервера приложения обычно применяются названия, подобные jsessionid или phpsessionid.

Когда некое приложение создаёт свой собственный куки состояния сеанса, NGINX Plus способен отыскивать его в откликах запросов и отслеживать их. Такой тип отслеживания куки осуществляется когда сама директива sticky снабжается соответствующим параметром learn. Совместная память для отслеживания куки определяется значением параметра zone с неким названием и размером. NGINX Plus направляет поиск куки в соответствующем отклике от своего сервера верхнего уровня через определение надлежащего параметра create и отыскивает предварительно зарегистрированное родство сервера при помощи значения параметра lookup. Сами значения таких параметров являются выставляемыми модулем HTTP переменными.

Наклейки маршрутов

Задача

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

Решение

Для применения переменных относительно необходимого запроса на маршрут воспользуйтесь директивой sticky с соответствующим параметром route:

[codesyntax lang="php" blockstate="collapsed"]

map $cookie_jsessionid $route_cookie {
    ~.+\.(?P&lt;route&gt;\w+)$ $route;
}
map $request_uri $route_uri {
    ~jsessionid=.+\.(?P&lt;route&gt;\w+)$ $route;
}

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky route $route_cookie $route_uri;
}

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;

}

[/codesyntax]

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

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

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

Задача

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

Решение

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

[codesyntax lang="php" blockstate="collapsed"]

$ 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
}

$ 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

}

[/codesyntax]

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

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

Задача

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

Решение

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

[codesyntax lang="php" blockstate="collapsed"]

upstream backend {
    server backend1.example.com:1234 max_fails=3 fail_timeout=3s;
    server backend2.example.com:1234 max_fails=3 fail_timeout=3s;
}

upstream backend {

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

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

}

[/codesyntax]

Данная настрока осуществляет пассивный мониторинг жизнеспособности своего восходящего потока, назначая значение max_fails директивы в три, а fail_timeout на три секунды. Данные параметры директивы работают одним и тем же способом как для серверов потоков, так и для серверов HTTP.

Обсуждение

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

Активные проверки жизнеспособности NGINX Plus

Задача

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

Решение

Для HTTP воспользуйтесь в блоке местоположения директивой health_check:

[codesyntax lang="php" blockstate="collapsed"]

http {
    server {
        ...
        location / {
            proxy_pass http://backend;
            health_check interval=2s
                fails=2
                passes=5
                uri=/
                match=welcome;
        }
    }
    # status is 200, content type is "text/html",
    # and body contains "Welcome to nginx!"
    match welcome {
        status 200;
        header Content-Type = text/html;
        body ~ "Welcome to nginx!";
    }
}

http {

server {

...

location / {

proxy_pass http://backend;

health_check interval=2s

fails=2

passes=5

uri=/

match=welcome;

}

# status is 200, content type is "text/html",

# and body contains "Welcome to nginx!"

match welcome {

status 200;

header Content-Type = text/html;

body ~ "Welcome to nginx!";

}

[/codesyntax]

Данная проверка жизнеспособности для серверов HTTP контролирует состояние жизнеспособности имеющихся серверов восходящего потока выполняя каждые две секунды некий запрос HTTP к URI'/'. Чтобы рассматриваться жизнеспособными, соответствующие серверы восходящего потока должны пройти пять последовательных проверок жизнеспособности. Они рассматриваются как не жизнеспособные когда отказывают две последовательные проверки. Соответствующий отклик от такого сервера верхнего уровня должен соответствовать тому определяемому блоку соответствия, который задаёт значение кода состояния равным 200, а значение заголовка Content-Type как 'text/html' и строку "Welcome to nginx!" в качестве значения тела отклика. Сам HTTP match block имеет три директивы: состояния, заголовка и тела. Все эти три директивы также имеют флаги сравнения.

Проверки для служб TCP/UDP очень похожи:

[codesyntax lang="php" blockstate="collapsed"]

stream {
    ...
    server {
        listen 1234;
        proxy_pass stream_backend;
        health_check interval=10s
            passes=2
            fails=3;
        health_check_timeout 5s;
    }
    ...
}

stream {

...

server {

listen 1234;

proxy_pass stream_backend;

health_check interval=10s

passes=2

fails=3;

health_check_timeout 5s;

}

...

}

[/codesyntax]

В данном примере некий сервер TCP настроен на ожидание по порту 1234 и для выполнения посредничества к некому набору серверов восходящего потока, для которого он и выполняет активные проверки жизнеспособности. Соответствующая директива health_check получает все те же параметры, что и HTTP, за исключением uri, а значение версии потока имеет параметр для переключения проткола проверки на udp. В данном примере значение интервала установлено на 10 секунд, требуются два прохода для того чтобы он рассматривался как жизнеспособный и три отказа чтобы принмать его не жизнеспособным. Такая активная проверка потока также способна удостоверять получаемый отклик от своего сервера верхнего уровня. Тем не менее, соответствующий блок match для серверов потока имеет только два параметра: send и expect. Значением директивы send являются подлежащие отправке сырые данные, в то время как expect представляет собой точный отклик или некое регулярное выражение для проверки соответствия.

Активные проверки жизнеспособности NGINX Plus непрерывно выполняют запросы к соответствующим серверам источников для контроля их жизнеспособности. Такие проверки жизнеспособности способны проверять не только значение кода отклика. В NGINX Plus активные проверки жизнеспособности HTTP осуществляют мониторинг на основе некого числа приемлемых критериев соответствующего отклика от самого сервера верхнего уровня. Вы можете настраивать мониторинг активных проверок жизнеспособности на то насколько часто проверяются серверы восходящего потока, сколько раз сервер обязан пройти такую проверку чтобы рассматривать его жизнеспособным, сколько раз он может отказывать прежде чем будет рассматриваться как не жизнеспособный и что следует рассматривать значением ожидаемого результата. Значение параметра match указывает на некий блок соответствия, который определяет значение приемлемого критерия для получаемого отклика. Значение блока соответствия также определяет те данные, которые отправляются в опрашиваемый сервер верхнего уровня при использовании значения контекста потока для TCP/ UDP. Эти свойства позволяют NGINX гарантировать жизнеспособность серверов восходящего потока на протяжении всего времени.

Медленный запуск

Задача

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

Решение

Для постепенного увеличения общего числа подключений со временем после того как некий сервер был представлен в своём пуле восходящей балансировки нагрузки, воспользуйтесь параметром slow_start в соответствующей директиве server:

[codesyntax lang="php" blockstate="collapsed"]

upstream {
    zone backend 64k;

    server server1.example.com slow_start=20s;
    server server2.example.com slow_start=15s;
}

upstream {

zone backend 64k;

server server1.example.com slow_start=20s;

server server2.example.com slow_start=15s;

}

[/codesyntax]

Данная настройка директивы server будет замедленно прогревать обмен к серверам восходящего потока после их представления в данном пуле. server1 будет медленно наращивать своё число подключений на протяжении 20 секунд, а server2 в течении 15 секунд.

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

Проверки жизнеспособности TCP

Задача

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

Решение

Для некой активной проверки воспользуйтесь директивой health_check в надлежащем блоке server:

[codesyntax lang="php" blockstate="collapsed"]

stream {
    server {
        listen       3306;
        proxy_pass   read_backend;
        health_check interval=10 passes=2 fails=3;
    }
}

stream {

server {

listen 3306;

proxy_pass read_backend;

health_check interval=10 passes=2 fails=3;

}

[/codesyntax]

Данный пример выполняет активный мониторинг серверов своего восходящего потока. Подлежащий отслеживанию сервер восходящего потока рассматривается как не жизнеспособный если он отказывает в отклике для трёх или более инициированных NGINX подключений TCP. NGINX выполняет данную проверку каждые 10 секунд. Определённый сервер будет рассматриваться как жизнеспособный только после прохода двух проверок на жизнеспособность.

Проверка жизнеспособности TCP может подтверждаться со стороны NGINX Plus пассивно или активно. Пассивный мониторинг жизнеспособности осуществляется путём регистрации взаимодействия между имеющимся клиентом и его сервером верхнего уровня. Когда такой сервер восходящего потока приводит к тайм- ауту или отклоняет подключения, пассивная проверка жизнеспособности будет считать такой сервер не жизнеспособным. Активные проверки жизнеспособности будут инициировать свои собственные настраиваемые проверки для определения жизнеспособности. Активные проверки жизнеспособности не только контролируют некое подключение к своему серверу восходящего потока, но также могут ожидать некий заданный отклик.

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Centos

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

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

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

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

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

Клейкие куки

Обучения наклейкам NGINX Plus

Наклейки маршрутов

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

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

Активные проверки жизнеспособности NGINX Plus

Медленный запуск

Проверки жизнеспособности TCP

https://github.com/midnight47/