KVM vs. VMware összehasonlítás a vállalati virtualizációhoz

Informatec Digital » Erőforrás » KVM vs. VMware összehasonlítás a vállalati virtualizációhoz

Ha habozol a KVM vagy a VMware infrastruktúra beállítása között (vagy egyszerűen csak jobban meg szeretnéd érteni, hogy melyik mit kínál), ez az útmutató részletes összehasonlítást nyújt: teljesítmény, biztonság, licencelés, támogatás, konténerkompatibilitás, biztonsági mentés, klaszterezés, hálózatépítés, lemezformátumok, integráció más komponensekkel, például az OpenStack-kel vagy az Active Directory-val… a lényeg az, hogy mire befejezed az olvasást, világosan megérted, hogy melyik lehetőség melyik forgatókönyvben a legmegfelelőbb.

Mik a KVM és a VMware, és miben hasonlítanak egymásra?

A VMware a maga részéről egy egész virtualizációs termékcsalád mögött álló vállalat. Az adatközpontok kontextusában a kulcsszereplő a VMware ESXi , egy 1-es típusú hipervizor, amely a VMware vSphere platform magját alkotja . Az ESXi körül a vCenter, a vSAN, az NSX, a Horizon, a Tanzu és számos más komponens forog, amelyek egy nagyon érett ökoszisztémát alkotnak az igényes vállalati környezetek számára.

Mind a KVM, mind az ESXi 1-es típusú bare-metal hipervizorok, amelyek képesek több virtuális gép (VM) futtatására vendég operációs rendszerekkel, például Windows, Linux, BSD vagy Solaris rendszerekkel, hardveresen támogatott virtualizációval (Intel VT-x, AMD-V). Elméletileg mindkettő lehetővé teszi a virtuális gépek kiépítését, elkülönítését, élő migrációkat , pillanatképeket és nagy klaszterek kezelését. A különbség abban rejlik, hogy hogyan valósulnak meg ezek a funkciók, mennyibe kerülnek, milyen a rugalmasságuk, és milyen adminisztratív lehetőségeket kínálnak mindegyikük.

Hipervizor típusok és belső architektúra

A virtualizációban általában különbséget tesznek az 1-es típusú (csupasz fém) és a 2-es típusú (gazda operációs rendszerre telepített) hipervizorok között. A KVM és az ESXi az 1-es típusba tartozik, míg az olyan termékek, mint a VMware Workstation, a VMware Player, a VMware Fusion és a VirtualBox a 2-es típusba.

A KVM esetében , bár egy Linux gazdagép részeként telepítik, 1-es típusú hipervizornak tekintik, mivel a Linux kernel közvetlen hipervizorként működik a hardveren. A KVM így a CPU ütemezőt, a memóriakezelést és a hálózati stacket magától a Linuxtól örökli, ami jelentős rugalmasságot és hardverkompatibilitást biztosít számára.

Az ESXi a VMware saját minimális operációs rendszere, amelyet kifejezetten hipervizorként terveztek. Zárt kernellel rendelkezik , amely tanúsított és optimalizált illesztőprogramokkal van integrálva, és a VMware felügyeleti síkját használja a hardverrel és a csomag többi részével (vCenter, NSX stb.) való interakcióhoz. Ez a megközelítés a szoftveres lábnyomot csak a virtualizációhoz feltétlenül szükséges mértékre csökkenti.

Az 1-es és 2-es típusú megkülönböztetés mellett fontos megérteni a teljes „csupasz” virtualizáció és a hardveresen támogatott virtualizáció közötti különbséget is. A tisztán szoftveralapú teljes virtualizációban a hipervizor emulálja az összes hardvert, és lefordítja a CPU utasításokat (bináris fordítás), ami lassabb, de lehetővé teszi a VT-x/AMD-V nélküli futtatást. Hardveresen támogatott virtualizáció esetén egyes vCPU utasítások közvetlenül a fizikai CPU-n hajtódnak végre, ami jelentősen csökkenti a terhelést. A KVM és az ESXi erre az utóbbi megközelítésre támaszkodik a nagy teljesítmény biztosítása érdekében.

Teljesítmény: A KVM vagy a VMware teljesít jobban?

