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

Мне часто задают вопрос: «Что лучше с точки зрения производительности: иметь несколько крупных объектов групповой политики (GPO) или много мелких?». Этот вопрос, вместе с другими вопросами, относящимися к разработке групповых политик и их производительности и является темой данной статьи И, как и для большинства общих вопросов,

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

Монолитные объекты GPO против функциональных

Начать стоит с описания различных способов применения объектов GPO. Термины «монолитный» и «функциональный» относятся к их схемам. Монолитные объекты GPO содержат параметры из множества различных областей. Для примера, монолитный объект GPO может содержать параметры из политик административных шаблонов, обслуживания Internet Explorer и установки программного обеспечения – все в едином объекте GPO. По контрасту, функциональные объекты GPO обычно выполняют только одну задачу. Для примера, функциональный объект GPO может заниматься только установкой программного обеспечения или применением параметров безопасности. Я встречал даже функциональные объекты GPO, которые содержали только один параметр политики! Но это, вероятно, редкий случай. На рис. 1 показаны некоторые из преимуществ и недостатков каждого подхода.

Figure 1  Comparing monolithic and functional GPOs

Проблема Монолитные объекты GPO Функциональные объекты GPO

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

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

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

Знакомство с обработкой групповых политик

Обработка групповых политик – это сложный набор взаимодействий, включающий в себя многие элементы инфраструктуры Windows® и Active Directory®. Если рассматривать ее в целом, обработка групповой политики состоит из двух частей. Первая именуется основной, или обработкой инфраструктуры групповой политики. На этой стадии клиент групповой политики Windows запрашивает свой ближайший контроллер домена, чтобы определить скорость подключения к нему, его местонахождение в иерархии Active Directory (то есть членом какого сайта, домена и подразделения является клиент) и то, какие объекты GPO применяются к компьютеру или находящемуся в системе на данный момент пользователю. (Важно отметить, что в этом контексте клиент может быть сервером или рабочей станцией, входящей в домен Active Directory.) После создания списка объектов GPO начинается следующая фаза – обработка клиентского расширения (Client-Side Extension – CSE). В ходе фазы CSE каждое зарегистрированное расширение CSE обрабатывает список объектов GPO, устанавливающих параметры в его области. Например, расширение CSE реестра или административного шаблона сперва обрабатывает все объекты GPO, прилагающиеся к определенному компьютеру или пользователю и применившие к ним политику реестра.

В приведенном ниже списке подробно описаны действия, выполняемые циклом обработки групповой политики, включая сетевые взаимодействия между клиентом и контроллером домена. Важно помнить, что групповая политика применяется и к компьютерам, и к пользователям. Следовательно, при каждой обработке групповой политики, скажем, в ходе ее фонового обновления, перечисленные мною ниже действия будут повторены как для компьютера, так и для учетной записи находящегося в системе пользователя для каждой системы, поскольку к ним могут применяться различные наборы политик. Когда это происходит, Windows выполняет цикл обработки одновременно для компьютера и пользователя, причём эти циклы работают в различных потоках внутри процесса механизма групповой политики. (Процесс Winlogon для Windows 2000, Windows XP и Windows Server® 2003, либо служба клиента групповой политики в Windows Vista® и Windows Server 2008.)

Обработка групповой политики состоит из шести этапов.

