Решения для виртуализации контроллеров домена (часть 5)

Введение

До сих пор мое обсуждение размещения контроллера домена в виртуальной

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

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

Кэширование записи на диск

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

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

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

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

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

Дополнительная мера предосторожности

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

Другие затронутые службы

Прежде чем я двинусь дальше, я просто хочу быстро отметить, что отложенные сбои записи и перебои в подаче электроэнергии могут нанести ущерб базе данных Active Directory, они также могут вызвать проблемы для других типов баз данных. Хотя вы, вероятно, предпринимаете шаги для защиты приложений, управляемых базой данных, таких как Exchange Server, легко забыть, что существует ряд внутренних служб Windows, которые используют базу данных Extensible Storage Engine и поэтому должны быть защищены от кэширования записи на диск и сбоев питания. Помимо базы данных Active Directory, некоторые из этих служб включают службу репликации файлов (FRS) и DHCP.

Злоупотребление программным обеспечением виртуализации

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

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

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

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

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

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

Вывод

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

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