RDS для сотрудников в две смены: как выбрать модель лицензий и сервер

Представим склад или call-центр с графиком «с 8:00 до 20:00 и с 20:00 до 8:00». В зале стоят десять рабочих мест. Утром за ними садятся десять человек, вечером приходят другие десять, а на стыке смен пара человек задерживается, чтобы закрыть заявки. Вопрос звучит просто: сколько лицензий RDS покупать и какой сервер брать? Но под ним лежат два совершенно разных расчёта, и их нельзя смешивать. Один отвечает на вопрос «кому и с чего разрешено подключаться», другой — «сколько памяти и процессора съедят сеансы в самый тяжёлый час». Лицензия не делает сервер быстрее, а мощный сервер не заменяет право на доступ.

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

Три величины, которые постоянно путают

В разговорах о терминальном сервере почти всегда подменяют друг другом три понятия:

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

Эти величины живут независимо. Один человек может завести три сеанса с трёх устройств. Одно устройство за сутки обслужит четырёх людей, но в каждый момент времени на нём открыт один сеанс. Сервер «чувствует» только сеансы. Лицензионная модель смотрит на пользователей или устройства. Поэтому число одновременных входов, которое вы увидите в диспетчере, не равно числу лицензий, и наоборот.

Корпорация Microsoft в описании клиентских лицензий RDS говорит, что подключения к узлу сеансов лицензируются по пользователям или по устройствам, а сервер лицензирования выдаёт и отслеживает CAL. Там же подчёркивается, что версию CAL нужно сверять с версией Windows Server, а лицензия на саму операционную систему и право на удалённые рабочие столы — это разные вопросы. Для нашей задачи вывод практический: даже если у вас уже есть Windows Server, это ещё не закрывает доступ людей к сеансам.

Два графика, на которых модели расходятся

Чтобы увидеть разницу, возьмём два небольших условных случая.

График А: закреплённые места, люди меняются

В зале 10 компьютеров, принадлежащих компании. Дневная смена — 10 человек, ночная — другие 10. Каждый сотрудник работает только за рабочим местом в зале. Всего пользователей 20, устройств 10, одновременных сеансов в обычное время 10, на перекрытии смен — до 12–13, потому что уходящие ещё закрывают дела, а пришедшие уже вошли.

Здесь каждое устройство за сутки обслуживает двух разных людей. По описанию Microsoft, модель Per Device рассчитана на устройство, которым пользуются разные люди. Это как раз наш случай: потребность выражается числом 10 устройств, а не 20 пользователей. Модель Per User в этой конфигурации привязывалась бы к 20 людям, то есть формально потребовала бы вдвое больше единиц учёта. Вывод из графика: чем больше людей приходится на одно общее устройство, тем привлекательнее выглядит счёт по устройствам.

График Б: свои устройства у сотрудников

Теперь другая картина. В штате 20 человек, 10 днём и 10 ночью. Работают они из дома или с рабочих мест, но у многих есть по два устройства: ноутбук и телефон, а кто-то заходит ещё и с домашнего компьютера. Условно, у 20 человек набирается 38 устройств. Одновременно сеансов, как и раньше, 10–13.

Описание Microsoft относит Per User к пользователю, который работает с нескольких устройств. Счёт здесь идёт по 20 людям, и добавление ещё одного смартфона не увеличивает потребность. При лицензировании по устройствам пришлось бы считать все 38 устройств, которые подключаются к серверу. Модель сменилась, а нагрузка на сервер осталась той же.

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

Чтобы стало видно, как арифметика ведёт себя при небольших изменениях, пошевелим исходные числа. В графике А пусть ночную смену усилят: вместо 10 человек придут 14, а зал останется на 10 мест. Пользователей станет 24, устройств по-прежнему 10, и единица учёта «устройство» не изменится, а «пользователь» вырастет на четыре. Теперь обратный ход: в графике Б двое сотрудников отказываются от телефона для работы. Устройств станет 36, пользователей по-прежнему 20, то есть счёт по людям вообще не заметит этого изменения. Видно закономерность: при учёте по пользователям стоимость растёт вместе со штатом, при учёте по устройствам — вместе с парком техники. Поэтому прогноз найма и планы по закупке компьютеров нужно держать рядом, прежде чем сравнивать модели (описание выбора модели RDS).

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

