Репликация в Stronghold переносит секреты и данные между кластерами и узлами. Она решает разные задачи: масштабирование чтений, горячий резерв на случай аварии и копирование отдельных секретов. Ниже — четыре механизма репликации; их можно использовать вместе.
Типы репликации
Performance-репликация (PR)
Масштабирует и распределяет чтения между кластерами. Performance secondary получает общее состояние кластера — нелокальные хранилища, методы аутентификации, политики, пространства имён и идентификационные данные (Identity) — и обслуживает клиентов локально: чтения выполняет сам, а записи перенаправляет на primary. У каждого secondary собственный token store, поэтому на нём входят через реплицированный метод аутентификации. Доступна только в Stronghold EE на integrated Raft storage.
Репликация для аварийного восстановления (DR)
Горячий резерв на случай отказа primary. DR secondary — полная копия primary, включая локальные данные (токены и аренды), но клиентов не обслуживает и ждёт команды promote. После переключения он продолжает работать с теми же токенами и арендами, что и бывший primary. Доступна только в Stronghold EE на integrated Raft storage.
Performance standby (горизонтальное масштабирование чтений)
Не отдельный кластер, а standby-узлы (неведущие узлы HA) внутри одного кластера. Без репликации standby-узлы только ждут лидерства и не обслуживают запросы; с включённой репликацией они обслуживают чтения локально, перенаправляя записи активному узлу. Так чтения масштабируются внутри кластера, без разворачивания второго кластера. Подробнее — Performance standby.
Репликация KV1/KV2
Копирует отдельные секреты выбранных хранилищ KV1/KV2 между кластерами на
уровне API, отдельно по каждой точке монтирования. Работает по модели master-slave (pull):
кластер-потребитель периодически сам забирает изменения из источника по обычным
методам API (list/read), а локальная реплицируемая точка монтирования доступна только на
чтение. В отличие от нативной репликации она не переносит состояние кластера
целиком, не требует доступа к кластерному порту и может настраиваться почти на
любом узле — в том числе из внешнего хранилища с совместимым Vault KV/KV2 API.
Полное описание — на странице Репликация KV1/KV2.
Сравнение уровней и вариантов репликации
Репликация работает на нескольких уровнях — внутри кластера, между кластерами и по отдельным точкам монтирования (KV). Всего вариантов пять:
| Вариант | Уровень | Назначение | Резерв / standby-узлы | Редакция |
|---|---|---|---|---|
| HA: репликация хранилища | Внутри кластера | Отказоустойчивость узлов | standby-узлы перенаправляют все запросы на активный узел | Stronghold и Stronghold EE |
| Performance standby | Внутри кластера | Горизонтальное масштабирование чтений | standby-узлы читают локально, запись — на активный узел | Stronghold EE |
| Репликация для аварийного восстановления (DR) | Между кластерами | Горячий резерв и аварийное переключение | secondary не обслуживает клиентов, ждёт promote | Stronghold EE |
| Performance-репликация (PR) | Между кластерами | Масштабирование и распределение чтений | secondary читают локально, запись — на primary | Stronghold EE |
| KV-репликация (KV1/KV2) | Между кластерами, по точкам монтирования (API) | Копирование выбранных KV-хранилищ | реплика (slave) read-only, запись — в master | Stronghold EE, кроме DR secondary |
Три варианта переносят данные между кластерами: PR, DR и KV1/KV2 (HA и performance standby работают внутри одного кластера). Ниже — что именно уходит между кластерами (performance standby границу кластера не пересекает):
| Тип объекта | PR | DR | KV1/KV2 |
|---|---|---|---|
| Нелокальные mounts и их секреты | Да (можно фильтровать) | Да | Секреты выбранных KV1/KV2-хранилищ |
Локальные mounts (local) | Нет | Да | Секреты выбранных локальных KV1/KV2-хранилищ |
| Нелокальные auth-методы | Да | Да | Нет |
Локальные auth-методы (local) | Нет | Да | Нет |
| Политики ACL | Да | Да | Нет |
| Пространства имён | Да | Да | Нет |
| Идентификационные данные (сущности, группы, алиасы) | Да | Да | Нет |
| Токены | Нет (свой token store) | Да | Нет |
| Аренды (leases) | Нет | Да | Нет |
| Аудит-устройства | Нелокальные: да (на secondary только чтение); local: нет | Да | Нет |
Репликация KV1/KV2 работает на уровне отдельного хранилища и не зависит от флага
local: источником и приёмником может быть любое хранилище KV1/KV2, в том
числе локальное. Она копирует только секреты, а не конфигурацию самой точки монтирования.
Независимо от режима репликации любой кластер может дополнительно использовать seal wrap — второй слой шифрования чувствительных значений поверх барьера хранилища. Данные, зашифрованные через Seal, не реплицируются: у каждого кластера свой seal, а secondary может работать даже с другим типом seal, чем primary. Поэтому seal wrap настраивается на каждом кластере отдельно и не зависит от репликации.
Что реплицируется в PR и DR
Здесь подробно, что именно переносят кластерные режимы PR и DR. Их настройка — на страницах «Performance-репликация (PR)» и «Репликация для аварийного восстановления (DR)»; настройка KV1/KV2 — на отдельной странице.
PR реплицирует общее состояние кластера — то, что должно быть одинаковым на всех secondary:
- Нелокальные хранилища (mounts) и их данные: секреты под такими хранилищами переносятся на secondary (их можно ограничить фильтрами путей).
- Нелокальные методы аутентификации: их конфигурация и данные. По
умолчанию они реплицируются; путь монтирования
auth/<PATH>можно также указать в фильтре путей, поэтому не фильтруйте метод аутентификации, через который операторы входят на secondary. - Политики ACL (глобальные).
- Пространства имён со всем содержимым.
- Идентификационные данные (Identity): сущности, группы и алиасы. Реплицируются всегда: Identity — это singleton-монтирование, его нельзя отфильтровать.
- Системные и конфигурационные данные (
core/,sys/), кроме локальных для узла разделов.
PR не реплицирует то, что локально для каждого кластера:
- Локальные хранилища и локальные методы аутентификации (созданные с
флагом
local) вместе с их данными — они есть только на том кластере, где заведены. - Токены: у каждого кластера собственный token store. Secondary выдаёт собственные сервисные токены, а токены primary на нём недействительны — поэтому на secondary входят через реплицированный метод аутентификации.
- Аренды (leases) и их истечение.
- Локальные аудит-устройства (созданные с флагом
local). Нелокальные аудит-устройства реплицируются и на secondary доступны только для чтения. - Операционное состояние узла и данные, зашифрованные через Seal.
DR реплицирует всё перечисленное выше и дополнительно локальные данные: локальные хранилища, локальные методы аутентификации, локальные аудит-устройства, токены и аренды. DR secondary — это полная копия primary, поэтому после promote он продолжает работать с теми же токенами и арендами. Не копируется лишь то, что по своей природе принадлежит конкретному узлу: данные, зашифрованные через Seal, журнал изменений и индекс репликации, состояние Raft и кеши обнаружения узлов.
Доступные страницы
Раздел о репликации содержит следующие страницы:
- Архитектура и схемы — из чего состоят узлы и кластеры и комбинированные топологии.
- Performance-репликация (PR) — масштабирование чтений, настройка secondary, фильтры путей.
- Репликация для аварийного восстановления (DR) — горячий резерв, аварийное переключение и церемония promote.
- Performance standby — горизонтальное масштабирование чтений на standby-узлах внутри кластера.
- Репликация KV1/KV2 — копирование отдельных KV-хранилищ между кластерами (master-slave, pull, на уровне API).