виртуальный десктоп что такое

01 — Виртуализация рабочих мест. Что это и с чем едят

Как мы и обещали в анонс-посте, мы открываем цикл статей по виртуализации рабочего пространства.

Тема “модная” на западе, и ее развивают достаточно давно, как технологически (программно), так и с точки зрения аппаратной части. Если вы слышали о таких словах, как “тонкие клиенты”, “виртуализация”, “bring your own device”, “удаленный доступ к данным”, то, скорее всего, вы слышали о какой-либо из частей этого необъятного моря виртуализации рабочих мест.

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

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

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

Лет тридцать назад вместо Word’а на рабочем столе (реальном) вполне могла бы стоять печатающая машинка

(и хорошо, если это был какой-нибудь модный Selectric от IBM, с функцией удаления опечаток).

Вместо приложения “калькулятор” — его “десктопный” аналог, подключенный к розетке или автономный. Вместо поиска от Google — толстая стопка папок, пронумерованная по годам (или буквам алфавита). Вместо адресной книги почтового клиента — телефонный справочник и стопка конвертов. Вместо систем CAD/CAE — набор чертежных принадлежностей и технической документации. Ну а что было ещё чуть раньше… лучше не вспоминать.

За картинку спасибо mikejum, у него есть интересный пост, посвящённый счётам.

Сейчас все эти бумажно-аппаратные комплексы перенесены внутрь компьютеров, а сами компьютеры (и даже мобильные телефоны) по цене сравнимы с деревянной мебелью из IKEA. Сравните сложность производства стула, и, скажем, центрального процессора по техпроцессу в 45 нанометров. А ведь их стоимость сопоставима, и, порой, отличается не в 10-20 раз, а в 2-3. И, тем не менее, рабочее место до сих пор часто выглядит далёким от рафинированных промо-материалов без проводов, питания, в конно-сферических условиях в вакууме; а на наших столах всё ещё лежат документы, письменные принадлежности, стоит телефон, да мало ли чего ещё?

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

Что отличает процесс виртуализации, шедший последние 100 лет от того процесса, который идёт сегодня? Масштабы и скорость. Виртуализация рабочего места сегодня — это перенос вашего компьютера (и всех его приложений) в “виртуальное” состояние, и выполняется оно подобно тому, как в прошлом “аппаратные” помощники офисных служащих получили свои цифровые аналоги, после чего оказались в музеях.

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

Вместо блока питания на 350 ватт — небольшой и экономичный БП, как у ноутбуков, не требующий активного охлаждения. Вместо отдельных мест для бухгалтеров, инженеров и менеджеров — универсальные рабочие места, готовые к работе в любое время. Все программы, данные и настройки — на сервере, “железо” которого рассчитано на постоянные нагрузки, имеет коэффициент надежности “четыре девятки”, а ПО грамотно распределяет доступные ресурсы между активыми пользователями. Простаивающий компьютер инженера никак не поможет экономить на электроэнергии или ускорить работу его соседа. Виртуализация рабочих мест (в актуальном прочтении) решает эти и многие другие проблемы. Причем развертывание новых рабочих станций и расширение занимает минуты против часов в “классическом” случае. А вместо “неудобного” компьютера вы можете использовать ваш привычный ноутбук или планшет с док-станцией и внешним монитором. А самое главное — внутри компании практически с любого компьютера вы можете получить доступ к своим документам, файлам и приложениям за считанные секунды, и при этом не бояться ни потенциальной утечки данных, ни нарушений уровня допуска, ни потенциальных дыр в защите чужого компьютера. Ни файлов, ни данных, ни чего-либо хоть сколько-нибудь ценного на клиенте не хранится.

Что же умеет виртуализация сегодня, и какие технологии применяются в отрасли?

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

VDI — virtual desktop infrastructure — программно-аппаратный комплекс, который работает следующим образом: имеется сервер с серверной ОС, на котором крутятся “образы” с клиентскими операционками. Часть файлов у образов общая, часть — раздельная, но суть заключается в том, что у каждого из пользователей — свой образ операционки, а доступ к нему осуществляется (как правило, но из правил есть и исплючения) через тонкие клиенты. На тонком клиенте крутится либо специальная версия Windows (с приставкой Embedded), которая обеспечивает подключение к серверу и работу с “образом ОС”. который хранится на сервере, либо очень маленькая операционная система, единственным назначением которой является загрузка “железа” и базовых драйверов, поиск и подключение к серверу и вывод виртуального рабочего стола на ваш монитор.

