VDI-leverandørbinding: Risici og løsninger

Introduktion

Virtuel Desktop Infrastruktur (VDI) forenkler centraliseret desktop administration, men dens sammenkoblede komponenter kan gøre det vanskeligt at skifte platforme. Fra proprietære forbindelsesformidlere til licensbegrænsninger kan disse afhængigheder begrænse IT-valgmuligheder og øge migrationskompleksiteten. Denne artikel undersøger årsagerne til og risiciene ved VDI-leverandørbinding, forklarer hvordan man kan reducere dem, og skitserer praktiske skridt til at holde Windows applikationslevering fleksibel.

Hvad er VDI-leverandørbinding?

VDI-leverandørbinding er en situation, hvor en organisation bliver ekstremt afhængig af en specifik desktop-virtualiseringsplatform til det punkt, hvor det ville være ekstremt udfordrende, dyrt eller forstyrrende for virksomheden at skifte leverandør.

VDI-komponenter såsom hypervisorer, forbindelsesbrokere, desktopbilleder, brugerprofiler, autentificeringssystemer og andre administrationsværktøjer kombineres normalt i VDI-miljøer. Men på trods af at de er adskilte, kan de kræve specifik leverandørdokumentation og konfiguration for at kunne interagere med hinanden.

Årsagen er, at selvom applikationer skrevet i Windows-sprog normalt fungerer overalt, kræver desktops bygget til et specifikt VDI-miljø betydelig tid til at omkonfigurere. Derfor er leverandørlåsning ikke et uovervindeligt problem, men det skaber betydelige forhindringer for organisationer, der ønsker at skifte platforme.

Hvad er årsagerne til en leverandørbinding i VDI-miljøer?

VDI-leverandørbinding skyldes sjældent en specifik teknisk begrænsning. Det skyldes normalt flere afhængigheder af relateret infrastruktur, administrationsværktøjer, licensering og applikationskonfigurationer.

Proprietære forbindelsesbrokere og administrationsværktøjer

Forbindelsesbrokere er ansvarlige for at administrere brugerforbindelser til virtuelle skriveborde, mens administrationsværktøjer bruges til at provisionere, placere og vedligeholde skriveborde og applikationer. Værktøjer som Citrix Virtual Apps and Desktops, Omnissa Horizon og Azure Virtual Desktop er bygget ved hjælp af forskellige administrationsinfrastrukturer og konfigurationsteknikker.

Dette indebærer, at når man skifter fra en platform til en anden, kan det være nødvendigt at omstrukturere desktop-pools, applikationer, forbindelser og automatiserede værktøjer. Applikationerne selv kan forblive de samme, men deres implementering vil variere afhængigt af den oprindelige software.

Hypervisor og infrastrukturafhængigheder

VDI-platforme kræver infrastruktur, der er i stand til at hoste og administrere virtuelle skriveborde. Dette kan inkludere specifik hypervisor, cloud, lagring eller provisioning-teknologier.

Migreringsprocessen kan derfor involvere flere opgaver:

• Konvertering eller genopbygning af virtuelle maskinebilleder
• Omkonfigurering af netværk, lagring og ressourceallokering
• Erstatning af leverandørspecifikke provisioning-værktøjer
• V Validering af applikationskompatibilitet og ydeevne
• Genskabelse af tilgængelighed og katastrofegenopretningsmekanismer

Dog konceptet om bærbarhed strækker sig ikke altid til desktop-leveringsmiljøet. Den vellykkede migration af en virtuel maskine sikrer ikke, at det omgivende leveringsmiljø vil fungere uden ændringer.

Licensering og kontraktlige begrænsninger

VDI-implementeringer kræver typisk flere forskellige licenser – til operativsystemer, virtualiseringsprodukter, brugeradgangsrettigheder, administrationsværktøjer og tredjepartsapplikationer.

Leverandører adskiller sig betydeligt med hensyn til at samle eller adskille disse teknologier, hvilket kan gøre budgetplanlægning og overgangen til nye infrastrukturer mere kompleks.

