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

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

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

В случае сбоя сервера распределённая таблица продолжит работать, но результаты с вышедшего из строя шарда будут отсутствовать.

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, хранящий распределённую таблицу, где определены зеркальные агенты, отслеживает статус зеркал (активно или неактивно) и время отклика, а также выполняет автоматическое переключение при сбоях и балансировку нагрузки на основе этой информации.

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. Вероятности, взвешенные по задержкам, пересчитываются один раз за период karma.
3. Флаг "живой или мёртвый" корректируется один раз за запрос, включая ping-запросы.

Изначально вероятности равны. На каждом шаге они масштабируются обратно пропорционально задержкам, наблюдаемым за последний период karma, а затем нормализуются. Например, если в первые 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% в течение следующего периода karma, второе — с вероятностью 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.