VDI доставчик на заключване: рискове и решения

Въведение

Виртуалната десктопна инфраструктура (VDI) опростява централизираното управление на десктопите, но взаимосвързаните й компоненти могат да затруднят смяната на платформите. От собствени брокери на връзки до лицензионни ограничения, тези зависимости могат да ограничат ИТ избора и да увеличат сложността на миграцията. Тази статия разглежда причините и рисковете от заключване при доставчиците на VDI, обяснява как да ги намалим и очертава практически стъпки за запазване на гъвкавостта при доставката на Windows приложения.

Какво е заключване на доставчика на VDI?

Заключването на доставчика на VDI е ситуация, при която организацията става изключително зависима от конкретна платформа за виртуализация на работния плот до такава степен, че смяната на доставчици би била изключително предизвикателна, скъпа или разрушителна за компанията.

VDI компоненти като хипервизори, брокери на връзки, изображения на работни станции, потребителски профили, системи за удостоверяване и други инструменти за управление обикновено се комбинират в VDI среди. Въпреки това, въпреки че са отделни, те могат да изискват специфична документация и конфигурация от доставчика, за да взаимодействат успешно помежду си.

Причината е, че, въпреки че приложенията, написани на езика на Windows, обикновено работят навсякъде, настолните компютри, изградени за специфична VDI среда, изискват значително време за пренастройка. Следователно, зависимостта от доставчика не е непреодолим проблем, но създава съществени пречки за организациите, които се опитват да сменят платформите.

Какви са причините за заключване на доставчика в среди с VDI?

Заключването на доставчика на VDI рядко се причинява от едно конкретно техническо ограничение. Обикновено то произтича от множество зависимости от свързана инфраструктура, инструменти за управление, лицензиране и конфигурации на приложения.

Собствени брокери на връзки и инструменти за управление

Брокерите на връзки са отговорни за управлението на потребителските връзки към виртуални десктопи, докато инструментите за управление се използват за предоставяне, разполагане и поддържане на десктопи и приложения. Инструменти като Citrix Virtual Apps and Desktops, Omnissa Horizon и Azure Virtual Desktop са изградени с помощта на различна инфраструктура за управление и техники за конфигуриране.

Това означава, че при преминаване от една платформа на друга може да се наложи да се преструктурират десктоп пулове, приложения, връзки и автоматизирани инструменти. Самите приложения могат да останат същите, обаче тяхната реализация ще се различава в зависимост от първоначалния софтуер.

Хипервизор и зависимости на инфраструктурата

Платформите VDI изискват инфраструктура, способна да хоства и управлява виртуални десктопи. Това може да включва специфични хипервизори, облачни технологии, технологии за съхранение или технологии за предоставяне.

Процесът на миграция може следователно да включва няколко задачи:

• Конвертиране или възстановяване на изображения на виртуални машини
• Преконфигуриране на мрежата, съхранението и разпределението на ресурсите
• Заменяне на инструменти за предоставяне, специфични за доставчика
• V валидиране на съвместимостта и производителността на приложението
• Възстановяване на механизми за наличност и възстановяване след бедствия

Въпреки това, концепцията за преносимост не винаги се разширява до средата за доставка на работния плот. Успешната миграция на виртуална машина не гарантира, че околната среда за доставка ще функционира без модификация.

Лицензиране и договорни ограничения

VDI внедрения обикновено изискват няколко различни лиценза – за операционни системи, виртуализационни продукти, права за достъп на потребители, инструменти за управление и приложения на трети страни.

Доставчиците значително се различават по отношение на комбинирането или разделянето на тези технологии, което може да направи планирането на бюджета и прехода към нови инфраструктури по-сложни.

Това е особено важно, когато организациите искат да преминат от един VDI стек на друг, например, от локално решение към облачно решение, тъй като лицензионните модели за операционни системи, права на потребителите и потребление на инфраструктура могат да се променят драстично.

Уебсайтът Microsoft Learn предоставя един информация за лицензиране на Azure Virtual Desktop и как това се прилага към различни операционни системи и случаи на употреба.

Съответно, е съществено да се анализира целият лицензен пакет, включително последиците от всякакви договорни задължения, при вземането на решението, а не само разходите за абонамент.

Зависимости на приложението и потребителския профил

Windows приложенията могат да имат редица зависимости от операционната система, регистъра, драйверите, местоположението или други услуги.

Тези типове приложения обикновено се виртуализират в VDI среди, като определени аспекти на изискванията са вградени в основни изображения или включени в инструменти за управление на профили. Някои компании изграждат и поддържат свои собствени инструменти и скриптове, за да отговорят на специфичните нужди на своето приложение във връзка с останалата част от инфраструктурата.

