Гиперконвергентная инфраструктура (HCI): что это и когда выгоднее классической схемы

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

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

Что такое HCI и чем отличается от классической схемы

Классическая инфраструктура - это три отдельных слоя: серверы под виртуализацию, СХД и сеть хранения (SAN). Каждый слой проектируется, закупается и обслуживается отдельно: разные вендоры, разные специалисты, отдельные точки отказа. Связка HCI и классическая инфраструктура устроена иначе. Типовая нода HCI - сервер с локальными NVMe-дисками, гипервизором и программно-определяемым хранением. Несколько таких нод объединяются в кластер, который видит локальные диски всех узлов как единый пул.

Ключевая разница - модель масштабирования. Классическая схема растёт «вертикально»: добавили дисков в полку, заменили контроллер, расширили лицензию СХД. HCI растёт «горизонтально» - добавили ноду, и в кластере пропорционально стало больше CPU, ОЗУ и хранилища. Управление тоже одно: единая консоль на кластер вместо отдельных интерфейсов под серверы, СХД и SAN. Для штатного ИТ-отдела это снимает требование держать выделенного СХД-инженера и сетевика под фабрику хранения. Зависимость от вендора снижается, но не исчезает: у vSAN и Storage Spaces Direct действует сертифицированный список совместимости (HCL), и замена дисков или сетевых карт ограничивается выбором модели из этого списка. Это всё равно проще, чем пересобирать SAN-фабрику, но сверять HCL перед закупкой обязательно.

По четырем практическим критериям подходы сравниваются так.

Архитектура HCI: ноды, гипервизор, программно-определяемое хранение

Гиперконвергентное решение собирается из пяти компонентов.

1. Нода - стандартный 1U или 2U-сервер с локальными NVMe или SSD, мощным CPU под виртуализацию и сетевыми картами 25/100 GbE для трафика между узлами.
2. Гипервизор - VMware ESXi, Microsoft Hyper-V, Proxmox VE или российские платформы (zVirt, ROSA Virtualization, базис.DynamiX). Выбор задаёт стек управления и определяет совместимость с уже работающими системами.
3. Программно-определяемое хранение (SDS) - слой, который объединяет локальные диски нод в общий пул с репликацией, снапшотами и тонким резервированием. Реализуется через VMware vSAN, Microsoft Storage Spaces Direct (S2D) или Ceph - это разные продукты с разной моделью лицензирования и эксплуатации.
4. Сеть - выделенный канал 25/100 GbE между нодами. На нём держится производительность кластера и латентность хранилища. На небольших инсталляциях допустимо 10 GbE, но запас по скорости рекомендуется закладывать сразу - расширить сеть в работающем кластере дороже, чем заложить с запасом.
5. Единый интерфейс управления - кластер, виртуальные машины, диски, сеть и обновления видны в одной консоли.

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

Когда HCI выгоднее классической инфраструктуры

Виртуализация и VDI на 50–300 пользователей

Главный сценарий, где гиперконвергентное решение окупается. Компания на 100–300 рабочих мест с парком виртуальных машин под 1С, файловые сервисы, терминальные сессии - это типовая нагрузка HCI. Три-четыре ноды покрывают потребности по производительности и отказоустойчивости, причём не нужны выделенный СХД-специалист и SAN-фабрика. Срок развёртывания «коробочного» гиперконвергентного решения - 1–2 недели против 1,5–3 месяцев на классическую схему: гиперконвергент приходит готовым стеком, классика собирается из 3–4 закупок и интеграционного проекта.

На VDI картина ещё показательнее: профили пользователей и образы виртуальных рабочих мест живут в одном пуле, миграция между узлами идёт прозрачно, плановое обслуживание не требует окна простоя. Эффект для бюджета в горизонте 2–3 лет складывается из трёх статей: отсутствуют лицензии выделенной СХД, исключается SAN-фабрика из спецификации, сокращаются часы СХД-инженера на сопровождение.

Региональные офисы и распределённые филиалы

HCI хорошо ложится в логику «коробочного» филиала: 2–3 ноды на площадке закрывают локальные сервисы (контроллер домена, файловый ресурс, видеонаблюдение, кассы), управление идёт из головного офиса. По сравнению с классикой это радикально другая логика: вместо отдельных серверов, NAS и коммутаторов - один стек, который ИТ-отдел разворачивает по шаблону. Не требуется выезд СХД-инженера на место, обслуживание сводится к стандартным процедурам: добавить ноду, заменить диск, накатить обновление кластера. Для сетей из 10–30 филиалов это сильно снижает OpEx и упрощает планирование расширений.

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

Когда классическая схема всё ещё лучше

HCI - не универсальная замена классической инфраструктуре. Три ситуации, где трёхуровневая архитектура выигрывает.

