I det foregående der blev overvejet muligheder for, hvad de eksisterende systemer kunne erstattes med som led i implementeringen af importsubstitutionsbekendtgørelsen. De følgende artikler vil fokusere på at vælge specifikke produkter til at erstatte dem, der aktuelt er implementeret. Lad os starte med udgangspunktet – virtualiseringssystemet.
1. Valgets kvaler
Så hvad kan du vælge imellem? I :
- Servervirtualiseringssystem "R-virtualisering» (libvirt, KVM, QEMU)
- Softwarepakke"Brest virtualiseringsværktøjer» (libvirt, KVM, QEMU)
- Platform til styring og overvågning af virtualiseringsmiljøet "Sharx Stream" (en cloud-løsning, der ikke er egnet til offentlige kontorer i 95 % af tilfældene (hemmeligholdelse osv.)
- Softwarepakke til virtualisering af servere, desktops og applikationer "HOST" (KVM x86)
- System til sikker styring af virtualiseringsmiljøet "Z|virt"(alias oVirt+KVM)
- Virtualiseringsmiljøstyringssystem "ROSA Virtualisering"(alias oVirt+KVM)
- Hypervisor QP VMM (for ligner Oracle Virtual Box til at være noget andet)
Du kan også tage højde for hypervisorer, der er inkluderet i OS-distributionen eller placeret i deres arkiver. For eksempel har Astra Linux KVM-understøttelse. Og da det er inkluderet i OS-lagrene, kan det betragtes som "legitimt" til installation og brug. "Hvad kan bruges som en del af importsubstitution og hvad der ikke kan" blev diskuteret i det foregående , så jeg vil ikke dvæle ved dette spørgsmål.
Faktisk her :
- VirtualBox
- Virt-manager (KVM) Ørnestrøm
- libvirt over KVM
ROSA Linux har ikke sådan en liste, men du kan finde den på wikien :
- ROSA Virtualisering over oVirt over KVM
- QEMU over KVM
- oVirt 3.5 over KVM
Beregn har dette
Alt Linux har det samme
1.2. Der er et MEN
Ved nærmere undersøgelse konkluderer vi, at vi kun vil have at gøre med nogle få velkendte hypervisorer, nemlig:
QEMU er et gratis og open source-program til at emulere hardware fra forskellige platforme, som kan fungere uden brug af KVM, men brug af hardwarevirtualisering fremskynder ydeevnen af gæstesystemer markant, så brug af KVM i QEMU (-enable-kvm) er den foretrukne mulighed. (c) Det vil sige, at QEMU er en type 2 hypervisor, hvilket er uacceptabelt i et produktmiljø. Med KVM kan det bruges, men i dette tilfælde vil QEMU blive brugt som KVM-styringsværktøj...
Brug af originalen VirtualBox i handel er faktisk : “Fra og med version 4, udgivet i december 2010, distribueres hovedparten af produktet gratis under GPL v2-licensen. En ekstra pakke installeret oven på den, der giver understøttelse af USB 2.0- og 3.0-enheder, Remote Desktop Protocol (RDP), drevkryptering, opstart fra NVMe og PXE, distribueres under en speciel PUEL-licens ("til personlig brug og evaluering"). , hvorefter systemet er gratis til personlig brug, til træningsformål eller til evaluering, før du beslutter dig for at købe den kommercielle version." (c) Plus VirtualBox er også en type 2 hypervisor, så den forsvinder også.
Totalt: i sin rene form har vi kun KVM.
2. Resten: KVM eller KVM?
Hvis du stadig skal skifte til en "indenlandsk" hypervisor, er dit valg ærligt talt lille. Det vil være KVM i en eller anden indpakning, med visse modifikationer, men det vil stadig være KVM. Om dette er godt eller dårligt er et andet spørgsmål; der er stadig intet alternativ.
Hvis betingelserne ikke er så strenge, så som diskuteret i det foregående : “Vi er nødt til at bringe indikatorerne til de fastsatte grænser. Det betyder faktisk, at vi skal udskifte de eksisterende styresystemer med produkter fra Tele- og Massekommunikationsministeriets register og øge antallet af udskiftede styresystemer til 80 %.... Så vi kan roligt lade klyngen blive på Hyper-V, da vi har det, og vi kan lide det... "(c) Så vi står over for et valg: Microsoft Hyper-v eller KVM. KVM måske med kontroller "skruet" til det, men det vil stadig forblive det samme KVM.
Disse produkter er langt fra sammenlignelige Ikke Ikke ...Nå, du forstår...
Om implementering og konfiguration KVM det var ikke skrevet på samme måde Ikke Ikke ikke ... I et ord, .
Det samme gælder for
Jeg ser ingen mening i at gentage mig selv og beskrive disse systemer, sammenligne mv. Du kan selvfølgelig trække nøglepunkter frem fra artikler, men det ville være respektløst over for forfatterne, synes jeg. Den, der skal vælge, vil læse ikke kun dette, men også et bjerg af information for at bestemme sig.
Den eneste forskel, jeg vil fokusere på, er failover-klynger. Hvis Microsoft har dette indbygget i OS og hypervisor-funktionaliteten, så skal du i tilfælde af KVM bruge tredjepartssoftware, som bør inkluderes i OS-lagrene. Den samme kombination af Corosync+Pacemaker f.eks. (Næsten alle indenlandske operativsystemer har denne kombination... måske dem alle, men jeg tjekkede ikke 100% af dem.) Manualer til opsætning af clustering er også tilgængelige i overflod.
3. Konklusion
Nå, som sædvanlig gad vores Kulibins ikke, de tog hvad de havde, tilføjede lidt af deres eget og producerede et "produkt", der ifølge dokumenter er indenlandsk, men i virkeligheden er OpenSource. Giver det mening at bruge penge fra budgettet på "separate" virtualiseringssystemer (læs: ikke inkluderet i OS)? Tænk ikke. Da du stadig vil modtage den samme KVM, skal du kun betale for den.
At vælge en erstatning for en hypervisor afhænger således af, hvilket server-OS du vil købe til Enterprise og betjene. Eller, som i mit tilfælde, vil du blive med det, du allerede har (Hyper-VESXi insert_needed).
Kilde: www.habr.com