Гиперконвергентные системы хранения (HCI) в 2026: архитектура, кворум и сравнение vSAN, Nutanix, Proxmox с Ceph

Гиперконвергентная инфраструктура (HCI, Hyperconverged Infrastructure) собирает вычисления, сеть и хранение в один программный стек, который работает на каждом сервере кластера. Отдельная стойка с дисковым массивом и коммутаторами Fibre Channel не нужна: локальные NVMe и HDD каждого узла входят в общий пул, а распределённая файловая система раскладывает данные по серверам с заданным числом копий.

Прямой ответ на главный вопрос: HCI разумно выбирать там, где нужно наращивать ресурсы шагами по одному узлу, управлять кластером из единой консоли и переживать отказ сервера без остановки виртуальных машин. Для петабайтных архивов и нагруженных OLTP-баз выделенная SAN часто остаётся выгоднее по стоимости гигабайта. Подробный разбор отличий есть в статье DAS, NAS, SAN и HCI: как выбрать систему хранения.

Дальше: слои HCI, механика распределённого хранения, кворум и split-brain, восстановление после отказа узла, сравнение VMware vSAN, Nutanix, Proxmox с Ceph и SUSE Harvester, рабочие конфигурации для частного облака, VDI и филиалов, сетевые требования и предел масштабирования кластера.

Что такое гиперконвергентная инфраструктура (HCI) и зачем она нужна в 2026 году

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

Классическая SAN устроена зеркально. Тома живут в массиве, у массива есть контроллеры, кэш и полки расширения, серверы подключаются по Fibre Channel, iSCSI или NVMe-oF. Масштабирование идёт вертикально: добавляете полку или меняете контроллеры. В HCI масштабирование горизонтальное: новый узел приносит процессор, память и диски одновременно.

Что получает администратор на практике:

• Одну панель для виртуальных машин и хранилища вместо двух консолей.
• Шаг расширения размером с один сервер, без остановки кластера.
• Политику отказоустойчивости на уровне отдельной виртуальной машины: одной ВМ задаёте две реплики, другой три.
• Ниже порог входа: первый кластер из трёх узлов обычно дешевле стойки с массивом и FC-коммутаторами.

HCI не всегда выгоднее по деньгам. При больших объёмах холодных данных гигабайт в SAN на NL-SAS дисках может обойтись дешевле, потому что в HCI ёмкость покупается в комплекте с CPU и памятью. Прогнозы роста рынка HCI у разных агентств расходятся, поэтому бюджет считайте от собственной модели ёмкости и IOPS, а обзорные проценты CAGR держите только как контекст.

Кому подходит HCI: средний и малый бизнес, филиалы, VDI, частные облака, стенды разработки и тестирования. Кому нет: крупные ЦОД с петабайтами, среда с экстремальными требованиями к задержке одной базы, площадки, где регламент требует физически выделенного хранилища.

Ключевые компоненты HCI: гипервизор, SDS и сеть

Стек HCI делится на три слоя, и каждый можно выбрать отдельно, хотя не все комбинации официально поддерживаются.

• Гипервизор: VMware ESXi, KVM (в Proxmox VE и SUSE Harvester), Nutanix AHV.
• Программно-определяемое хранение (SDS): VMware vSAN, Ceph, Nutanix AOS, Longhorn.
• Сеть: 10, 25 или 100 GbE, jumbo frames, RDMA через RoCE или iWARP.

Пример на цифрах: кластер из трёх узлов, в каждом 8 NVMe по 3,84 ТБ. Суммарная сырая ёмкость около 92 ТБ, но полезная заметно меньше. Политика с двумя репликами оставляет примерно половину, с тремя - около трети. При этом каждый узел хранит свою долю данных и копии блоков соседей, поэтому отказ одного сервера не приводит к потере информации. Если данные лежат на узле без реплик, HCI вырождается в набор локальных дисков без отказоустойчивости.

Сеть несёт две нагрузки: трафик виртуальных машин и внутренний трафик репликации. Второй поток идёт между узлами постоянно, поэтому 1 GbE для кластера не подходит. Расчёт ёмкости и сетевых потоков для SDS разобран в материале программно-определяемые хранилища (SDS) в 2026 году.

Чем HCI отличается от классической SAN и NAS

Практический пример: филиал с тремя серверами и одной стойкой. Классический вариант - массив начального уровня плюс FC-коммутаторы плюс отдельное администрирование СХД. HCI-вариант - те же три сервера с локальными дисками и SDS, одна консоль, один пул ёмкости. Разница заметна в обслуживании: обновление прошивок массива и зонирование фабрики отпадают, но появляются требования к сети между узлами.

