Введение: почему отказоустойчивость сети и DNS критична для распределенных систем
Единая точка отказа (SPOF) - это компонент, выход из строя которого приводит к полной недоступности сервиса. В распределенных системах таких точек может быть несколько: один DNS-сервер, один маршрутизатор, один интернет-провайдер. Пока все работает, риски не видны. Первый же сбой показывает, насколько хрупкой была архитектура.
По данным Uptime Institute, около 30% всех инцидентов с недоступностью сервисов связаны с сетевыми проблемами, а не с отказами самих серверов. DNS-сбои в 2026 году уже приводили к массовым простоям крупных платформ: пользователи не могли разрешить имена, хотя бэкенд оставался полностью работоспособным. Это дорого обходится бизнесу: каждая минута простоя для высоконагруженного сервиса может стоить тысячи долларов.
Эта статья дает практические методы устранения единых точек отказа на трех уровнях: DNS-инфраструктура, сетевой стек с виртуальным IP и исходящие каналы связи. Вы получите готовые конфигурации для keepalived, схемы резервирования DNS и способы балансировки трафика между провайдерами. Материал ориентирован на DevOps-инженеров и системных администраторов, которым нужно гарантировать высокую доступность своих систем.
Единые точки отказа в распределенных системах: что чаще всего выходит из строя
Прежде чем настраивать резервирование, нужно четко определить, какие компоненты инфраструктуры могут стать причиной полного отказа. Типичная картина для небольшой распределенной системы: один DNS-сервер, один маршрутизатор, один канал в интернет. Каждый из этих элементов - потенциальная точка отказа.
DNS как критическая единая точка отказа
DNS - это служба каталогов интернета. Клиент не может подключиться к сервису по имени, пока не получит IP-адрес. Если DNS-сервер недоступен, пользователи получают ошибку разрешения имени, даже если все серверы приложения работают нормально. Для них сервис просто не существует.
Кэширование на стороне клиента и промежуточных резолверов временно смягчает проблему: записи живут в кэше до истечения TTL. Но это не решение. Как только TTL истекает, запросы снова уходят на недоступный сервер. При TTL 300 секунд у вас есть максимум 5 минут, прежде чем пользователи начнут массово терять доступ. Для критичных сервисов это неприемлемо.
Отказ DNS-сервера может быть вызван разными причинами: аппаратный сбой, исчерпание ресурсов, DDoS-атака, ошибка конфигурации после обновления. В каждом случае последствия одинаковы: полная потеря доступности всех сервисов, использующих этот сервер для разрешения имен.
Сетевые компоненты: маршрутизаторы, коммутаторы, каналы связи
Маршрутизатор или коммутатор уровня агрегации - классическая единая точка отказа. Один такой узел может обслуживать целый сегмент сети: десятки серверов, систему хранения, резервные копии. Его отказ изолирует весь сегмент от остальной инфраструктуры.
Канал связи не менее критичен. Если у вас один интернет-провайдер, его авария или плановые работы оставляют ваши публичные сервисы без доступа извне. Внутренняя сеть может работать, но клиенты не смогут достучаться до сервисов. Для B2B-сервисов это означает нарушение SLA и финансовые потери.
Отсутствие резервирования на уровне IP - еще одна распространенная проблема. Когда серверы настроены с одним статическим IP-адресом и одним шлюзом, любой сбой на этом пути оставляет сервис недоступным. Резервирование IP-адресов через виртуальный IP (VIP) решает эту проблему на уровне сетевого стека.
Резервирование DNS-инфраструктуры: несколько IP-адресов и дополнительные NS-записи
Резервирование DNS строится на двух уровнях: уровне записей (несколько A/AAAA-записей для одного имени) и уровне серверов (несколько NS-серверов). Оба механизма дополняют друг друга и должны применяться вместе.
Настройка нескольких IP-адресов для одного доменного имени
Несколько A-записей для одного доменного имени позволяют клиенту выбрать любой из доступных IP-адресов. Это называется round-robin DNS. Пример конфигурации зоны:
; Зона example.com
$TTL 300
@ IN SOA ns1.example.com. admin.example.com. (
2026081901 ; serial
3600 ; refresh
600 ; retry
1209600 ; expire
300 ) ; minimum
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 203.0.113.10
@ IN A 203.0.113.11
@ IN A 198.51.100.20
www IN A 203.0.113.10
www IN A 203.0.113.11
www IN A 198.51.100.20
ns1 IN A 203.0.113.53
ns2 IN A 198.51.100.53Клиент получает все три адреса и обычно использует первый. Если сервер с первым адресом недоступен, клиент должен попробовать следующий. На практике поведение зависит от реализации резолвера и приложения. Многие приложения не обрабатывают отказ первого адреса корректно и просто завершаются с ошибкой.
Round-robin DNS распределяет нагрузку, но не проверяет доступность серверов. Если один из серверов вышел из строя, DNS продолжит отдавать его адрес. Часть пользователей будет получать ошибки подключения. Для полноценного failover на уровне DNS нужны health checks, которые реализуются в GSLB-решениях. Подробнее о настройке GSLB и автоматическом переключении на основе проверок доступности читайте в руководстве по GSLB.
Использование дополнительных NS-записей для резервирования
NS-записи определяют, какие серверы являются авторитативными для зоны. Минимум два NS-сервера - обязательное требование для публичных доменов. Они должны размещаться в разных сетях и, желательно, в разных дата-центрах.
Вторичный NS-сервер получает копию зоны через механизм зонной передачи. Для синхронизации используется AXFR (полная передача) или IXFR (инкрементальная передача). Настройка NOTIFY на первичном сервере ускоряет обновление: при изменении зоны первичный сервер уведомляет вторичные, и те сразу запрашивают обновление.
Пример конфигурации BIND для первичного сервера с NOTIFY:
// named.conf на первичном сервере
zone "example.com" {
type master;
file "/etc/bind/zones/example.com.zone";
allow-transfer { 198.51.100.53; }; // IP вторичного NS
also-notify { 198.51.100.53; };
notify yes;
};На вторичном сервере зона настраивается как slave:
// named.conf на вторичном сервере
zone "example.com" {
type slave;
masters { 203.0.113.53; }; // IP первичного NS
file "/var/cache/bind/example.com.zone";
};При отказе первичного NS вторичный продолжает отвечать на запросы. Клиенты автоматически обращаются к нему, если первичный недоступен. Это обеспечивает непрерывность разрешения имен без вмешательства администратора.
Географическое распределение DNS-серверов
Размещение DNS-серверов в разных географических регионах защищает от региональных сбоев: отключение электричества в дата-центре, проблемы с магистральными каналами, природные катастрофы. Если оба NS-сервера находятся в одном дата-центре, пожар или авария на площадке оставит домен без DNS.
Минимальная схема: первичный NS в основном дата-центре, вторичный - в другом регионе или у облачного провайдера. Для критичных сервисов стоит рассмотреть anycast DNS, когда один IP-адрес анонсируется из нескольких точек мира, и трафик автоматически направляется к ближайшему доступному узлу. Настройка anycast требует взаимодействия с провайдерами и использования BGP, о чем подробно рассказано в материале по глобальной балансировке.
Отказоустойчивый сетевой стек с keepalived и VRRP
VRRP (Virtual Router Redundancy Protocol) решает проблему отказа шлюза или сервера с одним IP-адресом. Несколько узлов объединяются в группу и совместно владеют виртуальным IP-адресом. Один узел активен (MASTER), остальные находятся в режиме ожидания (BACKUP). При отказе активного узла один из резервных автоматически принимает VIP на себя.
Принцип работы VRRP и виртуального IP
Каждый узел в VRRP-группе имеет приоритет. Узел с наивысшим приоритетом становится MASTER и владеет виртуальным IP. MASTER периодически рассылает анонсы (advertisements) на multicast-адрес 224.0.0.18. BACKUP-узлы слушают эти анонсы. Если анонсы не приходят в течение заданного интервала (обычно 3 * advert_interval), BACKUP с наивысшим приоритетом инициирует выборы и становится новым MASTER.
Переключение происходит за секунды. Клиенты продолжают обращаться к тому же виртуальному IP, не замечая, что трафик теперь обслуживает другой физический узел. Это ключевое преимущество VRRP: отказ прозрачен для приложений и пользователей.
Настройка keepalived для автоматического переключения
keepalived - это реализация VRRP для Linux. Установка на Debian/Ubuntu:
apt update
apt install keepalivedБазовая конфигурация для двух узлов. Узел 1 (приоритет 100, MASTER):
# /etc/keepalived/keepalived.conf на узле 1
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass MySecretPass
}
virtual_ipaddress {
192.168.1.100/24
}
}Узел 2 (приоритет 90, BACKUP):
# /etc/keepalived/keepalived.conf на узле 2
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass MySecretPass
}
virtual_ipaddress {
192.168.1.100/24
}
}Параметр virtual_router_id должен быть одинаковым на обоих узлах. Пароль в authentication тоже должен совпадать. После запуска keepalived на обоих узлах проверьте статус:
systemctl status keepalived
ip addr show eth0На MASTER-узле виртуальный IP 192.168.1.100 будет виден в выводе ip addr. Для проверки переключения остановите keepalived на MASTER-узле и убедитесь, что BACKUP-узел принял VIP в течение 3-5 секунд.
Обработка сценариев сбоя и предотвращение split-brain
Split-brain - это ситуация, когда оба узла считают себя MASTER и оба владеют виртуальным IP. Это происходит при потере связи между узлами: BACKUP перестает получать анонсы, инициирует выборы и становится MASTER, хотя старый MASTER все еще работает. В результате два узла отвечают на один IP, что приводит к непредсказуемому поведению сети.
Для предотвращения split-brain используйте несколько механизмов. Во-первых, настройте аутентификацию VRRP: узлы с разными паролями не будут принимать анонсы друг друга. Во-вторых, добавьте скрипты проверки состояния (track_script), которые отслеживают доступность критичных сервисов и снижают приоритет узла при их отказе:
vrrp_script chk_nginx {
script "/usr/bin/killall -0 nginx"
interval 2
weight -20
}
vrrp_instance VI_1 {
# ... остальная конфигурация ...
track_script {
chk_nginx
}
}Если nginx перестает работать, приоритет узла снижается на 20, и VIP переходит к резервному узлу. Для полного исключения split-brain в критичных средах применяйте механизмы fencing: резервный узел перед принятием VIP может выполнить команду для принудительной изоляции старого MASTER (например, через IPMI или управляемый коммутатор).
Балансировка исходящего трафика через несколько восходящих каналов
Один интернет-провайдер - это единая точка отказа для всего исходящего трафика. Резервирование каналов требует двух и более провайдеров и настройки маршрутизации, которая автоматически переключает трафик при отказе одного из них.
Настройка нескольких шлюзов и policy routing
Для небольших инфраструктур достаточно двух default gateway с разными метриками. Маршрут с меньшей метрикой используется как основной, второй - как резервный. Пример для Linux:
# Основной провайдер
ip route add default via 203.0.113.1 metric 100
# Резервный провайдер
ip route add default via 198.51.100.1 metric 200При отказе основного шлюза ядро автоматически переключается на резервный. Недостаток: переключение может занять несколько секунд, а уже установленные соединения будут разорваны.
Policy routing позволяет маршрутизировать трафик по источнику. Например, трафик от определенных серверов или подсетей можно направить через резервного провайдера, распределяя нагрузку:
# Создаем таблицу маршрутизации для резервного провайдера
echo "200 backup" >> /etc/iproute2/rt_tables
ip route add default via 198.51.100.1 table backup
ip rule add from 192.168.2.0/24 table backupТеперь трафик из подсети 192.168.2.0/24 всегда идет через резервного провайдера, а остальной трафик - через основного. При отказе одного канала достаточно изменить правила, чтобы перенаправить весь трафик на рабочий канал.
Использование BGP для балансировки между провайдерами
Для крупных систем с собственными IP-адресами и автономной системой (AS) BGP предоставляет полноценное резервирование и балансировку. Вы анонсируете свои префиксы через обоих провайдеров, и трафик автоматически выбирает лучший путь на основе метрик BGP.
Настройка BGP требует получения номера AS от регионального интернет-регистратора и блока PI-адресов (provider-independent). После этого на маршрутизаторе настраиваются BGP-сессии с обоими провайдерами:
# Пример для FRR (Free Range Routing)
router bgp 65001
bgp router-id 203.0.113.1
network 203.0.113.0/24
neighbor 203.0.113.254 remote-as 65002
neighbor 203.0.113.254 description Provider1
neighbor 198.51.100.254 remote-as 65003
neighbor 198.51.100.254 description Provider2При отказе одного провайдера BGP автоматически отзывает маршруты через него, и весь трафик идет через второго. Переключение занимает от нескольких секунд до минуты в зависимости от настроек таймеров. Для ускорения сходимости используйте BFD (Bidirectional Forwarding Detection), который обнаруживает отказ за миллисекунды.
Более детально настройка BGP и anycast для глобальной отказоустойчивости разобрана в руководстве по BGP и Anycast.
Типичные ошибки при внедрении отказоустойчивости и как их избежать
Резервирование само по себе не гарантирует доступность. Без регулярного тестирования и правильной настройки механизмы failover могут не сработать в критический момент. Разберем самые частые ошибки.
Недостаточное тестирование сценариев отказа
Конфигурация, которая не тестировалась, - это конфигурация, которая не работает. Многие команды настраивают keepalived или резервный DNS-сервер, но никогда не проверяют, что произойдет при реальном отказе. Когда отказ случается, выясняется, что переключение не сработало: неверный приоритет, ошибка в скрипте проверки, отсутствие прав на выполнение.
Проводите плановые учения по отказу компонентов. Останавливайте MASTER-узел keepalived, отключайте первичный DNS-сервер, разрывайте BGP-сессию. Фиксируйте время переключения и поведение приложений. Автоматизируйте такие проверки, используя подходы chaos engineering: внедряйте случайные отказы в тестовой среде и наблюдайте за реакцией системы.
Полезная практика - вести журнал учений: дата, сценарий, время обнаружения, время восстановления, обнаруженные проблемы. Этот журнал помогает отслеживать прогресс и выявлять повторяющиеся слабые места.
Игнорирование TTL и кэширования DNS
TTL определяет, как долго запись живет в кэше резолверов. При планировании failover DNS-записей TTL критически важен. Если TTL установлен в 86400 секунд (сутки), изменения записей будут распространяться по интернету до 24 часов. Это значит, что после переключения на резервный IP часть пользователей еще сутки будет пытаться подключиться к старому адресу.
Для записей, которые могут меняться при failover, устанавливайте TTL не более 300 секунд. Это ускорит распространение изменений, но увеличит нагрузку на DNS-серверы. Найдите баланс: для стабильных записей TTL можно увеличить, для критичных - уменьшить.
Заранее планируйте изменения DNS. Если предстоит смена IP-адреса сервера, снизьте TTL за сутки до изменения. После переключения и проверки работоспособности можно вернуть TTL к обычному значению. Эта практика минимизирует окно, в течение которого пользователи получают устаревшие данные.
Заключение: комплексный подход к отказоустойчивости
Устранение единых точек отказа требует резервирования на всех уровнях: DNS-инфраструктура, сетевой стек, каналы связи. Настройте несколько NS-серверов в разных дата-центрах, используйте несколько A-записей для критичных сервисов, внедрите keepalived с VRRP для автоматического переключения виртуального IP и обеспечьте балансировку исходящего трафика через нескольких провайдеров.
Резервирование без тестирования не работает. Регулярно проверяйте сценарии отказа, следите за TTL DNS-записей и настройте мониторинг, который обнаружит сбой до того, как он повлияет на пользователей. Отказоустойчивость - это процесс, а не разовая настройка.
Для углубленного изучения темы рекомендуем ознакомиться с ключевыми принципами отказоустойчивости информационных систем и основами терминологии RTO и RPO. Если вы проектируете системы управления, обратите внимание на архитектуру резервирования и failover.