Ольга Андреева MCSE, Master CNE
Сергей Полехин MCT, Master CNI
В предыдущей публикации (╚КИ╩/21/1999) мы рассмотрели некоторые различия между двумя каталогами: Novell Directory Services (NDS) и Microsoft Active Directory (MAD). В этой статье мы сравнили принципы, применяющиеся в службах каталогов для эффективного представления и централизованного управления информацией обо всех ресурсах и сервисах сети (организационных единицах ≈ OU, правах доступа и способах управления объектами каталогов). Но, ввиду отсутствия места, не рассматривались внутренние механизмы функционирования каталога, обеспечивающие необходимый уровень быстродействия, надежности и стоимости предоставления информации о сетевых ресурсах конечным пользователям, приложениям и администраторам. Настоящая статья как раз и посвящена вопросам внутреннего функционирования Novell Direc-tory Services и Microsoft Active Directory с точки зрения эффективности управления всей БД каталога.
Физически информация, представляемая пользователю или администратору в виде объектов каталога NDS или MAD хранится в БД. БД размещается в защищенной области тома на одном или нескольких серверах сети. Первое различие в принципах хранения БД состоит в том, что в NDS каждый из серверов в любой момент времени, независимо от способа установки, потенциально может хранить и обслуживать БД каталога. Для этого администратору достаточно лишь указать сервер, на котором будет находиться БД. В Windows NT 4.0 (Directory Services Windows NT 4.0) для установки сервиса хранения БД каталога требовалось полностью переустановить сервер со всем ПО, если у администратора возникало желание на ранее установленном сервере разместить БД Directory Services. В MAD (Windows 2000) фирма Microsoft модифицировала принципы хранения БД, и теперь механизмы хранения представлены уже в виде отдельного сервиса, устанавливаемого администратором на выбранный сервер в любой момент времени. Таким образом, MAD по сравнению с Directory Services Windows NT 4.0, стала более удобной. Более подробно рассмотрим внутренние механизмы работы NDS и MAD, так как именно они определяют степень управляемости и надежности сети!
Понятие раздела непосредственно связано с функцией масштабирования каталога. Поэтому вести речь о разделах каталога совершенно бессмысленно для небольших компаний, использующих локальные высокоскоростные сети (LAN) (минимум 10Mб/c), состоящие из одного ≈ двух серверов и обслуживающие 50-150 пользователей при условии, что все пользователи размещаются в одном офисе. Поэтому принципы выделения разделов каталога рассмотрим на более сложном примере:
предположим, сеть некоторой компании ⌠Pictures_Inc■ объединяет ~30 тыс. пользователей и информационные сервисы нескольких филиалов в трех различных городах страны: Санкт-Петербурге, Москве и Екатеринбурге. При этом в каждом из филиалов пользователи работают с приложениями, принтерами и другими сервисами, размещенными на серверах своего филиала. Изредка пользователям необходимо работать с документами, хранящимися в другом филиале.
Средства и NDS и MAD позволяют описать ресурсы этой организации в виде объектов:
Информация о представленных в каталоге ресурсах, как мы указывали выше, физически может быть расположена на выбранных администратором серверах. И при создании дерева каталога инженер обязан очень строго подойти к вопросам планирования такого размещения. Например, пусть все города нашей организации связаны между собой быстрыми каналами связи (~10 Mбит/c). БД каталога расположим на одном сервере в Санкт-Петербурге (предположим, здесь размещаются главные администраторы сети). В этом случае доступ к ресурсам всей сети будет обеспечиваться с достаточной скоростью для пользователей из любого филиала ≈ по таким каналам связи они без проблем смогут обратиться к БД, которая физически расположена в Санкт-Петербурге. А что будет, если представить более реальную ситуацию: города связаны между собой медленными каналами связи (
Для таких случаев и NDS и MAD обладают механизмами, дающими возможность хранить БД каталога в распределенном виде. И вот тут начинается самое интересное! И в NDS и в MAD администратор имеет возможности для размещения копий БД каталога ≈ реплик на нескольких серверах сети. В этом случае, пользователи будут обращаться за искомой информацией к БД каталога, размещенной на ближайшем сервере, не загружая при этом медленные каналы связи. Но ничего не бывает бесплатным, и при размещении реплик на нескольких серверах начинают работать механизмы репликации, обеспечивающие полное соответствие информации об объектах каталога в БД различных серверов. Безусловно, такие действия приводят к возникновению служебного трафика в сети. Размер этого трафика напрямую зависит от количества изменяемых в сети объектов или их свойств.
Перед администратором, проектирующим такую сеть, стоит важная задача ≈ максимально снизить объем служебного трафика в медленных каналах связи, ведь ни для кого не является секретом, что аренда таких каналов ≈ одна из наиболее весомых статей расходов на сетевую инфраструктуру. Какие же средства предоставляют для этого NDS и MAD?
В MAD БД каталога непосредственно связана с понятием домена. Иначе говоря, размер раздела в MAD равен размеру домена. Этот подход приводит к тому, что при желании размещения реплик БД каталога на нескольких серверах, механизмы репликации MAD будут вынуждены синхронизировать информацию всего домена целиком независимо от количества описанных в нем объектов. Вторым недостатком такого подхода является необходимость использования серверов одинаковой производительности. Это требование проистекает из того, что все серверы, хранящие реплики MAD (доменные контроллеры), вынуждены хранить одинаковую для всех серверов БД домена. К примеру, если в нашей организации Pictures_Inc в Москве и Санкт-Петербурге работает по 10-15 тыс. пользователей соответствующими им ресурсами, а в Екатеринбурге ≈ 100 человек, то возникнет очень интересная ситуация. Если администратор пожелает разместить реплики каталога на серверах всех городов, то в Екатеринбурге он будет обязан использовать сервер не меньшей производительности, чем в Москве или Санкт-Петербурге! А зачем филиалу в 100 человек столь же мощный сервер?
Следует отметить, что фирма Microsoft в таком случае рекомендует представлять ресурсы организации не в виде нескольких организационных единиц внутри одного домена, а нескольких доменов, объединенных в дерево. В этом случае серверы каждого из филиалов будут хранить информацию только о ресурсах этого филиала (рис.2).
Но в этом случае мы получим знакомую до боли картинку доверительных отношений между доменами Windows NT 4.0. Разработчики фирмы Microsoft постарались упростить управление доверительными отношениями в MAD (Windows 2000), но настолько ли это стало простым? Доверительные отношения стали транзитивными, вся структура дерева доменов полностью привязана к сервису именования DNS (Domain Name Services). В итоге, говорить об упрощении управления большой сетью с использованием такого механизма вообще не приходится! Более того, сохранились все те же ограничения доменов Windows NT 4.0 в области управления ресурсами, например, при необходимости переноса информации об объекте пользователя из одного филиала в другой, его объект, по-прежнему, придется в одном домене полностью удалить, а затем в другом ≈ создать! А если при этом у него было ~ 70 различных свойств?
Какие же решения по организации сложной распределенной сети предлагает NDS? Во-первых, раздел в NDS может быть сформирован на основе любой части дерева каталогов. Единственное требование ≈ эта часть должна начинаться с какого-либо контейнера (рис. 3).
Информация, представленная каждым из разделов, физически в виде реплик может быть расположена на любом количестве серверов в любых комбинациях. Например, для нашей организации Pictures_Inc реплика разделов [Root] и ORG=Pictures_Inc может быть размещена на серверах Санкт-Петербурга (поближе к главным администраторам). Реплики разделов OU=Ekt и OU=Msk можно разместить на серверах городов Екатеринбурга и Москвы соответственно. Таким образом, оказываются решенными сразу несколько описанных ранее проблем:
1. Информацию о дереве каталогов можно хранить в распределенном виде и на конкретных серверах только в том объеме, который необходим для пользователей и администраторов конкретного филиала. Т.е. вы получите возможность неограниченного масштабирования NDS с использованием имеющейся аппаратуры серверов (производительность сервера подбирается под нужды конкретного филиала);
2. Трафик репликации по медленным каналам сводится к нулю, т.к. серверы каждого из городов хранят информацию только о своей части дерева;
3. Администратор имеет возможность свободного размещения реплик любых разделов по любым выбранным им серверам для повышения надежности работы каталога за счет хранения избыточных копий БД. Свободное размещение реплик предоставляет еще одну возможность оптимизации работы каталога: по мере необходимости администратор может размещать на физически расположенных рядом с пользователями серверах реплики тех разделов дерева каталогов, которые хранят информацию о наиболее часто используемых объектах NDS.
Такое размещение приводит к уменьшению сетевого трафика, связанного с поиском и доступом к объектам NDS.
Продуманность фирмой Novell реализованных в NDS технологий репликации дает возможность выполнять оптимизацию сетевого трафика еще одним способом: путем использования различных типов реплик: Master (мастер-реплика), Read/Write (реплика чтения/записи), Read-only (реплика только для чтения).
Реплики этих типов предоставляют возможность гибкого размещения информации об объектах NDS на серверах в зависимости от их функциональных ролей. Например, Master- реплики для повышения эффективности процессов администрирования обычно размещают на серверах, расположенных физически максимально близко к администраторам сети, Read/Write ≈ в целях обеспечения надежности хранения информации на серверах за счет ее избыточности, а создание ReadOnly- реплик дает возможность уменьшить трафик репликации в сравнении с Read/Write или Master. Следует заметить, что типы реплик в случае необходимости могут быть в любое время изменены администратором.
Итогом сравнения сервисов репликации каталогов NDS и MAD может служить рекомендация инженерам информационных систем предприятий по использованию в качестве сетевой службы каталогов ≈ Novell Directory Services. Именно NDS даст возможность фактически неограниченного масштабирования вашей сети без необходимости постоянного обновления аппаратного обеспечения серверов и увеличения капитальных вложений в аренду каналов связи!
В последующих публикациях мы рассмотрим принципы синхронизации информации о свойствах объектов в NDS и MAD; особенности механизмов поиска ресурсов в дереве каталога; принципы интеграции NDS, Directory Services Windows NT 4.0 и MAD; средства управления рабочими станциями Windows с применением NDS и MAD. Отдельная публикация будет посвящена выходу новой версии OC Novell NetWare 5.1.
Представительство Novell в СНГ:
121059, Москва, Бережковская наб., д.2. Бизнес-центр, офис 524. Тел.:(095)941-8075/73. факс: (095)941-8066.
E-mail: http://www.novell.ru