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

в 8:22, , рубрики: open source, Законодательство в IT, импортозамещение, системное администрирование

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

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

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

  • Система серверной виртуализации «Р-Виртуализация» (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. И так как он входит в репозитории ОС, то его можно считать «легитимным» для установки и использования. О том, «что можно использовать в рамках импортозамещения, а что нет», было оговорено в предыдущей статье, так что не буду останавливаться на этом вопросе.

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

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

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

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

У Calculate это QEMU over KVM

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

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

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

  1. KVM
  2. VirtualBox
  3. QEMU

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

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

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

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

image

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

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

Эти продукты сравнивались далеко не однократно, не двукратно, не трехкратно… Ну, вы поняли…

Про развертывание и настройку KVM так же писалось не однократно, не двукратно, не трехкратно и не четырехкратно… Словом, выпонели.

То же самое и про Microsoft Hyper-V..

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

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

3. Вывод

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

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

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

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js