Как рассчитать параметры терминального сервера?

В статье мы попытались рассказать об основных моментах, связанных с выбором и настройкой терминального сервера

Статья переведена нами с ресурса BrianMadden.com, который является частью TechTarget.com - мировым лидером в медиа технологиях, 9 млн. зарегистрированных пользователей, и более чем 10 лет новаторских достижений. Статье уже более 10 лет, но принципы неизменны, как говорится. )

Память

Каждый пользователь, который запускает приложение на сервере терминалов будет использовать память терминального сервера для этого приложения так же, как если бы он запускал это приложение на своей рабочей станции. Например, быстрая проверка диспетчера задач показывает, что Microsoft Word требует около 10 Мб памяти для запуска. Каждому пользователю Word будет нужно 10 МБ, это означает, что 20 пользователям теоретически потребуется 200 МБ оперативной памяти. Даже небольшому серверу терминалов предназначенному только для 20 пользователей Microsoft Office могут легко потребоваться 512 Мб.

Вывод №1 - чем больше ОЗУ, тем лучше.

Процессоры

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

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

В реальности загрузка процессора должна быть практически постоянно на уровне 99 загруженности%.

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

Вывод №2 - чем больше кеша, тем лучше.

Жесткие диски

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

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

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

Вывод №3 - храните данные отдельно от терминального сервера.

Тестирование мощностей сервера

После завершения своей стратегии (или, возможно, для того, чтобы помочь вам укрепить вашу стратегию), вам нужно запустить тесты производительности на серверах, чтобы определить количество пользователей, которых они смогут поддержать. Хотя есть множество интернет-сайтов и научных исследований, которые определяют показатели терминальных серверов, невозможно получить точные результаты, учитывая различия между средами, в том числе скорость работы сети, протоколы, Windows профиля, а также аппаратные и программные изменения.

Главная ошибка заключается в предположении, что система будет линейно масштабирована на высоком уровне при помощи получения информации из диспетчера задач. Предположим, что сервер не имеет активных пользователей: 4% загрузки процессора и 150 Мб оперативной памяти. При пяти активных пользователях загрузка процессора увеличивается до 14%, а памяти до 200 Мб. Быстрая оценка показывает, что процессор будет максимум рассчитан на 48 пользователей и 630 Мб памяти.

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

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

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

Следует отметить, что производительность следует рассматривать не только с точки зрения показателя производительности сервера (например, использование процессора и памяти), но и с точки зрения конечного времени ответа пользователя.

Независимо от того, точный инструмент или метод, который вы используете, при планировании мощностей и тестировании мы предлагаем следовать нашей основной методологии, а именно:

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

Результаты тестирования сервера должны дать ответы на эти вопросы:

  • Сколько пользователей ваш сервер сможет поддерживать?
  • Как сервер работает, когда он сильно загружен? (например, происходит лаг для текущей сессии, или же он перестает воспринимать новые сеансы)

Давайте рассмотрим каждый из шагов тестирования.

Шаг 1. Выберите Test Application

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

Шаг 2. Определение тестовых заданий

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

Шаг 3. Определите нужное время ответа

Определение соответствующего времени отклика приложений позволит вам определить, является ли ваш сервер свободным или занятым. Если тестируете приложение Microsoft Word, вы можете потребовать, чтобы письмо появлялось на экране в течение 0,2 секунд после нажатия пользователем клавиши. Это будет ваш порог приемлемой производительности. Позже, в процессе тестирования, вы можете обнаружить, что ваш сервер может поддерживать 130 одновременных пользователей до сбоя, хотя каждый пользователь должен подождать 0,5 секунды. В этом случае, вы можете обнаружить, что вы можете поддерживать только 80 пользователей с 0,2 секунды времени отклика.

Шаг 4. Определите, как пользователи используют приложения

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

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

Шаг 5. Создание сценариев приложений моделирования

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

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

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

Эти инструменты предлагают режим "записи" , который позволяет выполнять некоторые функции (например, ввод документов, просмотр веб-страниц, используя PeopleSoft и т.д.). После того, как сценарий записан, вы можете воспроизвести его для имитации пользователя с системой.

Когда приложение моделирования сценария будет завершено, вы получите файл или файлы, которые можно запустить из командной строки (например, "autoit.exe / слово" или "myappscript.cmd"). Сценарий должен запустить приложение, а затем начать "воспроизведение" моделирования взаимодействия с пользователем.

Шаг 6. Анализ результатов

Анализируя  результаты, надо иметь ввиду что, вы ищете узкие места в вашей системе.

На основании данных из лог-файла вашего теста, вы, вероятно, сможете выяснить точку, в которой производительность сервера начинает резко падать. Глядя на активность счетчика сессии тестирование скажет вам, сколько сессий было запущено, когда это падение произошло. Как только вы определите, сколько пользователей системы может быть запущено, вы можете запустить тесты снова. Для этого необходим второй тур испытаний, "впустите" в вашу систему "живых" пользователей в дополнение к тестовым пользователей. "Живые" пользователи будут в состоянии сказать вам, является ли система работоспособной или нет.

Вы можете импортировать данные о производительности в Excel. Создавайте диаграммы.

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

Спасибо, что прочли! Надеемся, что информация была полезной вам!