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

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

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

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

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

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

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

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

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

• 64-разрядные серверные платформы
• Виртуализация
• Повышенное внимание к потреблению электроэнергии
• Хранилище SSD
• Облачные сценарии

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

Базовые требования к планированию емкости

В этой статье ожидаются следующие базовые требования:

• Читатели прочитали и знакомы с рекомендациями по настройке производительности для Windows Server 2012 R2.
• Платформа Windows Server — это архитектура на основе x64. Но даже если среда Active Directory установлена в Windows Server 2003 x86 (теперь за пределами жизненного цикла поддержки) и содержит дерево сведений о каталоге (DIT), которое меньше 1,5 ГБ в памяти и может быть легко храниться в памяти, рекомендации из этой статьи по-прежнему применимы.
• Планирование емкости — это непрерывный процесс, и следует регулярно проверять, насколько хорошо среда соответствует ожиданиям.
• Оптимизация будет выполняться в течение нескольких жизненных циклов оборудования в результате изменения затрат на оборудование. Например, память становится дешевле, стоимость на ядро уменьшается или цена различных вариантов хранения изменяется.
• Планирование пикового занятого периода дня. Рекомендуется посмотреть на это в течение 30 минут или часов. Все большее может скрыть фактические пики и что-нибудь меньшее может быть искажено "временными пиками".
• Планирование роста на протяжении жизненного цикла оборудования для предприятия. Это может включать стратегию обновления или добавления оборудования в ошеломленном виде или полное обновление каждые три-пять лет. Для каждого из них потребуется "угадать", сколько будет увеличиваться нагрузка на Active Directory. Исторические данные, если они собираются, помогут с этой оценкой.
• Планирование отказоустойчивости. После получения оценки N план для сценариев, включающих N – 1, N – 2, N – x.

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

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

    Примечание.

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

Трехэтапный процесс для цикла планирования емкости

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

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

• "Прямое сопоставление" с одним гостевым на узел (где виртуализация существует исключительно для абстрагирования физического оборудования с сервера)
• "Общий узел"

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

Учитывая эти рекомендации, цикл планирования емкости является итеративным трехэтапным процессом:

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

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

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

1. Память
2. Network
3. Хранилище
4. Процессор
5. Вход в сеть

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

а именно:

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

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

Создать среду

Компонент	Оценки
служба хранилища/Размер базы данных	40 КБ до 60 КБ для каждого пользователя
ОЗУ	Размер базы данных Рекомендации по базовой операционной системе Приложения третьих лиц
Network	1 ГБ
ЦП	1000 одновременных пользователей для каждого ядра

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

Компонент	Критерии оценки	Общие вопросы планирования
служба хранилища/Размер базы данных	Раздел "Активация ведения журнала дискового пространства, освобожденного дефрагментацией", в разделе "Ограничения служба хранилища"
служба хранилища/ производительность базы данных	"ЛогическийDisk(диск базы данных NTDS)\Avg Disk> sec/read", "ЛогическийDisk(<диск> базы данных NTDS)\Avg Disk sec/Write", "ЛогическийDisk(<<диск базы данных NTDS)\Avg Disk> sec/Transfer" "ЛогическийDisk(диск> базы данных NTDS)\Reads/sec", "ЛогическийDisk(<<диск> базы данных NTDS)\Writes/sec", "ЛогическийDisk(<диск> базы данных NTDS)\Transfer/sec"	служба хранилища имеет две проблемы, связанные с решением Доступное пространство, которое с размером сегодняшнего шпинделя на основе и ssd хранилища не имеет значения для большинства сред AD. Доступные операции ввода-вывода ( ввода-вывода) — во многих средах это часто не учитывается. Но важно оценить только среды, в которых недостаточно ОЗУ для загрузки всей базы данных NTDS в память. служба хранилища может быть сложной темой и должен включать опыт поставщика оборудования для правильного определения размера. Особенно с более сложными сценариями, такими как SAN, NAS и iSCSI. Однако, как правило, стоимость на Гигабайт хранилища часто находится в прямой оппозиции к затратам на операции ввода-вывода: RAID 5 имеет более низкую стоимость за Гигабайт, чем Raid 1, но Raid 1 имеет более низкую стоимость за операции ввода-вывода Жесткие диски на основе spindle имеют более низкую стоимость на Гигабайт, но SSD имеют более низкую стоимость на операции ввода-вывода После перезапуска компьютера или службы служб домен Active Directory кэш расширяемый служба хранилища engine (ESE) пуст, а производительность будет привязана к диску, пока кэш нагревается. В большинстве сред AD считывает интенсивный ввод-вывод в случайном шаблоне на диски, отрицая большую часть преимущества кэширования и оптимизации чтения. Кроме того, AD имеет более большой кэш в памяти, чем большинство кэшей системы хранения.
ОЗУ	Размер базы данных Рекомендации по базовой операционной системе Приложения третьих лиц	служба хранилища является самым медленным компонентом на компьютере. Чем больше может быть резидент в ОЗУ, тем меньше необходимо перейти на диск. Убедитесь, что достаточно ОЗУ выделяется для хранения операционной системы, агентов (антивирусной программы, резервного копирования, мониторинга), базы данных NTDS и роста с течением времени. В средах, где максимальное количество ОЗУ не является экономичным (например, вспомогательными расположениями) или неосуществим (DIT слишком велик), обратитесь к разделу служба хранилища, чтобы обеспечить правильность размера хранилища.
Network	"Сетевой интерфейс(*)\Байт получено/с" "Сетевой интерфейс(*)\Байт sent/sec"	Как правило, трафик, отправленный из контроллера домена, гораздо превышает трафик, отправленный в контроллер домена. Так как переключение подключения Ethernet является полно дуплексным, входящий и исходящий сетевой трафик должны быть независимо от размера. Консолидация числа контроллеров домена увеличит объем пропускной способности, используемой для отправки ответов обратно в клиентские запросы для каждого контроллера домена, но будет достаточно близко к линейной для сайта в целом. При удалении сетевых контроллеров домена не забудьте добавить пропускную способность для спутникового контроллера домена в центральные контроллеры домена, а также использовать их для оценки объема трафика глобальной сети.
ЦП	"Логический диск (<диск базы данных NTDS)\Avg Disk> sec/Read" "Process(lsass)\% Processor Time"	После устранения нехватки хранилища в качестве узкого места устраните необходимый объем вычислительной мощности. Хотя не совсем линейно, количество ядер процессора, потребляемых на всех серверах в определенных область (таких как сайт), можно использовать для оценки количества процессоров, необходимых для поддержки общей нагрузки клиента. Добавьте минимальный необходимый для поддержания текущего уровня обслуживания во всех системах в область. Изменения скорости процессора, включая связанные с питанием изменения, числа последствий, производные от текущей среды. Как правило, невозможно точно оценить, как происходит от процессора 2,5 ГГц до 3 ГГц, что приведет к сокращению количества необходимых ЦП.
NetLogon	"Netlogon()\Semaphore Acquires" "Netlogon()\Semaphore Timeouts" "Netlogon(*)\Среднее время удержания Семафора"	Net Logon Secure Channel/MaxConcurrentAPI влияет только на среды с проверкой подлинности NTLM и (или) проверкой PAC. Проверка PAC включена по умолчанию в версиях операционной системы до Windows Server 2008. Это параметр клиента, поэтому контроллеры домена будут затронуты до тех пор, пока они не будут отключены во всех клиентских системах. Среды с значительной проверкой подлинности между доверием, включая доверие внутри леса, имеют больший риск, если он не имеет правильного размера. Консолидация серверов повышает параллелизм проверки подлинности между доверием. Всплески необходимо учитывать, например отработку отказа кластера, так как пользователи повторно проходят проверку подлинности в новом узле кластера. Для отдельных клиентских систем (например, кластера) может потребоваться также настройка.

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

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

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