Dette er især vigtigt, når organisationer ønsker at flytte fra en VDI-stak til en anden, for eksempel fra on-premise til cloud-baseret løsning, fordi licensmodellerne for operativsystemer, brugerrettigheder og infrastrukturforbrug kan ændre sig dramatisk.

Microsoft Learn hjemmeside tilbyder en indsigt i Azure Virtual Desktop licensering og hvordan det gælder for forskellige operativsystemer og anvendelsesscenarier.

Derfor er det vigtigt at analysere hele licensstakken, herunder konsekvenserne af eventuelle kontraktlige forpligtelser, når man træffer beslutningen, ikke kun abonnementsomkostningerne.

Applikations- og brugerprofilafhængigheder

Windows-applikationer kan have en række afhængigheder af operativsystemet, registreringsdatabasen, drivere, placering eller andre tjenester.

Disse typer af applikationer virtualiseres ofte i VDI-miljøer, med visse aspekter af kravene indbygget i masterbilleder eller inkorporeret i avancerede profilhåndteringsværktøjer. Nogle virksomheder bygger og vedligeholder deres egne værktøjer og scripts for at imødekomme deres specifikke applikationsbehov i forhold til resten af infrastrukturen.

I disse situationer bliver det ekstremt udfordrende at adskille applikationer fra deres understøttende elementer, hvilket præsenterer betydelig teknisk gæld og gør portabilitet ekstremt vanskelig.

Selv hvis applikationen i sig selv er bærbar, er der stadig essentielle elementer, såsom installation, konfiguration, brugerindstillinger og datastyring, der skal genoprettes i det nye miljø. At forstå forskellen mellem Windows applikationspakke og applikationsudgivelse kan hjælpe IT-teams med at adskille krav til softwareudrulning fra afhængigheder ved applikationslevering.

Hvad er risiciene ved at have en VDI-leverandørbinding?

Leverandørafhængighed præsenterer særlige vanskeligheder, når en organisation skal ændre sin infrastrukturstrategi, tilpasse sig licensændringer eller adoptere nye applikationsleveringsteknologier.

De primære risici vedrører omkostninger, arkitektonisk fleksibilitet og driftskontinuitet.

Stigende infrastruktur- og licensomkostninger

Et tæt koblet VDI-miljø kan gøre det vanskeligt for en organisation at optimere deres infrastrukturkomponenter.

Når licensbetingelserne ændrer sig, eller omkostningerne til infrastruktur stiger, kan det nødvendiggøre et storskala migrationsprojekt, hvis de har til hensigt at skifte udbyder. Dette kan skade deres forhandlingsposition og evne til at optimere omkostningerne.

Desuden kan det at levere alle applikationer gennem et fuldt virtuelt skrivebord medføre unødvendig overhead for arbejdsbelastninger, der kun kræver en eller to vinduesapplikationer.

Applikationspublisering er på ingen måde billigere end VDI: økonomien i de to tilgange vil variere afhængigt af arbejdsbelastningernes tæthed, de nødvendige operativsystemer, infrastrukturens fodaftryk samt administrations- og ledelseskravene.

Reduceret arkitektonisk fleksibilitet

Organisationer, der søger at adoptere en hybrid infrastruktur, erstatte aldrende servere, skifte mellem hostingudbydere eller endda adoptere nye leverings teknologier, kan finde deres muligheder begrænsede af eksisterende leverandørspecifikke afhængigheder.

En VDI-platform, der er tæt knyttet til en infrastrukturstak, kan nødvendiggøre en fuldstændig redesign af applikationer, der er beregnet til levering på andre stakke og hostingudbydere, hvilket dermed bremser den digitale transformationsproces.

Øget migrationskompleksitet

VDI-leverandørovergange handler ikke kun om migrering af virtuelle maskiner.

Administratorer skal også bevare autentificering, brugerprofiler, applikationsindstillinger, udskrivning, filadgang, sikkerhedspolitikker og sessionsadfærd.

Dårlig dokumentation af disse afhængigheder kan gøre processen sværere at kvantificere, teste og udføre uden hændelser.

