ПК СВ Брест в тестовом контуре КИИ: разворачиваем, меряем, смотрим на совместимость
ПК СВ Брест попал в реестр Минцифры для виртуализации класса КИИ. Развернули его в тестовом контуре промышленного клиента и посмотрели, что получается с железом и производительностью.
ПК СВ Брест включён в реестр отечественного ПО для виртуализации класса КИИ с расширенным списком совместимого оборудования
Несколько недель назад ПК СВ Брест появился в реестре Минцифры с новым статусом: платформа виртуализации, пригодная для объектов КИИ. Заодно обновился список совместимого оборудования - добавились позиции от отечественных производителей серверов. Один из наших промышленных клиентов как раз подбирает замену VMware vSphere для сегмента АСУ ТП и смотрит именно на реестровые платформы. Совпадение удобное, развернули тестовый контур.
Что такое ПК СВ Брест
Если коротко - это отечественная платформа виртуализации на базе KVM от компании НТС. Архитектурно похожа на oVirt/zVirt: движок управления, агенты на гипервизорных узлах, веб-консоль. Продукт занимает нишу между Proxmox (без коммерческой поддержки и не в реестре) и zVirt (хорошо известный, но у нашего клиента уже были вопросы к вендору по срокам сертификации на нужный профиль ФСТЭК). ПК СВ Брест позиционируется именно под КИИ первой и второй категории - это в документах написано прямо.
Железо клиента и первые сюрпризы
Тестовый контур собран из того, что есть в текущем парке: три сервера на базе Intel Xeon E5-2600 v4, хранилище через FC-коммутатор, сеть на Broadcom NetXtreme. Ничего экзотического, стандартный промышленный парк пятилетней давности.
Установка прошла без неожиданностей - ISO, стандартный инсталлятор, гипервизорный агент на все три узла. Веб-консоль подняли примерно за час. Первый сюрприз случился позже: FC-адаптеры Emulex LP16000 в обновлённом списке совместимости есть, но значатся с пометкой «проверено на версии 3.1». У клиента были опасения, работает ли это без дополнительных телодвижений на актуальной версии. Работает - но потребовало ручной загрузки firmware через вспомогательный скрипт поддержки, которой нет в стандартном дистрибутиве. Поддержка вендора среагировала быстро, скрипт прислали в тот же день, но само по себе это симптом: список совместимости периодически обгоняет реальную готовность драйверного слоя.
Что мерили и как
Тестовый контур не production, поэтому синтетика - не главная цель. Нас интересовало три вещи:
Накладные расходы гипервизора на вычислительную нагрузку. Клиент держит на виртуалках SCADA-процессы, там важна предсказуемость латентности, а не пиковая пропускная способность. Прогнали нагрузку, имитирующую профиль клиентского приложения: результат близкий к тому, что мы видели на zVirt с аналогичным железом. KVM есть KVM, принципиального разрыва нет.
Работа с локальным NVMe и FC-хранилищем одновременно. В архитектуре клиента горячие данные на локальных NVMe, холодный архив на FC-полке. Брест обрабатывает оба пути - локальные диски как локальное хранилище ВМ, FC-тома как shared storage для live migration. Live migration проверили: ВМ переезжает между узлами без остановки, латентность во время переезда ощутимо растёт (это ожидаемо для FC без специализированной настройки), но процесс завершается корректно.
Сеть управления и сеть данных. На production-объектах КИИ это должно быть разделено. Брест позволяет это сделать настройками - отдельный интерфейс под управляющий трафик, отдельный под ВМ. Настраивается через веб-консоль, понятно, никаких скрытых ограничений не обнаружили.
Документация и соответствие требованиям КИИ
Раздел, который нас интересовал не меньше производительности. Для объекта КИИ платформа виртуализации - не просто инструмент, это часть архитектуры защиты, и под неё нужна документация: технический паспорт, модель угроз, подтверждённое соответствие требованиям ФСТЭК.
У Бреста есть сертификат ФСТЭК (уровень доверия 4), и это реальный плюс для нашего клиента - требования к защите его сегмента предполагают именно сертифицированный гипервизор. С документацией для технического паспорта - рабочий вариант: вендор предоставляет форм-факторы для включения в комплект, но заполнять их под конкретную конфигурацию всё равно нужно самостоятельно. Это норма для любой платформы такого класса, просто нужно понимать, что это работа, которую придётся делать.
Что не устроило
Два момента, которые фиксируем честно.
Первое - скорость реакции на специфические конфигурации. Ситуация с FC-адаптерами показала, что за пределами типовых конфигураций из официального списка совместимости нужно рассчитывать на плотную работу с поддержкой. Это не катастрофа, но для промышленной среды, где плановые работы строго по окну, это означает дополнительное согласование.
Второе - инструменты миграции. Импорт ВМ из VMware через OVF работает, но миграция без остановки ВМ (аналог VMware vMotion в рамках перехода платформ) - пока ручная история с промежуточными шагами. Мы уже сравнивали платформы по этому параметру - у Бреста здесь примерно тот же уровень, что у zVirt: инструмент есть, но без магии.
Промежуточный итог
Платформа рабочая. Для клиента, у которого приоритет - реестр Минцифры плюс сертификат ФСТЭК под КИИ - Брест является реальным кандидатом. Производительность на уровне аналогов, сетевое разделение работает, документальная база для регуляторных требований есть.
Вопрос с совместимостью FC-адаптеров закрыт с помощью поддержки, но сам факт требует учесть в плане: перед production-развёртыванием нужна полноценная проверка всего парка железа по актуальному списку совместимости, а не по тому, что клиент видел на сайте полгода назад. Список живёт и обновляется.
С клиентом сейчас обсуждаем следующий шаг: пилот на одном из не самых критичных сегментов сети с небольшим набором рабочих ВМ. По итогам пилота будет понятнее, идёт ли Брест в production или остаётся запасным вариантом.
В рамках аудита инфраструктуры мы помогаем оценить платформы виртуализации под требования конкретного объекта КИИ - с учётом категории, текущего железа и документальных обязательств перед ФСТЭК.