ОЗУ

Просто, чем больше можно кэшировать в ОЗУ, тем меньше необходимо перейти на диск. Чтобы максимально увеличить масштабируемость сервера, минимальное количество ОЗУ должно быть суммой текущего размера базы данных, общим размером SYSVOL, рекомендуемой операционной системой и рекомендациями поставщика для агентов (антивирусная программа, мониторинг, резервное копирование и т. д.). Для размещения роста на протяжении всего времени существования сервера необходимо добавить дополнительный объем. Это будет экологически субъективно на основе оценки роста базы данных на основе изменений окружающей среды.

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

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

Оценка

Объем ОЗУ, необходимый контроллеру домена, фактически является сложным упражнением по следующим причинам:

• Высокий потенциал для ошибки при попытке использовать существующую систему для оценки того, сколько ОЗУ требуется, так как LSASS будет обрезаться в условиях давления памяти, искусственно превысив потребность.
• Субъективный факт, что отдельный контроллер домена должен кэшировать то, что "интересно" для своих клиентов. Это означает, что данные, которые необходимо кэшировать на контроллере домена на сайте только с сервером Exchange, будут очень отличаться от данных, которые необходимо кэшировать на контроллере домена, который выполняет проверку подлинности только пользователей.
• Труд для оценки ОЗУ для каждого контроллера домена на основе регистра является запретительным и изменяется по мере изменения среды.
• Критерии, лежащие в основе рекомендации, помогут принять обоснованные решения:
• Чем больше можно кэшировать в ОЗУ, тем меньше необходимо перейти на диск.
• служба хранилища на сегодняшний день является самым медленным компонентом компьютера. Доступ к данным на основе спинделя и носителей SSD находится в порядке 1000 000x медленнее, чем доступ к данным в ОЗУ.

Таким образом, чтобы максимально увеличить масштабируемость сервера, минимальное количество ОЗУ — это сумма текущего размера базы данных, общий размер SYSVOL, рекомендуемая операционная система и рекомендации поставщика для агентов (антивирусная программа, мониторинг, резервное копирование и т. д.). Добавьте дополнительные суммы, чтобы обеспечить рост на протяжении всего времени существования сервера. Это будет экологически субъективно на основе оценки роста базы данных. Однако для вспомогательных расположений с небольшим набором конечных пользователей эти требования могут быть расслаблены, так как эти сайты не должны кэшировать столько, сколько для обслуживания большинства запросов.

В средах, где максимальное количество ОЗУ не является экономичным (например, вспомогательными расположениями) или неосуществим (DIT слишком велик), обратитесь к разделу служба хранилища, чтобы обеспечить правильность размера хранилища.

Примечание.

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

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

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

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

Компонент	Оценочная память (пример)
Рекомендуемая базовая операционная система ОЗУ (Windows Server 2008)	2 ГБ
Внутренние задачи LSASS	200 МБ
Агент мониторинга	100 МБ
Антивирусная программа	100 МБ
База данных (глобальный каталог)	8,5 ГБ
Подушка для запуска резервного копирования, администраторы могут войти в систему без влияния	1 ГБ
Итог	12 ГБ

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

Со временем можно сделать предположение, что в базу данных будут добавлены дополнительные данные, и сервер, вероятно, будет работать в течение 3–5 лет. На основе оценки роста на 33%, 16 ГБ будет разумным объемом ОЗУ, который будет помещен на физический сервер. В виртуальной машине с учетом простоты изменения параметров и ОЗУ можно добавить на виртуальную машину, начиная с 12 ГБ с планом мониторинга и обновления в будущем, является разумным.

Network

Оценка

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

Примечание.

Как правило, большинство сетевого трафика на контроллере домена исходят, так как контроллер домена отвечает на клиентские запросы. Это причина для фокуса на исходящем трафике, хотя рекомендуется оценить каждую среду для входящего трафика. Те же подходы можно использовать для решения и проверки требований к входящего сетевого трафика. Дополнительные сведения см. в статье базы знаний 929851: динамический диапазон портов по умолчанию для TCP/IP изменился в Windows Vista и в Windows Server 2008.

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

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

При оценке объема поддерживаемого трафика существует две уникальные категории планирования емкости для AD DS с точки зрения сетевого трафика. Первым является реплика трафик, который проходит между контроллерами домена и тщательно рассматривается в справочном трафике репликации Active Directory и по-прежнему относится к текущим версиям AD DS. Второй — это внутренний трафик между клиентами и сервером. Один из более простых сценариев планирования, внутрисайтового трафика преимущественно получает небольшие запросы от клиентов относительно больших объемов данных, отправляемых клиентам. 100 МБ обычно будут достаточно в средах до 5000 пользователей на сервер на сайте. Использование сетевого адаптера 1 ГБ и поддержки масштабирования на стороне приема (RSS) рекомендуется для всех пользователей, превышающих 5 000 пользователей. Чтобы проверить этот сценарий, особенно в случае сценариев консолидации серверов, просмотрите сетевой интерфейс(*)\Байт/с на всех контроллерах домена на сайте, добавьте их вместе и разделите на целевое число контроллеров домена, чтобы обеспечить достаточную емкость. Самый простой способ сделать это — использовать представление "Область с накоплением" в надежности Windows и Монитор производительности (ранее известное как Perfmon), чтобы убедиться, что все счетчики масштабируются одинаково.

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

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