Større eksponering for leverandørændringer

Produktafbrydelse, nye licensmodeller, ændringer i support eller infrastrukturkrav kan nødvendiggøre en ændring i implementeringsstrategien.

Jo større afhængigheden er af en enkelt implementeringsplatform, desto højere er den potentielle operationelle indvirkning af disse ændringer på virksomheden.

At bevare alternative leveringsmuligheder kan mindske denne risiko og skabe større fleksibilitet, efterhånden som forretnings- eller teknologibehov ændrer sig.

Hvordan kan du reducere risiciene ved at have en VDI-leverandørbinding?

At reducere VDI-leverandørens lås kræver et sæt tekniske, arbejdsbyrde-relaterede og arkitektoniske overvejelser.

Ideen er ikke at undgå leverandører, men snarere at muliggøre platformændringer uden at forstyrre alle andre aspekter af applikationslevering.

1. Gennemgå eksisterende VDI-afhængigheder

Det første skridt er at identificere, hvad der er kritisk for leveringen af applikationer og skriveborde, og hvilke komponenter der er afhængige af teknologi, der er specifik for leverandører.

En afhængighedsinventar bør tage stilling til følgende spørgsmål:

Komponent	Spørgsmål at undersøge
Forbindelsesbroker	Kan desktop- og applikationstildelinger genskabes andre steder?
Hypervisor	Kan virtuelle maskiner og billeder flytte til alternativ infrastruktur?
Applikationer	Kræver applikationer specifikke billeder, operativsystemer eller drivere?
Brugerprofiler	Kan indstillinger og data migrere uafhængigt?
Godkendelse	Er identitetspolitikker knyttet til proprietære integrationer?
Licensering	Hvilke forpligtelser, adgangsrettigheder og udtrædelsesomkostninger gælder?
Automatisering	Hvilke scripts er afhængige af leverandørspecifikke API'er eller værktøjer?

Inventaret skal også omfatte applikationsejere, forretningskritikalitet, genopretningskrav og ikke-dokumenterede tilpasninger.

Denne klassifikation kan hjælpe IT-chefer med at forstå, hvilke afhængigheder der nemt kan erstattes, og hvilke der kræver betydelig redesign.

2. Adskil applikationslevering fra desktopinfrastruktur

En af de bedste metoder til at mindske behovet for VDI er at sikre, at hver applikation virkelig kræver en så omfattende løsning.

Mens VDI tilbyder virtuelle skriveborde, giver applikationspublisering fjernadgang til individuelle applikationer uden nødvendigvis at levere en hel desktop.

Begge metoder centraliserer applikationer, men på forskellige måder.

Krav	Fuldt VDI	Session-baseret applikationspublisering
Fuldstændig personlig tilpasset skrivebord	Godt egnet	Ikke det primære formål
Individuelle Windows-applikationer	Understøttet	Godt egnet
Dedikeret desktop OS-isolering	Tilgængelig	Generelt bruger delte sessionsværter
Specialiserede desktopkonfigurationer	Ofte egnet	Afhænger af kompatibilitet
Centraliseret applikationsstyring	Understøttet	Understøttet
Browser-baseret adgang	Platformafhængig	Tilgængelig med kompatible løsninger
Levering uden en fuld VDI-stak	Ikke generelt	Mulig

Forskellen er arkitektonisk, ikke funktionel.

Mange sådanne VDI-systemer tillader allerede publicering af applikationer, så tilladelse til publicering af applikationer hjælper dig ikke nødvendigvis med at undgå leverandørlåsning, medmindre disse applikationer kan adskilles fra VDI-kontrolplanet.

Sig for eksempel, at du har en regnskabsafdeling, der har brug for adgang til en Windows finansiel applikation, men ikke har brug for deres egne virtuelle skriveborde. Ved at offentliggøre applikationen på en Windows-maskine (korrekt opsat) kunne du undgå at skulle få alle til at bruge VDI, samtidig med at applikationsadministrationen forbliver centraliseret.

