Автоматичний 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 та забезпечте відмовостійкість вашого сервісу.