VDI dobavljačka zaključanost: Rizici i rješenja

Uvod

Virtualna desktop infrastruktura (VDI) pojednostavljuje centralizirano upravljanje radnim površinama, ali njezini međusobno povezani sastavni dijelovi mogu otežati prelazak na druge platforme. Od vlasničkih posrednika za povezivanje do ograničenja licenciranja, ove ovisnosti mogu ograničiti IT izbore i povećati složenost migracije. Ovaj članak ispituje uzroke i rizike zaključavanja dobavljača VDI-a, objašnjava kako ih smanjiti i opisuje praktične korake za održavanje fleksibilne isporuke Windows aplikacija.

Što je zaključavanje dobavljača VDI?

VDI vendor lock-in je situacija kada organizacija postane izuzetno ovisna o specifičnoj platformi za virtualizaciju radnih površina do te mjere da bi promjena dobavljača bila izuzetno izazovna, skupa ili ometajuća za tvrtku.

VDI komponente kao što su hipervizori, posrednici za povezivanje, slike radne površine, korisnički profili, sustavi autentifikacije i drugi alati za upravljanje obično se kombiniraju u VDI okruženjima. Međutim, unatoč tome što su odvojeni, mogu zahtijevati specifičnu dokumentaciju i konfiguraciju dobavljača kako bi uspješno međusobno surađivali.

Razlog je taj što, iako aplikacije napisane na Windows jeziku obično rade bilo gdje, radne površine izgrađene za specifično VDI okruženje zahtijevaju značajno vrijeme za ponovnu konfiguraciju. Stoga, zaključavanje dobavljača nije nepremostiv problem, ali stvara značajne prepreke za organizacije koje žele promijeniti platforme.

Koji su uzroci zaključavanja dobavljača u VDI okruženjima?

Zaključavanje VDI dobavljača rijetko je uzrokovano jednim specifičnim tehničkim ograničenjem. Obično proizlazi iz višestrukih ovisnosti o povezanoj infrastrukturi, alatima za upravljanje, licenciranju i konfiguracijama aplikacija.

Proprietarni posrednici veze i alati za upravljanje

Brokers veze odgovorni su za upravljanje korisničkim vezama na virtualne radne površine, dok se alati za upravljanje koriste za opskrbu, postavljanje i održavanje radnih površina i aplikacija. Alati poput Citrix Virtual Apps and Desktops, Omnissa Horizon i Azure Virtual Desktop izgrađeni su koristeći različitu infrastrukturu za upravljanje i tehnike konfiguracije.

To znači da prilikom prelaska s jedne platforme na drugu može biti potrebno restrukturirati desktop bazene, aplikacije, veze i automatizirane alate. Same aplikacije mogu ostati iste, međutim, njihova implementacija će se razlikovati ovisno o početnom softveru.

Hipervizor i ovisnosti o infrastrukturi

VDI platforme zahtijevaju infrastrukturu sposobnu za hostanje i upravljanje virtualnim radnim površinama. To može uključivati specifične hipervizore, cloud, pohranu ili tehnologije opskrbe.

Migracijski proces može stoga uključivati nekoliko zadataka:

• Pretvaranje ili obnavljanje slika virtualnih strojeva
• Ponovno konfiguriranje umrežavanja, pohrane i dodjele resursa
• Zamjena alata za opskrbu specifičnih dobavljača
• V Provjera kompatibilnosti aplikacija i performansi
• Ponovno uspostavljanje mehanizama dostupnosti i oporavka od katastrofa

Međutim, koncept prenosivosti ne odnosi se uvijek na okruženje isporuke radne površine. Uspješna migracija virtualne mašine ne osigurava da će okolno okruženje isporuke funkcionirati bez izmjena.

Licenciranje i ugovorne restrikcije

Implementacije VDI obično zahtijevaju nekoliko različitih licenci – za operacijske sustave, proizvode virtualizacije, prava pristupa korisnika, alate za upravljanje i aplikacije trećih strana.

Dobavljači se značajno razlikuju u pogledu pakiranja ili raspakiranja ovih tehnologija, što može učiniti planiranje proračuna i prijelaz na nove infrastrukture složenijim.

