Архитектура: Stronghold и Stronghold EE

Эта страница показывает архитектурные различия между базовым Stronghold и Stronghold EE через слои одного узла и объясняет, как порядок этих слоёв определяет поведение репликации: почему поток репликации переносит уже зашифрованные данные и почему seal у каждого кластера свой.

Базовый Stronghold соответствует Vault CE. Схемы упрощены: они показывают состав узла и направление запросов, а не сетевую разводку. Условные обозначения к схемам собраны в разделе Обозначения на схемах в конце страницы.

Сравнение уровней и вариантов репликации

Репликация работает на нескольких уровнях — внутри кластера, между кластерами и на уровне отдельных маунтов (KV). Всего вариантов пять; ниже они разобраны подробнее.

Слои одного узла

Запрос проходит слои узла сверху вниз. Ключевой момент — порядок слоёв: то, что расположено ниже, применяется позже и «видит» данные уже в том виде, в котором их обработали слои выше.

Узел Stronghold

Условные обозначения — в разделе Обозначения на схемах.

В базовом Stronghold узел состоит из четырёх слоёв: Stronghold API → Security Barrier → Raft → Physical storage.

• Stronghold API принимает запрос и направляет его к нужному backend’у.
• Security Barrier шифрует данные. Всё, что расположено ниже барьера, существует только в зашифрованном виде.
• Raft отвечает за консенсус и репликацию хранилища между узлами кластера (отказоустойчивость).
• Physical storage — хранилище на диске; данные лежат там уже зашифрованными.

В базовом Stronghold нет ни WAL Backend, ни sealwrap. Поэтому такой кластер не участвует в межкластерной репликации и не имеет второго слоя шифрования.

Узел Stronghold EE

Условные обозначения — в разделе Обозначения на схемах.

Stronghold EE добавляет два слоя, и важно, где именно они стоят: Stronghold API → Security Barrier → WAL Backend → Raft → Sealwrap → Physical storage.

• WAL Backend стоит сразу под барьером. Он записывает каждую мутацию в упорядоченный журнал, который служит источником данных для репликации. Так как он ниже барьера, в журнал попадают уже зашифрованные барьером значения.
• Sealwrap стоит в самом низу, между Raft и физическим хранилищем. Это второй слой шифрования для чувствительных путей; ключ хранит seal (внешний блок Sealwrapper).

Узлы в кластере

Несколько узлов объединяются в кластер поверх общего Raft-хранилища: один узел активный, остальные — standby. Между узлами данные синхронизируются по Raft (оранжевые стрелки), поэтому каждый узел держит полную зашифрованную копию хранилища. У кластера один seal — один Sealwrapper на всю группу.

HA-кластер (Stronghold)

Условные обозначения — в разделе Обозначения на схемах.

Клиент читает и пишет на активный узел (зелёные R/W). В базовом Stronghold standby-узлы запросы не обслуживают: они перенаправляют и чтение, и запись на активный узел (Forward R/W). Активный узел синхронизирует хранилище со standby по Raft — так обеспечивается отказоустойчивость: при отказе активного один из standby становится активным.

Performance standby (Stronghold EE)

Условные обозначения — в разделе Обозначения на схемах.

Тот же HA-кластер, но в Stronghold EE standby-узлы работают как performance standby: чтения они обслуживают локально, а запись перенаправляют на активный узел (Forward only Write). Чтобы standby отдавали свежие данные, активный узел стримит им события журнала (синие стрелки WAL). Так как WAL Backend ниже барьера, эти события несут уже зашифрованные данные. Seal у кластера по-прежнему один — общий внешний Sealwrapper.

Подробнее — на странице Performance standby.

Кластеры между собой

Межкластерная репликация доступна только в Stronghold EE. Она связывает целые кластеры: primary отдаёт поток журнала на secondary (синие Data WAL Streaming), а secondary перенаправляет клиентские записи обратно на primary. У каждого кластера свой Sealwrapper — и он может отличаться.

Performance

Условные обозначения — в разделе Обозначения на схемах.

Primary стримит на secondary только нелокальные данные — на схеме это отфильтрованный журнал filtered WAL. Локальные маунты и данные остаются на каждом кластере и не покидают его. Secondary обслуживает чтения локально, а записи перенаправляет на primary. Secondary-кластеров может быть несколько — primary раздаёт поток всем. Отдельному secondary можно ограничить набор реплицируемых данных фильтрами путей. У primary и secondary — свой seal (Sealwrapper 1 и Sealwrapper 2).

Disaster Recovery

Условные обозначения — в разделе Обозначения на схемах.

DR копирует всё, включая локальные данные — на схеме это WAL. Secondary — полная копия primary, но клиентов он не обслуживает и ждёт promote (Promote Request). При отказе primary secondary повышают (promote), и он берёт нагрузку на себя. Порядок promote и возврата прежнего primary — на странице Disaster recovery. У primary и secondary — свой seal (Sealwrapper 1 и Sealwrapper 2).

