Applikationsvirtualisering och prestanda: en komplett guide för att få ut det mesta av din infrastruktur

Informatec Digital » Resurser » Applikationsvirtualisering och prestanda: en komplett guide för att få ut det mesta av din infrastruktur

Enkelt uttryckt innebär virtualisering att skapa virtuella versioner av fysiska resurser (servrar, lagring, nätverk eller applikationer) för att köra flera miljöer på samma hårdvara. Denna möjlighet att "uppdela" en fysisk server i flera logiska instanser är grunden för molntjänster och de flesta moderna datacenter.

En virtuell maskin (VM) är ett isolerat system med sin egen virtuella processor, minne, lagring och nätverk, byggt från en värds fysiska resurser. Varje virtuell maskin beter sig som om den vore en oberoende dator och är vanligtvis inkapslad i en eller flera filer, vilket gör den relativt enkel att flytta, kopiera och återställa.

Komponenten som gör allt detta möjligt är hypervisorn eller VMM (Virtual Machine Monitor). Dess funktion är att separera värdens fysiska resurser (CPU, RAM, disk, nätverk) och allokera dem till de olika virtuella maskiner som behöver dem, kontrollera deras användning och isolera dem från varandra så att ett fel i en virtuell maskin inte påverkar resten av systemet.

Det finns två huvudtyper av hypervisorer . Typ 1 (bare metal) körs direkt på serverns hårdvara och är vanlig i datacenter och privata moln. Typ 2 installeras som en applikation ovanpå ett värdoperativsystem (till exempel en stationär hypervisor för att köra flera virtuella maskiner på en bärbar dator).

I Linux-ekosystemet är KVM (Kernel-based Virtual Machine) särskilt relevant , en typ 1-hypervisor integrerad i kärnan som gör det möjligt för virtuella maskiner att dra nytta av Linux prestanda och funktioner, med mycket detaljerad kontroll över CPU, minne och enheter.

Vad är applikationsvirtualisering och hur skiljer det sig från servervirtualisering?

Applikationsvirtualisering separerar applikationen från sitt operativsystem så att programmet körs utan att faktiskt installeras på användarens enhet. Applikationen "tror" att den kommunicerar med operativsystemet, men i verkligheten kommunicerar den med ett mellanliggande lager (app-hypervisor eller isoleringsteknik) som omdirigerar åtkomst till filer, registret och andra resurser.

Vanligtvis körs dessa applikationer på en central server (i ett datacenter eller molnet) och levereras via ett nätverk (LAN eller internet) till användarens enhet. För slutanvändaren verkar applikationen vara inbyggd, men den publiceras eller virtualiseras i en kontrollerad miljö.

Till skillnad från servervirtualisering, som fungerar på nivån av hela operativsystemet , fungerar applikationsvirtualisering på nivån av enskilda program : ett Word-dokument, ett CRM, ett ERP-system, ett designverktyg etc. Detta förenklar hantering, isolering och uppdateringar avsevärt, men introducerar prestandautmaningar relaterade till nätverk, lagring och användarprofiler.

Fördelar med applikationsvirtualisering för användare, IT och företag

Ur slutanvändarens perspektiv är den största fördelen friheten. De kan använda sin föredragna enhet (företagets bärbara dator, persondator, tunn klient, surfplatta) och komma åt företagsapplikationer utan att behöva oroa sig för att installera, uppdatera eller underhålla någonting. För dem är det nästan sömlöst att byta enhet: de loggar in och har sina genvägar redo att användas.

För IT-administratörer är applikationsvirtualisering en betydande lättnad. Istället för att driftsätta och uppdatera programvara på hundratals eller tusentals datorer installerar och underhåller de applikationen på en eller några få servrar och släpper den till behöriga användare. Detta centraliserar hanteringen på en plats och gör det mycket snabbare att implementera patchar, versionsändringar, säkerhetskonfigurationer och policyer.

Utvecklare drar också nytta av det. De kan ha olika virtualiserade miljöer på samma system för att testa kod på olika operativsystemversioner eller programvarukombinationer, utan att behöva sätta upp komplexa fysiska labb. Dessutom tillåter isoleringen som virtualiseringslagret ger dem att öppna potentiellt korrupta eller farliga filer utan att kompromettera värdsystemet.

För organisationen som helhet underlättar applikationsvirtualisering initiativ som BYOD (Bring Your Own Device) , minskar behovet av att köpa kraftfulla företagsenheter, förenklar supporten och leder vanligtvis till betydande besparingar i dubbla licenser, supporttimmar och tidiga hårdvaruförnyelser.