Ovo je posebno važno kada organizacije žele preći s jednog VDI stoga na drugi, na primjer, s lokalnog na rješenje temeljeno na oblaku, jer se modeli licenciranja za operativne sustave, prava korisnika i potrošnja infrastrukture mogu dramatično promijeniti.

Microsoft Learn web stranica pruža jedan uvid u licenciranje Azure Virtual Desktopa i kako se to primjenjuje na različite operacijske sustave i slučajeve upotrebe.

Stoga je važno analizirati cijeli licencni paket, uključujući implikacije bilo kakvih ugovornih obveza, prilikom donošenja odluke, a ne samo troškove pretplate.

Ovisnosti aplikacije i korisničkog profila

Windows aplikacije mogle bi imati niz ovisnosti o operativnom sustavu, registru, upravljačkim programima, lokaciji ili drugim uslugama.

Ove vrste aplikacija obično se virtualiziraju u VDI okruženjima, s određenim aspektima zahtjeva ugrađenim u glavne slike ili uključeni u napredne alate za upravljanje profilima. Neke tvrtke razvijaju i održavaju vlastite alate i skripte kako bi zadovoljile specifične potrebe svojih aplikacija u odnosu na ostatak infrastrukture.

U tim situacijama postaje izuzetno izazovno odvojiti aplikacije od njihovih podržavajućih elemenata, što predstavlja značajan tehnički dug i čini prenosivost izuzetno teškom.

Čak i ako je sama aplikacija prenosiva, još uvijek postoje bitni elementi, kao što su instalacija, konfiguracija, korisničke postavke i upravljanje podacima koje će trebati ponovno uspostaviti u novom okruženju. Razumijevanje razlike između Pakiranje Windows aplikacija i objavljivanje aplikacija može pomoći IT timovima da odvoje zahtjeve za implementaciju softvera od ovisnosti o isporuci aplikacija.

Koji su rizici vezivanja za VDI dobavljača?

Ovisnost o dobavljaču predstavlja posebne poteškoće kada organizacija mora promijeniti svoju infrastrukturalnu strategiju, prilagoditi se promjenama licenci ili usvojiti nove tehnologije isporuke aplikacija.

Glavni rizici odnose se na troškove, arhitektonsku fleksibilnost i operativnu kontinuitet.

Rastući troškovi infrastrukture i licenci

Usko povezano VDI okruženje može otežati organizaciji optimizaciju svojih infrastrukturnih komponenti.

Kada se uvjeti licenciranja promijene ili troškovi infrastrukture porastu, to može zahtijevati projekt migracije velikih razmjera ako namjeravaju promijeniti dobavljače. To može naštetiti njihovoj pregovaračkoj poziciji i sposobnosti optimizacije troškova.

Osim toga, pružanje svih aplikacija putem punog virtualnog radnog stola može uzrokovati nepotrebno opterećenje za radne zadatke koji zahtijevaju samo jednu ili dvije aplikacije za prozore.

Objavljivanje aplikacija ni na koji način nije jeftinije od VDI-ja: ekonomija ova dva pristupa varirat će ovisno o gustoći radnih opterećenja, potrebnim operativnim sustavima, infrastrukturi i zahtjevima za administraciju i upravljanje.

Smanjena arhitektonska fleksibilnost

Organizacije koje žele usvojiti hibridnu infrastrukturu, zamijeniti zastarjele poslužitelje, prelaziti između pružatelja usluga ili čak usvojiti nove tehnologije isporuke mogu otkriti da su im opcije ograničene postojećim ovisnostima o dobavljačima.

VDI platforma koja je usko povezana s jednim infrastrukturnim stogom može zahtijevati potpunu redizajn aplikacija namijenjenih isporuci na drugim stogovima i pružateljima hostinga, čime se usporava proces digitalne transformacije.

Povećana složenost migracije

Prelazi VDI dobavljača nisu samo o migraciji virtualnih strojeva.

Administratori također trebaju zadržati autentifikaciju, korisničke profile, postavke aplikacija, ispis, pristup datotekama, sigurnosne politike i ponašanje sesije.

Loša dokumentacija ovih ovisnosti može otežati proces kvantificiranja, testiranja i izvršavanja bez incidenata.

Veće izloženosti promjenama dobavljača

Prekid proizvoda, novi modeli licenciranja, promjene u podršci ili zahtjevi za infrastrukturom mogu zahtijevati promjenu strategije implementacije.