A KVM és az ESXi nyers teljesítménye a legtöbb éles környezetben nagyon hasonló. A KVM körülbelül 10 000, nagymértékben optimalizált kódsorra épül a Linux kernelben, ami csökkenti a terhelést, a QEMU és a virtio segítségével pedig közel natív teljesítményt ér el a CPU, a lemez és a hálózat tekintetében.

A VMware ESXi esetében a forráskód saját fejlesztésű, de a teljes termék becslések szerint több tízmillió sorból áll, ha az összes ökoszisztéma-komponenst figyelembe vesszük. Bizonyos szintetikus benchmarkokban a virtuális gépek valamivel gyorsabbnak bizonyultak KVM-en, mint ESXi-n, de valós vállalati környezetekben a különbségek általában elhanyagolhatók más szűk keresztmetszetekhez, például a tároláshoz vagy a hálózatépítéshez képest.

A VMware előnyre tesz szert az ütemezési optimalizálásokat, a DRS-t, a vMotiont és a Storage vMotiont magában foglaló forgatókönyvekben , amelyek minimális hatással teszik lehetővé a terheléselosztást és a virtuális gépek gyorsmozgatását, így nagyon stabil teljesítményt nyújtanak még akkor is, ha a fürt nagy mennyiségben van jelen.

A KVM ezzel szemben különösen azokban a környezetekben ragyog, ahol a Linux már jól bevált, és a kernel (CPU-vezérlő, I/O-ütemező, hugepages, NUMA stb.) és a hálózati verem finomhangolható. A kernel gazdagéppel való megosztásával nagyon gyorsan átveszi a gyártók által a Linux kernelbe beépített hardverfejlesztéseket .

Telepítés, összetettség és felügyeleti eszközök

A tanulási görbe az egyik olyan terület, ahol a KVM és a VMware közötti különbség a leginkább észrevehető. A KVM esetében a telepítés először egy Linux rendszer (Ubuntu, RHEL, CentOS, Oracle Linux, SUSE stb.) beállítását és a szükséges csomagok telepítését foglalja magában: KVM/QEMU, libvirt , felügyeleti eszközök, mint például a virt-manager vagy a virt-install, és ha szükséges, a virtuális switch, a hidak és a bonding manuális konfigurálása . Nagyon rugalmas, de a Linux ökoszisztéma jelentős ismeretét igényli.

A VMware ESXi-ben a munkafolyamat irányítottabb: letölti az ISO-képfájlt, kiírja egy USB-meghajtóra vagy CD-re, elindítja a szervert, és egy nagyon egyszerű grafikus varázslót követ. A következő lépés általában a vCenter Server Appliance (egy előre konfigurált virtuális gép) telepítése az ISO-ról, és onnantól kezdve gyakorlatilag mindent a vSphere Client webes felületén keresztül lehet kezelni.

A KVM-et napi szinten olyan eszközökkel kezelik, mint a virsh (a libvirt parancssori felülete) és a virt-manager (egy asztali grafikus felhasználói felület több KVM-gazdagép kezeléséhez), valamint SSH-n, VNC-n vagy SPICE-on keresztül a virtuálisgép-konzolokhoz való csatlakozáshoz. Elérhetők webes felületek, mint a Kimchi és a Foreman, és olyan projektek, mint az oVirt és a Red Hat Virtualization, egy fejlett vizuális réteget adnak a KVM-hez.

A VMware vSphere esetében a felügyelet sarokköve a vCenter, a hozzá tartozó vSphere Client webes klienssel, amelyről az ESXi hosztok, klaszterek, virtuális hálózatok, adattárak, HA, DRS, vSAN, NSX és egyebek vezérelhetők. Ezenkívül rendelkezésre áll az ESXCLI a parancssorhoz, a PowerCLI (PowerShell alapú) szinte minden automatizálásához, valamint a Host Client felület a vCenter nélküli önálló ESXi hosztokhoz.

Költség, licencek és támogatási modell

Költség szempontjából a különbség egyértelmű: a KVM egy nyílt forráskódú szoftver, amely Linuxba integrálva van, és önmagában nem igényel hipervizor licenceket. Bármely modern Linux disztribúción elérhető, mióta 2007-ben integrálták a kernelbe. A költségek a kereskedelmi támogatásból (Red Hat, SUSE, Oracle stb.) és minden további hozzáadni kívánt felügyeleti eszközből származnak, de az alapvető funkciók ingyenesek.

