Расчет памяти для терминального сервера 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.

Сайзинг терминального сервера при развертывании в облаке IaaS-провайдера

Сайзинг терминального сервера при развертывании в облаке IaaS-провайдера

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

На что обратить внимание в первую очередь

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

Правило 1. Не равнять всех под одну гребенку. Приложение приложению рознь. В зависимости от функционала может потребляться различное количество ресурсов. Это же касается и пользователей. Кто-то запускает минимальный набор «легких» приложений, кому-то, наоборот, может потребоваться тяжеловесный софт. Учитывайте эти моменты еще на этапе планирования.

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

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

Правило 4. Учитывать требования к ресурсам. Статистика показывает, что эра «железок» в собственной серверной уходит в прошлое. С появлением технологий виртуализации и облаков многие вопросы стали решаться достаточно просто. Например, чтобы увеличить объем памяти, достаточно поиграть бегунком в окне менеджера управления ресурсами, а не бежать, как раньше, за дополнительной линейкой. Лишь одно остается неизменным — требования, предъявляемые к ресурсам. Их следует учитывать.

Какова методика расчета необходимых ресурсов?

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

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

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

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

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

Моделирование нагрузки сервера терминалов

Моделирование нагрузки терминального сервера является одним из методов, точно оценивающих потенциал системы. Напомним, что этот он максимально эффективен в контексте четко определенного сценария.

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

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

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

# Переходим к тестированию. Суть этого шага заключается в формировании нагрузки на сервер и определении жизнеспособности системы. Что имеется в виду? В первую очередь, запускаем тест производительности, чтобы определить количество пользователей, которое сервер терминалов сможет выдержать. Несмотря на то что существует немалое количество источников и исследований на тему определения показателей производительности терминального сервера, ввиду различия между средами, скоростью работы сети, используемых протоколов и многого другого, при их использовании сложно получить точные результаты. Крайне важно применять детальный анализ для определения точного линейного масштабирования использования системы. Для этого необходимо имитировать нагрузку и сбор данных о производительности системы, благодаря которым можно узнать о ее узких местах и ограничениях пропускной способности.

Важно! Производительность терминального сервера лучше оценивать не только на основе показателей производительности (использование памяти, дисковой подсистемы, процессора), но и на основе времени отклика конечного пользователя.

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

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

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

Скрипты AutoIT

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

• Имитация пользовательского ввода мышью и клавиатурой в любых приложениях.
• Манипуляция окнами запущенных приложений (получение информации и управление).
• Глобальные перехватчики клавиатуры, запуск процедур по нажатию горячих клавиш.
• Построение GUI, основных элементов управления, а также пользовательских элементов управления, поставляемых как ActiveX.
• Работа с сетью (протоколы TCP и UDP, загрузка файлов).
• Мониторинг и запуск процессов; запуск процессов от имени указанной учетной записи.
• Работа с реестром.
• Работа с буфером обмена и многое другое.

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

Run(«notepad.exe «); запускаем «Блокнот»

WinWaitActive («Безымянный — Блокнот»); ожидаем появление окна «Блокнота»

Send («Какой-то текст.»); посылаем нажатия (имитируем ввод)

WinClose («Безымянный — Блокнот»); посылаем окну команду закрытия;

ожидаем появление окна запроса о сохранении:

WinWaitActive(«Блокнот», «Текст в файле Безымянный был изменен.»)

Send(««); посылаем нажатие Escape (имитируем ввод)

Скрипты WinBatch AutoIT дает возможность автоматизации произвольных приложений, даже тех, которые не поддерживают опций командной строки или специальных программных средств автоматизации.

WinBatch

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