Расчет памяти для терминального сервера RDS

Недавно мне потребовалось проанализировать потребление памяти на терминальном сервере, чтобы оценить вместимость сервера по количеству одновременно работающих пользователей. Филиалы организации достаточно широко разбросаны географически, пользователи подключаются к сайту с базой данных по достаточно слабым каналам, поэтому мы установили клиент «1С: Предприятие» на терминальный сервер в основном филиале. Пользователи со своих клиентских машин через Удаленный рабочий стол работают на сервере, к ним на компьютеры возвращаются только разностные данные по перерисовке картинки рабочего стола сервера и задания печати с сервера на принтер, при обрыве соединения база данных не страдает и сессии к 1С не висят (рассматривалась работа 1С версии 7.7), при восстановлении соединения пользователь возвращается в свою сессиию.

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

Итак, чтобы собрать данные, сколько же памяти расходует одна пользовательская сессия, я использовал следующий скрипт Power Shell (анализ производился когда на сервере еще оставалась свободная физическая память).

После работы скрипта в папке Мои Документы появился файл Processes.txt с таким содержимым:

Из этого отрывка таблички видно, какие процессы запущены у каждого пользователя, работающего на сервере, сколько памяти потребляет каждый процесс. Если просуммировать параметр Working Memory у каждого пользователя и усреднить полученные данные, то можно вычислить среднее значение физической памяти, необходимое для работы одного среднестатистического пользователя. Если сложить параметр Working Memory у служебных пользователей SYSTEM, LOCAL SERVICE и NETWORK SERVICE, то можно получить значение физической памяти, необходимое для работы операционной системы. Параметр Total Memory отвечает за объем использования памяти с учетом файла подкачки — виртуальная память. При больших разрывах в значениях между Working Memory и Total Memory пользователи начинают ощущать замедление в работе терминального сервера, так как производится частое обращение к диску для записи и считывания данных, не поместившихся в физическую память. Нормальное соотношение физической памяти к виртуальной памяти (физическая память + файл подкачки) равно от 1:2 до 1:3.

После подсчетов, усреднения и округления получилось, что один пользователь 1С потребляет в среднем 200 МБ физической памяти или 600 МБ виртуальной памяти, система потребляет 600 МБ физической памяти или 4000 МБ виртуальной памяти. Вместительность сервера на Windows Server 2003 64bit с 16 ГБ установленной ОЗУ равна: (16384 МБ [установлено] — 600 МБ [система]) / 200 МБ [пользователь] = 78 пользователей. То есть при использовании на терминальном сервере только приложения 1С одновременно могут работать 78 человек, не ощущая особых задержек в работе по причине нехватки памяти.

Если же на сервере будут запускаться другие программы, то данные нужно будет скорректировать. Например, при использовании на терминальном сервере программы MS Office потребуется 513 МБ ОЗУ для каждого клиента (значение взято из системных требований к MS Office и не измерялось на практике). То есть вместительность сервера Windows Server 2003 64bit с 16 ГБ установленной ОЗУ равна: (16384 МБ [установлено] — 600 МБ [система]) / (200 МБ [1C] + 512 МБ [MS Office]) [пользователь] = 22 пользователей.

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

Все заметки о службе терминалов в моем блоге можно найти по тегу RDS.

Windows 2019 терминальный сервер квота оперативной памяти

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами разобрали группы доступности AlwaysOn. Сегодня я хочу рассмотреть еще одну часто встречающуюся проблему в практике системного администратора, речь пойдет о балансировке и распределении системных ресурсов (CPU, Сеть, Диск) на хостах RDS фермы Windows Server 2019, но актуально будет и для более старых версий, вплоть до Windows Server 2012 R2. Мы научимся равномерно распределять нагрузку по пользовательским сессиям с помощью Dynamic Fair Share Scheduling (DFSS).

Проблема: один из пользователей потребляет 90% и более CPU

