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 может затруднить организации оптимизацию своих компонентов инфраструктуры.

Когда условия лицензирования меняются или стоимость инфраструктуры возрастает, это может потребовать масштабного проекта миграции, если они намерены сменить поставщиков. Это может ухудшить их переговорные позиции и способность оптимизировать затраты.

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

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

Сниженная архитектурная гибкость

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

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

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

Переходы поставщиков VDI касаются не только миграции виртуальных машин.

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

Плохая документация этих зависимостей может усложнить процесс количественной оценки, тестирования и выполнения без инцидентов.

Большее воздействие изменений поставщика

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

Чем больше зависимость от одной платформы развертывания, тем выше потенциальное операционное воздействие этих изменений на бизнес.

Сохранение альтернативных вариантов доставки может снизить этот риск и создать большую гибкость по мере изменения бизнес-или технологических потребностей.

Как вы можете снизить риски, связанные с зависимостью от поставщика VDI?

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

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

1. Аудит существующих зависимостей VDI

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

Инвентаризация зависимостей должна учитывать следующие вопросы:

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

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

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

2. Отделите доставку приложений от инфраструктуры рабочего стола

Один из лучших способов уменьшить необходимость в VDI — это убедиться, что каждое приложение действительно требует такого сложного решения.

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

Оба метода централизуют приложения, но по-разному.

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

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

Многие такие VDI-системы уже позволяют публиковать приложения, поэтому разрешение публикации приложений не обязательно поможет вам избежать зависимости от поставщика, если эти приложения не могут быть отделены от управляющего уровня VDI.

Скажем, у вас есть бухгалтерия, которой нужен доступ к финансовому приложению Windows, но не нужны собственные виртуальные рабочие столы. Публикуя приложение на Windows (правильно настроенном), вы можете избежать необходимости заставлять всех использовать VDI, при этом сохраняя централизованное управление приложением.

С другой стороны, людям, которым нужны постоянные рабочие столы, где у каждого пользователя есть своя собственная сессия рабочего стола, может понадобиться полный VDI.

3. Применяйте модульные и совместимые архитектуры

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

ИТ-команды должны приоритизировать следующее, где это применимо:

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

Обратите внимание, что разделение пользовательских данных от образов рабочего стола упростит как миграции, так и восстановление после сбоев: аналогично, инфраструктура как код поможет операциям воссоздавать среды с лучшей согласованностью.

Однако даже открытые стандарты и автоматизация могут не предотвратить зависимость от поставщика: часто существуют тонкие различия в реализации технологий различных поставщиков, и скрипты могут содержать вызовы к собственным API.

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

4. Рассмотрите гибридную доставку приложений

Организациям не нужно выбирать между сохранением всей своей инфраструктуры VDI или заменой ее чем-то совершенно другим.

Они могли бы принять гибридную стратегию, которая использует различные рабочие нагрузки в зависимости от их потребностей.

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

Они также могут предоставлять устаревшие приложения через браузеры. Для программного обеспечения Windows, которое нельзя легко переписать, понимание как опубликовать программное обеспечение Windows в интернете может помочь ИТ-командам оценить доставку на основе браузера как часть их гибридной стратегии.

Локальные приложения лучше сохранять, когда централизация мало что улучшает в общей производительности.

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

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

5. Сравните общую стоимость моделей доставки

Экономия на лицензировании сама по себе не определяет экономическую эффективность альтернативной архитектуры доставки приложений.

IT-команды должны оценить общую стоимость владения, включая инфраструктуру, затраты на программное обеспечение, администрирование, безопасность и миграцию.

Категория затрат	Критерии оценки
Программное обеспечение	Лицензирование, подписки, поддержка и продление
Инфраструктура	Вычисления, хранение, сеть и потребление облака
Операционные системы	Лицензирование Windows и применимые права доступа
Администрирование	Пров provisioning, обслуживание, мониторинг и устранение неполадок
Безопасность	MFA, контроль доступа, аудит и управление безопасностью
Миграция	Тестирование, конфигурация, обучение и развертывание
Бизнес-непрерывность	Доступность, резервное копирование, восстановление и время простоя

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

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

