11. Таблицы привязок и одноранговые узлы

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

Изначально таблицы привязок предназначались для хранения привязки клиента к серверу, чтобы сохранять сеанс между ними. При подключении или отправке запроса клиент определялся по отличительному признаку — исходному адресу, cookie или параметру URL. Выбранный сервер сохранялся в таблице вместе с этим признаком на настраиваемый срок. Благодаря этому последующие обращения того же клиента автоматически направлялись на сервер, где он создал сеанс приложения.

Теперь таблицы привязок могут хранить не только номер сервера, но и метрики активности конкретного клиента: число и интенсивность запросов и соединений, количество и скорость передачи байтов и т. д. Также можно хранить произвольные счётчики событий (“gpc” — счётчики общего назначения) и метки характеристик клиента (“gpt” — метка общего назначения).

На таблицы привязок могут ссылаться директивы “stick”, обеспечивающие привязку клиента к серверу, правила “track-sc”, определяющие, какой ключ отслеживать в какой таблице для сбора метрик, а также функции извлечения образцов и преобразователи, которые могут немедленно найти заданный ключ и получить определённую метрику или данные. Общий принцип таков: обновление таблиц (gpt/gpc/metrics) и поиск сведений о привязке обновляют время доступа к записи и отодвигают срок её истечения. Простой поиск через функции извлечения образцов и преобразователи лишь получает данные, не отодвигая срок истечения записи.

Чтобы механизм масштабировался и сохранял работоспособность при перезагрузках HAProxy и переключении при отказе, обновлениями таблиц привязок можно обмениваться с другими узлами, называемыми “peers”, через механизм “Peers”, описанный в разделе 11.2 . Для точной настройки обмена можно также задать, что некоторые таблицы только получают сведения от одноранговых узлов либо что полученные от них обновления следует пересылать в другую таблицу.

Таблицы привязок можно объявлять в секциях прокси (фронтендах и бэкендах) директивой “stick-table”: в секции допускается лишь одна таблица, получающая имя секции. Либо их можно объявлять в секциях peers директивой “table”, за которой следует имя таблицы: так в одной секции “peers” можно определить несколько таблиц. Если нужно несколько таблиц привязок, обычно рекомендуется объявлять их в секции peers, когда предполагается обмен ими, либо создавать дополнительные секции бэкендов, содержащие только определение “stick-table”.

11.1. Объявление stick-table

Объявления stick-table в секциях прокси (“frontend”, “backend”, “listen”) и в секциях “peers” очень похожи. Отличие состоит в том, что объявление в секции peers требует имени и не принимает параметр “peers”.

В секции “frontend”, “backend” или “listen”:

stick-table type <type> size <size> [expire <expire>] [nopurge] [recv-only] [write-to <wtable>] [srvkey <srvkey>] [store <data_type>]* [brates-factor <factor>] [peers <peersect>]

В секции “peers”:

table <name> type <type> size <size> [expire <expire>] [nopurge] [recv-only] [write-to <wtable>] [srvkey <srvkey>] [store <data_type>]* [brates-factor <factor>]

Аргументы: (обязательные сначала, затем в алфавитном порядке):

