Чем DaaS отличается от локально развернутой VDI?

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

Можно ли дать подрядчикам доступ к VDI с личных устройств?

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

Чем GPU Passthrough отличается от vGPU в VDI?

При vGPU физический графический ускоритель разделяется между несколькими виртуальными машинами. При GPU Passthrough устройство назначается одной VM напрямую. Оба варианта применяют для 3D, CAD, визуализации, видео и других графически интенсивных задач, но совместимость зависит от модели GPU, драйвера, гипервизора, VDI-платформы и их версий.

Можно ли хранить рабочие файлы внутри непостоянного VDI-десктопа?

Нет, если платформа не предусматривает отдельное хранение пользовательских данных и профилей. В непостоянной модели рабочий стол выдаётся из общего пула и по политике может быть сброшен до эталонного состояния или заменён. Поэтому локально сохранённые файлы, изменения настроек и результаты работы могут быть потеряны. До внедрения нужно определить, где будут храниться пользовательские файлы и персональные настройки. Для этого могут использоваться механизмы профилей, перенаправление папок и отдельные средства защиты данных — выбор зависит от платформы и принятой модели эксплуатации. Эти механизмы требуется проектировать отдельно от базового образа рабочих столов. Сброс состояния VM не является резервным копированием. Snapshot виртуальной машины также не заменяет резервную копию. Непостоянный пул подходит только после проверки, что данные и необходимые настройки пользователя сохраняются вне локального состояния выдаваемой VM.

Почему VDI может работать медленно при нормальных ресурсах VM?

Потому что на отклик влияют не только CPU и память виртуальной машины. Для VDI критичны задержка и потери в сети, доступная полоса канала до пользователя, удалённый протокол, качество хранилища и характер приложения. Хорошая сеть внутри дата-центра не компенсирует нестабильный канал между площадкой и клиентским устройством.

VDI: виртуализация рабочих столов, архитектура и выбор сценария

VDI — это централизованная инфраструктура виртуальных рабочих столов: пользователь работает с настольной ОС по сети, а сама ОС и приложения выполняются в виртуальной машине на серверной площадке или в облаке. Это не просто серверная VM с Windows: VDI предназначена для массовой выдачи, назначения, обновления и сопровождения пользовательских рабочих мест. Она полезна, когда такой централизованный жизненный цикл даёт измеримый эффект, но не является обязательным решением для любой удалённой работы.

Где работает рабочий стол при VDI

VDI использует виртуализацию: настольная Guest OS запускается как VM на хостах виртуализации. На пользовательском устройстве — ноутбуке, тонком клиенте, браузере или специализированном клиентском приложении — обычно выполняются ввод с клавиатуры и мыши, воспроизведение изображения, звука и работа с локально разрешённой периферией. Вычисления приложений, память VM и её виртуальные диски находятся в серверной инфраструктуре.

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

VDI не равна настольной VM

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

Компоненты типовой VDI-архитектуры

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

Логические компоненты VDI

Компонент	Роль в инфраструктуре
Хосты и гипервизор	Запускают VM с пользовательскими настольными ОС, распределяют вычислительные ресурсы и подключают VM к сети и хранилищу.
Брокер подключений	Аутентифицирует или использует внешний сервис идентификации, применяет политики и направляет пользователя к назначенному рабочему столу либо свободному экземпляру из пула.
Пул виртуальных рабочих столов	Объединяет похожие десктопы с общими правилами создания, назначения, питания, обновления и сброса состояния.
Сервис доставки рабочего стола	Организует сеанс удалённого отображения между клиентом и VM, передаёт экран, ввод, звук и разрешённые устройства.
Служба идентификации	Хранит учётные записи, группы и часто участвует в едином входе, многофакторной аутентификации и проверке политик.
Золотой образ	Эталонная VM или шаблон с утверждённой ОС, драйверами, агентом VDI и базовым набором приложений; служит источником стандартизированных экземпляров.
Профили и пользовательские данные	Отделяют данные и часть персональных настроек от базового образа, если это требуется выбранной моделью рабочих столов.
Хранилище и сеть	Размещают диски VM и обеспечивают потоки между VM, брокером, службами идентификации, клиентами и периферией.
Клиентское устройство	Предоставляет пользователю интерфейс подключения: тонкий клиент, ПК, ноутбук, браузер или мобильное устройство в пределах поддержки платформы.