Знания, полученные из данных на диаграмме (сетевой интерфейс(*)\Байт Sent/sec):

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

   Примечание.

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

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

   Примечание.

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

Выводы:

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

Короче говоря, окончательное развертывание систем должно иметь сетевой адаптер размером 1 ГБ и подключаться к сетевой инфраструктуре, которая будет поддерживать такую нагрузку. Кроме того, обратите внимание, что при наличии объема сетевого трафика загрузка ЦП из сетевых коммуникаций может оказать значительное влияние и ограничить максимальную масштабируемость AD DS. Этот же процесс можно использовать для оценки объема входящих подключений к контроллеру домена. Но учитывая преобладание исходящего трафика относительно входящего трафика, это академическое упражнение для большинства сред. Обеспечение аппаратной поддержки RSS важно в средах с более чем 5000 пользователями на сервер. В сценариях с высоким сетевым трафиком балансировка нагрузки прерываний может быть узким местом. Это может быть обнаружено процессором (*)% время прерывания неравномерно распределяется по ЦП. Сетевые адаптеры с поддержкой RSS могут снизить это ограничение и повысить масштабируемость.

Примечание.

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

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

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

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

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

Системные	Пиковая пропускная способность
DC 1	6.5 МБ/с
DC 2	6.25 МБ/с
DC 3	6.25 МБ/с
DC 4	5.75 МБ/с
DC 5	4.75 МБ/с
Итог	28.5 МБ/с

Рекомендуется: 72 МБ/с (28,5 МБ/с, разделенные на 40 %)

Число целевых систем	Общая пропускная способность (из выше)
2	28.5 МБ/с
Результат нормального поведения	28.5 ÷ 2 = 14.25 МБ/с

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

Хранилище

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

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

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

Определение параметров

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

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

Единственной рекомендацией является обеспечение доступности 110% размера NTDS.dit для включения дефрагментации. Кроме того, следует сделать размещение для роста на протяжении всей жизни оборудования.

Первое и самое важное — оценка размера NTDS.dit и SYSVOL. Эти измерения приводят к размеру как фиксированного диска, так и распределения ОЗУ. Из-за низкой стоимости этих компонентов математика не должна быть строгой и точной. Содержимое о том, как оценить это для существующих и новых сред, можно найти в серии статей "Данные служба хранилища". В частности, ознакомьтесь со следующими статьями:

• Для существующих сред — раздел "Активация ведения журнала дискового пространства, освобожденного дефрагментацией", в статье служба хранилища Ограничения.

• Для новых сред — статья " Оценки роста для пользователей и подразделений Active Directory".

  Примечание.

  Статьи основаны на оценках размера данных, сделанных во время выпуска Active Directory в Windows 2000. Используйте размеры объектов, которые отражают фактический размер объектов в вашей среде.

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

Размер базы данных может отличаться от версий операционной системы. Контроллеры домена, работающие под управлением более ранних операционных систем, таких как Windows Server 2003, имеют меньший размер базы данных, чем контроллер домена, который запускает более позднюю операционную систему, например Windows Server 2008 R2, особенно если включены такие функции, как корзина Active Directory или перемещение учетных данных.

Примечание.

• В новых средах обратите внимание, что оценки роста для пользователей Active Directory и организационных подразделений указывают на то, что 100 000 пользователей (в том же домене) используют около 450 МБ пространства. Обратите внимание, что заполненные атрибуты могут оказать огромное влияние на общую сумму. Атрибуты будут заполнены во многих объектах как сторонними, так и продуктами Майкрософт, включая Microsoft Exchange Server и Lync. Оценка на основе портфеля продуктов в среде предпочтительна, но упражнение по детализации математики и тестирования для точных оценок для всех, но крупнейших сред может на самом деле не стоило значительного времени и усилий.
• Убедитесь, что размер NTDS.dit составляет 110 % от свободного места, чтобы включить автономную дефрагментацию и запланировать рост в течение трех-пятилетнего срока существования оборудования. Учитывая, насколько дешевое хранилище, оценка объема хранилища составляет 300 % от размера DIT, так как выделение хранилища безопасно для удовлетворения роста и потенциальной необходимости автономной дефрагментации.

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

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

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

Данные, собранные на этапе оценки	Размер
Размер NTDS.dit	35 ГБ
Модификатор, позволяющий включить автономную дефрагментацию	2,1 ГБ
Общее необходимое хранилище	73,5 ГБ

Примечание.

Это хранилище необходимо в дополнение к хранилищу, необходимому для SYSVOL, операционной системы, файла страницы, временных файлов, локальных кэшированных данных (таких как файлы установщика) и приложений.

Хранение и производительность

Оценка производительности хранилища

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

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

В частности, общее хранилище (RAID, SAN, NAS, JBOD (т. е. дисковые пространства), VHD) имеет возможность перезаписывать или перегружаться другими рабочими нагрузками, размещенными в серверном хранилище. Кроме того, они добавляют в проблему, из-за проблем с san/network/driver (все между физическим диском и приложением AD) может привести к регулированию и/или задержкам. Для уточнения эти конфигурации не являются плохими, они являются более сложными конфигурациями, которые требуют правильной работы каждого компонента, поэтому требует дополнительного внимания, чтобы обеспечить допустимость производительности. Дополнительные сведения см. в подразделе "Введение имен SAN", а также в приложении D далее в этом документе. Кроме того, в то время как диски с твердым состоянием не имеют ограничения на спиннинг-диски (жесткие диски) относительно возможности обработки только одного ввода-вывода за раз, они по-прежнему имеют ограничения ввода-вывода, а перегрузка или превышение размера ssd возможна. Короче говоря, конечная цель всех усилий по производительности хранилища независимо от базовой архитектуры и дизайна хранилища заключается в том, чтобы обеспечить доступность необходимого объема операций ввода-вывода в секунду (операций ввода-вывода в секунду) и что эти операции ввода-вывода выполняются в пределах допустимого интервала времени (как указано в другом месте в этом документе). В этих сценариях с локально подключенным хранилищем см. приложение C для основных принципов разработки традиционных сценариев локального хранилища. Эти субъекты обычно применимы к более сложным уровням хранилища, а также помогут в диалоге с поставщиками, поддерживающими серверные решения для хранения данных.

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

Для сред, в которых база данных слишком велика, чтобы храниться в ОЗУ, используйте счетчики производительности, чтобы определить, сколько операций ввода-вывода необходимо поддерживать:

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

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

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