A VMware vSphere egy kereskedelmi megoldás, amelyre jellemzően CPU/mag és kiadás (Standard, Enterprise Plus stb.) alapján licencelnek. Tartalmazza az ESXi és a vCenter licenceit, és ha olyan termékeket szeretne hozzáadni, mint az NSX, vSAN, Tanzu, Horizon vagy vRealize , mindegyikhez külön licenc szükséges. Létezik az ESXi (vSphere Hypervisor) ingyenes kiadása, de jelentős korlátozásokkal rendelkezik : írásvédett API-k, nincs vCenter felügyelet, nincs technikai támogatás, és nem lehet olyan biztonsági mentési megoldásokat használni, amelyek az API-kra támaszkodnak.

A támogatás tekintetében a VMware a szerződésnek megfelelően 24 órás vállalati támogatást kínál , hozzáféréssel a tudásbázishoz, frissítésekhez, javításokhoz és közvetlen segítségnyújtáshoz. A KVM esetében a „hivatalos” támogatás a disztribúciós szolgáltatótól (Red Hat, Oracle, SUSE stb.) vagy a saját informatikai csapatodtól függ, és mindig egy nagyon aktív közösség támogatását élvezheted, de nincs egyetlen KVM-szállító sem, akihez támogatási jegyet küldhetnél, hacsak nem szerződsz egy adott szállítóval.

Hardverkompatibilitási és skálázási korlátok

A hardverkompatibilitás egy másik megkülönböztető tényező. Mivel a KVM Linux alapú , örökli a kernel által támogatott hardverek kiterjedt listáját: x86-os CPU-k VT-x/AMD-V- vel , többféle lemezvezérlő, hálózati adapterek, architektúrák, mint az ARM vagy a PowerPC bizonyos változataiban, és így tovább. Amíg a kernelhez tartozik illesztőprogram, a KVM általában problémamentesen működik az adott gazdagépen.

A VMware ESXi megköveteli, hogy a szerver és az összetevők szerepeljenek a hardverkompatibilitási listáján (HCL) . Ez biztosítja a tanúsított illesztőprogramokat és az optimális teljesítményt, de korlátozza a használatát régebbi vagy nagyon új hardvereken, amelyek még nem estek át a tanúsítási folyamaton. Nagyobb projekteknél ez növelheti a platform költségét, mivel a VMware által ajánlott speciális hardvereket kell vásárolni.

A korlátokat tekintve a KVM-et csomagoló kereskedelmi disztribúciók indikatív adatokat adnak meg. Például bizonyos környezetek esetén akár 384 CPU-mag és 6 TB RAM támogatott hosztonként , körülbelül 600 egyidejű virtuális géppel, és akár 256 vCPU (vagy több az újabb verziókban) és több terabájt virtuális RAM is elérhető virtuális gépenként . Ez a disztribúciótól (Red Hat, Oracle Linux, SUSE) és az egyes gyártók által végzett validációs tesztektől függ.

A VMware vSphere esetében a hivatalos dokumentáció nagyon magas korlátokat határoz meg: akár 896 logikai CPU és 24 TB RAM ESXi hosztonként , 1024 virtuális gép hosztonként, 4096 összesített vCPU, 256 vCPU virtuális gépenként, több mint 6 TB RAM virtuális gépenként, akár 62 TB virtuális lemezek, valamint akár 64 hosztból és 8000 virtuális gépből álló fürtök . A vCenter szinten akár 2500 ESXi hoszt és 40 000 virtuális gép kezelhető példányonként, ami jelentős növekedési lehetőséget biztosít.

Biztonság: elkülönítés, titkosítás és megfelelőség

A hipervizor biztonsága kritikus fontosságú: ha valaki feltöri a gazdagépet, akkor nyitva áll az ajtó az összes virtuális géphez és azok adataihoz. A KVM a Linux biztonsági ökoszisztémát használja ki az izoláció megerősítésére. Legfontosabb jellemzője az SELinux (Biztonsággal Fokozott Linux) és az sVirt (Biztonságos Virtualizáció) együttes használata . Az SELinux kötelező hozzáférés-vezérlési (MAC) házirendeket határoz meg, és az sVirt kiterjeszti ezeket a házirendeket a virtuális gépekre, folyamatokat és lemezképeket címkézve, hogy elkülönítse őket egymástól.