Почему seal может отличаться на кластерах

Поток репликации захватывается на уровне WAL Backend, то есть выше слоя sealwrap. Значит seal-обёртка на исходные данные ещё не наложена, и данные, зашифрованные через Seal, через межкластерную связь не передаются. Отсюда:

• secondary накладывает seal wrap своим seal, а не seal-ом primary;
• primary и secondary могут использовать даже разный тип seal (например, разные KMS);
• seal wrap настраивается на каждом кластере отдельно и не зависит от репликации.

Подробнее — на странице seal wrap. Что именно реплицируется в каждом режиме — на странице Обзор репликации.

KV-репликация (на уровне API)

Условные обозначения — в разделе Обозначения на схемах.

KV-репликация стоит особняком от межкластерной WAL-репликации. Её выполняет отдельный компонент — KV replicator, который живёт в самом верхнем слое узла, Stronghold API, то есть над Security Barrier. Поэтому она работает не с зашифрованным потоком WAL, а с логическими секретами через обычные публичные методы API.

Чем она отличается от perf/DR-репликации:

• Уровень API, а не WAL. WAL-репликация захватывается ниже барьера (на слое WAL Backend) и переносит шифртекст целого кластера. KV-репликация работает выше барьера, обращаясь к методам API, и синхронизирует только маунты KV1/KV2.
• Настраивается на slave-узле. Модель master-slave, pull: потребитель (slave) сам ходит на источник (master) и подтягивает секреты. Настройка задаётся при монтировании KV-хранилища на стороне потребителя.
• Работает на уровне узла. Так как общение идёт через методы API конкретного узла, репликация настраивается на конкретный узел кластера, а не на кластер целиком.
• Совместимость с разными хранилищами. master может быть хранилищем другой версии или реализации — Vault CE, Vault EE или любое хранилище секретов с совместимым Vault KV/KV2 API. Это упрощает миграцию и позволяет строить гетерогенные архитектуры.

Отсюда следует, где можно включить KV-репликацию: на любом узле, который обслуживает методы API, независимо от его роли в perf/DR-репликации. Единственное исключение — DR secondary: он не отвечает на клиентские запросы до promote, поэтому KV-репликация на нём недоступна.

KV-репликация — независимый оверлей: она не связана с seal, WAL и межкластерной репликацией и настраивается отдельно по каждому маунту.

Подробнее — на странице Репликация KV1/KV2.

Комбинированные топологии

Режимы независимы и совмещаются:

• Один primary — оба режима сразу. Кластер может одновременно быть performance primary и DR primary: раздавать данные на performance-secondary и держать DR-резерв.
• Каждый кластер — сам HA. Primary и secondary в межкластерных схемах — полноценные HA-кластеры; в Stronghold EE их standby-узлы обслуживают чтения как performance standby.
• Несколько secondary. У одного primary может быть много secondary-кластеров — и performance, и DR.

Ниже — несколько примеров таких комбинаций. Размер (HA или один узел) выбирается для каждого кластера отдельно, KV-репликацию можно навесить на любой кластер, кроме DR secondary, а seal у каждого кластера свой — поэтому seal wrap в топологии может быть настроен по-разному: где-то у каждого кластера свой seal, где-то один и тот же, а где-то его нет вовсе (disable_sealwrap).

Условные обозначения — в разделе Обозначения на схемах.

Primary одновременно DR- и Performance-primary и состоит из одного узла; оба secondary — HA-кластеры, а отдельный кластер подаёт данные в primary по KV-репликации. Seal у каждого кластера свой — Sealwrapper 1…4 в этой топологии все разные.

Условные обозначения — в разделе Обозначения на схемах.

Тот же комбинированный primary, но HA с performance standby; оба secondary — тоже HA-кластеры. KV-репликация подключена к performance-secondary — то есть навесить её можно не только на primary. Seal у кластеров разный — Sealwrapper 1 и Sealwrapper 2, а у primary кластера слой дополнительного Seal отсутствует.

Условные обозначения — в разделе Обозначения на схемах.

HA-primary с performance standby раздаёт данные на одноузловые DR- и Performance-secondary; KV-репликация не используется, а Seal настроен только на primary кластере — Sealwrapper 1.

Обозначения на схемах

На схемах два уровня объектов (узел и кластер) и три вида связей, различающихся цветом.

Связи бывают двух видов, и их важно не путать: Raft (оранжевые стрелки) синхронизирует узлы внутри одного кластера, а репликация (синие стрелки между кластерами) связывает кластеры между собой. Зелёные стрелки — это доступ клиентов и перенаправление их записей, а не репликация. Коротко: Raft связывает узлы внутри кластера, репликация — кластеры между собой.

Цвета слоёв узла на схемах одинаковые везде: