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

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

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

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

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

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

Вы можете развернуть 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 создает политики для всех объектов в коллекциях, когда вы нацеливаетесь на такие задачи, как развертывания. Изменения членства, либо путем запланированного обновления, либо добавочных обновлений, могут создать гораздо больше работы для всей системы. Последние сборки ветвей имеют специальные оптимизации политики для коллекций "Все системы" и "Все пользователи". При выборе всей организации используйте встроенные коллекции вместо клона этих встроенных коллекций.

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

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

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

Данные обнаружения — это глобальные данные. Распространенная проблема, связанная с производительностью, заключается в неправильной настройке методов обнаружения на основе сервера в иерархии, что приводит к обнаружению повторяющихся ресурсов с нескольких первичных сайтов. Тщательно настройте методы обнаружения для оптимизации взаимодействия с целевой службой, например контроллерами домена 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. Операции ввода-вывода в секунду: папки "Входящие" и операции ввода-вывода в секунду: SQL

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

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

Примечание 4. Требуется дисковое пространство

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

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

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

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

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

1. Скачайте служебную программу Diskspd.

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

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

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

   Например, используйте следующие командные строки для тестирования тома 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

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

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

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

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

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

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

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

См. также

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