VDI-leverantörslåsning: Risker och lösningar

Introduktion

Virtuell skrivbordsinfrastruktur (VDI) förenklar centraliserad skrivbordshantering, men dess sammanlänkade komponenter kan göra plattformsbyten svåra. Från proprietära anslutningsmäklare till licensbegränsningar kan dessa beroenden begränsa IT-val och öka migrationskomplexiteten. Denna artikel undersöker orsakerna till och riskerna med VDI-leverantörslås, förklarar hur man kan minska dem och skisserar praktiska steg för att hålla leveransen av Windows-applikationer flexibel.

Vad är VDI-leverantörslåsning?

VDI-leverantörslåsning är en situation där en organisation blir extremt beroende av en specifik skrivbordsvirtualiseringsplattform till den punkt där det skulle vara extremt utmanande, kostsamt eller störande för företaget att byta leverantör.

VDI-komponenter som hypervisorer, anslutningsmäklare, skrivbordsbilder, användarprofiler, autentiseringssystem och andra hanteringsverktyg kombineras vanligtvis i VDI-miljöer. Men trots att de är separata kan de kräva specifik leverantörsdokumentation och konfiguration för att framgångsrikt interagera med varandra.

Anledningen är att, även om applikationer skrivna i Windows-språk vanligtvis fungerar överallt, kräver skrivbord som är byggda för en specifik VDI-miljö betydande tid för att omkonfigurera. Därför är leverantörslåsning inte ett oöverstigligt problem, men det skapar betydande hinder för organisationer som söker byta plattformar.

Vad orsakar en leverantörslåsning i VDI-miljöer?

VDI-leverantörslåsning orsakas sällan av en specifik teknisk begränsning. Det beror vanligtvis på flera beroenden av relaterad infrastruktur, hanteringsverktyg, licenser och applikationskonfigurationer.

Egendomliga anslutningsmäklare och hanteringsverktyg

Anslutningsmäklare ansvarar för att hantera användaranslutningar till virtuella skrivbord medan hanteringsverktyg används för att tillhandahålla, placera och underhålla skrivbord och applikationer. Verktyg som Citrix Virtual Apps and Desktops, Omnissa Horizon och Azure Virtual Desktop är byggda med olika hanteringsinfrastruktur och konfigurationstekniker.

Detta innebär att när man byter från en plattform till en annan kan det vara nödvändigt att omstrukturera skrivbordspooler, applikationer, anslutningar och automatiserade verktyg. Applikationerna själva kan hållas desamma, men deras implementering kommer att skilja sig beroende på den ursprungliga programvaran.

Hypervisor och infrastrukturberoenden

VDI-plattformar kräver infrastruktur som kan vara värd för och hantera virtuella skrivbord. Detta kan inkludera specifika hypervisorer, moln, lagring eller provisioning-teknologier.

Migreringsprocessen kan därför involvera flera uppgifter:

• Konvertera eller återskapa virtuella maskinbilder
• Omkonfigurera nätverk, lagring och resursallokering
• Ersätta leverantörsspecifika provisionsverktyg
• V Validering av applikationskompatibilitet och prestanda
• Återskapa tillgänglighet och katastrofåterställningsmekanismer

Dock sträcker sig inte alltid konceptet av portabilitet till skrivbordets leveransmiljö. Den framgångsrika migreringen av en virtuell maskin garanterar inte att den omgivande leveransmiljön kommer att fungera utan modifiering.

Licensiering och avtalsbegränsningar

VDI-implementationer kräver vanligtvis flera olika licenser – för operativsystem, virtualiseringsprodukter, användartillgångsrätt, hanteringsverktyg och tredjepartsapplikationer.

Leverantörer skiljer sig avsevärt när det gäller att paketera eller avpaketera dessa teknologier, vilket kan göra budgetplanering och övergång till nya infrastrukturer mer komplex.