В тези ситуации става изключително трудно да се отделят приложенията от техните поддържащи елементи, което представлява значителен технически дълг и прави преносимостта изключително трудна.

Дори и приложението само по себе си да е преносимо, все още има основни елементи, като инсталацията, конфигурацията, потребителските настройки и управлението на данни, които ще трябва да бъдат възстановени в новата среда. Разбирането на разликата между Опаковане на Windows приложения и публикуване на приложения може да помогне на ИТ екипите да разделят изискванията за внедряване на софтуер от зависимостите на доставката на приложения.

Какви са рисковете от заключване с доставчик на VDI?

Зависимостта от доставчика представлява особени трудности, когато организацията трябва да промени своята инфраструктурна стратегия, да се адаптира към промени в лицензите или да приеме нови технологии за доставка на приложения.

Основните рискове са свързани с разходите, архитектурната гъвкавост и оперативната непрекъснатост.

Нарастващи инфраструктурни и лицензионни разходи

Тясно свързана VDI среда може да затрудни на организацията оптимизирането на компонентите на инфраструктурата си.

Когато условията за лицензиране се променят или разходите за инфраструктурата нарастват, това може да наложи проект за миграция в голям мащаб, ако те възнамеряват да сменят доставчиците. Това може да навреди на тяхната преговорна позиция и способността им да оптимизират разходите.

Освен това, предоставянето на всички приложения чрез пълен виртуален десктоп може да доведе до ненужни разходи за натоварвания, които изискват само едно или две приложения за Windows.

Публикуването на приложения по никакъв начин не е по-евтино от VDI: икономиката на двата подхода ще варира в зависимост от плътността на работните натоварвания, необходимите операционни системи, инфраструктурния отпечатък и изискванията за администриране и управление.

Намалена архитектурна гъвкавост

Организациите, които търсят да приемат хибридна инфраструктура, да заменят остарели сървъри, да преминават между доставчици на хостинг или дори да приемат нови технологии за доставка, може да открият, че опциите им са ограничени от съществуващи зависимости от конкретни доставчици.

Платформа VDI, която е тясно свързана с един инфраструктурен стек, може да наложи пълно преработване на приложенията, предназначени за доставка на други стека и хостинг доставчици, което забавя процеса на цифрова трансформация.

Увеличена сложност на миграцията

Преходите на VDI доставчиците не са само за миграция на виртуални машини.

Администраторите също трябва да запазят удостоверяване, потребителски профили, настройки на приложенията, печат, достъп до файлове, политики за сигурност и поведение на сесиите.

Лошата документация на тези зависимости може да направи процеса по-труден за количествено определяне, тестване и изпълнение без инциденти.

По-голяма експозиция на промени от доставчика

Прекратяване на продукта, нови лицензионни модели, промени в поддръжката или изискванията за инфраструктура може да наложат промяна в стратегията за внедряване.

Колкото по-голяма е зависимостта от една единствена платформа за внедряване, толкова по-висок е потенциалният оперативен ефект от тези промени за бизнеса.

Запазването на алтернативни опции за доставка може да намали този риск и да създаде по-голяма гъвкавост, когато бизнес или технологичните нужди се променят.

Как можете да намалите рисковете от заключване при доставчик на VDI?

Намаляването на зависимостта от доставчици на VDI изисква набор от технически, свързани с натоварването и архитектурни съображения.

Идеята не е да се избягват доставчиците, а по-скоро да се позволят промени в платформата, без да се нарушават всички останали аспекти на доставката на приложения.

1. Аудит на съществуващите VDI зависимости

Първата стъпка е да се идентифицира какво е критично за доставката на приложения и десктопи и какви компоненти зависят от технологии, специфични за доставчиците.

Инвентаризация на зависимостите трябва да разгледа следните въпроси:

Компонент	Въпроси за разследване
Свързващ брокер	Могат ли назначенията на работния плот и приложенията да бъдат възстановени на друго място?
Хипервизор	Могат ли виртуални машини и изображения да се прехвърлят на алтернативна инфраструктура?
Приложения	Изискват ли приложенията специфични изображения, операционни системи или драйвери?
Профили на потребители	Могат ли настройките и данните да се мигрират независимо?
Аутентификация	Свързани ли са политиките за идентичност с патентовани интеграции?
Лицензиране	Какви ангажименти, права на достъп и разходи за напускане се прилагат?
Автоматизация	Кои скриптове разчитат на специфични за доставчика API или инструменти?

