В предыдущей были рассмотрены варианты, на что можно заменить существующие системы в рамках выполнения приказа об импортозамещении. Далее в статьях речь пойдет о выборе конкретных продуктов для замены развернутых в настоящее время. Начнем с точки отсчета — системы виртуализации.
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. И так как он входит в репозитории ОС, то его можно считать «легитимным» для установки и использования. О том, «что можно использовать в рамках импортозамещения, а что нет», было оговорено в предыдущей , так что не буду останавливаться на этом вопросе.
На деле вот :
- 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 это
У Альт Линукс это тот же
1.2. Есть одно НО
При ближайшем рассмотрении, делаем вывод, что иметь дело нам придется всего лишь с несколькими известными гипервизорами, а именно:
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?
В случае, если вам все же необходимо перейти на «отечественный» гипервизор — выбор у вас, прямо скажем, невелик. Это будет KVM в той или иной обертке, с теми или иными доработками, но все равно это будет KVM. Хорошо это или плохо — вопрос другой, все равно альтернативы нет.
В случае, если условия не столь строги, то, как говорилось в предыдущей : «Нам надо привести показатели к установленным пределам. На деле это значит, что мы должны заменить существующие ОС на продукты из реестра Минкомсвязи и довести количество замененных операционных систем до 80%.… Итак, мы спокойно можем оставить кластер на Hyper-V, раз уж он у нас есть и нам он нравится…» (с) Так что перед нами стоит выбор: Microsoft Hyper-v или KVM. KVM может быть с «прикрученными» к нему средствами управления, но он все равно останется все тем же KVM.
Эти продукты сравнивались далеко не , не , не … Ну, вы поняли…
Про развертывание и настройку KVM так же писалось не , не , не и не … Словом, .
То же самое и про
Не вижу смысла повторяться и описывать эти системы, сравнивать и т.д. Можно, конечно, повыдергивать из статей ключевые моменты, но это будет неуважение к авторам, я считаю. Кому предстоит выбирать — тот прочтет не только это, но и еще гору информации, чтобы определиться.
Единственное отличие, на котором хочу заострить внимание — отказоустойчивая кластеризация. Если у Microsoft это встроено в ОС и функционал гипервизора, то в случае с KVM придется использовать стороннее ПО, которое должно входить в репозитории ОС. Та же связка Corosync+Pacemaker, например. (Эта связка есть почти у всех отечественных ОС… может, и у всех, но все 100% я проверять не стал.) Мануалы по настройке кластеризации так же имеются в избытке.
3. Вывод
Ну, как обычно, наши Кулибины не стали заморачиваться, взяли что было, прикрутили чуточку своего, и выдали «продукт», который по документам является отечественным, а на деле — OpenSource. Есть ли смысл тратить деньги из бюджета за «отдельные» системы виртуализации (читай не входящие в состав ОС)? Не думаю. Так как все равно вы получите тот же KVM, только за него еще нужно будет заплатить.
Таким образом, выбор замены для гипервизора сводится к тому, какие серверные ОС вы собираетесь закупать для Предприятия и эксплуатировать. Или же, как в моем случае, останетесь на том, что у вас уже есть (Hyper-VESXiвписать_нужное).
Источник: habr.com