Сколько серверов нужно для отказоустойчивой виртуализации: 2, 3 или 4 узла?

Для отказоустойчивой виртуализации минимально можно использовать 2 сервера, но это компромиссная схема: почти всегда понадобится отдельный свидетель кворума, аккуратная настройка хранения данных и строгий запас ресурсов. Для большинства рабочих инфраструктур разумнее начинать с 3 узлов: такой кластер проще держит кворум, легче переживает отказ одного сервера и лучше подходит для распределённого хранения. 4 узла выбирают не потому, что это «автоматически надёжнее», а потому что такая схема даёт больше запаса мощности, удобнее переносит обслуживание и меньше проседает после аварии.

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

Главная ошибка при выборе — думать только в категориях «2 дешевле, 4 надёжнее». В реальности 2 узла могут быть хорошим вариантом для небольшого филиала, 3 узла — оптимальной базой для малого и среднего бизнеса, а 4 узла — более зрелой схемой для инфраструктуры, где важны рост, обслуживание без лишнего риска и устойчивость к перегрузкам. Конечно, 5 и более узлов кластера - это надёжнее и интереснее, но мы рассмотрим построение именно бюджетных кластеров для малого и среднего бизнеса.

Что значит отказоустойчивая виртуализация

Есть несколько уровней отказоустойчивости. Первый — обычный перезапуск виртуальных машин после падения сервера. Это самый распространённый сценарий: физический узел вышел из строя, кластер обнаружил проблему и запустил ВМ там, где есть свободные ресурсы. Второй уровень — плановая миграция без остановки ВМ, когда администратор заранее переносит нагрузку перед обновлением или ремонтом сервера. Третий уровень — почти непрерывная работа без заметной паузы, но это уже более сложная и дорогая архитектура, которая нужна не всем. Есть и четвертый уровень - когда виртуальные машины запускаются вручную, в том числе из реплик\бэкапов, но такая отказоустойчивость уже на грани её отсутствия.

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

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

Для рабочей инфраструктуры нужно проверять как минимум пять уровней:

• вычислительные ресурсы: процессоры и оперативная память;
• хранилище виртуальных машин;
• сеть управления, миграции и хранения;
• питание и резервирование силовых линий;
• резервное копирование и восстановление после логических ошибок.

Отказоустойчивая виртуализация — это не одна галочка в настройках. Это архитектура, где отказ одного компонента не должен превращаться в остановку всей системы.

Почему кворум важнее, чем кажется

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

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

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

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

Разные платформы реализуют кворум по-разному, но сама логика большинства сохраняется. Например, в документации Proxmox VE отдельно подчёркивается, что для надёжного кворума в сценариях высокой доступности нужно не менее трёх узлов.

Что влияет на выбор количества серверов

Перед выбором между 2, 3 и 4 узлами нужно ответить не на один, а на несколько вопросов. Иначе можно купить правильное количество серверов, но получить неправильную архитектуру.

1. Сколько ресурсов должно остаться после отказа. В отказоустойчивом кластере нельзя считать все процессоры и всю память как постоянно доступные. Если один узел выходит из строя, его нагрузка должна переехать на оставшиеся серверы. Поэтому применяется принцип N+1: один узел может отказать, но инфраструктура должна продолжить работу.

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

2. Где лежат диски виртуальных машин. Возможны разные варианты: внешнее общее хранилище, локальные диски с репликацией, распределённое хранилище или смешанная схема. Внешний массив может упростить миграцию ВМ, но сам должен быть отказоустойчивым. Локальная репликация снижает зависимость от отдельного массива, но требует хорошей сети и внимательного расчёта задержек. Распределённое хранилище удобно для гиперконвергентной архитектуры, но тоже не прощает ошибок в планировании.
3. Допустимое время простоя. Для одних сервисов 15–30 минут приемлемы. Для других даже несколько минут уже проблема. Обычная высокая доступность чаще означает перезапуск ВМ, а не полное отсутствие простоя. Если бизнес ожидает непрерывную работу, нужно сразу обсуждать более сложные схемы, а не просто добавлять ещё один сервер.
4. Как будет проходить обслуживание. Серверы нужно обновлять, перезагружать, чистить, ремонтировать, менять диски, сетевые карты и блоки питания. Если каждый такой процесс превращается в риск для всех сервисов, архитектура выбрана слишком близко к минимуму.
5. Есть ли место для свидетеля кворума или третьей площадки. Для двухузловых схем это почти всегда принципиально. Свидетель может находиться в другом помещении, дата-центре, облаке или на отдельной небольшой машине, если это поддерживается выбранной платформой.

