Минимальный отказоустойчивый кластер: что реально нужно

Минимальный — не значит «просто два сервера»

Идея минимального кластера обманчиво проста: поставить рядом второй сервер — и при отказе первого всё продолжит работать. На практике пара серверов сама по себе отказоустойчивости не даёт: если оба подключены к одному коммутатору и одному ИБП, а данные лежат в одном месте, любой из этих общих элементов останавливает оба узла разом. Обзорная статья о высокой доступности предупреждает об этом прямо — здесь мы разворачиваем предостережение в конкретный состав.

«Минимальный» в названии означает нижний проектный порог для выбранного сценария: схема должна пережить отказ одного узла и дать предусмотренный платформой порядок обслуживания. Если часть требований не закрыта, получается другая схема с другими свойствами: например, резервный хост с восстановлением из копий. Это тоже рабочий вариант, но его границы нужно зафиксировать отдельно.

Дальше — пять элементов состава. Каждый из них становится вопросом приёмки: если элемент отсутствует, нужно заново определить, какие отказы схема действительно выдерживает.

Состав минимального кластера: пять элементов

Ресурсы узлов считаются от плана виртуальных машин с запасом на отказ соседа: в штатном режиме нагрузка делится на двоих, в аварийном защищаемые машины должны поместиться на выжившем узле. Методика расчёта ядер, памяти и дисков под план машин — в разборе «сколько ВМ потянет сервер»; сами узлы под требования платформы — серверы в каталоге ANDPRO, с проверкой конфигурации под конкретный проект.

Кворум и «третий голос»

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

В Failover Clustering для Windows Server каждый узел получает голос, а witness может добавить ещё один. Для работы кластера активным должно оставаться больше половины голосов; при потере большинства кластер останавливает роли, чтобы не допустить split-brain. Microsoft рекомендует настраивать witness, перечисляет облачный, дисковый и файловый типы и отдельно показывает его роль в двухузловых схемах. Это пример одной платформы: точный расчёт голосов и поведение при отказах нужно проверять по документации выбранного решения.

Размещение witness — отдельное проектное решение. Для cloud witness в Windows Server узлам нужен доступ к Azure Storage по HTTPS. File share witness Microsoft рекомендует физически отделять от узлов или площадок с учётом сети, питания, стойки и помещения. Disk witness, напротив, требует общего диска, доступного всем узлам. Поэтому универсальной точки размещения нет: выбранный тип сверяют с отказовыми доменами и требованиями конкретной платформы.

У других платформ механизмы кворума, типы голосующих участников и ограничения отличаются. В пилоте нужно воспроизвести потерю связи и отказ узла по документированному сценарию платформы, затем зафиксировать, какая сторона сохранила кворум, какие роли остановились и как кластер вернулся в штатное состояние.

Данные: общее хранилище или синхронизация

Чтобы выживший узел запустил машины соседа, ему нужны их данные. Два класса схем решают эту задачу по-разному.

Общее хранилище. Оба узла подключены к одной СХД, машины лежат на ней; при отказе узла второй запускает их с того же хранилища — данные едины по построению. Цена схемы: СХД сама становится критическим элементом, и её собственное резервирование — контроллеры, питание, пути подключения — обязательная часть проекта, иначе кластер из двух узлов получает одну общую точку отказа в самом центре. Как выбирается СХД и её резервирование — в гайде по СХД: SAN, NAS, DAS.

Синхронизация между узлами. Каждый узел хранит данные локально, а платформа переносит изменения между ними. Отдельная СХД не требуется, но появляются требования к сети и измеримый разрыв между актуальным состоянием и доступной копией: для конкретной схемы его проверяют при нормальной работе и при отказе. Границы репликации как механизма — что она переносит вместе с полезными изменениями — разобраны в статье о снапшотах и репликации.

При любой схеме хранения резервные копии снимаются и хранятся отдельно от кластера. Типовая ловушка общего хранилища — складывать копии на ту же СХД, где живут данные: при её отказе теряются и рабочие машины, и «резерв». Репозиторий копий — отдельное устройство вне кластерного контура, с офсайт-слоем по правилу архитектуры копий.

Выбор между схемами — проектный: объём и профиль данных, бюджет, требования к простою. Общий принцип для минимального кластера: схема хранения должна переживать отказ одного узла без потери актуальных данных критичных систем — и это свойство проверяется тестом, а не предполагается.

Сеть и питание: где прячутся общие точки отказа

Кластер переживает отказ узла — но только если узлы не делят между собой скрытые общие элементы. Проверка проводится по слоям, вопросом «что остановится, если выключить вот это»:

Сеть. Кластерную связь, синхронизацию и клиентский трафик проектируют по требованиям платформы; пути резервируют так, чтобы отказ одного линка или коммутатора не лишил узлы связи одновременно. Для каждой сети фиксируют её роль, отказовой сценарий и ожидаемое поведение кворума.

Питание. Два узла за одним ИБП сохраняют общую точку отказа. Схему питания строят так, чтобы отказ одного предусмотренного элемента не обесточил оба узла и доступный witness одновременно; конкретную топологию сверяют с вводами питания, БП серверов и ИБП площадки.