Инвентаризацията трябва също да включва собственици на приложения, критичност за бизнеса, изисквания за възстановяване и недокументирани персонализации.

Тази класификация може да помогне на ИТ мениджърите да разберат кои зависимости могат да бъдат лесно заменени и кои изискват значителен пре redesign.

2. Разделете доставката на приложения от настолната инфраструктура

Един от най-добрите методи за намаляване на нуждата от VDI е да се уверите, че всяко приложение наистина изисква такова сложно решение.

Докато VDI предлага виртуални десктопи, публикуването на приложения предоставя дистанционен достъп до индивидуални приложения, без непременно да предоставяте цял работен плот.

И двата метода централизират приложенията, но по различен начин.

Изискване	Пълен VDI	Публикуване на приложения на базата на сесии
Завършен персонализиран работен плот	Добре подходящо	Не е основната цел
Индивидуални Windows приложения	Подкрепен	Добре подходящо
Изолиране на операционна система за настолни компютри	Наличен	Обикновено използва споделени хостове на сесии
Специализирани конфигурации на работния плот	Често подходящо	Зависи от съвместимостта
Централизирано управление на приложенията	Подкрепен	Подкрепен
Достъп през браузър	Платформено зависимост	Наличен с съвместими решения
Доставка без пълен VDI стек	Не обикновено	Възможно

Разликата е архитектурна, а не функционална.

Много от тези VDI системи вече позволяват публикуване на приложения, така че разрешаването на публикуването на приложения не непременно ви помага да избегнете зависимост от доставчика, освен ако тези приложения не могат да бъдат отделени от контролния слой на VDI.

Кажете, например, че имате счетоводен отдел, който се нуждае от достъп до финансово приложение за Windows, но не се нуждае от свои собствени виртуални десктопи. Като публикувате приложението на Windows машина (правилно настроена), можете да избегнете необходимостта всички да използват VDI, като същевременно запазите администрирането на приложението централизирано.

От друга страна, хората, които се нуждаят от постоянни работни станции, където всеки потребител има своя собствена сесия на работния плот, може да се нуждаят от пълна VDI.

3. Приемете модулни и взаимозаменяеми архитектури

Модулните архитектури позволяват замяната на отделни елементи, без да се нарушава общата среда за доставка на приложения.

ИТ екипите трябва да приоритизират следното, когато е приложимо:

• Стандартизирана идентичност и удостоверяване
• Преносимо приложение код и документирани зависимости
• Потребителски данни, отделени от изображения на работния плот
• Инфраструктура като код: повтарящо се разгръщане, автоматизация
• Доставка, която работи на различни крайни устройства и хостинг среди

Обърнете внимание, че разделянето на потребителските данни от изображенията на работния плот ще опрости както миграциите, така и възстановяването след бедствия: по подобен начин инфраструктурата като код ще помогне на операциите да възстановят средите с по-добра последователност.

Въпреки това, дори отворените стандарти и автоматизацията може да не предотвратят зависимостта от доставчика: често има фини разлики в изпълнението между технологиите на различните доставчици, а скриптовете могат да съдържат извиквания към собствени API.

Следователно, целта е да се избегне ненужно свързване между компонентите на приложението и инфраструктурата, управлението и оперативните компоненти.

4. Обмислете хибридно предоставяне на приложения

Организациите не трябва да избират между запазването на цялата си VDI инфраструктура или заменянето ѝ с нещо съвсем различно.

Могат да приемат хибридна стратегия, която използва различни натоварвания в зависимост от нуждите им.

Организацията може да използва специализирани десктопи за мощни потребители, докато хоства съвместими бизнес приложения на споделени хостове за Windows сесии.

Те също могат да предоставят наследствени приложения чрез браузъри. За софтуер за Windows, който не може лесно да бъде пренаписан, разбирането как да публикувате Windows софтуер в мрежата може да помогне на ИТ екипите да оценят доставката на базата на браузър като част от тяхната хибридна стратегия.

Локалните приложения се запазват най-добре, когато централизацията не подобрява значително общата производителност.

Такава стратегия ще позволи на ИТ отдела да запази съществуващите инвестиции в инфраструктурата си, докато преминава към нови технологии с темпо, което е удобно за тях.

Предизвикателството с този подход е, че той създава допълнителна сложност и изисква по-подробно управление на идентичността, мерки за сигурност, които да са унифицирани на всички платформи, правила за мониторинг и процедури за поддръжка.

