Планирование емкости для служб домен Active Directory

В этой статье приведены рекомендации по планированию емкости для служб домен Active Directory (AD DS).

Цели планирования емкости

Планирование емкости не совпадает с устранением неполадок с производительностью. Цели планирования емкости:

• Правильно реализуйте и управляйте средой.
• Свести к минимуму время, затрачиваемое на устранение неполадок с производительностью.

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

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

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

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

• Virtualization
• Высокоскоростные устройства хранения, такие как твердотельные накопители (SSD) и интерфейс NVMe (nonvolatile memory express)
• Облачные сценарии

Доменные службы Active Directory (AD DS) — это зрелая распределенная служба, которую многие продукты Майкрософт и сторонних производителей используют в качестве серверной части. Это один из наиболее важных компонентов для обеспечения того, чтобы другие приложения имели необходимую емкость.

Важные сведения, которые следует учитывать перед началом планирования

Чтобы получить большую часть этой статьи, сделайте следующее:

• Убедитесь, что вы ознакомились с рекомендациями по настройке производительности для Windows Server и ознакомились с ней.
• Платформа Windows Server — это архитектура на основе x64, которая обеспечивает большее адресное пространство памяти по сравнению с системами x86. Рекомендации этой статьи применяются к среде Active Directory независимо от версии Windows Server. В текущих выпусках расширенные возможности памяти x64 позволяют кэшированию больших баз данных в памяти, хотя принципы планирования емкости остаются неизменными. Рекомендации также применяются, если в вашей среде есть дерево сведений о каталоге (DIT), которое может полностью соответствовать доступной системной памяти.
• Понять, что планирование емкости является непрерывным процессом, поэтому следует регулярно проверять, насколько хорошо вы создаете среду, соответствует вашим ожиданиям.
• Понять, что оптимизация происходит в течение нескольких жизненных циклов оборудования в результате изменения затрат на оборудование. Например, если память становится дешевле, стоимость на ядро уменьшается или цена различных вариантов хранения изменяется.
• Планирование ежедневного пикового периода занятости. Рекомендуется создавать планы на основе 30 минут или часовых интервалов. При выборе интервала следует учитывать следующие сведения:
  • Интервалы, превышающие один час, могут скрыть моменты, когда сервис достигает пиковой пропускной способности.
  • Интервалы менее 30 минут могут заставить временные колебания выглядеть более важными, чем они на самом деле.
• Планирование роста на протяжении жизненного цикла оборудования для предприятия. Это планирование роста может включать стратегии обновления или добавления оборудования поэтапно, или полное обновление раз в три-пять лет. Для каждого плана роста требуется оценить, сколько нагрузки на Active Directory растет. Исторические данные помогут вам сделать более точную оценку.
• Отказоустойчивость — это возможность системы продолжать работу должным образом при сбое некоторых компонентов. После определения необходимой емкости (известной как n), следует запланировать отказоустойчивость. Рассмотрим n + 1, n + 2 или даже n + x сценариев. Например, если вам нужно два контроллера домена (DC), планируйте три, чтобы можно было справиться с одним сбоем контроллера домена.

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

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

    Note

    Добавление приложений с поддержкой Active Directory может существенно повлиять на нагрузку контроллера домена, независимо от того, поступает ли загрузка с серверов приложений или клиентов.

Цикл планирования емкости в трех частях

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

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

Сценарии виртуализации предоставляют два варианта:

• Прямое сопоставление, где у вас есть только один гость на узел.
• Сценарии общего узла, где имеется несколько гостей на узел.

Сценарии прямого сопоставления идентичны физическим узлам. При выборе сценария общего узла он вводит другие переменные, которые следует учитывать в последующих разделах. Общие узлы также конкурируют за ресурсы с доменными службами Active Directory (AD DS), что может повлиять на производительность системы и взаимодействие с пользователем.

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

1. Измеряйте существующую среду, определите, где в настоящее время находятся узкие места в системе, и получите основы среды, необходимые для планирования объема емкости, необходимой для развертывания.
2. Определите, какое оборудование требуется на основе требований к емкости.
3. Отслеживайте и проверяйте, работает ли настроенная инфраструктура в спецификациях. Данные, собранные на этом шаге, становятся базовыми для следующего цикла планирования емкости.

Применение процесса

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

• Memory
• Network
• Storage
• Processor
• Netlogon

Базовые требования к хранилищу для AD DS и общее поведение совместимого клиентского программного обеспечения означают, что современное оборудование класса сервера легко соответствует потребностям планирования емкости сред с 10 000 до 20 000 пользователей. Хотя планирование емкости остается важным для всех развертываний, небольшие среды обычно имеют большую гибкость в выборе оборудования, так как большинство текущих серверных систем могут обрабатывать эти нагрузки, не требуя специализированной оптимизации.

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

Другие сведения, которые следует учитывать при планировании:

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

Сводные таблицы сбора данных

В следующих таблицах перечислены критерии определения оценки оборудования.

Рабочая среда

Высокоуровневые критерии оценки

Planning

В течение длительного времени типичная рекомендация по определению объема AD DS состояла в том, чтобы установить столько ОЗУ, сколько объем базы данных. Хотя увеличение вычислительной мощности и переход с архитектуры x86 на x64 сделало более тонкие аспекты изменения размера для производительности менее важными для AD DS, размещенных на физических компьютерах, виртуализация подчеркнула важность настройки производительности.

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

RAM

Чем больше хранилища можно кэшировать в ОЗУ, тем меньше необходимо перейти на диск.

Чтобы повысить масштабируемость сервера, вычислите минимальные требования к ОЗУ, суммируя эти компоненты:

• Текущий размер базы данных
• Рекомендуемая сумма для операционной системы
• Рекомендации поставщика для агентов, например:
  • Антивирусная программа
  • Мониторинг программного обеспечения
  • Резервное копирование приложений

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

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

• Вспомогательные расположения с ограничениями бюджета
• Развертывания, в которых дерево сведений о каталоге (DIT) слишком большое для размещения в памяти

Еще одним важным фактором, который следует учитывать при изменении размера памяти, является размер файла страницы. При изменении размера диска, как и все остальное, связанное с памятью, цель заключается в минимизации использования дисков. В частности, сколько ОЗУ необходимо свести к минимуму разбиение по страницам? Следующие несколько разделов должны дать вам информацию, необходимую для ответа на этот вопрос. Другие рекомендации по размеру страницы, которые не обязательно влияют на производительность AD DS, являются рекомендациями по операционной системе и настройке системы для дампов памяти.

Определение объема ОЗУ контроллера домена (DC) может быть сложно из-за многих сложных факторов:

• Существующие системы не всегда являются надежными индикаторами требований к ОЗУ, так как служба подсистемы локального центра безопасности (LSASS) уменьшает ОЗУ при нехватке памяти, искусственно занижая требования.
• Отдельные контроллеры домена должны кэшировать данные своих клиентов. Это означает, что данные, кэшированные в разных средах, изменяются в зависимости от типов клиентов, которые он содержит. Например, контроллер домена в среде с Exchange Server собирает данные, отличные от контроллера домена, который выполняет проверку подлинности только пользователей.
• Объем усилий, необходимых для оценки ОЗУ для каждого контроллера домена на основе регистра, часто является чрезмерным и изменяется по мере изменения среды.

Критерии рекомендаций помогут вам принять более обоснованные решения:

• Чем больше кэшируете в ОЗУ, тем меньше необходимо перейти на диск.
• Хранилище — это самый медленный компонент компьютера. Доступ к данным на основе спинделя и носителей SSD меньше, чем доступ к данным в ОЗУ.

Рекомендации по виртуализации оЗУ

Ваша цель оптимизации ОЗУ — свести к минимуму время, затраченное на диск. Избегайте перераспределения памяти на хосте (выделение большего объема ОЗУ гостям, чем имеется на физической машине). Превышение памяти само по себе не является проблемой, но если общее использование гостевых клиентов превышает ОЗУ хоста, хост начинает выгружать страницы. Пейджинг делает производительность зависимой от диска, когда DC (контроллер домена) обращается к NTDS.dit или файлу подкачки, или когда хост осуществляет пейджинг ОЗУ. Это поведение резко снижает производительность и взаимодействие с пользователем.

Пример сводки вычислений

Рекомендуется: 16 ГБ

С течением времени в базу данных добавляются дополнительные данные, а средняя продолжительность жизни сервера составляет около трех–пяти лет. Учитывая оценку роста в 33%, 18 ГБ — это разумный объем ОЗУ для установки в физический сервер.

Network

В этом разделе рассматривается оценка общего объема пропускной способности и емкости сети, необходимых для развертывания, включая запросы клиента, параметры групповой политики и т. д. Вы можете собирать данные для оценки с помощью Network Interface(*)\Bytes Received/sec счетчиков производительности и Network Interface(*)\Bytes Sent/sec счетчиков производительности. Выборка интервалов для счетчиков сетевых интерфейсов должна составлять 15, 30 или 60 минут. Что-то меньшее слишком неустойчивое для хороших измерений, и что-нибудь больше чрезмерно сглаживает ежедневные пики.

Требования к пропускной способности

Планирование масштабируемости сети охватывает две отдельные категории: объем трафика и нагрузку ЦП из сетевого трафика.

При планировании емкости для поддержки трафика необходимо учитывать две вещи. Во-первых, необходимо знать, сколько трафика репликации Active Directory проходит между контроллерами домена. Во-вторых, необходимо оценить внутренний трафик клиента к серверу. Внутренний трафик в основном получает небольшие запросы от клиентов относительно больших объемов данных, которые он отправляет обратно клиентам. 100 МБ обычно достаточно для сред с до 5000 пользователей на сервер. Для сред с числом пользователей более 5000 мы рекомендуем использовать сетевой адаптер со скоростью 1 Гб/с и поддержку масштабирования на стороне получения (RSS).

Чтобы оценить пропускную способность внутрисайтового трафика, особенно в сценариях консолидации сервера, необходимо просмотреть Network Interface(*)\Bytes/sec счетчик производительности на всех контроллерах домена на сайте, добавить их вместе, а затем разделить сумму на целевое число контроллеров домена. Простой способ вычисления этого числа — открыть представление надежности Windows и Монитор производительности и просмотреть представление области с накоплением. Убедитесь, что все счетчики масштабируются одинаково.

Рассмотрим пример более сложного способа проверки того, что это общее правило применяется к определенной среде. В этом примере мы делаем следующие предположения:

• Цель состоит в том, чтобы сократить объем ресурсов до максимально возможного количества серверов. В идеале один сервер несет нагрузку, а затем развертывает другой сервер для избыточности (n + 1 сценарий).
• В этом сценарии текущий сетевой адаптер поддерживает только 100 Мбит и находится в коммутируемой среде.
• Максимальное использование целевой пропускной способности сети составляет 60% в сценарии n (потеря контроллера домена).
• Каждый сервер имеет около 10 000 клиентов, подключенных к нему.

Теперь давайте рассмотрим, что диаграмма в счетчике Network Interface(*)\Bytes Sent/sec отображается в этом примере сценария:

1. Рабочий день начинается нарастать около 5:30 утра и уйдет в 7:00 вечера.
2. Пиковый загруженный период составляет от 8:00 до 8:15, с более чем 25 байтами, отправленными в секунду на самый загруженный контроллер домена.

   Note

   Все данные производительности являются историческими, поэтому пиковая точка данных в 8:15 указывает нагрузку с 8:00 до 8:15.

3. Есть пики до 4:00, с более чем 20 байтами, отправленными в секунду на самый загруженный контроллер домена, который может указывать на загрузку из разных часовых поясов или фоновых действий инфраструктуры, таких как резервные копии. Так как пик в 8:00 превышает это действие, это не актуально.
4. На сайте есть пять контроллеров домена.
5. Максимальная нагрузка составляет около 5,5 МБ/с на центр обработки данных, что составляет 44% от скорости подключения 100 МБ/с. Используя эти данные, мы можем оценить, что общая пропускная способность, необходимая в диапазоне от 8:00 до 8:15 утра, составляет 28 МБИТ/с.

   Note

   Счетчики отправки и получения сетевого интерфейса находятся в байтах, но пропускная способность сети измеряется в битах. Поэтому для вычисления общей пропускной способности необходимо выполнить 100 МБ ÷ 8 = 12,5 МБ и 1 ГБ ÷ 8 = 128 МБ.

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

• Текущая среда соответствует уровню отказоустойчивости n + 1 при 60% целевом использовании. Использование одной системы в автономном режиме перемещает пропускную способность на сервер примерно с 5,5 МБИТ/с (44%) на около 7 МБИТ/с (56%).
• Исходя из ранее указанной цели консолидации на один сервер, это изменение консолидации превышает максимальное целевое использование и возможное использование подключения размером 100 МБ.
• При 1 ГБ соединении это значение пропускной способности на сервер представляет собой 22% от общей пропускной способности.
• В нормальных условиях работы в сценарии n + 1 нагрузка клиента распределяется примерно на 14 МБ/с на сервер, что составляет 11% от общей емкости.
• Чтобы убедиться, что у вас достаточно производительности во время недоступности контроллера домена, нормальные операционные показатели для сервера составят около 30% загрузки сети или 38 МБ/с на сервер. Целевые показатели для отработки отказа будут составлять 60% использования сети или 72 МБ/с на сервер.

Окончательное развертывание системы должно иметь сетевой адаптер 1 ГБ и подключение к сетевой инфраструктуре, которая может поддерживать необходимую нагрузку. Из-за объема сетевого трафика загрузка ЦП из сетевых коммуникаций может ограничить максимальную масштабируемость AD DS. Этот же процесс можно использовать для оценки входящего взаимодействия с контроллером домена. Однако в большинстве сценариев не нужно вычислять входящий трафик, так как он меньше исходящего трафика.

Важно убедиться, что оборудование поддерживает RSS в средах с более чем 5000 пользователями на сервер. В сценариях высокой нагрузки сетевого трафика балансировка нагрузки на прерывания может стать узким местом. Вы можете обнаружить потенциальные узкие места, проверив Processor(*)\% Interrupt Time счетчик, чтобы узнать, распределяется ли время прерывания неравномерно между ЦП. Контроллеры сетевых интерфейсов с поддержкой RSS могут снизить эти ограничения и повысить масштабируемость.

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

Типичная рекомендация для физического сервера — это адаптер 1 ГБ для серверов, поддерживающих более 5000 пользователей. После того как несколько гостей начнут совместно использовать базовую инфраструктуру виртуального коммутатора, убедитесь, что узел имеет достаточную агрегированную пропускную способность сети для поддержки всех гостей. Учет пропускной способности в обоих сценариях: при запуске доменного контроллера в качестве виртуальной машины на узле с сетевым трафиком через виртуальный коммутатор и при подключении непосредственно к физическому коммутатору. Виртуальные коммутаторы требуют тщательного планирования пропускной способности. Связь вверх должна поддерживать агрегированные данные, передаваемые через неё. Сетевой адаптер физического узла, связанный с коммутатором, должен поддерживать нагрузку центра обработки данных и всех других гостей, которые совместно используют виртуальный коммутатор и подключаются через физический адаптер.

Пример сводки по вычислению сети

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

В соответствии с этой таблицей рекомендуемая пропускная способность будет составлять 72MBps (28,5 МБИТ/с ÷ 40%).

Как всегда, следует предположить, что загрузка клиента будет увеличиваться со временем, поэтому следует планировать этот рост как можно раньше. Рекомендуется планировать по крайней мере 50% предполагаемый рост сетевого трафика.

Storage

При планировании емкости для хранилища следует учитывать два способа.

• Размер емкости или хранилища
• Performance

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

Sizing

Оценка хранилища

По сравнению с тем, когда Active Directory впервые прибыл в то время, когда 4 ГБ и 9 ГБ дисков были самыми распространенными размерами дисков, теперь размер для Active Directory даже не учитывается для всех, кроме крупнейших сред. С наименьшими доступными размерами жестких дисков в диапазоне 180 ГБ, вся операционная система, SYSVOL и NTDS.dit могут легко поместиться на одном диске. В результате мы рекомендуем избежать слишком сильного инвестирования в размер хранилища.

Рекомендуем, чтобы было доступно 110% размера NTDS.dit, чтобы вы могли дефрагментировать своё хранилище.

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

Если вы собираетесь оценить хранилище, сначала необходимо оценить, насколько большой NTDS.dit и SYSVOL должен быть. Эти измерения помогут вам определить размер выделения для фиксированного диска и ОЗУ. Так как компоненты относительно низкие затраты, вам не нужно быть супер точным при выполнении математики. Дополнительные сведения об оценке хранилища см. в разделе "Ограничения хранилища " и "Оценки роста" для пользователей Active Directory и организационных подразделений.

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

Размеры баз данных могут отличаться от версий ОС. Контроллеры домена, работающие под управлением более ранних версий ОС, имеют меньший размер базы данных, чем работающие на более поздней версии. Контроллер домена с такими функциями, как rEcycle Bin или Credential Roaming, также может повлиять на размер базы данных.

Рекомендации по виртуализации хранилища

В сценариях, когда вы выделяете несколько файлов виртуального жесткого диска (VHD) на один том, следует использовать фиксированный диск состояния. Диск должен быть не менее 210% размера DIT, чтобы обеспечить достаточно зарезервированного места для ваших нужд. Этот фиксированный размер VHD включает в себя 100% размера DIT плюс 110% свободного места.

Пример сводки вычислений хранилища

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

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

• SYSVOL
• Файлы операционной системы
• Файл страницы
• Временные файлы
• Локальные кэшированные данные, такие как файлы установщика
• Приложения

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

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

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

• RAID
• Новые типы хранилища и сценарии виртуализированного и общего хранилища
• Общие спиндели в сети зоны хранения (SAN)
• VHD-файл в хранилище, подключенном к сети или san
• Твердотельные накопители (SSD)
• Энергонезависимые накопители памяти (NVMe)
• Многоуровневые архитектуры хранилища, такие как кэширование уровня хранилища SSD с большим объемом хранилища на основе спинdle

Другие рабочие нагрузки, размещенные на бекендовом хранилище, могут перегружать общее хранилище, например RAID, SAN, NAS, JBOD, пространства хранилища и VHD. Эти типы устройств хранения могут представлять дополнительную рекомендацию. Например, проблемы с SAN, сетью или драйвером, возникающие между физическим диском и приложением AD, могут привести к ограничению и задержкам. Чтобы прояснить, эти типы архитектур хранилища не являются плохим выбором, но они более сложны, что означает, что необходимо обратить дополнительное внимание, чтобы убедиться, что каждый компонент работает в качестве предполагаемого. Более подробные объяснения см. в приложении C и приложении D далее в этой статье.

Эта технология хранения с твердым состоянием (NVMe и SSD) не имеет одинаковых механических ограничений, что и традиционные жесткие диски. Однако они по-прежнему имеют ограничения ввода-вывода. При превышении этих ограничений система может стать перегруженной.

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

Из-за того, сколько вариантов хранения доступны сегодня, мы рекомендуем обратиться к группам поддержки оборудования или поставщикам, планируя, чтобы решение соответствовало потребностям развертывания AD DS. Во время этих бесед можно найти следующие счетчики производительности, особенно если база данных слишком велика для ОЗУ:

• LogicalDisk(*)\Avg Disk sec/Read (например, если NTDS.dit хранится на диске D, полный путь будет LogicalDisk(D:)\Avg Disk sec/Read)
• LogicalDisk(*)\Avg Disk sec/Write
• LogicalDisk(*)\Avg Disk sec/Transfer
• LogicalDisk(*)\Reads/sec
• LogicalDisk(*)\Writes/sec
• LogicalDisk(*)\Transfers/sec

При предоставлении данных следует убедиться, что интервалы выборки равны 15, 30 или 60 минут, чтобы дать наиболее точное представление о текущей среде.

оценка результатов;

В этом разделе основное внимание уделяется считываниям из базы данных, так как база данных обычно является наиболее требовательным компонентом. Вы можете применить ту же логику для записи в файл журнала, подставив <NTDS Log>)\Avg Disk sec/Write и LogicalDisk(<NTDS Log>)\Writes/sec).

Счетчик LogicalDisk(<NTDS>)\Avg Disk sec/Read показывает, правильно ли размер текущего хранилища. Если значение примерно равно ожидаемому времени доступа к диску для типа диска, LogicalDisk(<NTDS>)\Reads/sec счетчик является допустимой мерой. Если результаты примерно равны времени доступа к диску для типа диска, LogicalDisk(<NTDS>)\Reads/sec счетчик является допустимой мерой. Хотя допустимая задержка зависит от поставщика хранилища, хорошие диапазоны для LogicalDisk(<NTDS>)\Avg Disk sec/Read :

• 7200 об/мин: от 9 миллисекунд до 12.5 миллисекунд (мс)
• 10 000 rpm: 6 мс до 10 мс
• 15 000 rpm: 4 мс до 6 мс
• SSD — 1 мс до 3 мс

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

• LogicalDisk(<NTDS>)\Reads/sec — это объем операций ввода-вывода, который в настоящее время выполняет система.
  • Если LogicalDisk(<NTDS>)\Avg Disk sec/Read находится в оптимальном диапазоне для внутреннего хранилища, вы можете напрямую использовать LogicalDisk(<NTDS>)\Reads/sec для размера хранилища.
  • Если LogicalDisk(<NTDS>)\Avg Disk sec/Read не находится в оптимальном диапазоне для внутреннего хранения, необходимо использовать больше операций ввода-вывода согласно следующей формуле: LogicalDisk(<NTDS>)\Avg Disk sec/Read ÷ время доступа к диску физического носителя × LogicalDisk(<NTDS>)\Avg Disk sec/Read

При выполнении этих вычислений ниже приведены некоторые аспекты, которые следует учитывать:

• Если сервер имеет неоптимальное количество ОЗУ, полученные значения могут быть слишком высокими и недостаточно точными, чтобы быть полезными для планирования. Однако их можно использовать для прогнозирования худших сценариев.
• При добавлении или оптимизации ОЗУ также уменьшается объем операций ввода-вывода LogicalDisk(<NTDS>)\Reads/Sec. Это снижение может привести к тому, что решение хранилища будет менее надежным, чем предложенные первоначальные вычисления. К сожалению, мы не можем дать более конкретные сведения о том, что это означает, так как вычисления зависят от отдельных сред, особенно клиентской нагрузки. Однако рекомендуется настроить размер хранилища после оптимизации ОЗУ.

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

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

• Физический компакт-диск совместно использует один и тот же носитель в инфраструктуре SAN, NAS или iSCSI, что и другие серверы или приложения.
• Пользователь, использующий сквозной доступ к инфраструктуре SAN, NAS или iSCSI, которая использует носитель.
• Пользователь, использующий VHD-файл на общем носителе локально или в локальной инфраструктуре SAN, NAS или iSCSI.

С точки зрения гостевого пользователя, необходимость получения доступа к любому хранилищу через хост влияет на производительность, так как пользователю приходится проходить больше путей кода, чтобы получить доступ. Тестирование производительности указывает, что виртуализация влияет на пропускную способность в зависимости от того, сколько процессор использует хост-система. Использование процессора влияет на количество ресурсов, требуемых гостевым пользователем от узла. Этот спрос способствует обработке рекомендаций по виртуализации, которые необходимо принять для обработки потребностей в виртуализированных сценариях. Дополнительные сведения см. в приложении A.

Усложняет ситуацию наличие множества вариантов хранения, каждый из которых значительно по-разному влияет на производительность. К этим параметрам относятся сквозное хранилище, адаптеры SCSI и интегрированная среда разработки. При миграции с физической среды на виртуальную среду следует настроить различные параметры хранения для виртуализированных гостевых пользователей с помощью умножения 1.10. Однако при передаче между различными сценариями хранения не нужно учитывать корректировки, так как хранилище является локальным, SAN, NAS или iSCSI более важным.

Пример вычисления виртуализации

Определение количества операций ввода-вывода, необходимого для работоспособной системы в обычных условиях эксплуатации:

• Логический диск (<NTDS Database Drive>) ÷ трансферы в секунду во время пикового 15-минутного периода
• Чтобы определить объем операций ввода-вывода, необходимого для хранения, в котором превышается емкость базового хранилища:

  Необходимые операции ввода-вывода в секунду = (ЛогическийDisk(<NTDS Database Drive>)) ÷ avg Disk Read/sec ÷ <Target Avg Disk Read/sec>) × LogicalDisk(<NTDS Database Drive>)\Read/sec

Чтобы определить скорость, с которой следует прогреть кэш:

• Определите максимально допустимое время, которое можно потратить на потепление кэша. В типичных сценариях допустимое количество времени — сколько времени потребуется для загрузки всей базы данных с диска. В сценариях, когда ОЗУ не может загрузить всю базу данных, используйте время, необходимое для заполнения всей ОЗУ.
• Определите размер базы данных, за исключением пространства, которое вы не планируете использовать. Дополнительные сведения см. в разделе "Оценка для хранилища".
• Разделите размер базы данных на 8 КБ, чтобы получить общее количество операций ввода-вывода, необходимое для загрузки базы данных.
• Разделите общее число операций ввода-вывода по количеству секунд в определенном интервале времени.

Число, которое вы вычисляете, является приблизительным. Это не совсем точно, потому что размер кэша Extensible Storage Engine (ESE) не фиксирован. По умолчанию кэш растет и уменьшается, поэтому AD DS может вытеснить страницы, загруженные ранее. Фиксированный размер кэша делает оценку более точной.

Processing

Оценка использования процессора Active Directory

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

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

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

• Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read
• Process(lsass)\ Processor Time

Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read Если счетчик превышает 10 миллисекунд или 15 миллисекунд, данные в Process(lsass)\ Processor Time искусственно занижены, и проблема связана с производительностью хранилища. Рекомендуется задать интервалы выборки 15, 30 или 60 минут для наиболее точных данных.

Обзор обработки

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

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

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

Профиль поведения целевого сайта

При планировании емкости для всего сайта ваша цель должна быть проектированием емкости N + 1. В этой структуре, даже если одна система завершается сбоем в течение пикового периода, служба по-прежнему может продолжаться на приемлемых уровнях качества. В сценарии N загрузка во всех полях должна быть меньше 80%–100% во время пиковых периодов.

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

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

В первом примере мы делаем следующие предположения:

• Каждый из пяти ЦП на сайте имеет четыре ЦП.
• Общее целевое использование ЦП в рабочие часы составляет 40% в обычных условиях эксплуатации (N + 1) и 60% в противном случае (N). В нерабочее время целевое использование ЦП составляет 80%, так как мы ожидаем, что программное обеспечение резервного копирования и другие процессы обслуживания будут использовать все доступные ресурсы.

