<?xml version="1.0"?>

<!--
  Copyright (C) Igor Sysoev
  Copyright (C) Nginx, Inc.
  -->

<!DOCTYPE module SYSTEM "../../../../dtd/module.dtd">

<module name="Модуль ngx_http_upstream_module"
        link="/ru/docs/http/ngx_http_upstream_module.html"
        lang="ru"
        rev="89">

<section id="summary">

<para>
Модуль <literal>ngx_http_upstream_module</literal>
позволяет описывать группы серверов,
которые могут использоваться в директивах
<link doc="ngx_http_proxy_module.xml" id="proxy_pass"/>,
<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_pass"/>,
<link doc="ngx_http_uwsgi_module.xml" id="uwsgi_pass"/>,
<link doc="ngx_http_scgi_module.xml" id="scgi_pass"/>,
<link doc="ngx_http_memcached_module.xml" id="memcached_pass"/> и
<link doc="ngx_http_grpc_module.xml" id="grpc_pass"/>.
</para>

</section>


<section id="example" name="Пример конфигурации">

<para>
<example>
upstream <emphasis>backend</emphasis> {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://<emphasis>backend</emphasis>;
    }
}
</example>
</para>

</section>


<section id="directives" name="Директивы">

<directive name="upstream">
<syntax block="yes"><value>название</value></syntax>
<default/>
<context>http</context>

<para>
Описывает группу серверов.
Серверы могут слушать на разных портах.
Кроме того, можно одновременно использовать серверы,
слушающие на TCP- и UNIX-сокетах.
</para>

<para>
Пример:
<example>
upstream backend {
    server backend1.example.com weight=5;
    server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend3;

    server backup1.example.com  backup;
}
</example>
</para>

<para>
По умолчанию запросы распределяются по серверам циклически
(в режиме round-robin) с учётом весов серверов.
В вышеприведённом примере каждые 7 запросов будут распределены так:
5 запросов на <literal>backend1.example.com</literal>
и по одному запросу на второй и третий серверы.
Если при попытке работы с сервером происходит ошибка, то запрос
передаётся следующему серверу, и так далее до тех пор, пока не будут опробованы
все работающие серверы.
Если не удастся получить успешный ответ
ни от одного из серверов, то клиенту будет возвращён результат работы
с последним сервером.
</para>

</directive>


<directive name="server">
<syntax><value>адрес</value> [<value>параметры</value>]</syntax>
<default/>
<context>upstream</context>

<para>
Задаёт <value>адрес</value> и другие <value>параметры</value>
сервера.
Адрес может быть указан в виде доменного имени или IP-адреса,
и необязательного порта, или в виде пути UNIX-сокета, который
указывается после префикса “<literal>unix:</literal>”.
Если порт не указан, используется порт 80.
Доменное имя, которому соответствует несколько IP-адресов,
задаёт сразу несколько серверов.
</para>

<para>
Могут быть заданы следующие параметры:
<list type="tag">

<tag-name id="weight">
<literal>weight</literal>=<value>число</value>
</tag-name>
<tag-desc>
задаёт вес сервера, по умолчанию 1.
</tag-desc>

<tag-name id="max_conns">
<literal>max_conns</literal>=<value>число</value>
</tag-name>
<tag-desc>
ограничивает максимальное <value>число</value> одновременных активных
соединений к проксируемому серверу (1.11.5).
Значение по умолчанию равно 0 и означает, что ограничения нет.
Если группа не находится в <link id="zone">зоне разделяемой памяти</link>,
то ограничение работает отдельно для каждого рабочего процесса.
<note>
При включённых <link id="keepalive">неактивных постоянных</link> соединениях,
нескольких
<link doc="../ngx_core_module.xml" id="worker_processes">рабочих процессах</link>
и <link id="zone">зоне разделяемой памяти</link>,
суммарное число активных и неактивных соединений с проксируемым сервером
может превышать значение <literal>max_conns</literal>.
</note>
</tag-desc>