En viktig punkt är regelefterlevnad . Eftersom känsliga data inte finns på användarens enhet (utan i datacentret eller molnet) är det lättare att följa regler som HIPAA eller PCI-DSS, eftersom attackytan minskas och åtkomstkontroll och granskning centraliseras.

Virtualiseringens inverkan på prestanda: CPU, RAM, disk och nätverk

Virtualisering introducerar alltid en viss resursbelastning eftersom ett extra lager uppstår mellan applikationen och hårdvaran (hypervisorn, publiceringsmotorn, fjärrklienten etc.). Även om denna belastning vanligtvis är liten om plattformen är rätt dimensionerad, är det värt att förstå var den är mest märkbar.

På CPU- nivå visar benchmarktester att en typisk virtuell maskin som körs på KVM eller VMware vSphere uppnår mellan 5 % och 7,5 % lägre prestanda än samma system som körs direkt på bare metal-hårdvara. Denna skillnad är acceptabel för de flesta företagsapplikationer (kontorspaket, webbapplikationer, ERP), men den kan vara avgörande för beräkningsintensiva uppgifter, AI eller 3D-rendering.

I DDR4- kontra DDR5-RAM kan den effektiva hastigheten minska med cirka 7–13 % på grund av den extra hantering som hypervisorn kräver. I mycket krävande miljöer kräver detta antingen överdimensionering av minnet eller begränsning av antalet virtuella maskiner per värd för att förhindra flaskhalsar.

Den mest märkbara skillnaden är i lagring (IOPS) . Tester med verktyg som fio visar prestandaminskningar på cirka 17–25 % vid slumpmässiga läs-/skrivoperationer i 4K jämfört med samma disk i bare metal. Att välja NVMe-arrayer, högpresterande SSD-diskar, cacheminnen och en bra design för delad lagring är avgörande för att virtuella maskiner och virtualiserade applikationer ska köras smidigt.

Nätverkslatensen kan också öka, särskilt när många virtuella maskiner delar samma fysiska gränssnitt eller när grafikintensiv eller videotung trafik flyttas mellan fjärrsessioner. Nätverksdesign (VLAN, QoS, bandbredd, avlastning) och användningen av effektiva grafikpubliceringsprotokoll gör en betydande skillnad för användarupplevelsen.

Windows-, App-V- och VDI/RDS-miljöer: prestanda i praktiken

I moderna Windows-miljöer (Windows 7 SP1, Windows 10, Windows 11, Windows Server 2012 R2 och 2016) är applikationsvirtualisering med Microsoft App-V en av de viktigaste teknikerna för att leverera applikationer i RDS-scenarier (Remote Desktop Services) och VDI-infrastrukturer.

I dessa miljöer arbetar användare vanligtvis på icke-persistenta maskiner (virtuella maskiner eller RDSH-värdar som ofta regenereras). För att säkerställa att användare kan komma åt sina virtuella applikationer inom några sekunder efter inloggning är det avgörande att optimera App -V-klienten , profilhanteringslösningen och själva basavbildningen.

Användarupplevelsen beror på flera sammankopplade intervall: tiden från det att användaren anger sina inloggningsuppgifter tills de kan interagera med skrivbordet, tiden därifrån tills App-V-publiceringsuppdateringen börjar, uppdateringens varaktighet och slutligen den tid det tar för den virtuella programgenvägen eller filassociationen att bli tillgänglig.

Att optimera dessa tider innebär att kombinera App-V-konfigurationer ( läge för delat innehållslagring , gränser för samtidig publicering, bevarande av användarintegrationer), en bra profileringslösning (UE-V eller annan UPM) och en grundläggande avbildningsstrategi utformad enligt huvudmålet: maximal prestanda eller maximala lagringsbesparingar.

Användningsfall: prestandaorienterad metod kontra lagring

Vi kan gruppera App-V-distributioner i icke-persistenta, tillståndskänsliga VDI/RDSH-miljöer i två stora extrema scenarier, med vetskapen om att många företag i praktiken hamnar någonstans mittemellan: ett optimerat för prestanda och det andra fokuserat på att minska lagringsförbrukningen.

I ett prestandaorienterat scenario innehåller basavbildningen några eller alla relevanta virtuella applikationspaket, såväl som deras anslutningsgrupper. Detta innebär ytterligare avbildningsförberedelse och underhåll, men det erbjuder den bästa användarupplevelsen: applikationer verkar praktiskt taget redo från det ögonblick en användare loggar in.

