Назад | Перейти на главную страницу

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

У меня есть контроллер домена Windows Server 2008 R2, работающий на физическом сервере Dell, модель PowerEdge R510.

Здесь есть некоторые проблемы с электричеством, поэтому отключение электричества, к сожалению, довольно частое явление; Есть ИБП, но они не так надежны, как должны быть, и иногда серверы будут некорректно отключаться.

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

В этом нет никакого смысла, поскольку сервер является физическим и на нем никогда не выполнялись снимки, клонирование и / или восстановление; также на нем не устанавливается никакого дополнительного программного обеспечения, он выполняет только функции DC; в частности, отсутствует клонирование / восстановление / какое-либо программное обеспечение.

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

В чем может быть причина этой проблемы?

Сегодня я думал об этом несколько часов. Это немного сбивает с толку, но, как я указал в своем комментарии, я могу предположить, что у вас либо происходит какое-то кеширование диска, которое не фиксируется на диске до тех пор, пока отключение питания / грязное завершение работы не уничтожит содержимое кеша ... Или, поскольку вы работаете на томе RAID, на котором размещен ntds.dit, отключение питания может привести к временному выходу из строя вашего тома RAID или его несогласованности, хотя бы на мгновение.

Мы знаем, что партия отката USN - это когда DC восстанавливается до состояния, которое было раньше, классическим примером является восстановление виртуализированного DC из моментального снимка. Я знаю, что это не относится к вам точно ... но даже в случае диска с кешем записи вы можете думать о данных, которые физически находятся на диске, как о содержащих "предыдущее состояние", в то время как кэш записи это то, что на самом деле содержит самое актуальное состояние DC ... даже если два состояния находятся всего в полсекунды.

Поразмышляйте над этими комментариями Microsoft:

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

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

Я знаю, что ваш DC не виртуальная машина, но концепция все еще применима. Кэширование диска и контроллеры домена не смешиваются. Вот почему установка Active Directory отключает кэширование записи в качестве политики Windows, но вы все равно можете иметь механизмы кэширования в своем аппаратном RAID-контроллере и т. Д.

Сценарий Б. Запуск Active Directory с других дисков в сломанном зеркале

  1. Продвигайте контроллер домена. Найдите файл Ntds.dit на зеркальном диске.

  2. Разбейте зеркало.

  3. Продолжайте входящую и исходящую репликацию, используя файл Ntds.dit на первом диске в зеркале.

  4. Запустите контроллер домена с помощью файла Ntds.dit на втором диске в зеркале.

Это убийца репликации, который меня сильно укусил на физических контроллерах домена с томами RAID 1. У меня лично никогда не было реального отката USN, вызванного этим, но это убьет репликацию на этом DC. Я имею в виду, представьте себе RAID 1 том из 2 дисков. 1 диск умирает. Вы удаляете его, вставляете новый диск ... aaaaaa и DSA Not Writable.

Из Блог AskDS:

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

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

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