Sākot nopietni eksperimentēt ar mūsdienu virtualizāciju, agrāk vai vēlāk rodas atkārtota problēma: Virtuālās mašīnas reti piedāvā tādu pašu grafikas veiktspēju kā operētājsistēma, kas instalēta tieši aparatūrā.Lai gan resursdatora darbvirsma var darboties nevainojami pat 4K izšķirtspējā, virtuālās mašīnas darbvirsma var darboties saraustīti, ar peles aizturi, ekrāna plīsumiem vai video, kas netiek atskaņoti tik vienmērīgi, kā vajadzētu.
Šis scenārijs atkārtojas gan sadzīves vidē, gan Uzņēmumu platformas, kas izmanto KVM, Proxmox, VMware, Hyper-V vai publisko mākoni.Un sajūta ir tāda pati: "Resursdators darbojas perfekti, bet virtuālā mašīna ir lēna... ko es daru nepareizi? Vai man ir nepieciešama īpaša grafikas procesora (GPU) karte, SR-IOV, lai mainītu hipervizorus, vai vienkārši lielāka procesora jauda?"
Grafikas veiktspēja virtuālajās mašīnās: ko jūs patiesībā varat sagaidīt
Pirmais solis ir pielāgot cerības: Darbvirsmu virtualizācija ar "gandrīz vietējo" 3D paātrinājumu joprojām ir izaicinājumsIt īpaši, ja vēlaties koplietot vienu GPU starp resursdatoru un vairākām virtuālajām mašīnām, neizmantojot ļoti dārgus vai sarežģītus risinājumus.
Tipiskā gadījumā ar Debian 12 kā resursdators KVM vidē, Ryzen 7 PRO klēpjdators ar Radeon iGPU un 4K displejuFiziskā darbvirsma darbojas perfekti: logu pārvietošana notiek acumirklī, tīmekļa vietnes ielādējas ātri un 4K YouTube tiek atskaņots nevainojami. Tomēr Linux virtuālajās mašīnās ar Virtio vai SPICE grafiku veiktspēja samazinās: Apjomīgām tīmekļa lapām un tiešsaistes videoklipiem ir lielāka aizture, un vienmērīgums nav tik labs kā resursdatoram..
Testējot dažādas konfigurācijas (VirtIO-GPU draiveri, SPICE, virgl, dažādus attālinātos skatītājus, piemēram, virt-viewer, Windows klientus utt.), tiek novērots, ka Rādītājs un kopējā atsaucība ir nedaudz uzlabojusies, taču joprojām ir redzama attēla plīsumi, kadru kritumi un izteikta mazāk "dzīva" darbvirsmas sajūta.Tas daudziem cilvēkiem liek nekavējoties apsvērt GPU caurlaidi. Vai pat platformu maiņu.
Ir svarīgi saprast, ka pat jaudīgās infrastruktūrās Virtualizācija rada nelielu pieskaitāmo slodzi centrālajam procesoram, operatīvajai atmiņas ierīcei un jo īpaši diska ieejai/izejai un grafikai.Tradicionālās serveru slodzēs (tīmeklī, datubāzēs, mikropakalpojumos) šis sods ir pieņemams; bet, kad sākat jautāt Izsmalcināta grafiskā interaktivitāte, zema latentuma pakāpe un vienmērīgs videokatra milisekunde ir svarīga.
Virtuālās mašīnas salīdzinājumā ar fiziskajiem serveriem: reāla ietekme uz veiktspēju
Lai gan mēs šeit koncentrējamies uz grafiku, ir vērts aplūkot virtualizāciju kontekstā. Fiziskie (bezvadu) serveri joprojām ir etalons, ja meklējat neapstrādātu veiktspēju un minimālu latentumu.Īpaši augstas veiktspējas datubāzēs, 3D renderēšanā, mākslīgajā intelektā vai reāllaika straumēšanā.
Tipiski salīdzinošie testi rāda, ka labi konfigurēta virtuālā mašīna ar KVM vai VMware darbojas ļoti tuvu tīrai metāla procesora un RAM veiktspējai: aptuveni 5–8 % procesora zudumi un 7–13 % atmiņas zudumiLielākā nepilnība ir krātuvē. 4K IOPS var samazināties par 17–25 %, kas ir kritiski svarīgi, ja jūsu darba slodze ir ļoti ietilpīga diskā.
Šis sods pastāv arī grafiskajā dizainā ar niansi, ka GPU parasti koplieto resursus ar vairākām virtuālajām mašīnām (VM), un prezentācijas ceļš (SPICE, VNC, RDP, hipervizora paša protokols utt.) palielina latentumu un saspiešanu.Rezultāts: sistēma "nav nelietojama", bet, salīdzinot ar resursdatoru, tā šķiet mazāk vienmērīga.
Tāpēc ir situācijas, kad atmaksājas pieturēties pie tīra metāla: lielas transakciju datubāzes (Oracle, SQL Server Enterprise, SAP HANA), AI/ML dzinēji ar ietilpīgiem grafiskajiem procesoriem vai spēļu/straumēšanas serveri ar ļoti stingrām latentuma prasībām. Šādās situācijās virtualizācijas slāņa centrālā procesora, atmiņas, ievades/izvades un grafiskā procesora pieslodze kļūst daudz ievērojamāka.
Vietā, tīmekļa lietojumprogrammas, mikropakalpojumi, izstrādes vides un virtuālie biroja galddatori — pat a viegls darbvirsmas dizains Ubuntu vidē— Tie ļoti labi iederas virtuālajās mašīnās (VM). To priekšrocības ir momentuzņēmumi, augsta pieejamība un ātra mērogošana, un nelielais veiktspējas zudums ir pilnīgi pieņemams.
CPU, RAM, disks un tīkls: kādus rādītājus aplūkot lēnā virtuālajā mašīnā
Pirms vainot GPU, mums tas ir jāapstiprina Jūs neierobežo procesors, atmiņa, disks vai tīklsDaudzas "lēna darbvirsmas" problēmas patiesībā ir cita resursa piesātinājums: centrālais procesors gaida savu kārtu, intensīva mijmaiņas darbība vai disks ir sasniedzis savu maksimālo jaudu.
Piemēram, VMware vSphere vidē katra vCPU centrālais procesors (CPU) iziet cauri četriem stāvokļiem: RUN (darbojas), WAIT (gaida/I/O vai dīkstāvē), READY (rindā bez fiziskā centrālā procesora) un COSTOP (kopīga apstāšanās daudzkodolu virtuālajās mašīnās)Augstas READY vai COSTOP vērtības ir skaidras norādes par konkurētspēju un to, ka resursdatoram ir pārāk daudz abonementu.
CPU galvenie rādītāji ir ilgstošas lietošanas procentuālā daļa, MHz izmantošana uz vienu vCPU un gatavības/COSTOP skaitītājiJa virtuālā mašīna pastāvīgi ir noslogota ar 90–100 % vai ir GATAVA vairāk nekā 10 % laika, šī mašīna cīnās. Vairāku virtuālo centrālo procesoru (vCPU) pievienošana gandrīz nekad nepalīdz, ja resursdators jau ir noslogots.
Atmiņā mums jāuzmana Globālā lietošana ietver lapošanu/apmaiņu un tādās platformās kā Azure vai Hyper-V lapošanu vai apmaiņu uz sekundārajiem diskiem.Ja šajos sējumos ir daudz lasīšanas/rakstīšanas reižu, tā ir skaidra zīme, ka virtuālajai mašīnai ir beigusies RAM.
Diskā un tīklā tiek novērots sekojošais: vidējā lasīšanas/rakstīšanas latentuma vērtība, IOPS un tīkla joslas platumsIlgstoša latentuma vērtība virs 15–20 ms diskā vai pieejamības kritumi un taimauti attālajā krātuvē (Azure Storage, SAN utt.) ir tiešie attālā darbvirsmas uztvertās veiktspējas ienaidnieki.
Uzraudzības un diagnostikas rīki: no ESXTOP līdz Azure Monitor
Lielākie ražotāji piedāvā labi izstrādātus rīkus virtuālās mašīnas veiktspējas analīzei. Daži piemēri:
- VMware: vCenter un ESXTOP.
- Azure: Azure Monitor un PerfInsights.
- Hyper-V: veiktspējas monitors un PowerShell.
- KVM/Proxmox: tādas kombinācijas kā top, htop, iostat, virt-top un pati tīmekļa saskarne.
ESXTOP ir klasisks rīks reāllaika analīzei. Tas ļauj ik pēc dažām sekundēm skatīt metriku katram vCPU, piemēram, %IZMANTOTS, %PALAIDĪT, %SYS, %GAIDĪT, %DZĪVOKLIS, %RDY, %CSTP, %MLMTD un vēl daudz ko citu. Pamatnoteikums: ja %RDY vai %CSTP strauji pieaug, jums ir pārāk daudz vCPU vai pārāk daudz VM resursdatoram.
Pakalpojumā Azure, iespējojot diagnostiku VM un krātuves konta līmenī, tiek parādītas diagrammas par CPU, atmiņa, disks un tīklskā arī pieejamības, latentuma, ierobežošanas un krātuves taimauta kļūdu rādītāji. Šī informācija palīdz atšķirt platformas problēmu no jūsu puses sastrēguma, ko rada pārmērīga IOPS vai caurlaidspēja.
Hyper-V vidē darbs ir sadalīts starp Hyper-V pārvaldnieks, veiktspējas monitors, resursu monitors un PowerShell cmdletVarat pārbaudīt fiziskos un loģiskos kodolus, NUMA, VHDX diskus, virtuālos adapterus, disku rindas un daudz ko citu, lai precīzi noteiktu, kura daļa nedarbojas.
Papildus ražotājam daudzi ceļveži iesaka darboties specifiski stresa testisysbench procesoram, stress-ng un memtester operatīvajai atmiņai, fio diska ieejai/izejai, iperf3 vai netperf tīklam. Tas ļauj viegli salīdzināt tukšu metālu un virtuālo mašīnu un redzēt katra hipervizora ierobežojumus.
GPU virtualizācija: SR-IOV, caurlaide un patentēti risinājumi
Kad vājā vieta ir skaidri redzama grafiski (ekrāna plīsumi, zems kadru ātrums, lēnas animācijas, saraustīts video), ir pienācis laiks aplūkot GPU virtualizācijaŠeit ir trīs galvenās risinājumu saimes:
- GPU caurlaide (PCI caurlaide)Pilna grafikas karte tiek piešķirta vienai virtuālajai mašīnai. Tas piedāvā gandrīz dabisku veiktspēju, taču ar acīmredzamiem ierobežojumiem: šī grafikas karte kļūst nepieejama resursdatoram un citām virtuālajām mašīnām, un parasti šai virtuālajai mašīnai ir nepieciešama atsevišķa video izeja, kas nav ideāli, ja vēlaties visu redzēt vienā ekrānā.
- GPU virtualizācija ar SR-IOV (vienas saknes I/O virtualizācija)Tas ļauj virtuālās GPU funkcijas (VF) pakļaut dažādām VM. Ideja ir ļoti pievilcīga: grafikas aparatūras koplietošana ar minimālām papildu izmaksām. Intel reklamē šo pieeju savos Xe2 iGPU klēpjdatoriem (piemēram, Lunar Lake) un datu centru GPU (Flex), savukārt AMD un NVIDIA šo funkciju galvenokārt rezervē... ļoti dārgas vizītkartes kur turklāt bieži vien pastāv licencēšanas un abonēšanas modeļi, kas nav īpaši ērti lietojami mājas lietotājiem vai mazajiem uzņēmumiem.
- SR-IOVŠis risinājums Tas nav pilnībā caurspīdīgs virtuālajām mašīnām, tam ir nepieciešami īpaši draiveri, BIOS/programmatūras un hipervizora atbalsts, un tas var radīt savas saderības problēmas.Ne vienmēr ir vērts jaunināt visu aparatūru (piemēram, iegādāties Intel Lunar Lake klēpjdatoru tikai šī iemesla dēļ), ja pārējo darbplūsmu joprojām ierobežos citi faktori. Labs Datora aparatūras analīze palīdz izlemt.
- Patentēti GPU virtualizācijas risinājumiPiemēram, NVIDIA RTX vWS, NVIDIA VGX vai to pēcteči. Tie apvieno specifisku aparatūru (piemēram, VGX K1/K2 tipa kartes ar vairākiem Kepler GPU, lielu GDDR5 atmiņas apjomu un tūkstošiem CUDA kodolu) ar GPU hipervizoru, kas ļauj multipleksēt grafikas skaitļošanas jaudu desmitiem virtuālo darbvirsmu.
Daļējas GPU tehnoloģijas darbvirsmas vidēs: virtio-gpu, virgl un SPICE
Tiem, kas izmanto KVM, QEMU, Proxmox vai līdzīgus rīkus, parasti ir nepieciešams šāds ceļš: Paravirtualizēti grafikas kontrolleri, piemēram, virtio-gpu, apvienojumā ar attālās darbvirsmas protokoliem, piemēram, SPICEViesu pusē tiek instalēts draiveris, kas "saprot" šo virtuālo ierīci un nodrošina noteiktu pamata 2D/3D paātrinājuma līmeni.
VirGL ir papildu slānis, kas tulko OpenGL izsaukumus no viesa uz resursdatora GPUTādējādi lietojumprogramma virtuālajā mašīnā netieši izmanto reālo 3D paātrinājumu. Teorētiski tam vajadzētu uzlabot darbvirsmas un lietotņu grafikas veiktspēju. Tomēr praksē dažreiz notiek pretējais. Ja resursdatora iGPU ir nepietiekama jauda vai ieviešana nav perfekti izstrādāta, ir manāms ievērojams veiktspējas kritums.
Patiesībā daudzi lietotāji ar AMD iGPU (piemēram, Renoir) ziņo, ka, aktivizējot VirGL, VM darbvirsma kļūst daudz lēnāka un smagākalīdz pat sliktākai situācijai nekā Virtio-GPU izmantošana "bez GPU". Tas nenozīmē, ka VirGL ir bezjēdzīgs, taču tas ir ļoti atkarīgs no kombinācijas. aparatūra + draiveri + VM grafikas ielāde.
Proxmox trio Virtual GPU + SPICE + Virtual Viewer Šī parasti ir minimālā saprātīgā konfigurācija grafiskai Linux darbvirsmai. Tā nodrošina pienācīgu peles rādītāju, loga izmēru maiņu un labāku attēlu saspiešanu nekā vienkārša VNC, bet tomēr... Negaidiet tādu pašu pieredzi kā ar VMware ESXi attālo konsoli vai VMRC., kas pēc vairāku gadu optimizācijas ir ļoti noslīpēti.
Tāpēc daudzi administratori, kas nāk no ESXi, ir pārsteigti, izmēģinot Proxmox. Neskatoties uz ļoti jaudīgu hipervizoru, Attālās darbvirsmas "ātruma" sajūta ir zemāka ja vien jūs nepielāgojat daudz smalku iestatījumu vai neizmantojat īpašu GPU.
Kad GPU caurlaide ir tā vērta, un kad ne?
GPU caurlaide joprojām ir vislabāk funkcionējošā opcija konkrētai virtuālajai mašīnai. Tomēr ikdienas darbvirsmas lietošanas scenārijos ir vairāki trūkumi. Piemēram, nepieciešamība pēc cita monitora ieejas, GPU zudums resursdatoram, papildu sarežģījumi (IOMMU, grupas, BIOS, draiveri, kļūdas ar apturēšanu utt.).
Ja tavs mērķis ir tāds vienai virtuālajai mašīnai ir pilns 3D paātrinājumsPūles parasti atmaksājas. Tādi projekti kā Looking Glass ļauj "atkārtoti ievadīt" VM attēlu resursdatora darbvirsmā, lai izvairītos no papildu monitoriem. Bet, ja vēlaties vairākas biroja vai testēšanas virtuālās mašīnas ar labām pamatzināšanāmGPU pārsūtīšana uz katru no tiem nav iespējama.
Jaudīgiem galddatoriem varat apsvērt hibrīda kombināciju: Primārais GPU resursdatoram un caurlaide no otra, pieticīgāka GPU konkrētai virtuālajai mašīnaiTādā veidā jūs uzturat ļoti lietojamu resursdatora darbvirsmu un piešķirat šai virtuālajai mašīnai grafisko vidi, kas ir ļoti tuvu vietējai; a klēpjdatora analīze Tas var sniegt perspektīvu par galddatoru alternatīvām salīdzinājumā ar klēpjdatoriem.
Ar klēpjdatoriem viss kļūst sarežģītāk. Parasti tiem ir viens iGPU (vai iGPU + dGPU, kas ir cieši integrēts ar programmaparatūru)Ierobežotu resursu dēļ un bez reālas iespējas uzstādīt vēl vienu grafikas karti, caurlaide reti ir vērtīga. Ir saprātīgāk izmantot paravirtualizācijas iespējas (virtio-gpu, SPICE, RDP), lai samazinātu virtuālo mašīnu grafikas prasības.
Kopumā, Passthrough ir piemērots rīks dažām ļoti prasīgām virtuālajām mašīnām.Laboratorijās ar daudzām iekārtām vai nelieliem galddatoriem jūs vairāk interesē hipervizora pielāgošana, CPU/RAM/I/O slodzes kontrole un pareizā attālās darbvirsmas protokola izvēle.
Hipervizori, NUMA, dinamiskā atmiņa un citi veiktspējas faktori
Papildus GPU, hipervizora pārvaldības veids CPU, atmiņa, krātuve un tīkls Tas tieši ietekmē VM darbvirsmas uztverto plūstamību. Hyper-V, KVM, VMware un citiem ir nedaudz atšķirīgas filozofijas, taču tiem visiem ir kopīgas koncepcijas.
Piemēram, Hyper-V arhitektūra ir balstīta uz hipervizors, kas kontrolē piekļuvi aparatūrai, saknes nodalījums ar pārvaldības sistēmu un sekundārie nodalījumi virtuālajām mašīnāmTo atbalsta tādas tehnoloģijas kā virtuālā NUMA, dinamiskā atmiņa, virtuālie komutatori, tīkla SR-IOV un krātuves optimizācijas, piemēram, ODX.
NUMA (nevienmērīga atmiņas piekļuve) ir īpaši svarīga serveros ar daudziem kodoliem. Ja liela virtuālā mašīna ir slikti sadalīta starp fiziskajiem NUMA mezgliem, tās atmiņas latentums palielinās. Un veiktspēja cieš, pat ja šķiet, ka uz papīra ir pietiekami daudz resursu. Ideālā gadījumā virtuālās mašīnas vNUMA topoloģijai vajadzētu saskaņoties ar resursdatora pNUMA topoloģiju.
Dinamiskā atmiņa (Hyper-V, palielināšanās citos hipervizoros) var ietaupīt globālo RAM, bet Tas nav piemērots latentuma jutīgām darba slodzēm, piemēram, datubāzēm vai galddatoriem ar daudzām atvērtām lietojumprogrammām.Šādos gadījumos ieteicams piešķirt fiksētu atmiņu, lai izvairītos no pauzēm, kad hipervizors nolemj atgūt visu RAM uzreiz.
Uzglabāšana ir visizplatītākais sastrēgums. Ir ieteicams Izmantojiet fiksēta izmēra VHDX diskus, atsevišķus sistēmas un datu diskus, izvēlieties uzņēmuma līmeņa SSD vai NVMe diskus un intensīvas slodzes gadījumā izvairieties no RAID konfigurācijām ar sliktu rakstīšanas darbību (RAID 5/6).Ja pieejams, Storage Spaces Direct vai NVMe masīvi palīdz uzturēt latentumu pieņemamās robežās.
Tīklā ieteicams konfigurēt Ārējie virtuālie slēdži ātrās tīkla kartēs (10 GbE, ja iespējams), tīkla karšu apvienošana, SR-IOV iespējošana ļoti lielām tīkla slodzēm un MTU un slodzes samazināšanas regulēšana. Tikai tad, ja to atbalsta visa tīkla ķēde. Slikta tīkla konfigurācija var likt attālinātajam darbvirsmam, pat ar labu grafisko procesoru, izskatīties sliktāk nekā gaidīts.
Stresa testi un lietošanas gadījumi: kad izvēlēties virtuālo vai fizisko
Lai izlemtu, vai migrēt grafikas darba slodzi uz virtuālo mašīnu vai atstāt to fiziskā datu nesējā, ir svarīgi Testēšana ar etaloniem un stresa rīkiem Tiem vajadzētu izmērīt centrālā procesora, operatīvās atmiņas, diska un tīkla noslodzi. Un, ja iespējams, arī grafikas procesora noslodzi. Ideālā gadījumā "īstā" lietojumprogramma būtu jāsalīdzina ar to pašu lietojumprogrammu, kas darbojas virtuālajā mašīnā.
Reālistisks modelis varētu būt šāds: CPU pārbaudei palaidiet sysbench vai Geekbench, RAM pārbaudei — stress-ng vai memtester, 4K IOPS un diska latentuma pārbaudei — fio, tīkla joslas platuma pārbaudei — iperf3., un dažus pamata grafikas etalonus (piemēram, glxgears vai pārlūkprogrammā balstītu WebGL testu) gan resursdatorā, gan virtuālajā datorā.
Ja veiktspējas zudums ir pieņemamās robežās (piemēram, Mazāk nekā 10% no centrālā procesora/RAM un 15–20% soda diskāJa attālā darbvirsma šķiet pietiekami ērta paredzētajam lietojumam (biroja automatizācijai, administrēšanai, vieglai izstrādei), virtualizācija ir pilnīgi derīga iespēja.
No otras puses, ja lietojumprogramma lielā mērā balstās uz Grafiskā grafika, zema latentuma un augsta ilgstoša I/O caurlaidspēja (renderēšana programmā Blender, apjomīga CAD, AI dzinēji lielu modeļu apmācībai, spēles utt.), pieredze parasti ir daudz labāka fiziskā serverī ar īpašu GPU vai profesionālas klases GPU caurlaidē/virtualizētā virtuālajā mašīnā.
Svarīgi ir noteikt, kurš komponents (gatavs centrālais procesors, nepietiekama RAM atmiņa, ierobežota I/O, īstas GPU trūkums, lēns tīkls vai slikti optimizēts darbvirsmas protokols) palēnina katru virtuālo mašīnu. šajā gadījumā piemērot vienkāršāko un izmaksu ziņā visefektīvāko iespējamo risinājumuun rezervēt lielos ieguldījumus (speciālas grafikas kartes, SR-IOV, profesionāla aparatūra) tām darba slodzēm, kurās tās patiešām rada atšķirību.