Ezenkívül az iptables/nftables segítségével fejlett tűzfalat, UEFI biztonságos rendszerindítást biztosíthat vendéggépeken (bizonyos manuális konfigurációval), valamint memóriatitkosítási technológiákat, például TME/MKTME-t használhat kompatibilis hardvereken. Lemezszinten a KVM lehetővé teszi a QCOW2 képek 128 bites AES titkosítását a vendég számára átlátszóan, vagy a titkosítás delegálását a gazdagép fájlrendszerére vagy magára a vendég operációs rendszerre.

A VMware vSphere ezen a téren is kiemelkedő, szabályozott környezetekhez (HIPAA, PCI DSS stb.) tervezett funkciókészletével. Integrált tűzfalat kínál az ESXi-ben , támogatja a Secure Boot UEFI-t, integrációt biztosít a TPM-mel és a vSphere Trust Authority-val, részletesen kezeli az engedélyeket és szerepköröket, valamint virtuálisgép-titkosítást biztosít külső KMS-sel vagy a natív vSphere kulcsszolgáltatóval való integrációval.

A VMware virtuális gépei vTPM-et és virtualizáció-alapú biztonságot használhatnak , az NSX pedig elosztott oldalszintű biztonságot nyújt (mikroszegmentáció, elosztott tűzfal, IDS/IPS a kiadástól függően). Ezenkívül a VMware megfelelőség-figyelő és hipervizor-konfiguráció-végrehajtási eszközöket is kínál, így könnyebben összehangolható a platform a szigorú szabályozásokkal.

Virtuális hálózatok és kapcsolatok

Hálózati szinten a KVM a Linux kernel és specifikus eszközök képességeire támaszkodik. Virtuális switchekhez általában az Open vSwitch (OVS) az elterjedt , amely lehetővé teszi a nyilvános vagy privát virtuális hidakat, az elosztott kapcsolást a hosztok között, valamint támogatja a VLAN-okat, VXLAN-okat, QoS-t és más fejlett funkciókat. Klasszikus Linux hidak is létrehozhatók, és a bonding vagy teaming használható linkek hozzáadására vagy redundancia konfigurálására.

A Virtio hálózati interfészei támogatják a VLAN-okat, és a libvirt segítségével vezérelhetők , amely magában foglalja a virtuális hálózatkezelést és a QEMU-ba integrált DHCP-kiszolgálót. A tűzfal képességei ugyanolyan kiterjedtek, mint maga a Linux hálózati verem, és a VXLAN-ok, alagutak, VPN-ek és egyebek a szabványos ökoszisztéma-eszközökkel állíthatók be.

A VMware vSphere -ben a hálózat kétféle kapcsolón alapul: a standard vSwitch-en (hosztonként konfigurálva) és az elosztott vSwitch-en (központilag, a vCenterből felügyelve). Mindkettő támogatja a VLAN-okat, a terheléselosztáshoz és feladatátvételhez szükséges NIC-csoportosítást, valamint az alapvető biztonsági szabályzatokat. A fejlett szoftveresen definiált hálózatépítéshez (mikroszegmentáció, VXLAN, terheléselosztók, elosztott szabályzatok) a VMware NSX-et használják.

A linkaggregáció, portcsoportok, forgalmi irányelvek vagy hálózatok konfigurálása a vMotion és a tárolás számára általában felhasználóbarátabb a vSphere grafikus felhasználói felületén, mint mindezt CLI-n keresztül Linuxon, bár a KVM nagyobb szabadságot kínál az "egzotikus" forgatókönyvekhez, ha kényelmesen ismerjük az iproute2-t, az OVS-t és hasonlókat.

Tárolás, lemezformátumok és migráció

A KVM segítségével gyakorlatilag bármi használható, amit a Linux fizikai vagy logikai tárolóként képes csatlakoztatni: SAS, SATA, NVMe lemezek, LVM kötetek, NFS, iSCSI, SAN, NAS stb. A virtuális gépek használhatnak virtuális lemezképeket vagy Raw Device Mapping-et (eszköz- vagy kötetátadás). Az is lehetséges, hogy egy LVM kötetet közvetlenül csatolunk egy virtuális géphez.