• type <type> — обязательный аргумент, задающий тип ключа <type>. Обычно это одно слово, но у него также могут быть собственные аргументы:

  • ip — следует предпочесть более явный тип, например “ipv4” или “ipv6”. До версии 3.2 это был единственный способ настроить IPv4. В версии 3.2 “ip” — псевдоним “ipv4”, причём “ipv4” предпочтителен. В одной из будущих версий “ip” будет означать “ipv6”. Этот тип предназначен только для облегчения перехода с версий до 3.2 на версии после 3.2.

  • ipv4 — таблица, объявленная с этим типом, хранит только адреса IPv4. Представление очень компактно, около 50 байт на запись, и обеспечивает очень быстрый поиск и сохранение записей почти без накладных расходов. Основное применение — хранение исходных IP-адресов клиентов.

  • ipv6 — таблица, объявленная с “type ipv6”, хранит только адреса IPv6. Представление очень компактно, около 60 байт на запись, и обеспечивает очень быстрый поиск и сохранение записей почти без накладных расходов. Основное применение — хранение исходных IP-адресов клиентов.

  • integer Таблица, объявленная с “type integer”, будет хранить 32-битные целые числа, которые могут представлять идентификатор клиента, найденный в запросе, например.

  • string [len <len>] — таблица с “type string” хранит подстроки длиной до <len> символов. Если строка, полученная средством извлечения шаблона, длиннее <len>, она обрезается перед сохранением. При сопоставлении строки в таблице с извлечённым шаблоном сравнивается не более <len> символов. Если длина не указана, строка ограничивается 32 символами. Увеличение длины может заметно повысить потребление памяти.

  • binary [len <len>] — таблица с “type binary” хранит двоичные блоки длиной <len> байт. Если блок, полученный средством извлечения шаблона, длиннее <len>, он обрезается перед сохранением. Если результат выражения образца короче <len>, он дополняется значениями 0. Если длина не указана, блок ограничивается 32 байтами. Увеличение длины может заметно повысить потребление памяти.

• size <size> — обязательный аргумент, задающий максимальное число записей <size> в таблице. Он напрямую влияет на потребление памяти: требуется примерно 50 байт на запись, не считая указанного выше размера ключа, сохраняемых метрик и размера строки, если они есть. Поддерживаются суффиксы “k”, “m”, “g”, соответствующие множителям 2^10, 2^20 и 2^30.

• expire <delay> — максимальное время хранения записи с момента её последнего создания, обновления через ’track-sc’ или сопоставления правилом ‘stick match’ либо ‘stick on’. Срок <delay> задаётся в стандартном формате времени, как и тайм-ауты; единица по умолчанию — миллисекунды. Максимальный срок немного превышает 24 дня. Подробнее см. раздел 2.5 . Если срок не задан, сеансы не истекают автоматически, но при заполнении таблицы создание новых записей приводит к удалению самых старых. Если срок не задан, нельзя использовать “nopurge”. Примечание: преобразователи ’table_*’ выполняют поиск, но не продлевают срок хранения записи, поскольку им не требуется ’track-sc’.

• brates-factor <factor> — множитель для скорости входящего и исходящего потока байтов. Вместо отдельных байтов учитываются блоки байтов. Внутри используются 32-битные счётчики, ограниченные примерно 4 миллиардами за период. Этот параметр позволяет учитывать скорости выше предела 4G за заданный период. Множитель должен быть больше 0 и не больше 1024.

• nopurge запрещает удалять старые записи при заполнении таблицы. Без этого параметра, если HAProxy требуется сохранить запись в полной таблице, несколько самых старых записей удаляются, освобождая место для новых. Обычно именно это и требуется. Однако в некоторых случаях предпочтительно отклонять новые записи, сохраняя старые: например, если объём данных значительно превышает возможности оборудования и лучше отказать новым клиентам, чем уже подключённым. При использовании этого параметра необходимо правильно настроить “expire” (см. выше).

• recv-only указывает, что таблица предназначена только для получения интересующих данных от удалённого однорангового узла, а не для локальных обновлений. Параметр позволяет получать значения, которые обычно остаются локальными, например “conn_cur”. По умолчанию они не принимаются от других узлов, поскольку конфликтовали бы с обновлениями, которые локальный узел выполняет в этой таблице. Параметр имеет смысл только для таблиц, не используемых в правилах отслеживания или методах обновления: иначе говоря, для удалённых таблиц, из которых только читают сведения.

• peers <peersect> — созданные и изменённые записи, а также записи с продлённым сроком хранения передаются одноранговым узлам из секции <peersect> для синхронизации. Ключи, полученные от узлов этой секции, также вставляются или обновляются в таблице. Кроме того, при запуске может предприниматься попытка получить записи от прежнего экземпляра процесса, обозначенного в этой секции как локальный одноранговый узел.

