Імпортозаміщення на практиці. Частина 2. Початок. Гіпервізор

У попередній статті було розглянуто варіанти, потім можна замінити існуючі системи у межах виконання наказу про імпортозаміщення. Далі в статтях йтиметься про вибір конкретних продуктів для заміни розгорнутих в даний час. Почнемо з точки відліку системи віртуалізації.
Імпортозаміщення на практиці. Частина 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:

  • VirtualBox
  • Virt-manager (KVM) Орел current
  • лібвірт 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?

Імпортозаміщення на практиці. Частина 2. Початок. Гіпервізор

Якщо вам все ж таки необхідно перейти на «вітчизняний» гіпервізор — вибір у вас, прямо скажемо, невеликий. Це буде 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вписати_потрібне).

Джерело: habr.com

Додати коментар або відгук