RDP/RDS — remode desktop protocol / remote desktop services — программно-аппаратный комплекс, который работает иначе, нежели VDI. Главное отличие заключается в том, что серверная ОС является вашей рабочей средой: все программы запускаются прямо на сервере (внутри его ОС), и по протоколу RDP вы получаете доступ к конкретным приложениям или пользовательскому рабочему столу, но при этом никакого “образа” с вашей личной ОС на сервере нет, максимум — папка с пользовательским профилем и данными / документами. Доступ по протоколу RPD требует его поддержки на клиентской стороне, что накладывает определенные ограничения как на серверные, так и на пользовательские технологии.

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

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

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

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

Существует еще одно модное нынче течение и связанный с ним тип виртуализации. Речь идет о BYOD (“bring your own device”, “притащи свою железку”) и виртуализации приложений.

Реализаций у BYOD‘а — масса, начиная со спонсирования покупки того железа, с которым вы хотите работать (ноутбука, моноблока или еще какого-нибудь девайса), заканчивая бонусами в денежном эквиваленте, если вы приносите своё собственное устройство или работаете по удаленке, появляясь в офисе только тогда, когда это действительно необходимо.

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

Виртуализация приложений “проецирует” нужное вам приложение с сервера на ваш девайс, прозрачно для вас или в отдельном “окне” с рабочим столом, в зависимости от реализации. Все данные и рабочие файлы могут храниться одновременно в двух местах, в зашифрованном хранилище на локальном устройстве и в storag’e на сервере, а доступ к приложениям и данным может быть получен не только с ноутбука или домашнего компьютера, но и с планшета или телефона. У данного подхода есть много различных реализаций, отличающихся подходами, отвечающими за безопасность и сохранность данных, способами авторизации, доступностью с мобильных устройств и много чем еще, он сочетает в себе как большое количество плюсов, так и весомые минусы (особенно беспокоит BYOD безопасников и отделы, связанные с конфиденциальной информацией).

С базовыми понятиями виртуализации рабочих мест, а также с актуальными тенденциями в этой сфере, вроде бы, мы закончили. У вас остались вопросы? Есть, что добавить? Имели опыт работы с “виртуалками”? Хочется поделиться впечатлениями? Мы ждем вас в комментариях!

Источник

Виртуализация десктопов: что нового, какие тренды и куда идем?

Виртуализацией уже никого не удивить. Виртуализируется сегодня все: серверы, приложения, рабочие места. Однако для большинства рядовых пользователей эта технология является чем-то вроде того суслика из фильма ДМБ: «ты не видишь, я не вижу, а он есть». Однако все меняется, когда приходят они — виртуальные рабочие места, и вместо громоздкого системного блока или ноутбука на столе офисных работников появляется маленькая коробочка, т.н. тонкий клиент. Конечно, все может быть и немного по-другому, но сути это не меняет. О том, что такое виртуализация десктопов, какая она бывает, и что ждет нас в будущем, мы и поговорим.

Итак, что такое VDI (инфраструктура виртуальных рабочих столов)? Все просто: на физическом сервере разворачиваются виртуальные машины с пользовательскими либо серверными ОС, которые доступны через интернет из любой точки мира, где он есть (от 64 Кбит/с, если работу надо сделать, не считаясь с комфортом) с любого «умного» девайса. При этом для пользователя ничего не поменяется, но вот для ИТ-департамента ситуация с администрированием значительно изменится с точки зрения безопасности доступа к данным, доступности рабочих мест, простоты и стоимости обслуживания. Несмотря на сравнительно большую стоимость VDI (иногда в несколько раз) по сравнению с терминальным доступом, в случае, когда обязательным условием является изоляция рабочей среды пользователя с клиентской ОС на уровне отдельной виртуальной машины, VDI становится наиболее экономичным вариантом разворачивания новых точек и офисов вне зависимости от географии присутствия компании. При этом сохраняется вся функциональность сотрудников на местах и значительно снижается риск утечек конфиденциальной корпоративной информации за счет централизации управления рабочими данными.

VDI или терминальный доступ: критерии выбора

