Заместването на вноса на практика. Част 2. Начало. хипервизор

В предишния Статия бяха разгледани варианти с какво могат да бъдат заменени съществуващите системи като част от изпълнението на поръчката за заместване на вноса. Следващите статии ще се фокусират върху избора на конкретни продукти, които да заменят тези, които са внедрени в момента. Да започнем с отправната точка – системата за виртуализация.

1. Агонията на избора

И така, от какво можете да избирате? IN регистър на Министерството на далекосъобщенията и масовите комуникации има избор:

• Система за виртуализация на сървъра "R-Виртуализация» (libvirt, KVM, QEMU)
• Софтуерен пакет"Инструменти за виртуализация на Брест» (libvirt, KVM, QEMU)
• Платформа за управление и мониторинг на среда за виртуализация "Sharx Stream" (облачно решение, което не е подходящо за държавни служби в 95% от случаите (секретност и т.н.)
• Софтуерен пакет за виртуализация на сървъри, десктопи и приложения”HOST" (KVM x86)
• Система за сигурно управление на виртуализационната среда”Z|вирт"(известен още като oVirt+KVM)
• Система за управление на среда за виртуализация "ROSA виртуализация"(известен още като oVirt+KVM)
• хипервизор QP VMM (твърде подобен на Oracle Virtual Box, за да бъде нещо друго)

Можете също така да вземете предвид хипервайзорите, включени в дистрибуцията на ОС или разположени в техните хранилища. Например Astra Linux има KVM поддръжка. И тъй като е включено в хранилищата на ОС, може да се счита за „легитимно“ за инсталиране и използване. „Какво може да се използва като част от заместването на вноса и какво не“ беше обсъдено в предишния Статия, така че няма да се спирам на този въпрос.

Всъщност тук списък с инструменти за виртуализация на Astra Linux:

• VirtualBox
• Virt-мениджър (KVM) Орлов ток
• libvirt през KVM

ROSA Linux няма такъв списък, но можете да го намерите в wiki следните пакети:

• ROSA виртуализация през oVirt през KVM
• QEMU през KVM
• oVirt 3.5 през KVM

Calculate има това QEMU през KVM

Alt Linux има същото KVM

1.2. Има едно НО

При по-внимателно разглеждане заключаваме, че ще трябва да се справим само с няколко добре познати хипервайзора, а именно:

1. KVM
2. VirtualBox
3. QEMU

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

Използвайки оригинала VirtualBox в търговията е всъщност нарушение на лиценза: „Започвайки с версия 4, издадена през декември 2010 г., основната част от продукта се разпространява безплатно под лиценз GPL v2. Допълнителен пакет, инсталиран върху него, осигуряващ поддръжка за устройства с USB 2.0 и 3.0, протокол за отдалечен работен плот (RDP), криптиране на дискове, зареждане от NVMe и PXE, се разпространява под специален PUEL лиценз („за лична употреба и оценка“) , при които системата е безплатна за лична употреба, за целите на обучението или за оценка, преди да решите да закупите търговската версия." (c) Plus VirtualBox също е хипервизор тип 2, така че също изчезва.

Общо: в чист вид имаме само KVM.

2. Останалите: KVM или KVM?

Ако все пак трябва да преминете към „домашен“ хипервизор, изборът ви, честно казано, е малък. Ще бъде KVM в една или друга обвивка, с известни модификации, но пак ще е KVM. Дали това е добро или лошо е друг въпрос, все още няма алтернатива.

Ако условията не са толкова строги, тогава, както беше обсъдено в предишния Статия: „Трябва да доведем показателите до установените граници. Всъщност това означава, че трябва да заменим съществуващата ОС с продукти от регистъра на Министерството на телекомуникациите и масовите комуникации и да увеличим броя на заменените операционни системи до 80%... Така че можем спокойно да оставим клъстера на Hyper-V , тъй като го имаме и ни харесва... "(c) Така че сме изправени пред избор: Microsoft Hyper-v или KVM. KVM може би с контроли, „завинтени“ към него, но пак ще остане същото KVM.

Тези продукти далеч не са сравними веднъжНе два пътиНе три пъти...Е, нали разбирате...

Относно внедряването и конфигурацията KVM не беше написано по същия начин веднъжНе два пътиНе три пъти и не четири пъти... С една дума, избледня.

Същото важи и за Microsoft Hyper-V..

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

Единствената разлика, върху която искам да се съсредоточа, е клъстерирането при отказ. Ако Microsoft има това вградено в операционната система и функционалността на хипервайзора, тогава в случай на KVM ще трябва да използвате софтуер на трети страни, който трябва да бъде включен в хранилищата на операционната система. Същата комбинация от Corosync+Pacemaker, например. (Почти всички домашни операционни системи имат тази комбинация... може би всички, но не проверих 100% от тях.) Ръководствата за настройка на клъстерирането също са налични в изобилие.

3. Заключение

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

По този начин изборът на заместител на хипервайзор се свежда до това каква сървърна операционна система ще закупите за Enterprise и ще работите. Или, както в моя случай, ще останете с това, което вече имате (Hyper-VESXi insert_needed).

Източник: www.habr.com