1. Высоконагруженные базы данных с предсказуемой потребностью в IOPS. Выделенная СХД на enterprise-NVMe и SAN-фабрика дают стабильную задержку, которую сложно повторить на гиперконвергентном кластере: на HCI latency хранилища зависит от состояния сети между узлами и текущей нагрузки соседей по кластеру. Для биржевых, банковских и расчётных задач это критично.
2. Очень большие объёмы хранения с разной температурой данных (горячие/тёплые/холодные). Классическая СХД с тирингом и отдельными уровнями дисков (NVMe, SAS, NL-SAS) обходится дешевле, чем растягивать пул HCI до десятков и сотен ТБ NVMe.
3. Регуляторные требования к изоляции данных и сред. Там, где нужен физически отдельный СХД с отдельным контуром управления и собственной аттестацией (КИИ, ГИС, банковские контуры), HCI юридически и архитектурно неудобен.

Классическая схема остается выгоднее там, где нагрузка на вычисления и на хранение растет неравномерно, например, архивное хранилище видеонаблюдения на сотни терабайт при относительно скромных вычислительных потребностях. В HCI пришлось бы наращивать узлы целиком, включая процессоры и память, ради дополнительного объема хранения, что увеличивает стоимость гигабайта.

В крупных компаниях обычно встречается гибрид: HCI закрывает виртуализацию и VDI, классическая СХД - тяжёлые СУБД и долгосрочный архив. Это не выбор «или-или», а распределение задач по слоям инфраструктуры: каждому сервису та архитектура, в которой он живёт лучше всего.

Экономика HCI: CapEx, OpEx и TCO

Главный аргумент бизнеса в пользу HCI - не цена железа, а совокупная стоимость владения. На бумаге классическая схема выглядит дешевле по CapEx (особенно если СХД достаётся со скидкой и продаётся как готовое решение), но при пересчёте на 3–5 лет картина меняется. OpEx складывается ниже за счёт трёх вещей: одна консоль управления вместо трёх, обновление кластера одной процедурой вместо отдельных контуров СХД и SAN, отсутствие выделенного СХД-специалиста в штате. Решение о выборе подхода поэтому принимается не по строке «стоимость закупки», а по TCO на горизонте жизни инфраструктуры.

Где HCI экономит и где может оказаться дороже

Экономия на сопровождении: один стек вместо трёх, обновления централизованно, штатный ИТ-инженер обходится без выделенного СХД-специалиста. Дополнительный выигрыш - интеграционные работы: гиперконвергентное решение приходит готовой связкой, проект занимает недели, а не месяцы. Меньше интеграционных часов в смете и оплат разным подрядчикам за стыковку оборудования. Где HCI дороже - лицензии гипервизора и SDS обычно считаются по ядрам и по объёму хранилища, и при больших объёмах эта часть начинает доминировать в смете. Для нагрузок с дорогими лицензиями (например, СУБД на сотни ядер) экономика часто разворачивается в обратную сторону, и классика выходит ощутимо дешевле.

Расчёт узла HCI

Типовая производственная нода — это два процессора на 32–64 ядра суммарно, 256–1024 ГБ RAM (объем определяется плотностью ВМ) и двухуровневое хранилище: NVMe под кеш и SSD под capacity-слой. Важное требование к дискам — наличие PLP (Power Loss Protection): без защиты от потери питания при сбое теряются данные из буфера, поэтому consumer-накопители здесь не применяют.

Канал ноды — минимум два порта 25 GbE, для крупных инсталляций 100 GbE с RDMA. Коэффициент дедупликации и сжатия (data reduction) при планировании полезной емкости закладывают консервативно и проверяют на пилоте, потому что он зависит от типа данных. Серверы в кластер подбирают одинаковой конфигурации, чтобы SDS распределял данные равномерно. Запас по вычислительным ресурсам под рост числа виртуальных машин на 20–30% в горизонте двух-трех лет закладывают в расчет сразу.

HCI на 3 серверах

Минимальный кластер — 3 узла: они сами образуют кворум и переживают отказ одного узла без потери данных и без остановки ВМ. При двух узлах нужен внешний witness, иначе кластер не может сам определить, какая из двух копий данных актуальна при разрыве связи между ними. Три узла годятся для старта и филиалов, однако на время отказа или обслуживания одной ноды кластер теряет запас отказоустойчивости, поэтому для production закладывают 4–8 нод.

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

Российские платформы HCI

При новом строительстве в России фокус смещается на отечественные платформы и open-source. Российские решения обычно используют KVM или собственный гипервизор и программный слой SDS, который объединяет вычисления с распределенным хранилищем.

1. Basis. Решения компании «Базис» входят в реестр российского ПО, имеют сертификат ФСТЭК и применяются в госсекторе и на объектах КИИ.
2. vStack HCI. Построен на FreeBSD, гипервизоре bhyve и ZFS и объединяет SDS, вычисления и сеть в едином программно-определяемом решении.
3. Deckhouse Virtualization. Kubernetes-нативная гиперконвергенция от «Флант» на базе KubeVirt и собственного реплицируемого хранилища на DRBD (поддерживается и подключение Ceph). Удобна там, где инфраструктура уже строится вокруг контейнеров.

