Гибридный Azure Virtual Desktop для локального VDI

Введение

Azure Virtual Desktop Hybrid предоставляет организациям еще один путь между традиционным локальным VDI и полностью размещенными в Azure рабочими столами. Эта статья объясняет, как работает архитектура, как Azure Arc соединяет локальные хосты сеансов с AVD, какие изменения происходят в существующей инфраструктуре VDI и какие ограничения остаются. Также рассматривается, когда Hybrid AVD имеет смысл и что ИТ-команды должны оценить перед его внедрением.

Что такое гибридный Azure Virtual Desktop?

Azure Virtual Desktop Hybrid — это модель развертывания, при которой служба Azure Virtual Desktop по-прежнему размещается и управляется Microsoft в Azure, но хосты сеансов Windows, предоставляющие рабочие столы и приложения, находятся на месте.

Microsoft использует Azure Arc для установления соединения между средами. Все поддерживаемые локальные компьютеры будут серверами с поддержкой Azure Arc. Затем расширение Azure Virtual Desktop Arc устанавливает необходимые компоненты AVD и регистрирует этот компьютер как хост сеансов в пуле хостов AVD.

Все более или менее так же для конечного пользователя, как если бы они использовали AVD, размещенный в Azure. Пользователи получают доступ к назначенным рабочим столам или приложениям через Windows App. Однако разница в том, что рабочая нагрузка Windows будет предоставляться с инфраструктуры клиента, а не из вычислений Azure.

Таким образом, существует разделение инфраструктуры, где:

Компонент	Где это работает	Кто управляет этим
Служба AVD и брокерство	Азур	Майкрософт
Пулы хостов, группы приложений и назначения	Азур	Клиент настраивает их
Хосты сеансов Windows	На месте	Клиент
Гипервизор или физическая инфраструктура	На месте	Клиент
ОС и приложения хоста сеанса	На месте	Клиент
Локальная сеть и хранилище	На месте	Клиент
Интеграция Azure Arc	Azure + на месте	Общая зависимость

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

Как работает гибридный Azure Virtual Desktop?

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

Агент Azure Connected Machine регистрирует каждый хост сеанса в Azure Arc. Расширение Azure Virtual Desktop Arc затем может установить необходимые компоненты AVD и зарегистрировать машину в пуле хостов AVD.

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

Когда пользователь подключается, Azure Virtual Desktop предоставляет возможности на стороне сервиса для обнаружения ресурсов, аутентификации доступа и посредничества в сессии. Фактическая рабочая нагрузка Windows выполняется на локальном хосте сессии.

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

Как гибридный AVD изменяет существующую локальную VDI-среду?

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

Существующие вычисления могут оставаться на месте.

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

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

Наличие существующего оборудования не подразумевает, что среда VDI осталась неизменной. Хосты сеансов должны быть приведены в соответствие с Спецификации Microsoft и зарегистрированы как поддерживаемые Azure Arc, прежде чем они могут быть использованы с Azure Virtual Hybrid Desktop.

Контрольная плоскость VDI переходит в Azure

Наиболее значительные архитектурные различия проявляются выше хостов сеансов.

Вместо того чтобы управлять полным стеком доставки рабочего стола внутри компании, организация использует платформу Azure Virtual Desktop. Microsoft предоставляет основные компоненты сервиса для обнаружения ресурсов, брокерства и подключения через шлюз.

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

Управление локальной инфраструктурой остается

Перенос уровня обслуживания в Azure не делает поддерживающую инфраструктуру управляемой Microsoft.

IT-команды сохраняют ответственность за предоставление, обновление и обслуживание локального оборудования, операционных систем, приложений, сетевого взаимодействия, хранения данных и основной виртуализационной платформы. Microsoft явно документирует, что Azure Virtual Desktop Hybrid не предоставляет виртуальные машины хостов сеансов на месте и не управляет их состоянием питания.

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

В каком случае имеет смысл держать хосты сессий AVD на месте?

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

Унаследованные приложения и локальные зависимости

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

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

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

Требования к расположению данных и инфраструктуре

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

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

