Поделиться через

Рекомендации по размеру виртуальных машин узла сеансов для виртуальных рабочих столов Azure и служб удаленных рабочих столов Azure

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

Существует два типа сеансовых хостов, которые следует учитывать при их настройке для пользователей:

  • Один сеанс: выделенный одному пользователю одновременно.

  • Мультисеанс: совместное использование нескольких пользователей одновременно.

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

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

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

Планирование ресурсов

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

При планировании потенциала хостов сеансов рассмотрите следующие области:

Area Description
Рабочая нагрузка пользователя Общие сведения о типах приложений и задач, выполняемых пользователями. Разные рабочие нагрузки имеют различные требования к ресурсам, такие как ЦП, память и хранилище.
Число пользователей Оцените количество одновременных пользователей, обращающихся к узлам сеансов. Это помогает определить необходимые ресурсы для поддержки ожидаемой нагрузки пользователя.
Требования к ресурсам Анализ требований к ресурсам приложений и задач, выполняемых пользователями. К ним относятся ЦП, память, хранилище и пропускная способность сети.
Ожидания производительности Определите ожидания производительности для узлов сеансов, таких как время отклика, время входа в систему, время запуска приложения и общее взаимодействие с пользователем. Рассмотрите производительность входа в систему в ключевые моменты, такие как начало рабочего дня или смены, так как это может повлиять на производительность по сравнению с стабильным состоянием.
Масштабируемость Рассмотрите возможность масштабирования узлов сеансов по мере увеличения требований пользователей. Это может включать добавление дополнительных узлов сеансов или изменение конфигурации существующих, чтобы вместить дополнительных пользователей или рабочие нагрузки.
Устойчивость и избыточность Рекомендуется реализовать механизмы избыточности и отработки отказа, чтобы обеспечить высокий уровень доступности и свести к минимуму время простоя при неисправностях оборудования или программного обеспечения.
Мониторинг и оптимизация Реализуйте средства мониторинга для отслеживания использования ресурсов и метрик производительности. Используйте эти данные для оптимизации узлов сеансов и внесения текущих изменений по мере необходимости.

Следующие два подхода часто используются для определения производительности узлов сессий:

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

  • Подход к имитации: используйте средства автоматизации для создания имитированных рабочих нагрузок пользователей, которые имитируют реальное поведение пользователя. Обычно моделирование предполагает постепенное увеличение количества имитированных пользователей с течением времени и метрик производительности, собранных на протяжении всего теста. Анализ помогает определить точку снижения производительности за пределы допустимых пороговых значений. Этот подход более подходит для более крупных развертываний, где точное определение емкости значительно влияет на решения о покупке.

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

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

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

Ключевые факторы, влияющие на емкость и производительность

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

  • Масштабирование ЦП:

    • Количество ядер ЦП непосредственно влияет на количество пользователей, которые могут поддерживаться на виртуальной машине узла сеанса.
    • Удвоение числа ядер ЦП не обязательно удвоит емкость пользователя из-за уменьшения затрат на возврат и синхронизацию. Коэффициент масштабирования выше, когда начальное число ЦП небольшое, и уменьшается по мере увеличения числа ядер. Например, коэффициент масштабирования от 4 до 8 ядер больше, чем коэффициент от 8 до 16 ядер.
    • Коэффициент масштабирования обычно варьируется от 1,5 до 1,9, что означает, что для каждого дополнительного ядра можно ожидать пропорционального увеличения емкости пользователя, но не линейного.

  • Влияние на память:

    • Объем памяти, выделенной виртуальной машине узла сеанса, напрямую влияет на количество пользователей, которые он может поддерживать.
    • Если память является ограничивающим фактором, добавление большего объема памяти в более низких емкостях может значительно повысить производительность. Например, увеличение объема памяти с 8 ГБ до 16 ГБ может увеличить число пользователей, которые можно поддерживать.

  • Влияние входа пользователя:

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

  • Затраты на виртуализацию

    • Работа виртуальных машин может вызвать потери производительности на уровне 15-20% по сравнению с натурными машинами, на основе внутреннего тестирования.
    • Гипервизор увеличивает задержку и загрузку ЦП, что может привести к тому, что время отклика пользователя на 10%—20% выше, чем на аппаратном обеспечении без гипервизора.

  • Преимущества гиперпоточности

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

  • Производительность сети

    • Задержка в сети, потеря пакетов и дрожание могут повлиять на взаимодействие с пользователями, особенно для приложений, требующих частого взаимодействия с удаленными серверами или базами данных. Любое сочетание высокой задержки, потери пакетов и дрожания может привести к замедлению времени отклика и снижению производительности.
    • Снижение задержки сети RTT, потери пакетов и джиттера приводит к более быстрому времени отклика и повышению общей производительности. Рассмотрите возможность использования сетевых подключений с низкой задержкой, чтобы свести к минимуму влияние производительности сети на взаимодействие с пользователем.

  • Производительность хранилища

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

  • Требования к единицам обработки графики (GPU)

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

Все эти факторы могут повлиять на общую производительность и вместимость серверов сеансов. Измерение задержки ввода пользователя или времени отклика сквозного сеанса — это ключевая метрика, учитываемая при оценке производительности для пользовательского опыта. Эта метрика измеряет время, необходимое для обработки и отражения в сеансе входных данных пользователя, что обеспечивает более точное представление взаимодействия с пользователем. Как правило, пользователи ожидают время отклика менее 200 миллисекунд на свои действия, и любая задержка, превышающая это время, может привести к ухудшению пользовательского опыта. Дополнительные сведения об измерении взаимодействия с пользователем см. в статье "Использование счетчиков производительности для диагностики проблем с производительностью приложения на узлах сеансов удаленных рабочих столов".

