Блог

Отказоустойчивый кластер (failover): что это и когда нужен бизнесу

2026-07-13 15:30
Отказоустойчивый кластер работает как двое пилотов в кабине: пока один ведет самолет, второй наблюдает, и при отказе командира второй мгновенно берет штурвал — пассажиры даже не замечают. Failover-кластер делает то же самое с серверами: группа узлов страхует друг друга, и при сбое одного сервис продолжает работать на другом. Но дублирование инфраструктуры окупается не везде: оно решает ровно одну задачу — исключить простой там, где минута недоступности стоит реальных денег.

Что такое failover-кластер простыми словами

По сути это объединение серверов-узлов, в котором роль упавшего участника за секунды и без участия инженера перехватывает работающий. Отличие от обычного резерва принципиальное: запасную машину надо вручную включить и донастроить, теряя минуты или часы, тогда как узлы здесь подменяют друг друга автоматически. Высокая доступность (high availability, HA) рождается не из коробки на полке, а из постоянной готовности соседнего узла принять нагрузку на себя.
Эту схему регулярно смешивают с балансировкой нагрузки, хотя решают они разное. Балансировщик раскидывает запросы между серверами ради скорости и имеет дело с сервисами без состояния. Отказоустойчивая связка, наоборот, страхует сервисы с состоянием — базы данных, бизнес-приложения — и переносит их целиком при сбое. Балансировка отвечает за «быстрее силами многих», а резервирование — за «не упасть, когда один узел отвалится».

Архитектуры failover-кластера

Фундаментальных подходов два. Схема active/passive держит один узел рабочим, а второй — в горячем резерве, который перехватывает нагрузку лишь при падении основного: предсказуемо, но половина железа простаивает. В active/active трудятся оба узла сразу, прикрывая друг друга, — отдача выше, зато настройка сложнее, и приложение должно уметь жить на нескольких узлах параллельно.
Когда запаса нужно больше, переходят к схемам N+1 (один резерв на группу рабочих узлов) и N+M (сразу несколько резервов). Особняком стоит geo-кластер на два ЦОД: узлы намеренно разносят по разным городам или зданиям, чтобы устоять при потере целой площадки. Такая конфигурация защищает от пожара или аварии в дата-центре, но требует быстрого канала между ЦОД и аккуратной работы с задержками репликации.

Из чего состоит кластер

Система собирается из нескольких обязательных частей, и под узлы мы подбираем серверы с сопоставимой конфигурацией. Основа — сами узлы (nodes), между которыми идет heartbeat: периодические сигналы, по пропаже которых кластер понимает, что узел отказал. Решение о том, кто продолжает работу при разрыве связи, принимает quorum — правило большинства голосов, а witness добавляет решающий голос при четном числе узлов.
Данные держат либо на общем хранилище, либо в схеме shared-nothing с репликацией между узлами. Клиенты обращаются к сервису через virtual IP — плавающий адрес, который переезжает на живой узел; на сетевом уровне за это отвечает протокол VRRP. И обязательный элемент защиты от раскола — STONITH (fencing): механизм принудительно отключает зависший узел, чтобы два узла не начали работать как главные одновременно. Минимальная отказоустойчивая конфигурация — два узла плюс witness, а для запаса берут кластер из 3 узлов.

Когда failover-кластер реально нужен бизнесу

Кластеризация оправдана там, где минута простоя стоит дорого и измеряется деньгами. Интернет-магазин в пиковые часы теряет продажи с каждой минутой недоступности, поэтому фронт и база данных выносят в кластер. Банки, страховые и платежные системы работают в режиме, где простой недопустим в принципе и регулируется требованиями к непрерывности. Продуктивные ERP-системы, включая 1С:ERP, останавливают работу всей компании при отказе — их тоже кластеризуют.
По той же причине в отказоустойчивую связку выносят видеонаблюдение с важным архивом и медицинские системы, простой которых останавливает прием пациентов. Объединяет эти случаи одно: сервис работает почти круглосуточно, и его остановка бьет по выручке, безопасности или здоровью людей. Когда это про вашу нагрузку — резервирование становится не роскошью, а обязательным условием.

Когда без кластера можно обойтись

