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