En la antaŭa
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
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
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
Ĉi tiuj produktoj estas for de kompareblaj
Pri deplojo kaj agordo KVM ĝi ne estis skribita same
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