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

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

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

Также является важным то, что обслуживание приложения NGINX является жизнеспособным. По целому ряду причин приложения падают. Это может происходить по причине сетевой связи, отказов сервера, либо отказов приложения, причём мы перечислили только часть причин. Посредники (прокси) и балансировщики нагрузки должны обладать достаточным интеллектом чтобы чтобы выявлять отказы в восходящих к серверам потоках и прекращать передачу обмена к ним; в противном случае такой клиент будет пребывать в состоянии ожидания, получая лишь сообщения о таймауте. Неким способом снижения деградации службы при отказе какого- то сервера является наличие соответствующей проверки со стороны посредника жизнеспособности серверов восходящего потока. NGINX предлагает два различных способа проверки жизнеспособности: пассивной, доступной в версии с открытым исходным кодом, и активной, доступной только в NGINX Plus. Активные проверки жизнеспособности через регулярные промежутки времени будут выполнять подключение или запрос к имеющемуся серверу восходящего потока и могут получать подтверждение того что такой запрос верный. Пассивные проверки жизнеспособности выполняют мониторинг имеющегося подключения к восходящему серверу или отклика от него только по мерер того как клиенты выполняют такие запросы или подключения. Вы можете пожелать использовать пассивные проверки жизнеспособности для снижения нагрузки на свои серверы восходящего потока, но вы также можете пожелать применять активные проверки жизнеспособности для выявления отказа некого сервера восходящего потока прежде чем получит отказ обслуживаемый им клиент. Завершающая часть данной главы изучает мониторинг прикладных серверов восходящего потока для которых вы и выполняете балансировку нагрузки.

Задача

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

Решение

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

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

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

Обсуждение

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

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

Задача

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

Решение

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

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

Соответствующий блок 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 воспользуйтесь модулем steam NGINX применив блок upstream, определяемый как udp:

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

    server {
        listen 123 udp;
        proxy_pass ntp;
    }
}
 	   

Этот раздел настраивает балансировку нагрузки между двумя серверами 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:

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

Обсуждение

Вы можете спросить, "Зачем мне применять некую балансировку нагрузки, когда я могу иметь в записи 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):

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

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

Обсуждение

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

Задача

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

Решение

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

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

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

Обсуждение

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

Задача

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

Решение

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

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 в заголовках отклика, и определять существующие сеансы находя тот же самый куки в заголовках запросов. Такое родство (affinity) сеаснов хранится в разделяемой зоне памяти в 2 МБ, что позволяет отслеживать приблизительно 16 000 сеансов. Само название куки всегда будет определяться приложением. Внутри соответствующего приложения или настроек сервера приложения обычно применяются названия, подобные jsessionid или phpsessionid.

Обсуждение

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

Задача

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

Решение

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

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

Задача

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

Решение

Через API NGINX Plus воспользуйтесь параметром drain, который более подробно описывается в Главе 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
}
		

Обсуждение

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

Задача

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

Решение

Воспользуйтесь проверками жизнеспособности 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 в качестве запросов некого клиента. Пассивные проверки жизнеспособности включены по умолчанию; упомянутые здесь параметры позволяют вам подстраивать их поведение. Мониторинг жизнеспособности важен во всех типах балансировки нагрузок, причём не только с точки зрения взаимодействия пользователя, но также и для обеспечения непрерывности бизнеса. NGINX выполняет пассивный мониторинг серверов HTTP, TCP и UDP восходящего потока чтобы гарантировать их жизнеспособность и работу.

Задача

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

Решение

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

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

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

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

В данном примере некий сервер 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:

upstream {
    zone backend 64k;

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

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

Обсуждение

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

Задача

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

Решение

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

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

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

Обсуждение

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