11. Таблицы привязок и одноранговые узлы
Таблицы привязок в HAProxy — это механизм, позволяющий ассоциировать определённое количество информации и метрик с ключом определённого типа на определённый срок после последнего обновления. Это можно рассматривать как строку в таблице с несколькими столбцами, где номер строки определяется значением ключа, а столбцы представляют отдельные критерии.
Таблицы привязок изначально были спроектированы для хранения информации о привязке сеанса между клиентом и сервером с целью поддержания постоянных сессий между этими сущностями. Клиент подключается или отправляет запрос, клиент идентифицируется с помощью дискриминатора (источний адрес, кука, URL параметр), и выбранный сервер сохраняется в ассоциации с этим дискриминатором в таблице привязок на заданное время, чтобы последующие запросы от того же клиента автоматически направлялись на тот же сервер, где клиент создавал свою сессию приложения.
Сегодня таблицы привязок могут хранить больше информации, чем просто номер сервера; могут храниться элементы, связанные с активностью конкретного клиента (счётчики/скорости запросов, соединений, байт и т.д.), а также некоторые произвольные счётчики (“gpc” — “General Purpose Counters”) и некоторые метки для обозначения определённых характеристик клиента (“gpt” — “General Purpose Tag”).
На таблицы привязок могут ссылаться директивы “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”.
В секции “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>, который обычно представляет собой одно слово, но может также иметь собственные аргументы: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>] Таблица, объявленная с “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 миллиардами в период. Использование этого параметра позволяет иметь скорости, превышающие этот 4Г ограничение в течение заданного периода. Множитель должен быть больше 0 и меньше или равен 1024.nopurge означает, что мы отказываемся удалять старые записи при полном списке. При отсутствии этого параметра и при полном списке, когда HAProxy хочет сохранить запись, он удаляет несколько старых записей, чтобы освободить место под новые. Это чаще всего желаемое поведение. В некоторых специфических случаях может быть желательно отказаться от новых записей, вместо удаления старых. Это может быть актуально, когда объём данных для хранения значительно превышает аппаратные ограничения, и мы предпочитаем не предоставлять доступ новым клиентам, чем отклонять уже подключённых. При использовании этого параметра необходимо правильно настроить параметр “expire” (см. выше).
recv-only означает, что мы не планируем использовать список для выполнения обновлений, а только для получения данных от удалённого узла, на который мы ориентированы. Действительно, использование этого слова позволяет получать локальные значения, такие как “conn_cur”, которые по умолчанию не усваиваются, так как они конфликтуют с локальными обновлениями, выполняемыми на списке локальным узлом. Использование этого параметра актуально только для списков, не участвующих в отслеживании правил или методов, выполняющих обновления на списке, или, проще говоря, для удалённых списков, используемых только для получения информации.
peers
<peersect>Записи, создаваемые, обновляемые или обновляющиеся, будут отправлены в узлы секции<peersect>для синхронизации, а ключи, полученные от узлов в этой секции, также будут вставлены или обновлены в таблице. Кроме того, при запуске может быть выполнена попытка получения записей из более ранней версии процесса, обозначенной как «локальный узел» через эту секцию.srvkey
<srvkey>Указывает, как каждый сервер идентифицируется с целью привязки сеанса. Допустимые значения — “name” и “addr”. Если указано “name”, то используется аргумент<name>для сервера (может быть сгенерирован шаблоном). Если указано “addr”, то сервер идентифицируется по его текущему сетевому адресу, включая порт. “addr” особенно полезен, если вы используете открытие сервисов для генерации адресов серверов с привязкой сеанса и хотите использовать один и тот же хост на всех узлах для токена привязки сеанса.store
<data_type>Используется для хранения дополнительной информации в stick-table. Может быть использован в ACL для контроля различных критериев, связанных с активностью клиента, соответствующего stick-table. Для каждого указанного здесь элемента размер каждой записи будет увеличен, чтобы дополнительные данные могли поместиться. Множество типов данных может быть сохранено в записи. Множество типов данных может быть указано после ключевого слова “store”, как запятая-разделённый список. Альтернативно, возможно повторение ключевого слова “store” с одним или несколькими типами данных. Вместо типа “server_id”, который автоматически обнаруживается и включается, все типы данных должны быть явно объявлены для хранения. Если ACL ссылается на тип данных, который не хранится, то ACL просто не будет соответствовать. Некоторые типы данных требуют аргумента, который должен быть передан сразу после типа в скобках. См. ниже для поддерживаемых типов данных и их аргументов.write-to
<wtable>Указывает имя другой таблицы привязок, в которую будут записываться обновления узлов дополнительно к исходной таблице.<wtable>должен иметь тот же тип, что и таблица, определяемая в данном контексте, и должен иметь ту же длину ключа; исходная таблица не может быть использована в качестве целевой таблицы. При каждом получении обновления в исходной таблице через узел HAProxy пытается обновить соответствующую<wtable>запись. Если запись ещё не существует, она будет создана, в противном случае её значения будут обновлены, а также обновлена её таймер. Обратите внимание, что только типы, не участвующие в арифметических операциях, такие как server_id, server_key и gpt, будут записываться в<wtable>, чтобы предотвратить нарушение арифметических операций, выполняемых на локальной целевой таблице (например: предотвратить бесконечное увеличение общего счётчика). Один из распространённых случаев использования этой опции — возможность использования правил привязки (для сохранения соединений с серверами) в конфигурации кластера узлов, поскольку ключи для соответствия будут извлекаться из удалённых таблиц.
Типы данных, которые могут быть привязаны к записям с помощью директивы “store”, перечислены ниже. Важно учитывать, что памятные требования могут оказаться значительными при хранении большого количества типов данных. Действительно, хранение всех указанных ниже показателей одновременно в каждой записи может потребовать сотен байт на запись, или сотен мегабайт для таблицы из 1-миллион записей. По этой причине указано приблизительное значение объёма хранения для каждого типа в скобках после аргумента.
Аргументы:
bytes_in_cnt [4 байт] Это количество байт от клиента к серверу. Это положительное 64-битное целое число, которое подсчитывает суммарное количество байт, полученных от клиентов, соответствующих этому элементу. Заголовки включаются в подсчёт. Это может быть использовано для ограничения злоупотреблений в функциях загрузки на серверах фото или видео. Примечание: значения измеряются при входе данных в HAProxy, поэтому подсчёты не зависят от сжатия.
bytes_in_rate(
<period>) [12 байт] Это счётчик скорости передачи байт от клиента к серверу. Он принимает целочисленный параметр<period>, указывающий в миллисекундах длительность периода, в течение которого измеряется средняя скорость. Он отображает среднюю скорость входящей передачи байт за этот период, в байтах в период. Может использоваться для обнаружения пользователей, загружающих слишком много и слишком быстро. Предупреждение: при больших загрузках возможно, что объём переданных данных будет учтён один раз при завершении сессии, что приведёт к резким скачкам средней скорости передачи, вместо плавного изменения. Это может частично быть устранено с помощью “option contstats”, хотя это не является идеальным решением. Рекомендуется использовать byte_in_cnt для лучшего распределения нагрузки.bytes_out_cnt [4 байт] Это счётчик байт от сервера к клиенту. Это положительное 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>элементов General Purpose Counter — счётчиков общего назначения. Это массив положительных 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 элементов: gpt(100), обеспечивающим хранение счётчиков gpc0 до gpc99, чтобы обеспечить вписывание сообщения о синхронизации узла в буфер. Массив не может содержать меньше 1 элементов: если требуется хранить только счётчик gpc0, используйте gpc(1). Пользователи должны учитывать, что большое количество счётчиков увеличивает объём данных и нагрузку на трафик при использовании протокола узлов, поскольку все данные/счётчики передаются при каждом обновлении. Это 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 элементов: используйте gpt(1), если хотите хранить только метку gpt0. Пользователи должны учитывать, что большое количество счётчиков увеличит размер данных и нагрузку на трафик при использовании протокола пирсов, поскольку все данные/счётчики передаются при каждом обновлении. Данное 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 запросов, вызванных клиентами, соответствующими данному входу. Ошибки учитываются для недопустимых и обрезанных запросов, а также для запрещённых или замедленных запросов, а также для неудачных попыток аутентификации. Если сервер отвечает кодом 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.
Пример:
См. также: “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>
Создаёт новый список узлов с именем <peersect>. Это независимая секция, которая ссылается на одну или несколько таблиц привязок.
bind [<address>]:port [param*]
Определяет параметры привязки локального узла данной секции “peers”. Такие строки не поддерживаются в сочетании с строкой “peer” в той же секции “peers”.
disabled
Отключает секцию подруг. Отключает как прослушивание, так и любую синхронизацию, связанную с этой секцией. Данная возможность позволяет отключить синхронизацию таблиц привязок без необходимости закомментировать все “peers”.
default-bind [param*]
Определяет параметры привязки для локального узла, исключая его адрес.
default-server [param*]
Изменить стандартные параметры для сервера в секции “peers”.
Аргументы:
См. также: “server” и секция 5 о параметрах сервера
enabled
Это включает секцию «peers», которая ранее была отключена с помощью ключевого слова “disabled”.
log <target> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
“peers” секции поддерживают тот же “log” ключевое слово, что и для прокси в логировании информации о
“peers” слушателе. См. “log” опцию для прокси для дополнительных деталей.
peer <peername> [<address>]:port [param*]
Определяет узел внутри секции узлов. Если <peername> установлен в имя локального узла (по умолчанию имя хоста, или заданное с помощью команды “-L” или настройки “localpeer” в глобальной конфигурации), HAProxy будет ожидать входящее соединение от удалённого узла на указанном адресе. В противном случае адрес определяет место подключения для присоединения к удалённому узлу, а <peername> используется на уровне протокола для идентификации и проверки удалённого узла на стороне сервера.
При мягком перезапуске адрес локального узла используется старым экземпляром для подключения к новому и инициализации полного реплицирования (процесса обучения).
Рекомендуется иметь идентичную декларацию узлов на всех узлах и полагаться только на аргумент командной строки “-L” или настройку “localpeer” в глобальной конфигурации для изменения имени локального узла. Это упрощает поддержку единообразных конфигурационных файлов на всех узлах.
Можно использовать ссылки на переменные среды в параметре адреса, см. секцию 2.3 о переменных среды.
Примечание: ключевое слово “peer” может быть прозрачно заменено на ключевое слово “server” (см. объяснение ключевого слова “server” ниже).
server <peername> [<address>:<port>] [param*]
Как уже упоминалось, ключевое слово “peer” может быть заменено ключевым словом “server” с поддержкой всех
параметров “server”, приведённых в секции 5.2, относящихся к настройкам транспорта. Если удалённый узел локален, параметр адреса не должен присутствовать; он должен быть указан в строке “bind” (см. ключевое слово “bind” этой “peers” секции).
Некоторые параметры “server” неактуальны для секций “peers”. Узлы по своей природе не поддерживают динамическое разрешение имен хостов и проверку работоспособности, поэтому параметры, такие как “init_addr”, “resolvers”, “check”, “agent-check” или “track”, не поддерживаются. Аналогично, отсутствует балансировка нагрузки и привязка сеанса, поэтому параметры, такие как “weight” или “cookie”, не имеют эффекта.
Пример:
shards <shards>
В некоторых конфигурациях желательно распределять содержимое stick-table по некоторым узлам вместо отправки всего содержимого stick-table каждому узлу, указанному в секции “peers”. В таких случаях, “shards” указывает количество узлов, участвующих в распределении содержимого stick-table. См. также параметр сервера “shard”.
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” имеют собственные пространства имен stick-table для предотвращения коллизий между именами stick-table, идентичными в разных секциях “peers”. Это внутренне реализуется путем присоединения к названию таблиц привязки сеансов имени секции “peers” и добавления символа ‘/’ после него. Если где-то ещё в конфигурационном файле необходимо ссылаться на такие таблици привязки, объявленные в секциях “peers”, то необходимо использовать префиксированное имя stick-table в следующем виде:
Это также версия с префиксом имени stick-table, которая должна использоваться для ссылки на таблицы привязок через CLI.
Для протокола “peers” такого различия не требуется, поскольку обмениваться данными могут только одноранговые узлы “peers”, принадлежащие одной секции. В нескольких секциях “peers” можно объявлять таблицы привязок с одинаковым именем. По сети передаётся сокращённое имя stick-table. Префикс состоит только из символа ‘/’, чтобы избежать конфликтов имён stick-table между таблицами, объявленными как бэкенды, и stick-table в секциях “peers”, как в следующей необычной, но поддерживаемой конфигурации:
Здесь таблица “t1” объявленная в секции “mypeers” имеет глобальное имя “mypeers/t1”. Таблица “t1” объявленная как бэкенд имеет глобальное имя “t1”. Однако на уровне протокола узла первая таблица называется “/t1”, вторая снова называется “t1”.