Импортозамещение на практике. Часть 2. Начало. Гипервизор

В предыдущей статье ^[1] были рассмотрены варианты, на что можно заменить существующие системы в рамках выполнения приказа об импортозамещении. Далее в статьях речь пойдет о выборе конкретных продуктов для замены развернутых в настоящее время. Начнем с точки отсчета — системы виртуализации.

1. Муки выбора

Итак, из чего можно выбрать? В реестре Минкомсвязи ^[2] выбор есть ^[3]:

• Система серверной виртуализации «Р-Виртуализация» (libvirt, KVM, QEMU)
• Программный комплекс "Средства виртуализации «Брест»" (libvirt, KVM, QEMU)
• Платформа управления и мониторинга среды виртуализации «Sharx Stream» (облачное решение, которое не подходит для госконтор в 95% случаев (секретность и т.д.)
• Программный комплекс виртуализации серверов, рабочих столов и приложений «ХОСТ» (KVM x86)
• Система безопасного управления средой виртуализации "Z|virt" (он же oVirt+KVM)
• Система управления средой виртуализации «ROSA Virtualization» (он же oVirt+KVM)
• Гипервизор QP VMM (слишком похож на Oracle Virtual Box, чтобы быть чем-то другим)

Так же можно брать в расчет гипервизоры, входящие в состав поставки ОС, или находящиеся в их репозитории. Например, у той же Astra Linux есть поддержка KVM. И так как он входит в репозитории ОС, то его можно считать «легитимным» для установки и использования. О том, «что можно использовать в рамках импортозамещения, а что нет», было оговорено в предыдущей статье ^[1], так что не буду останавливаться на этом вопросе.

На деле вот список средств виртуализации Astra Linux ^[4]:

• VirtualBox
• Virt-manager (KVM) Орел current
• libvirt over KVM

У ROSA Linux такого списка нет, но в wiki можно найти следующие пакеты ^[5]:

• ROSA Virtualization over oVirt over KVM
• QEMU over KVM
• oVirt 3.5 over KVM

У Calculate это QEMU over KVM ^[6]

У Альт Линукс это тот же KVM ^[7]

1.2. Есть одно НО

При ближайшем рассмотрении, делаем вывод, что иметь дело нам придется всего лишь с несколькими известными гипервизорами, а именно:

1. KVM ^[8]
2. VirtualBox ^[9]
3. QEMU ^[10]

QEMU — свободная программа с открытым исходным кодом для эмуляции аппаратного обеспечения различных платформ, которая может работать и без использования KVM, но использование аппаратной виртуализации значительно ускоряет работу гостевых систем, поэтому использование KVM в QEMU (-enable-kvm) является предпочтительным вариантом. (с) То есть QEMU — гипервизор 2го типа, что неприемлемо в продуктовой среде. С KVM его можно использовать, но в этом случае QEMU будет использоваться в качестве средства управления KVM…

Использование оригинального VirtualBox в коммерции является фактически нарушением лицензии ^[11]: «Начиная с версии 4, выпущенной в декабре 2010 года, основная часть продукта распространяется бесплатно под лицензией GPL v2. Устанавливаемый поверх неё дополнительный пакет, обеспечивающий поддержку устройств USB 2.0 и 3.0, протокол удалённого рабочего стола (RDP), шифрование накопителя, загрузку с NVMe и по PXE, распространяется под особой лицензией PUEL («для личного использования и ознакомления»), по который система бесплатна для личного использования, в целях обучения или для оценки перед принятием решения о приобретении коммерческой версии.» (с) Плюс VirtualBox так же является гипервизором 2го типа, так что он так же отпадает.

Итого: в чистом виде мы имеем только KVM.

2. В остатке: KVM или KVM?

В случае, если вам все же необходимо перейти на «отечественный» гипервизор — выбор у вас, прямо скажем, невелик. Это будет KVM в той или иной обертке, с теми или иными доработками, но все равно это будет KVM. Хорошо это или плохо — вопрос другой, все равно альтернативы нет.

В случае, если условия не столь строги, то, как говорилось в предыдущей статье ^[1]: «Нам надо привести показатели к установленным пределам. На деле это значит, что мы должны заменить существующие ОС на продукты из реестра Минкомсвязи и довести количество замененных операционных систем до 80%.… Итак, мы спокойно можем оставить кластер на Hyper-V, раз уж он у нас есть и нам он нравится...» (с) Так что перед нами стоит выбор: Microsoft Hyper-v или KVM. KVM может быть с «прикрученными» к нему средствами управления, но он все равно останется все тем же KVM.

Эти продукты сравнивались далеко не однократно ^[12], не двукратно ^[13], не трехкратно ^[14]… Ну, вы поняли…

Про развертывание и настройку KVM так же писалось не однократно ^[15], не двукратно ^[16], не трехкратно ^[17] и не четырехкратно ^[18]… Словом, выпонели ^[19].

То же самое и про Microsoft Hyper-V.. ^[20]

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

Единственное отличие, на котором хочу заострить внимание — отказоустойчивая кластеризация. Если у Microsoft это встроено в ОС и функционал гипервизора, то в случае с KVM придется использовать стороннее ПО, которое должно входить в репозитории ОС. Та же связка Corosync+Pacemaker, например. (Эта связка есть почти у всех отечественных ОС… может, и у всех, но все 100% я проверять не стал.) Мануалы по настройке кластеризации так же имеются в избытке.

3. Вывод

Ну, как обычно, наши Кулибины не стали заморачиваться, взяли что было, прикрутили чуточку своего, и выдали «продукт», который по документам является отечественным, а на деле — OpenSource. Есть ли смысл тратить деньги из бюджета за «отдельные» системы виртуализации (читай не входящие в состав ОС)? Не думаю. Так как все равно вы получите тот же KVM, только за него еще нужно будет заплатить.

Таким образом, выбор замены для гипервизора сводится к тому, какие серверные ОС вы собираетесь закупать для Предприятия и эксплуатировать. Или же, как в моем случае, останетесь на том, что у вас уже есть (Hyper-VESXiвписать_нужное).

Автор: Сысоев Андрей

Источник ^[21]