Почему пик сеансов не определяет число CAL

Соблазн велик: «одновременно работают максимум 13, значит, нужно 13 лицензий». Такая логика была бы уместна в схеме с конкурентными лицензиями, но в тех терминах, которыми Microsoft описывает выбор между Per User и Per Device, счёт ведётся не по моменту, а по субъекту — человеку или устройству. В графике А на перекрытии смен работают 13 сеансов, но за сутки в системе побывали 20 человек и 10 устройств. В графике Б — те же 13 сеансов при 20 людях и 38 устройствах. Из одного только пика нельзя восстановить ни тот, ни другой счёт.

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

Где граница ситуаций получается размытой

Реальные графики редко бывают чистыми. Возможны смешанные варианты: часть мест общая, часть сотрудников приходит со своим ноутбуком, подрядчик подключается эпизодически. Модели, как следует из документации Microsoft, различаются по тому, на что рассчитан каждый тип: пользователь с несколькими устройствами или устройство для нескольких людей. Вопрос о том, допустимо ли и выгодно ли сочетать их в одной среде и как это отслеживается, нужно выяснять у поставщика лицензий на конкретной версии. Для провайдерского размещения Microsoft отдельно описывает SAL, то есть другую договорную рамку; она устроена иначе, чем покупка CAL самостоятельно.

Лицензия — не принадлежность сервера

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

Важная оговорка про MAATRIX: лицензии Windows и RDS не следует считать включёнными в VPS по умолчанию. В публичном предложении перечислены NVMe-диски, процессоры AMD EPYC и root-доступ; о лицензиях Windows Server и клиентских лицензиях RDS там речи не идёт. Поэтому закладывайте их как отдельную статью и уточняйте до заказа, а наличие нужного образа системы проверяйте в форме заказа.

Перекрытие смен: где рождается пик

Теперь о ресурсах. Здесь работает совсем другая арифметика: считается не «кто имеет право», а «сколько сеансов одновременно и что в них запущено». Для двух смен ключевая величина — не общее число людей, а размер перекрытия. Если смены стыкуются жёстко, в 20:00 и вечерние пришли, и дневные ушли, пик остаётся близким к десяти. Если люди приходят на 20 минут раньше, а уходящие задерживаются, возникает «горб» в расписании.

Есть и менее заметные эффекты. В начале смены все входят почти одновременно, и сервер переживает волну загрузки профилей, запуска офисных программ и клиента основной учётной системы. В конце смены многие делают отчёты и выгрузки. Среднесуточная нагрузка может выглядеть мирно, а вход в 8:00 и выход в 20:00 нет. Сервер нужно оценивать по этим коротким окнам.

Ещё одна деталь: незавершённые сеансы. Если человек закрыл окно, не выйдя из системы, сеанс может оставаться на сервере и занимать память. Утром такой «хвост» суммируется с новыми входами. Поэтому в расчёт пика стоит закладывать не только активных, но и оставленных сеансов, а политику их завершения — обсудить заранее. Конкретные настройки зависят от версии Windows Server, и подбирать их нужно по документации той версии, которую вы используете.

Покажем на условных числах, как «хвост» меняет пик. Пусть к 20:00 в графике А дневная смена в основном вышла, но двое закрыли окно, не завершив сеанс, и их сеансы остались на сервере. Вечерние входят почти одновременно, и на сервере оказывается 10 новых сеансов, 2–3 задержавшихся человека на перекрытии и 2 забытых. Это уже не «около 13», а ближе к 15 сеансов в памяти, хотя за клавиатурой по-прежнему не больше 13 человек. Для лицензий этот хвост ничего не меняет: пользователей и устройств осталось столько же. Для памяти он меняет всё, потому что каждый оставшийся сеанс держит свои процессы и открытые программы. Отсюда практический вывод: в таблице пика заводите отдельную строку «незавершённые сеансы» и заполняйте её по наблюдению во время пилота, а не по надежде на дисциплину.