1. Клиент выполняет обнаружение медленных подключений по протоколу Internet Control Message Protocol (ICMP) к контроллеру домена в своем сайте, чтобы определить скорость подключения. В Windows Vista использование ICMP для обнаружения медленных подключений заменяется работой службы сетевого расположения (NLA).
2. Клиент считывает информацию о состоянии расширения CSE из своего локального реестра, чтобы определить, какие объекты GPO обрабатывались последними.
3. Клиент использует протокол LDAP для поиска по атрибуту gpLink в Active Directory на каждом объекте-контейнере внутри своего местоположения в иерархии Active Directory – сперва на уровне подразделений (включая все вложенные подразделения), затем в домене и, наконец, на уровне сайта Active Directory. Из результатов поиска он выстраивает список объектов GPO, которые необходимо рассмотреть на предмет обработки.
4. Затем выполняется поиск каждого из GPO в Active Directory, чтобы определить, есть ли у клиента (пользователя или компьютера) необходимые разрешения для его обработки. Также рассматриваются номер его версии, путь к шаблону групповой политики (GPT), часть объекта GPO в SYSVOL и то, какие расширения CSE применяются в этом объекте GPO.
5. Затем клиент использует протокол SMB для чтения содержимого шаблона групповой политики и получения номера версии GPO из файла gpt.ini. Номера версий в контейнере групповой политики (Group Policy Container – GPC) и шаблон групповой политики используются для определения, менялся ли объект GPO со времени последнего цикла обработки.
6. Каждое расширение CSE запускается в порядке, зарегистрированном в HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions и обрабатывает объекты GPO, которые применяют это расширение CSE, если объект GPO изменился со времени последнего цикла обработки (как было определено в ходе основной обработки). Каждое расширение CSE также вносит данные результирующего набора политик пользователя (Resultant Set of User Policy – RSOP) в инструментарий управления Windows (WindowsManagement Instrumentation – WMI) при каждом обновлении, если они доступны.

Давайте разберем этот процесс и посмотрим, что может сказаться на производительности. В первую очередь следует понять, что между фоновой обработкой и обработкой переднего плана есть разница. Обработка переднего плана происходит в ходе перезапуска системы для компьютеров и входа в систему для пользователей. Фоновые обновления по умолчанию происходят на рабочих станциях и рядовых серверах каждые 90 минут плюс случайное значение, могущее достигать 30 минут. Фоновые обновления на контроллерах доменов по умолчанию происходят каждые 5 минут. В Windows Vista могут также происходить обновления на основе NLA, которые по сути являются событиями фонового обновления, вызванными предшествовавшим сбоем обработки групповой политики, произошедшим из-за отсутствия доступа к контроллеру домена (как если бы клиент был отключен в момент окончания интервала между фоновыми обновлениями). Почему эти различия важны? В основном потому, что определенные расширения CSE (например, расширения CSE установки программного обеспечения и перенаправления папок) не запускаются в ходе фоновых обновлений Точно так же сценарии входа в систему/выхода из нее или запуска/выключения не будут работать в ходе фонового обновления.

Аналогично, в этапе 1 данного процесса я упомянул обнаружение медленных подключений. В системах, предшествовавших Windows Vista, этот процесс зависел от использования клиентом ICMP для проверки связи с контроллером домена, чтобы определить его доступность и скорость связи. В случае падения расчетной скорости связи ниже определенного значения (500 кб/с по умолчанию), связь считается медленной, и, опять таки, некоторые расширения CSE, такие как расширения установки программного обеспечения, перенаправления папок, обслуживания Internet Explorer и другие, отказываются работать. Все эти условия могут повлиять на производительность, равно как и на ожидаемую доставку политики.

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

Когда происходит изменение групповой политики

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

Объект GPO состоит из двух частей – контейнера GPC, сохраненного в Active Directory внутри имеющегося в каждом домене контейнера CN=Policies, CN=System, и шаблона GPT, сохраненного в SYSVOL в папке Policies. Обе части содержат номер версии. У контейнера GPC номер версии хранится в атрибуте versionNumber на объекте контейнера GPC. У шаблона GPT он хранится внутри файла gpt.ini в корневой папке данного шаблона GPT. Клиент также сохраняет записи номеров версии обработанных им объектов GPO (как для компьютеров, так и для пользователей) в своем реестре. Информация о версии содержится в HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History, если речь идет об объекте GPO для компьютера, и в HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<Идентификатор безопасности пользователя>, если об объекте GPO для пользователя.

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

• Изменение в списке объектов GPO, применяющихся к пользователю или компьютеру (объект GPO добавлен или удален)
• Изменение состава членов группы безопасности пользователя или компьютера
• Изменение в фильтре WMI, связанном с объектом GPO (фильтр WMI добавлен или удален)