Требования к лицензированию должны быть проверены на основе фактической архитектуры, продукта доставки и соответствующих условий Microsoft.

Цель должна заключаться в минимизации общих затрат при обеспечении необходимой безопасности, производительности и надежности для удовлетворения бизнес-потребностей.

Что вам нужно сделать, чтобы избежать зависимости от поставщика VDI?

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

Поэтапная миграция предоставляет ИТ-командам возможность протестировать альтернативные методы доставки, сохраняя при этом статус-кво.

Шаг 1: Классификация приложений по требованиям к доставке

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

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

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

Шаг 2: Выберите рабочую нагрузку с низким риском

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

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

Пилотный проект должен продемонстрировать способность альтернативной инфраструктуры адекватно воспроизводить основные функции и пользовательский опыт оригинальной среды.

Шаг 3: Проверьте совместимость, производительность и безопасность

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

Проект миграции доставки приложений должен включать в тестовый сценарий следующие области:

• Установка приложения, зависимости и лицензирование
• Аутентификация, MFA и разрешения пользователей
• Профили пользователей, настройки и доступ к файлам
• Печать, буфер обмена и перенаправление периферийных устройств
• Конкуренция сессий и потребление ресурсов
• Задержка, отзывчивость и повторное подключение
• Журналирование, мониторинг и политики безопасности
• Резервное копирование, восстановление и процедуры отката

Запуск приложений успешно не гарантирует полной совместимости.

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

IT-команды должны разработать необходимые тесты и критерии производительности для сеансов, приложений, безопасности и функций отката.

Шаг 4: Миграция приложений в контролируемых фазах

Как только пилот соответствует критериям приемки, увеличьте развертывание в зависимости от бизнес-приоритета и технической сложности.

Сохраняйте оригинальную среду доставки во время перехода, когда это возможно, позволяя администраторам сравнивать производительность, эффективно устранять неполадки и возвращаться к установленным процессам при необходимости.

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

Шаг 5: Просмотр оставшихся зависимостей

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

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

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

Это позволит новой среде избежать превращения в еще одну зависимость от поставщика.

В каком случае VDI является хорошим решением для сохранения?

Снижение зависимости от поставщика VDI не требует полной замены VDI.

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

Это также ценно для предоставления стандартизированных, централизованно управляемых рабочих столов с последовательными политиками управления рабочими столами.

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

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

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

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

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

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

Этот подход требует внимательного отношения к правильной документации зависимостей, изоляции данных приложения от его механизмов доставки, сохранению воспроизводимой конфигурации и постоянному исследованию альтернативных подходов и конфигураций.

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

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

Одним из полезных показателей гибкости является портативность приложения между значительно различными средами.

Если миграция приложения на другую, но поддерживаемую инфраструктуру требует значительной переработки несвязанных элементов из-за наличия множества зависимостей, это указывает на то, что необходимо проделать много работы, прежде чем приложение можно будет считать переносимым.

Эта метрика может применяться итеративно для постепенного увеличения гибкости инфраструктурных потребностей приложения или внесения оперативных корректировок без необходимости полного переработки самого приложения.

Ищете более простой способ доставки приложений Windows?

TSplus Удаленный доступ предоставляет альтернативу для организаций, которые хотят публиковать приложения Windows и предоставлять удаленные рабочие столы без развертывания традиционного полного стека VDI. С помощью публикации приложений, доступа через браузер HTML5 и поддержки сред Windows, размещенных на месте или в облаке, это помогает ИТ-командам разнообразить варианты доставки, сохраняя при этом централизованный контроль.

Заключение

Зависимость от поставщика VDI становится дорогостоящей, когда приложения зависят от тесно интегрированной инфраструктуры, лицензирования и систем управления. Картирование этих зависимостей и внедрение альтернативных методов доставки могут помочь организациям сохранить контроль, не отказываясь от VDI полностью.

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