5. Сравнете общата цена на моделите за доставка

Спестяванията от лицензиране сами по себе си не определят икономическата ефективност на алтернативна архитектура за доставка на приложения.

ИТ екипите трябва да оценят общата цена на притежание, включително инфраструктура, разходи за софтуер, администриране, сигурност и миграция.

Категория разходи	Критерии за оценка
Софтуер	Лицензиране, абонаменти, поддръжка и подновяване
Инфраструктура	Изчисления, съхранение, мрежи и облачно потребление
Операционни системи	Лицензиране на Windows и приложими права за достъп
Администрация	Осигуряване, поддръжка, мониторинг и отстраняване на проблеми
Сигурност	MFA, контрол на достъпа, одитиране и управление на сигурността
Миграция	Тестване, конфигуриране, обучение и внедряване
Непрекъснатост на бизнеса	Наличност, резервно копие, възстановяване и излагане на престой

Публикуването на приложения може да намали нуждата от специфични компоненти в среда на VDI, но има свои собствени изисквания за внедряване и лицензиране.

Например, традиционните конфигурации за хостинг на сесии на Microsoft Remote Desktop Services (RDS) биха изисквали подходящите лицензии за достъп на клиенти RDS, както е описано в Документация за RDS CAL на Microsoft .

Изискванията за лицензиране трябва да бъдат валидирани въз основа на действителната архитектура, продукта за доставка и съответните условия на Microsoft.

Целта трябва да бъде да се минимизират общите разходи, като същевременно се осигурят необходимата сигурност, производителност и надеждност за удовлетворяване на бизнес нуждите.

Какво трябва да направите, за да се мигрирате от заключването на доставчика на VDI?

Намаляването на зависимостта от доставчици е много по-безопасно да се прави постепенно, отколкото да се извърши пълна подмяна на платформата.

Постепенната миграция дава на ИТ екипите възможност да докажат алтернативни методи на доставка, като същевременно запазват статуквото.

Стъпка 1: Класифицирайте приложенията по изисквания за доставка

Започнете с групиране на приложенията въз основа на техните технически зависимости и изисквания на крайния потребител. Три широки категории са особено полезни за идентифициране:

• Приложения, изискващи пълни работни станции – натоварвания, изискващи специална операционна система, специална конфигурация или изолация на ниво работен плот
• Приложения, подходящи за дистанционно публикуване – Windows приложения, съвместими с поддържаните споделени/посветени среди за хостинг на сесии
• Приложения, подходящи за локален или браузър-роден достъп – софтуер, който вече не изисква да се изпълнява в среда на VDI.

Такава класификация може да помогне на администратора да идентифицира кандидати за алтернативни модели на доставка, които не изискват значителни адаптации.

Стъпка 2: Изберете пилотен товар с нисък риск

Изберете приложение с ясно определени изисквания за ресурси, малко зависимости и ограничена потребителска база.

Избягвайте да започвате с бизнес-критични приложения, които разчитат на сложни периферни интеграции, уникални драйвери или уязвими наследствени компоненти.

Пилотният проект трябва да докаже способността на алтернативната инфраструктура да възпроизведе адекватно основните функции и потребителското изживяване на оригиналната среда.

Стъпка 3: Валидиране на съвместимост, производителност и сигурност

Преди да увеличите мащаба, тествайте функциите и оперативните характеристики в реалистични среди.

Проектът за миграция на доставката на приложения трябва да включва следните области в тестовия сценарий:

• Инсталиране на приложения, зависимости и лицензиране
• Аутентификация, MFA и потребителски разрешения
• Профили на потребители, настройки и достъп до файлове
• Печатане, клипборд и пренасочване на периферни устройства
• Сесийна конкурентност и потребление на ресурси
• Забавяне, отзивчивост и повторно свързване
• Регистриране, мониторинг и политики за сигурност
• Резервно копие, възстановяване и процедури за връщане назад

Стартирането на приложения успешно не гарантира пълна съвместимост.

Например, едно приложение може да работи добре само по себе си, но да се провали, когато няколко потребители се опитат да го стартират едновременно или да печатат документи на принтери.

ИТ екипите трябва да проектират необходимите тестове и критерии за производителност за сесиите, приложенията, сигурността и функциите за възстановяване.

Стъпка 4: Мигрирайте приложенията в контролирани фази

След като пилотният проект отговаря на критериите за приемане, увеличете разгръщането в зависимост от бизнес приоритета и техническата сложност.