Если любое из этих условий выполнено, клиент выполнит повторную обработку политики в ходе этого цикла, однако в этом процессе есть свои тонкости, про которые стоит знать из-за их значительного влияния на производительность. Если для какого-либо расширения CSE изменяется 1 объект GPO из 10, то все объекты GPO для этого расширения CSE должны быть обработаны. Помните, что «обрабатываемой единицей» является расширение CSE. Однако расширения CSE должны обрабатывать политики в определенном порядке (сперва локальные объекты GPO, затем объекты GPO, связанные с сайтом, затем связанные с доменом и с подразделением). Приняв это требование, предположим, к примеру, что к пользователю применимы 10 объектов GPO, привязанных на различных уровнях Active Directory. Предположим также, что каждый из этих 10 объектов GPO применяет какой-либо параметр политики административного шаблона. На сцену выступает администратор, изменяющий объект GPO, связанный с доменом, – добавляя новый параметр политики административного шаблона. Теперь компьютер или пользователь начинают обрабатывать политики и замечают, что номер версии измененного объекта GPO выше, чем в прошлый раз, следовательно, его нужно обработать снова. Но чтобы сохранить порядок обработки политик, при этом будет необходимо обработать все параметры административного шаблона, которые прилагаются ко всем объектам GPO. Таким образом, простое изменение объекта GPO может нанести сильный удар по производительности клиента.

Сравнение производительности монолитных и функциональных объектов GPO

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

Монолитные объекты GPO могут давать скрытое снижение производительности из-за особенностей контроля версий групповых политик. Причины этого очевидны не сразу. Они связаны с отсутствием в механизме обработки групповых политик концепции контроля версий на основе расширений CSE. Допустим, к пользователю применяются три объекта GPO. Каждый объект GPO монолитен в том, что он реализует политику в нескольких областях. Для примера, предположим, что каждый объект GPO реализует политики административного шаблона, установки программного обеспечения и перенаправления папок. Теперь предположим, что администратор изменяет политику административного шаблона в одном из этих объектов GPO. Это изменение увеличивает номер версии. Затем на сцену выходит пользователь и начинает обработку групповых политик. Расширение CSE административного шаблона запускается, замечает, что один из объектов GPO изменился, и обрабатывает все три объекта GPO снова.

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

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

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

Измерение производительности групповых политик

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

Итак, как можно измерить продолжительность цикла обработки групповых политик? Ответ опять непрост. Если используется Windows Vista или Windows Server 2008, можно воспользоваться новыми рабочими журналами просмотра событий. Рабочий журнал групповой политики средства просмотра событий, который можно найти в «Журналы приложений и служб»\Microsoft\Windows\«Групповая политика»\«Действующая», предоставляет превосходный инструментарий для каждого этапа цикла обработки групповой политики (см. рис. 2).

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

Однако для тех, кто не работает в среде Windows Vista или Windows Server 2008, механизмы измерения времени обработки политик куда менее прямолинейны. В этом случае остается включить подробное ведение журнала userenv (поддержку обеспечивает статья базы знаний Майкрософт support.microsoft.com/kb/221833) и просматривать временные метки внутри файла для выбранного цикла обработки, или использовать параметры в реестре клиента, указывающие время начала и завершения обработки политики. Эти значения для компьютера хранятся здесь

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}

а для пользователя – здесь:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}