• srvkey <srvkey> — способ идентификации сервера в таблице привязок. Допустимы “name” и “addr”. При “name” используется аргумент сервера <name>, который может быть сгенерирован шаблоном. При “addr” сервер определяется текущим сетевым адресом, включая порт. Значение “addr” особенно полезно, когда механизм обнаружения служб формирует адреса серверов с реплицируемыми таблицами привязок и требуется, чтобы один токен привязки указывал на один и тот же узел у всех участников.

• store <data_type> — хранение дополнительных сведений в таблице привязок. ACL могут использовать их для проверки различных критериев активности клиента, соответствующего записи таблицы. Каждый указанный элемент увеличивает размер записи на объём дополнительных данных. В одной записи можно хранить несколько типов данных: перечислить их через запятую после “store” либо повторить “store” с одним или несколькими типами. Все сохраняемые типы должны быть объявлены явно, кроме “server_id”, который обнаруживается и включается автоматически. Если ACL ссылается на несохраняемый тип данных, совпадения не будет. Некоторым типам требуется аргумент, который необходимо указать в круглых скобках сразу после типа. Поддерживаемые типы и их аргументы перечислены ниже.

• write-to <wtable> — имя другой таблицы привязок, куда обновления от одноранговых узлов записываются дополнительно к исходной таблице. Таблица <wtable> должна иметь тот же тип и длину ключа, что и объявляемая таблица; исходная таблица не может быть собственной целью. При каждом обновлении исходной таблицы, полученном от другого узла, HAProxy пытается обновить соответствующую запись <wtable>. Если записи нет, она создаётся; иначе обновляются её значения и таймер. В <wtable> записываются только типы, не участвующие в арифметических операциях, например server_id, server_key и gpt. Это предотвращает влияние вычисленных значений удалённой таблицы на арифметические операции в локальной целевой таблице, в частности бесконечный рост общего накопительного счётчика. Типичный случай применения — правила привязки к серверу в кластере одноранговых узлов, где ключи для сопоставления поступают из удалённых таблиц.

Ниже перечислены типы данных, которые можно связать с записью через директиву “store”. При хранении большого числа типов потребность в памяти может быть значительной. Все перечисленные показатели вместе могут занимать сотни байт на запись, а для таблицы из 1 миллиона записей — сотни мегабайт. Поэтому для каждого типа после аргумента в скобках указан приблизительный объём хранения.

Аргументы:

• bytes_in_cnt [8 байт] Это количество байт от клиента к серверу. Это положительное 64-битное целое число, которое подсчитывает суммарное количество байт, полученных от клиентов, соответствующих этому элементу. Заголовки включаются в подсчёт. Это может быть использовано для ограничения злоупотреблений в функциях загрузки на серверах фото или видео. Примечание: значения измеряются при входе данных в HAProxy, поэтому подсчёты не зависят от сжатия.

• bytes_in_rate(<period>) [12 байт] Это счётчик скорости передачи байт от клиента к серверу. Он принимает целочисленный параметр <period>, указывающий в миллисекундах длительность периода, в течение которого измеряется средняя скорость. Он отображает среднюю скорость входящей передачи байт за этот период, в байтах в период. Может использоваться для обнаружения пользователей, загружающих слишком много и слишком быстро. Предупреждение: при больших загрузках возможно, что объём переданных данных будет учтён один раз при завершении передачи, что приведёт к резким скачкам средней скорости передачи, вместо плавного изменения. Это может частично быть устранено с помощью “option contstats”, хотя это не является идеальным решением. Рекомендуется использовать byte_in_cnt для более справедливого учёта.

