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