Failover

Failover — это автоматический или ручной процесс переключения функций, нагрузки или управления с основного (активного) компонента вычислительной системы на резервный (пассивный) при отказе, сбое или плановом отключении основного. Failover является ключевым механизмом обеспечения отказоустойчивости и высокой доступности (High Availability, HA) информационных систем, позволяя минимизировать время простоя (downtime) и потерю данных.

История

Концепция резервирования и переключения на резерв возникла в середине XX века вместе с развитием первых электронных вычислительных машин. В 1950-х годах, в эпоху ламповых компьютеров, отказы были частым явлением, и для критически важных задач (например, военных или финансовых) применялось дублирование аппаратных блоков. Однако автоматическое переключение без участия человека появилось позже.

В 1970-х годах с развитием многопроцессорных систем и сетей передачи данных (например, в системе ARPANET) были разработаны первые протоколы, позволяющие автоматически перенаправлять трафик при отказе узла. В 1980-х годах компания Tandem Computers (позже вошедшая в Compaq и Hewlett-Packard) создала одни из первых коммерческих отказоустойчивых серверов с аппаратным failover, ориентированных на банковские и биржевые системы.

В 1990-х годах с распространением клиент-серверной архитектуры и веб-технологий failover стал стандартным требованием для серверов баз данных, веб-серверов и систем хранения данных. Развитие кластерных технологий (например, Microsoft Cluster Service, Linux-HA) позволило реализовать failover на уровне программного обеспечения.

В 2000-х и 2010-х годах с ростом облачных вычислений (Amazon Web Services, Microsoft Azure, Google Cloud) failover стал неотъемлемой частью архитектуры распределённых систем, где он реализуется на уровне виртуализации, контейнеризации и оркестрации (например, Kubernetes).

Принципы работы

Основная цель failover — обеспечить непрерывность работы сервиса при отказе одного или нескольких компонентов. Процесс обычно включает три этапа:

1. Мониторинг (Health Check) — постоянная проверка состояния основного компонента. Используются «сердцебиения» (heartbeat) — периодические сигналы, которыми обмениваются узлы кластера. Если резервный узел не получает сигнал от основного в течение заданного тайм-аута, он инициирует failover.

1. Переключение (Switchover) — передача функций от отказавшего компонента к резервному. В зависимости от реализации, это может включать:

• Перенаправление сетевого трафика (например, через плавающий IP-адрес или DNS-запись).
• Монтирование общих дисковых томов.
• Запуск экземпляров приложений на резервном узле.
• Восстановление состояния (state) из последней контрольной точки (checkpoint).

1. Восстановление (Fallback) — возврат к нормальной работе после устранения неисправности. В некоторых системах fallback выполняется автоматически, в других — вручную, чтобы избежать нестабильности.

Классификация

По способу переключения

• Автоматический failover — переключение происходит без участия человека, на основе данных мониторинга. Используется в критически важных системах, где время простоя недопустимо (например, в авиадиспетчерских системах, банковских процессинговых центрах).
• Ручной failover — переключение инициируется администратором вручную. Применяется в системах, где автоматическое переключение может привести к нежелательным последствиям (например, при сложных транзакциях, требующих проверки целостности данных).

По типу резервирования

• Активный-пассивный (Active-Passive) — основной узел обрабатывает все запросы, резервный находится в режиме ожидания. При отказе основного резервный активируется и начинает обслуживать запросы. Этот подход прост в реализации, но требует избыточных ресурсов.
• Активный-активный (Active-Active) — оба узла одновременно обрабатывают запросы, распределяя нагрузку. При отказе одного узла нагрузка перераспределяется на оставшийся. Этот подход эффективнее использует ресурсы, но сложнее в реализации (требуется синхронизация данных и балансировка нагрузки).
• N+1 резервирование — один резервный узел обслуживает группу из N активных узлов. При отказе любого из активных узлов резервный принимает его функции.
• Полное резервирование (2N) — каждый активный узел имеет выделенный резервный.

По уровню реализации

• Аппаратный failover — реализуется на уровне физических устройств (дублирование блоков питания, процессоров, сетевых карт). Пример: RAID-массивы с горячей заменой дисков.
• Программный failover — реализуется на уровне операционной системы, приложений или middleware. Пример: кластеры баз данных (PostgreSQL с Patroni, MySQL с Group Replication).
• Сетевой failover — реализуется на уровне сетевой инфраструктуры (протоколы VRRP, HSRP, CARP). Пример: резервирование шлюзов по умолчанию.
• Облачный failover — реализуется средствами облачного провайдера (например, AWS Auto Scaling Groups, Azure Availability Zones).

