I forrige
1. valgets kvaler
Så, hva kan du velge mellom? I
- Servervirtualiseringssystem "R-virtualisering» (libvirt, KVM, QEMU)
- Software pakke "Brest virtualiseringsverktøy» (libvirt, KVM, QEMU)
- Plattform for administrasjon og overvåking av virtualiseringsmiljøet "Sharx Stream" (en skyløsning som ikke er egnet for offentlige kontorer i 95 % av tilfellene (hemmelighold osv.)
- Programvarepakke for virtualisering av servere, skrivebord og applikasjoner "HOST" (KVM x86)
- System for sikker administrasjon av virtualiseringsmiljøet "Z|virt"(aka oVirt+KVM)
- Virtualiseringsmiljøstyringssystem "ROSA virtualisering"(aka oVirt+KVM)
- Hypervisor QP VMM (for lik Oracle Virtual Box til å være noe annet)
Du kan også ta hensyn til hypervisorer som er inkludert i OS-distribusjonen eller som er plassert i depotet deres. For eksempel har Astra Linux KVM-støtte. Og siden det er inkludert i OS-lagrene, kan det betraktes som "legitimt" for installasjon og bruk. "Hva kan brukes som en del av importsubstitusjon og hva som ikke kan" ble diskutert i forrige
Faktisk her
- VirtualBox
- Virt-manager (KVM) Ørnestrøm
- libvirt over KVM
ROSA Linux har ikke en slik liste, men du finner den på wikien
- ROSA virtualisering over oVirt over KVM
- QEMU over KVM
- oVirt 3.5 over KVM
Calculate har dette
Alt Linux har det samme
1.2. Det er ett MEN
Ved nærmere undersøkelse konkluderer vi med at vi bare må forholde oss til noen få kjente hypervisorer, nemlig:
QEMU er et gratis og åpen kildekode-program for å emulere maskinvare fra ulike plattformer, som kan fungere uten å bruke KVM, men bruk av maskinvarevirtualisering øker ytelsen til gjestesystemer betydelig, så bruk av KVM i QEMU (-enable-kvm) er det foretrukne alternativet. (c) Det vil si at QEMU er en type 2 hypervisor, som er uakseptabel i et produktmiljø. Med KVM kan det brukes, men i dette tilfellet vil QEMU bli brukt som KVM-administrasjonsverktøyet...
Bruker originalen VirtualBox i handel er faktisk
totalt: i sin rene form har vi bare KVM.
2. Resten: KVM eller KVM?
Hvis du fortsatt trenger å bytte til en "hjemlig" hypervisor, er valget ditt, ærlig talt, lite. Det blir det KVM i en eller annen innpakning, med visse modifikasjoner, men det vil fortsatt være KVM. Om dette er bra eller dårlig er et annet spørsmål; det er fortsatt ikke noe alternativ.
Hvis vilkårene ikke er så strenge, så, som diskutert i forrige
Disse produktene er langt fra sammenlignbare
Om distribusjon og konfigurasjon KVM det var ikke skrevet på samme måte
Det samme gjelder
Jeg ser ingen vits i å gjenta meg selv og beskrive disse systemene, sammenligne osv. Du kan selvfølgelig trekke frem nøkkelpunkter fra artikler, men dette vil være respektløst overfor forfatterne, synes jeg. Den som må velge vil lese ikke bare dette, men også et berg av informasjon for å bestemme seg.
Den eneste forskjellen jeg ønsker å fokusere på er failover-klynger. Hvis Microsoft har dette innebygd i OS- og hypervisorfunksjonaliteten, må du i tilfellet med KVM bruke tredjepartsprogramvare, som bør inkluderes i OS-lagrene. Samme kombinasjon av Corosync+Pacemaker, for eksempel. (Nesten alle innenlandske operativsystemer har denne kombinasjonen ... kanskje alle, men jeg sjekket ikke 100 % av dem.) Manualer for å sette opp clustering er også tilgjengelig i rikelig med.
3. Konklusjon
Vel, som vanlig brydde seg ikke våre Kulibins, de tok det de hadde, la til litt av sitt eget og produserte et "produkt" som ifølge dokumenter er innenlands, men i virkeligheten er OpenSource. Er det fornuftig å bruke penger fra budsjettet på "separate" virtualiseringssystemer (les: ikke inkludert i OS)? Ikke tenk. Siden du fortsatt vil motta samme KVM, trenger du bare å betale for den.
Å velge en erstatning for en hypervisor kommer derfor ned på hvilket server-OS du skal kjøpe for Enterprise og drifte. Eller, som i mitt tilfelle, vil du bli med det du allerede har (Hyper-VESXi insert_needed).
Kilde: www.habr.com