Брокер не выполняет пользовательские приложения вместо VM и обычно не передаёт весь экран как единственный посредник. Его задача — найти подходящий ресурс после входа пользователя: закреплённый рабочий стол, активный сеанс или доступный экземпляр пула. За счёт этого можно применять права доступа, запреты по группам, правила повторного подключения и политики выдачи.

Чем VDI отличается от серверной VM, RDS и удалённого ПК

Модель	Где выполняется работа	Единица предоставления	Типичная модель эксплуатации
Обычная серверная VM	На серверной платформе	Отдельная VM под серверную роль: приложение, БД, служба или инфраструктурный компонент	Администратор ведёт VM как самостоятельную систему; массовое предоставление пользовательских рабочих мест не является её основной функцией.
VDI	В отдельной настольной VM на серверной или облачной инфраструктуре	Персональный либо временно выдаваемый виртуальный рабочий стол	Платформа управляет назначениями, пулами, подключениями, образами, профилями и обслуживанием множества рабочих мест.
Терминальный доступ / RDS	На сервере с сеансами пользователей	Пользовательский сеанс или опубликованное приложение	Несколько пользователей могут работать в одной серверной ОС, разделяя её ядро и системную среду в пределах возможностей платформы.
Удалённый доступ к физическому ПК	На конкретном пользовательском ПК	Физическое рабочее место, уже закреплённое за человеком	Удалённый пользователь управляет существующим компьютером; серверный пул настольных VM не создаётся.
DaaS	В инфраструктуре облачного провайдера или управляемой облачной среде	Рабочий стол как облачный сервис	Это модель поставки и эксплуатации; она может использовать механизмы, похожие на VDI, но не тождественна локально развернутой VDI.

Постоянные и непостоянные виртуальные рабочие столы

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

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

Выбор модели рабочего стола

Критерий	Постоянный	Непостоянный
Назначение	Персональное рабочее место с сохраняемым окружением	Стандартизированное рабочее место для взаимозаменяемых пользователей
Изменения внутри VM	Обычно сохраняются	Обычно сбрасываются или заменяются по политике
Профиль и данные	Всё равно требуют отдельной политики хранения и защиты	Критичны: без внешнего хранения пользователь может потерять несохранённое локальное состояние при сбросе
Сопровождение	Больше индивидуальных экземпляров и исключений	Проще повторно развернуть единообразные экземпляры, но требуется зрелое управление профилями и приложениями
Подходящие примеры	Инженер с персональными инструментами, пользователь с индивидуальной конфигурацией	Контакт-центр, учебная аудитория, киоск, типовое офисное рабочее место

Сброс состояния — не резервное копирование

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

Термины persistent/non-persistent, desktop pool, golden image и механизмы возврата к исходному состоянию реализованы у разных платформ по-разному. Например, Microsoft описывает персональные и объединённые в пул узлы сеансов в официальной терминологии Azure Virtual Desktop, а Citrix использует собственную модель каталогов машин и групп доставки, изложенную в руководстве по созданию каталогов машин Citrix Virtual Apps and Desktops. Платформы могут применять клоны, шаблоны, диски состояния, средства профилей и другие механизмы. Ограничения создания, обновления, отката и совместимости нужно сверять в официальном руководстве именно выбранного продукта и его версии.

Золотой образ не отменяет сопровождение

Золотой образ позволяет обновить одну эталонную конфигурацию и автоматически создать или обновить множество десктопов в пуле вместо ручной работы с каждым экземпляром. Это особенно полезно для непостоянной модели. Однако образ нужно тестировать так же внимательно, как и обычную ОС: обновление ОС, драйвера, агента VDI, средства защиты или приложения может нарушить вход, работу профиля, печать, USB-устройства или удалённое отображение.

Как безопасно обновлять базовый образ VDI

Это общий порядок принятия изменений, а не инструкция для конкретной VDI-платформы.

1
Зафиксировать состав образа и зависимостей
Опишите версию ОС, агента VDI, драйверов, приложений, настроек профилей и политик. Ожидаемый результат — список, по которому можно отличить новую редакцию образа от предыдущей. Если состав неизвестен, сначала проведите инвентаризацию, а не обновляйте действующий образ.
2
Проверить изменение на тестовом экземпляре
Создайте тестовую копию или тестовый пул в поддерживаемом выбранной платформой порядке и примените обновление там. Проверьте вход пользователя, запуск критичных приложений, профиль, печать, разрешённую периферию и выход из сеанса. Если тест не пройден, не распространяйте образ на производственный пул.
3
Определить воздействие на существующих пользователей
Уточните, требует ли платформа пересоздания VM, перезагрузки, отключения сеансов либо отдельной миграции профилей. Ожидаемый результат — согласованное окно работ и порядок отката. При отсутствии понятного отката оставьте предыдущий работоспособный образ доступным в пределах политики хранения.
4
Раскатить изменение поэтапно
Сначала назначьте новую версию ограниченной группе пользователей и наблюдайте за входами, ошибками приложений и задержками. При стабильном результате расширяйте охват. При массовых сбоях остановите дальнейшее распространение и вернитесь к предыдущей утверждённой версии по процедуре платформы.

