RDS или VDI: как рассчитать инфраструктуру под пользователей и приложения

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

В первом случае обычно рассматривают RDS — многопользовательские сеансы на Windows Server. Во втором может потребоваться VDI — отдельные виртуальные рабочие столы. Оба варианта позволяют сотрудникам подключаться удалённо, но по-разному используют серверные ресурсы, хранят профили, изолируют приложения и масштабируются.

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

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

Чем RDS отличается от VDI

В этой статье под RDS понимается сеансовая модель на базе RD Session Host: несколько пользователей одновременно работают на одном Windows Server, но каждый получает отдельный сеанс.

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

Как устроена общая среда RDS

На терминальном сервере работают:

• одна серверная операционная система;
• общие установленные приложения;
• службы Windows;
• антивирус и средства защиты;
• пользовательские сеансы;
• локальные или контейнерные профили.

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

Главное преимущество RDS — плотное использование ресурсов. Операционная система и приложения устанавливаются один раз, а не повторяются в каждой виртуальной машине.

Такая модель хорошо подходит, когда сотрудники:

• используют одинаковый набор программ;
• не нуждаются в локальных административных правах;
• выполняют похожие операции;
• могут работать на общей версии Windows Server;
• не запускают конфликтующие драйверы и службы;
• не требуют жёсткой изоляции друг от друга.

Как устроены виртуальные рабочие столы VDI

В VDI каждый активный рабочий стол представляет собой отдельную виртуальную машину. У неё есть собственные:

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

Виртуальные рабочие столы могут быть персональными или пуловыми.

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

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

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

Где проходит граница изоляции

В RDS изоляция существует на уровне сеансов, прав и процессов внутри одной операционной системы. В VDI граница проходит между виртуальными машинами.

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

Упрощённое сравнение:

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

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

• на офисный компьютер;
• на Windows VPS;
• на терминальный сервер RDS;
• в виртуальный рабочий стол VDI;
• на административный сервер.

Поэтому вопрос «RDP или VDI» сформулирован некорректно. Сравнивать нужно архитектуры рабочих мест, а не протокол с инфраструктурой.

Подробнее различия между вариантами подключения разобраны в статье «Что такое удалённый рабочий стол: RDP, RDS и VDI».

Какие данные собрать до расчёта

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

Число пользователей и одновременных сеансов

Нужно разделять:

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

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

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

Разделите пользователей по профилям нагрузки

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

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

Составьте перечень приложений

Для каждого приложения фиксируют:

• поддерживает ли оно Windows Server;
• допускает ли многопользовательскую установку;
• можно ли запускать несколько экземпляров;
• какие версии должны использовать сотрудники;
• требуется ли локальная служба;
• устанавливаются ли драйверы;
• нужны ли административные права;
• используется ли аппаратный ключ;
• поддерживается ли работа через RDS или VDI;
• можно ли централизованно обновлять программу.

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

Проверьте периферийные устройства

Удалённое рабочее место может использовать:

• принтеры;
• сканеры;
• смарт-карты;
• USB-токены;
• электронную подпись;
• кассовое оборудование;
• микрофоны и камеры;
• несколько мониторов;
• графические планшеты;
• специализированные контроллеры.

Формальная поддержка перенаправления устройства ещё не гарантирует нормальную работу конкретного приложения. Такие сценарии нужно включать в пилотное тестирование.

Оцените пользовательские профили

В профиле могут храниться:

• рабочий стол и документы;
• настройки приложений;
• кеши браузеров;
• данные Outlook и Microsoft 365;
• временные файлы;
• настройки 1С;
• пользовательские шаблоны;
• данные поиска и индексации.

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

Для переносимых профилей могут использоваться контейнеры FSLogix. Они размещают профиль пользователя в файле VHD или VHDX на сетевом хранилище и подключают его при входе.

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

Определите требования к доступности

До расчёта нужно выяснить:

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

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

Как предварительно рассчитать RDS

Расчёт RDS состоит из четырёх частей:

1. ресурсы операционной системы и серверных служб;
2. нагрузка пользовательских сеансов;
3. фоновые процессы и защитное ПО;
4. резерв на пики, рост и обслуживание.

Рассчитайте оперативную память

Упрощённая формула выглядит так:

RAM RDS = RAM операционной системы и служб + сумма памяти одновременных сеансов + память фоновых процессов + резерв.

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

Предположим, пилот показал следующие значения:

В этом условном примере пользовательские сеансы требуют около 69,5 ГБ. К результату нужно добавить память для Windows Server, RDS-служб, антивируса, мониторинга и других процессов, а затем предусмотреть резерв.

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

Оцените CPU

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

Для пилота собирают:

• среднюю загрузку;
• пиковую загрузку;
• загрузку отдельных ядер;
• длительность пиков;
• очередь процессов;
• время выполнения пользовательских операций;
• поведение системы при одновременном запуске тяжёлых задач.

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

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

Рассчитайте хранилище

Для RDS нужно учитывать:

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

Размер диска — только один параметр. Не менее важна способность хранилища выдерживать одновременные операции чтения и записи.

Особенно заметны:

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

Учтите профильное хранилище

Если используется один RD Session Host и сотрудники всегда попадают на него, локальные профили могут быть допустимы для небольшой среды.

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

При расчёте контейнерного решения учитывают:

