Как рассчитать ресурсы на терминальном сервере: практический метод определения размера

Калькулятор терминального сервера редко является буквальным калькулятором. В большинстве сред SMB и MSP это метод планирования, используемый для оценки того, сколько ЦП, ОЗУ, хранилища и резервов потребуется терминальному серверу, прежде чем пользователи начнут жаловаться. Реальный вопрос, стоящий за ключевым словом, практичен: как правильно рассчитать ресурсы на терминальном сервере, чтобы развернуть его с уверенностью, избежать перерасхода и снизить риск узких мест в производительности ?

Что должен на самом деле рассчитывать калькулятор терминального сервера?

Полезный калькулятор терминального сервера должен оценивать не только «пользователей на сервер». В качестве администратора он должен помочь вам спланировать производительность ЦП, ОЗУ, хранилища, хранилища профилей и запас по емкости при реалистичном одновременном использовании. Рекомендации Microsoft для хостов сеансов удаленного рабочего стола определяют размеры в зависимости от типа рабочей нагрузки и рекомендуемого количества пользователей на vCPU, а не по универсальному ограничению подключения.

Почему количество пользователей само по себе недостаточно для расчета ресурсов на терминальном сервере?

Использование сеанса

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

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

Различие имеет значение, потому что "30 пользователей" само по себе не является показателем емкости. Оно становится значимым только после того, как вы определите что делают и используют эти пользователи в периоды пиковых нагрузок.

Использование сервера

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

• 1 сервер для Брокера, Веб и Лицензирования
• 1 или более серверов для хоста сеансов
• 1 RD Gateway на собственном сервере для внешнего доступа.

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

Какие четыре входа формируют планирование ресурсов?

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

Поэтому вам нужно подвести итог:

Одновременные активные пользователи

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

Класс нагрузки на группу пользователей

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

Тип приложения и сессии

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

Пиковая, ростовая и резервная маржа

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

Как рассчитать ресурсы на терминальных серверах?

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

Шаг 1: Подсчитайте одновременных пользователей, а не общее количество пользователей

Начните с числа пользователей, которые активны одновременно. Это число определяет нагрузку на сервер. Компания с 50 именованными пользователями может иметь только 18-25 подключенных одновременно в часы пик. При определении размера хоста сеансов количество одновременных сеансов гораздо полезнее, чем общее количество пользователей.

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

Шаг 2: Классифицируйте рабочие нагрузки как легкие, средние или тяжелые

Далее отсортируйте пользователей группы по рабочей нагрузке. Microsoft’s текущие рекомендации для хоста сессии предлагает следующие базовые диапазоны плотности для многосессионных сред, и HP и другие источники согласны:

• до 6 легких пользователей на vCPU,
• 4 средних пользователя на vCPU и
• 2 тяжелых пользователя на vCPU,

с соответственно 8 vCPU, 16 ГБ ОЗУ, 32 ГБ хранилища минимальный пример ВМ по этим рабочим нагрузкам. Рекомендации также включают поддержание размеров многосессионных ВМ примерно между 4 и 24 vCPU для лучшей отдачи по мощности.

Простая карта рабочей нагрузки для планирования МСБ таким образом будет направлять сортировку:

• Свет: один бизнес-приложение, ограниченное использование браузера, короткие сессии
• Средний: Офисные приложения, вкладки браузера, инструменты PDF, умеренный многозадачность
• Тяжелый: ERP, большие файлы Excel, постоянное использование браузера, печать, несколько приложений открыты весь день

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

Шаг 3: Оцените емкость ЦПУ

После группировки пользователей оцените ЦПУ с помощью подхода пользователей на vCPU. Например, если 24 одновременных пользователя в основном являются средними пользователями, базовая линия Microsoft, составляющая около 4 пользователей на vCPU, предполагает начало с примерно 6 vCPU, а затем округление до практичного размера хоста с запасом на всплески. Если вы хотите обеспечить лучшую емкость для всплесков во время краткосрочных пиков спроса на ЦПУ, планируйте более низкие соотношения пользователей на ядро, чем вы могли бы в противном случае.

Как, возможно, стало очевидно, размер ЦП не должен ограничиваться математическим минимумом. Он должен учитывать всплески входа, активность антивируса, задания по отчетности и короткие периоды одновременного запуска приложений.

Шаг 4: Оцените требования к оперативной памяти

Оперативная память должна покрывать потребности операционной системы, основных служб, накладных расходов сессии и использования памяти приложений на пользователя. Как описано выше, текущая базовая линия Microsoft для многосессионного использования сочетает легкие, средние и тяжелые примеры нагрузки с минимумом 16 ГБ ОЗУ для начальной точки с 8 vCPU. Хотя это всего лишь базовая линия, она тем не менее предоставляет ощутимую отправную точку для оценки.

Практический метод в малом или среднем бизнесе заключается в том, чтобы:

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

PeteNetLive предоставляет a умышленно широкое правило большого пальца от 2 до 8 ГБ на пользователя для планирования ОЗУ хоста сеансов RD. Это полезно как предостережение против недооценки тяжелых сеансов, даже если точное число должно быть уточнено в тестировании.

Шаг 5: Проверьте использование хранилища и накладные расходы профиля

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

