Failover обеспечивает автоматическое переключение нагрузки на резервный компонент, если основной перестал отвечать. Это предотвращает простой системы и повышает доступность, особенно в критически важных сервисах.
Существуют два основных режима: Active-Passive, где резерв ожидает активации, и Active-Active, где несколько узлов работают одновременно и могут мгновенно подхватить нагрузку. Выбор режима зависит от требований к доступности и допустимого времени простоя.
Failover применяется в кластерах баз данных, балансировщиках, API-шлюзах, микросервисных платформах и системах хранения. Это ключевой паттерн архитектур, ориентированных на непрерывную работу.
Failover — один из базовых элементов архитектур высокой доступности. Он предполагает, что система должна уметь автоматически реагировать на сбой любого критического компонента: базы данных, приложения, балансировщика, сетевого узла, кэша, брокера сообщений. В отличие от простых схем ручного восстановления, механизмы failover включают автоматическое обнаружение сбоя, принятие решения о переключении и своевременное разворачивание резервного узла для обработки нагрузки.
Active-Passive — это классическая форма failover. Основной узел работает, а резервный ожидает момента переключения. Он может быть синхронным или асинхронным. Синхронный резерв имеет такое же состояние и минимальное RPO, но может работать медленнее. Асинхронный — быстрее, но при переключении может потерять последние транзакции. Архитектор выбирает компромисс между скоростью и консистентностью исходя из SLA.
Active-Active предполагает, что все узлы работают одновременно, распределяя нагрузку между собой. Это более надежная схема: отказ одного узла не требует переключения, балансировщик просто убирает его из пула. Такой подход характерен для горизонтально масштабируемых микросервисов, облачных баз данных, распределенных кешей (Redis Cluster), брокеров сообщений и API-шлюзов.
Ключевой вызов Failover — согласованность данных. При переключении важно избежать ситуации «split-brain», когда два узла одновременно считают себя активными и принимают противоречивые изменения. Поэтому системы используют механизмы здоровья (health checks), контроль quorum, протоколы выбора лидера (Raft, Paxos), детекторы отказов и алгоритмы консенсуса. Архитектор должен понимать, как работает каждый из них, чтобы минимизировать риск конфликтов и обеспечить корректность поведения.
В Event-Driven системах failover используется не только для приложений, но и для самих очередей: Kafka использует репликацию партиций, ZooKeeper/RAFT для координации, а брокеры вроде RabbitMQ — кластеризацию и зеркалирование очередей. Это критично для обеспечения гарантированной доставки сообщений и устойчивости всей цепи обработки.
Failover также используется в API-инфраструктуре: балансировщики уровня L4/L7 автоматически исключают недоступные узлы, а retry-механизмы маршрутизируют запросы на живые инстансы. В распределенных файловых системах (HDFS, Ceph, GlusterFS) переключение на резервные реплики обеспечивает бесперебойный доступ к данным.
На рынке труда архитекторы, способные проектировать корректный failover, особенно ценятся в секторах банковских ИС, телекоммуникаций, страхования, логистики, высоконагруженных маркетплейсов и госуслуг. Failover — это основа работы систем, которые не имеют права останавливаться. Ошибка в проектировании здесь приводит не просто к сбою, а к финансовым потерям, потере данных и недоступности критических сервисов.