På den anden side kan folk, der har brug for vedholdende skriveborde, hvor hver bruger har deres egen skrivebordssession, have brug for fuld VDI.

3. Vedtag modulære og interoperable arkitekturer

Modulære arkitekturer muliggør udskiftning af individuelle elementer uden at forstyrre det overordnede applikationsleveringsmiljø.

IT-teams bør prioritere følgende, hvor det er relevant:

• Standardiseret identitet og autentificering
• Bærbar applikationskode og dokumenterede afhængigheder
• Brugerdata adskilt fra skrivebordsbilleder
• Infrastruktur som kode: gentagelig implementering, automatisering
• Levering, der fungerer på tværs af slutpunkter og hostingmiljøer

Bemærk, at adskillelse af brugerdata fra skrivebordsbilleder vil forenkle både migrationer og katastrofegenopretning: på samme måde vil infrastruktur som kode hjælpe driften med at genskabe miljøer med bedre konsistens.

Dog kan åbne standarder og automatisering ikke forhindre leverandørbinding: der er ofte subtile forskelle i implementeringen mellem forskellige leverandørers teknologier, og scripts kan indeholde opkald til proprietære API'er.

Derfor er målet at undgå unødvendig kobling mellem applikations- og infrastrukturkomponenter, ledelse og driftskomponenter.

4. Overvej hybrid applikationslevering

Organisationer behøver ikke at vælge mellem at bevare hele deres VDI-infrastruktur eller erstatte den med noget helt andet.

De kunne vedtage en hybridstrategi, der udnytter forskellige arbejdsbelastninger i henhold til deres behov.

En organisation kunne udnytte dedikerede skriveborde til powerbrugere, mens de hoster kompatible forretningsapplikationer på delte Windows-sessionværter.

De kunne også levere ældre applikationer gennem browsere. For Windows-software, der ikke nemt kan omskrives, forståelse hvordan man offentliggør Windows-software på nettet kan hjælpe IT-teams med at evaluere browserbaseret levering som en del af deres hybride strategi.

Lokale applikationer bevares bedst, når centralisering gør lidt for at forbedre den samlede ydeevne.

En sådan strategi vil gøre det muligt for IT-afdelingen at bevare eksisterende investeringer i deres infrastruktur, mens de overgår til nye teknologier i deres eget tempo.

Udfordringen med denne tilgang er, at den skaber yderligere kompleksitet og kræver mere omfattende identitetsstyring, sikkerhedsforanstaltninger, der er ensartede på tværs af alle platforme, overvågningsregler og supportprocedurer.

5. Sammenlign de samlede omkostninger ved leveringsmodeller

Licensbesparelser alene dikterer ikke omkostningseffektiviteten af en alternativ applikationsleveringsarkitektur.

IT-teams bør evaluere de samlede ejeromkostninger, herunder infrastruktur, softwareomkostninger, administration, sikkerhed og migration.

Omkostningskategori	Evalueringskriterier
Software	Licensering, abonnementer, support og fornyelser
Infrastruktur	Computing, opbevaring, netværk og cloud-forbrug
Operativsystemer	Windows-licensering og gældende adgangsrettigheder
Administration	Provisionering, vedligeholdelse, overvågning og fejlfinding
Sikkerhed	MFA, adgangskontroller, revision og sikkerhedsstyring
Migration	Test, konfiguration, træning og implementering
Forretningskontinuitet	Tilgængelighed, backup, gendannelse og nedetidseksponering

Applikationsudgivelse kan reducere behovet for specifikke komponenter i et VDI-miljø, men det har sine egne implementerings- og licenskrav.

For eksempel ville traditionelle Microsoft Remote Desktop Services (RDS) session hosting konfigurationer kræve de passende RDS Client Access Licenser som beskrevet i Microsoft's RDS CAL dokumentation .

Licenskrav skal valideres baseret på den faktiske arkitektur, leveringsprodukt og relevante Microsoft vilkår og betingelser.

Målet bør være at minimere de samlede omkostninger, samtidig med at der leveres den sikkerhed, ydeevne og pålidelighed, der er nødvendig for at imødekomme forretningsbehov.