• профиль хранения
• Хранение ОС
• логи: для безопасности и других подобных целей

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

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

Шаг 6: Добавьте запас для пиков, роста и резервирования

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

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

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

Простой метод калькулятора терминального сервера для МСП и МСП

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

Быстрая формула планирования

Используйте эту последовательность:

1. Количество одновременные пользователи .
2. Сортируйте их по светлый, средний и тяжелый группы.
3. Оценка ЦПУ используя базовое соотношение пользователей на vCPU.
4. Оценка ОЗУ с учетом накладных расходов ОС и потребности в каждой сессии.
5. Проверить хранение для профиля, временной и производительности запуска.
6. Добавить 20 до 30 процентов запаса , затем проверьте потребности в резервировании.

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

Пример 1: 15 пользователей офисов с легким доступом

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

Используя рекомендуемые легкие базовые линии, первоначальная оценка ЦП составляет около 3 vCPU. На практике это слишком узко для всплесковой емкости, поэтому планировщик выберет более практичный профиль хоста, а не будет строить на пределе. Вы найдете рекомендации, которые отдают предпочтение более широкому диапазону размеров от 4 до 24 vCPU с 8 vCPU и 16 ГБ ОЗУ в качестве стандартного базового профиля для многосессионных рабочих нагрузок.

Для RAM зарезервируйте емкость для ОС и служб, затем добавьте память сессии для каждого пользователя. Если среда стабильна и использование приложений узкое, это может удобно разместиться на скромном хосте, но это все равно должно быть проверено во время пилотного использования.

Пример 2: 30 смешанных пользователей офиса и ERP

Предположим:

• 18 средних пользователей
• 12 тяжелых пользователей

Планировочный ярлык будет рассматривать среднюю группу примерно по 4 пользователя на vCPU и тяжелую группу примерно по 2 пользователя на vCPU. Это подразумевает около 4,5 vCPU для средней группы и 6 vCPU для тяжелой группы, до учета накладных расходов и запаса. На практике это уже указывает на необходимость использования не одного легкого хоста, а либо более крупного хоста с запасом, либо распределения нагрузки между несколькими хостами сессий.

Это то место, где совет "планируйте ресурсы сервера" становится значимым. С помощью ERP так же, как и в любом корпоративном контексте, цель заключается не только в том, чтобы разместить пользователей где-то. Цель заключается не только в том, чтобы разместить пользователей где-то. Цель состоит в том, чтобы поддерживать приемлемое время отклика в самые загруженные часы дня.

Пример 3: Когда разделять пользователей между несколькими хостами

Как только расчет приводит к плотному хосту с ограниченной емкостью всплеска, лучшим решением может быть архитектурный подход, а не вертикальное масштабирование. Хосты сеансов могут быть настроены на выполнение тяжелой работы, в то время как таким ролям, как RD Connection Broker, Gateway и Licensing, могут быть назначены разные профили ресурсов. Распределение нагрузки пользователей между несколькими хостами, вероятно, улучшит устойчивость, гибкость обслуживания и планирование переключения на резервный режим.

Для MSP это часто является решающим моментом, когда калькулятор терминального сервера становится обсуждением масштабирования фермы, а не обсуждением одного сервера.

Какие распространенные ошибки при масштабировании обычно нарушают производительность терминального сервера?

Ошибки в размерах обычно не вызваны только математикой. Они возникают из-за неверных предположений.

Смешение лицензирования с производственной мощностью

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

Игнорирование сессий с высокой нагрузкой на браузер и печать

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

Размеры только для средней нагрузки

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

Забывая остальную часть стека RDS

Хост сессии является основным потребителем ресурсов, но это не единственная роль в среде. Разделение ролей PeteNetLive является полезным напоминанием о необходимости учитывать Брокер соединений, Шлюз, Веб-доступ и Лицензирование отдельно, когда развертывание выходит за рамки небольшой установки с одним хостом.

Почему мониторинг должен подтверждать ваши оценки размеров?

Калькулятор терминального сервера предоставляет вам базу для планирования. Он не дает вам доказательства. Для доказательства вам необходимо отслеживать использование.

От базового уровня до доказательства: мониторинг как необходимость

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

Где TSplus Server Monitoring делает разницу?

Мониторинг сервера TSplus подходит после развертывания оценки размеров. Это помогает проверить, соответствует ли насыщение ЦП, давление на память, узкие места в хранилище или всплески использования предположениям, использованным в планировании. Это особенно полезно для ИТ-администраторов SMB и MSP, которым нужны доказательства перед изменением размера хоста, перераспределением пользователей или добавлением другого сервера.

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

Программное обеспечение TSplus для безопасной и стабильной доставки приложений и рабочих столов

TSplus Remote Access является слоем доставки в более широкой истории, в то время как Advanced Security специально разработан для защиты серверов приложений. Кроме того, TSplus Remote Support предоставляет набор необходимых инструментов для устранения неполадок и обслуживания этих серверов и многого другого из любого места. Как только среда будет правильно настроена, TSplus Remote Access будет публиковать рабочие столы и приложения проще, чем Citrix, и без превышения вашего бюджета. Тестирование таких функций, как веб-доступ и централизованная доставка, даст вам представление о том, как вы можете выйти за рамки случайного доступа RDP.

Заключение

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

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