Автоматичний failover: налаштування перемикання при збої

Автоматичний failover: налаштування перемикання при збої сервера

Ми налаштовуємо автоматичний failover для вашого production-оточення, щоб при збої основного сервера трафік перемикався на резервний без участі людини. Мета — скоротити RTO (Recovery Time Objective) з «поки хтось не прокинеться» до 30–120 секунд. Для e-commerce або SaaS це різниця між втратою 5 хвилин виручки та години — зниження втрат до 90%. Наш досвід — 7 років у відмовостійких архітектурах, понад 40 проєктів із failover-схемами. Інженери мають сертифікати AWS і Linux, гарантуємо стабільну роботу.

Як працює автоматичний failover?

Failover може бути реалізований на різних рівнях стеку: DNS, балансувальник навантаження, віртуальні IP (VRRP) та рівень бази даних. Кожен підхід має свої trade-offs за швидкістю перемикання, складністю та вартістю.

DNS-рівень — найпростіший, але повільний. Health check перевіряє primary кожні 10–30 секунд. При падінні — змінюється DNS-запис на IP резервного сервера. Затримка складається з TTL запису та часу виявлення: 60–300 секунд. Підходить для більшості веб-застосунків, де допустима пауза до 5 хвилин.

Load Balancer (AWS ALB/NLB, nginx upstream) — перемикання за 5–30 секунд, але вимагає обох серверів в одній хмарі або регіоні. Health check працює на рівні балансувальника.

VRRP / Keepalived — віртуальний IP переміщується між серверами при збої майстра за 2–5 секунд. Класика для on-premise та dedicated.

Database failover — окреме завдання. Застосунок має знати про новий primary DB. Patroni (PostgreSQL), MHA (MySQL), AWS RDS Multi-AZ вирішують це автоматично.

DNS vs балансувальник: що обрати?

DNS failover повільніший за балансувальник у 10 разів, але його простіше налаштувати і він не прив’язаний до конкретного провайдера.

Приклад реалізації на 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 лише при повній працездатності. Наші інженери налаштовують такий check з урахуванням специфіки вашого стеку.

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?

Регулярні навчання — обов’язково. Failover, який не тестувався, швидше за все не спрацює в потрібний момент. Наш стандартний протокол перевірки:

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

Цільові метрики: detection time < 30 с, switch time < 60 с, total RTO < 120 с.

Що входить у налаштування failover під ключ

• Аналіз поточної архітектури та вимог до відмовостійкості
• Проєктування схеми failover (DNS, балансувальник, VRRP, DB)
• Налаштування health check-ів та моніторингу
• Реалізація синхронізації даних (реплікація БД, файлів, сесій)
• Розробка скриптів автоматичного перемикання
• Тестування сценаріїв збою та відновлення
• Документація та навчання вашої команди
• Підтримка на етапі експлуатації (опціонально)

Терміни налаштування

Точні терміни залежать від складності інфраструктури. Оцінимо ваш проєкт — зв'яжіться для консультації.

Проблема split-brain та її вирішення

Split-brain виникає, коли обидва сервери вважають себе primary. У Keepalived вирішується через fencing (STONITH) — при конфлікті слабкий вузол примусово вимикається. У PostgreSQL/Patroni — через DCS (etcd, Consul, ZooKeeper) як арбітр. Ми гарантуємо, що схема виключає цю ситуацію.

Моніторинг failover-подій

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

Отримайте консультацію — зв'яжіться з нами для обговорення вашого проєкту. Замовте налаштування failover та забезпечте відмовостійкість вашого сервісу.