Опишу реальный случай с которым вы обязательно столкнетесь, если у вас в компании используются терминальные столы. И так есть RDS ферма построенная на базе Windows Server 2012 R2 до Windows Server 2019. На каждом из RDSH хостов могут одновременно работать свыше 30 пользователей. В среднем они суммарно не потребляют более 30% процессорных мощностей, но когда приходит период отчетности некоторые пользователи начинают нагружать сервера куда интенсивнее. Очень часто можно встретить, что пользователь работающий с Excel, 1С и похожими программами начинает потреблять 80-90% процессорных мощностей, в результате чего начинают страдать остальные пользователи этого RDSH хоста.

Ранее для решения это проблемы в Windows Server 2008 R2 был замечательный компонент диспетчер системных ресурсов (Windows System Resource Manager), но Microsoft его посчитала устаревшим и выпилила из состава компонентов, аж с Windows Server 2012 R2 и выше. Но не думайте, что доблестные разработчики не подумали чем вам восполнить этот пробел, они придумали и включили в состав Windows Server компонент «Динамическое планирование долевого распределения» или как в оригинале «Dynamic Fair Share Scheduling (DFSS)«.

Что такое Dynamic Fair Share Scheduling (DFSS)?

Так как официального метода вернуть Windows System Resource Manager не существует, а есть лишь костыльные, нам придется работать с тем, что есть. «Динамическое планирование долевого распределения» или как в оригинале «Dynamic Fair Share Scheduling (DFSS)» — это механизм автоматической балансировки и распределения сетевой нагрузки, дисковых, процессорных мощностей между всеми пользовательскими сессиями на RDSH хосте. Все эти три варианта имеют цель предотвратить чрезмерное использование ресурсов одним пользователем и предоставить всем пользователям одинаковые возможности. Однако методы FairShare не гарантируют, что ресурсы не будут исчерпаны, это все еще может иметь место. Если все пользователи используют все ресурсы ЦП, FairShare гарантирует, что все пользователи получат некоторую емкость ЦП, но все же может быть, что все процессоры загружены на 100%, а пользователи испытывают снижение производительности, это нужно учитывать.

Вот так называются три компонента входящие в состав DFSS

• CPU Fair Share — Динамически распределяет процессорное время между пользовательскими сессиями. Тут будет учитываться их количество и интенсивность использования.
• Network Fair Share — Динамически распределяет полосу пропускания сетевого интерфейса между пользовательскими сессиями. Советую использовать совместно с Qos.
• Disk Fair Share — данная функция защищает ваши диски от очень интенсивного использования одним пользователем, позволяет равномерно балансировать дисковые операции между всеми.

Как включить Dynamic Fair Share Scheduling (DFSS)?

Если говорить про Windows Server 2019, то динамическое планирование долевого распределения уже по умолчанию там активно, то же самое и на Windows Server 2016, а вот в Windows Server 2012 R2, ее нужно активировать. Для того чтобы у вас в системе был активен встроенный балансировщик ресурсов DFSS, у вас должна быть выключена одна политика или выставлен нужный ключ реестра.

Балансировка CPU на RDSH хосте

Для того, чтобы у вас на RDS ферме была балансировка процессорных мощностей, необходимо наличие активной политики:

Как я и писал выше функция планирования ЦП со справедливым разделением в 2019 системе включена по умолчанию, и данная политика имеет статус не задано.

Если этот параметр политики включен, то планирование ЦП со справедливым разделением отключено. Если этот параметр политики отключен или не настроен, планирование ЦП со справедливым разделением включено

Так же эта настройка имеет и аналог в виде ключа реестра, найти его можно по пути:

Если ключ EnableCpuQuota имеет значение 1, то значит планирование ЦП со справедливым разделением включено. Хочу отметить, что в Windows Server 2012 R2, хоть в системе и есть политика, но данного ключа нет, а его желательно бы создать если хотите использовать CPU Fair Share.