Основные вендоры VDI-решений активно рекламируют VDI как must have для средних и малых компаний, но, положа руку на сердце, малому и среднему бизнесу виртуальные рабочие столы не нужны по той цене, по которой они предлагаются. Даже если вдруг потребуется жесткое соблюдение политик безопасности, терминального доступа более чем достаточно. Под терминальным доступом в самом общем плане имеем ввиду удаленный доступ множества пользователей к приложениям, запущенным в рамках операционной системы сервера, общей для всех пользователей, с едиными низкоуровневыми системными процессами и т.д. Это основное отличие от VDI, где для каждого пользователя на аппаратном сервере будет развернута отдельная виртуальная машина с операционной системой и необходимыми конкретному пользователю приложениями. Также существует выгодная гибридная схема, когда пользователь подключен к серверной ОС, но 1 пользователь = 1 виртуальная машина. Это так называемый «серверный VDI», сочетающий в себе плюсы терминального решения и виртуализации десктопов.

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

VDI гипервизорная

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

По сути, сегодня есть всего два варианта виртуальной инфраструктуры рабочих мест (терминальный доступ и «серверный VDI», упомянутый выше, также часто используются для решения задач VDI, но за полноценный VDI мы их считать не будем): гипервизорная и контейнерная. Гипервизорная наиболее распространена, и именно к этому виду относится большинство популярных решений для виртуализации от таких производителей как Microsoft, VMware и Citrix. Причем в связи с тем, что такая модель наиболее распространена, она имеет множество отлаженных «фишек», которые недоступны в случае с «контейнерами». Например, функцию прямого подключения дополнительного GPU, часто требующегося в конструкторских и дизайнерских бюро. Подобная технология (GRID Virtual GPU) полноценно поддерживается гипервизором XenServer. Рассмотрим же ПО для обеспечения удаленного доступа к рабочим столам Citrix XenApp и XenDesktop.

На сегодня архитектурно XenApp и XenDesktop друг от друга не отличаются. Единственно, что их технически отличает – агент, который ставится на клиентскую ОС – VDI (часто именно это называют XenDesktop) или на серверную ОС – терминальный сервер (то, что подразумевается под XenApp). Однако, не нужно забывать, что в XenDesktop начиная с редакции Enterprise включены и VDI и терминальные сервисы. Раньше, до версии 7, технически это были два разных продукта – разная архитектура, консоли управления. И если пользователю система представлялась единой, то администратору было сложнее: фактически в рамках решения присутствовали и терминальные сервисы, и виртуальные десктопы, настройку каждого из них приходилось выполнять отдельно в разных местах. Сейчас в решении есть единая консоль для терминального варианта и виртуальных десктопов, единый веб-портал, где можно отслеживать состояние системы (Desktop Director), статус конкретной машины и многое другое.

Инфраструктура виртуализации десктопов Citrix работает на любом гипервизоре: XenServer, Microsoft Hyper-V, VMware ESXi, и Nutanix Acropolis. Это четыре гипервизора, где система может сама автоматически создавать виртуальные машины, удалять их, перезапускать, выключать. Соответственно, при смене гипервизора можно бесшовно перейти с одного на другой. В случае с другими гипервизорами XenDesktop будет воспринимать виртуальные машины как физические, без возможности их автоматического создания, удаления и управления.

С помощью XenDesktop фактически можно заменить рабочее место любого сотрудника. В рамках данного решения используется свой фирменный протокол передачи данных. В случае если нет возможности использовать агента, который ставиться на клиентское рабочее место, используется собственная (Citrix) реализация HTML5. Это одно из отличий от продуктов некоторых других вендоров, у которых один протокол лицензированный, второй — собственной разработки.
Даже если у кого-то из заказчиков еще остался промышленный UNIX (AIX, HP Unix, Solaris), то в рамках XenApp и XenDesktop начиная с редакции Enterprise есть возможность поставить XenApp for UNIX. Соответственно, продукты Citrix поддерживаются серверными операционными системами Windows и различными вариантами Linux. Если нужно использовать офлайновый режим работы, то есть отдельный продукт Desktop Player, который работает на Mac- и Windows-ноутбуках. Это корпоративное решение, которое не подразумевает, что конечный пользователь сам может развернуть себе виртуальную машину, это можно сделать только с помощью администратора.

