Performance-репликация (PR)

Performance-репликация (PR, performance replication) копирует хранилище primary-кластера (кроме локальных путей) на один или несколько performance-secondary. Secondary обслуживает чтения локально, а записи перенаправляет на primary. Так нагрузку чтения можно масштабировать и размещать ближе к потребителям.

Перед началом

Перед настройкой межкластерной репликации подготовьте следующее:

• Убедитесь, что оба кластера работают на Stronghold EE с integrated Raft storage и что репликация включена. Подробнее — в разделе «Обзор».
• Убедитесь, что кластерный порт primary доступен с secondary и что у вас есть CA-сертификат primary для TLS.
• Подготовьте токен с правами на sys/replication/* на обоих кластерах.

В примерах ниже ${PRIMARY_ADDR} и ${SECONDARY_ADDR} — API-адреса кластеров, а ${VAULT_TOKEN} — токен с правами на sys/replication/*.

Шаг 1. Включите primary

На кластере primary включите межкластерную репликацию в режиме primary:

d8 stronghold write -force sys/replication/performance/primary/enable

stronghold write -force sys/replication/performance/primary/enable

Шаг 2. Создайте activation-токен для secondary

Сгенерируйте токен активации в виде токена обёртывания для secondary с идентификатором id:

d8 stronghold write sys/replication/performance/primary/secondary-token id=sec-1 ttl=24h

stronghold write sys/replication/performance/primary/secondary-token id=sec-1 ttl=24h

Параметр id обязателен, ttl по умолчанию — 30m. Команда возвращает одноразовый токен обёртывания в поле wrap_info.token — его и передайте на secondary.

Шаг 3. Включите secondary

Передайте токен обёртывания из предыдущего шага. Для окружений с самоподписанными сертификатами параметр ca_file или ca_path (CA primary в формате PEM, читается на сервере secondary) обязателен, иначе TLS-соединение с primary не пройдёт проверку.

curl --header "X-Vault-Token: ${VAULT_TOKEN}" --request POST --data @secondary-enable.json "${SECONDARY_ADDR}/v1/sys/replication/performance/secondary/enable"

Пример secondary-enable.json:

{
  "token": "<WRAPPING_TOKEN>",
  "primary_api_addr": "<PRIMARY_API_ADDR>",
  "ca_file": "<PRIMARY_CA_FILE>"
}

Поля secondary/enable:

• token — обязательный; токен обёртывания из шага 2.
• primary_api_addr — адрес primary для разворачивания токена; обязателен, если в токене нет claim addr.
• ca_file / ca_path — путь к PEM-файлу или директории PEM-файлов, читается на сервере.
• client_cert_pem / client_key_pem — опциональные клиентский сертификат и ключ для TLS-соединения при unwrap.

Шаг 4. Проверьте статус

Проверьте статус репликации на кластере secondary:

d8 stronghold read -address="${SECONDARY_ADDR}" sys/replication/performance/status

stronghold read -address="${SECONDARY_ADDR}" sys/replication/performance/status

Когда secondary подключён и тянет WAL, поле state равно stream-wals, а connection_state — ready. Secondary догнал primary, когда его last_wal дошёл до last_remote_wal.

Шаг 5. Проверьте репликацию данных

Команды к secondary выполняйте с токеном, полученным при входе через реплицированный метод аутентификации (шаг 3): root-токен primary на secondary недействителен.

# Запись на primary.
d8 stronghold kv put -address="${PRIMARY_ADDR}" secret/hello value=world

# Чтение на secondary после схождения.
d8 stronghold kv get -address="${SECONDARY_ADDR}" secret/hello

# Запись на secondary перенаправляется на primary и возвращается через WAL.
d8 stronghold kv put -address="${SECONDARY_ADDR}" secret/fromsec value=1

# Запись на primary.
stronghold kv put -address="${PRIMARY_ADDR}" secret/hello value=world

# Чтение на secondary после схождения.
stronghold kv get -address="${SECONDARY_ADDR}" secret/hello

# Запись на secondary перенаправляется на primary и возвращается через WAL.
stronghold kv put -address="${SECONDARY_ADDR}" secret/fromsec value=1

Фильтры путей

Primary может выборочно не отдавать конкретные хранилища или пространства имён конкретному secondary. Фильтры настраиваются для каждого secondary по id:

• deny — реплицировать всё, кроме перечисленных путей.
• allow — реплицировать только перечисленные пути.

Режим по умолчанию — allow.

# Запретить хранилище blocked/ для sec-1.
curl --header "X-Vault-Token: ${VAULT_TOKEN}" --request POST --data '{"mode":"deny","paths":["blocked/"]}' "${PRIMARY_ADDR}/v1/sys/replication/performance/primary/paths-filter/sec-1"

# Прочитать фильтр.
curl --header "X-Vault-Token: ${VAULT_TOKEN}" "${PRIMARY_ADDR}/v1/sys/replication/performance/primary/paths-filter/sec-1"

# Прочитать развёрнутый фильтр (реальные storage-префиксы, которые будут применены).
curl --header "X-Vault-Token: ${VAULT_TOKEN}" "${PRIMARY_ADDR}/v1/sys/replication/performance/primary/dynamic-filter/sec-1"

# Снять фильтр.
curl --header "X-Vault-Token: ${VAULT_TOKEN}" --request DELETE "${PRIMARY_ADDR}/v1/sys/replication/performance/primary/paths-filter/sec-1"

Изменение фильтра применяется вживую: при добавлении пути в deny (или удалении из allow) primary стримит инвалидацию и secondary удаляет ранее разрешённые данные; при обратном изменении данные реплицируются заново.

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

Операции управления

В таблице перечислены команды управления межкластерной репликацией:

Примечания:

• revoke-secondary также удаляет фильтр этого secondary.
• Для update-primary, когда у нового primary новый идентификатор кластера (например, это повышенный бывший secondary), используйте token-метод со свежим activation-токеном нового primary. Address-метод (primary_cluster_addr) применим только если primary сохранил прежний идентификатор.