Что оценить до решения о VDI

Нельзя получить достоверную плотность пользователей, разделив число ядер или объём RAM на условную норму «на один рабочий стол». Пики нагрузки VDI часто вызывают одновременный вход пользователей, запуск тяжёлых приложений, обновления или завершение смены. Для проектирования серверов, запаса на отказ и детального подбора CPU, памяти, сети и хранения используйте материал «Как спроектировать виртуальную инфраструктуру для продакшена и 1С».

Пользовательские роли и одновременность. Разделите лёгкие офисные, операторские, инженерные, графические и иные нагрузки. Считайте не только зарегистрированных пользователей, но и тех, кто реально работает одновременно.
CPU и память. Нужны фактические профили приложений, а не только выделенные vCPU и RAM VM. Учитывайте всплески при входе, браузерах, антивирусной проверке, обновлениях и запуске приложений.
Хранилище. Оцените задержку, IOPS и пропускную способность при массовом включении, загрузке ОС, входе и обновлении пулов. Особенности datastore и vSAN разобраны в статье «Datastore и VMware vSAN: как организовать хранение виртуальных машин».
Сеть до площадки. Проверьте задержку, потери пакетов, доступную полосу, маршрутизацию, VPN или иной защищённый доступ. Хорошая сеть внутри дата-центра не компенсирует нестабильный канал до пользователя.
Периферия. Определите необходимость печати, сканеров, смарт-карт, камер, гарнитур, USB-устройств, нескольких мониторов и специальных драйверов. Каждое устройство проверяют в поддерживаемой комбинации клиента, протокола и ОС.
Доступность. Спланируйте последствия недоступности хоста, хранилища, сети, брокера, службы идентификации и канала связи. Централизация превращает часть локальных проблем в общую точку воздействия.
Эксплуатация и лицензии. Учтите лицензии гостевой ОС, права на виртуальные Windows-рабочие столы, VDI-платформу, клиентские компоненты, поддержку и возможные требования к внешнему доступу.

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

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

1
Сегментировать пользователей
Соберите группы по приложениям, периферии, уровню персонализации, графическим задачам и режиму работы. Результат — несколько профилей вместо усреднённого «пользователя VDI». Если в одной группе оказываются офисный оператор и специалист САПР, разделите её.
2
Измерить пики существующей работы
Зафиксируйте время массового входа, запуска приложений, обновлений и характерные жалобы на отклик. Результат — временные окна и показатели, по которым можно проверить пилот. Если телеметрии нет, начните со сбора метрик на репрезентативной группе, а не с расчёта по паспортным характеристикам ПК.
3
Проверить критичные приложения и устройства
Составьте перечень приложений, драйверов, устройств и требований к нескольким мониторам, звуку и видео. Результат — список обязательных тестов. Если поставщик приложения не поддерживает работу в виртуальной или удалённой среде, зафиксируйте риск до закупки.
4
Провести пилот на реальном профиле
Пилотируйте каждый значимый профиль в условиях, близких к рабочим: с реальной сетью, аутентификацией, периферией и одновременными входами. Результат — измерения отклика, нагрузки хостов, задержек хранилища и обращений в поддержку. При неудовлетворительном результате локализуйте ограничение — приложение, сеть, хранилище, профиль или клиент — до масштабирования.
5
Сверить права использования
До развёртывания подтвердите у правообладателей и в лицензионных документах выбранные редакции и модель доступа к гостевым ОС и VDI-платформе. Результат — документированный расчёт для целевого числа пользователей и устройств. Если права не подтверждены, не заменяйте проверку предположением, что лицензия физического ПК автоматически покрывает виртуальный рабочий стол.

Когда VDI рациональнее физических ПК

Однотипные рабочие места со сменным графиком

1. Однотипные рабочие места со сменным графиком

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

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

Повторяемое предоставление рабочего места новым сотрудникамМеньше индивидуальных изменений в базовой ОСБолее контролируемое размещение данных при корректно настроенных правах и защите

Регулируемый доступ к внутренним системам

