Чтобы добавить новый узел в кластер, просто запустите еще один экземпляр Manticore и убедитесь, что он доступен для остальных узлов кластера. Подключите новый узел к остальным узлам кластера, используя распределенную таблицу, и обеспечьте безопасность данных с помощью репликации.

Для понима как добата табли с уда агents, важно first иметь базовое understanding о distributed tables In this article, we will focus на как использовать distributed table как basis для созда кластер Мanticore instances.

table mydist {
          type  = distributed
          agent = box1:9312:shard1
          agent = box2:9312:shard2
          agent = box3:9312:shard3
          agent = box4:9312:shard4
}

In event server failure, distributed table will still work, but results from failed shard will be missing.

table mydist {
          type  = distributed
          agent = box1:9312|box5:9312:shard1
          agent = box2:9312:|box6:9312:shard2
          agent = box3:9312:|box7:9312:shard3
          agent = box4:9312:|box8:9312:shard4
}

Агенты зеркал могут использоваться взаимозаменяемо при обработке поискового запроса. Экземпляр(ы) Manticore, размещающий распределённую таблицу, где определены зеркалируемые агенты, отслеживает статус зеркал (активны или неактивны) и время отклика, а также выполняет автоматический failover и балансировку нагрузки на основе этой информации.

agent = node1|node2|node3:9312:shard2

Пример выше объявляет, что node1:9312, node2:9312 и node3:9312 имеют таблицу с именем shard2 и могут использоваться как взаимозаменяемые зеркала. Если любой из этих серверов выходит из строя, запросы будут распределяться между оставшимися двумя. Когда сервер снова становится доступен, основной узел обнаружит это и начнёт направлять запросы ко всем трём узлам снова.

Зеркало также может включать индивидуальный список таблиц, как показано ниже:

agent = node1:9312:node1shard2|node2:9312:node2shard2

Это работает аналогично предыдущему примеру, но при обращении к разным серверам будут использоваться разные имена таблиц. Например, node1shard2 будет использоваться при запросах к node1:9312, и node2shard будет использоваться при запросах к node2:9312.

По умолчанию все запросы направляются к лучшему из зеркал. Лучшее зеркало выбирается на основе последних статистических данных, контролируемых директивой конфигурации ha_period_karma. Основной узел хранит метрики (общее количество запросов, количество ошибок, время отклика и т.д.) для каждого агента и группирует их по временным интервалам. Карма — это длина временного интервала. Лучшее зеркало агента затем определяется динамически на основе последних двух таких временных интервалов. Конкретный алгоритм выбора зеркала можно настроить с помощью директивы ha_strategy.

Период кармы задан в секундах и по умолчанию равен 60 секундам. Основной узел хранит до 15 периодов кармы с метриками по каждому агенту для целей инструментирования (см. оператор SHOW AGENT STATUS). Однако для логики HA/LB используются только последние два периода.

При отсутствии запросов основной узел посылает регулярную команду ping каждые ha_ping_interval миллисекунд, чтобы собирать статистику и проверять, жив ли удалённый хост. Значение ha_ping_interval по умолчанию равно 1000 мс. Установка его в 0 отключает пинги, и статистика будет накапливаться только на основе реальных запросов.

Пример:

# sharding table over 4 servers total
# in just 2 shards but with 2 failover mirrors for each shard
# node1, node2 carry shard1 as local
# node3, node4 carry shard2 as local
# config on node1, node2
agent = node3:9312|node4:9312:shard2
# config on node3, node4
agent = node1:9312|node2:9312:shard1

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

ha_strategy = {random|nodeads|noerrors|roundrobin}

Стратегия выбора зеркала для балансировки нагрузки является опциональной и по умолчанию установлена в значение random.

Стратегия, используемая для выбора зеркала, или другими словами, выбора конкретного зеркального агента в распределённой таблице, контролируется этой директивой. По сути, эта директива управляет тем, как мастер выполняет балансировку нагрузки между настроенными зеркальными агентскими узлами. Реализованы следующие стратегии:

ha_strategy = random

Простая стратегия случайного выбора по умолчанию не учитывает статус зеркал, уровень ошибок и, что важнее всего, фактические задержки отклика. Чтобы справиться с неоднородными кластерами и временными пиками нагрузки на агентские узлы, существует группа стратегий балансировки, которые динамически регулируют вероятности на основе фактических задержек запросов, наблюдаемых мастером.

Адаптивные стратегии, основанные на вероятностях, взвешенных по задержкам, работают следующим образом:

1. Статистика задержек накапливается блоками по ha_period_karma секунд.
2. Вероятности, взвешенные по задержкам, пересчитываются один раз за период кармы.
3. Флаг "живой или мёртвый" корректируется на каждый запрос, включая ping-запросы.

Изначально вероятности равны. На каждом шаге они масштабируются обратными значениями задержек, наблюдаемых в течение последнего периода кармы, а затем нормализуются заново. Например, если в первые 60 секунд после запуска мастера 4 зеркала показали задержки 10 мс, 5 мс, 30 мс и 3 мс соответственно, то первый шаг корректировки будет следующим:

1. Исходные проценты: 0.25, 0.25, 0.25, 0.25.
2. Наблюдаемые задержки: 10 мс, 5 мс, 30 мс, 3 мс.
3. Обратные значения задержек: 0.1, 0.2, 0.0333, 0.333.
4. Масштабированные проценты: 0.025, 0.05, 0.008333, 0.0833.
5. Нормализованные проценты: 0.15, 0.30, 0.05, 0.50.

Это означает, что первое зеркало будет иметь 15% шанс быть выбранным в следующий период кармы, второе — 30%, третье (самое медленное, с задержкой 30 мс) — только 5%, а четвёртое и самое быстрое (3 мс) — 50%. После этого периода второй шаг корректировки снова обновит эти шансы и так далее.

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

ha_strategy = nodeads

ha_strategy = noerrors

ha_strategy = roundrobin

ha_period_karma = 2m

ha_period_karma определяет размер окна статистики агентских зеркал, в секундах (или с суффиксом времени). Опционально, по умолчанию 60.

Для распределённой таблицы с агентскими зеркалами сервер отслеживает несколько различных счётчиков для каждого зеркала. Эти счётчики затем используются для фейловера и балансировки. (Сервер выбирает лучшее зеркало на основе этих счётчиков.) Счётчики накапливаются блоками по ha_period_karma секунд.

После начала нового блока мастер всё ещё может использовать накопленные значения из предыдущего блока, пока новый блок не заполнится наполовину. Таким образом, любое предыдущая история перестаёт влиять на выбор зеркала спустя максимум 1.5 периода ha_period_karma.

Хотя для выбора зеркала используется не более 2 блоков, для целей инструментирования фактически хранится до 15 последних блоков. Их можно просмотреть с помощью оператора SHOW AGENT STATUS.

ha_ping_interval = 3s

Директива ha_ping_interval задаёт интервал между ping-запросами, отправляемыми агентским зеркалам, в миллисекундах (или с суффиксом времени). Эта опция является необязательной, по умолчанию значение равно 1000.

Для распределённой таблицы с агентскими зеркалами сервер шлёт всем зеркалам команду ping в периоды простоя, чтобы отслеживать их текущий статус (живы они или мертвы, время сетевого отклика и т. п.). Интервал между ping-запросами определяется настройкой ha_ping_interval.

Если вы хотите отключить ping-запросы, установите ha_ping_interval в 0.