Detta är särskilt viktigt när organisationer vill flytta från en VDI-stack till en annan, till exempel från lokal lösning till molnbaserad lösning, eftersom licensieringsmodellerna för operativsystem, användartillgångar och infrastrukturkonsumtion kan förändras dramatiskt.

Microsoft Learn-webbplatsen erbjuder en insikt i Azure Virtual Desktop-licensiering och hur det tillämpas på olika operativsystem och användningsfall.

Därför är det viktigt att analysera hela licensieringsstrukturen, inklusive konsekvenserna av eventuella avtalsenliga skyldigheter, när man fattar beslutet, inte bara abonnemangskostnaderna.

Applikations- och användarprofilberoenden

Windows-applikationer kan ha ett antal beroenden på operativsystemet, registret, drivrutiner, plats eller andra tjänster.

Dessa typer av applikationer virtualiseras vanligtvis i VDI-miljöer, med vissa aspekter av krav inbyggda i masterbilder eller införlivade i avancerade profilhanteringsverktyg. Vissa företag bygger och underhåller sina egna verktyg och skript för att möta sina specifika applikationsbehov i förhållande till resten av infrastrukturen.

I dessa situationer blir det extremt utmanande att separera applikationer från deras stödjande element, vilket medför betydande teknisk skuld och gör portabilitet extremt svårt.

Även om applikationen i sig är portabel, finns det fortfarande viktiga element, såsom installation, konfiguration, användarinställningar och databehandling som måste återställas i den nya miljön. Att förstå skillnaden mellan Windows-applikationspaketering och applikationspublicering kan hjälpa IT-team att separera krav för programvarudistribution från beroenden för applikationsleverans.

Vilka är riskerna med att ha en VDI-leverantörslåsning?

Leverantörsberoende medför särskilda svårigheter när en organisation måste ändra sin infrastrukturstrategi, anpassa sig till licensändringar eller anta nya teknologier för applikationsleverans.

De huvudsakliga riskerna rör kostnader, arkitektonisk flexibilitet och driftskontinuitet.

Ökande infrastruktur- och licenskostnader

Ett tätt kopplat VDI-miljö kan göra det svårt för en organisation att optimera sina infrastrukturkomponenter.

När licensvillkoren ändras eller kostnaden för infrastrukturen ökar kan det kräva ett storskaligt migrationsprojekt om de avser att byta leverantör. Detta kan skada deras förhandlingsposition och förmåga att optimera kostnader.

Dessutom kan tillhandahållandet av alla applikationer genom en fullständig virtuell skrivbord medföra onödig overhead för arbetsbelastningar som endast kräver en eller två fönsterapplikationer.

Applikationspublicering är på intet sätt billigare än VDI: ekonomin för de två tillvägagångssätten kommer att variera beroende på arbetsbelastningens densitet, de nödvändiga operativsystemen, infrastrukturens fotavtryck samt administrations- och hanteringskraven.

Minskad arkitektonisk flexibilitet

Organisationer som söker att anta en hybridinfrastruktur, ersätta åldrande servrar, byta mellan hostingleverantörer eller till och med anta nya leveransteknologier kan upptäcka att deras alternativ är begränsade av befintliga leverantörsspecifika beroenden.

En VDI-plattform som är nära kopplad till en infrastrukturstack kan kräva en fullständig omdesign av applikationer avsedda för leverans på andra stackar och värdtjänstleverantörer, vilket därmed fördröjer den digitala transformationsprocessen.

Ökad migrationskomplexitet

Övergångar mellan VDI-leverantörer handlar inte bara om migrering av virtuella maskiner.

Administratörer behöver också behålla autentisering, användarprofiler, applikationsinställningar, utskrift, filåtkomst, säkerhetspolicyer och sessionsbeteende.

Dålig dokumentation av dessa beroenden kan göra processen svårare att kvantifiera, testa och genomföra utan incidenter.

Större exponering för leverantörsförändringar