• bytes_out_cnt [8 байт] Это счётчик байт от сервера к клиенту. Это положительное 64-битное целое число, которое подсчитывает накопленное количество байт, отправленных клиентам, соответствующим этому вхождению. В счёт включаются заголовки. Может использоваться для ограничения злоупотреблений ботами, забирающими весь сайт. Примечание: значения измеряются при входе данных в HAProxy, поэтому сжатие не влияет на подсчёт.

• bytes_out_rate(<period>) [12 байт] Это счётчик скорости передачи байт от сервера к клиенту. Он принимает целочисленный параметр <period>, указывающий в миллисекундах длительность периода, в течение которого измеряется средняя скорость. Он отображает среднюю скорость исходящей передачи байт за этот период, в байтах в период. Может использоваться для обнаружения пользователей, скачивающих слишком много и слишком быстро. Предупреждение: при больших передачах возможно, что объём переданных данных будет учтён один раз при завершении передачи, что приведёт к резким скачкам средней скорости передачи, вместо плавного изменения. Это может частично быть устранено с помощью “option contstats”, хотя это не является идеальным решением. Рекомендуется использовать byte_out_cnt для более справедливого учёта.

• conn_cnt [4 байта] Это количество соединений. Это положительное 32-битное целое число, которое подсчитывает абсолютное количество соединений, полученных от клиентов, соответствующих этому элементу. Оно не означает, что соединения были приняты, просто что они были получены.

• conn_cur [4 байта] — число текущих соединений. Это положительное 32-битное целое число, хранящее количество одновременных соединений для записи. Оно увеличивается, когда входящее соединение соответствует записи, и уменьшается при завершении соединения. Так в любой момент известно точное число одновременных соединений для записи. По умолчанию этот тип не принимается от других одноранговых узлов: полученное значение не имело бы смысла, поскольку не учитывало бы локальный счётчик. С recv-only можно получать число одновременных соединений, наблюдаемое другими узлами.

• conn_rate(<period>) [12 байт] Это счётчик частоты соединений. Он принимает целочисленный параметр <period>, указывающий в миллисекундах длительность периода, в течение которого измеряется среднее значение. Он отображает среднюю интенсивность соединений за этот период, в соединениях на период. Результат — целое число, которое может быть использовано в ACL. Прием или отклонение соединений не влияет на их измерение.

• glitch_cnt [4 байта] — число протокольных аномалий на фронтенде. Это положительное 32-битное целое число, накапливающее число аномалий, отмеченных на клиентском соединении. Аномалии — необычные или неожиданные с точки зрения протокола действия клиента, которые могут указывать на серьёзную неисправность клиента либо на атакующего. Счётчик помогает выбрать способ обработки таких клиентов.

• glitch_rate(<period>) [12 байт] Счётчик частоты протокольных аномалий. Принимает целочисленный параметр <period>, задающий в миллисекундах длительность периода усреднения. Возвращает среднюю частоту аномалий на фронтенде за этот период. Может использоваться для обнаружения неисправных клиентов или потенциальных атакующих, выполняющих необычные или неожиданные с точки зрения протокола действия, если HAProxy отметил их как таковые.

• gpc(<nb>) [4 * <nb> байт] Массив из <nb> счётчиков общего назначения. Это массив положительных 32-битных целых чисел, которыми можно считать что угодно. Чаще всего их используют как увеличиваемые счётчики в записях, например чтобы отметить достижение предела и запустить действия. Массив ограничен 100 элементами, от gpc0 до gpc99, чтобы сообщение обновления для однорангового узла помещалось в буфер. Пользователям следует учитывать, что большое число счётчиков увеличивает объём данных и трафик протокола peers, поскольку при изменении любого элемента передаются все данные и счётчики. Этот data_type исключает использование устаревших data_types ‘gpc0’ и ‘gpc1’ в той же таблице. При использовании массива ‘gpc’ в качестве data_type все функции извлечения образцов и действия для ‘gpc0’ и ‘gpc1’ применяются к первым двум элементам массива.