• размер одного профиля;
• число активных профилей;
• одновременные входы;
• операции чтения и записи;
• свободное место;
• рост VHD/VHDX;
• резервное копирование;
• доступность файлового хранилища;
• поведение при его отказе.

Высокопроизводительные RD Session Host не помогут, если профильное хранилище медленно подключает контейнеры.

Определите число узлов

Один RDS-сервер проще и дешевле, но его перезагрузка или отказ затрагивают всех пользователей.

Второй RD Session Host может понадобиться, если:

• один узел не выдерживает пиковую нагрузку;
• обновления нельзя проводить с общим простоем;
• требуется распределение пользователей;
• нужен резерв на отказ;
• группы пользователей нужно разделить;
• разные приложения конфликтуют между собой.

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

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

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

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

Персональная VDI-машина закреплена за сотрудником и сохраняет изменения. Она удобна, когда нужны:

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

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

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

Рассчитайте ресурсы виртуальных машин

Для каждой группы определяют шаблон рабочего стола:

После этого ресурсы активных виртуальных машин суммируют и добавляют затраты инфраструктуры:

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

Не суммируйте только зарегистрированных пользователей

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

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

В расчёте фиксируют:

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

Учтите загрузочный шторм

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

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

Поэтому хранилище проверяют не только по объёму, но и по:

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

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

В VDI отдельно учитывают:

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

Снимки виртуальных машин нельзя считать полноценной заменой резервного копирования. Они зависят от основной инфраструктуры хранения и со временем могут увеличивать нагрузку.

Предусмотрите отказ узла

Если VDI работает на нескольких вычислительных узлах, нужно определить, куда будут запущены рабочие столы после отказа одного из них.

Есть два разных подхода:

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

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

Как сравнить полную стоимость и эксплуатацию

Сравнивать только объём CPU и RAM недостаточно. В стоимость входят лицензии, хранилище, резервирование, обновления и трудозатраты администраторов.

Серверные ресурсы

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

VDI требует отдельных экземпляров ОС и чаще потребляет больше RAM и дискового пространства. Но позволяет точнее распределять ресурсы между группами и изолировать тяжёлые рабочие места.

При сравнении учитывают:

• вычислительные узлы;
• оперативную память;
• системные и профильные диски;
• резерв мощности;
• сетевую инфраструктуру;
• резервное копирование;
• тестовую среду;
• ресурсы на период обновления.

Лицензирование

Для RDS необходимо учитывать лицензирование Windows Server, клиентский доступ и RDS CAL, а также лицензии приложений. Сервер лицензирования выдаёт RDS CAL пользователям или устройствам в соответствии с выбранным режимом.

Для VDI состав лицензий зависит от:

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

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

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

Администрирование и обновления

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

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

• версии образов;
• применение политик;
• сохранение профилей;
• обновление персональных машин;
• совместимость приложений;
• возврат на предыдущую версию.

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

Отказоустойчивость

Нужно сравнивать не только вероятность отказа, но и его масштаб.

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

Критичными остаются общие компоненты:

• хранилище профилей;
• аутентификация;
• сеть;
• брокер подключений;
• лицензирование;
• гипервизор;
• резервное копирование.

Пилот важнее расчёта на бумаге

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

В пилот включают представителей каждой группы пользователей и измеряют:

• потребление RAM;
• загрузку CPU;
• дисковые задержки;
• время входа;
• скорость подключения профиля;
• запуск приложений;
• работу 1С;
• печать и периферию;
• мультимедиа;
• поведение при отключении и повторном входе;
• обновление рабочего места.

Когда подходит гибридная схема RDS и VDI

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

Основная группа на RDS

RDS подходит для сотрудников, которые:

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

Такую группу проще обслуживать как общую серверную среду.

Изолированные рабочие места VDI

Отдельные виртуальные рабочие столы можно выделить:

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

Специализированные приложения

Иногда одно приложение не поддерживает работу на RDS или требует версию, несовместимую с программами других сотрудников.

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

Но перед этим нужно проверить альтернативы:

• публикацию приложения через RemoteApp;
• отдельный RDS-узел для группы;
• изменение порядка установки;
• серверную версию приложения;
• устранение конфликта совместимости.

Как не усложнить инфраструктуру без причины

Гибридная схема означает, что компании придётся сопровождать две модели:

• RDS-серверы;
• виртуальные рабочие столы;
• разные образы;
• профили;
• политики;
• лицензии;
• мониторинг;
• резервное копирование.

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

Полезно зафиксировать решение в таблице:

Заключение

RDS и VDI решают одну пользовательскую задачу — предоставляют удалённое рабочее место, — но используют разные архитектурные модели.

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

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

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

Что почитать дальше

• Терминальный сервер на Windows Server: как работает RDS и когда он нужен бизнесу — роли RDS, пользовательские сеансы, профили, лицензирование и безопасность.
• Что такое удалённый рабочий стол: RDP, RDS и VDI — общий обзор вариантов удалённого доступа.
• Активация сервера лицензирования RDS — практический порядок подготовки лицензирования терминальной среды.

Когда стоит обратиться к специалистам

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

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

Если для проекта требуется отдельная серверная среда, можно использовать Windows VPS/VDS для размещения Windows-приложений и компонентов удалённого доступа. Многопользовательскую работу при этом нужно проектировать с учётом ролей RDS и необходимого лицензирования.

Кратко

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