Реестр отечественного ПО и VMware: помогаем заказчику составить обоснование закупки

Постановление Правительства №1236 обязывает государственные органы при закупке ПО проверять реестр отечественного ПО и, если аналог найден, обосновывать, почему не берут его. Звучит просто. На практике «обоснование» - это не просто написать «нам нравится VMware», а подготовить документ, который выдержит проверку. Один из наших заказчиков - государственный орган - столкнулся с этим вплотную: плановая закупка продления лицензий VMware vSphere зависла, потому что юридический блок потребовал корректное обоснование до выхода на тендер.

Нас привлекли именно для этого - разобраться с реестром, сравнить, что есть, и дать документарную основу для закупочной процедуры.

Что ищем в реестре

Реестр Минцифры - это сайт reestr.minsvyaz.ru, поиск по классам ПО. VMware vSphere относится к классу «Средства виртуализации» (класс 02.05 по классификатору), и в этом разделе позиций хватает. На момент нашей работы там числились несколько российских продуктов: zVirt, «РЕД Виртуализация», «Скала-Р Виртуализация» и ряд других.

Ключевой вопрос: является ли что-то из этого функциональным аналогом? Формальное наличие в том же классе - не аналог. Нужно сравнивать по функциям, которые реально используются в инфраструктуре заказчика.

Сравнительная таблица: что сравниваем

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

• Управление кластером и высокая доступность - vSphere HA, DRS, балансировка нагрузки между хостами, автоматическое переключение ВМ при отказе хоста.
• Хранилища и миграция - vMotion (живая миграция ВМ без останова), Storage vMotion, интеграция с СХД по Fibre Channel и iSCSI, поддержка VMFS и NFS.
• Сетевая виртуализация - Distributed Virtual Switch, управление политиками трафика на уровне кластера.
• Интеграция с существующей средой - поддержка Windows Server 2016/2019 в качестве гостевых ОС, интеграция с Active Directory для управления доступом, vCenter API для автоматизации через Ansible и Terraform.
• Резервное копирование - совместимость с уже развёрнутым Veeam Backup через VADP.

По каждому пункту смотрели, что предлагают отечественные продукты из реестра. Для части позиций документация доступна публично, для части - запрашивали у вендоров через партнёров.

Что выяснилось

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

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

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

VADP-совместимость - Veeam Backup использует VMware vStorage APIs for Data Protection для резервного копирования без агентов. Ни один из рассмотренных российских продуктов совместимость с VADP не декларировал. Это означает: переход на отечественный гипервизор потребует пересмотра всей стратегии резервного копирования, что выходит за рамки простой замены ПО.

vCenter API и автоматизация - заказчик активно использует Ansible с модулями community.vmware для управления инфраструктурой. Российские продукты имеют собственные API, но не совместимые с существующими плейбуками. Переход = переписывание автоматизации.

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

Структура обоснования

На основе таблицы подготовили документ обоснования закупки. Его структура - примерно такая:

1. Перечень классов ПО по классификатору, к которым относится закупаемый продукт.
2. Список продуктов из реестра, рассмотренных как потенциальные аналоги.
3. Методика сравнения - по каким критериям оценивали (это важно зафиксировать, чтобы была прозрачность в выборе критериев).
4. Сравнительная таблица с результатами.
5. Вывод: в рамках рассмотренных продуктов функциональный аналог, обеспечивающий выполнение конкретных требований без существенного изменения смежных систем, не выявлен. Далее - перечень конкретных расхождений, которые к этому выводу привели.

Юридический блок заказчика принял документ и закупка пошла дальше.

Формализация для повторных закупок

Второй результат этой работы - шаблон, который позволяет воспроизвести процесс при следующей закупке иностранного ПО. Чтобы не делать каждый раз с нуля:

• зафиксированная методика поиска по реестру (по каким классификаторам, с какими ключевыми словами),
• стандартная структура сравнительной таблицы с перечнем типовых критериев,
• шаблон раздела обоснования под разные типы ПО (гипервизор, СУБД, средства резервного копирования).

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

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