• gpc_rate(<nb>,<period>) [12 * <nb> байт] — массив интенсивностей приращения счётчиков общего назначения за период. Элементы — положительные 32-битные целые числа, пригодные для любых целей. Как и <gpc>, они учитывают события, но хранят интенсивность увеличения счётчика, а не накопленное значение. Обычно они измеряют частоту определённых событий, например запросов к конкретному URL. Массив ограничен 100 элементами: gpc_rate(100,<period>) позволяет хранить gpc0_rate–gpc99_rate, чтобы сообщение обновления для однорангового узла помещалось в буфер. В массиве должно быть не меньше 1 элемента; для одной интенсивности gpc0_rate используется gpc_rate(1,<period>). Следует учитывать, что большое число счётчиков увеличивает объём данных и трафик протокола peers: при изменении любого из них передаются все данные и счётчики. Этот data_type исключает устаревшие data_types ‘gpc0_rate’ и ‘gpc1_rate’ в той же таблице. При использовании массива ‘gpc_rate’ в качестве data_type все функции извлечения и действия для ‘gpc0’ и ‘gpc1’ относятся к первым двум элементам массива.

• gpc0 [4 байта] Это первый счётчик общего назначения. Это положительное 32-битное целое число, которое может использоваться для любых целей. Чаще всего оно используется для присвоения специальной метки определённым записям, например, чтобы отметить, что определённое поведение было обнаружено и должно быть известно для последующих совпадений.

• gpc0_rate(<period>) [12 байт] Это скорость увеличения первого счётчика общего назначения за определённый период. Это положительное 32-битное целое число, которое может использоваться для любых целей. Подобно <gpc0>, оно подсчитывает события, но вместо хранения накопленного значения, оно сохраняет скорость увеличения счётчика. Чаще всего оно используется для измерения частоты возникновения определённых событий (например, запросов к конкретному URL).

• gpc1 [4 байта] Это второй счётчик общего назначения. Это положительное целое число из 32 бит, которое может быть использовано для любых целей. Чаще всего оно применяется для присвоения специальной метки некоторым записям, например, чтобы отметить, что определённое поведение было обнаружено и должно быть известно для последующих совпадений.

• gpc1_rate(<period>) [12 байт] Это скорость увеличения второго счётчика общего назначения за определённый период. Это положительное целое число из 32 бит, которое может быть использовано для любых целей. Подобно <gpc1>, оно подсчитывает события, но вместо хранения накопленного значения, оно сохраняет скорость увеличения счётчика. Чаще всего оно используется для измерения частоты появления определённых событий (например, запросов к конкретному URL).

• gpt(<nb>) [4 * <nb> байт] — массив из <nb> меток общего назначения. Его элементы — положительные 32-битные целые числа, пригодные для любых целей. Обычно ими помечают записи, например фиксируют обнаруженное поведение, которое необходимо учитывать при последующих сопоставлениях. Массив ограничен 100 элементами: gpt(100) позволяет хранить gpt0–gpt99, чтобы сообщение обновления для однорангового узла помещалось в буфер. В массиве должно быть не меньше 1 элемента; для одной метки gpt0 используется gpt(1). Следует учитывать, что большое число счётчиков увеличивает объём данных и трафик протокола peers: при изменении любого из них передаются все данные и счётчики. Этот data_type исключает устаревший data_type ‘gpt0’ в той же таблице. При использовании массива ‘gpt’ в качестве data_type все функции извлечения и действия для ‘gpt0’ относятся к первому элементу массива.

• gpt0 [4 байта] — первая метка общего назначения. Это положительное 32-битное целое число, пригодное для любых целей. Обычно им помечают записи, например фиксируют обнаруженное поведение, которое необходимо учитывать при последующих сопоставлениях.

• http_req_cnt [4 байта] — число запросов HTTP. Это положительное 32-битное целое число, подсчитывающее общее число запросов HTTP от клиентов, соответствующих записи. Корректность запросов не имеет значения. При постоянных соединениях на клиентской стороне это значение отличается от числа сеансов.