Produktavveckling, nya licensieringsmodeller, förändringar i support eller infrastrukturkrav kan kräva en förändring i distributionsstrategin.

Ju större beroendet av en enda distributionsplattform, desto högre blir den potentiella operativa påverkan av dessa förändringar på verksamheten.

Att bevara alternativa leveransalternativ kan mildra denna risk och skapa större flexibilitet när affärs- eller teknologibehov förändras.

Hur kan du minska riskerna med att ha en VDI-leverantörslåsning?

Att minska VDI-leverantörslåsning kräver en uppsättning tekniska, arbetsbelastningsrelaterade och arkitektoniska överväganden.

Idén är inte att undvika leverantörer, utan snarare att möjliggöra plattformsändringar utan att störa alla andra aspekter av applikationsleverans.

1. Granska befintliga VDI-beroenden

Det första steget är att identifiera vad som är avgörande för leveransen av applikationer och skrivbord, och vilka komponenter som är beroende av teknik som är specifik för leverantörer.

En beroendeinventering bör ta upp följande frågor:

Komponent	Frågor att undersöka
Anslutningsmäklare	Kan skrivbords- och applikationstilldelningar återskapas någon annanstans?
Hypervisor	Kan virtuella maskiner och bilder flyttas till alternativ infrastruktur?
Applikationer	Kräver applikationer specifika bilder, operativsystem eller drivrutiner?
Användarprofiler	Kan inställningar och data migrera oberoende?
Autentisering	Är identitetspolicys kopplade till proprietära integrationer?
Licensiering	Vilka åtaganden, åtkomsträttigheter och utträdeskostnader gäller?
Automation	Vilka skript är beroende av leverantörsspecifika API:er eller verktyg?

Inventeringen måste också inkludera applikationsägare, affärskritikalitet, återhämtningskrav och odokumenterade anpassningar.

Denna klassificering kan hjälpa IT-chefer att förstå vilka beroenden som enkelt kan bytas ut och vilka som kräver betydande omdesign.

2. Separera applikationsleverans från skrivbordsinfrastruktur

Ett av de bästa sätten att minska behovet av VDI är att säkerställa att varje applikation verkligen kräver en så omfattande lösning.

Medan VDI erbjuder virtuella skrivbord, tillhandahåller applikationspublicering fjärråtkomst till individuella applikationer utan att nödvändigtvis leverera en hel skrivbordsmiljö.

Båda metoderna centraliserar applikationer, men på olika sätt.

Krav	Full VDI	Sessionsbaserad applikationspublicering
Komplett personlig skrivbord	Väl lämpad	Inte det primära syftet
Individuella Windows-applikationer	Stödd	Väl lämpad
Dedikerad skrivbords-OS-isolering	Tillgänglig	Använder vanligtvis delade sessionsvärdar
Specialiserade skrivbordsinställningar	Ofta lämplig	Beroende på kompatibilitet
Centraliserad applikationshantering	Stödd	Stödd
Webbläsartillgång	Plattformsberoende	Tillgänglig med kompatibla lösningar
Leverans utan en fullständig VDI-stack	Inte allmänt	Möjlig.

Skillnaden är arkitektonisk, inte funktionell.

Många sådana VDI-system tillåter redan publicering av applikationer, så att tillåta publicering av applikationer hjälper dig inte nödvändigtvis att undvika leverantörslåsning, om inte dessa applikationer kan avkopplas från VDI-kontrollplanet.

Säg, till exempel, att du har en redovisningsavdelning som behöver åtkomst till en Windows-finansapplikation men inte behöver sina egna virtuella skrivbord. Genom att publicera applikationen på en Windows-dator (korrekt inställd) kan du undvika att alla måste använda VDI, samtidigt som du fortfarande håller applikationsadministrationen centraliserad.

Å andra sidan kan personer som behöver beständiga skrivbord, där varje användare har sin egen skrivbordssession, behöva full VDI.