Обратная сторона честнее: для многих систем такая схема избыточна и не окупается. Внутренние сервисы с допустимым простоем в несколько часов спокойно живут на одном сервере с настроенным резервным копированием. Бэк-офис, который работает с девяти до шести, не нуждается в круглосуточной отказоустойчивости — ночной сбой успеют устранить до начала рабочего дня. Тестовые и dev-среды кластеризовать незачем по определению.
Граница простая: если сервис можно поднять из резервной копии или переключить на горячий standby за приемлемое для бизнеса время, полноценный кластер с автоматическим failover не нужен. Удвоение железа и усложнение эксплуатации оправданы только тогда, когда счет идет на секунды и минуты, а не на часы.

Инструменты по типам приложений

Под каждую платформу есть свой инструментарий, и выбор отечественных решений — часть импортозамещения серверов. На Windows кластеризацию закрывает встроенный WSFC (Windows Server Failover Cluster) вместе с Hyper-V Failover Cluster — это отдельная большая тема со своей спецификой. На Linux стандарт де-факто — Pacemaker с Corosync: связка строит активно-пассивные и активно-активные кластеры почти для любого сервиса.
Для баз данных применяют специализированные решения. PostgreSQL кластеризуют связкой Patroni и etcd с автоматическим переключением за секунды. Для MySQL берут MHA, Orchestrator или ProxySQL. Сетевую отказоустойчивость и плавающий адрес дают Keepalived с VRRP и балансировщик HAProxy. Платформа vSphere HA от VMware в РФ перешла в разряд legacy после ухода вендора, и новые проекты строят на перечисленных открытых инструментах.

Метрики: RTO и RPO

Решение о кластеризации принимают не на ощущениях, а по двум метрикам. Первая метрика, RTO (recovery time objective), задает потолок времени на восстановление — за сколько сервис обязан вернуться в строй. Вторая, RPO (recovery point objective), очерчивает допустимый объем потерянных данных — за какой промежуток их не жалко лишиться. Синхронная репликация подтягивает RPO к нулю, а время возврата — к секундам; суточный бэкап оставляет до суток данных под риском и часы на подъем. Из этих чисел и вытекает, нужна ли вообще кластеризация.
Перевести метрики в деньги помогает цена одной минуты простоя. Для интернет-магазина в пиковый сезон она может исчисляться десятками тысяч рублей за минуту — и тогда вложение отбивается за считанные недели. Если же час недоступности стоит копейки, тратиться на отказоустойчивость смысла нет. Окупаемость выводят напрямую: цену решения соотносят с потерями, которых удалось избежать, и сверяют с уровнем SLA, обещанным клиентам.

Сколько стоит failover-кластер

Затраты делятся на капитальные и операционные. К CapEx относят дополнительный сервер, хранилище или диски под репликацию и лицензии на ПО резервирования, если оно платное. В OpEx ложатся электропитание удвоенного парка, обслуживание, поддержка и часы инженеров на более сложную эксплуатацию. Разница с одиночной машиной проявляется не только при покупке, но и весь срок сопровождения.
Честную картину дает расчет совокупной стоимости владения (TCO) на три-пять лет: суммируют CapEx и OpEx за период и сопоставляют с предотвращенными потерями от простоев за тот же срок. На сценариях с дорогим простоем вложение выходит в плюс быстро; на сценариях с дешевым — может не окупиться никогда. Этот расчет стоит сделать до закупки, а не после.

Сценарии перехода

К отказоустойчивости приходят постепенно, и резкий скачок не обязателен. Первый шаг — от одного сервера к схеме active/passive: добавляют второй узел и witness, настраивают репликацию и автоматическое переключение, и за месяц система получает базовую отказоустойчивость. Это закрывает большинство потребностей среднего бизнеса.
Дальше масштабируют по мере роста требований: от active/passive к geo-кластеру между двумя ЦОД для защиты от отказа площадки. Распространен и гибрид — продуктив в кластере на своей площадке плюс аварийное восстановление (DR) в облаке. Такой подход дает географическое разнесение без второго собственного дата-центра. Каждый шаг добавляет устойчивости и стоимости, поэтому их проходят по мере реальной необходимости.

Три ошибки, которые обнуляют отказоустойчивость