NAS не конкурирует с HCI напрямую: он отдаёт файлы по NFS или SMB, а HCI отдаёт дисковые ресурсы гипервизору. В гибридных средах NAS часто остаётся под файловые сервисы и бэкапы, а HCI занимает нишу под виртуальные машины. Классификацию всех типов хранилищ с расчётом IOPS и уровней RAID смотрите в обзоре СХД в 2026: классификация и практический выбор.

Архитектура распределённого хранения в HCI: как данные живут на узлах

Распределённое хранение делит данные на блоки или объекты и раскладывает их по узлам с заданным коэффициентом избыточности. Основных схем две. Репликация (mirroring) хранит 2 или 3 полные копии, что даёт быстрый отклик и простой ремонт, но съедает ёмкость пропорционально числу копий. Erasure coding делит данные на фрагменты и добавляет контрольные, например схема 4+2 хранит 4 фрагмента данных и 2 контрольных. Такая схема экономит ёмкость (в примере 4+2 накладные расходы 50 процентов, а не 100), но требует больше узлов и даёт выше задержку при записи.

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

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

Кворум и split-brain: как HCI избегает разделения кластера

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

Правила простые:

• Для голосования нужно нечётное число участников: 3 или 5.
• В кластере из двух узлов добавляют третий узел-свидетель (witness), который не хранит данные, но участвует в голосовании.
• Потеря кворума останавливает запись; чтение часто продолжает работать с уцелевших реплик.

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

Восстановление после отказа узла: этапы и подводные камни

Процесс восстановления состоит из четырёх этапов. Система обнаруживает пропажу узла, обычно за десятки секунд. Трафик переключается на уцелевшие реплики, виртуальные машины продолжают работу. Запускается перестройка (rebuild): недостающие копии собираются из сохранившихся данных и раскладываются по свободному месту. Когда узел возвращается, его диски синхронизируются с актуальным состоянием кластера.

Время восстановления зависит от трёх величин: объёма потерянных данных, скорости сети и скорости дисков. Ориентир: 1 ТБ данных при скорости 1 Гбит/с передаётся около 2,2 часа в идеальных условиях, с накладными расходами и конкуренцией за диск реальный процесс занимает ближе к 2,5 часа. На 25 GbE то же самое укладывается в минуты, но упирается в пропускную способность дисков.

Частые ошибки:

• Нет запаса свободного места под перестройку. Правило: держите резерв, равный объёму данных одного узла, иначе rebuild не стартует.
• Кластер собран на 1 GbE. Перестройка занимает сутки, и всё это время система работает без запаса по отказоустойчивости.
• Нет мониторинга состояния деградации. Администратор узнаёт о незавершённом rebuild только при втором отказе.
• Все реплики размещены на дисках одного узла из-за ошибки в правилах размещения, и отказ сервера уносит обе копии.

VMware vSAN, Nutanix и Ceph ускоряют перестройку за счёт параллельного копирования на несколько узлов и приоритизации трафика восстановления, но полностью скрыть физику не могут.

Обзор ключевых HCI-решений: VMware vSAN, Nutanix, Proxmox с Ceph и SUSE Harvester

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

VMware vSAN: архитектура, лицензирование и типовые сценарии

vSAN работает внутри ESXi и собирает локальные диски узлов в единое хранилище. Виртуальным машинам хранилище отдаётся по тем же правилам, что обычный датастор, а избыточность задаётся политикой хранения: число отказов, которые должен пережить объект, метод (репликация или erasure coding), тип дисков.

Минимальная конфигурация для отказоустойчивости: три узла плюс свидетель для кворума, если используется двухузловая схема или растянутый кластер. Лицензирование идёт по числу процессоров или по ёмкости, и на больших кластерах статья расходов становится заметной. Сценарии, где vSAN встречается чаще всего: частное облако на vSphere и VDI. Требования к платформе жёсткие: минимум 10 GbE, на all-flash рекомендуется 25 GbE, а оборудование должно быть в списке совместимости (HCL). Поставить vSAN на неподдерживаемые контроллеры и диски можно, но получить отказ в поддержке при инциденте тоже.

Nutanix: особенности, управление и стоимость владения

Nutanix предлагает собственный гипервизор AHV и проприетарную распределённую файловую систему AOS, при этом поддерживает запуск на ESXi. Управление идёт через консоль Prism, которая закрывает и виртуальные машины, и хранилище, и мониторинг в одном интерфейсе. Минимальный рабочий кластер - три узла.

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

