Нативная репликация переносит данные одного кластера Stronghold на другие кластеры по сети. В отличие от репликации KV1/KV2, которая копирует отдельные секреты между хранилищами, нативная репликация переносит состояние кластера целиком: подключённые хранилища, политики, identity и остальные данные.
Поддерживаются два независимых режима.
| Режим | Назначение | Что переносит | Обслуживает клиентов |
|---|---|---|---|
| Performance | Масштабирование и распределение чтений | Общие данные кластера (хранилища, политики, identity), кроме локальных для узла | Да: читает локально, записи перенаправляет на primary, ведёт собственный token store |
| Disaster Recovery (DR) | Горячий резерв и аварийное переключение | Все данные кластера, включая локальные (токены, аренды) | Нет: ждёт promote |
Отдельно есть performance standby — это не другой кластер, а неактивные HA-узлы внутри одного кластера, которые обслуживают чтения локально. Смотрите Performance standby.
Что реплицируется
Обе схемы работают на уровне хранилища кластера, но переносят разный объём данных.
Performance реплицирует общее состояние кластера — то, что должно быть одинаковым на всех secondary:
- Нелокальные хранилища (mounts) и их данные: секреты под такими хранилищами переносятся на secondary (их можно ограничить фильтрами путей).
- Нелокальные методы аутентификации: их конфигурация и данные. Аутентификация реплицируется всегда и не подпадает под фильтры, чтобы фильтр секретов не заблокировал вход операторам.
- Политики ACL (глобальные).
- Пространства имён со всем содержимым.
- Identity: entity, группы и алиасы. Реплицируются всегда, независимо от фильтров.
- Системные и конфигурационные данные (
core/,sys/), кроме локальных для узла разделов.
Performance не реплицирует то, что локально для каждого кластера:
- Локальные хранилища и локальные методы аутентификации (созданные с
флагом
local) вместе с их данными — они есть только на том кластере, где заведены. - Локальные политики.
- Токены: у каждого кластера собственный token store. Secondary выдаёт собственные сервисные токены, а токены primary на нём недействительны — поэтому на secondary входят через реплицированный метод аутентификации.
- Аренды (leases) и их истечение.
- Аудит-устройства: их настройка локальна для узла.
- Операционное состояние узла и seal-материал.
Disaster Recovery реплицирует всё перечисленное выше и дополнительно локальные данные: локальные хранилища и методы аутентификации, локальные политики, токены и аренды. DR secondary — это полная копия primary, поэтому после promote он продолжает работать с теми же токенами и арендами. Не копируется лишь то, что по своей природе принадлежит конкретному узлу: seal-материал, журнал изменений и индекс репликации, состояние Raft и кэши обнаружения узлов.
| Тип сущности | Performance | Disaster Recovery |
|---|---|---|
| Нелокальные mounts и их секреты | Да (можно фильтровать) | Да |
Локальные mounts (local) | Нет | Да |
| Нелокальные auth-методы | Да | Да |
Локальные auth-методы (local) | Нет | Да |
| Политики ACL | Да | Да |
| Локальные политики | Нет | Да |
| Пространства имён | Да | Да |
| Identity (entity, группы, алиасы) | Да | Да |
| Токены | Нет (свой token store) | Да |
| Аренды (leases) | Нет | Да |
| Аудит-устройства | Нет (локально) | Да |
Независимо от режима репликации любой кластер может дополнительно использовать seal wrap — второй слой шифрования чувствительных значений поверх барьера хранилища. Seal-материал не реплицируется: у каждого кластера свой seal, а secondary может работать даже с другим типом seal чем primary. Поэтому seal wrap настраивается на каждом кластере отдельно и не зависит от репликации.
Требования
- Enterprise Edition. Нативная репликация есть только в Stronghold EE.
- Integrated Raft storage. Репликация ведёт журнал изменений, который
пишется только на integrated Raft storage. На других бэкендах она не
запускается, а её эндпоинты возвращают
replication not supported by this physical backend. - Доступ к кластерному порту. Secondary подключается к primary по
кластерному порту (
cluster_address, TLS с ALPN), а не по API-порту. Этот порт должен быть доступен между кластерами, а их TLS-сертификаты — согласованы.
Нативная репликация Performance и DR доступна только в Standalone-установке Stronghold. В составе модуля DKP межкластерная репликация не поддерживается.
Включение и отключение
В Stronghold EE репликация включена по умолчанию: эндпоинты sys/replication/*
доступны сразу. Включение конкретного режима — отдельная операция, она описана
на страницах Performance и DR.
Чтобы полностью отключить репликацию, задайте в конфигурации сервера параметр:
disable_wal_replication = trueТогда узел загружается как обычный: репликация, performance standby и эндпоинты
sys/replication/* недоступны. Чтобы отключить только performance standby, не
трогая репликацию, используйте disable_performance_standby = true.
Параметры disable_wal_replication и disable_performance_standby задаются в
конфигурации сервера Standalone-установки Stronghold.
Если репликация отключена, GET sys/replication/status возвращает 404.
Проверка состояния
d8 stronghold read sys/replication/statusСтатус режима показывает mode, cluster_id, state (running,
stream-wals, idle), connection_state, last_wal, last_remote_wal и
списки известных primary и secondary. Secondary догнал primary, когда его
last_wal дошёл до last_remote_wal.
Если репликацию включают на кластере, где уже есть данные (например, после
обновления со сборки без репликации), или после периода с отключённой
репликацией, узел при первом запуске сам заново индексирует хранилище. Вызывать
sys/replication/reindex вручную не нужно.
Доступные страницы
- Топологии и сценарии — схемы и типовые кейсы для всех трёх режимов.
- Репликация Performance — масштабирование чтений, настройка secondary, фильтры путей.
- Disaster recovery — горячий резерв, аварийное переключение и церемония promote.
- Performance standby — чтения на неактивных HA-узлах внутри кластера.