<tag-name id="max_fails">
<literal>max_fails</literal>=<value>число</value>
</tag-name>
<tag-desc>
задаёт число неудачных попыток работы с сервером, которые должны произойти
в течение времени, заданного параметром <literal>fail_timeout</literal>,
чтобы сервер считался недоступным на период времени, также заданный
параметром <literal>fail_timeout</literal>.
По умолчанию число попыток устанавливается равным 1.
Нулевое значение отключает учёт попыток.
Что считается неудачной попыткой, определяется директивами
<link doc="ngx_http_proxy_module.xml" id="proxy_next_upstream"/>,
<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_next_upstream"/>,
<link doc="ngx_http_uwsgi_module.xml" id="uwsgi_next_upstream"/>,
<link doc="ngx_http_scgi_module.xml" id="scgi_next_upstream"/>,
<link doc="ngx_http_memcached_module.xml" id="memcached_next_upstream"/> и
<link doc="ngx_http_grpc_module.xml" id="grpc_next_upstream"/>.
</tag-desc>

<tag-name id="fail_timeout">
<literal>fail_timeout</literal>=<value>время</value>
</tag-name>
<tag-desc>
задаёт
<list type="bullet">

<listitem>
время, в течение которого должно произойти заданное число неудачных
попыток работы с сервером для того, чтобы сервер считался недоступным;
</listitem>

<listitem>
и время, в течение которого сервер будет считаться недоступным.
</listitem>

</list>
По умолчанию параметр равен 10 секундам.
</tag-desc>

<tag-name id="backup">
<literal>backup</literal>
</tag-name>
<tag-desc>
помечает сервер как запасной сервер.
На него будут передаваться запросы в случае, если не работают основные серверы.
<note>
Параметр нельзя использовать совместно с
методами балансировки нагрузки
<link id="hash"/>, <link id="ip_hash"/> и <link id="random"/>.
</note>
</tag-desc>

<tag-name id="down">
<literal>down</literal>
</tag-name>
<tag-desc>
помечает сервер как постоянно недоступный.
</tag-desc>

</list>
</para>

<para>
<note>
Если в группе только один сервер,
параметры <literal>max_fails</literal> и <literal>fail_timeout</literal>
игнорируются и такой сервер никогда не будет считаться недоступным.
</note>
</para>

</directive>


<directive name="zone">
<syntax><value>имя</value> [<value>размер</value>]</syntax>
<default/>
<context>upstream</context>
<appeared-in>1.9.0</appeared-in>

<para>
Задаёт <value>имя</value> и <value>размер</value> зоны разделяемой памяти,
в которой хранятся конфигурация группы и её рабочее состояние,
разделяемые между рабочими процессами.
В одной и той же зоне могут быть сразу несколько групп.
В этом случае достаточно указать <value>размер</value> только один раз.
</para>

</directive>


<directive name="hash">
<syntax><value>ключ</value> [<literal>consistent</literal>]</syntax>
<default/>
<context>upstream</context>
<appeared-in>1.7.2</appeared-in>

<para>
Задаёт метод балансировки нагрузки для группы, при котором
соответствие клиента серверу определяется при помощи
хэшированного значения <value>ключа</value>.
В качестве <value>ключа</value> может использоваться
текст, переменные и их комбинации.
Следует отметить, что любое добавление или удаление серверов в группе
может привести к перераспределению большинства ключей на другие серверы.
Метод совместим с библиотекой Perl
<link url="https://metacpan.org/pod/Cache::Memcached">Cache::Memcached</link>.
</para>

<para>
Если задан параметр <literal>consistent</literal>, то вместо
вышеописанного метода будет использоваться метод консистентного хэширования
<link url="https://www.metabrew.com/article/libketama-consistent-hashing-algo-memcached-clients">ketama</link>.
Метод гарантирует, что при добавлении сервера в группу или его удалении
на другие серверы будет перераспределено минимальное число ключей.
Применение метода для кэширующих серверов обеспечивает
больший процент попаданий в кэш.
Метод совместим с библиотекой Perl
<link url="https://metacpan.org/pod/Cache::Memcached::Fast">Cache::Memcached::Fast</link>
при значении параметра <value>ketama_points</value> равным 160.
</para>

</directive>


