- Rakenduste ja serverite virtualiseerimine optimeerib ressursse, kuid toob kaasa väikese lisakoormuse protsessorile, muutmälule, kettale ja võrgule, mida tuleb mõõta ja hallata.
- App-V-s on sisselogimisaja lühendamise võtmeks hästi ettevalmistatud baaskujutise, SCS-režiimi, kliendiparameetrite ja hea profiilihalduse (UE-V/UPM) kombinatsioon.
- Füüsiliste serverite ja virtualiseeritud keskkondade vahel valimine sõltub töökoormuse tüübist: paljas metall äärmise jõudluse tagamiseks ja virtuaalmasinad paindlikkuse, skaleeritavuse ja tsentraliseeritud halduse tagamiseks.
- Stresstestimine ja pidev jälgimine võimaldavad teil ressursse kohandada, tuvastada kitsaskohti ja tagada hea kasutajakogemuse VDI-, RDSH- ja hübriidpilvedes.
Virtualiseerimine hõlmab lihtsustatult öeldes füüsiliste ressursside (serverite, salvestusruumi, võrkude või rakenduste) virtuaalsete versioonide loomist , et käitada samal riistvaral mitut keskkonda. See võime "viilutada" füüsilist serverit mitmeks loogiliseks eksemplariks on pilvandmetöötluse ja enamiku tänapäevaste andmekeskuste alus.
Virtuaalmasin (VM) on isoleeritud süsteem, millel on oma virtuaalne protsessor, mälu, salvestusruum ja võrk, mis on ehitatud hosti füüsilistest ressurssidest. Iga VM käitub nagu oleks see iseseisev arvuti ja on tavaliselt kapseldatud ühte või mitmesse faili, mistõttu on seda suhteliselt lihtne teisaldada, kopeerida ja taastada.
Komponent, mis seda kõike võimaldab, on hüperviisor ehk VMM (Virtual Machine Monitor). Selle ülesanne on eraldada hosti füüsilised ressursid (protsessor, muutmälu, ketas, võrk) ja jaotada need erinevatele virtuaalmasinatele, mis neid vajavad, kontrollides nende kasutamist ja isoleerides need üksteisest nii, et ühe virtuaalmasina rike ei mõjutaks ülejäänud süsteemi.
Hüperviisoreid on kahte peamist tüüpi . 1. tüüp (bare metal) töötab otse serveri riistvaral ja on levinud andmekeskustes ja privaatpilvedes. 2. tüüp installitakse rakendusena host-operatsioonisüsteemi peale (näiteks töölaua hüperviisor mitme virtuaalmasina käitamiseks sülearvutis).
Linuxi ökosüsteemis on eriti oluline KVM (kernel-based Virtual Machine) , kerneli integreeritud 1. tüüpi hüperviisor, mis võimaldab virtuaalmasinatel Linuxi jõudlusest ja võimalustest kasu saada, pakkudes väga detailset kontrolli protsessori, mälu ja seadmete üle.
Mis on rakenduste virtualiseerimine ja kuidas see erineb serveri virtualiseerimisest?
Rakenduste virtualiseerimine eraldab rakenduse selle operatsioonisüsteemist, nii et programm töötab ilma seda tegelikult kasutaja seadmesse installimata. Rakendus "usub", et see suhtleb operatsioonisüsteemiga, kuid tegelikkuses suhtleb see vahekihiga (rakenduse hüperviisor või isolatsioonitehnoloogia), mis suunab juurdepääsu failidele, registrile ja muudele ressurssidele.
Tavaliselt töötavad need rakendused keskserveris (andmekeskuses või pilves) ja edastatakse kasutaja seadmesse võrgu (LAN või interneti) kaudu. Lõppkasutajale tundub rakendus küll natiivsena, kuid tegelikult avaldatakse või virtualiseeritud kontrollitud keskkonnas.
Erinevalt serveri virtualiseerimisest, mis töötab kogu operatsioonisüsteemi tasandil , töötab rakenduste virtualiseerimine üksikute programmide , näiteks Wordi dokumendi, CRM-i, ERP-i, disainitööriista jne tasandil . See lihtsustab oluliselt haldust, isoleerimist ja värskendusi, kuid toob kaasa võrgu, salvestusruumi ja kasutajaprofiilidega seotud jõudlusprobleeme.
Rakenduste virtualiseerimise eelised kasutajatele, IT-le ja ettevõttele
Lõppkasutaja vaatenurgast on peamine eelis vabadus. Nad saavad kasutada oma eelistatud seadet (ettevõtte sülearvuti, personaalarvuti, õhuke klient, tahvelarvuti) ja pääseda ligi ettevõtte rakendustele ilma, et peaksid muretsema millegi installimise, värskendamise või hooldamise pärast . Nende jaoks on seadmete vahetamine peaaegu sujuv: nad logivad sisse ja neil on otseteed kasutusvalmis.
IT-administraatorite jaoks on rakenduste virtualiseerimine märkimisväärne kergendus. Tarkvara juurutamise ja parandamise asemel sadades või tuhandetes arvutites installivad ja haldavad nad rakendust ühel või mõnel serveril ning avaldavad selle volitatud kasutajatele. See koondab halduse ühte kohta ja muudab paranduste, versioonimuudatuste, turvakonfiguratsioonide ja poliitikate rakendamise palju kiiremaks.
Ka arendajad saavad sellest kasu. Neil saab olla samal süsteemil erinevad virtualiseeritud keskkonnad, et testida koodi erinevatel operatsioonisüsteemi versioonidel või tarkvarakombinatsioonidel, ilma et nad peaksid üles seadma keerukaid füüsilisi laboreid. Lisaks võimaldab virtualiseerimiskihi pakutav isolatsioon neil avada potentsiaalselt rikutud või ohtlikke faile ilma hostsüsteemi kahjustamata.
Organisatsiooni jaoks tervikuna hõlbustab rakenduste virtualiseerimine selliseid algatusi nagu BYOD (Bring Your Own Device ehk oma seadme kaasa võtmine) , vähendab võimsate ettevõtteseadmete ostmise vajadust, lihtsustab tuge ning tähendab tavaliselt märkimisväärset kokkuhoidu duplikaatlitsentside, tugitundide ja riistvara varajase uuendamise pealt.
Oluline punkt on regulatiivsete nõuete järgimine . Kuna tundlikud andmed ei asu kasutaja seadmes (vaid andmekeskuses või pilves), on lihtsam järgida selliseid eeskirju nagu HIPAA või PCI-DSS, kuna rünnakupind on väiksem ning juurdepääsu kontroll ja auditeerimine on tsentraliseeritud.
Virtualiseerimise mõju jõudlusele: protsessor, muutmälu, ketas ja võrk
Virtualiseerimine toob alati kaasa teatud ressursikulu , kuna rakenduse ja riistvara vahele ilmub täiendav kiht (hüperviisor, avaldamismootor, kaugklient jne). Kuigi see koormus on platvormi õige suuruse korral tavaliselt väike, tasub mõista, kus see kõige märgatavam on.
Protsessori tasandil näitavad võrdlustestid, et tüüpiline KVM-il või VMware vSphere'il töötav virtuaalmasin saavutab 5–7,5% väiksema jõudluse kui sama süsteem, mis töötab otse paljal metallriistvaral. See erinevus on enamiku ettevõtte rakenduste (kontoripaketid, veebirakendused, ERP) jaoks vastuvõetav, kuid see võib olla kriitilise tähtsusega arvutuslikult intensiivsete ülesannete, tehisintellekti või 3D-renderdamise jaoks.
DDR4 ja DDR5 muutmälude puhul võib efektiivne kiirus hüperviisori vajaliku täiendava halduse tõttu väheneda umbes 7–13%. Väga nõudlikes keskkondades on vaja kas mälu ülesuurendada või virtuaalmasinate arvu hosti kohta piirata, et vältida kitsaskohti.
Kõige märgatavam erinevus on salvestusruumis (IOPS) . Selliste tööriistadega nagu fio tehtud testid näitavad 4K juhusliku lugemise/kirjutamise operatsioonide puhul umbes 17–25% jõudluse langust võrreldes sama kettaga paljal metallil. NVMe-massiivide, suure jõudlusega SSD-de, vahemälude ja hea jagatud salvestusruumi disaini valimine on virtuaalmasinate ja virtualiseeritud rakenduste sujuva töö tagamiseks kriitilise tähtsusega.
Võrgu latentsus võib samuti suureneda, eriti kui paljudel virtuaalmasinatel on sama füüsiline liides või kui graafika- või videomahukat liiklust kaugseansside vahel liigutatakse. Võrgu ülesehitus (VLAN-id, QoS, ribalaius, koormuse vähendamine) ja tõhusate graafika avaldamise protokollide kasutamine mõjutavad oluliselt kasutajakogemust.
Windowsi, App-V ja VDI/RDS keskkonnad: jõudlus praktikas
Kaasaegsetes Windowsi keskkondades (Windows 7 SP1, Windows 10, Windows 11, Windows Server 2012 R2 ja 2016) on rakenduste virtualiseerimine Microsoft App-V abil üks võtmetehnoloogiaid rakenduste edastamiseks kaugtöölaua teenuste (RDS) stsenaariumides ja VDI infrastruktuurides.
Nendes keskkondades töötavad kasutajad tavaliselt mittepüsivatel masinatel (virtuaalmasinad või RDSH-hostid, mida sageli uuesti genereeritakse). Selleks, et kasutajad saaksid oma virtuaalsetele rakendustele juurde pääseda sekundite jooksul pärast sisselogimist, on oluline optimeerida App -V klienti , profiilihalduslahendust ja baaskujutist ennast.
Kasutajakogemus sõltub mitmest omavahel seotud intervallist: ajast alates hetkest, mil kasutaja sisestab oma identimisteabe, kuni ta saab töölauaga suhelda, ajast sealt kuni App-V avaldamise värskenduse alguseni, selle värskenduse kestusest ja lõpuks ajast, mis kulub virtuaalse rakenduse otsetee või failiseose kättesaadavaks muutumiseks.
Nende aegade optimeerimine hõlmab App-V konfiguratsioonide ( jagatud sisusalvestusrežiim , samaaegse avaldamise piirangud, kasutajaintegratsioonide säilitamine), hea profileerimislahenduse (UE-V või mõni muu UPM) ja põhieesmärgi kohaselt loodud baaskujutise strateegia kombineerimist: maksimaalne jõudlus või maksimaalne salvestusruumi kokkuhoid.
Kasutusjuhud: tulemuspõhine lähenemine vs. salvestusruum
Me saame App-V juurutused mittepüsivates, olekuga VDI/RDSH keskkondades jagada kahte peamisse äärmuslikku stsenaariumi, teades, et praktikas jäävad paljud ettevõtted kuhugi vahepeale: üks on optimeeritud jõudluse saavutamiseks ja teine keskendub salvestusruumi tarbimise vähendamisele.
Jõudluspõhises stsenaariumis sisaldab baaskujutis eelnevalt mõnda või kõiki asjakohaseid virtuaalrakenduste pakette ja nende ühendusrühmi. See hõlmab täiendavat kujutise ettevalmistamist ja hooldust, kuid pakub parimat kasutajakogemust: rakendused kuvatakse praktiliselt valmis hetkest, mil kasutaja sisse logib.
Salvestusruumile orienteeritud lähenemisviis väldib kasutajaspetsiifiliste pakettide lisamist baaskujutisesse, mis hoiab ära jagatud kettamassiivide risustamise andmetega, mida paljud kasutajad ei pruugi vajada. See lähenemisviis seab esikohale virtuaalmasinate kujutiste suuruse vähendamise, nihutades mõned konfiguratsioonitoimingud sisselogimise ajale, suurendades seega veidi aega, mis kulub teatud rakenduste kättesaadavaks muutumiseks.
Praktikas on tavaline, et jõudluspõhist lähenemisviisi rakendatakse kriitiliste kasutajate või pakettide alamhulgale (nt klienditeenindajad või paljukasutatavad ärirakendused) ja salvestuspõhist lähenemisviisi juhuslikele kasutajatele või rakendustele, mis on käivitusaja suhtes vähem tundlikud.
Keskkonna ja baaskujutise ettevalmistamine App-V jaoks
Rakenduste virtualiseerimise sujuvaks toimimiseks VDI-s või RDSH-s peab baaskujutise ja profiilide halduslahendus (UE-V või mõni muu UPM) olema korralikult ette valmistatud. Selles etapis tekkiv viga toob tavaliselt kaasa lõputuid sisselogimisi, integratsioonide kadumise või tarbetuid duplikaatväljaandeid.
Jõudluspõhise lähenemisviisi puhul hõlmavad peamised sammud süsteemi integreeritud App-V kliendi lubamist , UE-V (või samaväärse lahenduse) aktiveerimist App-V konfiguratsioonimalliga, jagatud sisusalvestuse (SCS) režiimi konfigureerimist nii, et kettal hoitaks ainult avaldatavaid andmeid, ja registri seadistamist nii, et see säilitaks sisselogimisel kasutajaintegratsioonid.
Lisaks tuleb kõik globaalsed ja kasutajaühenduse paketid ja rühmad eelkonfigureerida (kasutades selliseid käske nagu Add-AppvClientPackage ja Add-AppvClientConnectionGroup) ning globaalsed paketid peavad olema eelnevalt avaldatud. Mõnel juhul on soovitatav teostada globaalseid ja kasutaja avaldamise/värskendamise tsükleid, tühistada kasutaja sihtmärgi pakettide avaldamine ning puhastada profiilides VFS-kirjed (näiteks AppData\Local ja AppData\Roaming, mis on seotud App-V-ga).
Salvestusruumil põhineva lähenemisviisi puhul on ettevalmistus sarnane, kuid eelkonfigureeritakse ainult globaalsed ühendusgrupid ja paketid. Kasutajapõhised paketid jäetakse baaskujutisest välja, et vältida virtuaalmasinate suuruse ja kettaruumi kasutamise suurenemist.
Lisaks on oluline mõista, et IT-administraator peab baaskujutist regulaarselt värskendama , et see kajastaks muudatusi paketiversioonides, turvapaikades ja uutes juurdepääsuõigustes. Mõnes keskkonnas on vaja hallata mitut erinevat kujutist erinevate kasutajaprofiilide jaoks.
App-V kliendi kriitilised jõudlusparameetrid
App-V kliendis on mitu registrisätet , mis mõjutavad otseselt publikatsioonide kiirust ning protsessori, ketta ja võrgu koormust, eriti RDS-hostidel, kus on palju samaaegseid kasutajaid.
Jagatud sisusalvestuse (SCS) režiim lubab kohalikul kettal salvestada ainult avaldamise metaandmeid, samas kui ülejäänud rakenduse ressursid laaditakse nõudmisel kesksest hoidlast (SAN, sisuserver). See säästab kohalikku IOPS-i ja vähendab kettaruumi, eeldusel, et sisuserveriga on olemas madala latentsusega võrguühendus.
Valik PreserveUserIntegrationsOnLogin takistab kliendil sisselogimisel eelkonfigureerimata pakettidest pärinevate kasutajaintegratsioonide lahtiühendamist ja uuesti integreerimist. Kui see võti pole lubatud ja konfigureerimata kasutajapakette on palju, võib iga sisselogimine kaasa tuua iga paketi topeltavaldamise, mis mõjutab oluliselt sisselogimisaega.
Teine oluline parameeter on MaxConcurrentPublishingRefresh , mis määrab, mitu kasutajat saavad samaaegselt avaldamisvärskenduse käivitada. Selle piiranguta jätmine RDS-serveris võib põhjustada väga suuri protsessori koormuse tõuse, kui paljud kasutajad logivad samaaegselt sisse. Mõistliku väärtuse määramine leevendab neid tõuse, kuid suurte sisselogimislainete korral võivad mõnedel kasutajatel uute avaldatud rakenduste nägemiseks tekkida veidi pikemad ooteajad.
Kasutajaprofiilide haldus: UE-V ja muud UPM-i lahendused
Selleks, et virtuaalsed rakendused saaksid mittepüsivates keskkondades peaaegu koheselt käivituda, on oluline, et kasutajaprofiilide halduslahendus säilitaks ja rakendaks seansside vahel õigeid „kasutajaintegratsioone”: registrivõtmeid, otseteid, start-menüüsid, App-V katalooge jne.
Microsofti kasutajakogemuse virtualiseerimine (UE-V) keskendub suuresti VDI ja RDS stsenaariumidele. See jäädvustab ja salvestab kasutaja seaded ning rakendab neid automaatselt, kui kasutaja logib sisse teise seadmesse või seansi kaudu. App-V puhul saab UE-V töötada kindlate mallidega, mis jäädvustavad täpsed registri- ja failiteed, kuhu integratsioonid salvestatakse.
Üks oluline eripära on .lnk-failide (otseteede) käsitlemine . UE-V toetab .lnk-laiendi eemaldamist välistatud failide loendist ainult siis, kui kõikidel kasutajaseadmetel on sama rakenduste komplekt installitud samale teele. Kui see tingimus ei ole täidetud (näiteks rakendus on installitud ainult ühte arvutisse või erinevale teele), võib .lnk-failide sünkroonimine põhjustada katkiseid otseteid.
Teiste UPM-i lahenduste (kasutajaprofiili kettad, kolmandate osapoolte tooted) kasutamisel on oluline, et need suudaksid säilitada määratud kasutajaintegratsioone (logid ja kaustad), sünkroonida profiili õigel ajal (sisselogimisel või rakenduse käivitamisel enne App-V avaldamist) ja jäädvustada muudatusi nendes asukohtades enne väljalogimist.
App-V-s võeti kasutusele utiliit SyncAppvPublishingServer.exe, et pakkuda profileerimislahendusi selge päästikuga: see käivitab kasutaja avaldamisvärskenduse sisselogimisel, kuid võimaldab seda edasi lükata kuni profiili täieliku laadimiseni. See takistab App-V-l avaldamast mittetäielikku või aegunud profiili.
Kasutajakogemuse õpetus: mis juhtub iga sisselogimise ajal
Vaadates voogu samm-sammult, saame paremini aru, kuidas kasutajate igapäevaelus rakenduste virtualiseerimist tajutakse, olenevalt sellest, kas me kasutame jõudlus- või salvestuslähenemisviisi.
Jõudluspõhise lähenemisviisi puhul käivitab esimene sisselogimine mittepüsivasse VDI/RDSH-sse kasutaja avaldamise või värskendamise. Kui see on esimene kord, kui kasutaja on virtuaalseid rakendusi saanud, võtab toiming tavapärase aja. Kui see on lõpule viidud, jäädvustab profileerimislahendus kasutajate integratsioonid, tavaliselt väljalogimisel, millel on sarnane mõju ülejäänud kasutaja oleku salvestamisele.
Esialgses etapis rakendab UPM-i lahendus kõik kasutajaintegratsioonid enne, kui App-V hakkab avaldamisprotsessi värskendama. Kasutajad näevad otseteid oma töölaual või menüüs Start kohe algusest peale ja paljud neist on koheselt funktsionaalsed. Kui õigustes muudatusi ei tehta, lõpeb avaldamisprotsess sekunditega. Muudatuste korral pikeneb kestus sõltuvalt virtualiseeritud rakenduste arvust ja keerukusest.
Selle tulemusel, säilitades 100% kasutajaintegratsioonidest, on avaldamise ajal koormus minimaalne : süsteem kohandab ainult õiguste või versiooni muudatusi ning rakendused on sisselogimisest alates väga lühikese aja jooksul valmis.
Salvestusruumil põhineva lähenemisviisi puhul käivitab esimene sisselogimine ka kasutaja avaldatud faili tavapärase kestusega. Nii esimesel kui ka järgnevatel sisselogimistel võib aga kasutajapakettide eelkonfigureerimise (lisamise või värskendamise) vajadus rakenduse kättesaadavust pikendada. Tavaline on lisada 10 sekundit või rohkem, olenevalt pakettide mahust ja keerukusest.
Sellisel juhul peavad avaldamis- ja värskendamisprotsessid igal sisselogimisel kõik virtuaalsed rakendused ümber konfigureerima, mis pikendab paratamatult avaldamise värskendamise etappi. See säästab kettaruumi, kuid ohverdab osa sisselogimiskiirusest.
App-V paketi elutsükkel ja ootel olekud
App-V pakettide elutsükli haldamine mõjutab ka jõudlust ja kasutajatele nähtavate versioonide järjepidevust. Kui administraator paketti värskendab, õigusi muudab või rakenduste avaldamise tühistab, võivad need toimingud jääda ootele, kui pakett on kasutusel.
Alates App-V 5.0 SP2-st on kasutusele võetud ootel olekud . Nurjumise asemel märgitakse avaldamis- või avaldamise tühistamistoimingud lõpuleviituks järgmisel App-V teenuse taaskäivitamisel või avaldamis-/avaldamise tühistamiskäsu uuesti väljastamisel. Globaalselt avaldatud pakettide puhul nõuab see tavaliselt serveri või klienditeenuse taaskäivitamist.
Mittepüsivates keskkondades ei pruugita neid ootel ülesandeid kunagi töödelda, kuna masinad hüljatakse või luuakse uuesti enne tingimuste täitmist. Ootel ülesanded salvestatakse kasutajaprofiili (näiteks kausta HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\PendingTasks all) ja kui profileerimislahendus seda võtit enne sisselogimist ei rakenda, jäävad toimingud ebakindlasse olukorda.
Seepärast on nii oluline hoida baaskujutis vastavuses pakettide tegeliku olekuga: versioonid, õigused, globaalsed väljalasked. Mida vähem me toetume ootel olevatele staatustele, seda prognoositavam on kogemus ja seda vähem on üllatusi pakettidega, mis näivad olevat kinni jäänud või ootamatult kadunud.
Järjestuse optimeerimine ja konfigureerimine avaldamise toimivuse parandamiseks
App-V sisaldab mitmesuguseid funktsioone, mis mõjutavad rakenduste avaldamise ja käivitamise toimingute toimimist. Teatud muudatused järjestamisfaasis võivad kiiretes võrgukeskkondades märgatavaid erinevusi tekitada.
Üks näide on funktsiooniploki 1 (FB1) eemaldamine . Kui FB1 (rakenduse käivitamiseks eelnevalt alla laaditavate failide minimaalne komplekt) pole määratletud, proovib rakendus kohe käivituda ja vajaliku faili lennult alla laadida. Kiirete võrkude puhul võib see esimest käivitamist kiirendada, kuid aeglaste võrkude puhul võib see põhjustada katkestusi või ootamist täiendava sisu voogesituse ajal.
Uue paketi loomisel sekventseriga jätke voogesituse etapis lihtsalt valik „Optimeeri paketti aeglaste võrkude jaoks” märkimata. Olemasolevate pakettide puhul saate paketti värskendada ilma seda optimeerimist valimata. Ideaalis tehke need testid kontrollitud keskkonnas ja taastage sekventser pärast alati puhta hetktõmmise olekusse.
Teine aspekt on kõrvutiasetsevate (SxS) assambleede, näiteks Visual C++ käituskeskkondade haldamine . Pakettide muutmiseks ei ole vaja neid uuesti järjestada: kui SxS-sõltuvused on kliendile juba installitud, siis App-V avaldamise ajal käivitatav MSI-installer ei käivitu, mis säästab aega. Liiga paljude SxS-assambleede lisamine paketti võib avaldamise ajal käivitada täiendavaid installimisi, mis mõjutab jõudlust.
Dünaamiliste konfiguratsioonifailide (juurutamine/kasutaja konfiguratsioon) kasutamisel on samuti mõju. App-V klient peab need failid parsima ja skripte käivitama või virtuaalse registri väljajätmisi/kaasamisi rakendama. Kui iga pakett sisaldab suuri konfiguratsioone, mõjutab see avaldamist. Nende kasutamine ainult seal, kus need pakuvad reaalset väärtust, ja nende keelamine pakettides, mis neid ei vaja, võib avaldamisaega oluliselt lühendada.
Lõpuks tasub üle vaadata pakettides sisalduvad virtuaalsed fondid . Kuigi tüüpiline pakett sisaldab tavaliselt kuni kakskümmend fonti, tähendab iga deklareeritud font juurutamise värskenduse ajal lisatööd. Mittevajalike virtuaalsete fontide keelamine dünaamilise konfiguratsiooni abil ja tegelikult vajalike fontide installimine pildil aitab paljude kasutajate puhul juurutamist lühendada.
Virtuaalsete masinate üldine jõudluse optimeerimine
Lisaks App-V-le on mitmeid levinud tavasid mis tahes virtuaalse masina jõudluse parandamiseks , olgu see siis töölaua-, labori- või tootmiskeskkonnas.
Esimene samm on veenduda, et riistvara virtualiseerimise laiendused, näiteks Intel VT-x või AMD-V , on hosti BIOS-is/UEFI-s lubatud. Ilma nendeta peab hüperviisor emuleerima rohkem toiminguid tarkvaras ja jõudlus langeb järsult.
Samuti on soovitatav valida dünaamiliste asemel fikseeritud suurusega virtuaalsed kettad . Kuigi kettad, mis täitudes kasvavad, on ruumi osas paindlikumad, kipuvad need killustuma ja pakuvad halvemat jõudlust. Kui hostil pole ruumipuudus probleemiks, tasub algusest peale reserveerida maksimaalne virtuaalse ketta suurus.
Salvestuskoht on veel üks kriitiline tegur. Võimaluse korral on kõige parem majutada virtuaalmasinaid kiiretel SSD-del, mitte mehaanilistel kõvaketastel või aeglastel välistel draividel. Jõudluse erinevus süsteemi käivitusaja, rakenduste käivitamise aja ja andmetele juurdepääsu osas on väga märgatav.
Ära unusta külalissüsteemidesse installida hüperviisori integratsioonitööriistu (Guest Additions, VMware Tools jne). Need lisavad optimeeritud draiverid video, võrgu, hiire ja salvestusruumi jaoks ning võimaldavad palju sujuvamat toimimist kui operatsioonisüsteemi üldised draiverid.
Lõpuks on soovitatav igale virtuaalmasinale eraldada piisavalt muutmälu ja protsessori tuuma , pidades meeles, et iga virtuaalmasin töötab tervikliku operatsioonisüsteemiga. Windows 7/10/11 süsteemide või praeguste Linuxi distributsioonide puhul on 2 GB väga range miinimum; praktikas parandab suurema mälu eraldamine oluliselt jõudlust. Sama kehtib ka protsessori tuumade kohta: kui hostil on palju tuumasid, on nende tark jaotamine aktiivsete virtuaalmasinate vahel oluline.
Füüsilised serverid vs virtualiseeritud keskkonnad: millal valida kumbagi varianti
Teenuste juurutamisel tekib alati küsimus, kas on parem valida virtuaalmasinad või spetsiaalsed füüsilised serverid . Ühest vastust pole: see sõltub töökoormusest, latentsuse kriitilisusest ning kulu- ja paindlikkuseesmärkidest.
Füüsilised (paljad metallserverid) pakuvad maksimaalset toorjõudlust ilma hüperviisori lisakoormuseta. Need on eelistatud valik väga suure jõudlusega tehinguandmebaaside, GPU-mahukate töökoormuste (tehisintellekt, 3D-renderdamine, täiustatud CAD) või reaalajas teenuste (mängud, tugevalt kodeeritud voogesitus) jaoks, kus iga millisekund on oluline.
Virtuaalmasinad seevastu säravad väga paindlikes ja skaleeritavates keskkondades . Veebiteenused, mikroteenused ja konteinerid , arendus- ja testimiskeskkonnad, virtuaalsed töölauad ja paljud ettevõtterakendused toimivad virtualiseeritud keskkondades suurepäraselt, võimaldades hetktõmmiseid, reaalajas migreerimist, kiiret varustamist ja tsentraliseeritud ressursside haldamist.
Litsentsimise ja kulude seisukohast võivad virtualiseeritud keskkonnad olla kallimad, kui kasutatakse kommertshüperviisoreid protsessori- või soklilitsentsidega, kuid need säästavad riistvara, ruumi ja energiatarbimist. Spetsiaalne füüsiline server seevastu võib olla litsentsimise seisukohast odavam, kuid ressursside kasutamisel vähem efektiivne, kui see majutab ainult mõnda rakendust.
Praktikas valivad paljud organisatsioonid hübriidse lähenemisviisi : füüsilised serverid kõige kriitilisemate ja jõudlustundlikemate töökoormuste jaoks ning virtualiseerimisklaster ülejäänud teenuste, sealhulgas rakenduste avaldamise platvormide ja VDI jaoks.
Stressitestid ja mõõdikud tulemuslikkuse hindamiseks
Teadlike otsuste langetamiseks ei piisa ainult intuitsioonist: on vaja ka mõõtmist. Protsessori, muutmälu, ketta ja võrgu koormustestid võimaldavad võrrelda virtualiseeritud keskkondi füüsiliste serveritega ning kontrollida, kas jõudluse langus on konkreetse rakenduse jaoks vastuvõetav.
Tööriistad nagu sysbench aitavad mõõta protsessori arvutusvõimsust (näiteks arvutades algarve teatud piirini), samas kui utiliidid nagu memtester või stress-ng võimaldavad teil hinnata mälu latentsust ja ribalaiust erinevates koormustingimustes.
Salvestusruumi puhul on spetsiaalsed tööriistad, näiteks fio , IOPS-i, läbilaskevõime ja latentsuse mõõtmise de facto standard erinevate juurdepääsumustrite (järjestikune lugemine/kirjutamine, juhuslik lugemine/kirjutamine ja mõlema kombinatsioonid) korral. Need tööriistad võimaldavad teil kvantifitseerida virtualiseerimiskihi ja kasutatava ketta serveri tüübi mõju.
Võrgu tasandil võimaldavad sellised utiliidid nagu iperf3, netperf ja ping mõõta füüsiliste hostide, virtuaalmasinate ja kaugklientide vahelist maksimaalset ribalaiust, keskmist latentsusaega ja värinat. Need andmed on eriti olulised stsenaariumides, mis hõlmavad graafiliste rakenduste või kõrge interaktsiooninõudega kaugtöölaudade avaldamist.
Nende mõõdikute kombineerimine reaalse pilootkasutaja kogemusega võimaldab disaini kohandada: alates RAM-i või protsessori täiendamisest teatud virtuaalmasinates kuni ketta asukohtade muutmiseni, samaaegsete App-V publikatsioonide maksimaalse suuruse muutmiseni või otsuseni, et teatud andmebaas peaks töötama füüsilisel hostil.
Eelnevat arvesse võttes võib hästi läbimõeldud rakenduste ja infrastruktuuri virtualiseerimine pakkuda väga tugevat tasakaalu jõudluse, paindlikkuse ja kulude vahel . Selliste tehnoloogiate nagu App-V, UE-V, KVM või kommertshüperviisorite kasutamine, füüsiliste serverite ja virtuaalmasinate hoolikas valimine vastavalt töökoormusele ning kriitiliste avaldamis- ja kasutajaprofiilide parameetrite peenhäälestamine võimaldab töötajatel nautida kiireid ja kõikjal kättesaadavaid rakendusi ilma, et aluseks olev keerukus muutuks ettevõtte kitsaskohaks.
