I det föregående alternativ övervägdes för vad de befintliga systemen skulle kunna ersättas med som en del av genomförandet av importsubstitutionsförordningen. Följande artiklar kommer att fokusera på att välja specifika produkter för att ersätta de som för närvarande distribueras. Låt oss börja med utgångspunkten - virtualiseringssystemet.
1. Kval av val
Så vad kan du välja mellan? I :
- Servervirtualiseringssystem "R-virtualisering» (libvirt, KVM, QEMU)
- Mjukvarupaket "Brest virtualiseringsverktyg» (libvirt, KVM, QEMU)
- Plattform för hantering och övervakning av virtualiseringsmiljön "Sharx Stream" (en molnlösning som inte lämpar sig för statliga kontor i 95 % av fallen (sekretess, etc.)
- Mjukvarupaket för virtualisering av servrar, stationära datorer och applikationer "VÄRD" (KVM x86)
- System för säker hantering av virtualiseringsmiljön "Z|virt"(aka oVirt+KVM)
- Managementsystem för virtualiseringsmiljö"ROSA virtualisering"(aka oVirt+KVM)
- Hypervisor QP VMM (för lik Oracle Virtual Box för att vara något annat)
Du kan också ta hänsyn till hypervisorer som ingår i OS-distributionen eller finns i deras arkiv. Till exempel har Astra Linux KVM-stöd. Och eftersom det är inkluderat i OS-arkiven kan det anses vara "legitimt" för installation och användning. "Vad kan användas som en del av importsubstitution och vad som inte kan" diskuterades i föregående , så jag tänker inte uppehålla mig vid denna fråga.
Faktiskt här :
- VirtualBox
- Virt-chef (KVM) Örnström
- libvirt över KVM
ROSA Linux har ingen sådan lista, men du kan hitta den på wikin :
- ROSA virtualisering över oVirt över KVM
- QEMU över KVM
- oVirt 3.5 över KVM
Calculate har detta
Alt Linux har samma sak
1.2. Det finns ett MEN
Vid närmare granskning drar vi slutsatsen att vi bara kommer att behöva hantera ett fåtal välkända hypervisorer, nämligen:
QEMU är ett gratis och öppen källkodsprogram för att emulera hårdvara från olika plattformar, som kan fungera utan att använda KVM, men att använda hårdvaruvirtualisering snabbar upp prestanda avsevärt för gästsystem, så att använda KVM i QEMU (-enable-kvm) är det föredragna alternativet. (c) Det vill säga QEMU är en typ 2 hypervisor, vilket är oacceptabelt i en produktmiljö. Med KVM kan det användas, men i det här fallet kommer QEMU att användas som KVM-hanteringsverktyget...
Använder originalet VirtualBox i handeln är faktiskt : “Från och med version 4, släppt i december 2010, distribueras huvuddelen av produkten gratis under GPL v2-licensen. Ett extra paket installerat ovanpå det, som ger stöd för USB 2.0- och 3.0-enheter, Remote Desktop Protocol (RDP), enhetskryptering, uppstart från NVMe och PXE, distribueras under en speciell PUEL-licens ("för personligt bruk och utvärdering"). , enligt vilket systemet är gratis för personligt bruk, för utbildningsändamål eller för utvärdering innan du bestämmer dig för att köpa den kommersiella versionen." (c) Plus VirtualBox är också en typ 2 hypervisor, så den försvinner också.
Totalt: i sin rena form har vi bara KVM.
2. Resten: KVM eller KVM?
Om du fortfarande behöver byta till en "inhemsk" hypervisor är ditt val, ärligt talat, litet. Det kommer att vara KVM i ett eller annat omslag, med vissa modifieringar, men det kommer fortfarande att vara KVM. Om detta är bra eller dåligt är en annan fråga, det finns fortfarande inget alternativ.
Om villkoren inte är så strikta, då, som diskuterats i föregående : ”Vi måste föra indikatorerna till de fastställda gränserna. Detta betyder faktiskt att vi måste ersätta det befintliga operativsystemet med produkter från ministeriet för telekom och masskommunikation och öka antalet utbytta operativsystem till 80 %... Så vi kan lugnt lämna klustret på Hyper-V , eftersom vi har det och vi gillar det... "(c) Så vi står inför ett val: Microsoft Hyper-v eller KVM. KVM kanske med kontroller "skruvade" till det, men det kommer fortfarande att förbli detsamma KVM.
Dessa produkter är långt ifrån jämförbara , inte , inte ...Jaha, du förstår...
Om distribution och konfiguration KVM det var inte skrivet på samma sätt , inte , inte och inte ... I ett ord, .
Detsamma gäller för
Jag ser ingen mening med att upprepa mig och beskriva dessa system, jämföra osv. Man kan givetvis dra fram nyckelpunkter från artiklar, men det skulle vara respektlöst mot författarna tycker jag. Den som måste välja kommer att läsa inte bara detta, utan också ett berg av information för att bestämma sig.
Den enda skillnaden jag vill fokusera på är failover-klustring. Om Microsoft har detta inbyggt i operativsystemet och hypervisorfunktionaliteten, måste du i fallet med KVM använda programvara från tredje part, som bör inkluderas i OS-förråden. Samma kombination av Corosync+Pacemaker, till exempel. (Nästan alla inhemska operativsystem har den här kombinationen... kanske alla, men jag kollade inte 100% av dem.) Manualer för att sätta upp klustring finns också i överflöd.
3. Slutsats
Tja, som vanligt brydde sig inte våra Kulibins, de tog vad de hade, lade till lite eget och producerade en "produkt" som enligt dokument är inhemsk, men i verkligheten är OpenSource. Är det vettigt att spendera pengar från budgeten på "separata" virtualiseringssystem (läs: ingår inte i operativsystemet)? Tänk inte. Eftersom du fortfarande kommer att få samma KVM behöver du bara betala för det.
Att välja en ersättare för en hypervisor beror alltså på vilket server-OS du ska köpa till företaget och driva. Eller, som i mitt fall, kommer du att stanna med det du redan har (Hyper-VESXi insert_needed).
Källa: will.com