Proxmox с Ceph: open-source HCI и подводные камни

Proxmox VE включает поддержку Ceph и позволяет собрать HCI-кластер без вендорских лицензий. Минимально работоспособны три узла, но для стабильности при выходе одного сервера лучше планировать пять: на трёх узлах запас по отказоустойчивости почти исчезает после первой потери. Ceph требует выделенных SSD или NVMe под журналы и сеть 10 GbE и выше, а на практике ставят отдельный интерфейс под кластерный трафик.

Типовые ошибки, которые ломают кластер:

• Некорректная CRUSH-карта: правила размещения отправляют несколько реплик на диски одного узла, и защита от отказа сервера не работает.
• Малое число мониторов или их размещение на перегруженных узлах: кластер теряет кворум при плановых работах.
• Экономия на сети: 1 GbE, отсутствие jumbo frames, общий интерфейс под трафик ВМ и репликацию.
• Игнорирование расчёта свободного места под перестройку, из-за чего первый же отказ оставляет кластер в состоянии, где rebuild не запускается.

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

SUSE Harvester: HCI на базе Kubernetes и KVM

Harvester объединяет KVM, Kubernetes и Longhorn как слой хранения. Виртуальные машины запускаются через KubeVirt, а кластер управляется из Rancher, что удобно, если в компании уже используется этот стек оркестрации. Минимальная конфигурация - три узла.

Решение ориентировано на смешанные нагрузки: контейнеры и виртуальные машины на одном пуле ресурсов. Основные сценарии: edge-площадки, филиалы, небольшие частные облака, где важна единая автоматизация через API Kubernetes. Harvester заметно моложе vSAN и Nutanix, поэтому перед закупкой оборудования стоит отдельно проверять список поддерживаемых дисков и сетевых карт, а также требования Longhorn к задержке дисков: он чувствителен к медленным SATA SSD.

Практические сценарии применения HCI: частное облако, VDI и филиалы

Частное облако на HCI: проверенные конфигурации

Рабочая конфигурация среднего размера: 5 узлов, в каждом 2 процессора, 256 ГБ RAM, 2 NVMe под кэш или журналы и 4 HDD по 8 ТБ под ёмкость, сеть 25 GbE на кластерном интерфейсе. Пять узлов дают запас: один сервер может уйти на обслуживание, второй отказать внезапно, и кластер сохранит данные с репликацией 3.

Для частного облака важны изоляция ресурсов между командами и возможность живой миграции. Политики хранения настраивают для каждого пула: базы данных получают репликацию 3 на NVMe, тестовые стенды - репликацию 2 на HDD. Типовая ошибка - экономия на сети. Кластер на 1 GbE с репликацией 3 и активной миграцией упирается в канал, виртуальные машины получают задержки, а rebuild растягивается на сутки.

VDI на HCI: особенности и типовые ошибки

VDI предъявляет самые высокие требования к задержке и IOPS, потому что одновременно работают десятки или сотни десктопов, и все они обращаются к диску случайным образом. Ориентир для офисных профилей: не более 10-15 мс отклика на чтение, иначе пользователи жалуются на «тормоза» при входе в систему. All-flash кластер от 4 узлов закрывает нагрузку в 100 виртуальных десктопов без заметных просадок, гибридные конфигурации подходят для лёгких сценариев с малым числом одновременных сессий.

Частые ошибки при развёртывании VDI на HCI:

• Недостаточный кэш на узлах: рабочие наборы десктопов не помещаются, и чтение уходит на медленные HDD.
• Сканирование антивирусом всего диска одновременно по расписанию: пиковая нагрузка совпадает с утренним входом пользователей.
• Игнорирование профилей и контейнеров пользовательских данных: без выноса профилей узел перегружается лишними операциями записи.
• Запуск 100 десктопов на трёх узлах в расчёте на репликацию 2 без запаса по CPU и памяти.

HCI в филиалах: 2-узловые и 3-узловые конфигурации

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

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

Ограничения HCI при масштабировании и требования к сети

HCI масштабируется линейно до определённого размера кластера, обычно это 10-20 узлов. Дальше растёт восточно-западный трафик: данные реплицируются между узлами, и объём служебных потоков начинает конкурировать с полезной нагрузкой. При 10 узлах и репликации 3 внутренний трафик может достигать нескольких Гбит/с в пике, а на перестройке после отказа упирается в пропускную способность сети целиком.

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

