En la antaŭa opcioj estis pripensitaj por kio la ekzistantaj sistemoj povus esti anstataŭigitaj kun kiel parto de la efektivigo de la importanstataŭordo. La sekvaj artikoloj fokusiĝos pri elektado de specifaj produktoj por anstataŭigi tiujn nuntempe deplojitaj. Ni komencu per la deirpunkto - la virtualiga sistemo.
1. La agonio de elekto
Do, el kio vi povas elekti? EN :
- Servila virtualiga sistemo "R-Virtualigo» (libvirt, KVM, QEMU)
- Programaro "Iloj de virtualigo de Brest» (libvirt, KVM, QEMU)
- Platformo por administrado kaj monitorado de la virtualiga medio "Sharx Stream" (nuba solvo, kiu ne taŭgas por registaraj oficejoj en 95% de kazoj (sekreteco ktp.)
- Programarpakaĵo por virtualigo de serviloj, labortabloj kaj aplikaĵoj "GASTO" (KVM x86)
- Sistemo por sekura administrado de la virtualiga medio "Z|virt"(alinome oVirt+KVM)
- Virtualiga medio-administra sistemo "ROSA Virtualigo"(alinome oVirt+KVM)
- Hypervisor QP VMM (tro simila al Oracle Virtual Box por esti io alia)
Vi ankaŭ povas konsideri hipervizilojn inkluzivitajn en la OS-distribuo aŭ situantaj en ilia deponejo. Ekzemple, Astra Linukso havas KVM-subtenon. Kaj ĉar ĝi estas inkluzivita en la OS-deponejoj, ĝi povas esti konsiderata "legitima" por instalado kaj uzo. "Kio povas esti uzata kiel parto de import-anstataŭigo kaj kio ne povas" estis diskutita en la antaŭa , do mi ne traktos ĉi tiun aferon.
Fakte, ĉi tie :
- VirtualaBox
- Virt-manaĝero (KVM) Aglo-fluo
- libreton super KVM
ROSA Linukso ne havas tian liston, sed vi povas trovi ĝin en la vikio :
- ROSA Virtualigo super oVirt super KVM
- QEMU super KVM
- oVirt 3.5 super KVM
Kalkuli havas ĉi tion
Alt Linukso havas la samon
1.2. Estas unu SED
Post pli proksima ekzameno, ni konkludas, ke ni devos trakti nur kelkajn konatajn hipervizilojn, nome:
QEMU estas senpaga kaj malfermfonta programo por kopii aparataron de diversaj platformoj, kiu povas funkcii sen uzi KVM, sed uzi aparataron virtualigon signife plirapidigas la agadon de gastsistemoj, do uzi KVM en QEMU (-enable-kvm) estas la preferata opcio. (c) Tio estas, QEMU estas tipo 2 hiperviziero, kio estas neakceptebla en produkta medio. Kun KVM ĝi povas esti uzata, sed ĉi-kaze QEMU estos uzata kiel la KVM-administra ilo...
Uzante la originalon VirtualaBox en komerco estas fakte : “Komencante per la versio 4, publikigita en decembro 2010, la ĉefa parto de la produkto estas senpage distribuita laŭ la permesilo GPL v2. Kroma pakaĵo instalita sur ĝi, provizante subtenon por USB 2.0 kaj 3.0-aparatoj, Remote Desktop Protocol (RDP), stirada ĉifrado, ekfunkciigo de NVMe kaj PXE, estas distribuita sub speciala permesilo PUEL ("por persona uzo kaj taksado"). , sub kiu la sistemo libera por persona uzo, por trejnado, aŭ por taksado antaŭ ol decidi aĉeti la komercan version." (c) Plus VirtualBox ankaŭ estas tipo 2 hiperviziero, do ĝi ankaŭ malaperas.
Sumo: en ĝia pura formo ni nur havas KVM.
2. La resto: KVM aŭ KVM?
Se vi ankoraŭ bezonas ŝanĝi al "hejma" hiperviziero, via elekto, sincere parolante, estas malgranda. Ĝi estos KVM en unu envolvaĵo aŭ alia, kun certaj modifoj, sed ĝi ankoraŭ estos KVM. Ĉu tio estas bona aŭ malbona estas alia demando; ankoraŭ ne ekzistas alternativo.
Se la kondiĉoj ne estas tiel striktaj, tiam, kiel diskutite en la antaŭa : “Ni devas alporti la indikilojn al la establitaj limoj. Fakte, ĉi tio signifas, ke ni devas anstataŭigi la ekzistantan OS per produktoj de la Registroministerio pri Telekomunikado kaj Amasa Komunikado kaj pliigi la nombron da anstataŭigitaj operaciumoj al 80%.... Do, ni povas sekure lasi la areton sur Hyper-V. , ĉar ni havas ĝin kaj ni ŝatas ĝin... "(c) Do ni estas antaŭ elekto: Microsoft Hyper-v aŭ KVM. KVM eble kun kontroloj "ŝraŭbintaj" al ĝi, sed ĝi ankoraŭ restos la sama KVM.
Ĉi tiuj produktoj estas for de kompareblaj ne ne ...Nu, vi komprenas...
Pri deplojo kaj agordo KVM ĝi ne estis skribita same ne ne kaj ne ... Unuvorte, .
La sama validas por
Mi vidas nenian signifon ripeti min kaj priskribi ĉi tiujn sistemojn, kompari, ktp. Vi povas, kompreneble, eltiri ŝlosilajn punktojn el artikoloj, sed tio estus malrespekta al la aŭtoroj, mi pensas. Kiu devas elekti, legos ne nur ĉi tion, sed ankaŭ monton da informoj por decidiĝi.
La nura diferenco, pri kiu mi volas koncentriĝi, estas malsukcesa grupigo. Se Mikrosofto havas ĉi tion enkonstruita en la OS kaj hiperviziero-funkcio, tiam en la kazo de KVM vi devos uzi triapartan programaron, kiu devus esti inkluzivita en la OS-deponejoj. La sama kombinaĵo de Corosync+Pacemaker, ekzemple. (Preskaŭ ĉiuj hejmaj operaciumoj havas ĉi tiun kombinaĵon... eble ĉiuj, sed mi ne kontrolis 100% el ili.) Manlibroj por agordi clustering ankaŭ haveblas abunde.
3. Konkludo
Nu, kiel kutime, niaj Kulibins ne ĝenis, ili prenis tion, kion ili havis, aldonis iomete sian propran, kaj produktis "produkton" kiu, laŭ dokumentoj, estas hejma, sed fakte estas OpenSource. Ĉu havas sencon elspezi monon de la buĝeto por "apartaj" virtualigaj sistemoj (legu: ne inkluzivita en la OS)? Ne pensu. Ĉar vi ankoraŭ ricevos la saman KVM, vi nur devos pagi por ĝi.
Tiel, elekti anstataŭaĵon por hiperviziero dependas de kia servilo OS vi aĉetos por la Enterprise kaj funkciigos. Aŭ, kiel en mia kazo, vi restos kun tio, kion vi jam havas (Hyper-VESXi insert_needed).
fonto: www.habr.com