- Virtualizacija aplikacija i poslužitelja optimizira resurse, ali uvodi neznatno opterećenje CPU-a, RAM-a, diska i mreže koje se mora mjeriti i upravljati.
- U App-V-u, kombinacija dobro pripremljene osnovne slike, SCS načina rada, parametara klijenta i dobrog upravljanja profilima (UE-V/UPM) ključna je za smanjenje vremena prijave.
- Izbor između fizičkih poslužitelja i virtualiziranih okruženja ovisi o vrsti radnog opterećenja: bare metal za ekstremne performanse i virtualni strojevi za fleksibilnost, skalabilnost i centralizirano upravljanje.
- Testiranje opterećenja i kontinuirano praćenje omogućuju vam prilagođavanje resursa, otkrivanje uskih grla i osiguravanje dobrog korisničkog iskustva u VDI, RDSH i hibridnim oblacima.
Virtualizacija , jednostavno rečeno, uključuje stvaranje virtualnih verzija fizičkih resursa (poslužitelja, pohrane, mreža ili aplikacija) za pokretanje više okruženja na istom hardveru. Ova sposobnost "razdvajanja" fizičkog poslužitelja na nekoliko logičkih instanci temelj je računarstva u oblaku i većine modernih podatkovnih centara.
Virtualni stroj (VM) je izolirani sustav s vlastitim virtualnim CPU-om, memorijom, pohranom i mrežom, izgrađen od fizičkih resursa hosta. Svaki VM ponaša se kao da je neovisno računalo i obično je enkapsuliran u jednoj ili više datoteka, što ga čini relativno jednostavnim za premještanje, kopiranje i vraćanje.
Komponenta koja sve to omogućuje je hipervizor ili VMM (Virtual Machine Monitor). Njegova je funkcija odvojiti fizičke resurse hosta (CPU, RAM, disk, mreža) i dodijeliti ih različitim virtualnim strojevima kojima su potrebni, kontrolirajući njihovu upotrebu i izolirajući ih jedne od drugih tako da kvar u jednom virtualnom stroju ne utječe na ostatak sustava.
Postoje dvije glavne vrste hipervizora . Tip 1 (bare metal) radi izravno na hardveru poslužitelja i uobičajen je u podatkovnim centrima i privatnim oblacima. Tip 2 se instalira kao aplikacija na glavnom operativnom sustavu (na primjer, hipervizor za stolna računala za pokretanje više virtualnih strojeva na prijenosnom računalu).
U Linux ekosustavu, KVM (Kernel-based Virtual Machine) je posebno relevantan , hipervizor tipa 1 integriran u kernel koji omogućuje virtualnim strojevima da iskoriste performanse i mogućnosti Linuxa, s vrlo granularnom kontrolom CPU-a, memorije i uređaja.
Što je virtualizacija aplikacija i kako se razlikuje od virtualizacije poslužitelja?
Virtualizacija aplikacija odvaja aplikaciju od operativnog sustava tako da se program pokreće bez da je zapravo instaliran na korisnikovom uređaju. Aplikacija "vjeruje" da komunicira s operativnim sustavom, ali u stvarnosti komunicira s posredničkim slojem (hipervizor aplikacije ili tehnologija izolacije) koji preusmjerava pristup datotekama, registru i drugim resursima.
Obično se ove aplikacije izvode na središnjem poslužitelju (u podatkovnom centru ili oblaku) i isporučuju se putem mreže (LAN ili interneta) na korisnički uređaj. Krajnjem korisniku aplikacija izgleda izvorno, ali je zapravo objavljena ili virtualizirana u kontroliranom okruženju.
Za razliku od virtualizacije poslužitelja, koja funkcionira na razini cijelog operativnog sustava , virtualizacija aplikacija funkcionira na razini pojedinačnih programa : Word dokumenta, CRM-a, ERP-a, alata za dizajn itd. To uvelike pojednostavljuje upravljanje, izolaciju i ažuriranja, ali uvodi izazove performansi povezane s mrežom, pohranom i korisničkim profilima.
Prednosti virtualizacije aplikacija za korisnike, IT i poslovanje
Iz perspektive krajnjeg korisnika , glavna prednost je sloboda. Mogu koristiti svoj željeni uređaj (prijenosno računalo tvrtke, osobno računalo, tanki klijent, tablet) i pristupati korporativnim aplikacijama bez brige o instaliranju, ažuriranju ili održavanju bilo čega. Za njih je promjena uređaja gotovo besprijekorna: prijavljuju se i imaju spremne prečace za korištenje.
Za IT administratore , virtualizacija aplikacija predstavlja značajno olakšanje. Umjesto implementacije i ažuriranja softvera na stotinama ili tisućama računala, oni instaliraju i održavaju aplikaciju na jednom ili nekoliko poslužitelja te je objavljuju ovlaštenim korisnicima. To centralizira upravljanje na jednom mjestu i znatno ubrzava primjenu zakrpa, promjena verzija, sigurnosnih konfiguracija i pravila.
Programeri također imaju koristi. Mogu imati različita virtualizirana okruženja na istom sustavu za testiranje koda na različitim verzijama operativnih sustava ili kombinacijama softvera, bez potrebe za postavljanjem složenih fizičkih laboratorija. Nadalje, izolacija koju pruža sloj virtualizacije omogućuje im otvaranje potencijalno oštećenih ili opasnih datoteka bez ugrožavanja glavnog sustava.
Za organizaciju u cjelini, virtualizacija aplikacija olakšava inicijative poput BYOD-a (Bring Your Own Device - Donesi vlastiti uređaj) , smanjuje potrebu za kupnjom snažnih korporativnih uređaja, pojednostavljuje podršku i obično se prevodi u značajne uštede u dupliciranim licencama, satima podrške i ranoj obnovi hardvera.
Važna točka je usklađenost s propisima . Budući da se osjetljivi podaci ne nalaze na korisnikovom uređaju (već u podatkovnom centru ili oblaku), lakše je pridržavati se propisa poput HIPAA-e ili PCI-DSS-a, jer je površina napada smanjena, a kontrola pristupa i revizija centralizirani.
Utjecaj virtualizacije na performanse: CPU, RAM, disk i mreža
Virtualizacija uvijek uvodi određeno opterećenje resursa jer se pojavljuje dodatni sloj između aplikacije i hardvera (hipervizor, mehanizam za objavljivanje, udaljeni klijent itd.). Iako je ta kazna obično mala ako je platforma pravilno dimenzionirana, vrijedi razumjeti gdje je najuočljivija.
Na razini CPU-a , testovi performansi pokazuju da tipični VM koji radi na KVM-u ili VMware vSphere postiže između 5% i 7,5% manje performansi od istog sustava koji radi izravno na osnovnom hardveru. Ova razlika je prihvatljiva za većinu poslovnih aplikacija (uredski paketi, web aplikacije, ERP), ali može biti kritična za računalno zahtjevne zadatke, umjetnu inteligenciju ili 3D renderiranje.
Kod DDR4 u odnosu na DDR5 RAM , efektivna brzina može se smanjiti za oko 7-13% zbog dodatnog upravljanja koje zahtijeva hipervizor. U vrlo zahtjevnim okruženjima to zahtijeva ili predimenzioniranje memorije ili ograničavanje broja virtualnih strojeva po hostu kako bi se spriječila uska grla.
Najuočljivija razlika je u pohrani (IOPS) . Testovi s alatima poput fio pokazuju pad performansi od oko 17-25% u 4K nasumičnim operacijama čitanja/pisanja u usporedbi s istim diskom u golom sustavu. Odabir NVMe nizova, visokoučinkovitih SSD-ova, predmemorija i dobrog dizajna dijeljene pohrane ključan je za nesmetan rad virtualnih strojeva i virtualiziranih aplikacija.
Latencija mreže također se može povećati, posebno kada mnogi virtualni strojevi dijele isto fizičko sučelje ili prilikom premještanja prometa s puno grafičkih ili video sadržaja između udaljenih sesija. Dizajn mreže (VLAN-ovi, QoS, propusnost, rasterećenje) i korištenje učinkovitih protokola za objavljivanje grafike značajno utječu na korisničko iskustvo.
Windows, App-V i VDI/RDS okruženja: performanse u praksi
U modernim Windows okruženjima (Windows 7 SP1, Windows 10, Windows 11, Windows Server 2012 R2 i 2016), virtualizacija aplikacija s Microsoft App-V jedna je od ključnih tehnologija za isporuku aplikacija u scenarijima usluga udaljene radne površine (RDS) i VDI infrastrukturama.
U tim okruženjima korisnici obično rade na neperzistentnim računalima (VM-ovi ili RDSH hostovi koji se često regeneriraju). Kako bi se osiguralo da korisnici mogu pristupiti svojim virtualnim aplikacijama unutar nekoliko sekundi nakon prijave, ključno je optimizirati App -V klijenta , rješenje za upravljanje profilima i samu osnovnu sliku.
Korisničko iskustvo ovisi o nekoliko međusobno povezanih intervala: vremenu od trenutka kada korisnik unese svoje vjerodajnice do trenutka kada može komunicirati s radnom površinom, vremenu od tada do početka ažuriranja objavljivanja App-V-a, trajanju tog ažuriranja i konačno, vremenu potrebnom da prečac virtualne aplikacije ili povezanost datoteke postanu dostupni.
Optimizacija ovih vremena uključuje kombiniranje App-V konfiguracija ( način dijeljenog pohranjivanja sadržaja , ograničenja istovremenog objavljivanja, očuvanje korisničkih integracija), dobro rješenje za profiliranje (UE-V ili neki drugi UPM) i strategiju osnovne slike dizajniranu prema glavnom cilju: maksimalne performanse ili maksimalna ušteda prostora za pohranu.
Primjeri upotrebe: pristup orijentiran na performanse u odnosu na pohranu
Implementacije App-V-a u neperzistentnim, stateful VDI/RDSH okruženjima možemo grupirati u dva glavna ekstremna scenarija, znajući da se u praksi mnoge tvrtke nađu negdje između: jedna je optimizirana za performanse , a druga usmjerena na smanjenje potrošnje prostora za pohranu.
U scenariju orijentiranom na performanse, osnovna slika unaprijed uključuje neke ili sve relevantne pakete virtualnih aplikacija, kao i njihove grupe za povezivanje. To uključuje dodatnu pripremu i održavanje slike, ali nudi najbolje korisničko iskustvo: aplikacije se čine virtualno spremnima od trenutka kada se korisnik prijavi.
Pristup orijentiran na pohranu izbjegava uključivanje korisnički specifičnih paketa u osnovnu sliku, sprječavajući pretrpavanje dijeljenih diskovnih polja podacima koji mnogim korisnicima možda nisu potrebni. Ovaj pristup daje prioritet smanjenju veličine slika virtualnih strojeva, uz cijenu premještanja nekih operacija konfiguracije na vrijeme prijave, čime se neznatno povećava vrijeme potrebno da određene aplikacije postanu dostupne.
U praksi je uobičajeno primjenjivati pristup usmjeren na performanse na podskup kritičnih korisnika ili paketa (npr. osoblje korisničke službe ili intenzivno korištene poslovne aplikacije), a pristup usmjeren na pohranu na povremene korisnike ili aplikacije manje osjetljive na vrijeme pokretanja.
Priprema okruženja i osnovne slike za App-V
Da bi virtualizacija aplikacija u VDI-ju ili RDSH-u funkcionirala glatko, osnovno rješenje za upravljanje slikama i profilima (UE-V ili neki drugi UPM) mora biti pravilno pripremljeno. Pogreška u ovoj fazi obično rezultira beskonačnim prijavama, izgubljenim integracijama ili nepotrebnim dupliciranim publikacijama.
U pristupu usmjerenom na performanse, ključni koraci uključuju omogućavanje klijenta App-V integriranog u sustav , aktiviranje UE-V-a (ili ekvivalentnog rješenja) pomoću predloška konfiguracije App-V-a, konfiguriranje načina rada pohrane dijeljenog sadržaja (SCS) kako bi se podaci objavljivali samo na disku i postavljanje registra za zadržavanje korisničkih integracija nakon prijave.
Osim toga, svi globalni i korisnički paketi i grupe za povezivanje moraju biti unaprijed konfigurirani (pomoću naredbi kao što su Add-AppvClientPackage i Add-AppvClientConnectionGroup), a globalni paketi moraju biti unaprijed objavljeni. U nekim slučajevima preporučuje se izvođenje globalnih i korisničkih ciklusa objavljivanja/ažuriranja, poništavanje objavljivanja ciljnih korisničkih paketa i čišćenje VFS unosa u profilima (na primjer, u AppData\Local i AppData\Roaming povezanim s App-V).
U pristupu orijentiranom na pohranu, priprema je slična, ali su unaprijed konfigurirane samo globalne grupe veza i paketi. Paketi specifični za korisnike izostavljeni su iz osnovne slike kako bi se izbjeglo povećanje veličine i korištenja diska virtualnih strojeva.
Osim toga, važno je razumjeti da će IT administracija morati redovito ažurirati osnovnu sliku kako bi odražavala promjene u verzijama paketa, sigurnosnim zakrpama i novim pravima pristupa. U nekim okruženjima bit će potrebno upravljati nekoliko različitih slika za različite korisničke profile.
Kritični parametri performansi u App-V klijentu
Unutar App-V klijenta postoji nekoliko postavki registra koje izravno utječu na brzinu publikacija i opterećenje CPU-a, diska i mreže, posebno na RDS hostovima s mnogo istovremenih korisnika.
Način rada dijeljenog spremišta sadržaja (SCS) omogućuje pohranjivanje samo metapodataka objavljivanja na lokalni disk, dok se ostali resursi aplikacije učitavaju na zahtjev iz središnjeg repozitorija (SAN, poslužitelj sadržaja). To štedi lokalni IOPS i smanjuje prostor na disku, pod uvjetom da postoji mrežna veza s poslužiteljem sadržaja s niskom latencijom.
Opcija PreserveUserIntegrationsOnLogin sprječava klijenta da dezintegrira i ponovno integrira korisničke integracije iz paketa koji nisu unaprijed konfigurirani prilikom prijave. Ako ovaj ključ nije omogućen i postoji mnogo nekonfiguriranih korisničkih paketa, svaka prijava može rezultirati dvostrukim objavljivanjem za svaki paket, što značajno utječe na vrijeme prijave.
Drugi važan parametar je MaxConcurrentPublishingRefresh , koji definira koliko korisnika može istovremeno pokrenuti ažuriranje objave. Ostavljanje bez ograničenja na RDS poslužitelju može uzrokovati vrlo visoke skokove CPU-a kada se mnogi korisnici istovremeno prijave. Postavljanje razumne vrijednosti ublažava te skokove, ali uz cijenu da u scenarijima s velikim valovima prijava neki korisnici mogu iskusiti nešto dulje vrijeme čekanja da vide nove objavljene aplikacije.
Upravljanje korisničkim profilima: UE-V i druga UPM rješenja
Da bi se virtualne aplikacije pokrenule gotovo trenutno u netrajnim okruženjima, bitno je da rješenje za upravljanje korisničkim profilima održava i primjenjuje ispravne „integracije korisnika“ između sesija: ključeve registra, prečace, izbornike Start, App-V kataloge itd.
Microsoftova virtualizacija korisničkog iskustva (UE-V) snažno je usmjerena na VDI i RDS scenarije. Snima i pohranjuje korisničke postavke te ih automatski primjenjuje kada se korisnik prijavi na drugi uređaj ili sesiju. Za App-V, UE-V može raditi s određenim predlošcima koji bilježe točne putove registra i datoteka gdje su pohranjene integracije.
Jedna važna osobitost je rukovanje .lnk datotekama (prečacima). UE-V podržava uklanjanje .lnk ekstenzije s popisa isključenih datoteka samo u scenarijima u kojima svi korisnički uređaji imaju isti skup aplikacija instaliran na istoj putanji. Ako ovaj uvjet nije ispunjen (na primjer, aplikacija je instalirana samo na jednom računalu ili na drugoj putanji), sinkronizacija .lnk datoteka može rezultirati neispravnim prečacima.
Prilikom korištenja drugih UPM rješenja (diskovi korisničkih profila, proizvodi trećih strana) ključno je da mogu: sačuvati određene korisničke integracije (zapisnike i mape), sinkronizirati profil u odgovarajuće vrijeme (prijava ili pokretanje aplikacije, prije objavljivanja App-V) i zabilježiti promjene na tim lokacijama prije odjave.
U App-V-u je uveden uslužni program SyncAppvPublishingServer.exe kako bi se rješenjima za profiliranje pružio jasan okidač: pokreće ažuriranje objave korisnika prilikom prijave, ali omogućuje odgodu dok se profil u potpunosti ne učita. To sprječava App-V da objavi na nepotpunom ili zastarjelom profilu.
Vodič za korisničko iskustvo: što se događa pri svakoj prijavi
Promatrajući tijek korak po korak, možemo bolje razumjeti kako se virtualizacija aplikacija doživljava u svakodnevnom životu korisnika, ovisno o tome usvajamo li pristup usmjeren na performanse ili pohranu.
U pristupu usmjerenom na performanse , prva prijava na neperzistentni VDI/RDSH pokreće objavljivanje ili ažuriranje korisnika. Ako je to prvi put da je korisnik primio virtualne aplikacije, operacija traje uobičajeno vrijeme. Nakon završetka, rješenje za profiliranje bilježi integracije korisnika, obično nakon odjave, s učinkom sličnim spremanju ostatka stanja korisnika.
U početnim fazama, UPM rješenje prvo primjenjuje sve korisničke integracije prije nego što App-V počne osvježavati proces objavljivanja. Korisnici vide prečace na radnoj površini ili izborniku Start od samog početka, a mnogi od njih odmah su funkcionalni. Ako nema promjena dozvola, proces objavljivanja završava se za nekoliko sekundi. Kada postoje promjene, trajanje se povećava ovisno o broju i složenosti virtualiziranih aplikacija.
Kao rezultat toga, očuvanjem 100% korisničkih integracija, opterećenje tijekom objavljivanja je minimizirano : sustav prilagođava samo promjene dozvola ili verzija, a aplikacije su spremne u vrlo kratkom vremenu od prijave.
U pristupu temeljenom na pohrani , prva prijava također pokreće korisničku publikaciju, s normalnim trajanjem. Međutim, i pri toj prvoj prijavi i pri sljedećim prijavama, potreba za prethodnom konfiguracijom (dodavanjem ili ažuriranjem) korisničkih paketa može produžiti dostupnost aplikacije. Uobičajeno je dodati 10 sekundi ili više, ovisno o količini i složenosti paketa.
U ovom slučaju, procesi objavljivanja i ažuriranja moraju ponovno konfigurirati sve virtualne aplikacije pri svakoj prijavi, što neizbježno produžuje fazu osvježavanja objavljivanja. To štedi prostor na disku, ali žrtvuje dio brzine prijave.
Životni ciklus App-V paketa i stanja na čekanju
Upravljanje životnim ciklusom App-V paketa također utječe na performanse i dosljednost verzija koje korisnici vide. Kada administrator ažurira paket, promijeni dopuštenja ili poništi objavljivanje aplikacija, te operacije mogu ostati na čekanju ako se paket koristi.
Počevši od App-V 5.0 SP2, uvedena su stanja na čekanju . Umjesto neuspjeha, operacije objavljivanja ili poništavanja objavljivanja označavaju se za dovršetak pri sljedećem ponovnom pokretanju usluge App-V ili kada se ponovno izda naredba za objavljivanje/poništavanje objavljivanja. Za globalno objavljene pakete to obično zahtijeva ponovno pokretanje poslužitelja ili klijentske usluge.
U netrajnim okruženjima, ovi zadaci na čekanju možda nikada neće biti obrađeni jer se računala odbacuju ili ponovno stvaraju prije nego što se uvjeti ispune. Zadaci na čekanju pohranjuju se u korisničkom profilu (na primjer, pod HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\PendingTasks), a ako rješenje za profiliranje ne primijeni ovaj ključ prije prijave, operacije će ostati neizvršene.
Zato je toliko važno da osnovna slika bude usklađena sa stvarnim stanjem paketa: verzije, prava, globalna izdanja. Što se manje oslanjamo na statuse na čekanju, to će iskustvo biti predvidljivije i manje će biti iznenađenja s paketima koji se čine zaglavljenima ili neočekivano nestaju.
Optimizacija i konfiguracija sekvenciranja za poboljšanje performansi objavljivanja
App-V uključuje razne značajke koje utječu na ponašanje objavljivanja i pokretanja aplikacija. Određene prilagodbe tijekom faze sekvenciranja mogu napraviti primjetne razlike u okruženjima brzih mreža.
Jedan primjer je uklanjanje bloka značajki 1 (FB1) . Ako FB1 (minimalni skup datoteka koje se prethodno preuzimaju za pokretanje aplikacije) nije definiran, aplikacija će pokušati odmah pokrenuti i preuzeti ono što joj je potrebno u hodu. Na brzim mrežama to može ubrzati prvo pokretanje, ali na sporim mrežama može uzrokovati prekide ili čekanje dok se struji dodatni sadržaj.
Prilikom izrade novog paketa pomoću sekvencera, jednostavno ostavite opciju "Optimiziraj paket za spore mreže" neoznačenu tijekom koraka strujanja. Za postojeće pakete možete ažurirati paket bez odabira ove optimizacije. Idealno bi bilo izvršiti ove testove u kontroliranom okruženju i uvijek nakon toga vratiti stroj za sekvenciranje na čistu snimku stanja.
Drugi aspekt je upravljanje Side-by-Side (SxS) sklopovima , kao što su Visual C++ runtime okruženja. Nije potrebno mijenjati redoslijed paketa da bi se oni modificirali: ako su SxS ovisnosti već instalirane na klijentu, MSI instalacijski program koji App-V može pokrenuti tijekom objavljivanja neće se pokrenuti, što će uštedjeti vrijeme. Uključivanje previše SxS sklopova u paket može pokrenuti dodatne instalacije tijekom objavljivanja, što utječe na performanse.
Korištenje dinamičkih konfiguracijskih datoteka (Implementacija/Konfiguracija korisnika) također ima utjecaj. App-V klijent mora analizirati te datoteke i pokretati skripte ili primijeniti izuzeća/uključivanja virtualnog registra. Ako svaki paket sadrži velike konfiguracije, objavljivanje će biti pogođeno. Korištenje samo tamo gdje pružaju stvarnu vrijednost i onemogućavanje u paketima kojima nisu potrebne može značajno smanjiti vrijeme objavljivanja.
Konačno, vrijedi pregledati virtualne fontove uključene u pakete. Iako tipičan paket obično sadrži najviše dvadeset, svaki deklarirani font znači dodatni posao tijekom ažuriranja implementacije. Onemogućavanje nepotrebnih virtualnih fontova putem dinamičke konfiguracije i umjesto toga instaliranje fontova koji su stvarno potrebni izvorno u slici pomaže u skraćivanju vremena implementacije s mnogo korisnika.
Opća optimizacija performansi u virtualnim strojevima
Osim App-V-a, postoji niz uobičajenih praksi za poboljšanje performansi bilo kojeg virtualnog stroja , bilo u okruženju računala, laboratorija ili produkcije.
Prvi korak je osigurati da su proširenja za virtualizaciju hardvera, kao što su Intel VT-x ili AMD-V , omogućena u BIOS-u/UEFI-ju hosta. Bez njih, hipervizor će morati emulirati više operacija u softveru, a performanse će se smanjiti.
Također je preporučljivo odabrati virtualne diskove fiksne veličine umjesto dinamičkih. Iako su diskovi koji rastu kako se popunjavaju fleksibilniji u smislu prostora, obično postaju fragmentiraniji i nude lošije performanse. Ako prostor na hostu nije problem, vrijedi od početka rezervirati maksimalnu veličinu virtualnog diska.
Lokacija pohrane je još jedan ključni faktor. Kad god je to moguće, najbolje je hostirati virtualne strojeve na brzim SSD-ovima, a ne na mehaničkim tvrdim diskovima ili sporim vanjskim diskovima. Razlika u performansama u vremenu pokretanja sustava, vremenu pokretanja aplikacija i pristupu podacima vrlo je uočljiva.
Ne zaboravite instalirati alate za integraciju hipervizora (Guest Additions, VMware Tools itd.) na gostujuće sustave. Oni dodaju optimizirane upravljačke programe za video, mrežu, miš i pohranu te omogućuju puno glatkiji rad nego s generičkim upravljačkim programima operativnog sustava.
Konačno, preporučljivo je dodijeliti dovoljno RAM-a i CPU jezgri svakom virtualnom stroju, imajući na umu da svaki virtualni stroj pokreće kompletan operativni sustav. Za Windows 7/10/11 sustave ili trenutne Linux distribucije, 2 GB je vrlo ograničen minimum; u praksi, dodjeljivanje više memorije značajno poboljšava performanse. Isto vrijedi i za CPU jezgre: ako host ima mnogo jezgri, njihova mudra raspodjela među aktivnim virtualnim strojevima će napraviti razliku.
Fizički poslužitelji u odnosu na virtualizirana okruženja: kada odabrati koju opciju
Prilikom implementacije usluga uvijek se postavlja pitanje je li bolje odabrati virtualne strojeve ili namjenske fizičke poslužitelje . Ne postoji jedinstven odgovor: ovisi o opterećenju, kritičnosti latencije te ciljevima troškova i fleksibilnosti.
Fizički (bare metal) poslužitelji nude maksimalne sirove performanse bez opterećenja hipervizora. Oni su preferirani izbor za vrlo visokoučinkovite transakcijske baze podataka, opterećenja s intenzivnim korištenjem GPU-a (AI, 3D renderiranje, napredni CAD) ili usluge u stvarnom vremenu (igre, jako kodirani streaming) gdje je svaka milisekunda važna.
S druge strane, virtualni strojevi sjajno se pokazuju u vrlo fleksibilnim i skalabilnim okruženjima . Web servisi, mikroservisi i kontejneri , razvojna i testna okruženja, virtualna radna mjesta i mnoge poslovne aplikacije izvrsno funkcioniraju u virtualiziranim okruženjima, omogućujući snimke stanja, migracije uživo, brzo pružanje usluga i centralizirano upravljanje resursima.
S gledišta licenciranja i troškova, virtualizirana okruženja mogu biti skuplja ako se koriste komercijalni hipervizori s licencama po CPU-u ili po socketu, ali štede na hardveru, prostoru i potrošnji energije. S druge strane, namjenski fizički poslužitelj može biti jeftiniji za licenciranje, ali manje učinkovit u korištenju resursa ako hostira samo nekoliko aplikacija.
U praksi se mnoge organizacije odlučuju za hibridni pristup : fizičke poslužitelje za najkritičnija i na performanse osjetljiva opterećenja i virtualizacijski klaster za ostale usluge, uključujući platforme za objavljivanje aplikacija i VDI.
Stres testovi i metrike za procjenu performansi
Za donošenje informiranih odluka, sama intuicija nije dovoljna: potrebno je mjeriti. Testovi opterećenja CPU-a, RAM-a, diska i mreže omogućuju vam usporedbu virtualiziranih okruženja s fizičkim poslužiteljima i provjeru je li smanjenje performansi prihvatljivo za određenu aplikaciju.
Alati poput sysbencha pomažu u mjerenju računalnog kapaciteta CPU-a (na primjer, izračunavanjem prostih brojeva do određene granice), dok uslužni programi poput memtestera ili stress-nga omogućuju procjenu latencije memorije i propusnosti pod različitim uvjetima opterećenja.
Za pohranu podataka, specijalizirani alati poput fio-a su de facto standard za mjerenje IOPS-a, propusnosti i latencije s različitim obrascima pristupa (sekvencijalno čitanje/pisanje, nasumično čitanje/pisanje i kombinacije oba). Ovi alati omogućuju vam kvantificiranje utjecaja sloja virtualizacije i vrste korištenog diskovnog backenda.
Na razini mreže, uslužni programi poput iperf3, netperf i ping omogućuju vam mjerenje maksimalne propusnosti, prosječne latencije i podrhtavanja između fizičkih hostova, virtualnih strojeva i udaljenih klijenata. Ovi podaci su posebno relevantni u scenarijima koji uključuju objavljivanje grafičkih aplikacija ili udaljenih radnih površina s visokim zahtjevima za interakcijom.
Kombiniranjem ovih metrika s korisničkim iskustvom u stvarnom pilotnom programu moguće su prilagodbe dizajna: od nadogradnje RAM-a ili CPU-a na određene virtualne strojeve, do promjene lokacija diskova, mijenjanja maksimalne veličine istodobnih App-V publikacija ili odlučivanja da se određena baza podataka treba pokretati na fizičkom hostu.
U svjetlu navedenog, dobro osmišljena virtualizacija aplikacija i infrastrukture može ponuditi vrlo snažnu ravnotežu između performansi, fleksibilnosti i troškova . Korištenje tehnologija kao što su App-V, UE-V, KVM ili komercijalni hipervizori, pažljiv odabir između fizičkih poslužitelja i virtualnih strojeva na temelju opterećenja i fino podešavanje kritičnih parametara objavljivanja i korisničkog profila omogućuje zaposlenicima da uživaju u brzim, bilo gdje dostupnim aplikacijama bez da temeljna složenost postane usko grlo poslovanja.