При вопросе «что выбрать?» стоит исходить не из конкретного желаемого продукта, а из ограничений, накладываемых приложениями, их вариантами лицензирования, требованиями пользователей и стоимостью всего решения. XenApp в чистом виде лицензируется только как конкурентный пользователь. XenDesktop может лицензироваться и как конкурентный пользователь, и как пользователь/устройство, то есть здесь нет отдельной лицензии на пользователя и на устройство. В этом случае работает логика сервера лицензий, который выбирает, в какой вариант переключиться, чтобы было потреблено наименьшее количество лицензий при текущем использовании.

Разница в стоимости лицензии пользователь/устройство против конкурентного пользователя (XenApp и XenDesktop) приблизительно в два раза. Иногда получается, что заказчику нужен XenApp, но ему выгоднее купить XenDesktop, который продается по схеме лицензирования пользователь-устройство. Он получит необходимое ему в два раза дешевле, но при этом сможет в дальнейшем при необходимости подключить виртуальные десктопы.

VDI контейнерная и из облака

Теперь поговорим о контейнерной виртуализации. На сегодня она является экзотикой, самый известный пример такой технологии — Parallels Containers для Windows. Главное преимущество этого варианта – значительно большая по сравнению с традиционным VDI (но меньшая, чем у терминальных сервисов) плотность размещения пользователей на сервере (до 250 мест), и в некоторых случаях возможность немного сэкономить на лицензиях ПО Microsoft. Контейнерная виртуализация объединяет в себе ряд плюсов, но и ряд минусов, перешедших к ней от VDI и терминальных сервисов. До выхода Windows Server 2016 Microsoft не поддерживала контейнерные технологии вообще, и компании, внедрившие этот продукт в свою инфраструктуру, при выходе любого обновления к серверной ОС (а это десктоп серверной ОС) должны были ждать, пока Parallels проверит и даст добро на установку соответствующего обновления. Теперь, после выхода Windows Server 2016, и официальной поддержки технологии контейнеров Windows в рамках ОС ситуация может изменится.

Контейнерная технология виртуализации работает в ядре ОС (Windows Server 2008/2012), что позволяет разделять объекты ядра между контейнерами, тем самым изолируя их друг от друга. Каждый контейнер имеет свой собственный набор процессов, сессий и драйверов, а также реестр и дерево объектов ядра. При этом достигается полноценная виртуализация рабочих столов, а пользователи не замечают никакой разницы по сравнению с классическим вариантом, потому что видит десктоп серверной ОС, специальными темами «перекрашенный» в привычную ему клиентскую операционную систему. В среднем в таком варианте требуется в полтора раза меньше вычислительных ресурсов и ресурсов СХД, чем в случае гипервизора. Нельзя сказать, что этот вариант однозначно экономичнее, чем классическая VDI, но при определенных условиях экономия на вычислительной мощности серверной части может стать главной и оправдать внедрение с точки зрения бизнеса. Стоит сказать, что на сегодняшний момент это все еще не до конца признанная технология виртуализации десктопов (Microsoft до сих пор не оказывает поддержку при таком варианте VDI) и часть возможностей, доступных гипервизорной виртуализации, недоступна контейнерной.

Вот актуальные на сегодня подходы к VDI. Что же дальше? А дальше путь идет «в облака». Например, уже сегодня в VMware Horison 7 в версии Enterprise реализован запуск десктопов и приложений с помощью облачной автоматизации. Однако стоит учесть, что согласно лицензионным правилам Microsoft, на настоящий момент доставка клиентского десктопа из публичного облака запрещена. Единственное «послабление» сделано для продуктов Citrix. В начале 2016 года компании Citrix и Microsoft объявили о том, что единственным легальным вариантом будет развернутая в облаке Microsoft Azure система XenDesktop. В этом случае можно будет отдавать пользователю Windows 10 в качестве десктопа. XenDesktop уже сейчас можно развернуть «из коробки» в облачных средах Amazon Web Services, Microsoft Azure или в рамках Cloud Platform.

Пока что это лишь зачатки «включения» в продукт виртуализации облачных сред, но действительность ИТ с все возрастающим множеством «..aaS» говорит о том, что возможно появится и аббревиатура «VDI-as-a-Service». Реализуется поддержка программных продуктов конкурента, а также работа с максимальным числом ОС и ПО, как открытого, так и проприетарного. Что ждет VDI – покажет время, но очевидно, что трансформация не останавливается, становится доступнее и проще. Возможно, мы застанем те времена, когда «толстый» клиент полностью будет вытеснен тонким.

Источник