Den lagringsorienterade metoden undviker att inkludera användarspecifika paket i basavbildningen, vilket förhindrar att delade diskarrayer blir överfulla med data som många användare kanske inte behöver. Denna metod prioriterar att minska storleken på virtuella maskinavbildningar, på bekostnad av att vissa konfigurationsåtgärder flyttas till inloggningstiden, vilket ökar den tid det tar för vissa applikationer att bli tillgängliga något.

I praktiken är det vanligt att tillämpa prestandametoden på en delmängd av kritiska användare eller paket (t.ex. kundtjänstpersonal eller flitigt använda affärsapplikationer) och lagringsmetoden på tillfälliga användare eller applikationer som är mindre känsliga för starttid.

Förbereda miljön och basavbildningen för App-V

För att applikationsvirtualisering i VDI eller RDSH ska fungera smidigt måste baslösningen för avbildning och profilhantering (UE-V eller annan UPM) förberedas korrekt. Ett fel i detta skede resulterar vanligtvis i oändliga inloggningar, förlorade integrationer eller onödiga dubbletter av publikationer.

I prestandametoden inkluderar viktiga steg att aktivera den systemintegrerade App-V-klienten , aktivera UE-V (eller en motsvarande lösning) med App-V-konfigurationsmallen, konfigurera läget för delat innehållslagringsläge (SCS) för att endast behålla publiceringsdata på disk och ställa in registret för att behålla användarintegrationer vid inloggning.

Dessutom måste alla globala och användaranslutningspaket och grupper vara förkonfigurerade (med kommandon som Add-AppvClientPackage och Add-AppvClientConnectionGroup), och globala paket måste vara förpublicerade. I vissa fall rekommenderas det att utföra globala och användaranslutnings-/uppdateringscykler, avpublicera användarmålpaket och rensa upp VFS-poster i profiler (till exempel i AppData\Local och AppData\Roaming relaterade till App-V).

I den lagringsorienterade metoden är förberedelserna liknande, men endast globala anslutningsgrupper och paket är förkonfigurerade. Användarspecifika paket utelämnas från basavbildningen för att undvika att öka storleken och diskanvändningen för de virtuella maskinerna.

Dessutom är det viktigt att förstå att IT-administrationen regelbundet behöver uppdatera basavbildningen för att återspegla ändringar i paketversioner, säkerhetsuppdateringar och nya åtkomsträttigheter. I vissa miljöer kommer det att vara nödvändigt att hantera flera olika avbildningar för olika användarprofiler.

Kritiska prestandaparametrar i App-V-klienten

Inom App-V-klienten finns flera registerinställningar som direkt påverkar publiceringshastigheten och belastningen på CPU, disk och nätverk, särskilt på RDS-värdar med många samtidiga användare.

I läget Shared Content Store (SCS) kan endast publiceringsmetadata lagras på den lokala disken, medan resten av programmets resurser laddas på begäran från ett centralt arkiv (SAN, innehållsserver). Detta sparar lokal IOPS och minskar diskutrymme, förutsatt att det finns en nätverksanslutning med låg latens till innehållsservern.

Alternativet PreserveUserIntegrationsOnLogin förhindrar att klienten demonterar och återintegrerar användarintegrationer från paket som inte är förkonfigurerade vid inloggning. Om den här nyckeln inte är aktiverad och det finns många okonfigurerade användarpaket kan varje inloggning resultera i dubbelpublicering för varje paket, vilket avsevärt påverkar inloggningstiden.

En annan viktig parameter är MaxConcurrentPublishingRefresh , som definierar hur många användare som kan utlösa en publiceringsuppdatering samtidigt. Att lämna den utan en gräns på en RDS-server kan orsaka mycket höga CPU-toppar när många användare loggar in samtidigt. Ett rimligt värde mildrar dessa toppar, till kostnaden att vissa användare, i scenarier med stora vågor av inloggningar, kan uppleva något längre väntetider för att se nya publicerade applikationer.

Hantering av användarprofiler: UE-V och andra UPM-lösningar

För att virtuella applikationer ska kunna starta nästan omedelbart i icke-persistenta miljöer är det viktigt att lösningen för hantering av användarprofiler underhåller och tillämpar korrekta "användarintegrationer" mellan sessioner: registernycklar, genvägar, startmenyer, App-V-kataloger etc.