Как отключать CPU Fair Share

Существуют ситуации, при которых требуется выключить DFSS, приведу пример. Citrix Xenapp также имеет свои собственные политики для разделения процессорного времени между пользователями, и неудивительно, что они не могут сосуществовать с политиками Microsoft. Управление процессорами Citrix не вступит в силу, если DFSS все еще включен. На самом деле, вы получите следующую ошибку на сервере:

Для отключения CPU Fair Share в Windows Server 2019, вам нужно сначала включить политику «Отключить планирование ЦП со справедливым разделением (Turn off Fair Share CPU Scheduling)». Сделать, это можно через групповые политики или же через локальный редактор политик (gpedit.msc).

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

Так же отключить DFSS можно и через PowerShell, для этого введите команду изменяющую значение реестра:

Пример использования CPU Fair Share

Чтобы показать работу FairShare, я использовал инструмент CPUstress, созданный Тимом Манганом. С помощью этого инструмента вы можете вызвать чрезмерное использование ресурсов процессора. В тесте будут участвовать два пользователя, Барбоскин Геннадий Викторович и Администратор.

Первый тест с включенной опцией динамического распределения процессорного время между пользовательскими сессиями. Я зашел на свою RDS ферму и запустил из под каждого пользователя CPUstress. Как видно из картинки мой процессор загружен на 100% и все его мощности делятся в равных частях между пользователями сервера.

А вот тест когда CPU Fair Share выключен, как видите тут уже идет борьба за ресурсы между пользователями, у администратора в моем примере 73%, а у barboskin.g 25%. Потом эти доли могут кардинально поменяться.

Балансировка дисковых операций на RDSH хосте

Управление балансировкой дисковых операций осуществляется через компонент Disk Fair Share. Данный компонент включается или выключается исключительно через ключ реестра EnableFairShare.

«1» означает, что компонент активен, а вот «0» отключает Disk Fair Share.

С помощью FairShare of Resources в RD Session Host Microsoft реализовала приятную функциональность. Это здорово, что Microsoft расширила функциональность с помощью Network and Disks, но лично я думаю, что большинство компаний будут чаще использовать CPU FairShare. На этом у меня все, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Windows Server 2019 — терминальный сервер без домена

Установим роли терминального сервера на Windows Server 2019 и лицензируем. Маленькая тонкость — сервер не в домене.

Подготовка Windows Server 2019

Для начала установим сам сервер. Всё необходимое вынесено в отдельную статью:

Не забываем про настройку:

Итак, операционная система установлена и настроена. Сервер в рабочей группе WORKGROUP.

Установка роли терминального сервера

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

Роль Remote Desktop Licensing

Входим в Server Manager. Справа вверху выбираем Manage > Add Roles and Features.

Попадаем в раздел Before You Begin.

Это начальная страница, пропускаем. Next.

Попадаем в раздел Installation Type. Для установки сервиса удаленных рабочих столов предусмотрен специальный мастер Remote Desktop Services installation, но нам не удастся его использовать, поскольку сервер не в домене. Выбираем Role-based or feature-based installation. Next.

Попадаем в раздел Server Selection. Выбираем текущий сервер. Next.

Попадаем в раздел Server Roles. Выделяем галкой роль Remote Desktop Services. Next.

Попадаем в раздел Features. Здесь ничего дополнительно не выбираем. Next.

Попадаем в раздел Remote Desktop Services. Ненужное нам окошко. Next.

Попадаем в раздел Role Services. Первая роль, которую нам нужно установить, это Remote Desktop Licensing. Выделяем галкой.

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

Remote Desktop Licensing выделено галкой, Next.

Попадаем в раздел Confirmation. Install.

Начинается установка роли.

Роль Remote Desktop Licensing успешно установлена. Примечательно, что перезагрузка не требуется.

Открываем Windows Administrative Tools.

Переходим в папку Remote Desktop Services.

Запускаем оснастку Remote Desktop Licensing Manager.

