Amikor komolyan elkezdünk foglalkozni a modern virtualizációval, előbb-utóbb visszatérő problémába ütközünk: A virtuális gépek ritkán kínálnak ugyanolyan grafikus teljesítményt, mint a közvetlenül a hardverre telepített operációs rendszer.Míg a gazdagép asztala simán futhat még 4K felbontásban is, a virtuális gép asztala akadozhat, egérhibákkal, képernyőszakadással vagy a kelleténél nem olyan simán lejátszódó videókkal.
Ez a forgatókönyv megismétlődik mind otthoni környezetben, mind Vállalati platformok, amelyek KVM-et, Proxmoxot, VMware-t, Hyper-V-t vagy nyilvános felhőt használnak.És az érzés ugyanaz: "A gazdagép tökéletesen működik, de a virtuális gép lassú... mit csinálok rosszul? Szükségem van egy dedikált GPU-ra, SR-IOV-ra, hogy megváltoztassam a hipervizorokat, vagy egyszerűen csak több nyers CPU-teljesítményre?"
Grafikus teljesítmény virtuális gépekben: amire valójában számíthat
Az első lépés az elvárások korrigálása: Az asztali gépek virtualizálása „közel natív” 3D gyorsítással továbbra is kihívást jelentKülönösen akkor, ha egyetlen GPU-t szeretne megosztani egy gazdagép és több virtuális gép között anélkül, hogy nagyon drága vagy összetett megoldásokhoz folyamodna.
Egy tipikus esetben, amikor Debian 12 KVM feletti hosztként, Ryzen 7 PRO laptop Radeon iGPU-val és 4K kijelzővelA fizikai asztal tökéletesen működik: az ablakok áthelyezése azonnal megtörténik, a weboldalak gyorsan betöltődnek, és a 4K YouTube simán lejátszható. A Linux virtuális gépeken, amelyeken virtio vagy SPICE grafikus kártya van, azonban a teljesítmény visszaesik: A nehéz weboldalak és online videók nagyobb akadozást tapasztalnak, és a simaságuk sem olyan jó, mint a tárhelyszolgáltatóé..
Különböző konfigurációk tesztelésekor (VirtIO-GPU illesztőprogram, SPICE, virgl, különböző távoli megjelenítők, például a virt-viewer, Windows kliensek stb.) megfigyelhető, hogy A mutató és az általános válaszidő némileg javult, de a képszakadás, a képkockakimaradás és a kevésbé "élénk" asztali gép határozott érzete továbbra is jelen van.Ez sok embert arra késztet, hogy azonnal fontolóra vegye a GPU-átvitelt. Vagy akár a platformváltást.
Fontos megérteni, hogy még a nagy teljesítményű infrastruktúrákban is A virtualizáció kismértékű többletterhelést jelent a CPU, a RAM, és különösen a lemez I/O és a grafika számára.Hagyományos szerverterhelések esetén (web, adatbázisok, mikroszolgáltatások) ez a büntetés elfogadható; de amikor elkezded kérdezni Kiváló grafikai interaktivitás, alacsony késleltetés és gördülékeny videóminden milliszekundum számít.
Virtuális gépek kontra fizikai szerverek: valós hatás a teljesítményre
Bár itt a grafikára koncentrálunk, érdemes a virtualizációt kontextusba helyezni. A fizikai (csupasz fém) szerverek továbbra is az etalon, ha nyers teljesítményt és minimális késleltetést keresünk.Különösen nagy teljesítményű adatbázisokban, 3D renderelésében, mesterséges intelligenciában vagy valós idejű streamingben.
A tipikus benchmark tesztek azt mutatják, hogy egy jól konfigurált KVM-en vagy VMware-en futó virtuális gép CPU és RAM tekintetében nagyon közel teljesít a csupasz fémhez: hozzávetőlegesen 5-8%-os CPU- és 7-13%-os memóriaveszteségA legnagyobb hiányosság a tárhely terén mutatkozik. A 4K IOPS akár 17-25%-kal is csökkenhet, ami kritikus fontosságú, ha a munkaterhelés nagyon lemezigényes.
Ez a büntetés a grafikai tervezésben is létezik, azzal az árnyalattal, hogy A GPU jellemzően több virtuális géppel osztja meg az erőforrásokat, és a megjelenítési útvonal (SPICE, VNC, RDP, a hipervizor saját protokollja stb.) késleltetést és tömörítést biztosít.Az eredmény: a rendszer "nem használhatatlan", de a gazdagéphez képest kevésbé zökkenőmentesnek érződik.
Ezért vannak olyan helyzetek, amikor megéri a csupasz fémnél maradni: nagy tranzakciós adatbázisok (Oracle, SQL Server Enterprise, SAP HANA), nagy teljesítményű GPU-kkal rendelkező AI/ML motorok, vagy játék-/streaming szerverek nagyon szigorú késleltetési követelményekkel. Ilyen helyzetekben a virtualizációs réteg CPU-, memória-, I/O- és GPU-terhelése sokkal észrevehetőbbé válik.
Ehelyett, webes alkalmazások, mikroszolgáltatások, fejlesztői környezetek és virtuális irodai asztali gépek – akár egy könnyű asztali gép Ubuntuban— Nagyon jól illeszkednek virtuális gépekbe. Előnyük a pillanatképek, a magas rendelkezésre állás és a gyors skálázhatóság, és a kismértékű teljesítményveszteség tökéletesen elfogadható.
CPU, RAM, lemez és hálózat: milyen mutatókat kell figyelembe venni egy lassú virtuális gépen
Mielőtt a GPU-t hibáztatnánk, meg kell erősítenünk, hogy Nem korlátoz a CPU, a memória, a lemez vagy a hálózatSok „lassú asztali” probléma valójában egy másik erőforrás telítettségéből adódik: a CPU a sorára vár, intenzív swap-elés történik, vagy a lemez a határán van.
A VMware vSphere-ben például minden vCPU CPU-ja négy állapoton megy keresztül: RUN (működik), WAIT (várakozás/I/O vagy tétlen), READY (sorban áll fizikai CPU nélkül) és COSTOP (együttes leállítás többmagos virtuális gépekben)A magas READY vagy COSTOP értékek egyértelműen jelzik a versenyhelyzetet és azt, hogy a gazdagép túl van fizetve.
A CPU-k esetében a legfontosabb mutatók a következők: tartós használat százalékos aránya, MHz-használat vCPU-nként és Ready/COSTOP számlálókHa egy virtuális gép folyamatosan 90-100%-os kihasználtságon van, vagy az idő több mint 10%-ában KÉSZ állapotban van, akkor az a gép küzd. Több vCPU hozzáadása akaratlanul is szinte soha nem segít, ha a gazdagép már amúgy is terhelés alatt van.
Emlékezetünkben vigyáznunk kell a A globális használat magában foglalja a lapozást/cserét, valamint olyan platformokon, mint az Azure vagy a Hyper-V, a másodlagos lemezeken lévő fájlok lapozását vagy cseréjét.Amikor ezek a kötetek sok olvasást/írást mutatnak, az egyértelmű jele annak, hogy a virtuális gépnek elfogyott a RAM-ja.
A lemezen és a hálózaton a következők figyelhetők meg: átlagos olvasási/írási késleltetés, IOPS és hálózati sávszélességA lemezen tartósan 15-20 ms feletti késleltetések, illetve a távoli tárolókban (Azure Storage, SAN stb.) az elérhetőség csökkenése és az időtúllépések közvetlen ellenségei a távoli asztalon érzékelt teljesítménynek.
Monitoring és diagnosztikai eszközök: az ESXTOP-tól az Azure Monitorig
A nagyobb gyártók jól fejlett eszközöket kínálnak a virtuális gépek teljesítményének elemzésére. Néhány példa:
- VMware: vCenter és ESXTOP.
- Azure: Azure Monitor és PerfInsights.
- Hyper-V: Teljesítményfigyelő és PowerShell.
- KVM/Proxmox: olyan kombinációk, mint a top, htop, iostat, virt-top és maga a webes felület.
Az ESXTOP egy klasszikus a valós idejű elemzésekhez. Lehetővé teszi a vCPU-nkénti metrikák néhány másodpercenkénti megtekintését, például %HASZNÁLT, %FUTÁS, %SYS, %VÁRAKOZÁS, %ÜRETMENTES, %RDY, %CSTP, %MLMTD és még sok más. Az alapszabály: ha a %RDY vagy a %CSTP megemelkedik, akkor túl sok vCPU vagy túl sok virtuális gép van a gazdagéphez.
Az Azure-ban a diagnosztika virtuális gép- és tárfiókszintű engedélyezése diagramokat jelenít meg a következőkről: CPU, memória, lemez és hálózatvalamint a rendelkezésre állásra, a késleltetésre, a szabályozásra és a tárolási időtúllépési hibákra vonatkozó mérőszámokat. Ez az információ segít megkülönböztetni a platformproblémákat a túlzott IOPS vagy átviteli sebesség miatti szűk keresztmetszettől.
A Hyper-V-ben a munka megoszlik a következők között: Hyper-V Manager, Teljesítményfigyelő, Erőforrás-figyelő és PowerShell-parancsmagokMegvizsgálhatja a fizikai és logikai magokat, a NUMA, VHDX lemezeket, a virtuális adaptereket, a lemezsorokat és sok mást, hogy finomhangolja, melyik rész nem megfelelő.
A gyártón túl számos útmutató a futást javasolja specifikus stressztesztek: sysbench CPU-hoz, stress-ng és memtester RAM-hoz, fio lemez I/O-hoz, iperf3 vagy netperf hálózathoz. Ez lehetővé teszi a bare metal és a virtuális gépek egyszerű összehasonlítását, és az egyes hipervizorok korlátainak megtekintését.
GPU virtualizáció: SR-IOV, áteresztés és saját fejlesztésű megoldások
Amikor a szűk keresztmetszet egyértelműen grafikai jellegű (képernyőszakadás, alacsony képkockasebesség, lassú animációk, akadozó videó), itt az ideje megvizsgálni a... GPU-virtualizációHárom fő megoldáscsalád létezik itt:
- GPU áteresztés (PCI áteresztés)Egyetlen virtuális géphez egy teljes grafikus kártya van hozzárendelve. Ez közel natív teljesítményt kínál, de nyilvánvaló korlátokkal: a GPU elérhetetlenné válik a gazdagép és a többi virtuális gép számára, és általában dedikált videokimenetre van szükség az adott virtuális géphez, ami nem ideális, ha mindent ugyanazon a képernyőn szeretnél látni.
- GPU virtualizáció SR-IOV-val (Single Root I/O Virtualization)Lehetővé teszi a virtuális GPU-funkciók (VF-ek) különböző virtuális gépekhez való hozzáférését. Az ötlet nagyon vonzó: grafikus hardver megosztása minimális terheléssel. Az Intel ezt a megközelítést a laptopokhoz (például a Lunar Lake) készült Xe2 iGPU-iban és az adatközponti GPU-kban (Flex) népszerűsíti, míg az AMD és az NVIDIA ezt a funkciót elsősorban a következők számára tartja fenn: nagyon drága névjegykártyák ahol ráadásul gyakran vannak olyan licencelési és előfizetési modellek, amelyek nem túl felhasználóbarátak otthoni felhasználók vagy kisvállalkozások számára.
- SR-IOVEz a megoldás Nem teljesen transzparens a virtuális gépek számára, speciális illesztőprogramokat, BIOS/firmware-t és hipervizor-támogatást igényel, és saját kompatibilitási problémákat is okozhat.Nem mindig éri meg az összes hardvert frissíteni (például egy Intel Lunar Lake laptopot venni csak ezért), ha a munkafolyamat többi részét továbbra is más tényezők korlátozzák. Egy jó PC hardver elemzés segít dönteni.
- Saját fejlesztésű GPU-virtualizációs megoldásokIlyen például az NVIDIA RTX vWS, az NVIDIA VGX vagy utódaik. Ezek speciális hardvereket (például VGX K1/K2 típusú kártyákat több Kepler GPU-val, nagy mennyiségű GDDR5 memóriával és több ezer CUDA maggal) kombinálnak egy GPU hipervizorral, amely lehetővé teszi a grafikus számítási kapacitás multiplexálását több tucat virtuális asztalon.
Részleges GPU technológiák asztali környezetekben: virtio-gpu, virgl és SPICE
KVM, QEMU, Proxmox vagy hasonló felhasználók számára a szokásos elérési út a következő: Paravirtualizált grafikus vezérlők, mint például a virtio-gpu, távoli asztali protokollokkal, például a SPICE-szal kombinálvaA vendég oldalon egy olyan illesztőprogram van telepítve, amely "megérti" az adott virtuális eszközt, és lehetővé tesz egy bizonyos szintű alapvető 2D/3D gyorsítást.
A VirGL egy további réteg, amely lefordítja az OpenGL hívásokat a vendéggépről a gazdagépreÍgy egy virtuális gépen belüli alkalmazás közvetve használja a valódi 3D gyorsítást. Elméletileg ennek javítania kellene az asztali környezet és az alkalmazások grafikus teljesítményét. A gyakorlatban azonban néha az ellenkezője történik. Ha a gazdagép iGPU-ja gyenge, vagy a megvalósítás nincs kidolgozva, jelentős teljesítménycsökkenés észlelhető.
Valójában sok AMD iGPU-val rendelkező felhasználó (például Renoir) arról számolt be, hogy amikor aktiválják a VirGL-t, a A virtuális gép asztali gépe sokkal lassabb és nehezebb lesz.odáig fajulva, hogy rosszabb, mint a Virtio-GPU használata "GPU nélkül". Ez nem jelenti azt, hogy a VirGL haszontalan, de nagymértékben függ a kombinációtól. hardver + illesztőprogramok + virtuális gép grafikai betöltése.
A Proxmoxnál a trió virtio-gpu + SPICE + virt-viewer Ez általában a grafikus Linux asztali környezet minimálisan elfogadható konfigurációja. Lehetővé teszi a tisztességes egérmutató használatát, az ablak átméretezését és a képtömörítés jobb működését, mint az egyszerű VNC, de mégis... Ne várjon ugyanazt az élményt, mint a VMware ESXi távoli konzol vagy a VMRC esetében., amelyeket évekig tartó optimalizálás után rendkívül kifinomulttá tettek.
Ezért sok ESXi-ről érkező rendszergazda meglepődik, amikor kipróbálja a Proxmoxot. Annak ellenére, hogy nagyon erős hipervizorral rendelkezik, A távoli asztal „harapósságának” érzete alacsonyabb hacsak nem finomhangolsz sokat, vagy dedikált GPU-t használsz.
Mikor éri meg a GPU-átvitel, és mikor nem?
A GPU-áteresztés továbbra is a legjobban teljesítő opció egy adott virtuális gép esetében. A mindennapi asztali használat során azonban számos hátránya van. Például, másik monitor bemenet szükségessége, a gazdagép GPU-jának elvesztése, további bonyodalmak (IOMMU, csoportok, BIOS, illesztőprogramok, felfüggesztéssel kapcsolatos hibák stb.).
Ha a célod az, hogy egyetlen virtuális gép teljes 3D gyorsítással rendelkezikAz erőfeszítés általában megéri. Az olyan projektek, mint a Looking Glass, lehetővé teszik a virtuális gép képének „újrabefecskendezését” a gazdagépbe, így elkerülhető a további monitorok használata. De ha azt szeretnéd, hogy… több irodai vagy tesztelési virtuális gép jó alaptudássalGPU átvitele mindegyikre nem megvalósítható.
Nagy teljesítményű asztali számítógépek esetén érdemes lehet hibrid kombinációt is megfontolni: Elsődleges GPU a gazdagéphez és áteresztőképesség egy második, szerényebb GPU-ról egy adott virtuális géphezÍgy egy nagyon jól használható gazdaasztalt tarthatsz fenn, és a virtuális gépednek egy a natívhoz nagyon közel álló grafikus környezetet biztosíthatsz; a laptop elemzés Perspektívát nyújthat az asztali számítógépek és a laptopok alternatíváinak összehasonlítására.
A laptopokkal a dolgok bonyolultabbá válnak. Általában van bennük egyetlen iGPU (vagy iGPU + dGPU, amely nagymértékben integrálva van a firmware-rel)Korlátozott erőforrások és egy másik grafikus kártya telepítésének reális lehetőségének hiányában az átvitel ritkán éri meg. Ésszerűbb a paravirtualizált lehetőségek (virtio-gpu, SPICE, RDP) kihasználása a virtuális gépek grafikai elvárásainak csökkentése érdekében.
Röviden: A Passthrough a megfelelő eszköz néhány nagyon igényes virtuális gép számára.Sok géppel vagy könnyű asztali számítógépekkel rendelkező laborok esetén jobban érdekli a hipervizor beállítása, a CPU/RAM/I/O terhelés szabályozása és a megfelelő távoli asztali protokoll kiválasztása.
Hipervizorok, NUMA, dinamikus memória és egyéb teljesítménytényezők
A GPU-n túl a hipervizor kezelése is CPU, memória, tárhely és hálózat Közvetlenül befolyásolja a virtuális gép asztalának érzékelt folyékonyságát. A Hyper-V, a KVM, a VMware és mások némileg eltérő filozófiával rendelkeznek, de mindegyikben közös koncepciók vannak.
A Hyper-V architektúra például egy olyan rendszeren alapul, hipervizor, amely a hardverhez való hozzáférést szabályozza, egy root partíció a felügyeleti rendszerrel, valamint a virtuális gépek másodlagos partícióiEzt olyan technológiák támogatják, mint a virtuális NUMA, a dinamikus memória, a virtuális kapcsolók, a hálózati SR-IOV, valamint a tárolási optimalizálások, mint például az ODX.
A NUMA (Non-Uniform Memory Access) különösen fontos a sokmagos szervereknél. Ha egy nagyméretű virtuális gép rosszul van particionálva a fizikai NUMA csomópontok között, a memória-késleltetése megnő. És a teljesítmény romlik, még akkor is, ha papíron úgy tűnik, hogy bőséges erőforrásokkal rendelkezik. Ideális esetben a virtuális gép vNUMA topológiájának összhangban kell lennie a gazdagép pNUMA topológiájával.
A dinamikus memória (Hyper-V-ben, más hipervizorokban felfuttatható) globális RAM-ot takaríthat meg, de Nem megfelelő a késleltetésre érzékeny munkaterhelésekhez, például adatbázisokhoz vagy sok megnyitott alkalmazást tartalmazó asztali számítógépekhez.Ilyen esetekben célszerű fix memóriát lefoglalni, hogy elkerüljük a szüneteket, amikor a hipervizor úgy dönt, hogy egyszerre visszanyerje a RAM-ot.
A tárolás messze a leggyakoribb szűk keresztmetszet. Ajánlott Használjon fix méretű VHDX lemezeket, külön rendszer- és adatlemezeket, válasszon vállalati szintű SSD-ket vagy NVMe meghajtókat, és kerülje a gyenge írási viselkedésű RAID-konfigurációkat (RAID 5/6) intenzív munkaterhelések esetén.Ahol elérhetők, a Storage Spaces Direct vagy az NVMe tömbök segítenek a késleltetések elfogadható határokon belül tartásában.
Hálózaton célszerű konfigurálni Külső virtuális switchek gyors hálózati kártyákon (lehetőleg 10 GbE), hálózati kártya összevonása (teaming), SR-IOV engedélyezése nagyon nagy hálózati terhelés esetén, valamint MTU és terheléselosztás finomhangolása Csak akkor, ha a teljes hálózati lánc támogatja. A rossz hálózati konfiguráció miatt egy távoli asztal, még egy jó GPU-val is, rosszabbul nézhet ki a vártnál.
Stressztesztelés és használati esetek: mikor válasszunk virtuális vagy fizikai gépet
Annak eldöntéséhez, hogy egy grafikus munkaterhelést virtuális gépre migrálunk, vagy fizikai adathordozón hagyunk, fontos Tesztelés benchmarkokkal és stresszeszközökkel Mérniük kell a CPU, RAM, lemez- és hálózathasználatot. És ha lehetséges, a GPU-használatot is. Ideális esetben a „valódi” alkalmazást egy virtuális gépen futó ugyanazon alkalmazással kell összehasonlítani.
Egy reális minta lehet a következő: Futtasd a sysbench vagy a Geekbench programot a CPU, a stress-ng vagy a memtester programot a RAM, a fio programot a 4K IOPS és a lemez késleltetésének, az iperf3 programot pedig a hálózati sávszélesség ellenőrzésére., valamint néhány alapvető grafikus benchmark (pl. glxgears vagy böngészőalapú WebGL teszt) mind a gazdagépen, mind a virtuális gépen.
Ha a teljesítménycsökkenés az elfogadható határokon belül van (pl. Kevesebb, mint 10% CPU/RAM terhelés és 15-20% lemezhasználati veszteségHa a távoli asztal elég simán működik a kívánt célra (irodai automatizálás, adminisztráció, könnyű fejlesztés), a virtualizáció tökéletesen alkalmas megoldás.
Ha viszont az alkalmazás nagymértékben támaszkodik GPU, alacsony késleltetés és magas tartós I/O áteresztőképesség (Blenderben renderelés, nehéz CAD, nagy modelleket betanító AI-motorok, játékok stb.) esetén az élmény általában sokkal jobb egy dedikált GPU-val rendelkező fizikai szerveren vagy egy professzionális szintű GPU-áteresztéssel/virtualizált virtuális gépen.
A kulcs annak észlelése, hogy melyik komponens (üzemkész CPU, elégtelen RAM, korlátozott I/O, valódi GPU hiánya, lassú hálózat vagy rosszul optimalizált asztali protokoll) lassítja az egyes virtuális gépeket. az adott esetben a lehető legegyszerűbb és legköltséghatékonyabb megoldást alkalmazzaés a nagy beruházásokat (dedikált GPU-k, SR-IOV, professzionális hardver) azokra a munkaterhelésekre kell fenntartani, ahol valóban számítanak.