Microsofts User Experience Virtualization (UE-V) är starkt fokuserad på VDI- och RDS-scenarier. Den samlar in och lagrar användarinställningar och tillämpar dem automatiskt när användaren loggar in på en annan enhet eller session. För App-V kan UE-V arbeta med specifika mallar som samlar in exakt de register- och filsökvägar där integrationer lagras.

En viktig egenhet är hanteringen av .lnk-filer (genvägar). UE-V stöder endast borttagning av .lnk-tillägget från listan över undantagna filer i scenarier där alla användarenheter har samma uppsättning program installerade i samma sökväg. Om detta villkor inte är uppfyllt (till exempel om ett program är installerat på endast en dator eller i en annan sökväg) kan synkronisering av .lnk-filer resultera i trasiga genvägar.

När man använder andra UPM-lösningar (användarprofildiskar, tredjepartsprodukter) är det avgörande att de kan: bevara angivna användarintegrationer (loggar och mappar), synkronisera profilen vid lämplig tidpunkt (inloggning eller programstart, före App-V-publicering) och registrera ändringar på dessa platser före utloggning.

I App-V introducerades verktyget SyncAppvPublishingServer.exe för att ge profileringslösningar en tydlig utlösare: det initierar användarens publiceringsuppdatering vid inloggning, men tillåter att den fördröjs tills profilen har laddats helt. Detta förhindrar att App-V publicerar till en ofullständig eller föråldrad profil.

Handledning för användarupplevelse: vad som händer vid varje inloggning

Genom att titta på flödet steg för steg kan vi bättre förstå hur applikationsvirtualisering uppfattas i användarnas vardag, beroende på om vi använder en prestanda- eller lagringsmetod.

I prestandametoden utlöser den första inloggningen till en icke-persistent VDI/RDSH en användarpublicering eller uppdatering. Om det är första gången användaren har tagit emot virtuella applikationer tar åtgärden den vanliga tiden. När den är klar registrerar profileringslösningen användarintegrationer, vanligtvis vid utloggning, med en effekt som liknar att spara resten av användarens tillstånd.

I de inledande skedena tillämpar UPM-lösningen först alla användarintegrationer innan App-V börjar uppdatera publiceringsprocessen. Användare ser genvägarna på skrivbordet eller Start-menyn från början, och många av dem fungerar omedelbart. Om det inte sker några ändringar i behörigheterna slutförs publiceringsprocessen på några sekunder. När det sker ändringar ökar tiden beroende på antalet och komplexiteten hos de virtualiserade applikationerna.

Genom att bevara 100 % av användarintegrationerna minimeras belastningen under publiceringen : systemet justerar bara behörighets- eller versionsändringar, och applikationerna är redo på mycket kort tid från inloggning.

I den lagringsbaserade metoden startar den första inloggningen även användarpublikationen, med normal varaktighet. Men både vid den första inloggningen och vid efterföljande inloggningar kan behovet av att förkonfigurera (lägga till eller uppdatera) användarpaket förlänga applikationens tillgänglighet. Det är vanligt att lägga till 10 sekunder eller mer, beroende på paketens volym och komplexitet.

I det här fallet måste publicerings- och uppdateringsprocesserna omkonfigurera alla virtuella applikationer vid varje inloggning, vilket oundvikligen förlänger publiceringsuppdateringsfasen. Detta sparar diskutrymme men offrar en del av inloggningshastigheten.

App-V-paketets livscykel och väntande tillstånd

Att hantera livscykeln för App-V-paket påverkar också prestanda och konsekvensen hos de versioner som användarna ser. När en administratör uppdaterar ett paket, ändrar behörigheter eller avpublicerar program kan dessa åtgärder förbli väntande om paketet används.

Från och med App-V 5.0 SP2 introducerades väntande tillstånd . Istället för att misslyckas markeras publicerings- eller avpubliceringsåtgärder som slutförda vid nästa omstart av App-V-tjänsten eller när ett publicerings-/avpubliceringskommando utfärdas igen. För globalt publicerade paket kräver detta vanligtvis en omstart av servern eller klienttjänsten.

I icke-persistenta miljöer kan dessa väntande uppgifter aldrig bearbetas eftersom maskiner kasseras eller återskapas innan villkoren är uppfyllda. Väntande uppgifter lagras i användarprofilen (till exempel under HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\PendingTasks), och om profileringslösningen inte tillämpar den här nyckeln före inloggning kommer operationerna att lämnas i limbo.