Как быстро перевести компанию в онлайн с виртуализацией — Windows Virtual Desktop

Все переходим на «удалёнку»! Это стало главной задачей примерно 2 месяца назад, когда мир изменился. Компаниям, которые мы обслуживаем как архитекторы облачных решений, в дополнение к настройке VPN к своей инфраструктуре понадобились удалённые рабочие столы. Удалённые рабочие столы для компаний нельзя назвать новой потребностью, которая ранее не была закрыта в компаниях вообще – у многих были и есть крупные локальные фермы VDI и терминальные сервера. Из-за массовости и скорости необходимого перехода на первый план у заказчиков, в разной степени, появились следующие проблемы:

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

Предоставление сервиса удалённых рабочих мест (VDI) и терминальных серверов в масштабах компании, даже небольшой, требует существенного объёма работы от администраторов. Большая часть времени уходит на настройку и интеграцию множества компонентов, из которых состоит эти сервис. Microsoft предлагает посмотреть на эту задачу по новому с Windows Virtual Desktop (WVD). WVD это облачный сервис по виртуализации десктопов и приложения на базе Microsoft Azure. Главные преимущества WVD включают:

WVD Fall 2019 Release (GA) и Spring 2020 Update (Preview)

30 апреля в WVD стал доступен новый функционал, который сгруппирован под названием Spring 2020 Update. Этот функционал сейчас доступен в Public Preview и на него не распространяется SLA. На GA функционал, предоставляемый в рамках предыдущей версии — Fall 2019 Update, предоставляется с SLA 99.9%. ВМ, на базе которых предоставляются пулы для пользовательских сессий, покрываются своим SLA 99.95%. Функционал, связанный с Spring 2020 Update, планируется к переводу в GA в течение 2020 года. Так же будут подготовлены инструменты миграции экземпляров, построенных на базе Fall 2019 release, в новую версию.

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

Оценка стоимости

На странице Windows Desktop Pricing в разделе Personal Desktop и Multi-session Desktop example scenarios приведены ссылки на расчёты в калькуляторе, которые компонуют необходимые дополнительные ресурсы, такие как облачное хранилище для контейнеров профилей, сетевой трафик и т.д. с точки зрения стоимости преимущества использования WVD максимально проявляет себя при использовании Windows 10 Enterprise multisession в сценарии использования совместного пула. При интеграции с локальным ЦОД в расчёт стоит дополнительно включать стоимость Azure VPN Gateway и исходящего трафика.

Архитектура Microsoft Windows Virtual Desktop

Понимание архитектуры WVD позволит вам принять правильные решения при планировании и развёртывания сервиса, а также выстроить корректные ожидания от его производительности.

Для обсуждения, давайте разобьём архитектуру на блоки:

Клиенты

Конечный пользователь может подключаться к сервису как с использованием тонкого клиента через веб браузер, так и через толстый клиент на Windows, Mac, iOS, Android (все клиенты здесь). После авторизации пользователь видит иконки для подключения к удалённым десктопам или приложениям RemoteApp. Доступ к удалённым десктопам происходит по протоколу RDP поверх HTTPS. Дополнительным преимуществом использования толстого клиента на Windows является то, что опубликованные приложения синхронизируются в меню Старт.

Доступ происходит к единой публичной отказоустойчивой (SLA 99.5%) точке сервиса по адресу https://rdweb.wvd.microsoft.com/. Кастомизировать URL возможно с использованием сервиса Azure Front Door как описано здесь.

При логине в сервис используется учётная запись в Azure Active Directory (aka Azure AD), который вам необходимо иметь или создать. В облачной Azure AD необходимо создать учётные записи для пользователей или настроить синхронизацию УЗ через Azure AD Connect из вашей локальной сети. Для повышения безопасности доступа при аутентификации пользователя можно настроить использование Azure MFA, а так же создать другие дополнительные политики аутентификации с использованием Conditional Access (как описано здесь)

Для усиления безопасности функции клиента можно ограничить через кастомные настройки RDP, такие как отключение работы буфера обмена (clipboard), проброса локальных дисков внутрь удалённой сессии и т.д. Настройка производится как описано здесь, полный список свойств, которые можно использовать, можно посмотреть здесь.

Windows Virtual Desktop

