Рекомендации по размеру и производительности сайта Configuration Manager

Относится к Configuration Manager (Current Branch)

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

В этой статье рассматриваются самые узкие места производительности Configuration Manager, являющиеся наиболее участниками: дисковая подсистема ввода-вывода или операции ввода-вывода в секунду.

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

Методология тестирования производительности

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

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

Параметры интервалов функций

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

Объекты

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

Загрузки

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

Конфигурация

Запускайте тестирование на различном физическом оборудовании, а также оборудовании Hyper-V и Azure, с использованием сочетания поддерживаемых операционных систем и версий SQL Server. Всегда проверяйте наихудшие случаи для поддерживаемой конфигурации. Как правило, Hyper-V и Azure при аналогичной настройке возвращают сопоставимые результаты производительности на эквивалентном физическом оборудовании. Текущие серверные операционные системы, как правило, имеют производительность, равную или превышающую более ранние версии ОС. Хотя все поддерживаемые платформы соответствуют минимальным требованиям, обычно последние версии вспомогательных продуктов, таких как Windows и SQL Server, обеспечивают еще более высокую производительность.

Наибольшая разница связана с используемыми версиями SQL Server. Дополнительные сведения о версиях SQL Server см. в статье Какую версию SQL Server следует использовать?.

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

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

Инвентаризация оборудования

Чтобы проверить базовую производительность, настройте сбор инвентаризации оборудования один раз в неделю с размером MOF-файла по умолчанию плюс примерно 20% других свойств. Не включайте все свойства, а собирайте только те свойства, которые вам действительно нужны. При сборе свойств, например доступной виртуальной памяти, будьте особенно внимательны при сборе свойств, которые всегда меняются с каждым циклом инвентаризации. Сбор этих свойств может вызвать чрезмерный отток в каждом цикле инвентаризации у каждого клиента.

Инвентаризация программного обеспечения

Чтобы проверить базовую производительность, установите для параметра "Сбор инвентаризации программного обеспечения" один раз в неделю с указанием только сведений о продукте . Сбор большого количества файлов может создать значительную нагрузку на подсистему инвентаризации. Не указывайте фильтры, которые могут собрать тысячи файлов во многих клиентах, таких как *.exe или *.dll.

Коллекции

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

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

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

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

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

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

Помните, что Configuration Manager создает политики для всех объектов в коллекциях, когда вы нацеливаете на них такие задачи, как развертывание. Изменение членства, будь то с помощью запланированного или добавочного обновления, может значительно увеличить объем работы для всей системы. В последних сборках Current Branch реализована специальная оптимизация политик для коллекций "Все системы" и "Все пользователи". Для всего предприятия используйте встроенные коллекции, а не клон этих встроенных коллекций.

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

Методы обнаружения

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

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

Общие рекомендации по размерам

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

Замечания по общим рекомендациям по размерам

Примечание 1. Ядра

Configuration Manager выполняет множество одновременных процессов, поэтому требуется определенное минимальное количество ядер ЦП для сайтов различных размеров. Хотя ядра с каждым годом становятся быстрее, важно обеспечить параллельную работу определенного минимального количества ядер. Как правило, любой ЦП серверного уровня, выпущенный после 2015 г., соответствует базовым требованиям к производительности для ядер, указанных в таблице. Configuration Manager использует преимущества других ядер, помимо указанных. Достигнув минимального количества предлагаемых ядер, расставьте приоритеты инвестиций в ресурсы процессора, чтобы увеличить скорость существующих ядер. Не добавляйте новые, более медленные ядра. Например, Configuration Manager обеспечивает более высокую производительность при выполнении ключевых задач обработки при использовании 16 быстрых ядер, чем при использовании 24 медленных ядер. Такая производительность предполагает, что имеется достаточно других системных ресурсов, таких как дисковые операции ввода-вывода в секунду.

Связь между ядрами и памятью также важна. Как правило, менее 3–4 ГБ ОЗУ на ядро снижает общую вычислительную мощность ваших SQL Server. Если SQL Server размещен рядом с компонентами сервера сайта, требуется больше ОЗУ на ядро.

Примечание 2. Выделение памяти SQL Server

Используйте это значение для настройки максимального объема памяти сервера (в МБ) в свойствах SQL Server. Это процент от общего объема памяти, доступной на сервере.

Не настраивайте минимальное и максимальное значения одинаково. Это руководство относится к максимальному объему памяти, который следует разрешить SQL Server.

Примечание 3. IOPS: папки "Входящие" и операции ввода-вывода в секунду: SQL

