Multi-Region Disaster Recovery: архітектура, реплікація та тестування

Чому мультирегіональний DR ламається на реплікації

Резервний регіон зазвичай з'являється раніше, ніж перевіряють його працездатність. Реплікацію налаштовано в один бік: зміни йдуть з основного контуру в резервний, а зворотний потік ніхто не піднімає.

Поки обидва регіони живі, схема виглядає надійною — відставання репліки вимірюється секундами, статистика чиста.

При відмові регіону картина змінюється: резервний вузол стає основним, застосунок починає писати в нього, і ці записи вже нікуди не передаються.

Повернення колишнього регіону в роботу обертається розсинхроном реплікації — дві бази з різними даними, і рішення про те, чия версія правильна, ухвалюється вручну і під тиском.

Друга причина — спільна точка відмови за межами регіону. Сховище секретів, домен, служба автентифікації, черга фонових завдань часто живуть в одному місці.

Резервний контур піднімається, але взяти облікові дані до власної бази йому ніде: вони лежать у тому самому регіоні, який недоступний.

І третє — ручний розбір перемикання. Регламент, який ніхто не проганяв повністю, складається з кроків, що залежать від стану основного регіону, а звіритися з ним уже не можна.

Поки інженери відновлюють порядок дій, сервіс простоює, і час простою визначає не інфраструктура, а пам'ять конкретної людини.

Розбираємо, як кожен із цих сценаріїв закривається в архітектурі мультирегіонального DR: від двосторонньої реплікації до автоматичної перевірки перемикання.

Що дає георезервування: ефект у вимірюваних метриках

Резервування в одному регіоні не рятує від відмови майданчика: аварія у провайдера зв'язку або помилка конфігурації, що розійшлася по всіх вузлах, зупиняє сервіс на години.

Георезервування переносить роботу в другий регіон, але цінність дають не самі копії даних, а те, за який час і з якою втратою даних ми повернемося в роботу. Тому контур проєктуємо від цільових показників, а не від «поставимо репліку на всяк випадок».

Показники тягнуть у різні боки: синхронна реплікація в PostgreSQL скорочує точку збереження даних, але додає затримку на запис, асинхронна — швидша, зате при аварії губляться останні транзакції.

Сервіси розкладаємо за класами: платежам і статусам замовлень — строга точка збереження, аналітиці й кешам — швидкість.

Прибрані класи відмов важливіші за відсотки доступності. Геоконтур закриває відмову майданчика, розрив каналу між регіонами й помилку випуску, коли відкат одного регіону не зачіпає другий.

Залишаються помилки в даних і логіці: реплікація розносить їх по обох контурах, тому випуски ізолюємо й перевіряємо перед перемиканням.

Режими роботи мультирегіонального DR: холодний, теплий, активний

Режим резервування — це відповідь на два питання: скільки часу сервіс може бути недоступним і яку втрату даних бізнес вважає допустимою. Від цих цифр залежать і схема реплікації, і режими перемикання трафіку, і те, чи доведеться інженеру запускати перемикання вручну вночі. Нижче — чотири режими, між якими реально вибирають, та їхні обмеження.

Різниця в обмеженнях тут важливіша за різницю в назвах: активний резерв упирається в консистентність даних, теплий — у швидкість масштабування, холодний — у час розгортання.

На практиці режими комбінують: критичний контур тримають в активному-активному, звітність та архіви — на холодному резерві, а загальний сценарій перемикання перевіряють цілком, інакше зв'язка ламається на стику.

Етапи впровадження: від аудиту до навчальних перемикань

Роботи йдуть послідовно, бо кожен наступний етап спирається на артефакти попереднього: перемикання трафіку не починають, поки не описано склад сервісів та їхні залежності, а навчання не проводять до того, як репліку підтверджено звіркою даних. Нижче — порядок, за яким ми ведемо впровадження мультирегіонального DR.