Вторая причина считать окна входа отдельно — их форма. Если смена начинается ровно в 8:00 и все садятся за компьютеры в течение пяти минут, запуск программ и загрузка профилей накладываются друг на друга. Если же ввести ступенчатый вход, например по группам с разницей в несколько минут, общая нагрузка за то же число людей распределится мягче. Это организационная мера, которая иногда экономит ступень тарифа, поэтому её стоит обсудить с руководителем смены до покупки.

Какая нагрузка у сеанса на самом деле

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

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

Допустим, в пик у нас 13 сеансов: 6 лёгких, 5 средних и 2 тяжёлых. Реальные потребности каждого профиля мы не знаем и придумывать их нельзя: их даёт только замер на ваших приложениях. Но сама схема расчёта понятна: сумма «число сеансов × потребление профиля» плюс запас на систему и на пиковые окна входа. Память, как правило, ограничивает раньше процессора, потому что каждый сеанс держит собственный набор процессов; процессор же упирается в моменты массового входа и тяжёлых отчётов. Это общее рассуждение, а не обещание: на вашем наборе программ узким местом может оказаться и диск.

Разберём схему на тех же 13 сеансах, подставив вместо неизвестных величин буквы. Пусть для лёгкого сеанса пилот покажет потребление памяти L, для среднего M, для тяжёлого H. Тогда оценка памяти в пик равна 6 × L + 5 × M + 2 × H плюс память системы и запас на «хвосты». Если к 13 сеансам добавить два забытых сеанса среднего профиля, формула получит ещё 2 × M. Такая запись полезна тем, что показывает чувствительность: тяжёлых сеансов всего два, но если H в несколько раз больше M, именно они определят итог, и экономить стоит на их оптимизации, а не на лёгких.

Тот же подход помогает прочитать таблицу тарифов MAATRIX: у Heka 4 vCPU и 8 ГБ RAM, у Maat 8 vCPU и 16 ГБ, то есть ступень удваивает обе величины (публичное предложение VPS). Когда в формулу подставлены замеренные L, M и H, вы видите, ближе ли итог к одной ступени или к другой, и можете сравнить это с запасом, а не выбирать «на глаз». Сами значения ресурсов остаются отправной точкой для проверки, а не заявленной ёмкостью.

Как получить свои цифры

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

От расчёта к VPS

Когда вы получили оценку пиковой потребности, её нужно сопоставить с вариантами конфигураций. В каталоге MAATRIX представлены тарифы с такими ресурсами:

Эта таблица — ориентир для старта теста, а не обещание ёмкости. Нельзя утверждать, что тариф «потянет» столько-то сеансов: это зависит от приложений, профилей и привычек людей. Разумный путь — взять ступень, которая по грубой прикидке выглядит достаточной, провести пилот в часы пика и по результату либо остаться, либо подняться на ступень выше. Root-доступ позволяет настроить среду под нужды сервера, а NVMe помогает там, где вход в сеанс упирается в загрузку профилей с диска; впрочем, как именно это скажется на вашей нагрузке, покажет только замер.

Практические детали заказа: в публичном предложении указаны локации UK, US, RU и FR, оплата картой РФ и через СБП, а VPS создаётся автоматически через пару минут после оплаты. Доступность конкретного образа системы в конкретной локации проверяйте в форме заказа. Выбор локации для рабочего места сотрудников — отдельный вопрос задержки и требований вашей организации; он не решается автоматически выбором страны. Общий подход к выбору под задачу — без ставки на громкие названия — описан в материале о методике выбора модели под задачу; по смыслу он близок: сначала измеримые критерии, потом выбор.

Что принести поставщику лицензий

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

1. Список пользователей по сменам: сколько человек в каждой, есть ли подрядчики и сезонные сотрудники.
2. Список устройств: корпоративные и личные, закреплённые за залом и мобильные; сколько устройств у каждого человека, подключающегося к серверу.
3. Схема использования: какие устройства общие для нескольких людей и сколько человек в сутки на каждом.
4. Версия Windows Server, которую планируете использовать, и способ размещения: собственное оборудование или аренда VPS.
5. Ожидаемый рост штата за ближайший год, чтобы не пересчитывать всё при первом найме.

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

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

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

Два результата одного расписания

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

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