Эти значения соответствуют потребностям операций ввода-вывода в секунду для логических дисков Configuration Manager и SQL Server. IOPS: столбец "Входящие" показывает требования к операциям ввода-вывода в секунду для логического диска с каталогами папки "Входящие" Configuration Manager. В столбце IOPS: SQL показано общее количество операций ввода-вывода в секунду для логических дисков, используемых различными файлами SQL Server. Эти столбцы отличаются тем, что два диска должны иметь разное форматирование. Дополнительные сведения и примеры о рекомендуемых конфигурациях дисков SQL Server и лучших методиках работы с файлами, включая сведения о разделении файлов на несколько томов, см. в разделе "Часто задаваемые вопросы о размерах и производительности сайта".

Оба этих столбца IOPS используют данные из стандартного отраслевого средства Diskspd. Инструкции по дублированию этих измерений см. в разделе "Как измерить производительность диска ". Как правило, после выполнения базовых требований к процессору и памяти подсистема хранения оказывает наибольшее влияние на производительность сайта, и улучшения здесь обеспечат наибольшую окупаемость инвестиций.

Примечание 4. Требуется место для хранения

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

Измерение производительности диска

Для предоставления стандартизированных рекомендаций по операциям ввода-вывода в секунду, необходимых средам Configuration Manager различного размера, можно использовать стандартное средство Diskspd. Хотя следующие шаги тестирования и строки команд не являются исчерпывающими, они предоставляют простой и воспроизводимый способ оценить пропускную способность дисковой подсистемы ваших серверов. Вы можете сравнить свои результаты с минимальным рекомендуемым количеством операций ввода/вывода в секунду в таблице общих рекомендаций по размерам .

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

Проверка операций ввода-вывода в секунду с диска

1. Загрузите утилиту Diskspd.

2. Убедитесь, что у вас есть не менее 100 ГБ свободного места на диске. Отключите все приложения, которые могут мешать или создавать дополнительную нагрузку на диск, например активное антивирусное сканирование каталога, SQL или SMSExec.

3. Запустите Diskspd из командной строки с повышенными привилегиями.

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

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

   DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat
   
   del G:\\test\testfile.dat
   
   DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.dat
   

4. Просмотрите выходные данные второго теста, чтобы найти общее количество операций ввода-вывода в секунду в столбце ввода-вывода в секунду . В следующем примере общее количество операций ввода-вывода в секунду равно 3929,18.

   Total IO
   | thread |  bytes      |  I/Os   |  MB/s  | I/O per s | AvgLat | LatStdDev |
   |--------|-------------|---------|--------|-----------|--------|-----------|
   |   1    |  9651814400 |  147275 |  30.68 |    490.92 | 16.294 | 10.210    |
   |   2    |  9676652544 |  147654 |  30.76 |    492.18 | 16.252 |  9.998    |
   |   3    |  9638248448 |  147068 |  30.64 |    490.23 | 16.317 | 10.295    |
   |   4    |  9686089728 |  147798 |  30.79 |    492.66 | 16.236 | 10.072    |
   |   5    |  9590931456 |  146346 |  30.49 |    487.82 | 16.398 | 10.384    |
   |   6    |  9677242368 |  147663 |  30.76 |    492.21 | 16.251 | 10.067    |
   |   7    |  9637330944 |  147054 |  30.64 |    490.18 | 16.319 | 10.249    |
   |   8    |  9692577792 |  147897 |  30.81 |    492.99 | 16.225 | 10.125    |
   | Total: | 77250887680 | 1178755 | 245.57 |   3929.18 | 16.286 | 10.176    |
   

Примеры конфигураций дисков

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

Физические компьютеры и Hyper-V

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

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

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

Производительность компьютеров и дисков Azure

Производительность дисков Azure зависит от нескольких факторов, таких как размер виртуальной машины Azure, а также количество и тип используемых ею дисков. Кроме того, в Azure постоянно добавляются новые типы компьютеров и скорости дисков, отличающиеся от приведенной ниже диаграммы. Дополнительные сведения о работе Configuration Manager в Azure и дополнительные сведения о дисковом вводе-выводе в Azure см. в статье "Часто задаваемые вопросы о Configuration Manager в Azure".

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

Дополнительные сведения о доступных в настоящее время дисках см. в статье Выбор типа диска для виртуальных машин Azure IaaS.

См. также

• Часто задаваемые вопросы о размере и производительности сайта
• Часто задаваемые вопросы о Configuration Manager в Azure
• Размеры и масштабы
• Рекомендуемое оборудование