Гиперконвергентная инфраструктура для ведомства: сравнение с СХД

С чего начинается выбор: проблема и ограничения ведомства

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

Отсюда и выбор: гиперконвергентная инфраструктура (HCI) или классическая схема «серверы плюс СХД». На бумаге обе решают виртуализацию и хранение. На деле они отличаются тем, как быстро их можно запустить, какие компетенции нужны в сопровождении и как решение будет жить через год, когда нагрузка вырастет.

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

Пример. Если планируется миграция 60-80 виртуальных машин в короткое окно и нет желания зависеть от редких специалистов по SAN, HCI часто выглядит логично. Если уже есть зрелая команда по СХД и нужно масштабировать хранилище отдельно от вычислений, классика обычно дает больше гибкости.

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

Что такое HCI простыми словами

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

Типичная HCI-система состоит из узлов (серверы с CPU, RAM и дисками), сети для обмена данными между узлами и программного слоя управления. Этот слой объединяет диски всех узлов в общее хранилище и дает единое окно управления: где работают ВМ, сколько занято места, какой узел перегружен.

Отказоустойчивость достигается за счет кластера. Данные виртуальных машин обычно хранятся с копированием на несколько узлов. Если один узел выходит из строя, виртуальные машины поднимаются на соседних, а данные остаются доступными благодаря копиям. Чем выше уровень защиты, тем больше ресурсов уходит на «запас».

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

Важно помнить: HCI - не «магия», а другой способ собрать тот же ЦОД. Процессоры, память, диски, сеть и программная платформа все равно выбираются, просто управляются как единый комплекс.

Классическая схема «серверы плюс СХД»: как она устроена

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

Типовой набор включает кластер гипервизора на серверах, отдельную СХД, отдельную сеть для трафика хранения (FC или iSCSI) и инструменты виртуализации и резервного копирования.

Из-за разделения слоев часто есть и разделение ответственности: администратор серверов и гипервизора, администратор СХД, сетевой инженер, специалисты по бэкапу и ИБ.

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

Сложности чаще начинаются на стыках. Чтобы поднять новый пул ВМ, нужно выделить LUN на СХД, настроить зонирование или VLAN, проверить мультипасинг, политики доступа, совместимость прошивок и драйверов, а затем протестировать отказоустойчивость. Чем больше участников и «точек настройки», тем важнее заранее распределить роли и согласовать план работ.

Сроки внедрения: где быстрее и почему

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

HCI обычно запускается быстрее, потому что компонентов меньше, а часть настройки идет по шаблону. Но преимущество держится только при подготовленной сети: согласованные L2/L3-схема, VLAN, MTU, резервирование каналов и адресное пространство. Если этого нет, «быстрый» кластер легко теряет выигрыш.

Классическая схема чаще дольше по срокам, потому что этапов больше: отдельно серверы, отдельно СХД, отдельно SAN-сеть, больше совместимостей и точек передачи ответственности между командами. Даже при хороших поставках время уходит на «стыковку» и устранение мелких расхождений в настройках.

Что проверить, чтобы не сорвать календарь

До старта полезно пройтись по нескольким пунктам:

• готовность площадки: порты, стойки, питание, охлаждение;
• утвержденные схемы сети, адресация, правила ИБ и доступов;
• план миграции и окно простоя для действующих сервисов;
• сценарий приемо-сдаточных испытаний и критерии «введено»;
• кто отвечает за интеграцию и поддержку в первые недели.

Если региональному ведомству нужно поднять виртуальную инфраструктуру за 6-8 недель, HCI часто укладывается при готовых сетях и документах. При проекте с SAN, зонированием и отдельными контурами хранения сроки классики обычно растягиваются. В таких проектах ускорение часто начинается не с «железа», а с сетевой подготовки и документов.

Сопровождение и компетенции: кто будет поддерживать

Поддержка часто решает выбор сильнее, чем характеристики.

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

Для классики набор компетенций шире. Помимо виртуализации нужны знания СХД (RAID-политики, пулы, производительность), SAN (FC/iSCSI), зонирование и диагностика путей. Это не «сложно само по себе», но требует практики и времени.

В любом варианте стоит заранее закрыть базовые роли: виртуализация, сеть, резервное копирование и восстановление (с тестами), ИБ (учетки, журналы, сегментация), а также процесс инцидентов и изменений.

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

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

Масштабирование: что происходит при росте нагрузки

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

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

В классической схеме рост раздельный: не хватает мощности - докупаете серверы, не хватает емкости или IOPS - расширяете СХД. Это часто экономичнее, когда рост неравномерный (например, резко увеличились объемы хранения из-за архивов или видео, а вычисления почти не изменились).

Частый спорный момент в HCI - «нужно только больше дисков». В ряде архитектур это означает покупку дополнительных узлов вместе с CPU/RAM. Иногда это решают конфигурациями с упором в диски или отдельными storage-узлами, но это нужно уточнять до закупки.

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

Экономика и закупка для ведомства: на что смотреть кроме цены

При сравнении HCI и классики часто смотрят только на ценник оборудования. Для ведомства важнее общая стоимость владения: внедрение, сопровождение и риски простоев.

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