3. Anta modulära och interoperabla arkitekturer

Modulära arkitekturer möjliggör utbyte av individuella element utan att störa den övergripande applikationsleveransmiljön.

IT-team bör prioritera följande där det är tillämpligt:

• Standardiserad identitet och autentisering
• Bärbar applikationskod och dokumenterade beroenden
• Användardata separerad från skrivbordsbilder
• Infrastruktur som kod: upprepningsbar distribution, automatisering
• Leverans som fungerar över slutpunkter och värdmiljöer

Observera att separationen av användardata från skrivbordsbilder kommer att förenkla både migreringar och katastrofåterställning: på samma sätt kommer infrastruktur som kod att hjälpa verksamheten att återskapa miljöer med bättre konsekvens.

Men även öppna standarder och automatisering kanske inte förhindrar leverantörslåsning: det finns ofta subtila skillnader i implementeringen mellan olika leverantörers teknologier, och skript kan innehålla anrop till proprietära API:er.

Därför är målet att undvika onödig koppling mellan applikations- och infrastrukturkomponenter, förvaltning och operativa komponenter.

4. Överväg hybrid applikationsleverans

Organisationer behöver inte välja mellan att behålla hela sin VDI-infrastruktur eller att ersätta den med något helt annat.

De skulle kunna anta en hybridstrategi som utnyttjar olika arbetsbelastningar enligt deras behov.

En organisation kan använda dedikerade skrivbord för kraftanvändare samtidigt som den värdar kompatibla affärsapplikationer på delade Windows-sessionvärdar.

De kunde också leverera äldre applikationer genom webbläsare. För Windows-programvara som inte lätt kan skrivas om, förståelse hur man publicerar Windows-programvara på webben kan hjälpa IT-team att utvärdera webbläsarbaserad leverans som en del av deras hybrida strategi.

Lokala applikationer behålls bäst när centralisering gör lite för att förbättra den övergripande prestandan.

En sådan strategi kommer att möjliggöra för IT-avdelningen att behålla befintliga investeringar i sin infrastruktur medan de övergår till nya teknologier i sin egen takt.

Utmaningen med denna metod är att den skapar ytterligare komplexitet och kräver mer omfattande identitetshantering, säkerhetsåtgärder som är enhetliga över alla plattformar, övervakningsregler och supportprocedurer.

5. Jämför den totala kostnaden för leveransmodeller

Licensbesparingar ensamma dikterar inte kostnadseffektiviteten hos en alternativ applikationsleveransarkitektur.

IT-team bör utvärdera den totala ägandekostnaden inklusive infrastruktur, programvarukostnader, administration, säkerhet och migrering.

Kostnadskategori	Utvärderingskriterier
Programvara	Licenser, prenumerationer, support och förnyelser
Infrastruktur	Beräkning, lagring, nätverk och molnanvändning
Operativsystem	Windows-licensiering och tillämpliga åtkomsträttigheter
Administration	Provisionering, underhåll, övervakning och felsökning
Säkerhet	MFA, åtkomstkontroller, granskning och säkerhetshantering
Migration	Testning, konfiguration, utbildning och implementering
Affärskontinuitet	Tillgänglighet, säkerhetskopiering, återställning och nedetidsexponering

Applikationspublicering kan minska behovet av specifika komponenter i en VDI-miljö, men den har sina egna distributions- och licenskrav.

Till exempel skulle traditionella Microsoft Remote Desktop Services (RDS) sessionhostingkonfigurationer kräva de lämpliga RDS-klientåtkomstlicenserna som beskrivs i Microsofts RDS CAL-dokumentation .

Licenskrav bör valideras baserat på den faktiska arkitekturen, leveransprodukten och relevanta Microsoft-villkor.

Målet bör vara att minimera totala kostnader samtidigt som man fortfarande levererar den säkerhet, prestanda och tillförlitlighet som krävs för att möta affärsbehoven.

