Как собрать отказоустойчивый кластер серверов с запасом мощности и емкости хранилища

Отказоустойчивый кластер нужен для одного: чтобы сервис пережил отказ железа без остановки. Упал узел, диск, блок питания - нагрузка уезжает на соседа, пользователь ничего не заметил. Звучит просто, но между «поставить два сервера» и «получить работающий кластер» лежит несколько решений, на которых легко ошибиться: кворум, общее хранилище, запас мощности. Разберём, как собрать такой кластер под небольшую компанию, на что смотреть при выборе железа и где чаще всего спотыкаются - с реальным примером из нашей практики.

Что считать отказоустойчивым кластером

Сначала о терминах, потому что их путают. Под «кластером» понимают три разные вещи:

• Кластер высокой доступности (HA). Виртуальные машины крутятся на узлах, а если узел падает - они автоматически перезапускаются на живом. Простой есть, но короткий: минута-две на перезапуск ВМ. Это рабочий вариант для большинства задач малого и среднего бизнеса.
• Отказоустойчивый кластер (fault tolerance). ВМ работает синхронно сразу на двух узлах; отказ одного не даёт даже секундного простоя. Дороже и требовательнее к сети - берут под то, что не должно моргать вообще.
• Балансировка нагрузки. Несколько узлов делят между собой запросы, чтобы держать высокую нагрузку. Это про производительность, а не про отказ, хотя часто идёт в связке с HA.

Если нужна теория - что это такое и зачем вообще, разобрано в статье что такое кластеризация серверов. Здесь мы про практику: как из железа и софта собрать работающую отказоустойчивую систему. На практике «отказоустойчивым» в разговоре называют и HA-кластер тоже, и в большинстве проектов SMB собирают именно его - поэтому дальше речь в основном про HA, а честный fault tolerance упомянем там, где он уместен.

Кворум: почему кластер из двух узлов - особый случай

Главная ловушка кластера - split-brain. Представьте два узла, между которыми пропала связь. Каждый считает, что второй умер, и берёт нагрузку на себя. В итоге одни и те же данные пишут две машины независимо - и вы получаете два расходящихся набора данных, которые потом не свести. Это хуже, чем простой.

Чтобы этого не случилось, кластер использует кворум - правило «работает тот, у кого большинство голосов». При трёх узлах всё просто: осталось двое - у них большинство, они и работают; одиночка себя выключает. А вот при двух узлах большинства не бывает - 1 против 1. Поэтому кластеру из двух серверов нужен третий голос:

• Witness/арбитр - маленький сторонний сервис (может жить на дешёвом мини-ПК, в облаке или на файловой шаре), который даёт решающий голос. Он не хранит данные, только голосует.
• Кворумный диск - общий диск, владение которым определяет, кто главный.

Общее хранилище или репликация: где живут данные

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

Внешнее общее хранилище (shared storage). Отдельная СХД (или дисковая полка), к которой подключены оба сервера. Данные в одном месте, узлы - только вычислители. Классика, но у внешней СХД появляется своя точка отказа, поэтому её саму берут с дублированием контроллеров и путей.

Программная репликация (гиперконвергенция). Диски стоят внутри самих серверов, а специальный софт зеркалит их между узлами по сети - общей СХД нет вообще. Так работают Starwind VSAN, Microsoft Storage Spaces Direct (S2D), Proxmox поверх Ceph или реплицируемого ZFS. Для кластера из двух узлов это часто выходит проще и дешевле, чем отдельная СХД.

Под репликацию критична сеть между узлами: зеркалирование ест полосу, и на гигабите оно станет узким местом. Закладывайте отдельные 10-гигабитные (а лучше 25) линки под синхронизацию. Подробнее про сам принцип - в разборе репликации данных между системами хранения.

Запас мощности: правило N+1

«С запасом мощности» - не про то, чтобы взять сервера помощнее на всякий случай. Это про конкретное правило: при отказе одного узла оставшиеся должны тянуть всю нагрузку. Логика простая - если у вас два узла и каждый загружен на 80%, то после отказа одного второму придётся тянуть 160% своих возможностей. Он ляжет следом, и отказоустойчивость окажется фикцией.

Отсюда правило N+1: суммарной мощности должно хватать с запасом на выход одного узла из строя.

• Два узла: каждый не должен постоянно грузиться выше ~50% по CPU и RAM, чтобы в одиночку принять всё.
• Три узла: потолок повыше, около 65%, - при отказе одного его долю делят двое.

То же касается и памяти: если все ВМ в сумме просят 200 ГБ RAM, каждый из двух узлов должен иметь эти 200 ГБ, а не 100. Память - обычно первое, во что упирается консолидация, поэтому считать запас надо именно по ней, а не по числу ядер.

По хранилищу «запас ёмкости» означает две вещи: место под рост данных (диски проще доставить, чем мигрировать массив) и свободные слоты/отсеки под будущее расширение. Кластер, который нельзя нарастить не разбирая, - плохой кластер.

Гипервизор: на чём собирать в 2026

Софтверная основа кластера - платформа виртуализации. Расклад изменился: VMware vSphere после перехода под Broadcom подорожал и для российского рынка фактически недоступен, поэтому его закладывать в новый проект не стоит. Актуальные варианты:

• Proxmox VE - открытая платформа, встроенная кластеризация и HA, хранилище через Ceph или ZFS-репликацию. Популярный выбор под SMB-кластер без лицензионных платежей. Сколько под него нужно железа - разобрано в системных требованиях Proxmox.
• Microsoft Hyper-V - если инфраструктура на Windows; failover-кластеризация штатная, хранилище через S2D. Лицензии Windows Server считать отдельно.
• Российские платформы - zVirt, ROSA Virtualization, «Брест» и другие из реестра отечественного ПО. Актуальны под импортозамещение (госсектор, КИИ).

Если виртуализация для вас тема новая, стоит начать с того, что такое виртуализация сервера и как она вообще устроена, - кластер строится уже поверх неё.

Железо под кластер: на что смотреть

Отказоустойчивость начинается не в софте, а в железе. Каждый узел должен быть избыточен сам по себе, иначе кластер просто переносит единую точку отказа на уровень ниже.

• Два блока питания на каждый узел, в идеале - от разных линий питания. Один БП умер - сервер работает.
• RAID под систему и диски под данные. Систему - на зеркало (RAID1), данные - под выбранную схему хранения (репликация или RAID на СХД).
• Сетевое резервирование: минимум две сетевые карты, агрегация линков (LACP), отдельные линки под данные кластера и под управление. Одиночный сетевой порт - единая точка отказа.
• Контроллер удалённого управления (iDRAC у Dell, iLO у HP, IPMI/BMC у Supermicro) с лицензией - чтобы управлять узлом, даже когда ОС не грузится.
• ИБП на каждый ввод. Кластер переживёт отказ узла, но не одновременное обесточивание обоих - питание тоже дублируют. Как подобрать - в обзоре видов ИБП.

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

Пример из практики: кластер на ограниченном бюджете

Чтобы не оставаться в теории - реальный проект. К нам обратилась компания, оказывающая таможенно-брокерские услуги. Задача: кластер из двух серверов под виртуализацию, с отказоустойчивым хранилищем для ВМ, непрерывным доступом к базе данных и запасом на рост. Бюджет ограничен коридором 350 000-750 000 ₽.

Инженеры собрали кластер из двух серверов Dell с такой конфигурацией на каждый узел:

• оперативная память с запасом под консолидацию ВМ;
• два блока питания - на случай отказа одного;
• четыре сетевых порта - под разведение трафика данных и управления;
• контроллер удалённого доступа iDRAC с лицензией;
• SSD в массиве под данные с возможностью расширения;
• отдельные диски под систему.

Отказоустойчивое хранилище для виртуальных машин реализовали программной репликацией между узлами (тот самый гиперконвергентный подход), под VMware vSphere / Hyper-V. Кластер укомплектовали салазками и организовали кабель-менеджмент в шкафу. Уложились в заданный бюджет, оставив заказчику запас мощности и свободные отсеки: доставить диски или ввести третий узел позже выйдет заметно дешевле, чем собирать с нуля.

Важная оговорка на 2026 год: этот проект - иллюстрация подхода, а не спецификация «повторяйте за нами». Модели серверов и платформу виртуализации сегодня подбирают под текущий рынок (Proxmox или Hyper-V вместо vSphere, актуальные поколения серверов), но логика - два избыточных узла, репликация вместо дорогой СХД, кворум, запас мощности и ёмкости - остаётся ровно той же.

Чек-лист перед сборкой

Короткий список, по которому стоит пройтись до заказа железа:

1. Сколько узлов - два (с арбитром кворума) или три?
2. Где данные - внешняя СХД или программная репликация между узлами?
3. Заложен ли третий голос (witness) против split-brain?
4. Считали ли запас по правилу N+1 - потянет ли оставшийся узел всю нагрузку (особенно по RAM)?
5. Есть ли отдельная быстрая сеть (10/25 Гбит) под синхронизацию данных?
6. Дублированы ли БП, сетевые пути, питание (ИБП на каждый ввод)?
7. Есть ли запас по ёмкости и свободные слоты под расширение?
8. Настроены и проверены бэкапы - кластер не заменяет резервное копирование?

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

Можно ли собрать отказоустойчивый кластер из двух серверов? Да, это самый частый сценарий для SMB. Но обязательно нужен третий голос (witness-арбитр) против split-brain - иначе при обрыве связи между узлами данные разъедутся.

Кластер заменяет резервное копирование? Нет. Кластер защищает от отказа железа, но не от удаления данных, шифровальщика или ошибки администратора - всё это спокойно реплицируется на второй узел. Бэкапы нужны отдельно.

Обязательна ли отдельная СХД? Нет. Для кластера из двух-трёх узлов программная репликация дисков внутри серверов (Starwind, S2D, Ceph) часто проще и дешевле внешней СХД и убирает её как отдельную точку отказа.

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

Чем HA-кластер отличается от честной отказоустойчивости (fault tolerance)? В HA при отказе узла ВМ перезапускается на живом - простой минута-две. При fault tolerance ВМ работает синхронно на двух узлах и отказ не даёт даже секундного простоя, но это дороже и требовательнее к сети.

По теме: кластеризация и high availability: как обеспечить аптайм 99,99% · отказоустойчивый файловый сервер: настройка кластера в Windows · кластер серверов 1С