Существующие инвестиции в дата-центр

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

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

Нагрузки, чувствительные к задержке на стороне сервера

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

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

Когда гибридный AVD может быть не самым подходящим вариантом

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

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

Устраняет ли гибридный AVD VPN и шлюзы RD?

Azure Virtual Desktop устраняет многие сложности внешней связи, позволяя организациям избегать раскрытия отдельных хостов сеансов в интернете или развертывания стандартного шлюза удаленного рабочего стола (RD Gateway) для AVD.

AVD использует инфраструктуру сервисов Microsoft для подключения через сервис Microsoft. По умолчанию используется транспорт на основе TCP для обратного подключения, в то время как RDP Shortpath может согласовать транспорт на основе UDP, если сеть и конфигурация это поддерживают.

Для организаций, которые в настоящее время имеют среду VDI, использующую входящее соединение по протоколу удаленного рабочего стола (RDP), а также другие методы, такие как доступ по VPN или локально управляемые шлюзы RD для удаленный доступ это может значительно изменить архитектуру внешнего доступа.

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

Каковы ограничения гибридного виртуального рабочего стола Azure?

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

Microsoft в настоящее время определяет несколько возможности управления хостами сеансов как неподдерживаемый для гибридного AVD:

• Управление питанием
• Автоматическое масштабирование Azure Virtual Desktop
• Запустить ВМ при подключении
• Конфигурация хоста сеанса

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

Кроме того, поддержка операционных систем различается, так как нет поддержки Azure Virtual Desktop Hybrid с Windows 10 Enterprise multi-session и Windows 11 Enterprise multi-session. Это значительное отличие, поскольку многосессионные клиентские операционные системы Windows являются ключевой особенностью Azure, размещенного AVD.

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

Наконец, наличие локальных хостов сеансов не делает развертывание AVD независимым от облака, так как управляемый Microsoft сервис Azure Virtual Desktop продолжает быть неотъемлемой частью архитектуры.

Azure-Hosted AVD против гибридного AVD против традиционного VDI на месте

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

	Традиционный локальный VDI	Гибридный Azure Virtual Desktop	Azure-Hosted AVD
Хосты сеансов	На месте	На месте	Азур
Служба VDI/управляющая плоскость	Обычно инфраструктура клиента/поставщика	Microsoft AVD в Azure	Microsoft AVD в Azure
Требуется локальный гипервизор	Обычно да	Да для хостов на базе VM	Нет
Управление локальными вычислениями	Клиент	Клиент	Не применимо к локальному вычислению
Функции жизненного цикла нативной AVD VM	Нет	Ограниченный	Широкая поддержка
Близость к локальным приложениям	Высокий	Высокий	Зависит от проектирования сети
Зависимость от Azure	Зависит от продукта	Да	Да
Потребление вычислительных ресурсов Azure	Нет	Не для локальных хостов сеансов	Да

Таким образом, гибридная AVD имеет архитектуру среднего уровня, где рабочие нагрузки доставляются из облака (управляемого Microsoft), но локальные вычисления управляются клиентом.

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

Как IT-команды должны оценить переход на гибридный AVD?

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

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

Текущее состояние стека VDI должно быть сопоставлено с моделью AVD. Какие брокеры, шлюзы и управляющие службы будут заменены Azure Virtual Desktop? Какие операционные обязанности останутся?

Управление жизненным циклом хоста сеанса является ключевым аспектом. Если существующая платформа VDI включает автоматическое развертывание, запуск/остановку или масштабирование ВМ, оцените, доступны ли эти возможности в Hybrid AVD, а не предполагайте, что контрольный уровень Azure заменит их.

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

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

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

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

Заключение

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

Решающим фактором является то, предоставляет ли сохранение этих рабочих нагрузок локально явное техническое или операционное преимущество. Команды ИТ должны оценить зависимости приложений, управление инфраструктурой, сетевое взаимодействие, лицензирование и зависимость от Azure вместе, прежде чем решать, действительно ли гибридный AVD упрощает их VDI-среду.