Мультирегиональное аварийное восстановление для платформы NXLog в AWS

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

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

Для организаций, использующих NXLog Platform в AWS, стратегия аварийного восстановления (DR) в нескольких регионах предоставляет практичный способ поддержания непрерывности. Используя AWS Elastic Disaster Recovery (AWS DRS), вы можете непрерывно реплицировать развернутую платформу NXLog Platform в резервный регион AWS и восстанавливать ее по мере необходимости.

Этот подход описан в руководстве NXLog Multi-Region DR Guide for AWS и основан на блочной репликации, а не на содержании второго полнофункционального рабочего окружения NXLog.

Почему NXLog Platform отлично подходит для аварийного восстановления на блочном уровне

NXLog Platform — это контейнеризированная многокомпонентная платформа, работающая на Linux с использованием Podman. Ее архитектура включает:

• ClickHouse для хранения и аналитики логов
• PostgreSQL для метаданных
• HashiCorp Vault для управления секретами
• Постоянные данные конфигурации, сертификаты и данные приложений, хранящиеся на диске

При развертывании в AWS постоянные данные, используемые NXLog Platform, могут размещаться на томах Amazon EBS. Это делает блочную репликацию практичной стратегией аварийного восстановления. Вместо повторного развертывания платформы в другом регионе AWS DRS непрерывно реплицирует блоки, записываемые в хранилище исходного экземпляра, в промежуточную (staging) среду в регионе восстановления.

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

• повторно устанавливать NXLog Platform;
• вручную пересоздавать контейнеры;
• отдельно восстанавливать конфигурационные файлы;
• заново настраивать сертификаты и секреты;
• разворачивать с нуля базовую операционную систему.

Среда восстановления создается на основе реплицированного состояния исходного сервера.

Настройка непрерывной репликации с помощью AWS DRS

Базовая настройка требует установки агента репликации AWS DRS на экземпляр EC2, где запущен NXLog Platform. Общий порядок действий следующий:

1. Откройте консоль AWS DRS в основном регионе.
2. Сгенерируйте команду установки агента AWS DRS.
3. Выполните команду на экземпляре EC2 с NXLog Platform с правами root.
4. Дождитесь завершения первичной синхронизации.
5. Убедитесь, что сервер отображается со статусом Ready for recovery (Готов к восстановлению) и статусом репликации Healthy (В норме).

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

• TCP 1500 для передачи данных репликации
• TCP 443 для управляющего контура AWS DRS

Также следует убедиться, что все тома контейнеров NXLog Platform с постоянными данными размещены на Amazon EBS.

Настройка среды восстановления для NXLog Platform

Типового развертывания AWS DRS самого по себе недостаточно. Восстановленный экземпляр должен иметь сетевую связность, необходимую для нормальной работы NXLog Platform после переключения (failover). В частности, заранее настройте группу безопасности (security group) для экземпляра восстановления.

Необходимый входящий трафик

Среда восстановления должна разрешать:

• TCP 443 — веб-интерфейс HTTPS для NXLog Platform
• TCP 5514 — сбор логов с агентов NXLog
• TCP 5515 — управление агентами NXLog

Необходимый исходящий трафик

Экземпляру также необходим доступ к сервисам, требуемым для стандартной работы, включая:

• DNS: TCP/UDP 53
• SMTP: TCP 25, 465 или 587 для отправки уведомлений по электронной почте
• TCP 443 к порталу клиентов NXLog (Customer Portal) для проверки подписки и обновления шаблонов конфигурации

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

Тестируйте план аварийного восстановления до того, как он понадобится

Стратегия аварийного восстановления, которая ни разу не тестировалась — это лишь предположение. AWS DRS поддерживает проведение учений по восстановлению (recovery drills), позволяя запускать временные экземпляры без нарушения работы основной продуктивной среды. Регулярные проверки должны подтверждать работоспособность восстановленного экземпляра NXLog Platform.

Как минимум, следует проверить:

1. Контейнеры NXLog Platform

 На восстановленном экземпляре убедитесь, что требуемые контейнеры запущены: sudo podman ps Все необходимые контейнеры NXLog Platform должны присутствовать и находиться в рабочем состоянии.

2. Веб-интерфейс

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

• веб-интерфейс NXLog Platform доступен по протоколу HTTPS;
• администраторы могут успешно пройти аутентификацию;
• платформа функционирует в среде восстановления.