Hvad skal du gøre for at migrere væk fra VDI-leverandørens lås?

At reducere afhængigheden af leverandører er meget sikrere at gøre gradvist snarere end at foretage en fuldstændig udskiftning af platformen.

Faseopgradering giver IT-teams en mulighed for at bevise alternative leveringsmetoder, samtidig med at status quo opretholdes.

Trin 1: Klassificer applikationer efter leveringskrav

Begynd med at gruppere applikationer baseret på deres tekniske afhængigheder og slutbrugerkrav. Tre brede kategorier er især nyttige til at identificere:

• Applikationer, der kræver fulde skriveborde – arbejdsbelastninger, der kræver et dedikeret OS-miljø, særlig konfiguration eller isolering på skrivebordsniveau
• Applikationer velegnede til fjernpublisering – Windows-applikationer, der er kompatible med understøttede delte/ dedikerede session-vært miljøer
• Applikationer, der er egnede til lokal eller browser-nativ adgang – software, der ikke længere kræver at blive kørt inden for et VDI-miljø

En sådan klassificering kan hjælpe administratoren med at identificere kandidater til alternative leveringsmodeller, som ikke kræver betydelige tilpasninger.

Trin 2: Vælg en lavrisiko pilotarbejdsmængde

Vælg en applikation med klart definerede ressourcekrav, få afhængigheder og en begrænset brugerbase.

Undgå at starte med forretningskritiske applikationer, der er afhængige af komplicerede perifere integrationer, unikke drivere eller sårbare legacy-komponenter.

Piloten skal bevise evnen til den alternative infrastruktur til tilstrækkeligt at replikere essentielle funktioner og brugeroplevelsen fra det oprindelige miljø.

Trin 3: Valider kompatibilitet, ydeevne og sikkerhed

Før du skalerer op, skal du teste funktioner og driftsfunktioner i realistiske miljøer.

Applikationsleveringsmigrationsprojektet skal inkludere følgende områder i testsituationen:

• Applikationsinstallation, afhængigheder og licensering
• Godkendelse, MFA og brugerrettigheder
• Brugerprofiler, indstillinger og filadgang
• Udskrivning, udklipsholder og perifere omdirigering
• Sessionskonkurrence og ressourceforbrug
• Latency, responsivitet og genforbindelse
• Logging, overvågning og sikkerhedspolitikker
• Backup, gendannelse og tilbageførsel procedurer

At lancere applikationer med succes garanterer ikke fuld kompatibilitet.

For eksempel kan en applikation fungere fint alene, men fejle, når flere brugere forsøger at køre den samtidig eller udskrive dokumenter på printere.

IT-teams skal designe de nødvendige tests og præstationskriterier for sessioner, applikationer, sikkerhed og rollback-funktioner.

Trin 4: Migrer applikationer i kontrollerede faser

Når piloten opfylder sine acceptkriterier, skal implementeringen skaleres op baseret på forretningsprioritet og teknisk kompleksitet.

Behold den oprindelige leveringsmiljø gennem overgangen, når det er muligt, så administratorer kan sammenligne ydeevne, fejlfinde effektivt og vende tilbage til etablerede processer, hvis det er nødvendigt.

Dokumenter succeskriterier, tildel ansvar og etabler tilbageføringsprocedurer for hver fase af migrationen. Disse foranstaltninger bidrager også til applikationsmodstandsdygtighed hjælpe organisationer med at bevare essentielle forretningsfunktioner under infrastrukturændringer.

Trin 5: Gennemgå resterende afhængigheder

Problemet med leverandørbinding er ikke begrænset til en enkelt instans.

Nye applikationer, behovet for at opgradere platformen, ændringer i licensering eller operationel tilpasning kan skabe yderligere afhængigheder, efter at migrationen er afsluttet.

Derfor er periodiske gennemgange nødvendige for at sikre, at applikationer kan fortsætte med at fungere på den målrettede platform, at konfigurationer er blevet korrekt registreret, og at andre leveringsmetoder forbliver tilgængelige.