Теперь давайте рассмотрим диаграмму (Processor Information(_Total)\% Processor Utility) для каждого из контроллеров домена, как показано на следующем рисунке.

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

• В нескольких пятиминутных интервалах есть пики на 10%, иногда даже на 20%. Однако если эти пики не приводят к превышению целевого объекта плана загрузки ЦП, их не нужно исследовать.

• Пиковый период для всех систем составляет от 8:00 до 9:15. Средний рабочий день длится с 5:00 до 5:00 вечера. Таким образом, любые случайные пики использования ЦП, которые происходят в период от 5:00 до 4:00, находятся за пределами рабочих часов, и поэтому вам не нужно включать их в задачи планирования емкости.

  В нерабочие часы кратковременные пики в хорошо управляемой системе обычно приходят из:

  • Задания резервного копирования
  • Полные проверки антивирусной программы
  • Проверки инвентаризации оборудования
  • Проверки инвентаризации программного обеспечения
  • Распространение программного обеспечения или развертывание исправлений

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

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

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

В этом примере два контроллера домена работают на 40%. Один переходит в автономный режим, и оставшийся контроллер домена увеличивается до предполагаемого показателя 80%. Во время переключения на резерв эта нагрузка превышает пороговое значение плана емкости и уменьшает запас мощности до 10%–20% для пиков. Каждый пик теперь может привести центр обработки данных к 90% или даже 100%, уменьшая отзывчивость.

Вычисление требований ЦП

Счетчик Process\% Processor Time производительности отслеживает общее время всех потоков приложений, потраченных на ЦП, а затем делит эту сумму на общий объем пройденного системного времени. Многопоточное приложение в системе с несколькими ЦП может превышать 100% времени ЦП, и вы будете интерпретировать его данные иначе, чем данные счетчика Processor Information\% Processor Utility. На практике счетчик Process(lsass)\% Processor Time отслеживает, сколько ЦП работает в 100 % системы, требуется для поддержки требований процесса. Например, если счетчик имеет значение 200 %, это означает, что системе требуется два ЦП, работающих на 100 % для поддержки полной загрузки AD DS. Хотя ЦП, работающий на полную мощность, является самым экономным с точки зрения потребления энергии, многопоточная система более быстродействующая, когда система не загружена на 100%. Причины этой эффективности описаны в приложении A.