4. Proxmox VE + Ceph и oVirt + GlusterFS. Open-source связки бесплатны по лицензии, но требуют собственных компетенций и не дают вендорской поддержки. Как такая схема выглядит на практике, показывает разбор Proxmox VE и Ceph: кластер на 3 узла.

Часть российских платформ включена в реестр российского ПО.

Поэтому при закупках по 44-ФЗ и 223-ФЗ заказчик проверяет актуальную реестровую запись и условия национального режима для конкретной версии продукта.

Зарубежные платформы для новых проектов не рассматривают: Nutanix ушел из России, а VMware vSAN и Microsoft Storage Spaces Direct остаются вариантом только для существующих инсталляций. Тем, кто сопровождает такие кластеры, пригодится разбор Storage Spaces Direct в кластере Windows Server.

Эксплуатация HCI

После запуска основная работа смещается в мониторинг емкости пула и состояния нод. Заполнение SDS выше 70–80% ухудшает производительность и осложняет восстановление после отказа, поэтому за свободным местом следят с запасом. Обновления гипервизора и storage-агента выполняют по одной ноде (rolling update), чтобы система оставалась в работе.

При отказе ноды система восстанавливает недостающие копии на оставшихся, а на время ребилда нагрузка на канал и диски растет — это тоже закладывают в проектную емкость. Регулярно проверяют, что политика репликации или erasure coding соответствует реальной критичности данных, а witness-узел кворума доступен.

Типовые ошибки

Первая ошибка — запуск трех узлов в production без запаса на отказ: при выходе одной ноды из строя система теряет отказоустойчивость до восстановления, поэтому для production закладывают минимум 4 узла. Вторая — сеть 1 GbE между нодами: такой канал не тянет storage-трафик и становится узким местом всей инсталляции.

Третья распространенная ошибка — consumer NVMe без PLP вместо enterprise-накопителей: при сбое питания теряются данные из буфера записи, а гарантий по ресурсу и стабильной задержке такие диски не дают. Все три экономят на старте и дорого обходятся в эксплуатации.

Как выбрать: чек-лист

Перед решением в пользу гиперконвергенции пройдите по пунктам:

• Нагрузка однородна и масштабируется горизонтально (VDI, филиалы, общая виртуализация);
• Есть бюджет на сеть 25/100 GbE с RDMA между нодами;
• Для production закладывается от 4 узлов с запасом на отказ одного;
• Если нужен статус реестра или сертификат ФСТЭК, выбирается российская платформа из реестра.

Если по большинству пунктов ответ «да», гиперконвергенция даст выигрыш по TCO и скорости развертывания. Если преобладают крупные изолированные СУБД, объем данных растет намного быстрее вычислений или речь идет про 1–3 сервера, сравните вариант с классической СХД.

Часто задаваемые вопросы (FAQ)

Что такое гиперконвергентная инфраструктура?

Это архитектура ЦОД, которая объединяет вычисления, хранение и сеть в одном программно-определяемом узле. Локальные диски всех узлов собираются в общий пул слоем SDS, а отдельный дисковый массив не нужен.

Чем HCI отличается от классической SAN-архитектуры (HCI vs SAN)?

Ключевое различие HCI и SAN-архитектуры — источник хранения. В 3-tier данные лежат на выделенной СХД, к которой серверы идут по Fibre Channel. В HCI роль хранилища выполняет SDS поверх локальных дисков узлов, а трафик идет по Ethernet без FC-фабрики.

Сколько узлов минимум для HCI?

Технический минимум — 3 узла, которые сами образуют кворум, а компактные ROBO-конфигурации стартуют с 2 нод и внешнего witness. Для production закладывают минимум 4 узла, чтобы сохранить отказоустойчивость при выходе одного из строя.

Какая сеть нужна между узлами HCI?

10 GbE — минимум для тестового стенда, 25 GbE — стандарт для production, 100 GbE с RDMA (RoCE v2) — для крупных инсталляций и AI. Канал 1 GbE для HCI непригоден.

Работает ли VMware vSAN в России?

Существующие инсталляции vSAN продолжают работать, но это legacy-стек: новые лицензии официально недоступны, а после смены модели лицензирования Broadcom многие компании планируют миграцию на российские платформы.

Какие российские HCI есть?

Основные варианты — решения «Базиса», vStack HCI и Deckhouse Virtualization. Платформы «Базиса» входят в реестр российского ПО и имеют сертификат ФСТЭК, Deckhouse Virtualization — Kubernetes-нативная гиперконвергенция.

Что лучше: HCI или 3-tier для 1С?

Для типовой 1С на кластере виртуализации HCI работает хорошо. Если это одна крупная база с жесткими требованиями к задержке, стоит сравнить вариант с выделенной СХД, где хранение не конкурирует за CPU с вычислениями.

Можно ли собрать HCI на open-source (Proxmox + Ceph)?

Да, связка Proxmox VE плюс Ceph — распространенный open-source-вариант гиперконвергенции. Она бесплатна по лицензии, но требует собственных компетенций по Ceph и не дает вендорской поддержки, поэтому подходит командам с сильным DevOps.