Importo pakeitimas praktikoje. 2 dalis. Pradžia. hipervizorius

Ankstesniame straipsnis buvo svarstomos galimybės, kuo būtų galima pakeisti esamas sistemas įgyvendinant importo pakeitimo nurodymą. Tolesniuose straipsniuose pagrindinis dėmesys bus skiriamas konkrečių produktų, kurie pakeis šiuo metu naudojamus produktus, pasirinkimą. Pradėkime nuo atspirties taško – virtualizacijos sistemos.
Importo pakeitimas praktikoje. 2 dalis. Pradžia. hipervizorius

1. Pasirinkimo agonija

Taigi, iš ko galite pasirinkti? IN Telekomunikacijų ir masinių ryšių ministerijos registras yra pasirinkimas:

  • Serverio virtualizacijos sistema "R-virtualizacija» (libvirt, KVM, QEMU)
  • programinės įrangos paketas "Bresto virtualizacijos įrankiai» (libvirt, KVM, QEMU)
  • Platforma virtualizacijos aplinkai valdyti ir stebėti „Šarkso srautas“ (debesų sprendimas, kuris 95% atvejų netinka vyriausybės įstaigoms (slaptumas ir pan.)
  • Programinės įrangos paketas serverių, stalinių kompiuterių ir programų virtualizavimui "HOST“ (KVM x86)
  • Sistema saugiam virtualizacijos aplinkos valdymuiZ|virt(dar žinomas kaip oVirt+KVM)
  • Virtualizacijos aplinkos valdymo sistema "ROSA virtualizavimas(dar žinomas kaip oVirt+KVM)
  • hipervizorius QP VMM (per daug panašus į Oracle Virtual Box, kad būtų kuo nors kitu)

Taip pat galite atsižvelgti į hipervizorius, įtrauktus į OS platinimą arba esančius jų saugyklose. Pavyzdžiui, „Astra Linux“ palaiko KVM. Ir kadangi jis yra įtrauktas į OS saugyklas, jis gali būti laikomas „teisėtu“ diegimui ir naudojimui. „Kas gali būti naudojama kaip importo pakeitimo dalis, o ko ne“ buvo aptarta anksčiau straipsnis, todėl šiuo klausimu nesigilinsiu.

Tiesą sakant, čia Astra Linux virtualizacijos įrankių sąrašas:

  • VirtualBox
  • Virt-vadybininkas (KVM) Erelio srovė
  • libvirt per KVM

ROSA Linux tokio sąrašo neturi, bet jį galite rasti wiki šiuos paketus:

  • ROSA virtualizavimas per oVirt per KVM
  • QEMU per KVM
  • oVirt 3.5 per KVM

Skaičiavimas turi tai QEMU per KVM

Alt Linux turi tą patį KVM

1.2. Yra vienas BET

Atidžiau panagrinėję darome išvadą, kad turėsime susidurti tik su keliais gerai žinomais hipervizoriais, būtent:

  1. KVM
  2. VirtualBox
  3. QEMU

QEMU yra nemokama ir atviro kodo programa, skirta įvairių platformų aparatinei įrangai emuliuoti, kuri gali veikti nenaudojant KVM, tačiau naudojant aparatinės įrangos virtualizavimą gerokai paspartėja svečių sistemų veikimas, todėl KVM naudojimas QEMU (-enable-kvm) yra pageidaujamas pasirinkimas. (c) Tai yra, QEMU yra 2 tipo hipervizorius, kuris yra nepriimtinas gaminio aplinkoje. Su KVM jį galima naudoti, tačiau šiuo atveju QEMU bus naudojamas kaip KVM valdymo įrankis...

Naudojant originalą VirtualBox komercijoje iš tikrųjų yra licencijos pažeidimas: „Nuo 4 versijos, išleistos 2010 m. gruodžio mėn., pagrindinė produkto dalis platinama nemokamai pagal GPL v2 licenciją. Viršuje įdiegtas papildomas paketas, palaikantis USB 2.0 ir 3.0 įrenginius, nuotolinio darbalaukio protokolą (RDP), disko šifravimą, paleidimą iš NVMe ir PXE, platinamas pagal specialią PUEL licenciją („asmeniniam naudojimui ir vertinimui“). , pagal kurią sistema nemokama asmeniniam naudojimui, mokymo tikslais arba įvertinimui prieš nusprendžiant įsigyti komercinę versiją. (c) Plus VirtualBox taip pat yra 2 tipo hipervizorius, todėl jis taip pat išnyksta.

Iš viso: gryna forma mes turime tik KVM.

2. Likusi dalis: KVM ar KVM?

Importo pakeitimas praktikoje. 2 dalis. Pradžia. hipervizorius

Jei vis tiek reikia pereiti prie „buitinio“ hipervizoriaus, jūsų pasirinkimas, atvirai kalbant, yra mažas. Taip ir bus KVM viename ar kitame įpakavime, su tam tikromis modifikacijomis, bet tai vis tiek bus KVM. Kitas klausimas, ar tai gerai, ar blogai.

Jei sąlygos nėra tokios griežtos, tada, kaip buvo aptarta ankstesniame straipsnis: „Reikia privesti rodiklius iki nustatytų ribų. Tiesą sakant, tai reiškia, kad turime pakeisti esamą OS produktais iš Telekomunikacijų ir masinių ryšių ministerijos registro ir padidinti pakeistų operacinių sistemų skaičių iki 80%... Taigi, galime drąsiai palikti klasterį Hyper-V. , kadangi mes jį turime ir mums patinka... "(c) Taigi mes susiduriame su pasirinkimu: Microsoft Hyper-v arba KVM. KVM gal su "prisuktais" valdikliais, bet vis tiek liks toks pat KVM.

Šie produktai toli gražu nėra palyginami kartąNe du kartusNe triskart...Na, supranti...

Apie diegimą ir konfigūraciją KVM buvo parašyta ne taip pat kartąNe du kartusNe triskart ne keturis kartus... Žodyje, išnyko.

Tas pats pasakytina apie „Microsoft Hyper-V“..

Nematau prasmės kartoti savęs ir aprašyti šias sistemas, lyginti ir t.t. Žinoma, iš straipsnių galima išskirti pagrindinius dalykus, bet, manau, tai būtų nepagarba autoriams. Kas turės pasirinkti, perskaitys ne tik tai, bet ir kalną informacijos, kad apsispręstų.

Vienintelis skirtumas, į kurį noriu atkreipti dėmesį, yra klasterizavimas. Jei „Microsoft“ tai įdiegė į OS ir hipervizoriaus funkcijas, tada KVM atveju turėsite naudoti trečiosios šalies programinę įrangą, kuri turėtų būti įtraukta į OS saugyklas. Pavyzdžiui, tas pats Corosync + Pacemaker derinys. (Beveik visos vietinės operacinės sistemos turi tokį derinį... gal visos, bet 100% netikrinau.) Klasterizacijos nustatymo vadovų taip pat gausu.

3. Išvada

Na, kaip įprasta, mūsų kulibinai nesivargino, pasiėmė ką turėjo, pridėjo šiek tiek savo ir pagamino „produktą“, kuris pagal dokumentus yra vietinis, o realiai yra OpenSource. Ar prasminga leisti pinigus iš biudžeto „atskiroms“ virtualizacijos sistemoms (skaitykite: neįtrauktoms į OS)? negalvok. Kadangi vis tiek gausite tą patį KVM, turėsite tik už jį sumokėti.

Taigi hipervizoriaus pakaitalo pasirinkimas priklauso nuo to, kokią serverio OS ketinate įsigyti „Enterprise“ ir ją naudoti. Arba, kaip mano atveju, liksite prie to, ką jau turite (Hyper-VESXi insert_needed).

Šaltinis: www.habr.com

Добавить комментарий