• http_req_rate(<period>) [12 байт] Это счётчик частоты запросов. Он принимает целочисленный параметр <period>, указывающий в миллисекундах длительность периода, в течение которого вычисляется среднее значение. Он отображает среднюю интенсивность запросов HTTP в течение этого периода, в запросах за период. Результат — целое число, которое можно использовать в ACL. Не имеет значения, являются ли запросы действительными или нет. Примечание: это отличается от сессий при использовании постоянного соединения на клиентской стороне.

• http_err_cnt [4 байта] — число ошибок запросов HTTP. Это положительное 32-битное целое число, подсчитывающее общее число ошибок запросов HTTP по вине клиентов, соответствующих записи. Учитываются некорректные и усечённые запросы, запрещённые запросы, запросы, задержанные ловушкой соединений (tarpit), и неудачные попытки аутентификации. Если сервер отвечает кодом 4xx, запрос также считается ошибочным, поскольку ошибка вызвана клиентом, например при сканировании уязвимостей.

• http_err_rate(<period>) [12 байт] Это счётчик частоты запросов HTTP. Он принимает целочисленный параметр <period>, указывающий в миллисекундах длительность периода, за который измеряется среднее значение. Счётчик возвращает среднюю частоту ошибок HTTP запросов за этот период, в запросах на период (см. http_err_cnt выше, что считается ошибкой). Результат — целое число, которое можно использовать в ACL.

• http_fail_cnt [4 байта] Это счётчик сбоев HTTP ответа. Это положительное 32-битное целое число, которое подсчитывает абсолютное количество сбоев HTTP ответов, вызванных серверами, соответствующими этому элементу. Ошибки учитываются при неверных и обрезанных ответах, а также при любых ответах 5xx, кроме 501 и 505. Предназначен для использования в сочетании с путём или URI для обнаружения сбоев сервиса.

• http_fail_rate(<period>) [12 байт] Это счётчик частоты сбоев HTTP ответа. Он принимает целочисленный параметр <period>, указывающий в миллисекундах продолжительность периода, за который измеряется среднее значение. Счётчик возвращает среднюю частоту сбоев HTTP ответа за этот период, в запросах на период (см. http_fail_cnt выше, что считается сбоем). Результат — целое число, которое можно использовать в ACL.

• server_id [4 байта] — целое число с числовым идентификатором сервера, которому назначен запрос. Используется правилами “stick match”, “stick store” и “stick on” и включается автоматически при обращении к нему. Привязка на основе накопленных сведений имеет ограничения: при перезапуске все накопленные связи теряются, если одноранговые узлы не настроены для их передачи при перезапуске. Такая настройка рекомендуется. Обычно этот способ полезен как дополнение к другим механизмам привязки, но не всегда подходит как единственный механизм.

• sess_cnt [4 байта] — число сеансов. Это положительное 32-битное целое число, подсчитывающее общее число сеансов от клиентов, соответствующих записи. Сеансом считается соединение, принятое правилами уровня 4 (“tcp-request connection”).

• sess_rate(<period>) [12 байт] Это счётчик частоты сессий. Принимает целочисленный параметр <period>, указывающий в миллисекундах длительность периода, в течение которого вычисляется среднее значение. Отображает среднюю частоту входящих сессий за этот период, в сессиях за период. Результат — целое число, которое может использоваться в ACL.

Пример:

# Keep track of counters of up to 1 million IP addresses over 5 minutes
# and store a general purpose counter and the average connection rate
# computed over a sliding window of 30 seconds.
stick-table type ip size 1m expire 5m store gpc0,conn_rate(30s)

См. также: “stick match”, “stick on”, “stick store-request”, “track-sc”, раздел 2.5 о формате времени, раздел 11.2 об одноранговых узлах, раздел 9.7 об ограничениях пропускной способности и раздел 7 об ACL.