Применение

Failover широко применяется в различных отраслях и системах:

• Базы данных — кластеры СУБД (Oracle RAC, Microsoft SQL Server Always On, PostgreSQL с Patroni) обеспечивают автоматическое переключение на реплику при отказе основного узла.
• Веб-серверы — балансировщики нагрузки (Nginx, HAProxy) перенаправляют трафик на здоровые серверы при отказе одного из них.
• Системы хранения данных (СХД) — контроллеры СХД дублируются, и при отказе одного контроллера управление переходит к другому без потери доступа к данным.
• Телекоммуникационное оборудование — базовые станции, коммутаторы и маршрутизаторы имеют резервные модули, которые берут на себя нагрузку при сбое.
• Критическая инфраструктура — системы управления атомными электростанциями, авиационные системы управления полётом, медицинское оборудование (например, аппараты ИВЛ) обязаны иметь failover для предотвращения катастрофических последствий.
• Облачные сервисы — провайдеры (Yandex Cloud, VK Cloud, SberCloud) используют failover для обеспечения SLA (Service Level Agreement) по доступности, часто гарантируя uptime на уровне 99,9% и выше.

Проблемы и ограничения

Несмотря на преимущества, failover имеет ряд ограничений:

• «Сплит-брэйн» (Split-Brain) — ситуация, когда оба узла кластера считают себя активными и начинают одновременно обрабатывать запросы, что приводит к повреждению данных. Для предотвращения используются механизмы кворума (quorum) и fencing (изоляция отказавшего узла).
• Время переключения — даже при автоматическом failover существует задержка (от нескольких секунд до минут), в течение которой сервис недоступен. Для критически важных систем (например, финансовых транзакций) это может быть неприемлемо.
• Потеря данных — если failover не синхронизирован с последними транзакциями, возможна потеря данных, которые не были записаны на резервный узел. Для минимизации используются синхронная репликация и журналы транзакций.
• Сложность конфигурации — настройка failover требует высокой квалификации администраторов, особенно в распределённых системах с активной-активной архитектурой.
• Стоимость — резервирование оборудования и лицензий (например, для коммерческих СУБД) увеличивает общую стоимость владения системой.

Примеры реализации

• Microsoft Windows Server Failover Cluster — встроенная функция Windows Server, позволяющая создавать отказоустойчивые кластеры для приложений, файловых серверов и баз данных.
• Linux-HA (Pacemaker + Corosync) — популярное открытое решение для создания отказоустойчивых кластеров в Linux.
• Kubernetes — оркестратор контейнеров автоматически перезапускает отказавшие поды и перераспределяет нагрузку, реализуя failover на уровне контейнеров.
• PostgreSQL с Patroni — популярное решение для автоматического failover в базах данных PostgreSQL, используемое в том числе в российских компаниях (например, в «Яндексе» и «Сбере»).
• VRRP (Virtual Router Redundancy Protocol) — протокол, используемый для резервирования маршрутизаторов, описанный в RFC 5798.

Интересные факты

• В системах, где failover недопустим (например, в истребителях пятого поколения), используется тройное резервирование (triple modular redundancy) — три независимых канала, результаты которых сравниваются по мажоритарному принципу.
• В 2017 году из-за ошибки в конфигурации failover в AWS S3 (организация признана иностранным агентом в РФ) произошёл массовый сбой, затронувший многие крупные сайты, включая Netflix и Reddit.
• В российских банках (например, в Сбербанке) failover реализован на уровне дата-центров, расположенных в разных регионах, что позволяет переключать нагрузку при техногенных катастрофах или сбоях в энергоснабжении.

Источники

• RFC 5798 — Virtual Router Redundancy Protocol (VRRP).
• «Designing Data-Intensive Applications» by Martin Kleppmann (2017).
• «High Availability: Design, Techniques, and Processes» by Floyd Piedad and Michael Hawkins (2000).
• Документация Microsoft: «Failover Clustering in Windows Server».
• Документация PostgreSQL: «High Availability, Load Balancing, and Replication».