<directive name="ip_hash">
<syntax/>
<default/>
<context>upstream</context>

<para>
Задаёт для группы метод балансировки нагрузки, при котором запросы
распределяются по серверам на основе IP-адресов клиентов.
В качестве ключа для хэширования используются первые три
октета IPv4-адреса клиента или IPv6-адрес клиента целиком.
Метод гарантирует, что запросы одного и того же клиента
будут всегда передаваться на один и тот же сервер.
Если же этот сервер будет считаться недоступным,
то запросы этого клиента будут передаваться на другой сервер.
С большой долей вероятности это также будет один и тот же сервер.
<note>
IPv6-адреса поддерживаются начиная с версий 1.3.2 и 1.2.2.
</note>
</para>

<para>
Если один из серверов нужно убрать на некоторое время, то для сохранения
текущего хэширования IP-адресов клиентов этот сервер нужно пометить
параметром <literal>down</literal>.
</para>

<para>
Пример:
<example>
upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com <emphasis>down</emphasis>;
    server backend4.example.com;
}
</example>
</para>

<para>
<note>
До версий 1.3.1 и 1.2.2 для серверов, использующих метод балансировки нагрузки
<literal>ip_hash</literal>, нельзя было задать вес.
</note>
</para>

</directive>


<directive name="keepalive">
<syntax><value>соединения</value></syntax>
<default/>
<context>upstream</context>
<appeared-in>1.1.4</appeared-in>

<para>
Задействует кэш соединений для группы серверов.
</para>

<para>
Параметр <value>соединения</value> устанавливает максимальное число
неактивных постоянных соединений с серверами группы, которые будут
сохраняться в кэше каждого рабочего процесса.
При превышении этого числа наиболее давно не используемые соединения
закрываются.
<note>
Следует особо отметить, что директива <literal>keepalive</literal>
не ограничивает общее число соединений с серверами группы, которые
рабочие процессы nginx могут открыть.
Параметр <value>соединения</value> следует устанавливать достаточно
консервативно, чтобы серверы группы по-прежнему могли обрабатывать
новые входящие соединения.
</note>

<note>
При использовании методов балансировки нагрузки, отличных
от стандартного round-robin, следует активировать их до
директивы <literal>keepalive</literal>.
</note>
</para>

<para>
Пример конфигурации группы серверов memcached с постоянными соединениями:
<example>
upstream memcached_backend {
    server 127.0.0.1:11211;
    server 10.0.0.2:11211;

    keepalive 32;
}

server {
    ...

    location /memcached/ {
        set $memcached_key $uri;
        memcached_pass memcached_backend;
    }

}
</example>
</para>

<para>
Для HTTP директиву
<link doc="ngx_http_proxy_module.xml" id="proxy_http_version"/>
следует установить в “<literal>1.1</literal>”,
а поле заголовка <header>Connection</header> — очистить:
<example>
upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

server {
    ...

    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}
</example>
</para>

<para>
<note>
Хоть это и не рекомендуется, но также возможно использование постоянных
соединений с HTTP/1.0, путём передачи поля заголовка
<header>Connection: Keep-Alive</header> серверу группы.
</note>
</para>

<para>
Для работы постоянных соединений с FastCGI-серверами потребуется
включить директиву
<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_keep_conn"/>:
<example>
upstream fastcgi_backend {
    server 127.0.0.1:9000;

    keepalive 8;
}

server {
    ...

    location /fastcgi/ {
        fastcgi_pass fastcgi_backend;
        fastcgi_keep_conn on;
        ...
    }
}
</example>
</para>

<para>
<note>
Протоколы SCGI и uwsgi не определяют семантику постоянных соединений.
</note>
</para>

</directive>


<directive name="keepalive_requests">
<syntax><value>число</value></syntax>
<default>1000</default>
<context>upstream</context>
<appeared-in>1.15.3</appeared-in>

<para>
Задаёт максимальное число запросов, которые можно
сделать по одному постоянному соединению.
После того как сделано максимальное число запросов,
соединение закрывается.
</para>

