Создание очень большого хранилища Active Directory
Как известно, в Windows NT расширяемость домена является узким местом, на практике она ограничена пределом в размере базы SAM - не более 40 000 учетных записей пользователей в одном домене. В ряде компаний администраторы пробовали превысить данное ограничение на SAM и построить очень большие домены. Но оказалось, что этими доменами трудно управлять. Чтобы обойти ограничения на SAM, зачастую приходилось создавать слишком много доменов для размещения всех учетных записей.
Операционная система Windows 2000 основана на Active Directory (AD), хранилище учетных записей пользователей и объектов многочисленных типов. Служба AD - более расширяемая, чем SAM. Но вот насколько? Какое количество объектов можно хранить в одном домене? Как велики и насколько управляемы базы данных? Какова производительность такой AD?
Чтобы это выяснить, мы создали очень большую базу данных AD. Ее возможности демонстрировались на выставке Comdex в Лас-Вегасе в ноябре 1999 года и на презентации Windows 2000 в Сан-Франциско в феврале 2000 года. Как показали тесты, база данных может поддерживать 100 миллионов записей в реальной производственной обстановке. Мы расскажем, как создавалась демонстрационная база данных, и поделимся опытом, который приобрели в процессе строительства AD. Но сначала давайте рассмотрим некоторые основы AD.
ОСНОВЫ БАЗЫ ДАННЫХ AD
База данных службы AD - это транзакционная база данных, и основным ее свойством является упреждающая регистрирующая модель, которая использует процессор базы данных Microsoft Extensible Storage Engine 97 (ESE97). Information Store (IS) и Directory Store из Microsoft Exchange Server 5.5 также используют ESE97. Хотя существуют небольшие отличия между версиями ESE97 в Exchange Server и AD, опыт, полученный администраторами за годы работы с Exchange, очень пригодится при управлении службой AD. Программа Exchange 2000 Server использует новейшую версию ESE, ESE98, поддерживающую разделение баз данных и потоковый файл для хранения Internet-контента. В настоящее время AD не нуждается в разделении баз данных и хранит только данные в виде записей, потому и не использует ESE98.
Мы многому научились, работая с технологией ESE. Мы знаем, что она расширяема, поскольку многие серверы Exchange 5.5 поддерживают базы данных объемом более 100 Гбайт. База данных может увеличиваться в объеме без снижения производительности, если администраторы внимательно следят за нагрузкой при чтении-записи. Очень важно, что ESE может бороться с отказами аппаратных средств с помощью программного или аппаратного восстановления данных из журналов транзакций. При программном восстановлении системе не хватает интеллекта, но все равно нет необходимости восстанавливать файл базы данных AD из резервной копии. Для аппаратного восстановления, которое обычно требуется при неисправностях жесткого диска, необходимо восстановление базы данных AD из резервной копии.
На Рисунке 1 изображена схема архитектуры AD. Доступ к AD обеспечивается через различные клиентские интерфейсы. Такие клиенты как Microsoft Outlook 2000 используют Messaging API (MAPI), тогда как стандартное средство Windows 2000 Find Users работает с Lightweight Directory Access Protocol (LDAP). Такие программы как ADSIEDIT (сервисная программа из Microsoft Windows 2000 Resource Kit, которая позволяет изучать информацию об объектах AD) используют Active Directory Service Interfaces (ADSI) как свой основной программный интерфейс.
Агент службы каталога (DSA) управляет транзакциями и обращается через уровень базы данных к ESE. Уровни DSA и базы данных представляют схему и функции AD; ESE отвечает за управление информацией только внутри базы данных. Уровень базы данных отвечает за передачу данных из DSA и их преобразование в формат, понятный ESE. Файлы на диске - это ntds.dit, который является базой данных AD; набор журналов транзакций; файл контрольных точек, в котором фиксируются последние подтвержденные операции записи из буфера; временный файл базы данных. Эти файлы похожи на dir.edb (ESE97-совместимая база данных, которую использует Directory Store в Exchange 5.5) и соответствующие ему журналы транзакций и файл контрольных точек.
На Экране 2 показаны некоторые файлы, которые мы использовали при демонстрации расширяемости AD. Обратите внимание на объем базы данных (ntds.dit), содержащей 100 миллионов объектов. Также заметьте, что журналы транзакции имеют размер 10 Мбайт. В отличие от Exchange, где величина журналов транзакций составляет 5 Мбайт. Это различие вытекает из размера записей в базе данных. Exchange использует записи по 4 Кбайт, а AD использует записи по 8 Кбайт. Это связано с тем, что AD хранит объем информации для средней учетной записи пользователя, который составляет более 4 Кбайт. Компания Microsoft могла установить размер записи для AD объемом 4 Кбайт, но в результате это привело бы к переполнению страниц и ухудшило внутреннюю структуру базы данных. Большие записи предполагают, что каждая транзакция может собрать больше данных, поэтому разработчики Microsoft увеличили размер файла журнала.
ОБРАЗЦЫ ЧТЕНИЯ-ЗАПИСИ И ЖУРНАЛЫ ТРАНЗАКЦИЙ
Практика показывает, что от 70 до 90% всех операций, выполняемых службой AD, составляют операции чтения из файла ntds.dit. Это неудивительно, поскольку основная функция AD - аутентификация пользователя - требует сверки паролей, содержащихся в AD, с введенными пользователем данными. Даже такие приложения, как Exchange 2000, которые размещают информацию в AD, производят больше операций чтения, чем записи.
Доступ к файлу ntds.dit - многопоточный и асинхронный. Другими словами, в одно и то же время несколько потоков обслуживают запросы от разных клиентов и приложений. Операции записи передают контроль ESE сразу после завершения, но ESE некоторое время находится в режиме ожидания, прежде чем применить обновления к базе данных.
Система читает файлы журналов только при программной или аппаратной операциях восстановления, когда она должна повторить транзакции. Эти операции записи являются однопоточными и синхронными. Один поток управляет всеми операциями записи, что означает, что в данный момент может совершаться только одна операция записи. Вызывающий поток должен находиться в режиме ожидания до полного завершения записи перед возобновлением исполнения потока. Служба AD имеет последовательный доступ к системному журналу и добавляет данные в конец текущего журнала.
Когда объект AD добавляется, изменяется или удаляется, процессор базы данных вначале записывает транзакцию в набор буферов, формируя кэш в памяти, затем незамедлительно фиксирует транзакцию в текущем журнале транзакций (edb.log). Когда обе операции закончены, система считает транзакцию подтвержденной. Эта операция гарантирует, что данные могут быть восстановлены, перед тем, как система сделает попытку записать их в файл ntds.dit.
Программа Lsass.exe (Local Security Authority-LSA-процесс) контролирует все транзакции в AD. Когда нагрузка на систему позволяет это сделать, программа lsass.exe проверяет кэш- память на наличие несохраненных страниц, сохраняет эти страницы в базе данных и переводит указатель контрольной точки, когда система записывает данные из буферов. В случае полного отказа системы или повреждения диска с этой точки можно восстановить данные из журналов транзакций.
Для записи в базу данных и журналы транзакций AD использует те же принципы, что и Exchange. Подобно Exchange, служба AD поддерживает журналы с перезаписью и без нее. В режиме перезаписи система использует 20 журналов транзакций для фиксации транзакций, циклически меняя их. В режиме без перезаписи Exchange поддерживает полный набор журналов транзакций вплоть до момента удаления всего набора после успешного полного резервирования (желательно выполнять резервирование ежедневно). Но AD автоматически очищает журналы транзакций каждые 12 часов, чего нет в Exchange.
ЗАГРУЖАЕМЫЕ ОБЪЕКТЫ
AD содержит организационные единицы (OU), в которых помещены объекты. Каждый объект имеет отличительное имя (distinguished name - DN), которое соответствует полностью определенному представлению объекта в соглашениях LDAP. Имя DN формируется из набора относительных отличительных имен (relative distinguished name - RDN); все вместе RDN объекта описывают позиции объекта в иерархии каталога.
При тестировании масштабируемости AD потребовалось найти большой объем данных для загрузки в базу. Мы могли написать программу, создающую 100 миллионов имен и адресов, но при использовании реальных данных нагрузка была бы иной. Кроме того, можно было бы использовать реальные данные для других целей. Мы приобрели комплект из семи компакт-дисков, содержащих телефонные номера США по штатам в виде архивных файлов, из infoUSA.com. Очевидно, что невозможно было сразу ввести необработанные файлы в базу каталога AD, поэтому мы написали программу, считывающую данные и создающую файлы для загрузки в формате LDAP Data Interchange Format (LDIF).
Файлы LDIF представляют собой простые текстовые файлы. Они содержат команды вставки, обновления или удаления записи в базе данных, поддерживающей LDAP. Мы создали отдельный LDIF-файл для каждого штата. Первая команда в файле создает OU для записи. Например, следующая команда создает OU для штата New Hampshire:
# Create the OU
dn: OU=NH, DC=USA, DC=Compaq,
DC=com
changetype: add
objectClass: organizationalUnit
Последовательность команды в файле создает объект в AD для каждого телефонного номера. Далее считывается ограниченный набор атрибутов из входного файла и помещается в AD. Также выполняется обработка данных для создания уникальных DN для каждого объекта в OU, и исключаются записи без телефонных номеров. В Листинге 1 показана команда LDIF, добавляющая типичный объект <контакт>.
После создания файлов LDIF мы использовали утилиту LDIFDE для их загрузки в AD. LDIFDE входит в resource kit и может импортировать данные и экспортировать их из любого LDAP-совместимого каталога, включая AD. Мы использовали следующие команды для импорта данных штата New Hampshire:
C: > LDIFDE -k -y -i -f NH.LDF
Переключатели предписывают LDIFDE игнорировать ошибочные сообщения, предупреждающие о том, что объект уже введен (-k), использовать отложенное подтверждение при записи в AD (-y), импортировать данные (-i) из указанного файла импорта nh.ldf (-f). При отложенном подтверждении LDIFDE загружает данные в память, затем продолжает работу, не получив подтверждения, что процессор базы данных записал их на диск. Подтверждение записи данных производится позже, когда нагрузка на систему позволяет это сделать.
Такая задержка допустима, если предусмотрено размещение журналов транзакций изолированно от базы данных для защиты данных, и если на контроллере имеется запоминающее устройство кэша с обратной записью и батарейной поддержкой. Пока мы загружали данные для демонстрации AD на выставке Comdex, произошло полное отключение электричества. Когда питание восстановили, контроллер запоминающего устройства передал системе данные, удерживаемые кэш памятью, защищенной батареей, и загрузка продолжилась без потери транзакций.
Обработка и загрузка каждого файла LDIF с данными штата занимала у нас от одного до восьми часов, в зависимости от объема данных. Поэтому мы создали программу на языке Visual Basic (VB) для сканирования каталога, в котором формировались файлы LDIF, и загружали их последовательно по мере доступности. Так как многие записи не имели телефонных номеров, мы загрузили два штата (Texas и California) повторно, добившись магического числа 100 миллионов записей. Полный процесс загрузки занял целых три недели, но в течение этого периода мы производили загрузку непостоянно. Некоторое время мы занимались настройкой программы загрузки и другими задачами.
Записи с телефонными номерами на компакт-дисках InfoUSA.com сгруппированы по штатам, и мы загрузили каждый штат в его собственный OU. Мы разделили штаты на округа или города и использовали отдельные OU для каждого округа или города. Схематичность структуры OU не мешала эффективному поиску, поэтому поиск по фамилии обычно занимал меньше секунды, если только не задавать поиск такой распространенной фамилии как Smith без дополнительного критерия. На Экране 3 показаны результаты поиска для редко встречающейся фамилии (Capellas) в штате Texas. Как можно увидеть, в AD нашлось три записи (из 5 965 164 записей телефонных номеров для штата Texas). Скорость и эффективность поисков подтверждает возможности процессора базы данных ESE. Вы можете сами выполнить поиск в нашей базе данных. Чтобы узнать, как это сделать, посмотрите вкладку <Демонстрация>.
OU предназначены для разделения данных в AD на управляемые <порции>. Загружать более 10 000 объектов в один OU - не лучший вариант. Производительность работы стандартного инструмента управления, такого, как оснастка AD Users and Computers консоли Microsoft Management Console (MMC), значительно снижается, когда этот инструмент используется для выборки большого количества данных и при раскрытом контейнере OU. По умолчанию, эта оснастка MMC делает выборку 2000 записей в момент раскрытия OU. Можно установить режим выборки большего количества записей, но это будет замедлять скорость работы. Лучше разработать структуру OU таким образом, чтобы каждый контейнер OU содержал как можно меньше объектов. Например, наш каталог AD с телефонными номерами США действовал бы более эффективно, если бы мы определили OU для каждого округа в штате и затем разбили некоторые большие округа на части.
Каждый телефонный номер представляется в AD как отдельный объект <контакт>. Контакт меньше по размеру, чем объект <пользователь>, потому что он не входит в число объектов, которые Windows 2000 защищает. Мы могли создать и объект <пользователь>, а не объект <контакт>, но не сделали этого потому, что с ним загрузка происходила бы медленнее. Итоговая база данных все равно получилась больше (может быть, вдвое), но поиск в ней занимает столько же времени, так как служба AD эффективно использует индексы, если применяются такие атрибуты поиска, как фамилия.
РЕПЛИКАЦИЯ
Служба AD реплицирует информацию между контроллерами доменов для поддержания информации в каталоге в согласованном состоянии. Точный режим согласования зависит от того, как часто контроллеры домена выполняют репликацию, сколько контроллеров домена вовлечены в этот процесс и от количества внесенных в данные изменений. При формировании очень большой базы каталога на сервере существует высокая вероятность отказов, поэтому необходимо добавить в конфигурацию второй сервер.
Используя процедуру Dcpromo, мы назначаем сервер Windows 2000 контроллером домена. Процесс репликации производит полное копирование информации из AD в новый контроллер домена. С помощью этой программы можно создавать новые объекты с производительностью чуть больше чем 130 объектов в секунду или около 500 тысяч объектов в час; однако процесс репликации выполняется намного медленнее, приблизительно 30 объектов в секунду. Вероятно, это происходит потому, что механизм удаленного вызова процедур (RPC) посылает каждый объект отдельно с существующего контроллера домена на вновь появившийся сервер. Величина пакета репликации по умолчанию составляет приблизительно 900 объектов. Можно увеличить величину пакета для отправки большего количества объектов за единицу времени, но при этом увеличится объем памяти, занимаемой этим процессом. Как показано на Экране 4, преобразование сервера в контроллер домена в домене, который имеет очень большую базу AD, приводит к переносу большого числа данных, что занимает много времени. В нашем случае репликация завершилась через 7 дней. Скорее всего, обычной системе Windows 2000 не потребуется реплицировать такие объемы данных, и все же механизм репликаций, очевидно, заслуживает особого внимания компании Microsoft, продолжающей усовершенствовать службу AD.
АППАРАТНЫЕ ТРЕБОВАНИЯ
Фактически контроллеры домена NT требуют обычной конфигурации. Некоторые контроллеры доменов строятся на старых 486 системах, оснащенных 64 Мбайтами оперативной памяти и жесткими дисками небольших объемов. Эта конфигурация достаточна для обеспечения работы службы аутентификации небольших доменов. Контроллеры доменов системы Windows 2000 также аутентифицируют клиента при доступе, но механизм репликаций AD и транзакционная природа базы данных требуют более мощной аппаратной конфигурации. К счастью, при хорошо спроектированной сети Windows 2000 контроллеров домена требуется намного меньше, чем в сети Windows NT.
Некоторые приложения Windows 2000 создают специальные запросы к AD. Например, Exchange 2000 хранит всю свою информацию о почтовых ящиках, хранилищах и соединениях в AD, и ему нужен доступ к серверу глобального каталога (Global Catalog -GC), чтобы обеспечить клиентов списком Global Address List (GAL) и отправлять сообщения. Следовательно, при проектировании сети Windows 2000, включающей в себя Exchange 2000, необходимо установить GC так, чтобы все серверы Exchange 2000 могли легко соединяться с одним GC.
Контроллерам домена системы Windows 2000 и GC необходима такая же аппаратная конфигурация, как для серверов Exchange 2000 или Exchange 5.5. Для больших доменов типичный контроллер домена должен иметь два процессора, 256 Мбайт оперативной памяти, массив RAID 1 для журналов регистрации AD и массив RAID 5 для базы данных AD. Врезка
Конфигурация контроллера домена, которую мы описали, это только основа - исполняемые файлы Windows 2000 и файлы других приложений требуют использования дополнительных накопителей уровня RAID 0+1 (т.е. чередование с зеркальным отображением), что обеспечивает лучшую производительность ввода-вывода и соответствует серверу, поддерживающему объемную базу данных, которую предполагается интенсивно использовать (например, для GC, обслуживающего несколько больших серверов Exchange 2000).
Помните, что Exchange 2000 зависит от GC. Он обеспечивает клиентов адресной книгой GAL и определяет выбор каждого маршрута, по которому необходимо передавать сообщения пользователям. GC - это источник информации о том, какой сервер хранит почтовый ящик данного пользователя, а процедуре маршрутизации Exchange 2000 нужен доступ к GC для определения оптимального варианта отправки каждого сообщения. Эффективное использование кэш-памяти для выборки последней информации об адресах позволяет уменьшить воздействие на производительность поиска по GC. Но использование кэш-памяти не может компенсировать недостаточную мощность системы.
Большинство администраторов систем Windows 2000 при работе со службами AD не сталкиваются с такими объемными базами данных, как та, которую мы тестировали. Тем не менее, усиление конкуренции между поставщиками услуг (ASP) приведет к созданию служб, основанных на AD и поддерживающих такие приложения как Exchange 2000. В дальнейшем им явно понадобятся возможности для строительства и управления каталогами, которые будут включать в себя миллионы объектов. Наша расширяемая демонстрационная версия AD продемонстрировала, как служба AD может управлять миллионами объектов и в то же время показывать хорошую производительность, конечно, при хорошем планировании и использовании подходящих аппаратных средств.
A WEB DEMO
Действия значат больше слов, и тестирование очень большой Active Directory (AD) само по себе есть хороший путь оценить расширяемость каталога. Вы можете поискать телефонный номер в базе данных по адресу http://demo.esc.compaq.com/phonebook, этот сайт использует протокол Lightweight Directory Access Protocol (LDAP), активизирующий поиск через Active Server Pages (ASP) в службе AD. Модифицированная версия программы загрузки группирует данные телефонных номеров штата, затем группирует данные города и создает лучшие модели организационных единиц (OU), чем та, которая использовалась для оригинального теста. Это быстрый поиск, который может провести 8-процессорный сервер. В результате поиска для
АППАРАТНАЯ КОНФИГУРАЦИЯ ДЛЯ ТЕСТА AD
Компьютер Compaq ProLiant с восемью 550-мегагерцевыми процессорами Pentium III Xeon, 2 Мбайт кэш, и 2 Гбайта оперативной памяти 100 МГц Error-Correcting Code (ECC) SDRAM DIMM
Compaq StorageWorks ESA12000 - контроллер накопителя с четырьмя подсистемами ввода-вывода, каждая защищена энергонезависимой зеркальной ECC кэш-памятью объемом 1 Гбайт с обратной записью и батарейной поддержкой;
48 жестких дисков объемом по 18 Гбайт с интерфейсом Ultra SCSI.
Тони Редмонд - Редактор Windows 2000 Magazine, старший технический редактор выпусков Exchange Administrator, вице-президент и главный технолог в Compaq Global Services, автор
Мики Баладелли - Старший технический консультант службы применения технологий Microsoft компании Compaq. С ним можно связаться по адресу: micky.balladelli@compaq.com.