Мультирегіональне аварійне відновлення для платформи 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 та спроєктувати архітектуру управління логами, що відповідає їхнім вимогам до безпеки, аудиту та аварійного відновлення.