Налаштування DR-сайту (Hot/Warm/Cold Standby)

Налаштування DR-сайту (Hot/Warm/Cold Standby)

Компанія втрачає десятки тисяч доларів за годину простою — це тригер для впровадження DR. Ми проєктуємо резервні майданчики з нуля: від вибору моделі до навчань. Наші інженери мають сертифікації AWS і досвід відновлення після збоїв у клієнтів із fintech та e-commerce. Вибір між Hot, Warm і Cold Standby — це не технічне, а фінансове питання з технічними обмеженнями. Чим швидше потрібно відновитися, тим дорожче обходиться резервний майданчик. Завдання інженера — запропонувати бізнесу реальні варіанти з конкретними цифрами по RTO та вартості, а не просто спроєктувати «правильне» за підручником рішення.

Як вибрати модель резервування?

Визначальні фактори — допустимий час простою (RTO) та втрати даних (RPO). Згідно з Wikipedia, RTO та RPO — ключові метрики DR. Чим менший RTO, тим дорожча інфраструктура. Ми допомагаємо знайти баланс: оцінюємо критичність сервісів, вартість downtime та бюджет.

Hot Standby: дзеркало в реальному часі

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

Архітектура для хмари: активний/пасивний кластер у двох регіонах із синхронною реплікацією БД та AWS Global Accelerator або Cloudflare для DNS-failover.

# hot-standby/rds.tf
resource "aws_db_instance" "primary" {
  identifier = "prod-primary"
  engine = "postgres"
  engine_version = "15.4"
  multi_az = true # всередині одного регіону
  deletion_protection = true
  backup_retention_period = 7
  tags = {
    Role = "primary"
  }
}

resource "aws_db_instance" "dr_replica" {
  identifier = "prod-dr-replica"
  # Read replica в DR-регіоні — при failover promote до master
  replicate_source_db = aws_db_instance.primary.arn
  availability_zone = "eu-west-1a"
  # При promote ця репліка стане новим master
  auto_minor_version_upgrade = false
  tags = {
    Role = "dr-hot-standby"
  }
}

Ціна Hot Standby — приблизно подвоєння вартості інфраструктури. Для більшості стартапів це надмірно. Виправдано для fintech, healthcare, e-commerce із втратою понад $10K/год при downtime.

Warm Standby: баланс вартості та RTO

Warm Standby — DR-інфраструктура існує, але працює в скороченому обсязі. База даних реплікується, але з невеликим лагом. Сервери додатків вимкнені або працюють у режимі мінімальної потужності. При активації DR потрібно запустити інстанції, застосувати pending зміни конфігурації, переключити DNS.

RTO: від 15 хвилин до 2 годин залежно від складності. RPO: від кількох хвилин до 1 години.

---
# ansible/dr-warmup.yml — процедура прогріву DR-сайту
---
- name: Warm up DR site
  hosts: dr_site
  become: yes
  tasks:
    - name: Start application servers
      systemd:
        name: "{{ item }}"
        state: started
      loop:
        - app-server
        - worker
        - nginx
    - name: Promote PostgreSQL replica
      command: |
        su - postgres -c "pg_ctl promote -D /var/lib/postgresql/data"
      when: promote_db | bool
    - name: Update DNS to DR endpoint
      community.aws.route53:
        state: present
        zone: company.com
        record: app.company.com
        type: A
        ttl: 60
        value: "{{ dr_lb_ip }}"
        overwrite: yes
    - name: Run health checks
      uri:
        url: "https://app-dr.company.com/health"
        status_code: 200
        retries: 10
        delay: 30

Warm Standby зазвичай коштує 20–40% від вартості продакшн-інфраструктури. Це найпоширеніший вибір для компаній із SLA 99.9%.

Cold Standby: мінімальні витрати, максимальний RTO

Cold Standby — DR-інфраструктури в повному сенсі не існує. Є бекапи, документація з розгортання нового оточення та Terraform-конфігурація. При активації DR інфраструктура створюється з нуля, дані відновлюються з бекапів.

RTO: від 4 до 24 годин. RPO: відповідає частоті бекапів, зазвичай 1–24 години.

#!/bin/bash
# dr-coldstart.sh — скрипт холодного старту DR
set -euo pipefail

echo "=== DR Cold Start initiated at $(date) ==="

# Крок 1: Підняти інфраструктуру через Terraform
cd /opt/terraform/dr-site
terraform init -backend-config="bucket=company-tf-state-dr"
terraform apply -auto-approve -var="environment=dr"

# Крок 2: Відновити дані з останнього бекапу
LATEST_BACKUP=$(aws s3 ls s3://company-backups/db/ \
  --recursive | sort | tail -1 | awk '{print $4}')
aws s3 cp "s3://company-backups/$LATEST_BACKUP" /tmp/db-restore.dump

# Крок 3: Відновити БД
pg_restore \
  --host="${DR_DB_HOST}" \
  --username=postgres \
  --dbname=production \
  --jobs=8 \
  /tmp/db-restore.dump

# Крок 4: Переключити DNS
./scripts/switch-dns-to-dr.sh

echo "=== DR Cold Start completed at $(date) ==="

Cold Standby підходить для некритичних сервісів або компаній із дуже обмеженим бюджетом на DR. Важно перевіряти, що Terraform-конфіги актуальні та terraform apply дійсно працює — інакше в момент катастрофи виявиться, що state роз'їхався з реальністю півроку тому.

Що входить у проєктування DR-сайту?

Ми надаємо:

• Аудит поточної інфраструктури та виявлення критичних сервісів.
• Розрахунок RTO/RPO та вибір моделі Standby.
• Архітектуру DR-сайту з блок-схемами.
• Реалізацію через Terraform та Ansible (код у вашому репозиторії).
• Налаштування реплікації даних (БД, файли, конфіги).
• Документацію процедур активації та ролей команди.
• Проведення першого навчання зі звітом.
• Підтримка після впровадження: консультації та доопрацювання.

Все це — під ключ: від ідеї до працюючого DR, готового до тестування.

Вибір моделі: чек-лист

Чому тестування критичне?

Без навчань DR-сайт — це теоретична конструкція. Перше тестування ми проводимо протягом місяця після введення. Під час навчання перевіряємо: запуск інфраструктури, відновлення даних, перемикання DNS, час відгуку. Помилки фіксуємо та усуваємо. Наш досвід показує: навіть при ідеальній документації перший запуск виявляє 5–10 неврахованих проблем.

Процес проєктування та реалізації

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

На основі вимог і бюджету вибираємо модель Standby. Проєктуємо архітектуру DR-сайту, описуємо в Terraform. Реалізуємо реплікацію даних. Документуємо процедури активації. Проводимо перше тестування.

Без тестування DR-сайт — це теоретична конструкція. Перше навчання потрібно провести протягом місяця після введення в експлуатацію.

Орієнтири за термінами

Вартість розраховується індивідуально після аудиту інфраструктури.

Оцінимо ваш проєкт — напишіть нам. Гарантуємо працездатність DR за умови щорічних навчань. За 10+ років ми реалізували понад 40 проєктів з відновлення після збоїв.