11.2. Объявление одноранговых узлов

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

Исключение — тип данных “conn_cur”, который по умолчанию никогда не принимается от других узлов, поскольку должен отражать локальные значения. В старых версиях он синхронизировался по умолчанию, что приводило к отрицательным значениям в конфигурациях active-active и постоянному росту значений при перезагрузках или переключениях active-passive: локальное значение отражало больше соединений, чем имелось на самом деле. Однако иногда получать это значение от других узлов полезно, например для пассивной удалённой таблицы, используемой только для получения данных и мониторинга, без операций записи или обновления на её основе. Для этого в объявление таблицы добавляют “recv-only”. В любом случае сведения “conn_cur” всегда отправляются, чтобы системы мониторинга могли их наблюдать.

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

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

peers <peersect>

peers <peersect>

Создаёт список одноранговых узлов с именем <peersect>. Это независимая секция, на которую ссылаются одна или несколько таблиц привязок.

bind [<address>]:port [param*]

bind [<address>]:port [param*]
bind /<path> [param*]

Определяет параметры привязки локального узла данной секции “peers”. Такие строки не поддерживаются в сочетании с строкой “peer” в той же секции “peers”.

disabled

disabled

Отключает секцию peers: как прослушивание соединений, так и всю связанную с этой секцией синхронизацию. Это позволяет отключить синхронизацию таблиц привязок, не закомментировывая все ссылки на “peers”.

default-bind [param*]

default-bind [param*]

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

default-server [param*]

default-server [param*]

Изменяет параметры по умолчанию для сервера в секции “peers”.

Аргументы:

<param*>  — список параметров сервера. Ключевое слово "default-server"
          принимает множество параметров, описанных в отдельном разделе.
          В секции peers поддерживаются транспортные параметры строки
          "default-server". Подробнее см. раздел 5, а некоторые ограничения
          приведены ниже, в описании ключевого слова "server" этой секции.

См. также: “server” и раздел 5 о параметрах сервера

enabled

enabled

Это включает секцию «peers», которая ранее была отключена с помощью ключевого слова “disabled”.

log <target> [len <length>] [format <format>] [sample <ranges>:<sample_size>]

log <target> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
    <facility> [<level> [<minlevel>]]

Секции “peers” поддерживают то же ключевое слово “log”, что и прокси, для записи сведений о слушателе “peers” в журнал. Подробнее см. описание параметра “log” для прокси.

peer <peername> [<address>]:port [param*]

peer <peername> [<address>]:port [param*]
peer <peername> /<path> [param*]

Определяет узел внутри секции узлов. Если <peername> установлен в имя локального узла (по умолчанию имя хоста, или заданное с помощью параметра командной строки “-L” или настройки “localpeer” в глобальной конфигурации), HAProxy будет ожидать входящее соединение от удалённого узла на указанном адресе. В противном случае адрес определяет место подключения для присоединения к удалённому узлу, а <peername> используется на уровне протокола для идентификации и проверки удалённого узла на стороне сервера.

При мягком перезапуске адрес локального узла используется старым экземпляром для подключения к новому и инициализации полного реплицирования (процесса обучения).

Настоятельно рекомендуется иметь одинаковые объявления одноранговых узлов на всех узлах и полагаться только на аргумент командной строки “-L” или настройку “localpeer” в глобальной конфигурации для изменения имени локального узла. Это упрощает поддержку единообразных конфигурационных файлов на всех узлах.

В параметре адреса можно использовать переменные окружения; см. раздел 2.3 о переменных окружения.

Примечание: ключевое слово “peer” может быть прозрачно заменено на ключевое слово “server” (см. объяснение ключевого слова “server” ниже).

server <peername> [<address>:<port>] [param*]

server <peername> [<address>:<port>] [param*]
server <peername> [/<path>] [param*]