Сетевые требования: пропускная способность, задержки и RDMA

Сеть в HCI несёт ту же роль, что backplane в классическом массиве, поэтому экономия на ней бьёт по всей системе. Базовые требования:

• Пропускная способность от 10 GbE, для all-flash кластеров рекомендуется 25 GbE, для крупных кластеров 100 GbE.
• Задержка между узлами в пределах десятых долей миллисекунды, на практике ориентир ниже 1 мс.
• Jumbo frames (MTU 9000) на всех интерфейсах кластерного трафика.
• Отдельные VLAN или физические интерфейсы под репликацию, чтобы трафик ВМ и перестройка не мешали друг другу.
• RDMA (RoCE или iWARP) при больших кластерах: он снимает нагрузку с CPU и снижает задержку.

Для RDMA нужны сетевые карты с поддержкой RoCE, а коммутаторы должны корректно обрабатывать приоритеты трафика без потерь (PFC, ECN). Неправильная настройка QoS в RDMA-сети приводит к просадкам, которые трудно диагностировать: сеть формально работает, а кластер теряет пакеты при перегрузке. Ошибки в сети остаются главной причиной проблем с HCI, и проверять настройки стоит до переноса продакшн-нагрузки.

Когда HCI не подходит: сценарии, где SAN выигрывает

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

• Объёмы в петабайтах с холодными данными: стоимость гигабайта в SAN ниже, потому что ёмкость не связана с процессорами и памятью узлов.
• Отдельные высоконагруженные базы данных OLTP: массивы дают предсказуемую задержку и большой кэш, а в HCI запись проходит через сеть репликации.
• Один очень крупный кластер, 100 и более узлов: управление распределением становится сложнее, а восточно-западный трафик требует выделенной фабрики.
• Требования регламента на физически выделенные диски и разделение полномочий между командами ВМ и хранилища.

Выбор стоит делать от конкретных требований: измеренная задержка, требуемый IOPS, объём и профиль нагрузки. Общая архитектурная логика и критерии разобраны в руководстве архитектуры хранилищ: DAS, NAS, SAN и HCI.

Как выбрать и внедрить HCI: практические рекомендации

Критерии выбора HCI-решения под вашу задачу

Оценивайте решение по порядку, от workloads к платформе.

1. Профиль нагрузки. VDI и базы данных требуют IOPS и низкой задержки, архивы и бэкапы - ёмкости. От этого зависит выбор all-flash против гибридного кластера.
2. Требуемая отказоустойчивость. Репликация 3 или erasure coding 4+2 дают разный запас по ёмкости и разное поведение при отказе.
3. Бюджет на лицензии. Открытые Proxmox с Ceph и Harvester экономят на подписках, но требуют своей экспертизы. vSAN и Nutanix стоят дороже и дают вендорскую поддержку.
4. Совместимость с оборудованием. Проверьте HCL вендора до закупки серверов, контроллеров и сетевых карт.
5. Навыки команды. Ceph с плохо настроенной CRUSH-картой опаснее, чем лицензия на vSAN, купленная вовремя.
6. Планы масштабирования. Если через год ожидается удвоение, проверьте, во сколько обойдётся добавление узлов и не упрётесь ли вы в предел кластера.

Практический ориентир: для VDI важнее IOPS и задержка, для архива - стоимость гигабайта, для филиала - минимальное число узлов и простота обслуживания.

Пилотный проект и тестирование HCI перед внедрением

Пилот строится на трёх узлах и повторяет реальную топологию сети. Порядок действий:

1. Собрать три узла с тем же типом дисков и сетевых карт, что планируются в закупке.
2. Настроить кластерную сеть: VLAN, MTU 9000, при необходимости RDMA, проверить потери пакетов.
3. Развернуть SDS и создать пулы с целевой политикой репликации.
4. Залить тестовые данные и прогнать нагрузку, близкую к рабочей. Для случайного чтения и записи используют fio с профилем, повторяющим поведение приложения.
5. Замерить IOPS, задержку чтения и записи, поведение при пиковых всплесках.
6. Провести контролируемый отказ: погасить один узел и засечь, за сколько система восстановилась и как это отразилось на отклике.
7. Заполнить пул до проектного уровня и проверить, остаётся ли место под перестройку.

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

Отдельно проверьте эксплуатационные вещи: как обновляется SDS без простоя, сколько времени занимает добавление узла, как настроен мониторинг деградации, есть ли документация для дежурной смены. HCI упрощает управление, но не отменяет требования к регламентам.