A natív képformátumok a raw (img) és a qcow2 . A raw formátum nagyon egyszerű és gyors (körülbelül 10%-kal gyorsabb, mint a további rétegeket tartalmazó formátumok), de nem támogatja a belső pillanatképeket vagy a blokkszintű inkrementális biztonsági mentéseket. A Qcow2 ezzel szemben pillanatképeket, tömörítést, titkosítást, vékony kiépítést és TRIM/UNMAP támogatást kínál , lehetővé téve a fel nem használt tárhely visszanyerését olyan eszközökkel, mint a virt-sparsify. Továbbá a KVM más formátumokat is megért, például a VMDK-t (VMware-től), a VDI-t (VirtualBox), a VHDX-et (Hyper-V) és sok mást, megkönnyítve a platformok közötti migrációt.

A VMware ESXi- ben az alapértelmezett lemezformátum a VMDK . Minden lemez jellemzően egy .vmdk leíróból és egy egyszerű .vmdk fájlból áll, amely az adatokat tartalmazza. A vékony és a vastag kiépítés támogatott, az adattár pedig általában VMFS-en vagy NFS-en található. A lemezek kihasználhatják az automatikus leképezések megszüntetését a hely felszabadítása érdekében, és a Raw Device Mapping (RDM) segítségével a LUN-ok közvetlenül a virtuális gépekhez rendelhetők.

Virtuálisgép-migráció esetén a KVM élő migrációt kínál a hosztok között, amennyiben megosztják a tárhelyet, valamint bizonyos esetekben a tárhelymigrációt (virtuálisgép-fájlok áthelyezése egy másik hosztra), és tervek szerint kiterjesztik az élő tárhelymigrációt. A VMware évek óta kínálja a vMotion-t (élő virtuálisgép-migráció hosztok között) és a Storage vMotion-t (lemezek migrálása adattárak között a virtuális gép leállítása nélkül), mindkettő kifinomult és jól integrált a klaszterkezelésbe.

Klaszterezés, magas rendelkezésre állás és terheléselosztás

A klaszterezésben a KVM kínálja a komponenseket, de nem egy „zárt” terméket, amely összehasonlítható lenne a vSphere-rel. A magas rendelkezésre állás érdekében olyan eszközöket használnak klaszter erőforrás-kezelőként, mint a DRBD (blokkreplikáció a hálózaton keresztül), a Heartbeat és a Pacemaker. A csomópontok közötti feladatátvételi konfiguráció lehetséges , de jellemzően számos manuális műveletet és jelentős szakértelmet igényel.

Az automatizált terheléselosztás nem szabványos funkció; jellemzően olyan projektekre támaszkodik, mint az oVirt vagy a Red Hat Virtualization , amelyek egy fejlett felügyeleti réteget építenek a KVM-re, hogy automatikus migrációkat biztosítsanak a terhelés, a magas rendelkezésre állás (HA), a szabályzatok és egyéb tényezők alapján. Általánosságban elmondható, hogy egy jól hangolt KVM-klaszter beállítása HA-val nem egyszerű egy olyan kereskedelmi megoldás nélkül, amely tartalmazza.

Ezzel szemben a VMware vSphere pontosan a klaszterezési képességeivel tűnik ki. Az olyan funkciók, mint a vSphere HA lehetővé teszik a virtuális gépek automatikus újraindítását más hosztokon, ha egy csomópont meghibásodik, és a DRS (Distributed Resource Scheduler) a CPU- és RAM-fogyasztási szabályzatok alapján a vMotion segítségével a virtuális gépek hosztok közötti mozgatásával újraosztja a terhelést. Bizonyos virtuális gépek esetében hibatűrés is elérhető , amely valós idejű replikát tart fenn, és zökkenőmentes folytonosságot biztosít hoszthiba esetén.

Továbbá az elosztott energiagazdálkodás (Distributed Power Management) képes leállítani a gazdagépeket, amikor a terhelés alacsony, és újraindítani őket, amikor szükséges, így energiát takarít meg a kapacitás feláldozása nélkül. Ezeknek a mechanizmusoknak a konfigurálása meglehetősen egyszerű a vSphere kliensből, így a VMware a legkényelmesebb megoldás, ha összetett klaszterezésre van szükség anélkül, hogy a konzollal kellene bajlódni.

Vendégrendszer és konténer kompatibilitás

Mind a KVM, mind a VMware ESXi számos vendég operációs rendszert támogat: Windowst (a nagyon régi verzióktól, mint az NT vagy a 95, a jelenlegiekig), számos Linux disztribúciót (Ubuntu, Debian, RHEL, CentOS, Fedora, Oracle Linux, SUSE, Kali stb.), BSD származékokat (FreeBSD, OpenBSD), Solarist, OpenSolarist, NetWare-t, MS-DOS-t és bizonyos módosításokkal és korlátozásokkal még a macOS-t is.