Примечание.

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

• LogicalDisk(<NTDS>)\Avg Disk sec/Read указывает, правильно ли размер текущего хранилища. Если результаты примерно равны времени доступа к диску для типа диска, логическаяdisk(<NTDS)\Reads>/sec является допустимой мерой. Проверьте спецификации производителя для хранилища на задней части, но хорошие диапазоны для LogicalDisk(<NTDS>)\Avg Disk sec/Read примерно:
  • 7200 – от 9 до 12,5 миллисекунда (мс)
  • 10 000 – 6 до 10 мс
  • 15 000 – 4–6 мс
  • SSD — от 1 до 3 мс

  • Примечание.

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

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

Рекомендации:

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

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

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

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

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

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

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

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

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

Счетчик	Значение
Фактический логическийdisk(<диск базы данных NTDS)\Avg Disk> sec/Transfer	.02 секунды (20 миллисекунд)
Target LogicalDisk(<NTDS Database Drive)\Avg Disk> sec/Transfer	.01 секунды
Умножение для изменения доступных операций ввода-вывода	0.02 ÷ 0.01 = 2

Имя значения	Значение
LogicalDisk(<диск> базы данных NTDS)\Transfer/sec	400
Умножение для изменения доступных операций ввода-вывода	2
Общее количество операций ввода-вывода в секунду, необходимое во время пикового периода	800

Чтобы определить скорость, с которой требуется прогреть кэш, выполните следующие действия.

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

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

Точки данных для сбора	Values
Максимально допустимое время для теплого	10 минут (600 секунд)
Размер базы данных	2 ГБ

Шаг вычисления	Формула	Результат
Вычисление размера базы данных на страницах	(2 ГБ × 1024 × 1024) = размер базы данных в КБ	2 097 152 КБ
Вычисление количества страниц в базе данных	2 097 152 КБ ÷ 8 КБ = количество страниц	262 144 страниц
Вычисление операций ввода-вывода в секунду, необходимое для полного нагрева кэша	262 144 страницы ÷ 600 секунд = необходимые операции ввода-вывода в секунду	437 операций ввода-вывода в секунду

Обработка

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

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

• Независимо от того, работают ли приложения в среде в инфраструктуре общих служб и рассматриваются в разделе "Отслеживание дорогостоящих и неэффективных поисковых запросов" в статье "Создание более эффективных приложений с поддержкой Microsoft Active Directory" или миграция с вызовов SAM нижнего уровня на вызовы LDAP.

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

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

В существующих средах, так как ранее было рассмотрено изменение размера хранилища, предполагается, что хранилище теперь имеет правильный размер и поэтому данные о загрузке процессора допустимы. Для повторения важно убедиться, что узкие места в системе не являются производительностью хранилища. Когда узкие места существуют, и процессор ожидает, существуют состояния простоя, которые уйдут после удаления узких мест. По мере удаления состояний ожидания процессора по определению загрузка ЦП увеличивается, так как больше не придется ждать данных. Таким образом, соберите счетчики производительности "Логический диск(диск базы данных NTDS)\Avg Disk> sec/Read" и "Process(<lsass)\% Processor Time". Данные в файле Process(lsass)\% Processor Time будут искусственно низкими, если "Логический диск (<диск базы данных NTDS)\Avg Disk> sec/Read" превышает 10 до 15 мс, что является общим пороговым значением, которое корпорация Майкрософт поддерживает для устранения неполадок с производительностью, связанных с хранилищем. Как и раньше, рекомендуется использовать интервалы выборки 15, 30 или 60 минут. Все меньшее, как правило, будет слишком неустойчивым для хороших измерений; что-нибудь большее будет сглаживать ежедневный просмотр чрезмерно.

Введение

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

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

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

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

Как упоминание ранее, при планировании емкости для всего сайта цель состоит в том, чтобы разработать дизайн с проектом емкости N + 1, таким образом, что сбой одной системы в период пикового периода позволит продолжить обслуживание на разумном уровне качества. Это означает, что в сценарии "N" загрузка по всем полям должна быть меньше 100 % (лучше, менее 80 %) в пиковые периоды.