Площадка. Если оба узла размещены в одной стойке или комнате, пожар, затопление или полное обесточивание помещения остаются общим сценарием отказа. Такой кластер не становится катастрофоустойчивым автоматически: для площадочного риска нужны отдельные цели и внешний контур восстановления.

Что кластер даёт — и чего не даёт

Граница по данным требует отдельной проверки. Общая СХД или репликация не создаёт историческую точку восстановления: ошибочное удаление, повреждение базы или шифрование может затронуть весь рабочий контур. Поэтому резервные копии хранят независимо от кластера, а их восстановимость подтверждают регламентной проверкой — методика в гайде по тестовому восстановлению.

Когда кластер оправдан, а когда хватает резервного хоста

Ответ выводится из целевых значений простоя, и удобно смотреть на него как на лестницу из трёх ступеней.

Ступень 1. Копии плюс запасное железо. Резервное копирование по заданному RPO, подготовленный резервный сервер, восстановление из копии по регламенту. Время простоя включает развёртывание, восстановление и проверку; если измеренный результат укладывается в RTO системы, усложнять схему не требуется.

Ступень 2. Резервный хост с репликой. Выбранные машины реплицируются на второй сервер, а запуск выполняется по заранее проверенному сценарию — автоматически или вручную, если это предусмотрено платформой. Это промежуточная ступень, когда восстановление из копии не укладывается в RTO, а свойства полного кластера пока не требуются.

Ступень 3. Кластер. Автоматическое обнаружение отказа и запуск нагрузки на выжившем узле — ценой кворума, продуманного хранилища, резервированных путей и регламента. Кластер оправдан, когда проверенные ступени 1 и 2 не укладываются в RTO либо когда платформа и приложения позволяют безопасно переносить нагрузку перед обслуживанием узла.

Ступени можно сочетать: кластер включать только для систем, чьи RTO и сценарии обслуживания это обосновывают, а остальные оставлять на первой или второй ступени. Так требования каждой системы остаются явными, а состав инфраструктуры не расширяется без измеримой причины.

Какая ступень нужна каждой вашей системе — определяется целевыми RPO и RTO: методика их выбора по процессам — в статье о выборе RPO и RTO. А требования кластера к платформе виртуализации — живая миграция, поведение при отказе, редакции — входят в критерии выбора гипервизора: разбор — в статье о критериях выбора гипервизора.

Эксплуатация: кластер — это регламент

Работоспособность кластера нельзя подтверждать только текущим статусом «всё зелёное». Без тестов отказа, контроля кворума, синхронизации и свободного места ошибка конфигурации может оставаться незаметной до аварии или обслуживания.

Пилотную приёмку удобно разбить на шесть отдельных сценариев: отказ первого узла при полной защищаемой нагрузке; отказ второго узла; потеря одного сетевого пути; недоступность witness при сохранённой связи между узлами; перенос нагрузки перед обслуживанием; возврат узла и завершение синхронизации. Сценарии выполняют на изолированном стенде или в согласованном окне и только в пределах того, что разрешает документация платформы. Несколько отказов одновременно не объединяют в один тест, пока каждый одиночный сценарий не пройден и не зафиксирован.

Для каждого запуска журналируют исходное состояние, время события, состав активных голосов, какие роли остановились или перешли на соседний узел, время доступности приложения, ошибки и результат возврата в штатный режим. Приёмка считается пройденной не по зелёному статусу кластера, а по доступности конкретного сервиса и совпадению факта с его RTO и RPO. Если результат не совпал, фиксируют одно изменение конфигурации и повторяют только затронутый сценарий; так причина не смешивается с несколькими правками сразу.

До теста задают стоп-условия: кто прекращает сценарий, при каких ошибках начинается откат и из какой проверенной копии восстанавливаются данные, если испытание вышло за ожидаемые границы. Эти условия нужны даже на стенде: они отделяют управляемую проверку от импровизации и позволяют повторить тест после изменения конфигурации.

Регламент минимального кластера умещается в четыре пункта. Тест отказа узла по расписанию: плановое отключение одного узла с замером времени запуска машин и проверкой сервисов — по той же логике уровней и журнала, что и тест восстановления копий. Обновления по документации платформы: перенос нагрузки, обновление одного узла, проверка и только затем работа со следующим. Мониторинг: состояние узлов, кворума, синхронизации и место на хранилище — с назначенным получателем оповещений; контроль заданий и алертов — тема хаба о мониторинге ИТ-инфраструктуры. План на «узел не вернулся»: допустимая длительность работы на одном узле, ответственный за ремонт и порядок возврата резервирования.

На одной странице документации фиксируют схему сети и питания, размещение witness, приоритеты машин, контакты и порядок действий при отказе. Документ проверяют во время планового теста: оператор должен выполнить сценарий без устных подсказок автора схемы.

Типовые ошибки минимальных кластеров

Пять проверок ниже закрывают границы, которые легко пропустить при приёмке. Для каждой указаны последствие и способ доказать готовность схемы до аварии.

Частые вопросы