Därför är det så viktigt att hålla grundbilden i linje med paketens faktiska tillstånd: versioner, rättigheter, globala utgåvor. Ju mindre vi förlitar oss på väntande status, desto mer förutsägbar blir upplevelsen, och desto färre överraskningar blir det med paket som verkar ha fastnat eller försvinner oväntat.

Sekvenseringsoptimering och konfiguration för att förbättra publiceringsprestanda

App-V innehåller olika funktioner som påverkar hur applikationspublicering och startåtgärder fungerar. Vissa justeringar under sekvenseringsfasen kan göra märkbara skillnader i nätverksmiljöer med hög hastighet.

Ett exempel är borttagningen av funktionsblock 1 (FB1) . Om FB1 (den minsta uppsättning filer som förladdas ner för att starta applikationen) inte är definierad, kommer appen att försöka starta omedelbart och ladda ner det den behöver direkt. På höghastighetsnätverk kan detta påskynda den första starten, men på långsamma nätverk kan det orsaka avbrott eller väntetider medan ytterligare innehåll strömmas.

När du skapar ett nytt paket med sequencern, lämna helt enkelt alternativet "Optimera paket för långsamma nätverk" avmarkerat under streamingsteget. För befintliga paket kan du uppdatera paketet utan att välja denna optimering. Helst bör du utföra dessa tester i en kontrollerad miljö och alltid återställa sekvenseringsmaskinen till en ren ögonblicksbild efteråt.

En annan aspekt är hanteringen av SxS-sammansättningar (Side-by-Side) , till exempel Visual C++-körtider. Det är inte nödvändigt att ändra sekvensen på paket för att ändra dem: om SxS-beroenden redan är installerade på klienten kommer MSI-installationsprogrammet som App-V kan starta under publicering inte att köras, vilket sparar tid. Att inkludera för många SxS-sammansättningar i paketet kan utlösa ytterligare installationer under publicering, vilket påverkar prestandan.

Användningen av dynamiska konfigurationsfiler (distribution/användarkonfiguration) har också en inverkan. App-V-klienten måste analysera dessa filer och köra skript eller tillämpa virtuella registerundantag/inkluderingar. Om varje paket innehåller stora konfigurationer kommer publiceringen att påverkas. Att bara använda dem där de ger verkligt värde och inaktivera dem i paket som inte behöver dem kan avsevärt minska publiceringstiden.

Slutligen är det värt att granska de virtuella teckensnitt som ingår i paketen. Även om ett typiskt paket vanligtvis inte innehåller mer än tjugo, innebär varje deklarerat teckensnitt extra arbete under distributionsuppdateringen. Att inaktivera onödiga virtuella teckensnitt genom dynamisk konfiguration och istället installera de teckensnitt som faktiskt behövs direkt i avbildningen hjälper till att spara sekunder på distributioner med många användare.

Allmän prestandaoptimering i virtuella maskiner

Utöver App-V finns det ett antal vanliga metoder för att förbättra prestandan för alla virtuella maskiner , oavsett om det är i skrivbords-, labb- eller produktionsmiljöer.

Det första steget är att säkerställa att virtualiseringstillägg för hårdvara, som Intel VT-x eller AMD-V , är aktiverade i värdens BIOS/UEFI. Utan dem måste hypervisorn emulera fler operationer i programvaran, och prestandan kommer att försämras kraftigt.

Det är också lämpligt att välja virtuella diskar med fast storlek framför dynamiska. Diskar som växer allt eftersom de fylls upp är mer flexibla vad gäller utrymme, men de tenderar att bli mer fragmenterade och ge sämre prestanda. Om utrymme på värden inte är ett problem är det värt att reservera den maximala virtuella diskstorleken från början.

Lagringsplats är en annan kritisk faktor. När det är möjligt är det bäst att hosta virtuella maskiner på snabba SSD-diskar snarare än mekaniska hårddiskar eller långsamma externa enheter. Prestandaskillnaden i systemstarttid, programstarttider och dataåtkomst är mycket märkbar.

Glöm inte att installera hypervisor- integrationsverktygen (Guest Additions, VMware Tools, etc.) på gästsystemen. Dessa lägger till optimerade drivrutiner för video, nätverk, mus och lagring, och möjliggör mycket smidigare drift än med operativsystemets generiska drivrutiner.