Чтобы обеспечить временные пики нагрузки клиента, рекомендуется использовать пиковый период ЦП от 40% до 60 % емкости системы. Например, в первом примере в профиле поведения целевого сайта для поддержки загрузки AD DS потребуется от 3,33 ЦП (60 % целевого объекта) до 5 ЦП (40 %. Вы должны добавить дополнительную емкость в соответствии с требованиями ОС и любых других необходимых агентов, таких как антивирусная программа, резервное копирование, мониторинг и т. д. Планируйте резервировать 5–10% емкости одного ЦП для агентов инфраструктуры (антивирусная программа, резервное копирование, мониторинг). Измеряйте фактическое использование агента в вашей среде и корректируйте его при необходимости. Чтобы вернуться к нашему примеру, нам потребуется от 3,43 (60 % целевого объекта) до 5,1 (40 % целевых процессоров) для поддержки нагрузки во время пиковых периодов.

Теперь рассмотрим пример вычисления для определенного процесса. В этом случае мы рассмотрим процесс LSASS.

Вычисление использования ЦП для процесса LSASS

В этом примере система представляет собой сценарий N + 1, где один сервер несет нагрузку AD DS, а дополнительный сервер существует для избыточности.

На следующей диаграмме показано время процессора для процесса LSASS во всех процессорах для этого примера сценария. Эти точки данных приходят из счетчика производительности Process(lsass)\% Processor Time.

Ниже приведена диаграмма времени процессора LSASS, отображаемая в среде сценария:

• На сайте есть три контроллера домена.
• Рабочий день начинается наращивать около 7:00 утра, а затем нарастает вниз в 5:00 вечера.
• Самый оживленный период дня — от 9:30 до 11:00.

  Note

  Все данные о производительности являются историческими. Точка пиковых данных в 9:15 указывает нагрузку с 9:00 до 9:15.

• Пики до 7:00 могут указывать на дополнительную нагрузку из разных часовых поясов или фоновых действий инфраструктуры, таких как резервные копии. Однако, поскольку этот пик ниже пиковой активности в 9:30, это не причина для беспокойства.

При максимальной нагрузке процесс LSASS потребляет около 4,85 ЦП, работающих в 100%, что будет 485% на одном ЦП. Эти результаты показывают, что сайту сценария требуется около 12/25 ЦП для обработки AD DS. При добавлении рекомендуемой 5%-10% дополнительной емкости для фоновых процессов серверу требуется 12,30 до 12,25 ЦП для поддержки текущей нагрузки. Оценки, ожидающие будущего роста, делают это число еще выше.

Настройка весов LDAP

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

В следующих разделах описаны два примера сценариев, в которых следует настроить вес протокола LDAP.

Пример 1. Среда эмулятора PDC

Если вы используете эмулятор основного контроллера домена (PDC), поведение пользователей или приложений с неравномерно распределенным распределением может повлиять на несколько сред одновременно. Эмулятор PDC обычно имеет более высокую нагрузку ЦП, чем другие контроллеры домена. Многие операции предпочитают или всегда обращаются к нему, например:

• Средства управления групповыми политиками (создание, редактирование, связывание, обновление GPMC)
• Проверка изменений паролей / вторая попытка проверки подлинности (резервная проверка пароля)
• Операции создания и поддержания доверительных отношений
• Иерархия служб времени (доверенный источник времени в домене или лесу)
• Обработка блокировки учетной записи
• Устаревшие или неправильно настроенные приложения, которые по-прежнему предназначены для эмулятора PDC

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

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

В этих случаях задайте значение от LDAPSrvWeight 50 до 75 для эмулятора PDC.

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

В этом примере предполагается, что на основе профиля поведения целевого сайта все три контроллера домена на этом сайте имеют четыре ЦП. В обычных условиях, что произойдет, если один из этих ЦП имел восемь ЦП? Было бы два контроллера домена при использовании 40 % и один при 20% использовании. Хотя эта конфигурация не обязательно плоха, здесь есть возможность использовать настройку веса LDAP для балансировки нагрузки лучше.

Пример 2. Среда с разными счетчиками ЦП

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

Планирование сценария N + 1 имеет решающее значение. Влияние одного контроллера домена в автономном режиме должно быть рассчитано для каждого сценария. В предыдущем примере загрузка равномерно распределяется по всем серверам. В сценарии N (один сервер потерян) нагрузка на каждый оставшийся сервер остается примерно на уровне 60%. Текущее распределение приемлемо, так как коэффициенты остаются согласованными. При просмотре сценария настройки эмулятора PDC или любого общего сценария, в котором нагрузка пользователя или приложения не сбалансирована, эффект отличается:

Рекомендации по виртуализации для обработки

При планировании емкости для виртуализированной среды необходимо учитывать два уровня: уровень узла и гостевой уровень. На уровне узла необходимо определить пиковые периоды бизнес-цикла. Так как планирование гостевых потоков на ЦП для виртуальной машины аналогично получению потоков AD DS на ЦП физического компьютера, мы по-прежнему рекомендуем использовать 40% до 60% базового узла. На гостевом уровне, так как базовые принципы планирования потоков не изменяются, мы также рекомендуем сохранить использование ЦП в диапазоне от 40 до 60 %.

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

При использовании совместного хостинга предположительно на виртуализацию приходится около 10% падения эффективности ЦП. Если сайту требуется 10 ЦП на 40% целевого использования на физическом оборудовании, добавьте еще один ЦП для этой нагрузки. Выделите в общей сложности 11 виртуальных ЦП (vCPUs) между контроллерами гостевого домена N.

На сайтах с смешанным распределением физических и виртуальных серверов эта нагрузка на виртуализацию применяется только к виртуальным машинам. В проекте N + 1 физический сервер с 10 ЦП (или сервер с прямым отображением) примерно эквивалентен виртуальному ЦОД с 11 виртуальными ЦП. На узле также требуется еще 11 ЦП, зарезервированных для этой виртуальной машины.

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

Пример сводки вычислений виртуализации

Если вы планируете 50% рост спроса в течение трех лет, планируйте на 18,375 ЦП (12,25 × 1,5) к тому времени. Кроме того, вы можете просмотреть спрос после первого года, а затем добавить дополнительную емкость в зависимости от того, какие результаты говорят вам.

Загрузка проверки подлинности клиента с перекрестным доверием для NTLM

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

Во многих средах может быть один или несколько доменов, связанных отношениями доверия. Запросы проверки подлинности для удостоверений в других доменах, которые не используют Kerberos, должны проходить проверку доверия с помощью безопасного канала между двумя контроллерами домена. Контроллер домена пользователя обращается к контроллеру домена в целевом домене или следующему по пути доверия к нему. Параметр *MaxConcurrentAPI управляет количеством вызовов, которые контроллер домена может сделать к другому контроллеру домена в доверенном домене. Чтобы обеспечить защиту канала, можно обрабатывать объем нагрузки, необходимый для взаимодействия между контроллерами домена, можно настроить MaxConcurrentAPI или, если вы находитесь в лесу, создайте ярлыки доверия. Дополнительные сведения о том, как определить объем трафика в довериях, см. в разделе "Как настроить производительность для проверки подлинности NTLM" с помощью параметра MaxConcurrentApi.

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

Планирование виртуализации

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

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

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

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

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

Чтобы настроить MaxConcurrentAPI на существующем сервере, используйте следующее уравнение:

New_MaxConcurrentApi_setting≥ × + average_semaphore_hold_time semaphore_acquiressemaphore_time × ÷ time_collection_length

Дополнительные сведения см . в статье базы знаний 2688798. Как настроить производительность для проверки подлинности NTLM с помощью параметра MaxConcurrentApi.

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

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

Пример вычисления настройки виртуализации

Для этой системы в течение этого периода времени допустимы значения по умолчанию.

Мониторинг соответствия целям планирования емкости

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

Приложение A. Критерии изменения размера ЦП

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

Определения: размер ЦП

• Процессор (микропроцессор) — это компонент, который считывает и выполняет инструкции программы.

• Процессор с несколькими ядрами имеет несколько ЦП в одном интегрированном канале.

• Система с несколькими ЦП имеет несколько ЦП, которые не имеют одного интегрированного канала.

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

К этим определениям относятся гиперпотоки, один ядро на многоядерный процессор или один основной процессор.

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

Параллелизм на уровне потока

Каждый поток является независимой задачей, так как каждый поток имеет собственный стек и инструкции. AD DS может хорошо масштабироваться между несколькими логическими процессорами, так как он многопотоковый и может быть настроено количество доступных потоков. Дополнительные сведения о настройке доступных потоков см. в руководстве по просмотру и настройке политики LDAP в Active Directory с помощью Ntdsutil.exe.

Параллелизм на уровне данных

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

Рекомендации по скорости ЦП и нескольким ядрам

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

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

• Один исполняемый поток завершается быстрее на более быстром ядре; добавление еще простоящих ядер не дает преимуществ, если не выполняется параллельная работа.
• Когда поток останавливается из-за пропуска кэша или нуждается в данных из основной памяти, он не может продолжать работу до тех пор, пока данные не вернутся. Более быстрые ядра не устраняют задержку памяти; они могут ждать больше времени относительно скорости цикла.
• По мере увеличения параллелизма (запускаемых потоков) синхронизация, трафик согласованности кэша, конфликт блокировки и накладные расходы планировщика используют больший процент общих циклов.
• Более широкие системы (больше сокетов или ядер) усиливают эффекты задержки для операций, требующих глобального упорядочения (например, изменение общих данных, TLB сбросы, межпроцессорные прерывания).
• Некоторые пути кода сериализуются (закон Амдала). После насыщения параллельных регионов дополнительные ядра способствуют убывающей отдаче.

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

В итоге вопросы о том, следует ли добавлять более или более быстрые процессоры, становятся весьма субъективными и должны рассматриваться на основе регистра. Для AD DS, в частности, его потребности в обработке зависят от экологических факторов и могут отличаться от сервера до сервера в пределах одной среды. В результате предыдущие разделы в этой статье не вкладывайте значительные средства в создание супер точных вычислений. При принятии решений по покупке на основе бюджета рекомендуется сначала оптимизировать использование процессора на 40 % или в зависимости от того, что требуется для конкретной среды. Если ваша система не оптимизирована, вы не получаете выгоду от покупки дополнительных процессоров.

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

Теория очередей — это математическое исследование очередей или очередей. В теории очередей для вычислений закон использования представлен формулой t:

U k = B ÷ T

Где U k является процентом использования, B — это время, затрачиваемое на занятое время, и T — общее время, затрачиваемое на наблюдение за системой. В контексте Майкрософт это означает количество потоков интервала 100-nanosecond (ns), разделенных на количество интервалов 100-ns в заданном интервале времени. Это та же формула, которая вычисляет процент использования процессора, показанный в объекте процессора и PERF_100NSEC_TIMER_INV.

Теория очередей также содержит формулу: N = k ÷ (1 – U k) для оценки количества ожидающих элементов на основе использования, где N — длина очереди. Диаграмма этого уравнения по всем интервалам использования предоставляет следующие оценки того, сколько времени очередь для получения на процессоре находится в любой заданной нагрузке ЦП.

На основе этой оценки мы можем наблюдать, что после 50% загрузки ЦП среднее ожидание обычно включает один другой элемент в очереди и быстро увеличивается до 70 % использования ЦП.

Чтобы понять, как теория очередей применяется к развертыванию AD DS, давайте вернемся к метафоре шоссе, которую мы использовали в скорости ЦП и в нескольких ядрах.

Автобусные времена в середине дня упали бы где-то на 40% до 70% диапазона емкости. Есть достаточно трафика, что ваша способность выбирать полосу для езды не сильно ограничена. Хотя шанс другого водителя попасть на ваш путь высокий, он не требует того же уровня усилий, что вам потребуется найти безопасный разрыв между другими автомобилями в полосе, как во время пик-часа.

По мере приближения часа пиков система дорог приближается к 100% емкости. Смена полос во время пик-часа становится очень сложной, потому что автомобили настолько близки вместе, что у вас нет столько места для маневра при изменении полос. Поведение очереди объясняет целевой показатель долгосрочной средней емкости в 40%. Сохранение среднего использования около 40% оставляет место для коротких пиков (например, медленных или плохо закодированных запросов) и более крупных событий всплеска (таких как всплеск утром после отпуска).

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

• Преобразование PERF_100NSEC_TIMER_INV
  • B = количество интервалов 100-ns, которые расходуется потоком простоя на логический процессор. Изменение переменной X в вычислении PERF_100NSEC_TIMER_INV
  • T = общее число интервалов 100-ns в заданном диапазоне времени. Изменение переменной Y в вычислении PERF_100NSEC_TIMER_INV .
  • U k = процент использования логического процессора потоком простоя или % время простоя.
• Разработка математики:
  • U k = 1 – время %Processor
  • время %Processor = 1 – U k
  • время %Processor = 1 – B / T
  • время %Processor = 1 – X1 – X0 / Y1 – Y0

Применение этих концепций к планированию емкости

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

• Эффективность кэша
• Требования к согласованности памяти
• Планирование потоков и синхронизация
• Несовершенные нагрузки клиента

Так как вычислительная мощность относительно низкая стоимость, это не стоит инвестировать слишком много времени в вычислении идеально точного количества ЦП, необходимых вам.

Также важно помнить, что рекомендация 40% в данном случае не является обязательным требованием. Мы используем его в качестве разумного начала для вычисления. Для различных типов пользователей AD требуются различные уровни реагирования. Некоторые среды могут иметь среднюю загрузку ЦП 80%–90% и все еще соответствовать ожиданиям пользователей, если время ожидания в очереди не увеличивается заметно. Рассматривайте это как исключение, проверяйте с помощью данных о задержке и внимательно отслеживайте на предмет возникающих конфликтов.

Другие части системы медленнее ЦП. Настройте их тоже. Сосредоточьтесь на доступе к ОЗУ, доступе к диску и времени отклика сети. Рассмотрим пример.

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

• Устранение проблем, связанных с диском, может означать, что потоки, ранее застрявшие в состоянии ожидания, застряли, создавая больше конкуренции на время ЦП. В результате загрузка с 90% увеличивается до 100%. Для возврата использования на управляемые уровни необходимо настроить оба компонента.

  Note

  Счетчик Processor Information(*)\% Processor Utility может превышать 100 % с системами с режимом Turbo. Режим turbo позволяет ЦП превышать скорость процессора с оценкой в течение коротких периодов. Если вам нужна дополнительная информация, ознакомьтесь с документацией производителей ЦП и описаниями счетчиков.

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

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

Теперь рассмотрим четыре сценария:

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

На основе предыдущих примеров можно увидеть, что существует множество сценариев от 0% до 100% использования, которые имеют различные степени влияния на производительность. Кроме того, добавление дополнительных логических процессоров не обязательно повышает производительность за пределами конкретных сценариев. Это должно быть довольно просто, чтобы применить эти принципы к рекомендуемой цели использования ЦП на 40 % для узлов и гостей.

Приложение B. Рекомендации по различным скоростям процессора

В обработке предполагается, что процессор работает на скорости 100% часов при сборе данных и что все системы замены имеют ту же скорость обработки. Несмотря на то, что эти предположения не являются точными, особенно для Windows Server 2008 R2 и более поздних версий, где план питания по умолчанию сбалансирован, эти предположения по-прежнему работают для консервативных оценок. В то время как возможные ошибки могут увеличиться, это только увеличивает предел безопасности по мере увеличения скорости процессора.

• Например, в сценарии, требующего 11,25 ЦП, если процессоры работали на половину скорости при сборе данных, то более точную оценку их спроса будет составлять 5,125 ÷ 2.
• Невозможно гарантировать, что удвоение скорости часов увеличивает объем обработки, которая происходит в течение записанного периода времени. Время, затраченное процессорами на ожидание ОЗУ или других компонентов, остается примерно таким же. Таким образом, более быстрые процессоры могут тратить больший процент времени простоя во время ожидания получения данных системой. Мы рекомендуем придерживаться наименьшего общего знаменателя, держать оценки консервативными и избегать линейного сравнения скоростей процессора, которые могут сделать ваши результаты неточными.

Если скорость процессора в заменяемом оборудовании ниже текущего оборудования, следует пропорционально увеличить оценку количества необходимых процессоров. Например, рассмотрим сценарий, в котором вы вычисляете 10 процессоров для поддержания нагрузки сайта. Текущие процессоры выполняются в 3,3 ГГц, а процессоры, которые планируется заменить на 2,6 ГГц. Замена только 10 исходных процессоров даст вам 21% снижение скорости. Чтобы увеличить скорость, необходимо получить по крайней мере 12 процессоров вместо 10.

Однако эта переменная не изменяет целевые показатели использования процессора управления емкостью. Скорость процессора настраивается динамически на основе спроса на нагрузку, поэтому выполнение системы под более высокими нагрузками приводит к тому, что ЦП тратит больше времени в более высоком состоянии скорости часов. Конечная цель заключается в том, чтобы ЦП был на уровне 40 % использования в состоянии скорости 100 % в течение пиковых рабочих часов. Любое значение ниже этого создает экономию энергии путем снижения скорости процессора во время фаз низкой нагрузки.

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

1. Перейдите на веб-сайт Standard Performance Evaluation Corporation (SPEC).

2. Выберите Результаты.

3. Введите CPU2006 и выберите "Поиск".

4. В раскрывающемся меню для доступных конфигураций выберите все CPU2006 SPEC.

5. В поле "Запрос формы поиска" выберите "Простой", а затем нажмите кнопку Go!.

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

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

8. Запишите значения в столбцах Result и #Cores .

9. Определите модификатор с помощью следующего уравнения:

   ((Значение оценки целевой платформы на ядро) × (МГц на ядро базовой платформы)) ÷ ((базовое значение оценки на ядро) × (МГц на ядро целевой платформы))

   Например, вот как можно найти модификатор для процессора E5-2630:

   (35.83 × 2000) ÷ (33,75 × 2300) = 0,92

10. Умножьте количество процессоров, которые вы оцениваете, на этот модификатор.

    Для примера процессора E5-2630 0.92 × 10.3 = 10,35 процессоров.

Приложение C. Взаимодействие операционной системы с хранилищем

Концепции очереди, которые мы обсуждали во время отклика и как уровни действий системы влияют на производительность также применяются к хранилищу. Чтобы эффективно применять эти понятия, необходимо ознакомиться с тем, как операционная система обрабатывает операции ввода-вывода. В операционных системах Windows система создает очередь, в которой хранятся запросы ввода-вывода для каждого физического диска. Однако физический диск не обязательно является одним диском. ОС также может зарегистрировать агрегирование спинделей на контроллере массива или SAN в качестве физического диска. Контроллеры массива и saN также могут объединять несколько дисков в один набор массивов, разделяя их на несколько секций, а затем использовать каждую секцию в качестве физического диска, как показано на следующем рисунке.

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

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

• Спиндл — это устройство, физическое установленное на сервере.
• Массив представляет собой коллекцию спинделей, агрегированных контроллером.
• Секционирование массива — это секционирование агрегированного массива.
• Логический номер единицы (LUN) — это массив устройств SCSI, подключенных к компьютеру. В этой статье используются эти термины при разговоре о SAN.
• Диск включает в себя любой спинд или секцию, регистрируемую ОС в качестве одного физического диска.
• Секция — это логическая секционирование того, что ОС регистрирует как физический диск.

Рекомендации по архитектуре операционной системы

ОС создает очередь ввода-вывода первого входа (FIFO) для каждого диска, который он регистрирует. Эти диски могут быть спинделями, массивами или секциями массивов. Когда дело доходит до того, как ОС обрабатывает операции ввода-вывода, чем больше активных очередей, тем лучше. Когда ОС сериализует очередь FIFO, она должна обрабатывать все запросы FIFO ввода-вывода, выданные подсистеме хранения в порядке прибытия. Сохраняя отдельную очередь ввода-вывода для каждого шпинделя или массива, ОС предотвращает конкуренцию дисков за те же ограниченные ресурсы ввода-вывода и сохраняет активность изолированной только для затронутых дисков. Однако Windows Server 2008 представила исключение в виде приоритета ввода-вывода. Приложения, предназначенные для использования низкоприоритетных операций ввода-вывода, перемещаются в спину очереди независимо от того, когда ОС получила их. Приложения, не запрограммированные на использование настройки низкого приоритета, используют приоритет по умолчанию.

Знакомство с простыми подсистемами хранения

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

• Один 10 000 RPM Ultra Fast SCSI HD (Ультра Fast SCSI имеет скорость передачи 20 МБИТ/с)
• Одна шина SCSI (кабель)
• Один адаптер fast SCSI
• Одна 32-разрядная шина PCI 33 МГц

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

Далее давайте рассмотрим эти элементы на основе компонента.

Время доступа к жесткому диску

Средний жесткий диск на скорости 10 000 RPM имеет время поиска 7 мс и время доступа 3 мс. Время поиска — это среднее время, которое занимает время чтения или записи, чтобы переместиться в расположение на тарелке. Время доступа — это среднее время, необходимое для чтения или записи данных на диск после того, как он находится в правильном расположении. Поэтому среднее время чтения уникального блока данных в 10 000-RPM HD включает время поиска и доступа в общей сложности около 10 мс или 0,010 секунд на блок данных.

При каждом доступе к диску требуется перемещение головы в новое расположение на диске, поведение чтения или записи вызывается случайным образом. Если все операции ввода-вывода являются случайными, 10 000-RPM HD может обрабатывать примерно 100 операций ввода-вывода в секунду (операций ввода-вывода в секунду).

Когда все операции ввода-вывода происходят из смежных секторов на жестком диске, мы называем его последовательным вводом-выводом. Последовательный ввод-вывод не добавляет дополнительного времени поиска. После завершения первого ввода-вывода головка чтения и записи уже находится в следующем блоке данных. Например, 10 000-RPM HD может обрабатывать примерно 333 операций ввода-вывода в секунду на основе следующего уравнения:

1000 мс в секунду / 3 мс на каждую операцию ввода-вывода

До сих пор скорость передачи жесткого диска не относится к нашему примеру. Независимо от размера жесткого диска фактический объем операций ввода-вывода в секунду, который может обрабатывать 10 000 RPM HD, всегда составляет около 100 случайных или 300 последовательных операций ввода-вывода. Так как размеры блоков изменяются в зависимости от того, какое приложение записывает на диск, объем данных, извлекаемых на ввод-вывод, также изменяется. Например, если размер блока составляет 8 КБ, 100 операций ввода-вывода считываются или записываются на жесткий диск в общей сложности 800 КБ. Однако если размер блока равен 32 КБ, 100 операций ввода-вывода считывают или записывают 3200 КБ (3,2 МБ) на жесткий диск. Если скорость передачи SCSI превышает общий объем передаваемых данных, то скорость передачи быстрее не меняется. Дополнительные сведения см. в следующих таблицах:

Серверная планка SCSI

Как серверная планка SCSI, которая в этом примере является кабелем ленты, влияет на пропускную способность подсистемы хранения зависит от размера блока. Сколько операций ввода-вывода может обрабатывать шина, если ввод-вывод находится в блоках 8 КБ? В этом сценарии шина SCSI составляет 20 МБИТ/с или 20480 КБ/с. 20480 КБ/с при делении на блоки размером 8 КБ дает максимум примерно 2500 IOPS, поддерживаемых шиной SCSI.

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

Адаптер SCSI

Чтобы определить, сколько операций ввода-вывода система может обрабатывать, необходимо проверить спецификации производителя. Для перенаправления запросов ввода-вывода на соответствующее устройство требуется мощность обработки, поэтому объем операций ввода-вывода в системе зависит от адаптера SCSI или процессора контроллера массива.

В этом примере предполагается, что система может обрабатывать 1000 операций ввода-вывода.

Шина PCI

Шина PCI — это неучтаемый компонент. В этом примере шина PCI не является узким местом. Однако по мере увеличения масштаба систем она может стать узким местом в будущем.

Мы видим, сколько шина PCI может передавать данные в нашем примере с помощью следующего уравнения:

32 бита ÷ 8 бит на байт × 33 МГц = 133 МБ/с

Поэтому можно предположить, что 32-разрядная шина PCI, работающая в 33 МГц, может передавать данные 133 МБ/с.

66MHz 64-разрядная шина PCI может поддерживать теоретический максимум 528 МБИТ/с на основе этого уравнения:

64 бита ÷ 8 бит на байт × 66Mhz = 528MBps

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

Анализ подсистем хранения для поиска узких мест

В этом сценарии спиндел является фактором ограничения количества операций ввода-вывода, которые можно запросить. В результате это узкое место также ограничивает объем данных, которые система может передавать. Поскольку наш пример связан со сценарием AD DS, объем передаваемых данных составляет 100 случайных операций ввода-вывода в секунду при увеличении на 8 КБ, что в сумме дает 800 КБ в секунду при доступе к базе данных Jet. По сравнению со спинделем, выделенным только для файлов журналов, такой спиндель может обеспечивать до 300 последовательных операций ввода-вывода по 8 КБ каждую в секунду. Это равно 2400 КБ (2,4 МБ) в секунду.

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

Знакомство с RAID

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

В RAID 0 запись данных распределяет их по всем дискам в наборе RAID. Во время операции чтения или записи система извлекает данные из каждого диска или отправляет их на каждый диск, увеличив объем данных, которые система может передавать в течение этого определенного периода времени. Поэтому в этом примере, где мы используем диски с частотой вращения 10,000 об/мин, использование RAID 0 позволит выполнить 100 операций ввода-вывода. Общее количество операций ввода-вывода, которое поддерживает система, составляет N spindles раз 100 1/O в секунду в спинделе, или N спиндели × 100 операций ввода-вывода в секунду в секунду на спиндел.

В RAID 1 система зеркально или дублирует данные в паре спинделей для избыточности. Когда система выполняет операцию чтения операций ввода-вывода, она может считывать данные из обоих спинделей в наборе. Это зеркальное отображение делает емкость ввода-вывода для обоих дисков доступными во время операции чтения. Однако RAID 1 не дает никаких преимуществ производительности операций записи, так как система также должна зеркально отображать записанные данные в паре спинделей. Хотя зеркальное отображение не делает операции записи занимает больше времени, система не может одновременно выполнять несколько операций чтения. Поэтому каждая операция ввода-вывода записи стоит две операции чтения операций ввода-вывода.

Следующее уравнение вычисляет количество операций ввода-вывода в этом сценарии:

Чтение операций ввода-вывода + 2 ×записи доступных дисковых операций ввода-вывода =

Если вы знаете соотношение операций чтения с записью и числом спинделей в развертывании, вы можете использовать это уравнение для вычисления количества операций ввода-вывода, которые может поддерживать ваш массив:

Максимальное количество операций ввода-вывода в секунду для каждого спинделя × 2 спинделей × [(% операций + чтения% операций записи) ÷ (% операций чтения + 2 × % операций записи)] = общее количество операций ввода-вывода в секунду

Сценарий, использующий RAID 1 и RAID 0, ведет себя точно так же, как RAID 1 в затратах на чтение и запись операций. Однако операции ввода-вывода теперь чередуются между каждым зеркальным набором. Это означает, что уравнение изменяется на:

Максимальное количество операций ввода-вывода в секунду на спинделя × 2 спинделя × [(% операций + чтения% операций записи) ÷ (% операций чтения + 2 × % записи)] = общее число операций ввода-вывода

В наборе RAID 1 при полосе N числа наборов RAID 1 общий объем операций ввода-вывода, который может обрабатываться, становится N × ввода-вывода для каждого набора RAID 1:

N × {Максимальное число операций ввода-вывода в секунду на спиндели × 2 спинделя × [(% операции чтения + % записи) ÷ (% чтения + 2 ×% записи)]} = общее число операций ввода-вывода в секунду

Иногда мы вызываем RAID 5 N + 1 RAID, так как система чередует данные по n spindles и записывает сведения о четности в спиндел + 1. Однако RAID 5 использует больше ресурсов при выполнении операций ввода-вывода записи, чем RAID 1 или RAID 1 + 0. RAID 5 выполняет следующий процесс каждый раз, когда операционная система отправляет ввод-вывод записи в массив:

1. Чтение старых данных.
2. Прочтите старое четность.
3. Запись новых данных.
4. Напишите новый четность.

Каждый запрос ввода-вывода записи, отправляемый ОС контроллеру массива, требует завершения четырех операций ввода-вывода. Таким образом, запросы на запись RAID N + 1 занимают четыре раза до завершения операций ввода-вывода. Иными словами, чтобы определить, сколько запросов ввода-вывода из ОС преобразуется в количество запросов, которые получают спиндели, используйте это уравнение:

Чтение операцийввода-вывода+ 4 × записи операций =

Для RAID 1, как только вы знаете соотношение операций чтения и записи и количество спинделей, можно использовать следующее уравнение для оценки общего поддерживаемого ввода-вывода для массива:

Операций ввода-вывода в секунду на × (Spindles – 1) × [(% операций + чтения% операций записи) ÷ (% операций чтения + 4 × % записи)] = общее количество операций ввода-вывода в секунду

Общие сведения о SAN

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

Теперь давайте разберем SAN на его компоненты:

• Жесткий диск SCSI или Fibre Channel
• Обратная планка канала единиц хранения
• Сами единицы хранения
• Модуль контроллера хранилища
• Один или несколько коммутаторов SAN
• Один или несколько адаптеров шины узла (HBA)
• Шина взаимодействия периферийных компонентов (PCI)

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

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

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

При анализе канала в единице хранения следует использовать тот же подход, когда вы вычисляете количество ресурсов, доступных на шине SCSI: разделите пропускную способность по размеру блока. Например, если единица хранения имеет шесть каналов, которые поддерживают максимальную скорость передачи 20 МБИТ/с, общий объем доступных операций ввода-вывода и передачи данных составляет 100 МБИТ/с. Шесть каналов на 20MBps каждый дает теоретические 120MBps. Мы ограничиваем запланированную пропускную способность на уровне 100 МБ/с (дизайн N+1). Если один канал завершается ошибкой, оставшиеся пять (5 × 20MBps) по-прежнему доставляют необходимые 100 МБИТ/с. В этом примере также предполагается, что система равномерно распределяет нагрузку и отказоустойчивость по всем каналам.

Можно ли преобразовать предыдущий пример в профиль ввода-вывода в зависимости от поведения приложения. Для механизма Jet ввода-вывода в Active Directory максимальное значение составляет около 12,500 операций ввода-вывода в секунду или, эквивалентно, 100 МБ/с ÷ 8 КБ на каждую операцию ввода-вывода.

Чтобы понять, сколько пропускной способности поддерживает модули контроллера, также необходимо получить их спецификации производителя. В этом примере san имеет два модуля контроллера, поддерживающие 7500 операций ввода-вывода. Если вы не используете избыточность, общая пропускная способность системы составит 15 000 операций ввода-вывода в секунду. Однако в сценарии, где требуется избыточность, вы вычисляете максимальную пропускную способность на основе ограничений только одного из контроллеров, что составляет 7500 операций ввода-вывода в секунду. Если размер блока составляет 4 КБ, это пороговое значение значительно ниже максимальной пропускной способности 12500 IOPS, которую могут поддерживать каналы хранения, и поэтому является узким местом в вашем анализе. Однако в целях планирования необходимо планировать максимальное число операций ввода-вывода в 10 400 операций ввода-вывода.

Когда данные покидают модуль контроллера, они передаются по соединению Fibre Channel с пропускной способностью 1 Гбит/с, или 128 Мбайт/с. Поскольку эта сумма превышает общую ширину полосы пропускания 100 МБИТ/с для всех каналов хранения, система не будет испытывать узких мест. Только один из двух каналов Fibre Channel передает трафик во время нормальной работы; другой канал зарезервирован для резервирования. Если активный путь завершается ошибкой, резервный путь перехватывает управление. Достаточно емкости для обработки полной нагрузки данных.

Затем данные передают переключатель SAN на свой путь к серверу. Переключатель ограничивает объем операций ввода-вывода, который может обрабатываться, так как он должен обработать входящий запрос, а затем перенаправить его на соответствующий порт. Однако вы можете только знать, какой предел переключения имеется, если вы посмотрите на спецификации производителя. Например, если в системе есть два коммутатора, и каждый коммутатор может обрабатывать 10 000 операций ввода-вывода в секунду, общая пропускная способность составляет 20 000 операций ввода-вывода в секунду. В зависимости от правил отказоустойчивости, если один коммутатор перестает работать, общая пропускная способность системы составляет 10 000 операций ввода-вывода в секунду. Поэтому в обычных условиях не следует использовать более 80 % использования или 8000 операций ввода-вывода.

Наконец, HBA, устанавливаемая на сервере, также ограничивает количество операций ввода-вывода, которые он может обрабатывать. Установите дополнительные адаптеры шины хоста (HBA) для обеспечения отказоустойчивости. При вычислении емкости исключите избыточный HBA. Планируйте так, как если бы один HBA не работает (N - 1), и рассчитайте общий объем доступных операций ввода-вывода для одного или нескольких оставшихся активных HBA.

Рекомендации по кэшированию

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

• Кэширование улучшает устойчивый последовательный ввод-вывод, так как он буферизирует множество небольших операций записи в большие блоки ввода-вывода. Он также упорядочивает операции для хранения в нескольких больших блоках вместо многих мелких. Эта оптимизация уменьшает общий объем операций случайного и последовательного ввода-вывода, что делает больше ресурсов доступными для других операций ввода-вывода.
• Кэширование не улучшает устойчивую пропускную способность ввода-вывода записи в подсистеме хранения, так как только буферы записываются, пока не будут доступны спиндели для фиксации данных. Когда все доступные ввода-вывода из спинделей перегружены данными в течение длительного периода времени, кэш в конечном итоге заполняется. Чтобы очистить кэш, необходимо предоставить достаточно операций ввода-вывода для очистки кэша, предоставляя дополнительные спиндели или предоставляя достаточно времени между всплесками для системы.
• Большие кэши позволяют буферировать больше данных, что означает, что кэш может обрабатывать более длительные периоды насыщенности.
• В типичных подсистемах хранения ОПЕРАЦИОННая система улучшает производительность записи с кэшами, так как система должна записывать данные только в кэш. Однако после того, как базовый носитель перегружен операциями ввода-вывода, кэш заполняет и записывает производительность до обычной скорости диска.
• При кэшировании операций ввода-вывода кэш наиболее полезен при хранении данных последовательно на столе и позволяет кэшу считываться заранее. Считывание вперед, когда кэш может немедленно перейти к следующему сектору, как если следующий сектор содержит данные, которые система будет запрашивать далее.
• При чтении операций ввода-вывода происходит случайно, кэширование на контроллере диска не увеличивает объем данных, которые диск может считывать. Если размер кэша на основе ОС или приложения больше размера аппаратного кэша, то любые попытки повысить скорость чтения диска не изменяют ничего.
• В Active Directory кэш ограничен только объемом ОЗУ, который хранится в системе.

Рекомендации по SSD

Твердотельные накопители (SSD) принципиально отличаются от жестких дисков на основе спинделя. Диски SSD могут обрабатывать более высокие объемы операций ввода-вывода с меньшей задержкой. Хотя диски SSD могут быть дорогими на основе затрат на Гигабайт, они дешевы на основе затрат на операции ввода-вывода. Планирование емкости с SSD по-прежнему задает те же основные вопросы, что и с спинделями: сколько операций ввода-вывода в секунду они могут обрабатывать, и что такое задержка этих операций ввода-вывода в секунду?

Ниже приведены некоторые аспекты, которые следует учитывать при планировании SSD:

• Оба операций ввода-вывода в секунду и задержки относятся к конструкциям производителя. В некоторых случаях некоторые конструкции SSD могут работать хуже, чем технологии на основе спинделя. Проверьте спецификации поставщика для каждой модели SSD или шпинделя; производительность и задержка зависят от структуры. Не рассматривайте все твердотельные накопители (SSD) или все жесткие диски со шпинделями как равные. Сравните IOPS, задержку, надежность, параметры глубины очереди и функции встроенного ПО для каждой модели.
• Типы операций ввода-вывода в секунду могут иметь разные значения в зависимости от того, считываются ли они или записываются. Службы AD DS преимущественно основаны на чтении и, следовательно, меньше влияют на технологию записи, которую вы используете по сравнению с другими сценариями приложений.
• Напишите выносливость является предположение, что клетки SSD имеют ограниченный срок жизни и в конечном итоге будут носить после их использования много. Для дисков базы данных профиль ввода-вывода преимущественно считывает выносливость ячеек до точки, когда вам не нужно беспокоиться о выносливости записи так много.

Summary

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

• Несколько серверов с использованием одного и того же SAN LUN
• Несколько виртуальных машин, виртуальные диски которых находятся на одном томе NAS
• Узлы, обращающиеся к общим целевым объектам iSCSI через общую структуру

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

Рекомендуемый рабочий процесс исправления:

1. Измерение: сбор LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read, Avg Disk sec/Write, Reads/sec, Writes/sec, и статистики массива хранилища (глубина очереди, использование контроллера) с интервалами в 15–60 минут, охватывающими пиковые и временные окна техобслуживания.

2. Атрибут. Определение того, какая рабочая нагрузка вызывает пики задержки (коррелирует с окнами резервного копирования, антивирусной проверкой, пакетными заданиями или действием соседа виртуальной машины). Используйте метрики для каждой LUN / виртуальной машины, где они доступны.

3. Классифицируйте тип проблемы:

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

4. Действовать:

   • Перебалансируйте или изолируйте ресурсоемкие задачи на отдельные LUN, тома или уровни хранилища.
   • Резервное копирование или перепланировка резервных копий, полная антивирусная проверка и дефрагментация за пределами пиковых периодов проверки подлинности и запросов AD DS.
   • Добавляйте или модернизируйте компоненты хранилища, когда уровень использования остается постоянно высоким.
   • Убедитесь, что драйверы и встроенное ПО и многопатовое программное обеспечение настроены правильно.
   • Оптимизируйте объём ОЗУ, чтобы часто запрашиваемые данные находились в памяти, уменьшая нагрузку на чтение с хранилища.

5. Проверка. Убедитесь, что задержка после изменения возвращается к намеченной цели (например, 2–6 мс для SSD/NVMe, 4–12 мс для жестких дисков) и что максимальная глубина очереди остается в допустимых пределах.

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

Проверьте и исключите их перед добавлением дополнительных дисков или переходом на более быстрый носитель.

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

Ключевые критерии успеха:

• Устойчивая Avg Disk sec/Read и Avg Disk sec/Write в пределах целевой задержки во время пиковой нагрузки AD DS.
• Нет длительных периодов, когда IOPS выходит на плато, и задержка увеличивается. Если это будет наблюдаться, это может указывать на достижение насыщения.
• Тяжелые задачи обслуживания выполняются во время определенных окон обслуживания, не увеличивая задержку производительности выше пороговых значений.

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

Приложение D. Устранение неполадок с хранилищем в средах, где больше ОЗУ не является вариантом

Многие рекомендации по хранилищу перед виртуализированным хранилищем служили двумя целями:

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

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

При планировании емкости для производительности хранилища следует учитывать следующее:

• Состояние холодного кэша
• Состояние теплого кэша
• Резервное копирование и восстановление

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

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

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

• Разогрев кэша после перезагрузки
• Операции резервного копирования
• Восстановление операций

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

В большинстве случаев AD DS преимущественно считывает операции ввода-вывода с соотношением 90 % считывания до 10 % записи. Чтение ввода-вывода является типичным узким местом для взаимодействия с пользователем, а запись ввода-вывода — это узкое место, которое снижает производительность записи. Кэши, как правило, обеспечивают минимальное преимущество для чтения операций ввода-вывода, так как операции ввода-вывода для NTDS.dit файла являются преимущественно случайными. Поэтому основной приоритет заключается в том, чтобы убедиться, что вы правильно настраиваете хранилище профилей ввода-вывода для чтения.

В обычных условиях эксплуатации цель планирования хранилища — свести к минимуму время ожидания, чтобы система возвращала запросы из AD DS на диск. Количество невыполненных операций ввода-вывода и ожидающих операций ввода-вывода должно быть меньше или равно количеству путей на диске. В сценариях мониторинга производительности обычно рекомендуется, чтобы LogicalDisk((<NTDS Database Drive>))\Avg Disk sec/Read счетчик был меньше 20 мс. Задайте пороговое значение операционной системы, близкое к задержке в собственном хранилище. Цель — 2–6 мс: выбирайте нижний предел для более быстрого носителя (NVMe/SSD) и верхний предел для более медленных классов.

На следующем графике показано измерение задержки диска в системе хранения.

Давайте рассмотрим этот график строк:

• Область слева от диаграммы, обведенная зеленым цветом, показывает, что задержка согласована в 10 мс по мере увеличения нагрузки с 800 операций ввода-вывода в секунду до 2400 операций ввода-вывода в секунду. Эта базовая задержка зависит от используемого решения хранилища.
• Область справа от диаграммы, окружаемой в maroon, показывает системную пропускную способность между базовым и окончанием сбора данных. Сама пропускная способность не изменяется, но задержка увеличивается. В этой области показано, что происходит, когда объем запросов превышает физический предел системы хранения. Запросы остаются в очереди дольше, прежде чем диск начинает их обслуживать.

Теперь давайте подумаем о том, что эти данные говорят нам.

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

• Размер каждой страницы базы данных Active Directory составляет 8 КБ.
• Минимальное количество страниц, необходимых системе для чтения, равно 128.
• Таким образом, в базовой области на схеме система должна занять не менее 1,28 секунд, чтобы загрузить данные с диска и вернуть его клиенту. На отметке 20 мс пропускная способность значительно превышает рекомендуемую максимальную, процесс занимает 2,5 секунды.

На основе этих чисел можно вычислить, как быстро кэш нагревается с помощью следующего уравнения:

2400 операций ввода-вывода в секунду × 8 КБ на операцию ввода-вывода

После выполнения этого вычисления можно сказать, что скорость теплого кэша в этом сценарии составляет 20 МБИТ/с. Другими словами, система загружает около 1 ГБ базы данных в ОЗУ каждые 53 секунды.

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