Подготовка к отказам

🕛 21.01.2009, 20:43

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

Подготовка к бедствию включает просмотр всех элементов, составляющих нормальную сетевую инфраструктуру, а также некоторые спе
цифичные для Active Directory вещи. Перечисленные ниже процедуры являются критически важными.
* Разработайте последовательное создание резервной копии и восстановите управление контроллеров домена. Первый шаг в любом плане восстановления состоит в установке соответствующих аппаратных средств и программного обеспечения для поддержки создания резервных копий контроллеров домена. Затем вы должны создать и протестировать план резервирования и восстановления. * Проверьте свой план резервирования до и после развертывания Active Directory. После развертывания Active Directory ваши пользователи будут требовать, чтобы она была доступна все время. Нужно неоднократно протестировать свой план восстановления. Наилучшим образом управляемая сетевая среда имеет последовательную процедуру тестирования восстановления, в которой каждую неделю тестируется какой-либо компонент этой процедуры. Если бедствие действительно произойдет, вы будете вынуждены восстановить Active Directory настолько быстро, насколько это возможно. Это не должен быть тот случай, когда вы используете процедуру восстановления Active Directory в первый раз. * Разверните контроллеры домена Active Directory с аппаратной избыточностью. Большинство серверов можно заказывать с некоторым уровнем аппаратной избыточности при небольшой дополнительной стоимости. Например, сервер с двойным источником питания, избыточными сетевыми картами и избыточной аппаратной системой жесткого диска должен быть стандартным оборудованием для контроллеров домена. Если эта избыточность предохранит вас хотя бы от одной трудовой ночи по восстановлению контроллера домена, то это будет лучшая инвестиция, которую вы когда-либо делали. Во многих больших компаниях аппаратная избыточность поднята на такой уровень, когда все контроллеры домена связаны с различными цепями питания и подключены к различным коммутаторам Ethernet или сетевым сегментами * Во всех сетях, кроме самых маленьких, вы должны развернуть, по крайней мере, два контроллера домена. Active Directory использует циркулярную (circular) регистрацию для своих журналов регистрации событий, и этот заданный по умолчанию порядок не может быть изменен. Циркулярная регистрация означает, что с единственным контроллером домена вы можете потерять данные Active Directory в случае аварии на контроллере домена, и будете восстанавливать его из резервной копии. Даже в маленькой компании важно иметь несколько контроллеров домена. Если вы хотите, чтобы все пользователи большую часть времени использовали один контроллер домена, вы можете изменить записи DNS, регулируя приоритет каждого контроллера домена. Тогда второй контроллер домена может выполнять другие функции и использоваться только для создания резервной копии на случай аварии на первом контроллере домена.

Хранение данных в Active Directory

Как говорилось в гл. 2, база данных Active Directory хранится в файле по имени Ntds.dit, который по умолчанию расположен в папке %systemroot %\NTDS. Эта папка содержит также следующие файлы.
* Edb.chk - файл контрольных точек, который указывает, какие транзакции из журналов регистрации были записаны в базу данных Active Directory. * Edb.log - журнал регистрации текущих транзакций. Имеет фиксированную длину - 10 Мб. * Edbxxxxx.log. После того как Active Directory проработала некоторое время, могут появиться один или более журналов, у которых часть имени файла, обозначенная как ххххх, представляется собой увеличивающийся шестнадцатеричный порядковый номер. Эти журналы являются предшествующими журналами; всякий раз, когда текущий журнал заполнен, он переименовывается в следующий предшествующий журнал, и создается новый журнал Edb.log. Старые журналы автоматически удаляются по мере того, как изменения, представленные в журналах, переносятся в базу данных Active Directory. Каждый из этих журналов также занимает 10 Мб. * Edbtemp.log - временный журнал, который используется тогда, когда заполнен текущий журнал (Edb.log). Новый журнал создается под именем Edbtemp.log, в нем хранятся все транзакции, а затем журнал Edb.log переименовывается в следующий предшествующий журнал. Далее журнал Edbtemp.log переименовывается в журнал Edb.log. * Resl.log и Res2.log - резервные журналы, которые используются только в ситуации, когда на жестком диске заканчивается свободное пространство. Если текущий журнал заполнен, а сервер не может создать новый журнал, потому что на жестком диске нет свободного пространства, сервер подавит любые транзакции Active Directory, находящиеся в настоящее время в памяти, использует место для резервных журналов, а затем завершит работу Active Directory. Размер каждого из этих журналов также 10 Мб.

Совет. Если вы работали с какой-либо из недавних версий Microsoft Exchange Server, то это обсуждение компонентов и процессов базы данных Active Directory будет звучать для вас очень знакомым. База данных Active Directory - это та же самая база данных, которая развертывается с Exchange Server 4 или более поздними версиями.

Каждая модификация к базе данных Active Directory называется транзакцией. Транзакция может состоять из нескольких шагов. Например, когда пользователь перемещается из одной организационной единицы (OU) в другую, в OU-адресате должен быть создан новый объект, а в OU-источнике удален старый объект. Чтобы транзакция была закончена, оба шага должны быть выполнены, если один из шагов потерпит неудачу, вся транзакция должна получить откат, чтобы никакой шаг не был засчитан. Когда все шаги в транзакции выполнены, транзакция считается законченной. Используя модель транзакций, система Windows Server 2003 гарантирует, что база данных всегда остается в согласованном состоянии.

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

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

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

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

Эти преимущества максимальны, если журнал транзакций и база данных расположены на отдельных жестких дисках.

Служба Active Directory Windows Server 2003 сконфигурирована для циркулярной (circular) регистрации, и эта конфигурация не может быть изменена. При циркулярной регистрации сохраняются только те предшествующие журналы, содержащие транзакции, которые не были переписаны в базу данных. По мере передачи информации из предшествующего журнала в базу данных журнал удаляется. Циркулярная регистрация предотвращает потерю данных в случае сбоя на жестком диске вашего контроллера домена, когда вы будете восстанавливать базу данных из резервной копии. Предположим, что вы выполняете резервное копирование Active Directory каждую ночь, но жесткий диск вашего контроллера домена сломался в 17:00, после того как вы сделали несколько сотен изменений к базе данных в течение дня. По мере выполнения изменений предшествующие журналы транзакций удалялись, поскольку информация из них передавалась в базу данных Active Directory. Когда вы восстановите базу данных к состоянию, соответствующее резервной копии предыдущей ночи, все изменения, которые вы сделали в течение дня, будут потеряны.

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