Vad behöver du göra för att migrera bort från VDI-leverantörslåsning?

Att minska beroendet av leverantörer är mycket säkrare att göra gradvis snarare än att göra en fullständig ersättning av plattformen.

Fasad migration ger IT-team en möjlighet att bevisa alternativa leveransmetoder samtidigt som de upprätthåller status quo.

Steg 1: Klassificera applikationer efter leveranskrav

Börja med att gruppera applikationer baserat på deras tekniska beroenden och slutanvändarkrav. Tre breda kategorier är särskilt användbara för att identifiera:

• Applikationer som kräver fullständiga skrivbord – arbetsbelastningar som kräver en dedikerad OS-miljö, speciell konfiguration eller skrivbordsnivåisolering
• Applikationer som är lämpliga för fjärrpublicering – Windows-applikationer, kompatibla med stödda delade/ dedikerade session-värdmiljöer
• Applikationer som är lämpliga för lokal eller webbläsarnativ åtkomst – programvara som inte längre behöver köras inom en VDI-miljö.

En sådan klassificering kan hjälpa administratören att identifiera kandidater för alternativa leveransmodeller, som inte kräver betydande anpassningar.

Steg 2: Välj en låg-risk pilotarbetsbelastning

Välj en applikation med tydligt definierade resurskrav, få beroenden och en begränsad användarbas.

Undvik att börja med affärskritiska applikationer som är beroende av komplicerade perifera integrationer, unika drivrutiner eller sårbara äldre komponenter.

Piloten bör bevisa förmågan hos den alternativa infrastrukturen att på ett adekvat sätt återskapa viktiga funktioner och användarupplevelsen från den ursprungliga miljön.

Steg 3: Validera kompatibilitet, prestanda och säkerhet

Innan du skalar upp, testa funktioner och operativa egenskaper i realistiska miljöer.

Applikationsleveransmigreringsprojektet måste inkludera följande områden i testscenariot:

• Applikationsinstallation, beroenden och licensiering
• Autentisering, MFA och användartillstånd
• Användarprofiler, inställningar och filåtkomst
• Utskrift, urklipp och periferiredirektion
• Sessionskonkurrens och resursförbrukning
• Latens, responsivitet och återanslutning
• Loggning, övervakning och säkerhetspolicyer
• Säkerhetskopiering, återställning och återgångsprocedurer

Att lansera applikationer framgångsrikt garanterar inte full kompatibilitet.

Till exempel kan en applikation fungera bra på egen hand men misslyckas när flera användare försöker köra den samtidigt eller skriva ut dokument på skrivare.

IT-team måste utforma de nödvändiga testerna och prestandakriterierna för sessioner, applikationer, säkerhet och återställningsfunktioner.

Steg 4: Migrera applikationer i kontrollerade faser

När piloten uppfyller sina acceptanskriterier, skala upp distributionen baserat på affärsprioritet och teknisk komplexitet.

Behåll den ursprungliga leveransmiljön genom övergången när det är möjligt, vilket möjliggör för administratörer att jämföra prestanda, felsöka effektivt och återgå till etablerade processer om det behövs.

Dokumentera framgångskriterier, tilldela ansvar och fastställa återställningsprocedurer för varje fas av migreringen. Dessa åtgärder bidrar också till applikationsresiliens hjälpa organisationer att bevara viktiga affärsfunktioner under förändringar av infrastrukturen.

Steg 5: Granska återstående beroenden

Frågan om leverantörslåsning är inte begränsad till en enda instans.

Nya applikationer, behovet av att uppgradera plattformen, förändringar i licensiering eller operativ anpassning kan skapa ytterligare beroenden efter att migreringen är slutförd.

Därför behövs periodiska granskningar för att säkerställa att applikationer kan fortsätta att fungera på målplattformen, att konfigurationer har registrerats korrekt och att andra leveransmetoder förblir tillgängliga.

