Импортозамещение на практике. Часть 2. Начало. Гипервизор
В предыдущей статье были рассмотрены варианты, на что можно заменить существующие системы в рамках выполнения приказа об импортозамещении. Далее в статьях речь пойдет о выборе конкретных продуктов для замены развернутых в настоящее время. Начнем с точки отсчета — системы виртуализации.
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
У ROSA Linux такого списка нет, но в wiki можно найти следующие пакеты:
У Альт Линукс в репозитории нашлось:
У Calculate нашлось следующее:
У Ульяновск.BSD
1.2. Есть одно НО
При ближайшем рассмотрении, делаем вывод, что иметь дело нам придется всего лишь с несколькими известными гипервизорами, а именно:
QEMU — свободная программа с открытым исходным кодом для эмуляции аппаратного обеспечения различных платформ, которая может работать и без использования KVM, но использование аппаратной виртуализации значительно ускоряет работу гостевых систем, поэтому использование KVM в QEMU (-enable-kvm) является предпочтительным вариантом. (с) То есть QEMU — гипервизор 2го типа, что неприемлемо в продуктовой среде. С KVM его можно использовать, но в этом случае QEMU будет использоваться в качестве средства управления KVM.
bhyve — гипервизов второго типа. Отметается.
Использование оригинального VirtualBox в коммерции является фактически нарушением лицензии: «Начиная с версии 4, выпущенной в декабре 2010 года, основная часть продукта распространяется бесплатно под лицензией GPL v2. Устанавливаемый поверх неё дополнительный пакет, обеспечивающий поддержку устройств USB 2.0 и 3.0, протокол удалённого рабочего стола (RDP), шифрование накопителя, загрузку с NVMe и по PXE, распространяется под особой лицензией PUEL («для личного использования и ознакомления»), по который система бесплатна для личного использования, в целях обучения или для оценки перед принятием решения о приобретении коммерческой версии.» (с) Плюс VirtualBox так же является гипервизором 2го типа, так что он так же отпадает.
Итого: в чистом виде мы имеем только KVM.
2. В остатке: KVM или KVM?
В случае, если вам все же необходимо перейти на «отечественный» гипервизор — выбор у вас, прямо скажем, невелик. Это будет KVM в той или иной обертке, с теми или иными доработками, но все равно это будет KVM. Хорошо это или плохо — вопрос другой, все равно альтернативы нет.
В случае, если условия не столь строги, то, как говорилось в предыдущей статье: «Нам надо привести показатели к установленным пределам. На деле это значит, что мы должны заменить существующие ОС на продукты из реестра Минкомсвязи и довести количество замененных операционных систем до 80%.… Итак, мы спокойно можем оставить кластер на Hyper-V, раз уж он у нас есть и нам он нравится...» (с) Так что перед нами стоит выбор: Microsoft Hyper-V или KVM. KVM может быть с «прикрученными» к нему средствами управления, но он все равно останется все тем же KVM.
Эти продукты сравнивались далеко не однократно, не двукратно, не трехкратно… Ну, вы поняли…
Про развертывание и настройку KVM так же писалось не однократно, не двукратно, не трехкратно и не четырехкратно… Словом, выпонели.
То же самое и про Microsoft Hyper-V..
Не вижу смысла повторяться и описывать эти системы, сравнивать и т.д. Можно, конечно, повыдергивать из статей ключевые моменты, но это будет неуважение к авторам, я считаю. Кому предстоит выбирать — тот прочтет не только это, но и еще гору информации, чтобы определиться.
Единственное отличие, на котором хочу заострить внимание — отказоустойчивая кластеризация. Если у Microsoft это встроено в ОС и функционал гипервизора, то в случае с KVM придется использовать стороннее ПО, которое должно входить в репозитории ОС. Та же связка Corosync+Pacemaker, например. (Эта связка есть почти у всех отечественных ОС… может, и у всех, но все 100% я проверять не стал.) Мануалы по настройке кластеризации так же имеются в избытке.
3. Вывод
Ну, как обычно, наши Кулибины не стали заморачиваться, взяли что было, прикрутили чуточку своего, и выдали «продукт», который по документам является отечественным, а на деле — OpenSource. Есть ли смысл тратить деньги из бюджета за «отдельные» системы виртуализации (читай не входящие в состав ОС)? Не думаю. Так как все равно вы получите тот же KVM, только за него еще нужно будет заплатить.
Таким образом, выбор замены для гипервизора сводится к тому, какие серверные ОС вы собираетесь закупать для Предприятия и эксплуатировать. Или же, как в моем случае, останетесь на том, что у вас уже есть (Hyper-V\ESXi\вписать_нужное).
Так же по теме можете почитать:
Предыдущая статья про планирование импортозамещения.
И далее по теме:
Статья про «отечественные» операционные системы.
Статья про системы и сервисы.
И про QP ОС в придачу.