Što je veće oslanjanje na jednu platformu implementacije, to je veći potencijalni operativni utjecaj ovih promjena na poslovanje.

Očuvanje alternativnih opcija isporuke može ublažiti ovaj rizik i stvoriti veću fleksibilnost kako se poslovne ili tehnološke potrebe mijenjaju.

Kako možete smanjiti rizike od zaključavanja kod VDI dobavljača?

Smanjenje zaključavanja dobavljača VDI-a zahtijeva skup tehničkih, radnih i arhitektonskih razmatranja.

Ideja nije izbjegavati dobavljače, već omogućiti promjene platforme bez ometanja svih drugih aspekata isporuke aplikacija.

1. Revizija postojećih VDI ovisnosti

Prvi korak je identificirati što je ključno za isporuku aplikacija i radnih površina, te koji su komponenti ovisni o tehnologiji specifičnoj za dobavljače.

Inventar ovisnosti trebao bi obuhvatiti sljedeća pitanja:

Komponenta	Pitanja za istraživanje
Posrednik veze	Mogu li se dodjele radne površine i aplikacija ponovno stvoriti negdje drugdje?
Hipervizor	Mogu li se virtualne mašine i slike premjestiti na alternativnu infrastrukturu?
Aplikacije	Zahteva li aplikacije specifične slike, operativne sisteme ili drajvere?
Korisnički profili	Mogu li se postavke i podaci migrirati neovisno?
Autentifikacija	Jesu li politike identiteta povezane s vlasničkim integracijama?
Licenciranje	Koje obveze, prava pristupa i troškovi izlaska se primenjuju?
Automatizacija	Koji skripti ovise o API-ima ili alatima specifičnim za dobavljače?

Inventar mora također uključivati vlasnike aplikacija, poslovnu kritičnost, zahtjeve za oporavak i nedokumentirane prilagodbe.

Ova klasifikacija može pomoći IT menadžerima da razumiju koje su ovisnosti lako zamjenjive, a koje zahtijevaju značajno redizajniranje.

2. Odvojite isporuku aplikacija od infrastrukture radne površine

Jedna od najboljih metoda za smanjenje potrebe za VDI-jem je osigurati da svaka aplikacija zaista zahtijeva takvo složeno rješenje.

Dok VDI nudi virtualne radne površine, objavljivanje aplikacija pruža udaljeni pristup do pojedinačnih aplikacija bez nužnog isporučivanja cijelog radnog površine.

Obje metode centraliziraju aplikacije, ali na različite načine.

Zahtjev	Puni VDI	Objavljivanje aplikacija temeljenih na sesijama
Potpuno personalizirani radna površina	Dobro prilagođeno	Nije primarna svrha
Jedinstvene Windows aplikacije	Podržano	Dobro prilagođeno
Izolacija namjenskog radnog sustava	Dostupno	Općenito koristi zajedničke hosts sesija
Specijalizirane desktop konfiguracije	Često prikladno	Ovisi o kompatibilnosti
Centralizirano upravljanje aplikacijama	Podržano	Podržano
Pristup putem preglednika	Platforma ovisna	Dostupno s kompatibilnim rješenjima
Isporuka bez punog VDI stoga	Ne općenito	Moguće

Razlika je arhitektonska, a ne funkcionalna.

Mnogi takvi VDI sustavi već omogućuju objavljivanje aplikacija, pa omogućavanje objavljivanja aplikacija ne pomaže nužno u izbjegavanju zaključavanja od strane dobavljača, osim ako se te aplikacije ne mogu odvojiti od VDI kontrolne ravnine.

Recimo, na primjer, da imate računovodstveni odjel koji treba pristup Windows financijskoj aplikaciji, ali ne treba vlastite virtualne radne površine. Objavljivanjem aplikacije na Windows računalu (ispravno postavljenom), mogli biste izbjeći potrebu da svi koriste VDI, a istovremeno zadržati centraliziranu administraciju aplikacije.

S druge strane, ljudi koji trebaju trajne radne površine, gdje svaki korisnik ima svoju vlastitu sesiju radne površine, možda će trebati puni VDI.

3. Usvojite modularne i interoperabilne arhitekture

Modularne arhitekture omogućuju zamjenu pojedinačnih elemenata bez ometanja cjelokupnog okruženja isporuke aplikacija.