<para>
Периодическое закрытие соединений необходимо для освобождения
памяти, выделенной под конкретные соединения.
Поэтому использование слишком большого максимального числа запросов
может приводить к чрезмерному потреблению памяти и не рекомендуется.
</para>

<para>
<note>
До версии 1.19.10 по умолчанию использовалось значение 100.
</note>
</para>

</directive>


<directive name="keepalive_time">
<syntax><value>время</value></syntax>
<default>1h</default>
<context>upstream</context>
<appeared-in>1.19.10</appeared-in>

<para>
Ограничивает максимальное время, в течение которого
могут обрабатываться запросы в рамках постоянного соединения.
По достижении заданного времени соединение закрывается
после обработки очередного запроса.
</para>

</directive>


<directive name="keepalive_timeout">
<syntax><value>таймаут</value></syntax>
<default>60s</default>
<context>upstream</context>
<appeared-in>1.15.3</appeared-in>

<para>
Задаёт таймаут, в течение которого неактивное постоянное
соединение с сервером группы не будет закрыто.
</para>

</directive>


<directive name="least_conn">
<syntax/>
<default/>
<context>upstream</context>
<appeared-in>1.3.1</appeared-in>
<appeared-in>1.2.2</appeared-in>

<para>
Задаёт для группы метод балансировки нагрузки, при котором запрос
передаётся серверу с наименьшим числом активных соединений,
с учётом весов серверов.
Если подходит сразу несколько серверов, они выбираются циклически
(в режиме round-robin) с учётом их весов.
</para>

</directive>


<directive name="random">
<syntax>[<literal>two</literal> [<value>метод</value>]]</syntax>
<default/>
<context>upstream</context>
<appeared-in>1.15.1</appeared-in>

<para>
Задаёт для группы метод балансировки нагрузки, при котором запрос
передаётся случайно выбранному серверу, с учётом весов
серверов.
</para>

<para>
Если указан необязательный параметр <literal>two</literal>,
то nginx случайным образом выбирает
<link url="https://homes.cs.washington.edu/~karlin/papers/balls.pdf">два</link>
сервера, из которых выбирает сервер,
используя указанный <literal>метод</literal>.
Методом по умолчанию является <literal>least_conn</literal>,
при котором запрос передаётся на сервер
с наименьшим количеством активных соединений.
</para>

</directive>

</section>


<section id="variables" name="Встроенные переменные">

<para>
Модуль <literal>ngx_http_upstream_module</literal>
поддерживает следующие встроенные переменные:
<list type="tag">

<tag-name id="var_upstream_addr"><var>$upstream_addr</var></tag-name>
<tag-desc>
хранит IP-адрес и порт или путь к UNIX-сокету сервера группы.
Если при обработке запроса были сделаны обращения к нескольким серверам,
то их адреса разделяются запятой, например,
“<literal>192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock</literal>”.
Если произошло внутреннее перенаправление от одной группы серверов на другую
с помощью
<header>X-Accel-Redirect</header> или
<link doc="ngx_http_core_module.xml" id="error_page"/>,
то адреса, соответствующие разным группам серверов, разделяются двоеточием,
например,
“<literal>192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80</literal>”.
Если сервер не может быть выбран,
то переменная хранит имя группы серверов.
</tag-desc>

<tag-name id="var_upstream_bytes_received"><var>$upstream_bytes_received</var></tag-name>
<tag-desc>
число байт, полученных от сервера группы (1.11.4).
Значения нескольких соединений
разделяются запятыми и двоеточиями подобно адресам в переменной
<link id="var_upstream_addr">$upstream_addr</link>.
</tag-desc>

<tag-name id="var_upstream_bytes_sent"><var>$upstream_bytes_sent</var></tag-name>
<tag-desc>
число байт, переданных на сервер группы (1.15.8).
Значения нескольких соединений
разделяются запятыми и двоеточиями подобно адресам в переменной
<link id="var_upstream_addr">$upstream_addr</link>.
</tag-desc>