Workloads

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

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

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

Тип рабочей нагрузки Примеры пользователей Примеры приложений
Свет Пользователи, выполняющие основные задачи ввода данных Приложения для входа в базу данных, интерфейсы командной строки
Средний Консультанты и исследователи рынка Приложения для входа в базу данных, интерфейсы командной строки, Microsoft Word, статические веб-страницы
Heavy Разработчики программного обеспечения, создатели содержимого Приложения для входа в базу данных, интерфейсы командной строки, Microsoft Word, статические веб-страницы, Microsoft Outlook, Microsoft PowerPoint, динамические веб-страницы, разработка программного обеспечения
Power Графические дизайнеры, 3D-разработчики моделей, исследователи машинного обучения Приложения для входа в базу данных, интерфейсы командной строки, Microsoft Word, статические веб-страницы, Microsoft Outlook, Microsoft PowerPoint, динамические веб-страницы, редактирование фотографий и видео с помощью компьютеров (CAD), автоматизированное производство (CAM)

Рекомендации по размеру узла односеансового сеанса

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

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

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

В следующей таблице показаны примеры типичных рабочих нагрузок:

Тип рабочей нагрузки Минимальный объем хранилища виртуальных ЦП/ОЗУ/ОС Примеры экземпляров Azure Минимальный размер хранилища контейнеров профиля
Свет 2 виртуальных ЦП, 8 ГБ ОЗУ, 32 ГБ хранилища D2s_v5, D2s_v4 30 ГБ
Средний 4 виртуальных ЦП, 16 ГБ ОЗУ, 32 ГБ хранилища D4s_v5, D4s_v4 30 ГБ
Heavy 8 виртуальных ЦП, 32 ГБ ОЗУ, 32 ГБ хранилища D8s_v5, D8s_v4 30 ГБ

Рекомендации по размерам сервера хоста для многосессионной работы

В сценарии с несколькими сеансами несколько пользователей вошли в виртуальную машину узла сеанса в любое время. Например, при использовании пулов узлов в Azure Virtual Desktop с Windows 11 Enterprise мульти-сеансной операционной системой (ОС), это мульти-сеансовое развертывание.

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

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

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

Тип рабочей нагрузки Максимальное количество пользователей на виртуальный ЦП Минимальное хранилище виртуальных ЦП/ОЗУ/ОС Примеры экземпляров Azure Минимальное хранилище профилей
Свет 6 8 виртуальных ЦП, 16 ГБ ОЗУ, 32 ГБ хранилища D8s_v5, D8s_v4, F8s_v2, D8as_v4, D16s_v5, D16s_v4, F16s_v2, D16as_v4 30 ГБ
Средний 4 8 виртуальных ЦП, 16 ГБ ОЗУ, 32 ГБ хранилища D8s_v5, D8s_v4, F8s_v2, D8as_v4, D16s_v5, D16s_v4, F16s_v2, D16as_v4 30 ГБ
Heavy 2 8 виртуальных ЦП, 16 ГБ ОЗУ, 32 ГБ хранилища D8s_v5, D8s_v4, F8s_v2, D8as_v4, D16s_v5, D16s_v4, F16s_v2, D16as_v4 30 ГБ
Power 1 6 виртуальных ЦП, 56 ГБ ОЗУ, 340 ГБ хранилища D16ds_v5, D16s_v4, D16as_v4, NV6, NV16as_v4 30 ГБ

Для рабочих нагрузок с несколькими сеансами следует ограничить размер виртуальной машины размером от 4 виртуальных ЦП до 24 виртуальных ЦП по следующим причинам:

  • Все виртуальные машины должны иметь более двух ядер. Компоненты пользовательского интерфейса в Windows используют по крайней мере два параллельных потока для некоторых более тяжелых операций отрисовки. Для сценариев с несколькими сеансами наличие нескольких пользователей на двух основных виртуальных машинах приводит к нестабильному пользовательскому интерфейсу и приложениям, что снижает качество взаимодействия с пользователем. Четыре ядра — это наименьшее рекомендуемое количество ядер, которые должны иметь стабильная многосеансовая виртуальная машина.

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

Рекомендуемый диапазон от 4 до 24 ядер обычно обеспечивает лучшую производительность для пользователей по мере увеличения числа ядер. Например, если одновременно 12 пользователей войдут на виртуальную машину с четырьмя ядрами, то соотношение будет три пользователя на одно ядро. На виртуальной машине с 8 ядрами и 14 пользователями соотношение составляет 1,75 пользователей на ядро. В этом сценарии последняя конфигурация с соотношением 1,75 обеспечивает большую емкость ускорения для приложений с краткосрочным спросом на ЦП.

Эта рекомендация верна в более широком масштабе. В сценариях с 20 или несколькими пользователями, подключенными к одной виртуальной машине, несколько небольших виртуальных машин будут работать лучше, чем одна или две большие виртуальные машины. Например, если вы ожидаете, что 30 или более пользователей войдут в систему в течение 10 минут друг после друга на одном сервере сеанса с 16 ядрами, две 8-ядерные виртуальные машины будут справляться с рабочей нагрузкой лучше. Кроме того, можно использовать балансировку нагрузки по широте для равномерного распределения пользователей между различными виртуальными машинами, а не балансировку нагрузки по глубине, где можно использовать новый сеансовый хост только после того, как существующий будет заполнен пользователями.

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

Связанный контент

  • Last updated on