Сроки и трудозатраты нередко меняют итог. Если классика требует больше согласований, интеграции и «сшивки» компонентов, проект идет дольше, а команда дольше занята рутиной. Иногда более дорогая поставка окупается тем, что ввод в эксплуатацию быстрее и меньше риск затяжной миграции.

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

Отдельный пункт - прозрачность цепочки поставок и сервис по стране: предсказуемые сроки, понятное происхождение оборудования, возможность быстро восстановиться при отказе. Если важны требования по локальному содержанию, проверьте статус производителя и подтверждающие документы. В Казахстане это часто критично для закупок с преференциями: официальный статус отечественного производителя и сертификаты (ISO 9001, ISO 14001, ISO 45001) снимают часть бюрократических рисков.

Как выбрать: план для руководителя ИТ и заказчика

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

Полезно сформулировать цели в проверяемом виде: «перевести 60 ВМ на новую платформу без остановки критичных систем», «обеспечить отказоустойчивость уровня N+1», «сократить время ввода типового сервиса до 1 дня». Дальше - короткая последовательность:

• Описать профиль нагрузки простыми метриками: количество ВМ, объем данных, прирост в год, пиковые часы, доля критичных систем.
• Зафиксировать ограничения: сроки внедрения, штат и компетенции, требования к изоляции, допустимые окна простоя.
• Сначала определить бэкап и DR: где хранятся копии, какой RPO/RTO нужен, как проходит восстановление при отказе площадки.
• Провести пилот на 1-2 типовых сервисах и оценить не только скорость, но и сопровождение: обновления, диагностика, время реакции.
• Оформить критерии приемки и план миграции с понятным порядком отката.

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

Пример сценария: региональное ведомство и обновление серверной

Региональное ведомство держит в серверной несколько ключевых сервисов: файловые ресурсы, домен, почту или коллаборацию, 1-2 ведомственные системы, базу данных для отчетности, резервное копирование. Штат небольшой: 2-3 администратора на все, включая сеть и рабочие места. Остановка на несколько часов уже болезненна, а окно для работ обычно ночное или в выходные.

Вариант A: HCI-кластер

Типовой старт - 3 узла в кластер: вычисления, хранение и отказоустойчивость в одном контуре. Развертывание часто укладывается в короткий план: установка, настройка кластера, перенос ВМ.

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

Вариант B: серверы плюс СХД

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

Через 12-18 месяцев, когда растут данные (сканы, архивы, базы), в HCI обычно добавляют 1-2 узла и получают прирост и по дискам, и по CPU/RAM. В классике можно расширить только СХД, не трогая вычисления, но придется планировать лицензии, порты, полки и, иногда, миграции.

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

Частые ошибки при выборе HCI и классики

Самая частая проблема - решение принимают по общим обещаниям («HCI проще» или «СХД надежнее»), а не по реальным нагрузкам и процессам.

Вот ошибки, которые встречаются чаще всего:

• Выбирать HCI без понимания профиля хранения. Если много тяжелых баз данных, журналирования и быстрый прирост, нужно заранее понимать, что важнее: IOPS, задержка, объем или темп роста.
• Не проверить сеть и схему отказоустойчивости. HCI особенно чувствителен к корректной сети между узлами и запасу по пропускной способности.
• Смешать критичные и тестовые системы без правил. Без изоляции по ресурсам тестовые задачи могут «съесть» производительность в неожиданный момент.
• Отложить резервное копирование «на потом». Окна бэкапа, требования к хранению копий и восстановлению (RPO/RTO) должны быть ясны до закупки.
• Сравнивать варианты только по цене оборудования и забывать про внедрение, обучение и поддержку.

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

Короткий чеклист перед решением

Перед выбором полезно зафиксировать несколько вещей на бумаге. Обычно хватает 1-2 встреч, но это экономит недели на согласованиях и переделках.

Сначала перечислите системы, которые будут жить в новой среде, и задайте критичность хотя бы по двум ориентирам: сколько простоя допустимо (RTO) и сколько данных можно потерять (RPO). Затем уточните реальный рост: объем данных, темп увеличения, наличие архивов, сканов, видеонаблюдения и резервных копий.

Минимальный набор проверок:

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

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

Следующие шаги: как подготовить проект и не затянуть внедрение

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

Дальше сравните 2-3 варианта (HCI, классика, смешанный) по одной таблице критериев: сроки, риски, поддержка, как растет мощность.

Практичная последовательность, которая чаще всего экономит время:

• собрать профиль нагрузки (CPU, RAM, диски, сеть) и рост на 2-3 года;
• согласовать критерии приемки и требования к производительности;
• запланировать пилот на типовых сервисах с заранее согласованными измерениями;
• составить план миграции «волнами» и порядок отката;
• утвердить минимальный контур сопровождения: дежурства, мониторинг, окна обновлений.

Если внутри мало опыта внедрения инфраструктуры в госсекторе, полезно подключить интегратора, который умеет вести пилоты, миграции и документацию под проверку. В Казахстане это часто делают вместе с локальным производителем и системным интегратором, например GSE.kz: у компании есть собственные серверы серии S200 для ЦОД и услуги системной интеграции с круглосуточной технической поддержкой по стране.