<tag-name id="var_upstream_cache_status"><var>$upstream_cache_status</var>
</tag-name>
<tag-desc>
хранит статус доступа к кэшу ответов (0.8.3).
Статус может быть одним из “<literal>MISS</literal>”,
“<literal>BYPASS</literal>”, “<literal>EXPIRED</literal>”,
“<literal>STALE</literal>”, “<literal>UPDATING</literal>”,
“<literal>REVALIDATED</literal>” или “<literal>HIT</literal>”.
</tag-desc>

<tag-name id="var_upstream_connect_time"><var>$upstream_connect_time</var>
</tag-name>
<tag-desc>
хранит время, затраченное на установление соединения с сервером группы (1.9.1);
время хранится в секундах с точностью до миллисекунд.
В случае SSL, включает в себя время, потраченное на handshake.
Времена нескольких соединений
разделяются запятыми и двоеточиями подобно адресам в переменной
<link id="var_upstream_addr">$upstream_addr</link>.
</tag-desc>

<tag-name id="var_upstream_cookie_"><var>$upstream_cookie_</var><value>имя</value>
</tag-name>
<tag-desc>
кука с указанным <value>именем</value>, переданная сервером группы
в поле <header>Set-Cookie</header> заголовка ответа (1.7.1).
Необходимо иметь в виду, что куки запоминаются только из ответа
последнего сервера.
</tag-desc>

<tag-name id="var_upstream_header_time"><var>$upstream_header_time</var>
</tag-name>
<tag-desc>
хранит время,
затраченное на получение заголовка ответа от сервера группы (1.7.10);
время хранится в секундах с точностью до миллисекунд.
Времена нескольких ответов
разделяются запятыми и двоеточиями подобно адресам в переменной
<link id="var_upstream_addr">$upstream_addr</link>.
</tag-desc>

<tag-name id="var_upstream_http_"><var>$upstream_http_</var><value>имя</value></tag-name>
<tag-desc>
хранят поля заголовка ответа сервера.
Например, поле заголовка ответа <header>Server</header>
доступно в переменной <var>$upstream_http_server</var>.
Правила преобразования имён полей заголовка ответа в имена переменных
такие же, как для переменных с префиксом
“<link doc="ngx_http_core_module.xml" id="var_http_">$http_</link>”.
Необходимо иметь в виду, что поля заголовка запоминаются только из ответа
последнего сервера.
</tag-desc>

<tag-name id="var_upstream_queue_time"><var>$upstream_queue_time</var></tag-name>
<tag-desc>
хранит время, проведённое запросом в <link id="queue">очереди</link>
(1.13.9);
время хранится в секундах с точностью до миллисекунд.
Времена нескольких ответов
разделяются запятыми и двоеточиями подобно адресам в переменной
<link id="var_upstream_addr">$upstream_addr</link>.
</tag-desc>

<tag-name id="var_upstream_response_length"><var>$upstream_response_length</var>
</tag-name>
<tag-desc>
хранит длину ответа, полученного от сервера группы (0.7.27);
длина хранится в байтах.
Длины нескольких ответов
разделяются запятыми и двоеточиями подобно адресам в переменной
<link id="var_upstream_addr">$upstream_addr</link>.
</tag-desc>

<tag-name id="var_upstream_response_time"><var>$upstream_response_time</var>
</tag-name>
<tag-desc>
хранит время, затраченное на получение ответа от сервера группы;
время хранится в секундах с точностью до миллисекунд.
Времена нескольких ответов
разделяются запятыми и двоеточиями подобно адресам в переменной
<link id="var_upstream_addr">$upstream_addr</link>.
</tag-desc>

<tag-name id="var_upstream_status"><var>$upstream_status</var></tag-name>
<tag-desc>
хранит статус ответа, полученного от сервера группы.
Статусы нескольких ответов
разделяются запятыми и двоеточиями подобно адресам в переменной
<link id="var_upstream_addr">$upstream_addr</link>.
Если сервер не может быть выбран, то
переменная хранит статус <http-status code="502" text="Bad Gateway"/>.
</tag-desc>

<tag-name id="var_upstream_trailer_"><var>$upstream_trailer_</var><value>имя</value></tag-name>
<tag-desc>
хранит поля из конца ответа,
полученного от сервера группы (1.13.10).
</tag-desc>

</list>
</para>

</section>

</module>