Slutligen är det lämpligt att allokera tillräckligt med RAM och CPU-kärnor till varje virtuell maskin, med tanke på att varje virtuell maskin kör ett komplett operativsystem. För Windows 7/10/11-system eller nuvarande Linux-distributioner är 2 GB ett mycket snävt minimum; i praktiken förbättrar allokering av mer minne prestandan avsevärt. Detsamma gäller CPU-kärnor: om värden har många kärnor kommer det att göra skillnad att fördela dem klokt mellan de aktiva virtuella maskinerna.

Fysiska servrar kontra virtualiserade miljöer: när man ska välja varje alternativ

När man driftsätter tjänster uppstår alltid frågan om det är bättre att välja virtuella maskiner eller dedikerade fysiska servrar . Det finns inget entydigt svar: det beror på arbetsbelastningen, hur kritisk latensen är och kostnads- och flexibilitetsmålen.

Fysiska (bare metal) servrar erbjuder maximal rå prestanda utan den overhead som en hypervisor kräver. De är det bästa valet för transaktionsdatabaser med mycket hög prestanda, GPU-intensiva arbetsbelastningar (AI, 3D-rendering, avancerad CAD) eller realtidstjänster (spel, kraftigt kodad streaming) där varje millisekund räknas.

Virtuella maskiner, å andra sidan, glänser i mycket flexibla och skalbara miljöer . Webbtjänster, mikrotjänster och containrar , utvecklings- och testmiljöer, virtuella skrivbord och många företagsapplikationer presterar utmärkt i virtualiserade miljöer, vilket möjliggör ögonblicksbilder, livemigreringar, snabb provisionering och centraliserad resurshantering.

Ur ett licens- och kostnadsperspektiv kan virtualiserade miljöer bli dyrare om kommersiella hypervisorer med licenser per CPU eller per socket används, men de sparar på hårdvara, utrymme och energiförbrukning. En dedikerad fysisk server kan å andra sidan vara billigare att licensiera, men mindre effektiv i sin resursanvändning om den bara är värd för ett fåtal applikationer.

I praktiken väljer många organisationer en hybridmetod : fysiska servrar för de mest kritiska och prestandakänsliga arbetsbelastningarna och ett virtualiseringskluster för resten av tjänsterna, inklusive plattformar för applikationspublicering och VDI.

Stresstester och mätvärden för att utvärdera prestanda

För att fatta välgrundade beslut räcker det inte med intuition: du måste mäta. Stresstester av CPU, RAM, disk och nätverk låter dig jämföra virtualiserade miljöer med fysiska servrar och validera om prestandaförsämringen är acceptabel för en specifik applikation.

Verktyg som sysbench hjälper till att mäta processorns beräkningskapacitet (till exempel genom att beräkna primtal upp till en viss gräns), medan verktyg som memtester eller stress-ng låter dig utvärdera minneslatens och bandbredd under olika belastningsförhållanden.

För lagring är specialiserade verktyg som fio de facto standarden för att mäta IOPS, dataflöde och latens med olika åtkomstmönster (sekventiell läsning/skrivning, slumpmässig läsning/skrivning och kombinationer av båda). Dessa verktyg låter dig kvantifiera effekten av virtualiseringslagret och vilken typ av diskbackend som används.

På nätverksnivå kan verktyg som iperf3, netperf och ping mäta maximal bandbredd, genomsnittlig latens och jitter mellan fysiska värdar, virtuella maskiner och fjärrklienter. Denna data är särskilt relevant i scenarier som involverar publicering av grafiska applikationer eller fjärrskrivbord med höga interaktionskrav.

Genom att kombinera dessa mätvärden med verkliga användarupplevelser från pilotprojekt kan designjusteringar göras: från att uppgradera RAM eller CPU till vissa virtuella maskiner till att ändra diskplatser, modifiera den maximala storleken på samtidiga App-V-publikationer eller bestämma att en viss databas ska köras på en fysisk värd.

Mot bakgrund av ovanstående kan väl utformad applikations- och infrastrukturvirtualisering erbjuda en mycket stark balans mellan prestanda, flexibilitet och kostnad . Genom att utnyttja tekniker som App-V, UE-V, KVM eller kommersiella hypervisorer, noggrant välja mellan fysiska servrar och virtuella maskiner baserat på arbetsbelastning, och finjustera kritiska publicerings- och användarprofilparametrar kan anställda dra nytta av snabba, var som helst tillgängliga applikationer utan att den underliggande komplexiteten blir en flaskhals i verksamheten.