Отказоустойчивый кластер работает как двое пилотов в кабине: пока один ведет самолет, второй наблюдает, и при отказе командира второй мгновенно берет штурвал — пассажиры даже не замечают. 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-кластер — вопрос расчета, а не интуиции. Короткий порядок принятия решения:
- определить 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С, СУБД или веб-фронт. Подберем сервер под задачу под узлы кластера. Оставьте заявку.