A különbségek a konténervilággal való integrációban vannak . A KVM segítségével Docker vagy Kubernetes futtatható virtuális gépeken belül, mint bármely más hipervizorral, de vannak olyan speciális illesztőprogramok (docker-machine-driver-kvm) is , amelyek lehetővé teszik Docker gépek transzparens létrehozását a KVM tetején, javítva az izolációt és a teljesítményt a virtuális gépek manuális beállításához képest. Továbbá a KVM nagyon jól integrálódik az OpenStack- kel , ahol az A csoportba tartozik (maximális kompatibilitás), és gyakran az előnyben részesített hipervizor a Linux privát felhőkben.

A VMware a maga részéről először a vSphere Integrated Containers termékkel próbálkozott (konténereket futtatott könnyű virtuális gépekként Photon OS használatával), és jelentős előrelépést tett a VMware Tanzuval , amely közvetlenül az ESXi-be integrálja a Kubernetes-t és a konténereket. A Tanzu az ESXi hosztokat Kubernetes csomópontokká alakítja (Spherelet használatával), elérhetővé tesz egy vezérlési síkot a DevOps számára, a vCenterből kezelhető, és az NSX-T, valamint a megosztott tároló kihasználásával átfogó vállalati konténerkörnyezetet biztosít (bár további licencköltségekkel).

Röviden, ha erősen érintett vagy Linux-alapú natív felhőalapú ökoszisztémákban, a KVM + OpenStack/Kubernetes remek választás; ha már jelentős befektetéssel rendelkezel a VMware-ben, és a vSphere platformodba integrált konténereket keresel, minden hálózati és biztonsági extrával, a Tanzu egy hatékony választás.

Integráció más komponensekkel: AD, OpenStack és ökoszisztéma

A VMware vSphere natívan integrálódik a Microsoft Active Directory- val a hitelesítés és a szerepköralapú hozzáférés-vezérlés érdekében. A felhasználók bejelentkezhetnek a vSphere kliensbe a domainjük hitelesítő adataival, és részletes engedélyeket rendelhetnek az objektumokhoz (virtuális gépek, adattárak, klaszterek stb.). Továbbá a VMware csomag zökkenőmentesen integrálódik: NSX hálózatépítéshez, vSAN szoftveresen definiált tároláshoz, Horizon VDI-hez, vRealize automatizáláshoz és monitorozáshoz, és még sok máshoz.

A KVM világában az Active Directory integráció tökéletesen lehetséges a Linux gazdagép (vagy virtuális gépek) tartományhoz csatlakoztatásával, de a konfiguráció olyan eszközök használatát igényli, mint az sssd, a winbind vagy a realmd. Felhőalapú vezénylés esetén a KVM az OpenStack- kel remekel , ahol ez az előnyben részesített választás (A csoport), míg az ESXi a B csoportba tartozik: támogatott, de valamivel kevésbé prioritást élvez az OpenStack ökoszisztémában.

A gyártóhoz kötöttséget illetően a KVM, mivel nyílt forráskódú és nem rendelkezik gyártói kötöttséggel , gyakorlatilag bármilyen kereskedelmi vagy nyílt forráskódú szoftverrel integrálható, így a rendszer az igényeidhez igazítható. A VMware esetében a megoldást alapvetően a vezérlési sík és a termékek köré építed, ami nagyfokú konzisztenciát biztosít, de egyben a licencekhez és az ütemtervhez is köt.

Biztonsági mentés, replikáció és adatvédelem

A virtuális gépek biztonsági mentésének módja is jelentős különbségeket okoz. A KVM-ben az alapvető módszerek a virsh és a lemezes pillanatképek használatát foglalják magukban. Ha LVM-köteteket használnak a virtuális gépekhez, akkor LVM-pillanatképek hozhatók létre és menthetők ezekről a kötetekről, ami nagyon jó teljesítményt nyújt, de a migrációt és a tárhelykezelést bonyolultabbá teszi.