Detta kommer att göra det möjligt för den nya miljön att undvika att bli en annan leverantörslåsning.

I vilket fall är VDI den bra lösningen att behålla?

Att minska VDI-leverantörslåsning kräver inte en total ersättning av VDI.

VDI har ett legitimt värde för scenarier som involverar behovet av dedikerade operativsystem, beständiga skrivbord, grafikintensiva applikationer eller arbetsbelastningsisolering som delade sessionsvärdar inte kan tillhandahålla.

Det är också värdefullt för att leverera standardiserade, centralt hanterade skrivbord med konsekventa skrivbordshanteringspolicyer.

Beslutet att anta en annan arkitektur bör baseras på applikationens beteende, säkerhetsbehov, användarkrav och ekonomiska faktorer.

För de flesta organisationer är en distribuerad arkitektur mer praktisk än att tvinga alla applikationer in i samma leveransmodell.

Att behålla VDI för arbetsbelastningar som kräver det samtidigt som man använder oberoende applikationspublicering för andra arbetsbelastningar skulle möjliggöra att minska VDI-låsning utan att överge VDI:s funktioner.

Hur kan applikationsleverans förbli flexibel på lång sikt?

Den långsiktiga flexibiliteten hos ett system uppnås genom förmågan att behålla kontrollen över applikationsinfrastrukturrelationen och användartillgången.

Applikationer måste utformas på ett sätt som möjliggör deras fortsatta drift på potentiellt föränderliga infrastrukturvärdtjänster, hypervisorer eller skrivbordsvirtualiseringsplattformar.

Denna metod kräver noggrant fokus på korrekt dokumentation av beroenden, isolering av applikationsdata från dess leveransmekanismer, bevarande av reproducerbar konfiguration och kontinuerlig undersökning av alternativa metoder och konfigurationer.

Till exempel, medan en applikation som är skriven för Windows kan migreras för att köras på centralt hanterade Windows-servrar vid en ny organisation som använder olika hostingprogram eller hypervisorer, eller har ersatt sin VDI-brokeringprogramvara, indikerar det inte att applikationen är universellt transportabel.

Applikationer måste testas för sin förmåga att fungera på olika infrastrukturer, inklusive variationer i det grundläggande operativsystemet, lämplig licensiering, applikationsspecifik kompatibilitet eller prestandakarakteristika.

En användbar måttstock för flexibilitet är applikationens portabilitet mellan betydligt olika miljöer.

Om migrering av en applikation till en annan, men stödd, infrastruktur kräver omfattande omarbetning av orelaterade element på grund av närvaron av många beroenden, indikerar det att mycket arbete måste göras innan applikationen kan betraktas som portabel.

Denna mätning kan tillämpas iterativt för att gradvis öka flexibiliteten i en applikations infrastrukturbehov eller göra operativa justeringar utan att kräva en fullständig omarbetning av själva applikationen.

Letar du efter ett enklare sätt att leverera Windows-applikationer?

TSplus Remote Access erbjuder ett alternativ för organisationer som vill publicera Windows-applikationer och leverera fjärrskrivbord utan att implementera en traditionell full VDI-stack. Med applikationspublicering, HTML5-webbläsartillgång och stöd för Windows-miljöer som är värd på plats eller i molnet, hjälper det IT-team att diversifiera leveransalternativ samtidigt som de behåller centraliserad kontroll.

Slutsats

VDI-leverantörslåsning blir kostsamt när applikationer är beroende av tätt integrerad infrastruktur, licensiering och hanteringssystem. Att kartlägga dessa beroenden och införa alternativa leveransmetoder kan hjälpa organisationer att behålla kontrollen utan att helt överge VDI.

En flexibel arkitektur gör det möjligt för IT-team att behålla lämpliga arbetsbelastningar på virtuella skrivbord samtidigt som åtkomsten till andra förenklas, vilket minskar migrationsrisken och bevarar framtida alternativ.