Кроме того, если приложения и клиенты на сайте используют рекомендации по поиску контроллеров домена (то есть с помощью функции 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 в период с 5:00 по 4:00 будут находиться вне проблем планирования емкости.

  Примечание.

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

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

  Альтернативный сценарий— два контроллера домена, работающих на 40%: один контроллер домена завершается сбоем, ожидаемый ЦП на оставшейся стороне будет примерно 80 %. Это гораздо превышает пороговые значения, описанные выше для плана емкости, а также начинает серьезно ограничивать объем головного помещения для 10% до 20% в приведенном выше профиле нагрузки, что означает, что пики будут привести контроллер домена к 90% до 100% во время сценария "N" и определенно снизить скорость реагирования.

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

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

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

Самый простой способ сделать это — использовать представление "Область с накоплением" в надежности Windows и Монитор производительности (perfmon), убедившись, что все счетчики масштабируются одинаково.

Предположения.

• Цель состоит в том, чтобы сократить объем ресурсов до максимально возможного количества серверов. В идеале один сервер будет нести нагрузку и дополнительный сервер, добавленный для избыточности (N + 1 сценарий).

Знания, полученные из данных на диаграмме (Process(lsass)\% Процессор времени):

• Рабочий день начинается вверх около 7:00 и уменьшается в 5:00 вечера.
• Пиковый период с 9:30 до 11:00.

  Примечание.

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

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

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

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

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

Существует две распространенные причины настройки весов LDAP:

• Эмулятор PDC — это пример, который влияет на каждую среду, для которой поведение нагрузки пользователя или приложения не распределяется равномерно. В качестве определенных средств и действий, предназначенных для эмулятора PDC, таких как средства управления групповыми политиками, вторая попытка в случае сбоев проверки подлинности, установления доверия и т. д., ресурсы ЦП в эмуляторе PDC могут быть более сильно требоваться, чем в другом месте сайта.
  • Это полезно только для настройки, если есть заметное различие в использовании ЦП, чтобы уменьшить нагрузку на эмулятор PDC и увеличить нагрузку на другие контроллеры домена позволит более равномерное распределение нагрузки.
  • В этом случае задайте ldapSrvWeight от 50 до 75 для эмулятора PDC.
• Серверы с разными числами ЦП (и скоростями) на сайте. Например, предположим, что есть два восьмиядерных сервера и один четырехядерный сервер. Последний сервер имеет половину процессоров других двух серверов. Это означает, что хорошо распределенная нагрузка клиента увеличит среднюю нагрузку ЦП на четырехядерный прямоугольник примерно в два раза больше, чем восемь ядер.
  • Например, два восьмиядерных коробки будут работать на 40% и четырехядерный ящик будет работать на 80 %.
  • Кроме того, учитывайте влияние потери одного восьмиядерных коробки в этом сценарии, в частности, тот факт, что четырехядерный ящик теперь будет перегружен.

Пример 1 . PDC

Системные	Использование по умолчанию	Новый ldapSrvWeight	Предполагаемое использование новых данных
DC 1 (эмулятор PDC)	53 %	57	40%
DC 2	33%	100	40%
DC 3	33%	100	40%

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

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

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

Системные	Сведения о процессоре\ служебная программа процессора (_Total) Использование по умолчанию	Новый ldapSrvWeight	Предполагаемое использование новых данных
4-ЦП DC 1	40	100	30%
4-ЦП DC 2	40	100	30%
8-ЦП DC 3	20	200	30%

Будьте осторожны с этими сценариями, хотя. Как видно выше, математика выглядит очень красиво и красиво на бумаге. Но на протяжении всей этой статьи планирование сценария "N + 1" имеет первостепенное значение. Влияние одного контроллера домена в автономном режиме должно быть рассчитано для каждого сценария. В приведенном выше сценарии, когда распределение нагрузки даже, чтобы обеспечить 60 % нагрузки во время сценария N, с равномерной балансировкой нагрузки на всех серверах распределение будет хорошо, так как коэффициенты остаются согласованными. Глядя на сценарий настройки эмулятора PDC, и в целом любой сценарий, в котором нагрузка пользователя или приложения не сбалансирована, эффект очень отличается:

Системные	Настройка использования	Новый ldapSrvWeight	Предполагаемое использование новых данных
DC 1 (эмулятор PDC)	40%	85	47 %
DC 2	40%	100	53 %
DC 3	40%	100	53 %

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

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

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

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

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

Системные	Пиковый ЦП
DC 1	120 %
DC 2	147%
Dc 3	218%
Общее количество используемых ЦП	485%

Число целевых систем	Общая пропускная способность (из выше)
ЦП, необходимые в целевом объекте 40 %	4.85 ÷ .4 = 12.25

Повторяясь из-за важности этой точки, не забывайте планировать рост. При условии, что рост на 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_acquires + × semaphore_time × ÷ time_collection_length

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

Сведения о виртуализации

Нет, это параметр настройки операционной системы.

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

Тип данных	Значение
Семафор получает (минимум)	6,161
Семафор получает (максимум)	6,762
Время ожидания Семафора	0
Среднее время удержания Семафора	0.012
Длительность сбора (секунды)	1:11 минут (71 секунды)
Формула (из КБ 2688798)	((6762 – 6161) + 0) × 0,012 /
Минимальное значение maxConcurrentAPI	((6762 – 6161) + 0) × 0,012 ÷ 71 = .101

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

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

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

Категория	Счетчик производительности	Интервал или выборка	Назначение	Предупреждение
Процессор	Служебная программа процессора (_Total)\% обработчика	60 мин	40%	60 %
ОЗУ (Windows Server 2008 R2 или более ранней версии)	Память\Доступно МБ	< 100 МБ	Н/П	< 100 МБ
ОЗУ (Windows Server 2012)	Память\долгосрочное время существования резервного кэша	30 мин	Необходимо проверить	Необходимо проверить
Network	Сетевой интерфейс(*)\Байт Sent/sec Сетевой интерфейс(*)\Байт получено/с	30 мин	40%	60 %
Хранилище	LogicalDisk(<диск базы данных NTDS)\Avg Disk> sec/Read LogicalDisk(<диск базы данных NTDS)\Avg Disk> sec/Write	60 мин	10 мс	15 мс
Службы AD	Netlogon(*)\Среднее время удержания Семафора	60 мин	0	1 с

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

Определения

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

ЦП — центральная единица обработки

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

Несколько ЦП — несколько ЦП, а не в одном интегрированном канале

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

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

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

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

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

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

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

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

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

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

1. Если на шоссе есть только одна машина, это не имеет значения, если есть две полосы или 12 полос. Этот автомобиль будет идти так быстро, как ограничение скорости позволит.
2. Предположим, что данные, необходимые потоку, сразу не доступны. Аналогия заключается в том, что сегмент дороги завершает работу. Если на шоссе есть только один автомобиль, это не имеет значения, какое ограничение скорости находится до повторного открытия полосы (данные извлекается из памяти).
3. По мере увеличения числа автомобилей накладные расходы на управление числом автомобилей увеличивается. Сравните опыт вождения и количество внимания, необходимого, когда дорога практически пуста (например, поздно вечером) и когда движение тяжело (например, середина дня, но не час пик). Кроме того, учитывайте объем внимания, необходимого при движении на двухполосном шоссе, где есть только одна другая полоса, чтобы беспокоиться о том, что водители делают, против шести полос шоссе, где один должен беспокоиться о том, что много других водителей делают.

   Примечание.

   Аналогия о сценарии пикового часа расширена в следующем разделе: время отклика/влияние нагрузки на производительность системы.

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

Примечание.

Закон Амдала и закон Густафсона являются соответствующими понятиями здесь.

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

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

U k = B ÷ T

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

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

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

Возврат к аналогии вождения, используемой ранее в этом разделе:

• Занятое время "середины дня" будет, гипотетически, падать где-то в 40% до 70% диапазона. Существует достаточно движения таким образом, что одна способность выбрать любую полосу не сильно ограничена, и шанс другого водителя находиться на пути, в то время как высокий, не требует уровня усилий, чтобы "найти" безопасный разрыв между другими автомобилями на дороге.
• Обратите внимание, что по мере приближения дорожного движения к часу пиковой нагрузки дорожной системы приближается к 100% емкости. Изменение полос может стать очень сложным, потому что автомобили настолько близки вместе, что повышенная осторожность должна быть осуществлена для этого.

Именно поэтому долгосрочные средние показатели емкости консервативно оцениваются на 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 Time
  • %Processor Time = 1 – U k
  • %Processor Time = 1 – B / T
  • %Processor Time = 1 – X1 – X0 / Y1 – Y0

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

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

Сорок процентов не является жестким и быстрым требованием, это разумное начало. Для различных потребителей Active Directory требуются различные уровни реагирования. Существуют сценарии, в которых среды могут работать в 80% или 90% в качестве устойчивого среднего, так как увеличение времени ожидания доступа к процессору заметно не влияет на производительность клиента. Важно повторно выполнить итерацию, что в системе гораздо медленнее, чем логический процессор в системе, включая доступ к ОЗУ, доступ к диску и передачу ответа по сети. Все эти элементы необходимо настроить совместно. Примеры:

• Добавление дополнительных процессоров в систему под управлением 90 % с привязкой к диску, вероятно, не будет значительно повысить производительность. Более глубокий анализ системы, вероятно, определит, что есть много потоков, которые даже не получают на процессор, потому что они ожидают завершения ввода-вывода.
• Решение проблем, связанных с диском, потенциально означает, что потоки, которые ранее тратили много времени в состоянии ожидания, больше не будут находиться в состоянии ожидания ввода-вывода, и будет больше конкуренции за время ЦП, что означает, что использование 90 % в предыдущем примере будет переходить к 100 % (потому что он не может пойти выше). Оба компонента должны быть настроены совместно.

  Примечание.

  Служебная программа процессора (*)\% процессора может превышать 100 % с системами с режимом Turbo. В этом случае ЦП превышает скорость процессора с оценкой в течение коротких периодов. Справочная документация по производителям ЦП и описание счетчика для получения более подробной информации.

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

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

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

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

Применение субъектов выше 40 % ЦП в качестве разумного целевого объекта для узла, а также гостя является разумным началом для той же причины, что и выше, количество очередей.

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

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

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

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

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

Примечание.

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

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

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

   1. На веб-сайте корпорации по оценке производительности уровня "Стандартный" выберите "Результаты", выделите CPU2006 и выберите "Поиск всех SPECint_rate2006 результатов".
   2. В разделе "Простой запрос" введите критерии поиска для целевого процессора, например "Совпадения процессора" E5-2630 (базовый объект) и "Совпадения процессора" E5-2650 (базовый план).
   3. Найдите используемую конфигурацию сервера и процессора (или что-то близкое, если точное совпадение недоступно) и запишите значение в столбцах Result и #Cores .

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

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

   Используя приведенный выше пример:

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

3. Умножьте предполагаемое число процессоров модификатором. В приведенном выше случае для перехода от процессора E5-2650 к процессору E5-2630 умножаются вычисляемые 11,25 ЦП × 0,92 = 10,35 процессоров.

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

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

На этом рисунке два шпинделя зеркало и разделены на логические области для хранения данных (данные 1 и данные 2). Эти логические области рассматриваются операционной системой как отдельные физические диски.

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

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

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

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

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

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

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

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

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

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

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

  Примечание.

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

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

  Description	7200 RPM 9ms seek, 4ms access	10 000 RPM 7 мс, доступ к 3 мс	15 000 RPM 4 мс, доступ к 2 мс
  Случайный ввод-вывод	80	100	150
  Последовательный ввод-вывод	250	300	500

  10 000 дисков RPM	Размер блока 8 КБ (Active Directory Jet)
  Случайный ввод-вывод	800 КБ/с
  Последовательный ввод-вывод	2400 КБ/с

• Обратная планка SCSI (шина) — понимание того, как "серверная планка SCSI (шина)" или в этом сценарии кабель ленты влияет на пропускную способность подсистемы хранения зависит от знаний о размере блока. По сути, вопрос заключается в том, сколько операций ввода-вывода может обрабатывать автобус, если ввода-вывода находится в 8 КБ блоках? В этом сценарии шина SCSI составляет 20 МБ/с или 20480 КБ/с. 20480 КБ/с, разделенных на 8 КБ блоков, дает не более 2500 операций ввода-вывода в секунду, поддерживаемых шиной SCSI.

  Примечание.

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

  Ввод-вывод, поддерживаемый шиной SCSI на размер блока	Размер блока КБ 2	8 КБ размер блока (AD Jet) (SQL Server 7.0/SQL Server 2000)
  20 МБ/с	10,000	2500
  40 МБ/с	20,000	5,000
  128 МБ/с	65 536	16,384
  320 МБ/с	160 000	40 000

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

  Примечание.

  Предполагается, что шина SCSI эффективна на 100 %.

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

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

• Шина PCI — это часто пропущенный компонент. В этом примере это не будет узким местом; однако по мере увеличения масштаба систем она может стать узким местом. Для справки 32-разрядная шина PCI, работающая в 33 МГц, может передавать данные 133 МБ/с. Ниже приведено уравнение:

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

  Обратите внимание, что это теоретический предел; На самом деле достигается только около 50% максимума, хотя в определенных сценариях всплеска эффективность 75% может быть получена в течение коротких периодов.

  66 МГц 64-разрядная шина PCI может поддерживать теоретический максимум (64 бита ÷ 8 бит на байт × 66 МГц) = 528 МБ/с. Кроме того, любое другое устройство (например, сетевой адаптер, второй контроллер SCSI и т. д.) уменьшит пропускную способность, доступную по мере общего доступа к пропускной способности, и устройства будут бороться за ограниченные ресурсы.

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

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

Примечания.	Анализ узких мест	Диск	Шина	Адаптер	Шина PCI
Это конфигурация контроллера домена после добавления второго диска. Конфигурация диска представляет узкие места в 800 КБ/с.	Добавление 1 диска (Total=2) Операции ввода-вывода являются случайными Размер блока 4 КБ 10 000 RPM HD	Общее число операций ввода-вывода в 200 Всего 800 КБ/с.
После добавления 7 дисков конфигурация диска по-прежнему представляет узкие места в 3200 КБ/с.	Добавление 7 дисков (Total=8) Операции ввода-вывода являются случайными Размер блока 4 КБ 10 000 RPM HD	Всего 800 операций ввода-вывода. Всего 3200 КБ/с
После смены ввода-вывода на последовательный сетевой адаптер становится узким местом, так как он ограничен 1000 операций ввода-вывода в секунду.	Добавление 7 дисков (Total=8) Последовательный ввод-вывод Размер блока 4 КБ 10 000 RPM HD			2400 операций ввода-вывода в секунду можно считывать и записывать на диск, контроллер ограничен 1000 операций ввода-вывода в секунду
После замены сетевого адаптера адаптером SCSI, поддерживающим 10 000 операций ввода-вывода в секунду, узкие места возвращаются в конфигурацию диска.	Добавление 7 дисков (Total=8) Операции ввода-вывода являются случайными Размер блока 4 КБ 10 000 RPM HD Обновление адаптера SCSI (теперь поддерживает 10 000 операций ввода-вывода)	Всего 800 операций ввода-вывода. Всего 3200 КБ/с
После увеличения размера блока до 32 КБ шина становится узким местом, так как она поддерживает только 20 МБ/с.	Добавление 7 дисков (Total=8) Операции ввода-вывода являются случайными Размер блока 32 КБ 10 000 RPM HD		Всего 800 операций ввода-вывода. 25 600 КБ/с (25 МБ/с) можно считывать и записывать на диск. Шина поддерживает только 20 МБ/с
После обновления шины и добавления дополнительных дисков диск остается узким местом.	Добавление 13 дисков (Total=14) Добавление второго адаптера SCSI с 14 дисками Операции ввода-вывода являются случайными Размер блока 4 КБ 10 000 RPM HD Обновление до 320 МБ/с SCSI	2800 I/Os 11 200 КБ/с (10,9 МБ/с)
После изменения последовательного ввода-вывода диск остается узким местом.	Добавление 13 дисков (Total=14) Добавление второго адаптера SCSI с 14 дисками Последовательный ввод-вывод Размер блока 4 КБ 10 000 RPM HD Обновление до 320 МБ/с SCSI	8400 I/Os 33600 КБ\s (32.8 МБ\s)
После добавления более быстрых жестких дисков диск остается узким местом.	Добавление 13 дисков (Total=14) Добавление второго адаптера SCSI с 14 дисками Последовательный ввод-вывод Размер блока 4 КБ 15 000 RPM HD Обновление до 320 МБ/с SCSI	14 000 I/Os 56 000 КБ/с (54.7 МБ/с)
После увеличения размера блока до 32 КБ шина PCI становится узким местом.	Добавление 13 дисков (Total=14) Добавление второго адаптера SCSI с 14 дисками Последовательный ввод-вывод Размер блока 32 КБ 15 000 RPM HD Обновление до 320 МБ/с SCSI				14 000 I/Os 448 000 КБ/с (437 МБ/с) — это ограничение на чтение и запись в спинделе. Шина PCI поддерживает теоретические максимум 133 МБ/с (75 % эффективно в лучшем случае).

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

Характер подсистемы хранения резко не изменяется при появлении контроллера массива; он просто заменяет адаптер SCSI в вычислениях. Что изменяет стоимость чтения и записи данных на диск при использовании различных уровней массива (например, RAID 0, RAID 1 или RAID 5).

В RAID 0 данные чередуются по всем дискам в наборе RAID. Это означает, что во время операции чтения или записи часть данных извлекается или отправляется на каждый диск, увеличив объем данных, которые могут транзитировать систему в течение одного и того же периода времени. Таким образом, в течение одной секунды на каждом спинделе (опять же при условии, что 10000-rpm дисков), можно выполнять 100 операций ввода-вывода. Общее количество операций ввода-вывода, которое может поддерживаться, составляет N спинделей в секунду 100 операций ввода-вывода в секунду (дает 100*N ввода-вывода в секунду).

В RAID 1 данные зеркало (дублируются) между парой спинделей для избыточности. Таким образом, при выполнении операции чтения операций ввода-вывода данные можно считывать из обоих спинделей в наборе. Это эффективно делает емкость ввода-вывода на обоих дисках доступной во время операции чтения. Предостережение заключается в том, что операции записи не получают преимущества производительности в RAID 1. Это связано с тем, что одни и те же данные должны быть записаны на оба диска для обеспечения избыточности. Несмотря на то, что запись данных выполняется параллельно с обоими спинделями, так как оба спинделя занимают дублирующиеся данные, операция ввода-вывода в сущности предотвращает выполнение двух операций чтения. Таким образом, каждая запись операций ввода-вывода стоит две операции чтения ввода-вывода. Формулу можно создать из этих сведений, чтобы определить общее количество операций ввода-вывода, которые происходят:

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

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

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

RAID 1+ 0 ведет себя точно так же, как RAID 1 относительно расходов на чтение и запись. Однако ввод-вывод теперь чередуется по каждому зеркало набору. If

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

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

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

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

1. Чтение старых данных
2. Чтение старой четности
3. Запись новых данных
4. Создание нового четности

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

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

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

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

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

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

• Жесткий диск SCSI или Fibre Channel
• служба хранилища внутренний план канала служба хранилища
• Единицы хранения
• модуль контроллера служба хранилища
• Коммутаторы SAN
• HBA(s)
• Шина PCI

При разработке любой системы для избыточности дополнительные компоненты включаются для удовлетворения потенциального сбоя. При планировании емкости очень важно исключить избыточный компонент из доступных ресурсов. Например, если в san есть два модуля контроллера, емкость ввода-вывода одного модуля контроллера — это все, что должно использоваться для общей пропускной способности ввода-вывода, доступной системе. Это связано с тем, что если один контроллер завершается сбоем, все нагрузки ввода-вывода, требуемой всеми подключенными системами, должны обрабатываться оставшимся контроллером. Так как все планирование емкости выполняется для пиковых периодов использования, избыточные компоненты не должны учитываться в доступных ресурсах и запланированное пиковое использование не должно превышать 80% насыщенности системы (чтобы обеспечить ускорение или аномальное поведение системы). Аналогичным образом избыточный коммутатор SAN, единица хранения и спиндели не должны учитываться в вычислениях ввода-вывода.

При анализе поведения жесткого диска SCSI или Fibre Channel метод анализа поведения, как описано ранее, не изменяется. Хотя существуют определенные преимущества и недостатки для каждого протокола, ограничение на каждый диск является механическим ограничением жесткого диска.

Анализ канала в единице хранения точно такой же, как вычисление ресурсов, доступных на шине SCSI, или пропускной способности (например, 20 МБ/с), разделенных размером блока (например, 8 КБ). Где это отклоняется от простого предыдущего примера, находится в агрегации нескольких каналов. Например, если существует 6 каналов, каждая поддержка 20 МБ/с максимальной скорости передачи данных, общий объем операций ввода-вывода и передачи данных, доступных, составляет 100 МБ/с (это правильно, это не 120 МБ/с). Опять же, отказоустойчивость является основным игроком в этом вычислении, в случае потери всего канала система остается только с 5 функционируют каналами. Таким образом, чтобы обеспечить соблюдение ожиданий производительности в случае сбоя, общая пропускная способность для всех каналов хранения не должна превышать 100 МБ/с (предполагается, что нагрузка и отказоустойчивость равномерно распределяются по всем каналам). Преобразование этого в профиль ввода-вывода зависит от поведения приложения. В случае с операцией ввода-вывода в Active Directory это может соотнести примерно с 12500 операций ввода-вывода в секунду (100 МБ/с ÷ 8 КБ на операции ввода-вывода).

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

Когда данные выходят из модуля контроллера, он передает подключение Fibre Channel, оцененное в 1 ГБ/с (или 1 Гигабит в секунду). Чтобы сопоставить это с другими метриками, 1 ГБ/с превращается в 128 МБ/с (1 ГБ/с ÷ 8 бит/байт). Так как это превышает общую пропускную способность по всем каналам в единице хранения (100 МБ/с), это не будет узким местом в системе. Кроме того, так как это только один из двух каналов (дополнительное подключение 1 ГБ/с для избыточности Fibre Channel), если одно подключение завершается сбоем, оставшееся подключение по-прежнему имеет достаточно емкости для обработки всех необходимых данных передачи данных.

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

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

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

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

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

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

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

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

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

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

  В случае Active Directory кэш ограничен только объемом ОЗУ.

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

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

Рекомендации:

• Как операции ввода-вывода в секунду, так и задержки очень субъективно относятся к конструкциям производителя, и в некоторых случаях наблюдается снижение производительности, чем технологии, основанные на спине. Короче говоря, более важно проверить и проверить спецификации производителя на диске и не предполагать каких-либо общих возможностей.
• Типы операций ввода-вывода в секунду могут иметь очень разные числа в зависимости от того, является ли он чтением или записью. Службы AD DS, как правило, преимущественно на основе чтения, будут менее затронуты, чем в некоторых других сценариях приложений.
• "Запись выносливости" - это концепция, которую ячейки SSD в конечном итоге будут носить. Различные производители имеют дело с этой проблемой разные моды. По крайней мере для диска базы данных, профиль ввода-вывода преимущественно считывает значение этой проблемы, так как данные не являются очень неустойчивыми.

Итоги

Одним из способов думать о хранилище является пиктурирование домашних сантехники. Представьте себе, что данные хранятся в виде основного потока домашних операций ввода-вывода в секунду. Если это забито (например, корни в трубе) или ограничено (оно свернуто или слишком мало), все раковины в домашнем хозяйстве резервной копии, когда используется слишком много воды (слишком много гостей). Это совершенно аналогично общей среде, где одна или несколько систем используют общее хранилище в SAN/NAS/iSCSI с тем же базовым носителем. Различные подходы можно использовать для решения различных сценариев:

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

В любой конструкции сантехники несколько сливов питаются в основной слив. Если что-нибудь останавливает один из этих сливов или точку соединения, только вещи за этой точкой соединения резервное копирование. В сценарии хранения это может быть перегруженный коммутатор (сценарий SAN/NAS/iSCSI), проблемы совместимости драйверов (неправильное сочетание встроенного ПО,HBA/storport.sys) или резервного копирования/антивирусной или дефрагментации. Чтобы определить, является ли хранилище "канал" достаточно большим, необходимо измерять размер операций ввода-вывода и операций ввода-вывода. На каждом совместном соединении они объединяются, чтобы обеспечить достаточный "диаметр трубы".

Приложение D. Обсуждение устранения неполадок с хранилищем — среды, в которых предоставляется по крайней мере столько ОЗУ, сколько размер базы данных не является жизнеспособным вариантом

Полезно понять, почему эти рекомендации существуют таким образом, чтобы изменения в технологии хранения могли быть размещены. Эти рекомендации существуют по двум причинам. Первое — изоляция операций ввода-вывода, поэтому проблемы с производительностью (т. е. разбиение по страницам) в шпинделе операционной системы не влияют на производительность профилей базы данных и операций ввода-вывода. Во-вторых, файлы журналов для AD DS (и большинство баз данных) являются последовательными в природе, а жесткие диски и кэши на основе шпинделя имеют огромное преимущество производительности при использовании с последовательных операций ввода-вывода по сравнению с более случайными шаблонами операций ввода-вывода операционной системы и почти чисто случайными шаблонами операций ввода-вывода диска базы данных AD DS. Изолируя последовательный ввод-вывод на отдельный физический диск, пропускная способность может быть увеличена. Проблема, представленная сегодняшними вариантами хранения, заключается в том, что основные предположения, лежащие в основе этих рекомендаций, больше не соответствуют действительности. Во многих сценариях виртуализированного хранилища, таких как iSCSI, SAN, NAS и файлы образа виртуального диска, базовый носитель хранилища используется для нескольких узлов, поэтому полностью отрицает как изоляцию операций ввода-вывода, так и "последовательную оптимизацию ввода-вывода". На самом деле эти сценарии добавляют дополнительный уровень сложности в том, что другие узлы, обращающиеся к общему носителю, могут снизить скорость реагирования на контроллер домена.

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

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

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

Для обычных рабочих условий цель планирования хранилища сводит к минимуму время ожидания для возврата запроса от AD DS с диска. Это означает, что количество невыполненных операций ввода-вывода и ожидающих операций ввода-вывода меньше или эквивалентно количеству путей к диску. Существует множество способов измерения этого. В сценарии мониторинга производительности общая рекомендация заключается в том, что логическийdisk(<диск базы данных NTDS)\Avg Disk> sec/Read меньше 20 мс. Требуемое пороговое значение операционной системы должно быть гораздо ниже, желательно максимально близко к скорости хранилища в диапазоне от 2 до 6 миллисекунд (.002 до 006 секунды) в зависимости от типа хранилища.

Пример:

Анализ диаграммы:

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

Применение этих знаний:

• Влияние на членство пользователя в большой группе. Предположим, что для этого требуется чтение 1 МБ данных с диска, количество операций ввода-вывода и время его выполнения, как показано ниже.
  • Страницы базы данных Active Directory размером 8 КБ.
  • Для чтения с диска требуется не менее 128 страниц.
  • Если ничего не кэшируется, на полу (10 мс) это займет не менее 1,28 секунд, чтобы загрузить данные с диска, чтобы вернуть его клиенту. В 20 мс, где пропускная способность хранилища уже давно превышена, а также является рекомендуемой максимальной, для получения данных из диска потребуется 2,5 секунды, чтобы вернуть его конечному пользователю.
• С какой скоростью кэш будет нагреваться. Предположим, что загрузка клиента будет максимально увеличить пропускную способность в этом примере хранилища, кэш будет тепло в размере 2400 операций ввода-вывода в секунду × 8 КБ на операции ввода-вывода. Или примерно 20 МБ/с в секунду, загрузка около 1 ГБ базы данных в ОЗУ каждые 53 секунды.

Примечание.

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

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