IT timovi trebaju dati prioritet sljedećem gdje je primjenjivo:

• Standardizirani identitet i autentifikacija
• Prijenosni kod aplikacije i dokumentirane ovisnosti
• Podaci korisnika odvojeni od slika radne površine
• Infrastruktura kao kod: ponovljivo implementiranje, automatizacija
• Dostava koja radi na svim krajnjim točkama i okruženjima za hosting

Napomena da će odvajanje korisničkih podataka od slika radne površine pojednostaviti i migracije i oporavak od katastrofa: slično tome, infrastruktura kao kod pomoći će operacijama da ponovno kreiraju okruženja s boljom dosljednošću.

Međutim, čak i otvoreni standardi i automatizacija možda neće spriječiti zaključavanje dobavljača: često postoje suptilne razlike u implementaciji između tehnologija različitih dobavljača, a skripte mogu sadržavati pozive na vlasničke API-je.

Stoga je cilj izbjeći nepotrebno povezivanje između aplikacijskih i infrastrukturnih komponenti, upravljačkih i operativnih komponenti.

4. Razmotrite hibridnu isporuku aplikacija

Organizacije ne moraju birati između zadržavanja cijele svoje VDI infrastrukture ili njezine potpune zamjene nečim drugim.

Mogli bi usvojiti hibridnu strategiju koja koristi različite radne opterećenja prema svojim potrebama.

Organizacija bi mogla koristiti namjenske radne površine za moćne korisnike dok hosta kompatibilne poslovne aplikacije na zajedničkim Windows sesijskim poslužiteljima.

Mogli bi također isporučiti naslijeđene aplikacije putem preglednika. Za Windows softver koji se ne može lako prepisati, razumijevanje kako objaviti Windows softver na webu može pomoći IT timovima da procijene isporuku temeljenu na pregledniku kao dio svoje hibridne strategije.

Lokalne aplikacije najbolje se zadržavaju kada centralizacija malo poboljšava ukupne performanse.

Takva strategija omogućit će IT odjelu da zadrži postojeća ulaganja u svoju infrastrukturu dok prelaze na nove tehnologije vlastitim tempom.

Izazov s ovim pristupom je u tome što stvara dodatnu složenost i zahtijeva sveobuhvatno upravljanje identitetom, sigurnosne mjere jedinstvene za sve platforme, pravila nadzora i postupke podrške.

5. Usporedite ukupne troškove modela isporuke

Uštede na licencama same po sebi ne određuju isplativost alternativne arhitekture isporuke aplikacija.

IT timovi trebaju procijeniti ukupne troškove vlasništva uključujući infrastrukturu, troškove softvera, administraciju, sigurnost i migraciju.

Kategorija troškova	Kriteriji ocjenjivanja
Softver	Licenciranje, pretplate, podrška i obnavljanja
Infrastruktura	Računanje, pohrana, umrežavanje i potrošnja u oblaku
Operacijski sustavi	Licenciranje sustava Windows i primjenjiva prava pristupa
Administracija	Provisioniranje, održavanje, nadzor i rješavanje problema
Sigurnost	MFA, kontrole pristupa, revizija i upravljanje sigurnošću
Migracija	Testiranje, konfiguracija, obuka i implementacija
Kontinuitet poslovanja	Dostupnost, sigurnosna kopija, oporavak i izloženost prekidu rada

Objavljivanje aplikacija može smanjiti potrebu za specifičnim komponentama u VDI okruženju, ali ima svoje vlastite zahtjeve za implementaciju i licenciranje.

Na primjer, tradicionalne konfiguracije hostinga sesija Microsoft Remote Desktop Services (RDS) zahtijevale bi odgovarajuće RDS klijentske pristupne licence kako je opisano u Dokumentacija RDS CAL-a tvrtke Microsoft .

Zahtjevi za licenciranje trebaju se provjeriti na temelju stvarne arhitekture, proizvoda isporuke i relevantnih Microsoftovih uvjeta i odredbi.

Cilj bi trebao biti minimiziranje ukupnih troškova uz istovremeno pružanje sigurnosti, performansi i pouzdanosti potrebnih za zadovoljavanje poslovnih potreba.

Što biste trebali učiniti da se migrirate s VDI dobavljačkog zaključavanja?

