Кластеризация

Ключевые понятия и возможности кластера Meridian — несколько равноправных нод, согласованные бюджеты и шардинг.

Что это

Кластер Meridian — несколько равноправных нод за общим балансировщиком. Любая нода принимает запросы. Общее состояние — бюджеты, лимиты и состав кластера — согласуется через Raft. Отказ одной ноды не останавливает обслуживание и не приводит к двойному списанию или потере расхода.

Кластеризация доступна в редакции Enterprise и требует PostgreSQL в качестве основной БД. Для каждой ноды также важно локальное хранилище (не эвфемерное) или Persistent Volume для развертывания в Kubernetes. Локальное хранилище необходимо для записи журналов и слепоков состояний (snapshots) для согласования операций с бюджетов между узлами. В PostgreSQL происходит периодическая асинхронное обновление состояния бюджета для исключения взаимоблокировок между операциями и снижения нагрузки на кластер PostgreSQL.

Типичная конфигурация

Балансировщики распределяют запросы по нодам. Ноду, которая отвечает не статусом 200 на /internal/ready, они выводят и клиентские запросы на такие ноды не попадают.
Ноды Meridian равноправны: каждая принимает запросы. Между собой ноды общаются по портам gossip 7946, Raft 9090, Olric 3320/3322 и API 8080.
PV — локальное хранилище ноды или Persistent Volume: журналы Raft, снапшоты, топология и журнал событий. У каждой ноды свой, общий volume недопустим.
postgresql-cluster — основная база данных. Ноды подключаются к endpoint master-узла.

Ключевые понятия

Понятие	Что это
Нода	Один процесс Meridian. Ноды находят друг друга по статическому списку `cluster_config.peers` из конфигурационного файла и обмениваются состоянием по gossip-протоколу.
Raft-группа	Набор реплик на разных нодах с общим журналом. У группы один лидер. Остальные реплики — voter (голосует) или learner (догоняет журнал и пока не голосует).
Кворум	Большинство голосующих реплик: `voters / 2 + 1`. Пока кворум есть, группа принимает записи.
`_meta`	Служебная Raft-группа. Хранит документ топологии: какие ноды входят в кластер и где размещены реплики шардов.
Шард	Raft-группа данных. Хранит бюджеты и лимиты своих заказчиков.
Заказчик (customer)	Единица размещения. Заказчик вместе с командами, виртуальными ключами, бюджетами и лимитами целиком находится на одном шарде.
`shard0`	Шард по умолчанию. Существует всегда и не удаляется. Новый заказчик без явно указанного шарда попадает сюда.
Документ топологии	Версионированное описание кластера. Каждое изменение состава создаёт новую версию.

Лидеры распределены по нодам

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

        ┌── shard0 ──┐   ┌── shard1 ──┐   ┌── shard2 ──┐
node1   │   leader   │   │  follower  │   │  follower  │
node2   │  follower  │   │   leader   │   │  follower  │
node3   │  follower  │   │  follower  │   │   leader   │
        └────────────┘   └────────────┘   └────────────┘

Кластерная конфигурация с поддержкой фактора репликации меньше чем количество узлов будет поддержана в будущих релизах Meridian.

Версии топологии

У документа топологии три курсора:

Latest — последняя сохранённая версия.
Target — версия, которую кластер сейчас применяет.
Active — последняя полностью применённая версия. Её используют маршрутизация запросов и запуск шардов.

Изменение сначала сохраняется как Latest, затем применяется в фоне и становится Active. Пока Active отстаёт, страница Status показывает баннер.

Как запрос находит шард

Запрос несёт виртуальный ключ. Плагин governance находит по ключу шард заказчика и резервирует бюджет через лидера этого шарда. Запрос с неизвестным ключом обрабатывает shard0.

Возможности

Возможность	Что даёт
Высокая доступность	Кластер из 3 нод переживает отказ одной ноды, из 5 нод — двух.
Согласованные бюджеты	Резервирование проходит через лидера шарда. Параллельные запросы с разных нод не превышают бюджет.
Шардинг	Заказчики распределяются по шардам, нагрузка на запись — по нодам.
Миграция заказчиков	Заказчик переносится на другой шард в работающем кластере.
Управление составом	Добавление, drain ноды (вывод реплик с нее), активация и исключение нод, передача лидерства — из веб-интерфейса.
Авто-восстановление	Лидер `_meta` возвращает вернувшиеся ноды на шарды. Шард без кворума он не трогает — это решение оператора.
Журнал и события	История версий топологии и хронология смены лидеров, кворума и доступности нод.
Аварийный промоушен	Единственная выжившая нода становится single-node кластером, когда остальные потеряны.

Ограничения

В кластере не более 5 нод, фактор репликации не более 5.
Для production рекомендуется 3 или 5 нод.
Каждой ноде нужен собственный постоянный каталог data_dir. Общий volume недопустим.
При первом старте все ноды из peers должны запускаться одновременно, кластер не запустися для предотвращения ошибок выбора лидера для _meta и shard0 групп.
Несколько шардов и миграция требуют лицензии с возможностью sharding.

Веб-интерфейс

Кластер управляется в разделе Cluster бокового меню.

Страница	Адрес	Назначение
Status	`/workspace/cluster`	Состояние нод, реплик и gossip, управление составом
Shards	`/workspace/cluster/shards`	Шарды, их реплики, владение и миграции
Journal	`/workspace/cluster/journal`	История версий топологии
Events	`/workspace/cluster/events`	Смены лидеров, кворума и доступности нод

Дальше

Статус кластера — как читать страницу Status и управлять нодами.
Шардинг — шарды, их статусы и миграция заказчиков.
Эксплуатация — журнал, события и что меняет статусы кластера.
Конфигурация — параметры cluster_config, шаблоны развёртывания и устранение неполадок.

Кластеризация

Содержание