Это управляемая Microsoft-ом часть сервиса Windows Virtual Desktop, отвечающая за авторизацию пользователей, безопасный доступ к пулам десктопов, логгирование событий сервиса. Подключение к ВМ происходит с использованием подхода «reverse connect» – авторизации/аутентификации подключения по WebSocket по 443-порту с инициацией со стороны ВМ. Таким образом из Интернет не предоставляется прямой доступ к ВМ и нет открытых в Интернет портов. Процесс открытия сессии выглядит следующим образом:

Облачная часть

При создании экземпляра сервиса WVD, в Azure AD создаётся конфигурационная запись WVD tenant (тенанта). В Azure SQL DB управляемой части сервиса хранятся т.н. метаданные, относящиеся к ресурсам этого тенанта: соответствие десктопов и приложений пользователям, конфигурация пулов, список опубликованных приложений и так далее. В Fall 2019 Release эти данные хранятся в ЦОДах в США (см здесь). По мере развития сервиса Spring 2020 Release появится возможность хранить метаданные в других регионах, в том числе в West Europe.

Сессионные ВМ, на базе которых предоставляются десктопы и приложения, а так же профили пользователей хранятся в регионе Azure (ЦОДе), который вы выберите при развёртывании этих компонентов. Для максимальной производительности все компоненты сервиса стоит располагать в едином регионе.

Свой ближайший ЦОД вы сможете выбрать с использованием инструмента Windows Virtual Desktop Experience Estimator, который измерит задержку (RTT – round trip time) от вашего рабочего места до ЦОДа и обратно. По опыту работы для большинства пользователей из России ближайшим является регион West Europe.

Конечные пользователи и их техническая поддержка смогут в процессе работы мониторить производительность удалённого подключения с использованием Connection Experience Indicator for RDS & WVD.

Необходимым условием развёртывания экземпляра сервиса является присоединение виртуальных машин пула к AD DS. AD может быть как облачной на базе Azure AD (AAD DS), так и на базе локального AD. При настройке WVD для большинства сценариев подходит использование Azure AD DS, он достаточно быстро и просто настраивается. AAD DS также поддерживает работу с групповыми политиками.

Если вам необходима интеграция с локальным AD, тогда необходимо настроить VPN из Azure в локальную инфраструктуру. Об этом подробнее расскажем в разделе «локальная часть». Для развёртывания AAD DS в виртуальной сети в Azure необходимо создать выделенную подсеть. При развёртывании AAD DS будет необходимо указать УЗ, которую можно будет использовать для введения ВМ в домен. Для данной УЗ будет необходимо произвести процедуру сброса пароля для синхронизации хэша пароля в формате, который использует сервис по процессу, описанному здесь. После развёртывания AAD DS, необходимо в настройках сервиса указать его как источник DNS записей для вашей виртуальной сети.

При создании пула сессионных ВМ вы можете воспользоваться предложенным размером ВМ – D4s_v3 (4 vCPU, 16GB памяти) или указать более подходящий вам. Критичным может оказаться выбор размера ВМ в пуле. Одним из подходов к определению размера ВМ является разделение пользователей по типам: Light, Medium, Heavy и Power, которым будут соответствовать конфигурации как описано здесь.

Это подход может помочь при бюджетной оценке решения и первом подходе, но реальность внесёт свои коррективы. Для эмпирической оценки мощностей необходимых для обеспечения работы ваших пользователей можно использовать бесплатную версию SysTrack Windows Virtual Desktop Assessment.

Ресурсы в пулах представляются в двух вариантах – pooled и dedicated – совместные и выделенные ВМ. При использовании «совместного» пула несколько пользователей могут подключаться на одну ВМ в формате терминального сервера, в «выделенном» — ВМ закрепляется за конкретным пользователем. При начале работы с WVD можно начинать рассмотрение с ВМ серии:

Рекомендуемым типом диска для ВМ в пулах WVD является SSD диск типа «Premium». Диск для данного типа в стандартных образах ОС имеет размер 128GB (P10) и соответствующей этому размеру производительность – 500 IOPS (кратковременная пиковая до 3.5K IOPS), 100 MiB/sec. Производительность локального диска можно поднять, увеличив его размер до 2TB (P40).

По умолчанию профили пользователей размещаются на локальных дисках виртуальных машин в пуле. Ограничение такого подхода, является как сравнительно небольшая максимальная производительность локальных дисков, так и доступность профиля при выходе ВМ из строя при сбое или апгрейде. Вторым вариантом является размещение профиля на сетевом диске. Существует несколько технологий удалённого хранения профиля пользователей — Roaming user profiles (RUP), User profile disks (UPD), Enterprise state roaming (ESR). Каждый из этих подходов имеет свои ограничения при обеспечении работы подробно описанные здесь.