Smanjenje ovisnosti o dobavljačima mnogo je sigurnije raditi postupno nego napraviti potpunu zamjenu platforme.

Postupna migracija pruža IT timovima priliku da dokažu alternativne metode isporuke dok održavaju status quo.

Korak 1: Klasificirajte aplikacije prema zahtjevima isporuke

Započnite grupiranjem aplikacija na temelju njihovih tehničkih ovisnosti i zahtjeva krajnjih korisnika. Tri široke kategorije posebno su korisne za identifikaciju:

• Aplikacije koje zahtijevaju potpune radne površine – radni opterećenja koja zahtijevaju namjensko OS okruženje, posebnu konfiguraciju ili izolaciju na razini radne površine
• Aplikacije prikladne za udaljeno objavljivanje – Windows aplikacije, kompatibilne s podržanim dijeljenim/posvećenim okruženjima za host sesije
• Aplikacije prikladne za lokalni ili preglednički pristup – softver koji više ne zahtijeva pokretanje unutar VDI okruženja

Takva klasifikacija može pomoći administratoru da identificira kandidate za alternativne modele isporuke, koji ne zahtijevaju značajne prilagodbe.

Korak 2: Odaberite pilot opterećenje s niskim rizikom

Odaberite aplikaciju s jasno definiranim zahtjevima za resursima, malo ovisnosti i ograničenom korisničkom bazom.

Izbjegavajte započinjanje s poslovno kritičnim aplikacijama koje ovise o složenim perifernim integracijama, jedinstvenim upravljačkim programima ili ranjivim naslijeđenim komponentama.

Pilot bi trebao dokazati sposobnost alternativne infrastrukture da adekvatno replicira bitne funkcije i korisničko iskustvo izvorne okoline.

Korak 3: Potvrdite kompatibilnost, performanse i sigurnost

Prije povećanja, testirajte funkcije i operativne značajke u realnim okruženjima.

Projekt migracije isporuke aplikacija mora uključivati sljedeća područja u testnom scenariju:

• Instalacija aplikacije, ovisnosti i licenciranje
• Autentifikacija, MFA i korisničke dozvole
• Korisnički profili, postavke i pristup datotekama
• Ispis, međuspremnik i preusmjeravanje perifernih uređaja
• Istovremenost sesija i potrošnja resursa
• Kašnjenje, odziv i ponovna povezanost
• Zapisivanje, praćenje i sigurnosne politike
• Sigurnosne kopije, obnova i postupci vraćanja

Pokretanje aplikacija uspješno ne jamči potpunu kompatibilnost.

Na primjer, aplikacija može raditi dobro sama, ali može zakazati kada nekoliko korisnika pokuša pokrenuti je u isto vrijeme ili ispisivati dokumente na pisačima.

IT timovi moraju dizajnirati potrebne testove i kriterije izvedbe za sesije, aplikacije, sigurnost i značajke vraćanja.

Korak 4: Migrirajte aplikacije u kontroliranim fazama

Jednom kada pilot ispuni svoje kriterije prihvaćanja, povećajte implementaciju na temelju poslovnog prioriteta i tehničke složenosti.

Zadržite izvorno okruženje isporuke tijekom prijelaza kada je to moguće, omogućujući administratorima da uspoređuju performanse, učinkovito rješavaju probleme i se vrate na utvrđene procese ako je potrebno.

Dokumentirajte kriterije uspjeha, dodijelite odgovornosti i uspostavite postupke vraćanja za svaku fazu migracije. Ove mjere također doprinose otpornost aplikacije pomažući organizacijama da očuvaju bitne poslovne funkcije tijekom promjena infrastrukture.

Korak 5: Pregled preostalih ovisnosti

Problem zaključavanja dobavljača nije ograničen na jedan slučaj.

Nove aplikacije, potreba za nadogradnjom platforme, promjene u licenciranju ili prilagodbi rada mogu stvoriti dodatne ovisnosti nakon što migracija završi.

Stoga su potrebne periodične revizije kako bi se osiguralo da aplikacije mogu nastaviti raditi na ciljnoj platformi, da su konfiguracije ispravno zabilježene i da su dostupna druga sredstva isporuke.

To će omogućiti novom okruženju da izbjegne postati još jedan zaključani dobavljač.

U kojem slučaju je VDI dobro rješenje za zadržavanje?

