Настройка автоматического Failover при сбое основного сервера

Настройка автоматического Failover при сбое основного сервера

Автоматический failover — это переключение трафика на резервный сервер без участия человека. Цель: сократить RTO (Recovery Time Objective) с «пока кто-то не проснётся» до 30-120 секунд. Для e-commerce или SaaS это разница между потерей 5 минут и потерей часа выручки.

Уровни failover и где каждый применяется

DNS-уровень (Route 53 Health Checks, Cloudflare Failover). Самый простой вариант. Health check проверяет primary каждые 10-30 секунд. При падении — меняет DNS-запись на IP резервного сервера. Задержка: TTL + время обнаружения = 60-300 секунд. Подходит для большинства веб-приложений.

Load Balancer (AWS ALB/NLB, nginx upstream). Health check на уровне балансировщика, переключение за 5-30 секунд. Требует обоих серверов в одном облаке или регионе.

VRRP / Keepalived (bare metal / VPS). Виртуальный IP перемещается между серверами при сбое мастера. Переключение за 2-5 секунд. Классика для on-premise и dedicated.

Database failover. Отдельная задача — приложение должно знать о новом primary DB. Patroni (PostgreSQL), MHA (MySQL), AWS RDS Multi-AZ решают это автоматически.

Реализация на AWS Route 53

Route 53 Failover Policy:
  Primary record → 1.2.3.4 (основной сервер)
    Health check: HTTP GET /health, port 443
    Failure threshold: 3 consecutive failures
    Request interval: 10 seconds
  Secondary record → 5.6.7.8 (резервный сервер)
    Evaluate target health: Yes

Эндпоинт /health на приложении должен проверять реальное состояние: БД доступна, кеш работает, дисковое пространство не исчерпано. Возвращать 200 только при полной работоспособности.

Keepalived для bare metal / VPS

# /etc/keepalived/keepalived.conf на PRIMARY
vrrp_script check_app {
    script "/usr/local/bin/check_app.sh"
    interval 5
    weight -20
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        192.168.1.100/24
    }
    track_script {
        check_app
    }
}

Скрипт check_app.sh проверяет доступность приложения локально. При двух неудачных проверках подряд — BACKUP-сервер с приоритетом 90 захватывает виртуальный IP.

Синхронизация данных между серверами

Failover бессмысленен без актуальных данных на резервном сервере:

• БД: репликация master-slave (PostgreSQL streaming replication, MySQL GTID-репликация). Лаг репликации мониторится, алерт при превышении 30 секунд
• Файлы: lsyncd (realtime rsync) или S3-совместимое хранилище как общая точка
• Сессии: Redis с репликацией или sticky sessions через балансировщик
• Конфигурация: Ansible pull с общего git-репозитория

Тестирование failover

Регулярные учения — обязательны. Failover, который не тестировался — это failover, который не работает в нужный момент.

Протокол проверки:

1. Убедиться, что мониторинг фиксирует исходное состояние
2. Симулировать сбой: systemctl stop nginx или iptables -I INPUT -p tcp --dport 80 -j DROP на primary
3. Зафиксировать время до переключения
4. Проверить работоспособность через резервный сервер
5. Восстановить primary, проверить обратное переключение

Целевые метрики: detection time < 30s, switch time < 60s, total RTO < 120s.

Состояние «split-brain» и как его избежать

Проблема: оба сервера считают себя primary. В Keepalived решается через fencing (STONITH) — при конфликте слабый узел принудительно выключается. В PostgreSQL/Patroni — через DCS (etcd, Consul, ZooKeeper) как арбитр.

Сроки настройки

• DNS failover (Route 53 / Cloudflare) — 1-2 дня
• Keepalived + синхронизация данных — 3-5 дней
• Полная схема с DB failover (Patroni) — 5-10 дней
• Тестирование и документация — 1-2 дня

Мониторинг failover-событий

Каждое переключение — это инцидент, который нужно расследовать. Alertmanager или PagerDuty фиксируют событие. Автоматически создаётся тикет в Jira/Linear. Постфактум — root cause analysis: почему упал primary.