Репликация для аварийного восстановления (disaster recovery)

Репликация для аварийного восстановления (DR, disaster recovery) держит горячий резервный кластер — полную копию хранилища primary вместе с локальными данными (токенами, арендами). DR-secondary не обслуживает клиентов (кроме распечатывания и небольшого служебного набора) и ждёт promote, чтобы принять нагрузку при отказе primary.

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

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

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

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

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

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

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

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

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

На кластере primary создайте activation-токен для DR secondary:

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

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

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

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

На кластере secondary включите DR-репликацию в режиме secondary с activation-токеном:

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

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

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

В примере:

• <WRAPPING_TOKEN> — токен обёртывания из поля wrap_info.token, полученный на шаге 2;
• <PRIMARY_API_ADDR> — API-адрес кластера primary;
• <PRIMARY_CA_FILE> — путь к CA-сертификату primary в формате PEM на сервере secondary.

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

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

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

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

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

Статус показывает mode, state, connection_state, last_wal и last_remote_wal. DR-secondary догнал primary, когда его last_wal дошёл до last_remote_wal.

Повышение DR-secondary

Повышение требует DR operation token — его выпускают через церемонию с долями ключей и одноразовым паролем (OTP).

1. Запустите церемонию. В ответе возвращаются nonce и otp:

   curl --request PUT --data '{}' "${SECONDARY_ADDR}/v1/sys/replication/dr/secondary/generate-operation-token/attempt"

2. Внесите долю ключа. Повторите для каждой требуемой доли:

   curl --request PUT --data '{"key":"<KEY_SHARE>","nonce":"<NONCE>"}' "${SECONDARY_ADDR}/v1/sys/replication/dr/secondary/generate-operation-token/update"

   В команде <KEY_SHARE> — доля ключа распечатывания или ключа восстановления, <NONCE> — значение nonce из предыдущего шага.

   Когда complete становится true, в ответе появляется encoded_token. Расшифруйте его с помощью otp, чтобы получить DR operation token.

3. Повысьте secondary с помощью DR operation token:

   curl --request POST --data '{"dr_operation_token":"<DR_OPERATION_TOKEN>"}' "${SECONDARY_ADDR}/v1/sys/replication/dr/secondary/promote"

   В команде <DR_OPERATION_TOKEN> — DR operation token из предыдущего шага.

После promote бывший secondary становится активным DR primary и обслуживает клиентов.

Возврат прежнего primary

После аварийного переключения в кластере уже есть активный primary — повышенный secondary. Прежний primary нельзя просто запустить обратно как primary, иначе в кластере окажется два primary. Вместо этого подключите его к новому primary как DR secondary.

1. На новом primary выпустите activation-токен: d8 stronghold write sys/replication/dr/primary/secondary-token id=<SECONDARY_ID>. Activation-токен находится в поле wrap_info.token ответа.
2. Если прежний primary ещё считает себя primary, понизьте его: d8 stronghold write -force sys/replication/dr/primary/demote. После demote прежний primary становится DR secondary.
3. На прежнем primary выпустите DR operation token. Выполните шаги 1 и 2 из раздела «Повышение DR-secondary», указав адрес прежнего primary.
4. Подключите прежний primary к новому primary и передайте DR operation token: d8 stronghold write sys/replication/dr/secondary/update-primary token=<ACTIVATION_TOKEN> dr_operation_token=<DR_OPERATION_TOKEN>.

В командах:

• <SECONDARY_ID> — идентификатор DR secondary на новом primary;
• <ACTIVATION_TOKEN> — activation-токен из шага 1;
• <DR_OPERATION_TOKEN> — DR operation token из шага 3.

Используйте именно token-метод: у нового primary другой идентификатор кластера, и primary_cluster_addr для него не подойдёт.

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

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

Учитывайте следующее:

• demote понижает DR primary до отключённого DR secondary, сохраняя cluster ID и локальные данные, — узел готов переподключиться без обнуления.
• update-primary выполняется на DR secondary и требует DR operation token.
• Плановое переключение: demote на текущем primary, promote на резерве, затем update-primary, чтобы вернуть прежний primary как secondary. Подробнее — в разделе «Возврат прежнего primary».

Дополнительные ресурсы

• Регулярные учения по аварийному восстановлению
• Примеры использования