Выбираем наш сервер, правой кнопкой — активировать.

Открывается окно активации. Next.

Выбираем метод соединения Web Browser. Next.

Получаем код продукта который нам понадобится для активации (Product ID). Копируем.

Выбираем «Activate a license server». Next.

Вводим Product ID полученный ранее, организацию и любую страну или регион. Next. Next.

Если все сделано правильно, то мы получим необходимый код сервера лицензирования. Копируем его. На вопрос «Do you wish to install client access licenses now on the license server with this product ID?» отвечаем «Yes» и пока возвращаемся к терминальному серверу, к текущему окну ещё вернёмся.

Вводим код в открытом мастере, жмём Next.

Устанавливаем галку «Start Install Licenses Wizard now». Next.

Открывается мастер установки лицензий. Next.

Нас просят ввести license key pack ID. Возвращаемся к браузеру.

Вставляем License Server ID, в качестве программы лицензирования, по идее он уже должен сюда переместиться из предыдущего окна. License Program выбираем Enterprise agreement. Указываем компанию и страну. Next.

Выбираем тип продукта: Windows Server 2019 Remote Desktop Services Per Device client access license. Указываем количество лицензий. Обязательно соглашение Enterprise agreement, или ищем в интернете который подойдет…

Не стоит выбирать лицензии Per User, иначе потом вы получите такую ошибку:

Ну вот мы и получили нужные нам клиентские лицензии. Копируем.

Вводим ключ в мастер. Next.

Возвращаемся к Remote Desktop Licensing Manager. Сервер активирован. Лицензии получены. Кстати, они начнут тратиться после окончания триального периода.

Роль Remote Desktop Session Host

Входим в Server Manager. Справа вверху выбираем Manage > Add Roles and Features.

Попадаем в раздел Before You Begin.

Это начальная страница, пропускаем. Next.

Попадаем в раздел Installation Type. Выбираем Role-based or feature-based installation. Next.

Попадаем в раздел Server Selection. Выбираем текущий сервер. Next.

Попадаем в раздел Server Roles. Выделяем галкой роль Remote Desktop Session Host.

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

Роль Remote Desktop Session Host выделена. Next.

Попадаем в раздел Features, ничего не выделяем. Next.

Попадаем в раздел Confirmation. Ставим галку Restart the destination server automatically if required. Отображается предупреждение, что сервер может быть перезагружен. Yes.

Начинается процесс установки роли.

В процессе устанавливаются компоненты.

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

Роль Remote Desktop Session Host успешно установлена. Close.

Открываем Windows Administrative Tools.

Переходим в папку Remote Desktop Services.

Запускаем оснастку Remote Desktop Licensing Diagnoser.

The licensing mode for Remote Desktop Session Host server is not configured.

Откроется Local Group Policy Editor.

Раскрываем Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing.

Редактируем Use the specified Remote Desktop license servers.

Включаем — Enabled. В поле «License server to use» прописываем сервер, с которого получать лицензии, в моём случае «localhost». OK.

Редактируем Set the Remote Desktop licensing mode.

Включаем — Enabled. В поле «Specify the licensing mode for the RD Session Host server» устанавливаем значение Per Device. OK.

Снова запускаем оснастку Remote Desktop Licensing Diagnoser. Теперь всё зелёное, ошибок нет.

Практические испытания

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

На терминальном сервере создаём трёх локальных пользователей: user1, user2, user3.

Включаем их в группу Remote Desktop Users.

Коннектимся под этими пользователями к терминальному серверу по RDP.

Есть три активных сеанса.

Заключение

Мы с вами успешно создали терминальный сервер Windows Server 2019 в рабочей группе WORKGROUP без домена. 120 дней терминальный сервер будет работать в триальном режиме, затем начнёт использовать лицензии Per Device. Для подключения к терминальному серверу требуется создать локальную учётную запись и включить её в группу Remote Desktop Users.