В 2018 году Microsoft приобрёл технологию FSLogix, которая решает многие вызовы при работе с профилями. При подключении к удалённому десктопу или запуске удалённого приложения, через сервис WVD, FSLogix динамически подключается к сетевому ресурсу и с него подключает контейнер c профилем пользователя. FSLogix так же интегрируется с облачным решением Azure Files (SLA 99.9%) и AD – как облачным так и локальным. Ввиду высокой скорости работы и соотношения цена/функционал связка FSLogix/Azure Files/Azure AD является отличным вариантом для использования совместно с WVD.

Для высокой масштабируемости и производительности Azure Files (до 100K IOPS, 5GBps пропускной способности при задержке в 3ms) рекомендуется использовать редакцию Premium. При использовании редакции Premium производительность папки завязана на её размер, и как результат на стоимость. Более подробно о расчёте производительности и цены для редакцию Premium смотрите здесь. Стоит обратить внимание на возможности в Premium редакции накапливать «кредиты» и использовать их для кратковременного ускорения при пиковых нагрузках.

Ввиду необходимости подключения контейнера FSLogix к ВМ с ACL соответствующими пользователю необходимо интегрировать сервис с AD – облачным или локальным. Интеграция Azure Files c Azure AD доступна в GA, тогда как интеграции с локальным AD сейчас находится в Preview. Подключение ВМ к Azure Files так же возможна с применением Private Endpoint, которые предоставляют доступ к сервису с использованием приватной адресации в Azure.

Сценарии и преимущества других вариантов хранения профилей с использованием FSLogix таких как Azure NetApp Files или Storage Spaces Direct описаны здесь. При использовании контейнеров FSLogix необходимо обратить внимание на их размер по умолчанию (30GB) и ознакомиться с возможными инструментами для управления ими.

Для оценки производительности ВМ в пуле, можно воспользоваться встроенным средством Azure Monitor.

При развёртывании WVD необходимо заранее запланировать распределение подсетей внутри виртуальной сети Azure. В зависимости от конфигурации, которую вы развёртываете, вам могут потребоваться:

При необходимости включения в образ дополнительного ПО это можно сделать несколькими способами:

Локальная часть

Интеграция с корпоративными приложениями и ресурсами «локального» ЦОД может осуществляться через site-to-site VPN, построенный на базе Azure VPN Gateway или Network Virtual Appliance (NVA). При развёртывании Azure VPN Gateway необходимо создать отдельную подсеть с зарезервированным названием GatewaySubnet с минимальным размером в /27. NVA развёртываются на базе ВМ, без определённых требований к наименованию подсети. В случае использования NVA, направить трафик на него возможно с помощью User Defined Routes.

NVA может как передавать весь трафик для фильтрации в локальном ЦОД, так и фильтровать его в облаке. При использовании Azure VPN GW установить ограничения трафика на L4 можно с помощью Network Security Group (NSG), которую необходимо применять на подсеть с ВМ, входящими в пул. При фильтрации трафика, стоит принять ко вниманию, что для корректного функционирования WVD пулу ВМ необходим доступ к списку URL. NSG позволяют предоставлять доступ к сервисам на базе Service Tags (коллекции IP адресов, которые относятся к каждому сервису). Фильтровать трафика в Azure на базе URL можно через NVA (в облаке или локальном ЦОДе) или через Azure Firewall. Для минимизации задержек рекомендуется использовать решение для фильтрации, расположенное в Azure.

При развёртывании VPN-решения стоит обратить внимание на его пропускную способность. При использовании NVA производительность определяется лицензией и сетевой картой выбранной вами ВМ. Для развёртывания Azure VPN GW используется SKU соответствующей производительности. Необходимо обратить внимание, что в дополнение к почасовой стоимости Azure VPN GW или ВМ для NVA также оплачивается исходящий из облака трафик.

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

Light: 75Kbps
Medium: 150Kbps
Heavy: 500Kbps
Power: 1000Kbps

Для точной оценки объёма используемого трафика его следует замерить на сетевом оборудовании или ПО, таком как бесплатная версия SysTrack Windows Virtual Desktop Assessment

Заключение

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

Источник