1. Аудит інфраструктури. Інвентаризуємо сервіси, бази, черги, зовнішні інтеграції та зв'язки між ними, присвоюємо кожному клас критичності й цільовий час відновлення. Результат — карта залежностей, за якою видно, що не можна піднімати окремо.
2. Схема реплікації. Вирішуємо, що переносимо синхронно (транзакційні дані), а що асинхронно (логи, кеш, аналітика), і фіксуємо допустиму втрату даних для кожного класу. Окремо перевіряємо, як поводиться відставання репліки під піковим навантаженням.
3. Підготовка другого регіону. Розгортаємо ідентичний контур з опису інфраструктури: мережеві правила, доступи, секрети, конфігурація сервісів. Регулярна звірка ловить розходження, які накопичуються при ручних правках.
4. Перемикання трафіку. Описуємо порядок підняття сервісів з урахуванням залежностей і спосіб переведення навантаження через керування доменними записами та балансувальник. Перед прийманням трафіку — перевірка готовності вузлів.
5. Перевірка цілісності. Звіряємо обсяги та контрольні суми даних, проганяємо критичні сценарії на репліці, фіксуємо розходження й вирішуємо, які з них допустимі, а які блокують перемикання.
6. Навчальні перемикання. Проводимо за регламентом, із заміром часу від сигналу до приймання навантаження та зворотним поверненням. Кожне навчання завершується розбором і правками регламенту — він живе, а не лежить у документації.
7. Передавання в експлуатацію. Чергові інструкції, чек-листи, автоматизація повторюваних кроків і явні зони відповідальності.

Регламент перемикання оновлюється після кожного навчання — інакше він розходиться з реальною інфраструктурою вже за пару змін.

Комплект документації, схем і регламентів перемикання

Аварійне перемикання регіону — це не про витримку чергового, а про документ, за яким він діє.

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

• Схеми реплікації — напрямок потоків по кожному сховищу, режим синхронний чи асинхронний, допустиме відставання й точки, де аварійне перемикання обриває ще не донесені дані.
• Карта залежностей — що зав'язано на основний контур: черги, зовнішні сервіси, записи в системі імен, сховище секретів, і в якому порядку це піднімається в резервному регіоні.
• Регламент перемикання — хто ухвалює рішення, за якими критеріями запускається процедура, послідовність кроків, контрольні тайм-аути, точка неповернення й умови повернення назад.
• Політики доступу — ролі на період аварії, порядок видавання розширених прав, де лежать ключі та як вони працюють при недоступному основному контурі.
• Описи конфігурацій обох регіонів — інфраструктура як код, щоб резервний стенд відтворювався збіркою, а не збирався руками з пам'яті.
• Чек-листи чергової зміни — що перевірити до перемикання, під час і після, з відмітками та відповідальним за кожним пунктом.
• Матриця звірки даних — які розходження вважаються допустимими після повернення, чим звіряємо і як наздоганяємо накопичене відставання.
• Протоколи навчань — сценарії, фактичні часи перемикання й список розходжень, які за підсумками закрили.

Комплект оновлюється разом з архітектурою: зміна схеми реплікації або додавання залежності без правки карти й регламенту вважається незавершеною роботою. Опишіть ваш контур — повернемося з оцінкою та планом.

Кейс: відновлення за хвилини замість годин простою

Клієнт — сервіс із цілодобовим трафіком в одному регіоні. Відновлення трималося на ручному сценарії: інженер піднімав вузли з нічних резервних копій, розгортав кластер PostgreSQL зі знімка й правил маршрутизацію балансувальника вручну.

На перших навчаннях вклалися в 6-8 годин, причому більш ніж половина пішла на очікування копії та звірку даних, а не на саму роботу. Знімок відставав на добу — частина підтверджених операцій губилася безповоротно.

Що знайшли під час розбору

• Реплікація була асинхронною без контролю відставання: про втрату даних дізнавалися вже після перемикання.
• Доступи й налаштування домену правили руками, кроки ніде не описані — результат залежав від того, хто чергує.
• Навчання проводили час від часу, тому час відновлення ніхто не вимірював і не покращував.

Що стало після

Налаштували потокову реплікацію між регіонами й винесли перемикання у перевірюваний сценарій, де маршрутизація змінюється однією операцією з автоматичною перевіркою здоров'я вузлів.

Резервні копії залишилися, але тепер слугують страховкою від логічних помилок, а не основним планом.

На серії навчань час відновлення скоротився до 15 хвилин, а обсяг втрачуваних даних — до останніх секунд.