Три ошибки превращают кластер в источник ложной уверенности. Первая — один heartbeat вместо двух: единственный канал служебной связи отказывает, узлы перестают видеть друг друга и либо встают, либо уходят в split-brain, когда оба считают себя главными. Вторая — witness без резервирования: когда решающий голос завязан на одну точку, ее отказ парализует кворум. Третья и самая частая — отсутствие тестов переключения: систему собрали, но ни разу не проверили реальный failover, и в момент настоящего сбоя выясняется, что переключение не работает. Тест переключения проводят регулярно, а не надеются на него.

Сравнение архитектур

Сравнение архитектур failover-кластера
Архитектура Утилизация ресурсов Переключение Когда выбирать
active/passive Резерв простаивает Секунды-минуты Большинство сценариев с дорогим простоем
active/active Оба узла в работе Секунды Высокая нагрузка, приложение это умеет
N+1 / N+M Резерв на группу узлов Секунды-минуты Много рабочих узлов
Geo-кластер (2 ЦОД) Зависит от схемы Секунды плюс задержка канала Защита от потери площадки

Заключение: как принять решение

Нужен ли бизнесу failover-кластер — вопрос расчета, а не интуиции. Короткий порядок принятия решения:
  • определить RTO и RPO, которые требует бизнес от конкретного сервиса;
  • посчитать стоимость минуты простоя и сравнить ее с ценой кластера;
  • если простой дешев или допустим в часах — обойтись бэкапом и горячим резервом;
  • если счет на секунды и деньги — выбрать архитектуру active/passive или active/active;
  • заложить два heartbeat-канала, резервируемый witness и защиту от split-brain;
  • запланировать регулярный тест переключения — без него кластер не считается рабочим.
Пройденный расчет отделяет обоснованную инвестицию в непрерывность от дорогой страховки, которая никогда не понадобится.

Часто задаваемые вопросы

Что такое failover-кластер простыми словами?

Это группа серверов, где при отказе одного его роль автоматически и за секунды переходит на другой, и сервис продолжает работать. Так достигается высокая доступность без ручного включения резерва.

Чем кластер отличается от резервного бэкапа?

Бэкап — это копия данных, из которой сервис восстанавливают вручную за часы. Кластер переключает работающий сервис на живой узел автоматически за секунды. Бэкап нужен в любом случае, но он не заменяет кластер там, где недопустим простой.

Сколько узлов минимум для failover-кластера?

Минимум два узла плюс witness, что дает три голоса для кворума. Четное число узлов без witness рискует уйти в split-brain при разрыве связи. Для запаса по емкости часто берут три узла.

Что такое active/passive и active/active?

В active/passive один узел работает, второй ждет и подхватывает нагрузку при сбое. В active/active оба узла работают одновременно и страхуют друг друга — выше утилизация, но сложнее конфигурация и требования к приложению.

Что такое split-brain и как от него защититься?

Split-brain — это когда при разрыве связи оба узла считают себя главными и начинают работать параллельно, повреждая данные. Защита — кворум, witness и STONITH, который принудительно отключает зависший узел.

Сколько занимает переключение в failover-кластере?

Зависит от технологии: плавающий адрес по VRRP переключается за секунды, кластеры на Pacemaker — за десятки секунд, синхронная репликация баз дает переключение за секунды с нулевой потерей данных. Точное время закладывают в целевой RTO.

Какие инструменты используют для Linux-кластеров?

Базовый стандарт — Pacemaker с Corosync для большинства сервисов. PostgreSQL кластеризуют связкой Patroni и etcd, сетевую отказоустойчивость дают Keepalived с VRRP и HAProxy. Под каждый класс приложений есть свой инструмент.

Окупается ли кластер для малого бизнеса?

Только если простой сервиса стоит ощутимых денег. Для внутренних систем с допустимым простоем в часы кластер избыточен — дешевле бэкап и горячий резерв. Решение принимают по расчету стоимости минуты простоя, а не по размеру компании.

Рассчитаем кластер под ваш бизнес

Считаете, нужен ли вашему бизнесу failover-кластер? Инженеры Serverzilla рассчитают RTO и RPO, стоимость минуты простоя и окупаемость, подберут серверы под узлы и спроектируют схему active/passive или active/active под 1С, СУБД или веб-фронт. Подберем сервер под задачу под узлы кластера. Оставьте заявку.