#Переключение RabbitMQ workload на резервную среду и возврат обратно

В этом руководстве описывается runbook на стороне приложения для переключения workload с основной среды RabbitMQ на подготовленную резервную среду, а также для возврата workload обратно после того, как основная площадка снова станет доступна.

В этом документе предполагается, что топология, управление доступом, TLS-материалы и механизмы перемещения сообщений уже подготовлены. Он не заменяет проектирование disaster recovery. Используйте его вместе с DR-документами для конкретного workload, например RabbitMQ Disaster Recovery with Federated Exchanges.

#Предварительные требования

Перед переключением workload убедитесь, что выполнены следующие условия:

1. В резервной среде созданы необходимые virtual hosts, users, permissions, exchanges, queues, bindings, policies и объекты Kubernetes Secret.
2. У приложения есть документированный способ переключать endpoints брокера, credentials и TLS trust material.
3. Вы знаете, является ли событие плановым failover, внеплановым failover или failback после восстановления.
4. Вы знаете, как сообщения реплицируются или воспроизводятся между площадками, например с помощью Federation, Shovel, двусторонней публикации на уровне приложения или повторного воспроизведения на уровне бизнеса.

#Плановый Failover

Используйте плановый failover, когда основная площадка по-прежнему доступна и вы можете контролировать порядок переключения.

#1. Уменьшите число новых записей в основную среду

По возможности остановите или дренируйте producers до переключения consumers. Это ограничивает расхождение сообщений в окно переключения.

#2. Проверьте резервную среду

Проверьте резервный cluster перед переводом трафика:

• RabbitMQ Pods находятся в состоянии ready.
• Фаза RabbitmqCluster равна Active.
• Существуют необходимые users, virtual hosts и permissions.
• Существуют необходимые exchanges, queues, bindings и policies.
• Допустимы актуальность backlog очередей и lag репликации для данного workload.
• TLS listeners, если они используются, соответствуют конфигурации клиента.

#3. Переключите consumers

Сначала направьте consumers в резервную среду, если требуется, чтобы резервная площадка начала дренировать реплицированный backlog до перенаправления новых producers.

#4. Переключите producers

После того как consumers готовы в резервной среде, обновите producers так, чтобы они публиковали сообщения на адреса и с credentials резервного RabbitMQ.

#5. Проверьте поток сообщений в резервной среде

Убедитесь, что:

• Producers успешно публикуют сообщения.
• Consumers подключены и получают сообщения.
• Поведение backlog очередей соответствует ожиданиям.
• Аварии по диску и памяти отсутствуют.

#Внеплановый Failover

Используйте внеплановый failover, когда основная площадка недоступна или ее невозможно корректно дренировать.

#1. Оцените актуальность данных

Если используется асинхронная репликация, например Federation или Shovel, определите вероятный lag сообщений до запуска приложения в резервной среде.

#2. Запустите consumers с включенной idempotency

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

#3. Переключите producers на резервную среду

Обновите endpoint приложения, credentials и trust material так, чтобы использовать резервную среду.

#4. Отслеживайте backlog и аварии

Следите за глубиной очередей в резервной среде, lag consumers и авариями брокера, пока резервная площадка принимает workload.

#Процедура Failback

Failback — это отдельное контролируемое изменение. Не переключайте трафик обратно на основную площадку, пока основная среда не станет здоровой и ее топология не будет актуальной.

#1. Восстановите или проверьте основную среду

Перед failback проверьте на основной стороне следующее:

• Версия RabbitMQ и plugins соответствуют ожидаемому выпуску.
• Virtual hosts, users, permissions, exchanges, queues, bindings, policies и parameters настроены корректно.
• TLS certificates и объекты Kubernetes Secret актуальны.
• Направление replication или replay обновлено так, чтобы при необходимости заполнить основную площадку.

#2. Определите стратегию возврата сообщений

До обратного переключения трафика выберите один из следующих вариантов:

• Полностью дренировать backlog резервной среды, а затем переключить трафик.
• Заморозить producers, перенести оставшийся backlog, а затем переключить.
• Принять window повторного воспроизведения или дубликатов, специфичный для workload, и выполнить переключение в запланированной точке cutover.

#3. Сначала переключите consumers обратно

Переведите consumers первыми, если требуется, чтобы основная площадка начала дренировать восстановленный backlog до перенаправления новых producers.

#4. Затем переключите producers обратно

После того как consumers на основной площадке стабилизируются, перенаправьте producers обратно на основную площадку.

#5. Проверьте стабильное состояние

Убедитесь, что:

• Глубина очередей на основной площадке стабильна.
• Consumers больше не читают из резервной среды.
• Задачи replication или migration остановлены либо инвертированы в соответствии с DR design.
• Alerts и dashboards отражают новую активную площадку.

#Контрольный список проверки

Используйте следующий контрольный список как для failover, так и для failback:

#Связанная информация

• RabbitMQ Disaster Recovery with Federated Exchanges
• Manage RabbitMQ Definitions
• Check RabbitmqCluster Status