Регулярные учения также помогают измерить фактическое время восстановления и выявить проблемы с сетью, DNS, брандмауэром или контролем доступа до того, как они станут критическими.

Восстановление NXLog Platform после сбоя в регионе

Если основной регион AWS становится недоступен, процедура восстановления может быть выполнена с помощью AWS DRS. Типовая последовательность шагов при аварийном переключении:

1. Откройте консоль AWS DRS в регионе восстановления.
2. Выберите реплицированный исходный сервер NXLog Platform.
3. Запустите задание восстановления (recovery job).
4. Выберите подходящую точку восстановления (recovery point).
5. Запустите экземпляр восстановления.
6. Проверьте работу контейнеров и веб-интерфейса NXLog Platform.
7. Обновите записи DNS для перенаправления конечной точки сбора логов на восстановленный экземпляр.

Выбор правильной точки восстановления

Самая последняя точка восстановления обычно подходит для сбоев инфраструктуры, таких как отключение целого региона. Однако аварийное восстановление может быть связано и с инцидентами безопасности. Если исходная среда была скомпрометирована вирусом-вымогателем или в результате другой разрушительной атаки, восстановление из более ранней заведомо исправной точки может быть предпочтительнее отката к самому последнему состоянию. Это делает восстановление на определенный момент времени (point-in-time recovery) полезным не только при региональных сбоях доступности, но и в сценариях реагирования на киберинциденты.

Обратное переключение (Failback) после восстановления основного региона

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

Типовой процесс обратного переключения включает:

1. Стабилизацию исходной среды.
2. Запуск обратной репликации.
3. Запуск экземпляра обратного переключения.
4. Проверку работоспособности NXLog Platform.
5. Перенаправление DNS обратно на основную среду.

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

Почему этот подход важен для безопасности и соответствия стандартам

Инфраструктура управления логами является частью архитектуры безопасности и соответствия нормативным требованиям организации. Региональный сбой, прерывающий сбор логов, может привести к пробелам в:

• мониторинге безопасности;
• расследовании инцидентов;
• аудиторских следах;
• отчетности по соответствию стандартам;
• оперативном поиске и устранении неполадок.

Поддержание второго полностью функционального окружения управления логами может быть затратным и сложным с операционной точки зрения. Благодаря репликации на блочном уровне среда восстановления может находиться в экономичном промежуточном состоянии (staging) до тех пор, пока она действительно не понадобится. В результате формируется архитектура аварийного восстановления, которая защищает всю платформу NXLog Platform без необходимости постоянного содержания двух полноценных продуктивных сред.

Ключевые аспекты для внедрения

Перед развертыванием архитектуры в продуктивной среде организациям следует определить:

• RPO (Recovery Point Objective): допустимый объем потери последних данных логов;
• RTO (Recovery Time Objective): допустимое время восстановления сбора логов и доступа к ним;
• процедуры аварийного переключения DNS;
• необходимые правила брандмауэра и групп безопасности;
• процедуры выбора точки восстановления;
• доступ администраторов к региону восстановления;
• график регулярных проверок аварийного восстановления;
• процедуры обратного переключения (failback).

Технический механизм репликации — это лишь часть аварийного восстановления. Операционные процедуры также должны быть тщательно документированы и протестированы.

Итог

Данные логов представляют ценность только тогда, когда они доступны в самый нужный момент. Для организаций, использующих NXLog Platform на AWS, сервис AWS Elastic Disaster Recovery предоставляет практическую основу для устойчивости в нескольких регионах. Реплицируя экземпляр NXLog Platform на блочном уровне, компании могут поддерживать готовое к восстановлению окружение управления логами без развертывания второго полноценного продуктивного кластера.

Итоговая архитектура проста:

Репликация → Восстановление → Проверка → Перенаправление → Обратное переключение.

Для организаций со строгими требованиями к безопасности, аудиту или доступности такой подход помогает защитить непрерывность передачи телеметрии безопасности, сохраняя при этом операционные и инфраструктурные расходы на аварийное восстановление под контролем. Компания Softprom, являясь официальным дистрибьютором NXLog, помогает организациям оценить варианты развертывания NXLog Platform и спроектировать архитектуру управления логами, соответствующую их требованиям к безопасности, аудиту и аварийному восстановлению.