Архитектура на 2 узла: минимальный вариант, но не универсальный

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

Есть несколько вариантов хранения данных.

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

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

Третий вариант: гиперконвергентная схема, где вычисления и хранение объединены на тех же физических серверах. В двухузловой конфигурации такой подход почти всегда требует свидетеля. Например, в двухузловом vSAN witness-функция выполняется на отдельном виртуальном appliance за пределами двух основных хостов.

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

Но минусы тоже существенные. При отказе одного сервера второй должен принять всю нагрузку. Значит, в нормальном режиме каждый узел нельзя забивать до предела. Часто безопасный ориентир — держать загрузку так, чтобы один сервер мог временно выдержать виртуальные машины второго. Это не всегда означает ровно 50%, но сама логика именно такая: резерв мощности должен существовать заранее.

Двухузловая схема допустима, если:

• инфраструктура небольшая;
• есть отдельный свидетель кворума;
• нагрузка умеренная;
• простой в несколько минут приемлем;
• настроены регулярные резервные копии;
• сеть хранения и репликации не построена на одном слабом коммутаторе;
• есть понятный регламент восстановления.

Лучше не выбирать 2 узла, если в инфраструктуре много тяжёлых баз данных, высокая плотность ВМ, нет отдельной сети для хранения, нет места для свидетеля, ожидается быстрый рост нагрузки или обслуживание должно проходить без риска для рабочих сервисов. В таких условиях двухузловой кластер быстро становится не экономией, а постоянным источником ограничений.

Архитектура на 3 узла: самый сбалансированный минимум

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

Главное преимущество трёх узлов — нормальная устойчивость к отказу одного сервера. Если один узел выключился, два других продолжают работу и могут принять его виртуальные машины. Конечно, это возможно только при достаточном запасе ресурсов. Если все три сервера были загружены почти полностью, отказ всё равно приведёт к проблемам. Но при грамотном расчёте трёхузловая схема уже даёт рабочий баланс между ценой и надёжностью.

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

Три узла хорошо подходят для инфраструктуры, где есть 10–50 и более виртуальных машин, несколько критичных сервисов, файловые серверы, контроллеры домена, 1С, базы данных умеренного размера, внутренние порталы, системы учёта и мониторинга. Такая схема позволяет проводить обслуживание аккуратнее: один узел можно освободить от ВМ, обновить или перезагрузить, а остальные два продолжат работу.

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

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

Архитектура на 4 узла: больше запаса, но больше нюансов

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

Но 4 узла не стоит воспринимать как автоматическое решение всех проблем. Чётное количество серверов снова поднимает вопрос кворума. В некоторых платформах потребуется свидетель, в других будет использоваться динамическое голосование или другая логика. Важно не просто поставить четвёртый сервер, а понять, как выбранная система поведёт себя при отказе узла, потере сети, отказе хранилища или потере свидетеля. Microsoft отдельно описывает роль свидетеля кворума как компонента, который участвует в голосовании и помогает кластеру сохранять высокую доступность.

С точки зрения ресурсов четыре узла дают заметное преимущество. Если кластер проектируется по принципу N+1, один сервер можно держать как расчётный резерв, а остальные использовать под рабочую нагрузку. При этом после отказа инфраструктура не обязательно переходит в режим «всё на пределе». Это особенно важно для сервисов, где падение производительности почти так же неприятно, как и простой.

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

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

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

Сравнение схем на 2, 3 и 4 узла

Из таблицы видно, что выбор не сводится к простой лестнице «2 хуже, 4 лучше». Два узла могут быть правильным решением для небольшой площадки, если есть свидетель, резерв ресурсов и понятная схема хранения. Три узла — наиболее универсальный вариант. Четыре узла дают больше эксплуатационного комфорта, но требуют большего бюджета и более аккуратного проектирования.

Как выбрать схему по допустимому простою

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