Значения хранятся в формате FILETIME, и их необходимо преобразовать в обычную дату и время. Можно также использовать написанную мной бесплатную служебную программу GPTime.exe (доступную на gpoguy.com/tools.htm#GP_Time_Utility) для получения той же информации.

В отсутствие среды Windows Vista или Windows Server 2008, но при наличии доступа к журналу userenv все же можно получить ценную информацию о том, сколько времени ушло на каждый цикл обработки политики. Например, на рис. 3 изображен фрагмент журнала userenv, показывающий часть основной фазы обработки групповой политики.

Рис. 3 Часть журнала userenv

Обратите внимание, что в каждой строке файла журнала есть метка времени. Основная часть цикла обработки групповой политики начинается с события, сообщающего что-нибудь вроде: "ProcessGPOs: Starting user Group Policy (Background) processing ..." Часть цикла обработки, связанная с расширением CSE, начинается со строки: "ProcessGPOs: Processing extension Registry." Этот журнал и метки времени в нем можно использовать для определения продолжительности каждой части цикла обработки политики.

Общие наблюдения по поводу производительности

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

Это верно для большинства областей политики, поскольку большинству расширений CSE необходимо выполнять задачи, работающие дольше, чем основная часть их обработки, наиболее ресурсоемкими операциями которой являются запросы к Active Directory и SYSVOL. Например, нельзя и сравнить время, проведенное в основной части обработки, с тем временем, которое расширение CSE установки программного обеспечения может потратить на установку Microsoft® Office. Однако для большинства фоновых обновлений политики, когда изменений со времени последнего цикла нет, основная часть цикла занимает примерно то же время, что и работа расширения CSE. Исключением является обработка политики реестра – которая на самом деле довольно быстра, если пользователь или компьютер не отягощен десятками и сотнями параметров политики реестра.

Кроме того, отключение компьютера или пользовательской стороны объекта GPO по причине неиспользования почти не влияет на производительность обработки политик. Если же не используется сторона политики, все издержки будут заключаться в запросе к Active Directory, чтобы определить это. Запрос, идентичный тому, который происходит для определения того, реализованы ли расширения CSE для той стороны объекта GPO, должен быть выполнен, чтобы просмотреть вариант отключения. Эффект отключения стороны несущественен.

Рекомендации по достижению оптимальной производительности групповых политик

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

1. Если в объекты GPO вносятся частые изменения, не забывайте вышеупомянутые эффекты – изменение в одном расширении CSE может повлиять на обработку всех расширений CSE. В силу этого, если планируется частое внесение изменений, например в политику реестра, имеет смысл поместить данную политику в функциональный объект GPO (объект GPO, занимающийся только политикой реестра), поскольку это изолирует другие расширения CSE от изменений, вызывающих новую обработку.
2. При обдумывании того, сколько объектов GPO стоит иметь, не забывайте, что обработка политики происходит только после изменений, и «затратные» расширения CSE, такие как установка программного обеспечения или перенаправление папок, а также обработка большого числа политик реестра или установка разрешений на больших деревьях файлов либо реестра, занимают большую часть времени. Время, потраченное на запросы списка объектов GPO у Active Directory в ходе основной обработки, часто является самой малой частью цикла обработки. Так, 30 объектов GPO, применяющихся к какому-либо пользователю и отличающиеся минимальным числом изменений реестра, могут занять меньше времени на обработку, чем 5 объектов GPO, которые часто подвергаются изменениям и из-за этого постоянно используют затратные расширения CSE.
3. Избегайте моделей поведения, явно снижающих производительность обработки политик. Например, можно установить политику, заставляющую расширения CSE вести обработку, даже если объект GPO не изменен (в «Конфигурация компьютера»\«Административные шаблоны»\«Система»\«Групповая политика»). Но в этом случае стоит ожидать, что циклы обработки станут дольше.
4. Не забывайте о последствиях отключения оптимизации быстрого входа в систему в Windows XP и Windows Vista (это можно сделать, включив политику в «Конфигурация компьютера»\«Административные шаблоны»\«Система»\«Вход в систему»\«Всегда ждать ответа сети при запуске компьютера и входе пользователя в систему»). Когда эта политика включена, обработка переднего плана переключается с асинхронной на синхронную. Это значит, что политика компьютера и пользователя должна быть выполнена полностью, прежде чем пользователь сможет управлять компьютером и рабочим столом. Однако это также может быть полезно, поскольку позволяет обойти проблему необходимости двух и более перезапусков или входов в систему для ввода в действие политик установки программного обеспечения и перенаправления папок.

Заключение

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

Знакомство с тем, как функционирует цикл обработки и на что уходит время, является большим шагом к определению источников этих проблем. Используйте рабочие журналы Windows Vista или Windows Server 2008 (или журналы userenv в предыдущих версиях Windows) для получения практической информации о цикле обработки. Не забывайте о превратностях обработки расширений CSE и о том, что является изменением политики с точки зрения расширения CSE. Наконец, помните, что в динамических средах с большим числом изменений функциональные объекты GPO могут быть предпочтительнее монолитных. Итог же состоит в том, что групповая политика – это технология, разработанная для помощи в управлении средой Windows. Важно чтобы потребности бизнеса двигали проектирование групповых политик, а не наоборот. Достижению этой цели поможет учет описанных выше моделей поведения производительности.