KVM vs VMware-sammenligning til virksomhedsvirtualisering

Informatic Digital » Recursos » KVM vs VMware-sammenligning til virksomhedsvirtualisering

Hvis du tøver med at konfigurere din infrastruktur på KVM eller VMware (eller blot ønsker at forstå bedre, hvad hver enkelt tilbyder), giver denne guide en dybdegående sammenligning: ydeevne, sikkerhed, licenser, support, containerkompatibilitet, backup, klyngedannelse, netværk, diskformater, integration med andre komponenter som OpenStack eller Active Directory ... ideen er, at når du er færdig med at læse, vil du have en klar forståelse af, hvilket scenarie hver mulighed udmærker sig i.

Hvad er KVM og VMware, og hvordan ligner de hinanden?

VMware er på sin side virksomheden bag en hel familie af virtualiseringsprodukter. I forbindelse med datacentre er nøglespilleren VMware ESXi , en Type 1 hypervisor, der danner kernen i VMware vSphere- platformen . Omkring ESXi drejer sig vCenter, vSAN, NSX, Horizon, Tanzu og mange andre komponenter, der udgør et meget modent økosystem til krævende virksomhedsmiljøer.

Både KVM og ESXi er Type 1 bare-metal hypervisorer, der er i stand til at køre flere virtuelle maskiner (VM'er) med gæsteoperativsystemer som Windows, Linux, BSD eller Solaris, med understøttelse af hardwareassisteret virtualisering (Intel VT-x, AMD-V). Konceptuelt set tillader begge VM-provisionering, isolering, live-migreringer , snapshots og administration af store klynger. Forskellen ligger i, hvordan disse funktioner opnås, deres omkostninger, deres fleksibilitet og de administrative muligheder, som hver især tilbyder.

Hypervisortyper og intern arkitektur

Inden for virtualisering skelnes der normalt mellem type 1 (bare-metal) og type 2 (installeret oven på et værtsoperativsystem) hypervisorer. KVM og ESXi er type 1, mens produkter som VMware Workstation, VMware Player, VMware Fusion og VirtualBox er type 2.

I tilfælde af KVM , selvom den er installeret som en del af en Linux-vært, betragtes den som en Type 1-hypervisor, fordi Linux-kernen fungerer som en direkte hypervisor på hardwaren. KVM arver således CPU-scheduleren, hukommelsesstyringen og netværksstakken fra Linux selv, hvilket giver den betydelig fleksibilitet og hardwarekompatibilitet.

ESXi er VMwares eget minimale operativsystem, designet specifikt som en hypervisor. Det har en lukket kerne , integreret med certificerede og optimerede drivere, og bruger VMwares administrationsplan til at interagere med hardwaren og resten af ​​pakken (vCenter, NSX osv.). Denne tilgang reducerer softwarefodaftrykket til kun det, der er strengt nødvendigt for virtualisering.

Ud over forskellen mellem type 1/type 2 er det vigtigt at forstå forskellen mellem fuld "bar" virtualisering og hardwareassisteret virtualisering . Ved ren softwarebaseret fuld virtualisering emulerer hypervisoren al hardware og oversætter CPU-instruktioner (binær oversættelse), hvilket er langsommere, men tillader det at køre uden VT-x/AMD-V. Ved hardwareassisteret virtualisering udføres nogle vCPU-instruktioner direkte på den fysiske CPU, hvilket reducerer overhead betydeligt. KVM og ESXi er afhængige af sidstnævnte tilgang for at levere høj ydeevne.

Ydeevne: Yder KVM eller VMware bedre?

Den rå ydeevne af KVM og ESXi er meget ens i de fleste produktionsscenarier. KVM er bygget på cirka 10.000 højoptimerede kodelinjer i Linux-kernen, hvilket reducerer overhead, og med QEMU og virtio opnår den næsten native ydeevne for CPU, disk og netværk.

I tilfældet med VMware ESXi er kildekoden proprietær, men det samlede produkt anslås at være i titusindvis af millioner af linjer, når alle økosystemkomponenter er inkluderet. I visse syntetiske benchmarks er VM'er blevet set som en smule hurtigere på KVM end på ESXi, men i virkelige virksomhedsmiljøer er forskellene normalt marginale sammenlignet med andre flaskehalse såsom lagring eller netværk.

VMware får en fordel i scenarier, der involverer planlægningsoptimeringer, DRS, vMotion og Storage vMotion , som muliggør load balancing og hot-moving af VM'er med minimal påvirkning, hvilket opretholder en meget stabil ydeevne, selv når klyngen er tæt befolket.

KVM er derimod især fremragende i miljøer, hvor Linux allerede er veletableret, og kernen (CPU-regulator, I/O-scheduler, hugepages, NUMA osv.) og netværksstakken kan finjusteres. Ved at dele kernen med værten, implementerer den meget hurtigt hardwareforbedringer, som producenterne har indarbejdet i Linux-kernen.

Installations-, kompleksitets- og administrationsværktøjer

Læringskurven er et af de områder , hvor forskellen mellem KVM og VMware er mest mærkbar. Med KVM involverer installationen først opsætning af et Linux-system (Ubuntu, RHEL, CentOS, Oracle Linux, SUSE osv.) og installation af de nødvendige pakker: KVM/QEMU, libvirt , administrationsværktøjer som virt-manager eller virt-install, og om nødvendigt manuel konfiguration af den virtuelle switch, broer og bonding . Det er meget fleksibelt, men det kræver en betydelig forståelse af Linux-økosystemet.

I VMware ESXi er arbejdsgangen mere guidet: du downloader ISO-billedet, brænder det til et USB-drev eller en cd, starter serveren op og følger en meget simpel grafisk guide . Det næste trin er normalt at implementere vCenter Server Appliance (en prækonfigureret VM) fra den ISO, og derfra administreres stort set alt via vSphere Client-webgrænsefladen.

Dagligt administreres KVM med værktøjer som virsh (en CLI til libvirt) og virt-manager (en desktop GUI til administration af flere KVM-værter), samt SSH, VNC eller SPICE til at forbinde til VM-konsoller. Webgrænseflader som Kimchi og Foreman er tilgængelige, og projekter som oVirt og Red Hat Virtualization tilføjer et avanceret visuelt lag oven på KVM.

I VMware vSphere er hjørnestenen i styringen vCenter med dens vSphere Client-webklient , hvorfra ESXi-værter, klynger, virtuelle netværk, datalagre, HA, DRS, vSAN, NSX og mere styres. Derudover er der ESXCLI til kommandolinjen, PowerCLI (baseret på PowerShell) til automatisering af næsten alt og Host Client-grænsefladen til enkeltstående ESXi-værter uden vCenter.

Omkostninger, licenser og supportmodel

Med hensyn til omkostninger er forskellen tydelig: KVM er open source-software integreret i Linux og kræver ikke hypervisor-licenser som sådan. Det er tilgængeligt på enhver moderne Linux-distribution, siden det blev integreret i kernen i 2007. Omkostningerne stammer fra kommerciel support (Red Hat, SUSE, Oracle osv.) og eventuelle yderligere administrationsværktøjer, du måtte ønske at tilføje, men kernefunktionaliteten er gratis.

VMware vSphere er en kommerciel løsning, der typisk licenseres pr. CPU/kerne og udgave (Standard, Enterprise Plus osv.). Den inkluderer licenser til ESXi og vCenter, og hvis du vil tilføje produkter som NSX, vSAN, Tanzu, Horizon eller vRealize , kræver hver sin egen ekstra licens. Der findes en gratis udgave af ESXi (vSphere Hypervisor), men den har betydelige begrænsninger : skrivebeskyttede API'er, ingen vCenter-administration, ingen teknisk support og ingen mulighed for at bruge backupløsninger, der er afhængige af API'erne.

Med hensyn til support tilbyder VMware 24/7 virksomhedssupport i henhold til kontrakten, med adgang til deres vidensbase, opdateringer, programrettelser og direkte assistance. Med KVM afhænger den "officielle" support af din distributionsudbyder (Red Hat, Oracle, SUSE osv.) eller dit eget IT-team, og du har altid support fra et meget aktivt fællesskab, men der er ikke en eneste KVM-leverandør at indsende en supportsag til, medmindre du har en kontrakt med en bestemt leverandør.

Hardwarekompatibilitet og skaleringsgrænser

Hardwarekompatibilitet er en anden differentierende faktor. Da KVM er baseret på Linux , arver den den omfattende liste over hardware, der understøttes af kernen: x86 CPU'er med VT-x/AMD-V , flere typer diskcontrollere, netværkskort, arkitekturer som ARM eller PowerPC i visse varianter osv. Så længe kernen har en driver, kan KVM normalt fungere på den pågældende vært uden for mange problemer.

VMware ESXi kræver, at serveren og komponenterne er på dens Hardware Compatibility List (HCL) . Dette sikrer certificerede drivere og optimal ydeevne, men begrænser brugen af ​​den på ældre eller meget nyere hardware, der endnu ikke har gennemgået certificeringsprocessen. I store projekter kan dette øge platformens omkostninger på grund af behovet for at købe specifik hardware, der anbefales af VMware.

Med hensyn til begrænsninger angiver kommercielle distributioner, der pakker KVM, vejledende tal. For eksempel understøttes der i visse miljøer værdier på op til 384 CPU-kerner og 6 TB RAM pr. vært , med omkring 600 samtidige VM'er, og op til 256 vCPU'er (eller mere i nyere versioner) og adskillige terabyte virtuel RAM kan opnås pr. VM . Dette afhænger af distributionen (Red Hat, Oracle Linux, SUSE) og de valideringstests, der udføres af hver leverandør.

I VMware vSphere sætter den officielle dokumentation meget høje grænser: op til 896 logiske CPU'er og 24 TB RAM pr. ESXi-vært , 1.024 VM'er pr. vært, 4.096 aggregerede vCPU'er, 256 vCPU'er pr. VM, mere end 6 TB RAM pr. VM, virtuelle diske op til 62 TB og klynger på op til 64 værter og 8.000 VM'er . På vCenter-niveau kan op til 2.500 ESXi-værter og 40.000 VM'er pr. instans administreres, hvilket giver betydelig plads til vækst.

Sikkerhed: isolation, kryptering og overholdelse af regler

Hypervisor-sikkerhed er afgørende: Hvis nogen kompromitterer værten, har de en åben dør til alle VM'er og deres data. KVM udnytter Linux-sikkerhedsøkosystemet til at styrke isolationen. Dens nøglefunktion er den kombinerede brug af SELinux (Security-Enhanced Linux) og sVirt (Secure Virtualization) . SELinux definerer obligatoriske adgangskontrolpolitikker (MAC), og sVirt udvider disse politikker til VM'erne, taggingprocesser og diskbilleder for at isolere dem fra hinanden.

Derudover kan du udnytte iptables/nftables til avanceret firewalling, UEFI sikker opstart på gæstemaskiner (med en vis manuel konfiguration) og hukommelseskrypteringsteknologier som TME/MKTME på kompatibel hardware. På diskniveau giver KVM dig mulighed for at kryptere QCOW2-billeder med 128-bit AES transparent for gæsten eller delegere kryptering til værtsfilsystemet eller selve gæsteoperativsystemet.

VMware vSphere udmærker sig også på dette område med et sæt funktioner designet til regulerede miljøer (HIPAA, PCI DSS osv.). Det tilbyder en integreret firewall i ESXi , understøttelse af Secure Boot UEFI, integration med TPM og vSphere Trust Authority, detaljeret administration af tilladelser og roller samt kryptering af virtuelle maskiner med integration med ekstern KMS eller den native vSphere-nøgleudbyder.

VM'er i VMware kan bruge vTPM og virtualiseringsbaseret sikkerhed, og NSX leverer distribueret side-end-sikkerhed (mikrosegmentering, distribueret firewall, IDS/IPS afhængigt af udgaven). Derudover tilbyder VMware compliance-overvågning og værktøjer til håndhævelse af hypervisor-konfiguration, hvilket gør det nemmere at tilpasse platformen til strenge regler.

Virtuelle netværk og konnektivitet

På netværksniveau er KVM afhængig af Linux-kernens funktioner og specifikke værktøjer. Til virtuelle switche bruges Open vSwitch (OVS) almindeligvis , der muliggør offentlige eller private virtuelle broer, distribueret switching mellem værter og understøttelse af VLAN'er, VXLAN'er, QoS og andre avancerede funktioner. Klassiske Linux-broer kan også oprettes, og bonding eller teaming kan bruges til at tilføje links eller konfigurere redundans.

Virtio-netværksgrænseflader understøtter VLAN'er og kan orkestreres med libvirt , som inkluderer virtuel netværksadministration og en DHCP-server integreret i QEMU. Firewallfunktioner er lige så omfattende som selve Linux-netværksstakken, og VXLAN'er, tunneler, VPN'er og mere kan konfigureres ved hjælp af standard økosystemværktøjer.

I VMware vSphere er netværket baseret på to typer switche: standard vSwitchen (konfigureret pr. vært) og den distribuerede vSwitch (centralt administreret fra vCenter). Begge understøtter VLAN'er, NIC-teaming til load balancing og failover samt grundlæggende sikkerhedspolitikker. Til avanceret softwaredefineret netværk (mikrosegmentering, VXLAN, load balancers, distribuerede politikker) anvendes VMware NSX.

Konfiguration af linkaggregation, portgrupper, trafikpolitikker eller netværk til vMotion og lagring er normalt mere brugervenligt i vSphere GUI end at gøre det hele via CLI i Linux, selvom KVM tilbyder mere frihed til "eksotiske" scenarier, hvis du er fortrolig med iproute2, OVS og lignende.

Lagring, diskformater og migrering

Med KVM kan stort set alt, hvad Linux kan montere som fysisk eller logisk lagring, bruges: SAS, SATA, NVMe-diske, LVM-volumener, NFS, iSCSI, SAN, NAS osv. VM'er kan bruge virtuelle diskbilleder eller Raw Device Mapping (enheds- eller volumenpassthrough). Det er også muligt at tilknytte en LVM-volumen direkte til en VM.

De native billedformater er raw (img) og qcow2 . Raw-formatet er meget simpelt og hurtigt (omkring 10 % hurtigere end formater med yderligere lag), men det understøtter ikke interne snapshots eller inkrementelle backups på blokniveau. Qcow2 tilbyder derimod snapshots, komprimering, kryptering, tynd provisionering og TRIM/UNMAP-understøttelse , så du kan genvinde ubrugt plads med værktøjer som virt-sparsify. Derudover forstår KVM andre formater som VMDK (fra VMware), VDI (VirtualBox), VHDX (Hyper-V) og mange flere, hvilket letter migrering mellem platforme.

I VMware ESXi er standarddiskformatet VMDK . Hver disk består typisk af en .vmdk-deskriptor og en flad .vmdk-fil, der indeholder dataene. Tynd og tyk provisionering understøttes, og datalageret hostes normalt på VMFS eller NFS. Diske kan udnytte automatisk afkortning for at frigøre plads, og Raw Device Mapping (RDM) kan bruges til at kortlægge LUN'er direkte til VM'er.

Til VM-migrering tilbyder KVM live-migrering mellem værter, så længe de deler lagerplads, og lagermigrering (flytning af VM-filer til en anden vært) i visse scenarier, med planer om at udvide live-lagermigrering. VMware har tilbudt vMotion (live VM-migrering mellem værter) og Storage vMotion (migrering af diske mellem datalagre uden at lukke den virtuelle maskine ned) i årevis, begge yderst veludviklede og velintegrerede i klyngestyring.

Klyngedannelse, høj tilgængelighed og load balancing

I klyngedannelse tilbyder KVM komponenterne, men ikke et "lukket" produkt sammenligneligt med vSphere. For høj tilgængelighed bruges værktøjer som DRBD (blokreplikation over netværket), Heartbeat og Pacemaker som klyngeressourceadministratorer. Failover-konfiguration mellem noder er mulig , men det kræver typisk mange manuelle operationer og betydelig ekspertise.

Automatiseret load balancing er ikke en standardfunktion; den er typisk afhængig af projekter som oVirt eller Red Hat Virtualization , der bygger et avanceret administrationslag oven på KVM for at levere automatiske migreringer baseret på belastning, høj tilgængelighed (HA), politikker og andre faktorer. Generelt er det ikke ligetil at opsætte en velafstemt KVM-klynge med HA uden en kommerciel løsning, der inkluderer det.

I modsætning hertil skiller VMware vSphere sig netop ud for sine klyngefunktioner. Funktioner som vSphere HA gør det muligt for VM'er at blive genstartet automatisk på andre værter, hvis en node fejler, og DRS (Distributed Resource Scheduler) genbalancerer belastningen ved at flytte VM'er mellem værter ved hjælp af vMotion baseret på CPU- og RAM-forbrugspolitikker. Fejltolerance er også tilgængelig for visse VM'er, hvilket opretholder en realtidsreplika og sikrer problemfri kontinuitet i tilfælde af en værtsfejl.

Derudover kan Distributed Power Management lukke værter ned, når belastningen er lav, og genstarte dem efter behov, hvilket sparer energi uden at gå på kompromis med kapaciteten. Konfiguration af disse mekanismer er ret simpel fra vSphere Client, hvilket gør VMware til den mest bekvemme løsning, hvis du har brug for kompleks klyngedannelse uden at skulle kæmpe med konsollen.

Kompatibilitet mellem gæstesystemer og containere

Både KVM og VMware ESXi understøtter en bred vifte af gæsteoperativsystemer: Windows (fra meget gamle versioner som NT eller 95 til de nuværende), mange Linux-distributioner (Ubuntu, Debian, RHEL, CentOS, Fedora, Oracle Linux, SUSE, Kali osv.), BSD-derivater (FreeBSD, OpenBSD), Solaris, OpenSolaris, NetWare, MS-DOS og endda macOS med visse justeringer og begrænsninger.

Der er forskelle i integrationen med containerverdenen . Med KVM kan du køre Docker eller Kubernetes inde i VM'er, ligesom med enhver anden hypervisor, men der er også specifikke drivere (docker-machine-driver-kvm) , der giver dig mulighed for at oprette Docker-maskiner oven på KVM transparent, hvilket forbedrer isolation og ydeevne sammenlignet med manuel opsætning af VM'er. Derudover integrerer KVM rigtig godt med OpenStack , hvor det er klassificeret som Gruppe A (maksimal kompatibilitet) og ofte er den foretrukne hypervisor i Linux private clouds.

VMware har på sin side taget et første skridt med vSphere Integrated Containers (som kører containere som lette VM'er ved hjælp af Photon OS), og har taget et betydeligt spring fremad med VMware Tanzu , som integrerer Kubernetes og containere direkte i ESXi. Tanzu transformerer ESXi-værter til Kubernetes-noder (ved hjælp af Spherelet), eksponerer et kontrolplan til DevOps, administreres fra vCenter og udnytter NSX-T og delt lagring til at levere et omfattende enterprise containermiljø (omend med ekstra licensomkostninger).

Kort sagt, hvis du er stærkt involveret i Linux-baserede native cloud-økosystemer, er KVM + OpenStack/Kubernetes et godt valg; hvis du allerede har en betydelig investering i VMware og leder efter containere integreret i din vSphere-platform med alle netværks- og sikkerhedsfunktioner, er Tanzu en stærk mulighed.

Integration med andre komponenter: AD, OpenStack og økosystem

VMware vSphere integreres nativt med Microsoft Active Directory for godkendelse og rollebaseret adgangskontrol. Brugere kan logge ind på vSphere-klienten med deres domænelegitimationsoplysninger og tildele detaljerede tilladelser til objekter (VM'er, datalagre, klynger osv.). Derudover integrerer VMware-pakken problemfrit: NSX til netværk, vSAN til softwaredefineret lagring, Horizon til VDI, vRealize til automatisering og overvågning og mere.

I KVM- verdenen er Active Directory-integration fuldt ud mulig ved at forbinde Linux-værten (eller VM'erne) til domænet, men konfigurationen involverer håndtering af værktøjer som sssd, winbind eller realmd. Til cloud-orkestrering skinner KVM sammen med OpenStack , hvor det er det foretrukne valg (Gruppe A), mens ESXi er klassificeret som Gruppe B: understøttet, men noget mindre prioriteret i OpenStack-økosystemet.

Med hensyn til leverandørbinding, tillader KVM, som open source og uden leverandørbinding , integration med stort set enhver kommerciel eller open source-software, og tilpasser stakken til dine behov. Med VMware har du en tendens til at bygge løsningen omkring dens kontrolplan og produkter, hvilket giver en masse konsistens, men binder dig også til dens licenser og roadmap.

Backup, replikering og databeskyttelse

Måden, VM'er sikkerhedskopieres på, har også betydelige forskelle. I KVM involverer de grundlæggende metoder brugen af ​​virsh og disk-snapshots. Hvis LVM-volumener bruges til VM'erne, kan LVM-snapshots oprettes og sikkerhedskopieres fra disse volumener, hvilket giver meget god ydeevne, men gør migrering og pladsstyring mere kompleks.

Med rå billeder er sikkerhedskopier kun mulige, når den virtuelle maskine er slukket, da der ikke er nogen understøttelse af native snapshots på billedniveau. Med qcow2 kan der oprettes snapshots på en kørende virtuelle maskine (hvilket kræver QEMU-gæsteagenten på gæsteoperativsystemet og konfigurationen af ​​en org.qemu.guest_agent.0-kanal), og dataene kan derefter kopieres ensartet. Der findes løsninger, der udnytter libvirt og oVirt til at implementere trinvise sikkerhedskopier baseret på blokændringer.

Til replikering kan KVM bruge DRBD på Linux-kerneblokniveau og synkront replikere diske mellem noder for at montere klynger med høj tilgængelighed, dog normalt uden kryptering, medmindre trafikken er indkapslet i VPN'er eller lignende.

I VMware vSphere er databeskyttelsen robust takket være vStorage Data Protection API'er . Backup-leverandører (Veeam, NAKIVO osv.) bruger disse API'er til at oprette ensartede snapshots af kørende VM'er med applikationspause via VMware Tools og til at udnytte Changed Block Tracking (CBT) , hvilket muliggør yderst effektive inkrementelle backups ved kun at kopiere modificerede blokke.

Backupløsninger til VMware understøtter typisk øjeblikkelig VM-gendannelse , granulær gendannelse af programfiler eller objekter (Exchange, SQL, AD osv.) og replikering mellem ESXi-værter eller -sites. Den gratis udgave af ESXi eksponerer ikke disse API'er, så i så fald ville du have brug for scripts og manuelle backups af slukkede VM'er, hvilket generelt er uacceptabelt i produktion.

Hvis databeskyttelse på hypervisor-niveau og integration med adskillige kommercielle backupløsninger er afgørende, tilbyder vSphere i sidste ende et mere modent og homogent økosystem. KVM muliggør robuste strategier, men med en bredere vifte af tilgange og større afhængighed af teamets ekspertise og de valgte værktøjer.

Hvornår er KVM det værd, og hvornår er VMware det værd?

Valget mellem KVM og VMware handler ikke om, at den ene er "bedre" i absolutte termer, men snarere om at vælge det rigtige værktøj til konteksten. For organisationer med stramme budgetter , en stærk Linux-kultur og et ønske om at tilpasse platformen er KVM meget attraktivt: det kræver ingen hypervisor-licenser, tilbyder bred hardwarekompatibilitet og omfattende tilpasningsmuligheder. Det er ideelt til startups, små VPS-udbydere, testlaboratorier, Linux-centrerede miljøer eller private clouds baseret på OpenStack.

VMware ESXi og vSphere er bedst egnet til miljøer, der kræver en stærkt integreret tilgang, stærk kommerciel support og forenklet administration af store klynger. Virksomheder, der allerede bruger VMware-produkter (Horizon, NSX, vSAN, Tanzu), med strenge krav til tilgængelighed, overholdelse af regler og 24/7 support, eller som værdsætter en højglanspoleret, centraliseret konsol, foretrækker typisk at investere i vSphere-licenser og bygge deres virtualiseringsstrategi omkring dette økosystem.

Rent praktisk er KVM en højtydende og billig løsning , der belønner teams med Linux-erfaring og tolerance over for lidt mere kompleksitet. VMware tilbyder derimod en mere "lukket, men bekvem" oplevelse: Du betaler for licenser og vedligeholdelse, men til gengæld får du en ekstremt moden virtualiseringsplatform med avanceret klyngedannelse, finjusterede backupværktøjer og meget solid integration med resten af ​​dens stak.