Если бизнес говорит «нам нельзя простаивать», нужно уточнять, что именно имеется в виду. Нельзя простаивать час? Нельзя простаивать десять минут? Нельзя потерять ни одной транзакции? Это разные требования и разные бюджеты. Иногда для задачи достаточно 3 узлов и хороших резервных копий. Иногда нужен 4-узловой кластер, репликация на вторую площадку и регулярные тесты восстановления.

Неочевидные ошибки при выборе количества серверов

• Считать ресурсы всех серверов как рабочие. В отказоустойчивой схеме часть мощности должна быть зарезервирована под отказ. Если кластер из трёх узлов уже в обычный день загружен на 85–90%, он не сможет спокойно пережить потерю одного сервера. Формально узлов три, но практического резерва нет.
• Строить двухузловой кластер без свидетеля. Такая схема может выглядеть экономной, но именно в ней возникает больше вопросов к кворуму. Если узлы потеряют связь друг с другом, кластер должен принять безопасное решение. Без внешнего арбитража это сделать сложнее.
• Превращать общее хранилище в единую точку отказа. Иногда компания покупает два сервера, подключает их к одному недорогому массиву и считает задачу решённой. Но если массив, контроллер, полка дисков, коммутатор или путь к хранилищу не зарезервированы, отказоустойчивость остаётся неполной.
• Забывать про сеть. Для миграции виртуальных машин, репликации дисков и работы распределённого хранения нужна стабильная и предсказуемая сеть. Один коммутатор, один сетевой путь или смешивание всех типов трафика без расчёта могут привести к тому, что серверы есть, а кластер работает нестабильно.
• Не учитывать обслуживание. Аварии случаются редко, а плановые работы — постоянно. Если для обновления гипервизора каждый раз приходится останавливать половину сервисов, архитектура плохо подходит для эксплуатации. Хороший кластер должен переживать не только внезапный отказ, но и обычную жизнь инфраструктуры.
• Путать высокую доступность с резервным копированием. Если пользователь удалил базу, вирус зашифровал файлы или приложение записало ошибочные данные, кластер честно распространит это состояние дальше. В такой ситуации спасают не дополнительные узлы, а резервные копии и проверенное восстановление.
• Не тестировать аварийные сценарии. Кластер нужно проверять до реального сбоя: отключение одного узла, потеря сети хранения, отказ свидетеля, перезапуск коммутатора, нехватка места на хранилище. Без тестов администратор узнает поведение системы только в момент аварии.
• Забывать про лицензии и поддержку. Иногда четвёртый узел кажется недорогим, пока не посчитаны лицензии гипервизора, поддержка, накопители, сетевые карты, коммутаторы, резервное питание и место в стойке. Итоговую стоимость нужно считать целиком.

Практический алгоритм выбора

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

Дальше нужно определить допустимый простой. Для части инфраструктуры достаточно восстановления за час. Для бухгалтерии в отчётный период может быть критично даже 10–15 минут. Для интернет-сервиса или производственной системы требования будут ещё жёстче. От этого зависит, хватит ли обычного перезапуска ВМ или нужна более сложная схема.

Следующий шаг — расчёт ресурсов. Нужно посчитать не только текущую нагрузку, но и запас после отказа одного узла. Если выбирается 2 узла, каждый должен быть готов принять критичные ВМ второго. Если выбирается 3 узла, два оставшихся должны выдержать нагрузку после отказа одного. Если выбирается 4 узла, стоит заранее определить, проектируется кластер под отказ одного узла или нужен более высокий резерв.

Затем выбирается схема хранения. Внешнее хранилище удобно, но должно быть отказоустойчивым само по себе. Локальная репликация требует хорошей сети и ясных правил восстановления. Распределённое хранилище хорошо сочетается с 3–4 узлами, но требует внимания к числу копий, скорости дисков, сетевым задержкам и свободному месту.

После этого проверяется кворум. Сколько голосующих компонентов будет в кластере? Нужен ли свидетель? Где он расположен? Что произойдёт, если пропадёт связь с одним сервером, свидетелем или коммутатором? Ответы на эти вопросы должны быть записаны до запуска в эксплуатацию.

Затем оценивается обслуживание. Можно ли вывести один узел из работы без остановки сервисов? Останется ли запас, если в момент обслуживания откажет другой компонент? Есть ли регламент обновления гипервизора, прошивок, драйверов, сетевого оборудования и хранилища?

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

Итог: сколько серверов выбрать

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

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

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

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