Import helyettesítés a gyakorlatban. 2. rész. Kezdet. Hipervizor

Az előzőben cikk mérlegelték a lehetőségeket arra vonatkozóan, hogy a meglévő rendszereket mivel lehetne helyettesíteni az import helyettesítési rendelet végrehajtásának részeként. A következő cikkek konkrét termékek kiválasztására összpontosítanak a jelenleg telepített termékek helyettesítésére. Kezdjük a kiindulóponttal - a virtualizációs rendszerrel.

1. A választás kínja

Szóval miből választhatsz? BAN BEN a Távközlési és Tömegkommunikációs Minisztérium nyilvántartása van választási lehetőség:

• Szerver virtualizációs rendszer "R-virtualizáció» (libvirt, KVM, QEMU)
• Szoftver csomag "Brest virtualizációs eszközök» (libvirt, KVM, QEMU)
• Platform a virtualizációs környezet kezelésére és figyelésére "Sharx Stream" (kormányhivataloknak az esetek 95%-ában nem megfelelő felhőmegoldás (titoktartás stb.)
• Szoftvercsomag szerverek, asztali számítógépek és alkalmazások virtualizálásához "HOST" (KVM x86)
• Rendszer a virtualizációs környezet biztonságos kezeléséhez "Z|virt"(más néven oVirt+KVM)
• Virtualizációs környezetkezelő rendszerROSA virtualizáció"(más néven oVirt+KVM)
• Hipervizor QP VMM (túl hasonlít az Oracle Virtual Box-hoz, hogy bármi más legyen)

Figyelembe veheti az operációs rendszer disztribúciójában vagy a lerakatában található hipervizorokat is. Például az Astra Linux rendelkezik KVM támogatással. És mivel benne van az operációs rendszer adattáraiban, „jogosnak” tekinthető a telepítés és a használat szempontjából. „Mi használható az importhelyettesítés részeként és mit nem” az előzőekben volt szó cikk, ezért nem foglalkozom ezzel a kérdéssel.

Sőt, itt az Astra Linux virtualizációs eszközeinek listája:

• VirtualBox
• Virt-menedzser (KVM) Sasáram
• libvirttel KVM-en keresztül

A ROSA Linuxnak nincs ilyen listája, de a wikin megtalálod következő csomagokat:

• ROSA virtualizáció oVirt felett KVM felett
• QEMU KVM-en keresztül
• oVirt 3.5 KVM-en keresztül

A Calculate rendelkezik ezzel QEMU KVM-en keresztül

Az Alt Linuxon ugyanez van KVM

1.2. Van egy DE

Közelebbről megvizsgálva arra a következtetésre jutunk, hogy csak néhány jól ismert hipervizorral kell megküzdenünk, nevezetesen:

1. KVM
2. VirtualBox
3. QEMU

QEMU egy ingyenes és nyílt forráskódú program különféle platformok hardvereinek emulálására, amely KVM használata nélkül is működhet, de a hardveres virtualizáció jelentősen felgyorsítja a vendégrendszerek teljesítményét, ezért a KVM használata QEMU-ban (-enable-kvm) a preferált lehetőség. (c) Vagyis a QEMU egy 2-es típusú hipervizor, ami termékkörnyezetben elfogadhatatlan. KVM-mel használható, de ebben az esetben a QEMU lesz a KVM menedzsment eszköz...

Az eredeti felhasználásával VirtualBox a kereskedelemben valójában engedély megsértése: „A 4 decemberében kiadott 2010-es verziótól kezdődően a termék nagy része ingyenesen kerül terjesztésre a GPL v2 licenc alatt. A tetejére telepített kiegészítő csomag, amely támogatja az USB 2.0 és 3.0 eszközöket, a Remote Desktop Protocolt (RDP), a meghajtótitkosítást, az NVMe-ről és a PXE-ről történő rendszerindítást, speciális PUEL licenc alatt („személyes használatra és értékelésre”) kerül terjesztésre. , amely alapján a rendszer ingyenes személyes használatra, képzési célokra vagy a kereskedelmi verzió megvásárlása előtti értékelésre." (c) A Plus VirtualBox szintén 2-es típusú hypervisor, így az is eltűnik.

Összesen: tiszta formájában csak nálunk van KVM.

2. A többi: KVM vagy KVM?

Ha mégis „hazai” hipervizorra kell váltania, őszintén szólva kicsi a választása. Lesz KVM egyik-másik wrapperben, bizonyos módosításokkal, de attól még KVM lesz. Az, hogy ez jó vagy rossz, az egy másik kérdés, még mindig nincs alternatíva.

Ha a feltételek nem olyan szigorúak, akkor az előzőekben tárgyalt módon cikk: „A mutatókat a megállapított határértékekre kell hoznunk. Valójában ez azt jelenti, hogy a meglévő operációs rendszert le kell cserélnünk a Telecom és Mass Communications Minisztériumának termékeivel, és 80%-ra kell növelnünk a lecserélt operációs rendszerek számát... Szóval nyugodtan elhagyhatjuk a fürtöt a Hyper-V-n , hiszen megvan és szeretjük... "(c) Tehát választás előtt állunk: Microsoft Hyper-v vagy KVM. KVM talán rá "csavart" kezelőszervekkel, de akkor is ugyanaz marad KVM.

Ezek a termékek messze nem összehasonlíthatók egyszerNem kétszerNem háromszor...Nos, érted...

A telepítésről és a konfigurációról KVM nem ugyanúgy volt megírva egyszerNem kétszerNem háromszor és nem négyszer... Egy szóban, elenyészett.

Ugyanez vonatkozik A Microsoft Hyper-V..

Nem látom értelmét ismételni magam és leírni ezeket a rendszereket, összehasonlítani stb. Természetesen ki lehet húzni a cikkekből a legfontosabb pontokat, de ez szerintem tiszteletlen lenne a szerzőkkel szemben. Akinek választania kell, az nemcsak ezt olvassa el, hanem egy hegynyi információt is, hogy eldöntse.

Az egyetlen különbség, amelyre összpontosítani szeretnék, a feladatátvételi fürtözés. Ha a Microsoft ezt beépítette az operációs rendszerbe és a hypervisor funkcióba, akkor KVM esetén harmadik féltől származó szoftvert kell használnia, amelyet az operációs rendszer tárolóiban kell tartalmaznia. Például a Corosync+Pacemaker ugyanaz a kombinációja. (Majdnem minden hazai operációs rendszerben van ez a kombináció... talán mindegyik, de nem néztem meg 100%-ot.) A fürtözés beállításához kézikönyvek is bőven elérhetőek.

3. Következtetés

Nos, ahogy az lenni szokott, a mi Kulibinjeink nem zavartak, vették, amijük volt, hozzáadtak egy keveset a sajátjukból, és előállítottak egy „terméket”, ami a dokumentumok szerint hazai, de a valóságban OpenSource. Van értelme pénzt költeni a költségvetésből „külön” virtualizációs rendszerekre (értsd: nem tartalmazza az operációs rendszert)? Ne gondolkozz. Mivel továbbra is ugyanazt a KVM-et kapod, csak fizetni kell érte.

Így a hypervisor helyettesítőjének kiválasztása attól függ, hogy milyen szerver operációs rendszert kíván megvásárolni és működtetni az Enterprise számára. Vagy, mint az én esetemben, maradsz a már meglévőnél (Hyper-VESXi insert_needed).

Forrás: will.com