Система мониторинга репликаций сайта AD в реальном времени
Работа системного администратора интересна тем, что постоянно возникают новые задачи, которые требуют оригинальных решений. Вот и у меня появилась необходимость мониторинга состояния репликации между сайтами и контроллерами домена.
Ошибки в репликациях могут возникать по многим причинам, основные из которых — проблемы с каналом (сетью) и неполадки на самом контроллере домена. Я не буду подробно останавливаться на причинах возникновения ошибок — в каждой организации своя специфика инфраструктуры.
Для создания полноценной системы мониторинга были созданы два сценария, две задачи в планировщике заданий Scheduled Tasks и одна групповая политика Group Policy. Для запуска и работы всех этих компонентов необходима учетная запись с административными полномочиями, а также настроенная на запуск в автоматическом режиме служба оповещения Messenger на контроллерах домена и рабочих станциях администраторов. Кроме того, на контроллерах домена должны быть установлены утилиты из комплекта средств поддержки Support Tools из дистрибутива Windows Server 2003. Также желательно установить Resource Kit для Windows Server 2003 (все эти утилиты можно загрузить с сайта Microsoft).
Первый из созданных сценариев (см. листинг 1) обеспечивает сбор статистики работы службы репликации. У него есть общая часть с приведенным в листинге 2 сценарием для диагностики. Эта общая часть показана в листинге 3.
Механизм работы общей части
В самом начале работы сценариев мы отключаем отображение исполняемых команд. Указание параметра @ отключает вывод самой команды echo off. Далее мы выполняем проверку версии Windows, на которой запускается сценарий (он может работать на версиях от Windows NT 4.0 до Windows XP и Windows Server 2003). Если проверка завершается ошибкой, происходит вывод информации о сценарии, и тот завершает работу.
Если система относится к семейству Windows NT, то переменной INFO присваивается значение rem, а переменной SEXIT — значение 0, и происходит переход к следующему шагу.
Сбор статистики
Процесс работы сценария сбора статистики replic_monitor.bat (см. листинг 1) начинается с создания переменной file_name, которой мы присваиваем текущую дату из системной переменной %date%. Дописываем в файл %file_name%_rep_mon.log вывод команды echo (для форматирования). Если файл не найден, создаем файл и записываем в него. Далее дописываем в файл %file_name%_rep_mon.log текущую дату и время. Опять же для целей форматирования дописываем в файл %file_name%_rep_mon.log вывод команды echo.
С помощью утилиты repadmin с ключом /showrepl делаем запрос и указываем домен, для которого хотим получить информацию о репликах domain.local. Результаты записываем.
Делаем запрос уже с помощью утилиты dcdiag, назначаем домен /n:domain.local, указываем, что диагностируем репликацию /test:replications. Дописываем в файл %file_name%_rep_mon.log вывод команды.
Этот простой сценарий можно запускать однократно или по расписанию. Я применяю запуск по расписанию раз в час во все дни недели. Это обеспечивает меня полной статистикой с разбивкой на сутки. Ниже я покажу, как настроить такое задание.
Для запуска планировщика заданий Scheduled Tasks нажимаем Start, Settings, Control Panel, Scheduled Tasks. Запускается мастер Add Scheduled Tasks. На первом экране нажимаем кнопку Next и далее — кнопку Browse. В окне Select program to Schedule выбираем файл сценария и нажимаем кнопку Open. В последующих окнах указываем выполнение задачи ежедневно, задаем начальное время, а также вводим домен, учетную запись, пароль и подтверждение пароля. В окне, приведенном на экране 1, устанавливаем флажок, чтобы открыть расширенные настройки задания, и указываем эти дополнительные параметры, если нужно, в следующем окне. В этом окне (см. экран 2) нажимаем кнопку Advanced и настраиваем повторение задачи каждый час в течение 23 часов (см. экран 3). На этом настройка первой задачи завершена.
|
| Экран 1. Открытие расширенных настроек задания |
|
| Экран 2. Настройка дополнительных параметров задания |
И не забудьте проследить, чтобы у учетной записи, под которой будет запускаться задача, были все права на нее.
Диагностика проблем
Сценарий logon_replic_monitor.bat (см. листинг 2) позволяет осуществлять диагностику проблем с репликацией и сообщает о них администраторам.
Сценарий должен находиться в общей папке на контроллере домена. У учетной записи, от имени которой будет запускаться сценарий, должны быть разрешения уровня Modify в файловой системе и каталоге общего доступа. Так как в сценарии в явном виде указан пароль учетной записи с административными правами, доступ к этой папке должен быть только у администраторов и у учетной записи, под которой будет запускаться сценарий.
Механизм работы сценария несложен. Как и ранее, создаем переменную file_name и присваиваем ей значение logon. Далее создаем файл %file_name%_rep_mon.log с путем dc01Scripts и направляем в него вывод команды echo (для форматирования). Если файл существует, то удаляем его, создаем новый файл и пишем в него. Дописываем в файл %file_name%_rep_mon.log текущую дату и время и снова для целей форматирования — вывод команды echo ().
Запускаем repadmin /showrepl и указываем домен, для которого хотим получить информацию о репликах domain.local, указываем имя и пароль учетной записи с помощью ключей /u:domain est /pw:Password. Дописываем в файл %file_name%_rep_mon.log вывод команды.
Снова делаем запрос dcdiag, вводим в /n:domain.local домен, указываем, что диагностируем репликацию /test:replications, назначаем имя и пароль учетной записи /u:domain est /p:Password. Дописываем в файл %file_name%_rep_mon.log вывод команды.
В операторе for /f «tokens=1-7» %%A задаем просмотр значений в файле с первого по седьмое включительно. Присваиваем значения переменным начиная с %%A.
Операнд in (dc01Scripts\%file_name%_rep_mon.log) указывает файл для анализа и его местоположение.
Операнд do — обязательная часть цикла, после которой указываются действия, которые нужно выполнить.
Если находим информацию об ошибке, то отправляем сообщение администраторам, после чего завершаем выполнение сценария:
if «%%F»==»failed,» ((net send Test «Error in Replication!» & net send dc01 «Error in Replication!» & goto exit))
Здесь я использовал группирование команд скобками, а также оператор их последовательного выполнения и символ последовательного выполнения «&». Важно помнить, что команда net send может отправлять сообщения не только пользователям, но и компьютерам (точнее, всем пользователям, зарегистрированным на компьютере в данный момент). Так, в приведенном далее примере первая команда net send отправляет сообщение пользователю Test, а вторая команда — всем авторизованным пользователям на компьютере dc01.
Если находим сообщение об ошибке, то отправляем сообщение администраторам, после чего завершаем выполнение сценария — if «%%E»==»error» ((net send Test «DCDiag: Error in Replication!» & net send dc01 «CDiag: Error in Replication!» & goto exit))). Здесь все аналогично предыдущему шагу, но используется переменная %%E, так как мы ищем другое слово ошибки, которое находится в пятой переменной.
Первые семь шагов аналогичны описанным в первом сценарии и не требуют дополнительных комментариев.
Обращаю внимание читателей, что в данном сценарии мы использовали авторизацию учетной записи с административными правами. Это сделано для правильного функционирования сценария при процедуре аутентификации администратора в домен. Без указания имени и пароля сценарий выполнит только запрос даты и времени.
В сценариях я использовал переход на метку EXIT, и вот почему. Дело в том, что даже небольшая сеть в случае ошибок репликации создает больше одной строчки с ошибками. Если не использовать EXIT, то при каждом проходе сценария администраторы будут получать сообщение и рабочий стол будет «завален» сообщениями об ошибках.
Создание задания на запуск второго сценария по расписанию аналогично процедуре для первого сценария, единственное отличие — необходимость указывать запуск каждые 10 или 15 минут вместо часа.
Команда FOR является весьма мощным средством и может использоваться достаточно продуктивно, с более полным описанием ее синтаксиса рекомендую ознакомиться на сайте компании Microsoft http://www.microsoft.com/technet/prodtechnol/ windowsserver2003/ru/library/ServerHelp/ и книгой Вильяма Р. Станека «Командная строка Windows. Справочник администратора».
Может возникнуть вопрос — а почему потребовалось два сценария? Предположим, мы добавили в сценарий replic_monitor.bat функцию анализа журналов. В 8.58 произошел сбой репликации, в 9.15 мы его устранили. В 10.00 сценарий запускается и снова выдает ошибку репликации, хотя на самом деле ее нет! Произойдет ложное срабатывание механизма анализа, так как журнал уже содержит сообщение об ошибке в 9.00. Можно перезаписывать журнал каждый раз после устранения ошибки, но тогда мы будем терять статистическую информацию. Можно реализовать функцию перемещения журналов предыдущего запуска сценария в отдельный файл, но это излишне загрузило бы сам сценарий.
Особенности репликации
Почему в сценариях использовалась двойная диагностика проблем репликации? Представим себе, что сценарий отработал команду
repadmin /showrepl domain.local
и сообщил об ошибке. Мы отправили сервер на перезагрузку либо он перезагрузился сам. Во время перезагрузки происходит очередной запуск сценария, и ошибка репликации уже не будет зафиксирована, а будет указано время последней удачной репликации. Так что проблема еще не решена, но с точки зрения сценария все в порядке. Использование запроса
dcdiag /n:domain.local /test:replications
и последующий анализ результатов позволяют установить выпавший из репликации сервер.
Отправка сообщений
Для реализации функции отправки сообщений необходимо использовать бесплатную утилиту Blat (ее можно загрузить с www.blat.net). Blat.exe необходимо скопировать в %Systemroot%System32. Тогда строки сценария с проверкой на ошибки и отправку сообщения примут вид, приведенный в листинге 4.
Подробную информацию о синтаксисе Blat можно найти в поставляемом с ним руководстве.
Аутентификации в домене
Сценарий logon_replic_monitor.bat будет посылать нам информацию только в случае регистрации в домене. Если администратор не зарегистрировался в домене, то он не получит сообщений об ошибке. Чтобы сократить время информирования об ошибках до минимума, использовался механизм групповых политик и сценарий logon_replic_monitor.bat был назначен на запуск при аутентификации администратора в домене (в том числе удаленно).
Чтобы создать нужную политику, запускаем оснастку Active Directiry Users and Computers и переходим в контейнер, к которому будем применять групповую политику. Следует нажать правую кнопку мыши и выбрать пункт Properties.
Далее необходимо перейти на вкладку Group Policy и нажать кнопку Open или Create, если оснастка запускается на контроллере домена, а не на рабочей станции администратора с установленным Adminpak.msi (который можно загрузить с сайта Microsoft).
Создаем новую политику и присваиваем ей понятное имя. Выделяем политику, нажимаем правую кнопку мыши и выбираем пункт Edit. Переходим на вкладку Scripts. Раскрываем узлы по пути User ConfigurationWindows SettingsScriptsLogon.
Щелкаем правой кнопкой мыши на logon и выбираем Properties. В открывшемся окне нажимаем кнопку Add и указываем путь к сценарию. Нажимаем ОК (см. экран 4).
|
| Экран 4. Указание сценария в политике |
Наша политика почти готова. Теперь нужно указать, как она должна взаимодействовать с вышестоящими групповыми политиками. Если этого не сделать, политика работать не будет. Для этого пройдем по пути Computer ConfigurationAdministrative TemplatesSystemGroup Policy. Теперь следует дважды щелкнуть на пункте User Group Policy Loopback Processing Mode (режим обработки замыкания пользовательской групповой политики, см. экран 5).
Установите значение Enabled и выберите режим Merge («Слияние»). Теперь закройте все оснастки. Создание групповой политики завершено.
Заключение
Использование таких сценариев позволяет значительно упростить жизнь администратора и избавляет его от необходимости выполнять мониторинг репликации. Данный комплекс находится в промышленной эксплуатации с момента написания и проблем с его функционированием не выявлено. Подобные функции мониторинга можно реализовать и с помощью утилиты Eventquery и анализа журнала File Replication Service.
Николай Андрианов - Системный администратор в компании «Вагонмаш», а также администратор ресурса www.amdclub.ru. С ним можно связаться по адресу slayer@amdclub.ru