Недавно мы наблюдали интересную серию сбоев в нашем кластере, когда задания пользователей периодически прекращались с ошибками входа в систему, ошибками блокировки учетной записи или ошибками доступа к файлам.
Наш кластер представляет собой слабосвязанный и крупнозернистый кластер, состоящий из 40 компьютеров с 16-процессорной системой Windows 2003. Они участвуют в корпоративном домене с контроллерами домена локально и в глобальной сети. Отправка заданий осуществляется через стороннее приложение (ActiveBatch), а файловое хранилище делится между SAN, экспортированным сервером Windows 2003, и новым общим ресурсом CIFS в кластере Isilon.
Задания представляют собой ориентированные ациклические графы, состоящие из 1-5 000 процессов, запланированных на головном узле с помощью ActiveBatch. Большинство заданий представляют собой крошечные командные файлы или сценарии Perl, которые выполняют настройку среды для вычислительных кодов, написанных на FORTRAN. Файлы ввода и вывода для этих заданий хранятся либо в SAN, либо в Isilon.
То, что мы наблюдаем, - это периодические сбои при аутентификации, которые изначально считались изолированными на Isilon. Общий режим отказа: 100-200 заданий начнут выполнение, каждое из которых ссылается на общие данные конфигурации в файле. Большинство из них будут успешными, однако несколько заданий на нескольких машинах завершатся сбоем на стороне клиента с ошибкой прав доступа к файлу (либо 0x775 "Указанная учетная запись в настоящее время заблокирована ..." или 0x52E "неизвестное имя пользователя или неверный пароль").
Проверка журналов событий для этих периодов времени сообщает о 0 сбоях аудита безопасности, но нескольких успешных результатах аудита безопасности для одного и того же пользователя! Единственная запись в журнале событий в непосредственной близости - это событие 6013, сообщающее нам: «Время работы системы составляет 2199088 секунд».
Недавно мы также наблюдали ту же ошибку, когда программное обеспечение для планирования заданий пытается создать задания на удаленных машинах. ActiveBatch отправит сведения о задании службе, работающей на машине, которая затем попытается выдать себя за пользователя при создании задания. Как и в случае с ошибками прав доступа к файлам, мы наблюдаем как блокировку учетной записи, так и неизвестный пользователь / пароль, когда учетная запись пользователя не заблокирована и не неизвестна (и фактически процессы на одном компьютере завершились успешно вскоре после этих неудачных попыток).
Я недостаточно знаком с контроллерами домена и не имею достаточного доступа для изучения, чтобы знать, является ли это проблемой на стороне клиента или проблемой на стороне сервера. Отсутствие записей о сбоях в журнале событий на стороне клиента заставляет меня думать, что сбой, возможно, вызван тайм-аутом контроллера домена или проблемой сети. Однако опрос Wireshark трафика между случайным сервером и контроллером домена не выявил каких-либо серьезных несоответствий, кроме случайных сообщений Kerberos Response Too Big.
Это обычная проблема с настройками контроллера домена, когда высокая нагрузка на аутентификацию / олицетворение вызывает временные сбои?
Это не является обычным явлением, если только что-то не вызывает сбой, который может привести к блокировке.
Включение ведения подробного журнала Netlogon может помочь отследить его.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"DBFlag"=dword:24401F04
Созданные файлы:% systemroot% \ debug \ netlogon.log и netlogon.bak.
Они могут быстро переноситься в среду с большим объемом, поэтому вам может потребоваться увеличить размер файлов, который по умолчанию составляет 20 МБ. Чтобы увеличить его до 50 МБ:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"MaximumLogFileSize"=dword:3200000
Включение ведения журнала отладки для службы сетевого входа
http://support.microsoft.com/kb/109626