Окремо відпрацювали зворотне перемикання в початковий регіон: воно проходить без повторної синхронізації з нуля й без зупинки приймання операцій, тоді як раніше було найризикованішим етапом. Заміри після кожного навчання фіксуються, і деградація стає видною одразу.

Чим відрізняється планове перемикання від аварійного?

Планове й аварійне перемикання розв'язують одне завдання, але умови в них протилежні. У плановому сценарії час є: вікно узгоджено, репліку перевірено, застосунки зупиняються керовано.

В аварійному рішення ухвалюється за секунди за сигналом автоматики, а стан даних на момент відмови невідомий.

Планове перемикання йде за регламентом: звіряємо відставання репліки, переводимо застосунки в режим лише читання, гасимо фонові завдання, дочікуємося нульового лагу й перемикаємо трафік.

Відставання й підтвердження запису видно із системних представлень СУБД, наприклад PostgreSQL. Основний регіон залишається в гарячому резерві — повернутися можна тим самим регламентом.

Аварійне перемикання запускається автоматикою при недоступності регіону або черговим, якщо автоматика мовчить. Частина підтверджених операцій може не дійти до репліки — заради доступності сервісу свіжими записами жертвують, а старий регіон потім синхронізують вручну за журналами.

Критерії вибору режиму зводяться до трьох перевірок:

• чи зберігається канал керування основним регіоном, а не «чи впав моніторинг»;
• чи вкладається відставання репліки в допустиму втрату;
• чи є кворум, щоб не отримати два незалежні основні регіони.

Практичне правило: поки регіон керований і лаг у допуску — перемикаємося планово. В автоматики є поріг: при великому відставанні вона не піднімає другий регіон, а лише будить чергового.

Кожне аварійне перемикання потім програється як планове — інакше процедура повернення залишається неперевіреною.

Технічні сумніви: реплікація, затримки, навчання

Чотири сумніви найчастіше спливають на захисті архітектури: як реплікація впливає на основний контур, як часто проводити навчання, чим підтверджується цілісність даних і що відбувається при поверненні трафіку.

Як часто потрібні навчання?

Повне перемикання — раз на квартал, окремі сценарії (втрата зони, відмова сховища, деградація каналу) — щомісяця. Кожен прогін дає замір часу перемикання й відновлення, розходження розбираємо з власником сервісу до наступного навчання.

Чим підтверджується цілісність даних?

Не фактом завершення копіювання, а звіркою: контрольні суми блоків, повторний прогін журналу операцій на резервному контурі, порівняння агрегатів у ключових таблицях. Розходження — стоп-сигнал, перемикання не відкриваємо, поки не знайдено причину.

Що з конфліктами при поверненні трафіку?

Тримаємо один регіон на запис: у резервному контурі запис відкривається лише на час аварії, а після відновлення зміни переносяться в основний до повернення трафіку. Дві гілки даних не зустрічаються, тому розбір конфліктів не потрібен.

Обговорімо вашу схему резервування та режим перемикання

Оцінка й план з мультирегіонального DR тримаються на конкретиці: без вихідних даних виходить типове рішення, яке розсипається на першому ж перемиканні. На старті потрібен короткий набір ввідних — зазвичай він збирається за одну-дві зустрічі з вашою командою.

• Доступи до середовищ: другий регіон або можливість його підняти, права на розгортання, сховище секретів, засоби автоматизації — достатньо, щоб прогнати повний цикл навчання.
• Схема сервісів і зв'язків: що критично для бізнесу, які бази реплікуються, де черги, зовнішні виклики та спільні залежності.
• Цільові показники відновлення за кожним сервісом — допустима точка й допустимий час простою. Від них залежить режим реплікації: синхронний, асинхронний або періодичні знімки.
• Обмеження: вимоги до розміщення даних, пропускна здатність каналів між регіонами, періоди, коли перемикання заборонено.
• Вікно для навчань, узгоджене з бізнесом: коли можна перевести трафік у другий регіон і повернути назад.
• Відповідальний за приймання та перелік перевірок, за якими він підтверджує результат: доступність, цілісність даних, відгук під навантаженням.

Отримавши це, повернемося з оцінкою та планом: режим реплікації за сервісами, етапи, сценарії навчань, критерії приймання. Пропонуємо обговорити завдання — частина ввідних зазвичай уже є в документації, решту доберемо разом.