Как уже упоминалось, ключевое слово “peer” может быть заменено ключевым словом “server” с поддержкой всех параметров “server”, приведённых в разделе 5.2, относящихся к настройкам транспорта. Если указанный узел локальный, параметр адреса не должен присутствовать; он должен быть указан в строке “bind” (см. ключевое слово “bind” этой “peers” секции).

Некоторые параметры “server” неактуальны для секций “peers”. Узлы по своей природе не поддерживают динамическое разрешение имен хостов и проверку работоспособности, поэтому параметры, такие как “init_addr”, “resolvers”, “check”, “agent-check” или “track”, не поддерживаются. Аналогично, отсутствует балансировка нагрузки и привязка сеанса, поэтому параметры, такие как “weight” или “cookie”, не имеют эффекта.

Пример:

 # The old way.
 peers mypeers
     peer haproxy1 192.168.0.1:1024
     peer haproxy2 192.168.0.2:1024
     peer haproxy3 10.2.0.1:1024

 backend mybackend
     mode tcp
     balance roundrobin
     stick-table type ip size 20k peers mypeers
     stick on src

     server srv1 192.168.0.30:80
     server srv2 192.168.0.31:80

Пример:
  peers mypeers
     bind 192.168.0.1:1024 ssl crt mycerts/pem
     default-server ssl verify none
     server haproxy1 #local peer
     server haproxy2 192.168.0.2:1024
     server haproxy3 10.2.0.1:1024

shards <shards>

В некоторых конфигурациях желательно распределять содержимое stick-table по некоторым узлам вместо отправки всего содержимого stick-table каждому узлу, указанному в секции “peers”. В таких случаях, “shards” указывает количество узлов, участвующих в распределении содержимого stick-table. См. также параметр сервера “shard”.

table <tablename> type {ip | integer | string [len <length>] | binary [len <length>]}

table <tablename> type {ip | integer | string [len <length>] | binary [len <length>]}

  size `<size>` [expire `<expire>`] [write-to `<wtable>`] [nopurge] [store `<data_type>`]*
  [recv-only]

Настраивает таблицу привязок для текущей секции. Строка разбирается так же, как директива “stick-table” в других секциях, но аргумент “peers” здесь не требуется, а первым добавляется обязательный параметр с именем stick-table. В отличие от других секций, в “peers” может быть несколько строк “table”. Полные определения “table” и “stick-table” приведены выше в разделе 11.1 .

Секции “peers” имеют собственные пространства имён таблиц привязок, чтобы одинаковые имена в разных секциях “peers” не конфликтовали. Внутри HAProxy перед именем таблицы привязок добавляются имя секции “peers” и символ ‘/’. В других местах файла конфигурации на таблицу привязок из секции “peers” необходимо ссылаться по имени с этим префиксом:

peers mypeers
    peer A ...
    peer B ...
    table t1 ...

frontend fe1
    tcp-request content track-sc0 src table mypeers/t1

В CLI для обращения к таблице привязок также необходимо использовать имя с префиксом.

Для протокола “peers” такого различия не требуется, поскольку обмениваться данными могут только одноранговые узлы “peers”, принадлежащие одной секции. В нескольких секциях “peers” можно объявлять таблицы привязок с одинаковым именем. По сети передаётся сокращённое имя stick-table. Префикс состоит только из символа ‘/’, чтобы избежать конфликтов имён stick-table между таблицами, объявленными как бэкенды, и stick-table в секциях “peers”, как в следующей необычной, но поддерживаемой конфигурации:

peers mypeers
    peer A ...
    peer B ...
    table t1 type string size 10m store gpc0

backend t1
    stick-table type string size 10m store gpc0 peers mypeers

Здесь таблица “t1” объявленная в секции “mypeers” имеет глобальное имя “mypeers/t1”. Таблица “t1” объявленная как бэкенд имеет глобальное имя “t1”. Однако на уровне протокола узла первая таблица называется “/t1”, вторая снова называется “t1”.