Налаштування автоматичного 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 переміщується між серверами при падінні master. Переключення за 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-реплікація). Лаг реплікації моніторится,Alert при перевищенні 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.