Налаштування резервного дата-центру (DR Site) для веб-додатку
DR Site — це повноцінна копія інфраструктури в окремому фізичному або хмарному дата-центрі, готова прийняти трафік при катастрофічному сбою основної площадки. Термін «резервний дата-центр» охоплює різні рівні готовності: від cold standby (кілька годин на піднімання) до hot standby (хвилини).
Класифікація DR Site за готовністю
Cold Standby. Інфраструктура не запущена. Дані реплікуються, конфігурація зберігається в IaC. При сбою: піднімити окремення з Terraform → відновити дані з резервної копії → запустити додаток. RTO: 2-8 годин.
Warm Standby. Базова інфраструктура запущена у зменшеному розмірі (1 інстанс замість 10). Дані актуальні через реплікацію. При сбою: масштабувати до production-розміру → переключити DNS. RTO: 15-60 хвилин.
Hot Standby. Повна копія інфраструктури працює постійно. Дані синхронізовані з лагом < 1 хвилини. При сбою: переключити DNS/балансувальник. RTO: 1-5 хвилин.
Вибір місцезнаходження DR Site
Ключові вимоги:
- Фізично незалежна електромережа та інтернет-канали
- Мінімум 100 км від основної площадки (захист від регіональних катастроф)
- Відповідність законодавству (дані користувачів з РФ — у РФ, GDPR для Європи)
Варіанти:
- Другий AWS/GCP/Azure регіон (найпростіше)
- Інший хмарний провайдер (захист від vendor outage)
- Власний або орендований co-location (для regulated industries)
Репліцірування даних
PostgreSQL → DR Site: Streaming replication з асинхронним standby у DR. Для критичних даних — synchronous_commit = remote_apply (гарантує, що при сбою primary дані на standby, але збільшує затримку запису).
Моніторинг лагу репліцірування:
SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;
Alert при лаге > 30 секунд.
Файлові сховища:
- S3 Cross-Region Replication (AWS) — автоматично, RPO < 15 хвилин
- Rclone sync за розкладом — для об'єктів, які рідко змінюються
- Lsyncd для realtime синхронізації файлової системи між серверами
Redis: Redis Sentinel з репліцією у DR або Redis Cluster з geo-distribution.
Infrastructure as Code для DR
Весь DR Site описується в Terraform. Основне та резервне оточення — різні workspace або окремі директорії конфігурації, параметризовані через змінні:
module "app_cluster" {
source = "./modules/app"
region = var.region
instance_type = var.dr_mode ? "t3.medium" : "c6i.2xlarge"
replica_count = var.dr_mode ? 1 : 5
}
Cold standby: terraform apply тільки при активації DR. Warm standby: terraform apply одразу з dr_mode = true.
Процедура активації DR Site
Документований runbook з точними командами — не загальними словами, а конкретними кроками:
- Підтвердити сбой основної площадки (не хибна тривога)
- Оголосити DR-інцидент, призначити інцидент-менеджера
- Перевірити лаг репліцірування БД перед переключенням
- Якщо warm/hot: виконати promote БД-реплики (
pg_promote()) - Оновити DNS (Route 53 / Cloudflare) на DR-адреси
- Перевірити працездатність через DR Site
- Повідомити команду та, при необхідності, користувачів
- Зафіксувати час RTO
Мережева зв'язність
Між основною площадкою та DR Site потрібен виділений канал для репліцірування даних:
- AWS VPC Peering або Transit Gateway (всередину AWS)
- AWS Direct Connect / GCP Interconnect (з on-premise у хмару)
- Site-to-site VPN (бюджетний варіант, менш надійний)
Канал репліцірування повинен бути ізольований від користувацького трафіку — пікове навантаження додатку не повинно впливати на реплікацію.
Вартість DR Site
| Тип | Постійні видатки | Приклад (AWS) |
|---|---|---|
| Cold Standby | Сховище + реплікація | $50-200/місяць |
| Warm Standby | ~30% від prod | $500-2000/місяць |
| Hot Standby | ~80-100% від prod | $2000-8000/місяць |
Для більшості веб-додатків оптимальний warm standby: розумна вартість при RTO 30-60 хвилин.
Терміни реалізації
- Аналіз поточної інфраструктури та вибір стратегії — 2-3 дні
- Налаштування репліцірування даних — 3-7 днів
- Розгортання DR-інфраструктури у IaC — 5-10 днів
- Мережева зв'язність та безпека — 2-5 днів
- Процедури, runbook, тестування — 3-5 днів
Разом: 2-5 тижнів залежно від складності інфраструктури та типу DR.