Запазете оригиналната среда на доставка по време на прехода, когато е възможно, позволявайки на администраторите да сравняват производителността, ефективно да отстраняват проблеми и да се върнат към установените процеси, ако е необходимо.

Определете критерии за успех на документа, назначете отговорности и установете процедури за възстановяване за всяка фаза на миграцията. Тези мерки също допринасят за устойчивост на приложението помагайки на организациите да запазят основните бизнес функции по време на промени в инфраструктурата.

Стъпка 5: Преглед на оставащите зависимости

Проблемът с привързаността към доставчика не е ограничен до един единствен случай.

Новите приложения, необходимостта от актуализиране на платформата, промените в лицензиране или оперативна персонализация могат да създадат допълнителни зависимости след завършване на миграцията.

Следователно, периодични прегледи са необходими, за да се уверим, че приложенията могат да продължат да работят на целевата платформа, че конфигурациите са били правилно записани и че други средства за доставка остават налични.

Това ще позволи на новата среда да избегне да стане поредното заключване от доставчик.

В кой случай VDI е добро решение за запазване?

Намаляването на зависимостта от доставчика на VDI не изисква цялостна подмяна на VDI.

VDI има легитимна стойност за сценарии, които включват необходимостта от специализирани операционни системи, постоянни работни станции, графично интензивни приложения или изолация на натоварването, която хостовете на споделени сесии не могат да предоставят.

Това също е ценно за предоставяне на стандартизирани, централизирано управлявани работни станции с последователни политики за управление на работния плот.

Решението за приемане на различна архитектура трябва да се основава на поведението на приложението, нуждите от сигурност, изискванията на потребителите и икономическите фактори.

За повечето организации разпределената архитектура е по-практична от това да се наложи всички приложения да бъдат в един и същ модел на доставка.

Запазването на VDI за работни натоварвания, които го изискват, докато се използва независима публикация на приложения за други работни натоварвания, би позволило намаляване на зависимостта от VDI, без да се отказват възможностите на VDI.

Как може доставката на приложения да остане гъвкава в дългосрочен план?

Дългосрочната гъвкавост на системата се постига чрез способността да се запази контролът върху връзката между приложението и инфраструктурата и достъпа на потребителите.

Приложенията трябва да бъдат проектирани по начин, който позволява тяхната продължаваща работа на потенциално променящи се инфраструктурни хостинг доставчици, хипервизори или платформи за виртуализация на работния плот.

Този подход изисква внимателно внимание към правилната документация на зависимостите, изолацията на данните на приложението от механизмите за доставка, запазването на възпроизводима конфигурация и непрекъснатото проучване на алтернативни подходи и конфигурации.

Например, докато приложение, написано за Windows, може да бъде мигрирано да работи на централизирано управлявани Windows сървъри в нова организация, която използва различен хостинг софтуер или хипервизори, или е заменило софтуера за брокери на VDI, това не означава, че приложението е универсално преносимо.

Приложенията трябва да бъдат тествани за способността им да работят на различни инфраструктури, включително вариации в основната операционна система, подходящо лицензиране, съвместимост, специфична за приложението, или характеристики на производителността.

Един полезен показател за гъвкавост е преносимостта на приложението между значително различни среди.

Ако мигрирането на приложение към различна, но поддържана инфраструктура изисква обширна преработка на несвързани елементи поради наличието на много зависимости, това показва, че трябва да се свърши много работа, преди приложението да може да се счита за преносимо.

Тази метрика може да се прилага итеративно, за да се увеличи постепенно гъвкавостта на нуждите от инфраструктура на приложението или да се направят оперативни корекции, без да се изисква пълно преработване на самото приложение.

Търсите ли по-прост начин за доставка на Windows приложения?

TSplus Remote Access предлага алтернатива за организации, които искат да публикуват Windows приложения и да предоставят дистанционни работни станции, без да внедряват традиционен пълен VDI стек. С публикуването на приложения, достъп през HTML5 браузър и поддръжка за Windows среди, хоствани на място или в облака, помага на ИТ екипите да разнообразят опциите за доставка, като запазват централизирания контрол.

Заключение

Заключването на доставчика на VDI става скъпо, когато приложенията зависят от тясно интегрирана инфраструктура, лицензиране и управленски системи. Картографирането на тези зависимости и въвеждането на алтернативни методи за доставка могат да помогнат на организациите да запазят контрола, без да се отказват напълно от VDI.

Гъвкава архитектура позволява на ИТ екипите да поддържат подходящи натоварвания на виртуални десктопи, докато опростяват достъпа до други, намалявайки риска от миграция и запазвайки бъдещи опции.