Importsubstitusjon i praksis. Del 2. Begynnelse. Hypervisor

I forrige artikkel Det ble vurdert alternativer for hva de eksisterende systemene kunne erstattes med som en del av implementeringen av importsubstitusjonsordren. De følgende artiklene vil fokusere på å velge spesifikke produkter for å erstatte de som er distribuert for øyeblikket. La oss starte med utgangspunktet – virtualiseringssystemet.

1. valgets kvaler

Så, hva kan du velge mellom? I register for Tele- og massekommunikasjonsdepartementet det er et valg:

• 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 artikkel, så jeg vil ikke dvele ved dette problemet.

Faktisk her liste over Astra Linux-virtualiseringsverktøy:

• VirtualBox
• Virt-manager (KVM) Ørnestrøm
• libvirt over KVM

ROSA Linux har ikke en slik liste, men du finner den på wikien følgende pakker:

• ROSA virtualisering over oVirt over KVM
• QEMU over KVM
• oVirt 3.5 over KVM

Calculate har dette QEMU over KVM

Alt Linux har det samme KVM

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:

1. KVM
2. VirtualBox
3. QEMU

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 brudd på lisensen: "Fra og med versjon 4, utgitt i desember 2010, distribueres hoveddelen av produktet gratis under GPL v2-lisensen. En ekstra pakke installert på toppen av den, som gir støtte for USB 2.0- og 3.0-enheter, Remote Desktop Protocol (RDP), stasjonskryptering, oppstart fra NVMe og PXE, distribueres under en spesiell PUEL-lisens ("for personlig bruk og evaluering"). , der systemet er gratis for personlig bruk, for opplæringsformål eller for evaluering før du bestemmer deg for å kjøpe den kommersielle versjonen." (c) Plus VirtualBox er også en type 2 hypervisor, så den forsvinner også.

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 artikkel: «Vi må bringe indikatorene til de etablerte grensene. Faktisk betyr dette at vi må erstatte det eksisterende operativsystemet med produkter fra departementet for telekom og massekommunikasjon og øke antallet erstattede operativsystemer til 80 %... Så vi kan trygt la klyngen være på Hyper-V , siden vi har det og vi liker det... "(c) Så vi står overfor et valg: Microsoft Hyper-v eller KVM. KVM kanskje med kontroller "skrudd" til den, men den vil fortsatt forbli den samme KVM.

Disse produktene er langt fra sammenlignbare en gangIkke to gangerIkke tre ganger...Vel, du forstår...

Om distribusjon og konfigurasjon KVM det var ikke skrevet på samme måte en gangIkke to gangerIkke tre ganger og ikke fire ganger... I et ord, falmet bort.

Det samme gjelder Microsoft Hyper V..

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