Nyers képfájlok esetén a biztonsági mentések csak kikapcsolt virtuális gép mellett lehetségesek, mivel nincs natív képfájl szintű pillanatkép-támogatás. A qcow2 segítségével pillanatképek hozhatók létre egy futó virtuális gépen (ehhez QEMU vendégügynök szükséges a vendég operációs rendszeren, valamint egy org.qemu.guest_agent.0 csatorna konfigurálása), és az adatok ezután konzisztens módon másolhatók. Léteznek olyan megoldások, amelyek a libvirt és az oVirt segítségével növekményes biztonsági mentéseket valósítanak meg a blokkváltozások alapján.

Replikációhoz a KVM a Linux kernel blokk szintjén használhatja a DRBD-t , szinkron módon replikálva a lemezeket a csomópontok között a nagy rendelkezésre állású klaszterek csatlakoztatásához, bár általában titkosítás nélkül, kivéve, ha a forgalom VPN-ekbe vagy hasonlókba van ágyazva.

A VMware vSphere -ben az adatvédelem robusztus a vStorage Data Protection API-knak köszönhetően . A biztonsági mentési szolgáltatók (Veeam, NAKIVO stb.) ezeket az API-kat használják a futó virtuális gépek konzisztens pillanatképeinek létrehozására, az alkalmazások nyugalmi állapotának felügyeletére a VMware Tools segítségével, valamint a módosított blokkok követésén (CBT) keresztül , amely lehetővé teszi a rendkívül hatékony inkrementális biztonsági mentéseket azáltal, hogy csak a módosított blokkokat másolja.

A VMware biztonsági mentési megoldásai jellemzően támogatják az azonnali virtuális gépek helyreállítását , az alkalmazásfájlok vagy objektumok (Exchange, SQL, AD stb.) részletes visszaállítását, valamint az ESXi gazdagépek vagy webhelyek közötti replikációt. Az ESXi ingyenes kiadása nem teszi elérhetővé ezeket az API-kat, így ebben az esetben szkriptekre és a kikapcsolt virtuális gépek manuális biztonsági mentésére lenne szükség, ami általában nem elfogadható éles környezetben.

Végső soron, ha a hipervizor szintű adatvédelem és a számos kereskedelmi biztonsági mentési megoldással való integráció kulcsfontosságú, a vSphere egy érettebb és homogénebb ökoszisztémát kínál. A KVM robusztus stratégiákat tesz lehetővé, de szélesebb körű megközelítésekkel és nagyobb támaszkodással a csapat szakértelmére és a kiválasztott eszközökre.

Mikor éri meg a KVM és mikor a VMware?

A KVM és a VMware közötti választás nem arról szól, hogy abszolút értelemben melyik „jobb”, hanem inkább arról, hogy a kontextushoz megfelelő eszközt válasszuk. A szűkös költségvetéssel , erős Linux kultúrával és a platform testreszabására irányuló vággyal rendelkező szervezetek számára a KVM nagyon vonzó: nem igényel hipervizor licenceket, széleskörű hardverkompatibilitást kínál, és kiterjedt hangolási lehetőségeket biztosít. Ideális induló vállalkozások, kis VPS-szolgáltatók, tesztlaboratóriumok, Linux-központú környezetek vagy OpenStack-alapú privát felhők számára.

A VMware ESXi és a vSphere olyan környezetekhez a legalkalmasabb, amelyek nagymértékben integrált megközelítést, erős kereskedelmi támogatást és nagy klaszterek egyszerűsített kezelését igénylik. Azok a vállalatok, amelyek már használnak VMware termékeket (Horizon, NSX, vSAN, Tanzu), szigorú rendelkezésre állási, megfelelőségi és 24/7-es támogatási követelményekkel, vagy amelyek egy kifinomult, központosított konzolt értékelnek, jellemzően inkább vSphere licencekbe fektetnek be, és virtualizációs stratégiájukat erre az ökoszisztémára építik.

Nagyon gyakorlati szempontból a KVM egy nagy teljesítményű, alacsony költségű megoldás , amely a Linux tapasztalattal rendelkező csapatokat jutalmazza, és toleranciát mutat a valamivel nagyobb komplexitás iránt. A VMware ezzel szemben egy „zártabb, de kényelmesebb” élményt kínál: fizetsz a licencekért és a karbantartásért, de cserébe egy rendkívül kiforrott virtualizációs platformot kapsz fejlett klaszterezéssel, finomhangolt biztonsági mentési eszközökkel és nagyon stabil integrációval a rendszer többi részével.