Настройка 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 эта реплика станет новым мастером
  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 при условии ежегодных учений. За 5+ лет мы реализовали более 50 проектов по восстановлению после сбоев.