Smanjenje zaključavanja dobavljača VDI ne zahtijeva potpuno zamjenjivanje VDI-a.

VDI ima legitimnu vrijednost za scenarije koji uključuju potrebu za namjenskim operativnim sustavima, trajnim radnim površinama, aplikacijama koje zahtijevaju intenzivnu grafiku ili izolaciju radnog opterećenja koju zajednički sesijski poslužitelji ne mogu pružiti.

Također je vrijedno za isporuku standardiziranih, centralno upravljanih radnih površina s dosljednim politikama upravljanja radnom površinom.

Odluka o usvajanju drugačije arhitekture trebala bi se temeljiti na ponašanju aplikacije, sigurnosnim potrebama, zahtjevima korisnika i ekonomskim faktorima.

Za većinu organizacija, distribuirana arhitektura je praktičnija od prisiljavanja svih aplikacija u isti model isporuke.

Zadržavanje VDI-a za radne opterećenja koja to zahtijevaju, dok se koristi neovisno objavljivanje aplikacija za druga radna opterećenja, omogućilo bi smanjenje zaključavanja VDI-a bez napuštanja mogućnosti VDI-a.

Kako može isporuka aplikacija ostati fleksibilna na duži rok?

Dugoročna fleksibilnost sustava postiže se sposobnošću zadržavanja kontrole nad odnosom aplikacijske infrastrukture i pristupom korisnicima.

Aplikacije moraju biti projektirane na način koji omogućava njihovo neprekidno funkcioniranje na potencijalno promjenjivoj infrastrukturi pružatelja usluga, hipervizorima ili platformama za virtualizaciju radnih površina.

Ovaj pristup zahtijeva pažljivo praćenje pravilne dokumentacije o ovisnostima, izolaciju podataka aplikacije od njezinih mehanizama isporuke, zadržavanje ponovljivih konfiguracija i kontinuirano istraživanje alternativnih pristupa i konfiguracija.

Na primjer, dok se aplikacija napisana za Windows može migrirati za rad na središnje upravljanim Windows poslužiteljima u novoj organizaciji koja koristi različiti softver za hosting ili hipervizore, ili je zamijenila svoj softver za posredovanje VDI-jem, to ne ukazuje na to da je aplikacija univerzalno prenosiva.

Aplikacije moraju biti testirane na njihovu sposobnost rada na različitim infrastrukturnim okruženjima, uključujući varijacije u osnovnom operativnom sustavu, odgovarajuće licenciranje, kompatibilnost specifičnu za aplikaciju ili karakteristike performansi.

Jedna korisna mjera za fleksibilnost je prenosivost aplikacije između značajno različitih okruženja.

Ako migracija aplikacije na drugačiju, ali podržanu, infrastrukturu zahtijeva opsežno preuređivanje nepovezanih elemenata zbog prisutnosti mnogih ovisnosti, to ukazuje na to da se mora obaviti mnogo posla prije nego što se aplikacija može smatrati prenosivom.

Ova metrika može se primjenjivati iterativno kako bi se postupno povećala fleksibilnost infrastrukturnih potreba aplikacije ili izvršile operativne prilagodbe bez potrebe za potpunim preuređenjem same aplikacije.

Tražite jednostavniji način za isporuku Windows aplikacija?

TSplus Remote Access nudi alternativu za organizacije koje žele objaviti Windows aplikacije i isporučiti udaljene radne površine bez implementacije tradicionalnog punog VDI stoga. S objavljivanjem aplikacija, pristupom putem HTML5 preglednika i podrškom za Windows okruženja koja su hostirana lokalno ili u oblaku, pomaže IT timovima da diversificiraju opcije isporuke dok zadržavaju centraliziranu kontrolu.

Zaključak

Zaključavanje od dobavljača VDI postaje skupo kada aplikacije ovise o čvrsto integriranoj infrastrukturi, licenciranju i sustavima upravljanja. Mapiranje ovih ovisnosti i uvođenje alternativnih metoda isporuke može pomoći organizacijama da zadrže kontrolu bez potpunog napuštanja VDI-a.

Fleksibilna arhitektura omogućuje IT timovima da zadrže odgovarajuće radne opterećenja na virtualnim radnim površinama dok pojednostavljuju pristup drugima, smanjuju rizik od migracije i čuvaju buduće opcije.