Dette vil gøre det muligt for det nye miljø at undgå at blive en anden leverandørlås.

I hvilket tilfælde er VDI den gode løsning at bevare?

At reducere VDI-leverandørens låsning kræver ikke en total udskiftning af VDI.

VDI har legitim værdi for scenarier, der involverer behovet for dedikerede operativsystemer, vedholdende skriveborde, grafikintensive applikationer eller arbejdsbyrdeisolering, som delte sessionsværter ikke kan levere.

Det er også værdifuldt for at levere standardiserede, centralt styrede skriveborde med ensartede skrivebordshåndteringspolitikker.

Beslutningen om at vedtage en anden arkitektur bør baseres på applikationsadfærd, sikkerhedsbehov, brugerkrav og økonomiske faktorer.

For de fleste organisationer er en distribueret arkitektur mere praktisk end at tvinge alle applikationer ind i den samme leveringsmodel.

At bevare VDI til arbejdsbelastninger, der kræver det, mens man bruger uafhængig applikationspublisering til andre arbejdsbelastninger, ville muliggøre reduktion af VDI-låsning uden at opgive VDI's funktioner.

Hvordan kan applikationslevering forblive fleksibel på lang sigt?

Den langsigtede fleksibilitet i et system opnås gennem evnen til at bevare kontrollen over forholdet mellem applikationsinfrastruktur og brugeradgang.

Applikationer skal designes på en måde, der muliggør deres fortsatte drift på potentielt skiftende infrastruktur, hostingudbydere, hypervisorer eller desktopvirtualiseringsplatforme.

Denne tilgang kræver nøje opmærksomhed på korrekt dokumentation af afhængigheder, isolering af applikationsdata fra dens leveringsmekanismer, opbevaring af reproducerbar konfiguration og kontinuerlig undersøgelse af alternative tilgange og konfigurationer.

For eksempel, mens en applikation skrevet til Windows muligvis kan migreres til at køre på centralt administrerede Windows-servere i en ny organisation, der bruger anden hostingsoftware eller hypervisorer, eller har erstattet deres VDI-brokeringssoftware, indikerer det ikke, at applikationen er universelt transportabel.

Applikationer skal testes for deres evne til at fungere på forskellige infrastrukturer, herunder variationer i det grundlæggende operativsystem, passende licensering, applikationsspecifik kompatibilitet eller ydeevneegenskaber.

En nyttig måling for fleksibilitet er applikationens portabilitet mellem betydeligt forskellige miljøer.

Hvis migrering af en applikation til en anden, men understøttet, infrastruktur kræver omfattende omarbejdning af urelaterede elementer på grund af tilstedeværelsen af mange afhængigheder, indikerer det, at der skal gøres meget arbejde, før applikationen kan betragtes som bærbar.

Denne måling kan anvendes iterativt for gradvist at øge fleksibiliteten i en applikations infrastrukturbehov eller foretage operationelle justeringer uden at kræve en fuldstændig omarbejdning af selve applikationen.

Leder du efter en enklere måde at levere Windows-applikationer på?

TSplus Remote Access giver et alternativ for organisationer, der ønsker at publicere Windows-applikationer og levere fjernskrivbord uden at implementere en traditionel fuld VDI-stak. Med applikationspublisering, HTML5-browseradgang og support til Windows-miljøer, der hostes lokalt eller i skyen, hjælper det IT-teams med at diversificere leveringsmulighederne, samtidig med at de bevarer centraliseret kontrol.

Konklusion

VDI-leverandørens låsning bliver kostbar, når applikationer afhænger af tæt integreret infrastruktur, licensering og administrationssystemer. Kortlægning af disse afhængigheder og introduktion af alternative leveringsmetoder kan hjælpe organisationer med at bevare kontrollen uden at opgive VDI helt.

En fleksibel arkitektur gør det muligt for IT-teams at holde passende arbejdsbelastninger på virtuelle skriveborde, samtidig med at adgangen til andre forenkles, hvilket reducerer migrationsrisikoen og bevarer fremtidige muligheder.