1. Регулируемый доступ к внутренним системам

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

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

Рабочая среда предоставляется по единым правиламЛегче отозвать доступ к централизованному рабочему местуМожно стандартизировать клиентские требования

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

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

VDI, виртуализация GPU и графические задачи

Обычным офисным VDI-десктопам выделенный GPU требуется не всегда. Для 3D, CAD, визуализации, видео и других графически интенсивных задач могут использоваться vGPU, когда физический ускоритель разделяется между VM, либо GPU Passthrough, когда устройство назначается одной VM напрямую. Это не свойства VDI как таковой, а отдельные архитектурные решения.

Поддержка vGPU, passthrough, удалённого отображения с аппаратным кодированием, миграции графических VM и многомониторных конфигураций зависит от модели GPU, драйвера, гипервизора, VDI-платформы и их совместимых версий. Эти комбинации проверяют по официальным матрицам каждого поставщика и тестируют на пилоте. Настройка passthrough и вложенной виртуализации рассматривается отдельно в статье «GPU passthrough и вложенная виртуализация в ESXi и Proxmox VE».

Безопасность и облачная виртуализация: связанные, но отдельные темы

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

VDI можно развернуть в собственной серверной инфраструктуре, в частном облаке или получить как облачный сервис. Облачная виртуализация меняет модель размещения и эксплуатации, но не отменяет вопросы профилей, приложений, сети до пользователей, периферии, лицензирования и ответственности за доступ. Архитектура частного облака на KVM рассмотрена в статье «OpenStack как частное облако поверх KVM: компоненты и границы выбора».

Проверьте лицензии до пилота и масштабирования

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

Термины в статье

Брокер подключений: Брокер подключений — компонент инфраструктуры удалённых рабочих столов, который с учётом личности пользователя и политик доступа назначает ему сеанс или виртуальный рабочий стол.
Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Группа пользователей: Группа пользователей — объект разграничения доступа, объединяющий учётные записи под общим GID для назначения прав на файлы, службы и иные ресурсы нескольким пользователям.
Золотой образ: Золотой образ — эталонный шаблон ОС или виртуальной машины с утверждённой конфигурацией, из которого создают стандартизированные экземпляры.
Клонирование виртуальной машины: Создание копии виртуальной машины как отдельной ВМ; полный клон независим от исходной ВМ, а связанный использует её базовые виртуальные диски.
Непостоянный виртуальный рабочий стол: Непостоянный виртуальный рабочий стол — VDI-десктоп, локальное состояние которого сбрасывается после сеанса или по заданной политике обслуживания.
Постоянный виртуальный рабочий стол: Постоянный виртуальный рабочий стол — VDI-десктоп, закреплённый за пользователем и сохраняющий изменения ОС, приложений и пользовательских данных между сеансами.
Пул виртуальных рабочих столов: Пул виртуальных рабочих столов — логическая группа VDI-десктопов, управляемых по общим правилам создания, назначения пользователям, доступа и обслуживания.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Хост виртуализации: Хост виртуализации — физический сервер или вычислительная система, на которой работает гипервизор и размещаются виртуальные машины; его CPU, память, сеть и хранилище распределяются между гостями.
Частное облако: Частное облако — облачная среда для исключительного использования одной организацией с централизованным управлением и самообслуживанием пользователей.
Шаблон виртуальной машины: Подготовленный объект платформы виртуализации с образом ОС и заданной конфигурацией для повторяемого развертывания новых виртуальных машин.
Datastore: Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
GPU Passthrough: Режим назначения физического GPU виртуальной машине через PCIe/IOMMU, при котором гостевая ОС обращается к устройству напрямую с минимальными накладными расходами.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
IOPS: IOPS — число завершённых операций ввода-вывода в секунду, которое накопитель, RAID-массив или СХД обеспечивает при заданном профиле нагрузки.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
Nested Virtualization: Вложенная виртуализация — возможность запускать гипервизор и виртуальные машины второго уровня внутри обычной виртуальной машины.
vCPU: vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
VDI: VDI — архитектура, в которой пользовательские рабочие столы выполняются в виртуальных машинах на централизованной инфраструктуре, а пользователи подключаются к ним удалённо.
vGPU: vGPU — технология предоставления каждой ВМ отдельного виртуального GPU-устройства, позволяющая нескольким ВМ совместно использовать физический ускоритель.
vSAN: Программно-определяемое хранилище VMware, объединяющее локальные накопители хостов ESXi в общее распределённое хранилище с управлением через политики.