Технический обзор
Различия сетевых служб каталогов на уровне предприятия
Оснащенное службами каталогов сетей масштаба предприятия, сегодняшнее поколение сетевых операционных систем (NOS) позволяет администраторам гораздо легче поддерживать работу сотен или тысяч пользователей и управлять громоздкими сетевыми сплетениями, включающими многочисленные файловые серверы, которые охватывают различные отделы.
Но поскольку поставщики NOS продолжают закладывать в основу своих продуктов в корне отличные стандарты служб каталогов, то перспектива появления многоплатформных, независимых от NOS сетевых служб каталогов остается пока столь же далекой, как и мечта о новом поколении распределенных, поддерживающих каталоги продуктов для групповой работы.
Тем не менее способность корпораций стандартизовать хотя бы некоторые из своих серверов для какой-то одной из новых операционных систем приведет к увеличению продуктивности администрирования. Одна-единственная проблема состоит в определении того, какая итерация служб каталогов наилучшим образом соответствует нуждам вашей компании.
Кое-что помимо дизайна
По изяществу дизайна NetWare Directory Services (NDS) фирмы Novell и Open NetWork Computing Plus (ONC+) фирмы SunSoft явно затмевают предыдущего лидера сетевых служб каталогов, StreetTalk фирмы Banyan Systems.
Однако администратор сети предприятия, пытаясь определить направление, в котором следует менять существующую NOS, вряд ли будет заострять внимание на дизайне систем каталогов каждой из них. Скорее он будет опираться на то, какую службу каталогов смогут поддерживать сетевые приложения, используемые его компанией.
Польза, которую можно извлечь из службы каталогов, зависит преимущественно от степени ее использования при интеграции с установленными системами и от дальнейших планов корпорации по внедрению ПО.
Следовательно, много зависит от того, какой стандарт каталогов будет поддерживаться электронной почтой вашей компании или поставщиком СУБД.
Служба каталогов сети масштаба предприятия одного поставщика может оказаться более надежной, чем другого, но увеличение продуктивности управления это еще не все.
Например, схема доменов, используемая Windows NT корпорации Microsoft (в преддверии появления Cairo), не столь четкая, как, скажем, схема NetWare 4.1. Тем не менее ряд популярных пакетов баз данных и систем электронной почты начали вводить поддержку каталогов NT.
Windows NT поддерживается сторонними фирмами благодаря ее графическим средствам управления и тесной интеграции с Windows широко распространенной операционной системой для настольных ПК.
Обсуждение размерности архитектуры
Первоначально службы каталогов имели плоскую, одномерную архитектуру, когда все объекты находились на одном и том же уровне. При такой архитектуре пользователю нужно было знать местоположение информации или ресурсов, к которым он хотел получить доступ.
Например, для работы с системной базой данных bindery NetWare 3.х пользователи должны знать, какой файловый сервер хранит том с необходимыми им разделяемыми данными. Кроме того, на каждом файловом сервере, к которому они хотят получить доступ, должна быть учетная запись пользователя (user account). Это также означает, что администратор сети постоянно сталкивается с утомительной задачей добавления и удаления пользователей из нескольких баз bindery.
Двухмерная структура именования, до сих пор используемая в Microsoft LAN Manager и IBM LAN Server, занимает неопределенное промежуточное положение между целиком плоской, одномерной структурой bindery NetWare 3.х и четкой трехмерной архитектурой, используемой StreetTalk, NDS и ONC+.
Двухмерная служба каталогов LAN Manager и LAN Server позволяет группировать серверы в домены и предоставляет распределенный каталог для одноразовой аутентификации пользователя, выполнив которую, пользователь может получить доступ ко всем ресурсам в конкретном домене.
Борьба с жестким разделением на группы
Однако эти домены используют чрезвычайно ограниченную одноуровневую иерархию. При такой архитектуре сетевые серверы можно поместить в конкретную группу, но эти группы нельзя ни делить на более мелкие подмножества, ни объединять в более крупные организации.
Более того, такие сетевые ресурсы, как очереди на печать, по-прежнему привязаны к физическому местоположению. Простое перемещение совместно используемого тома на другой файловый сервер требует, чтобы администратор изменил карту подключения сетевых дисков на каждом клиентском ПК. В крупной среде любое административное изменение превращается в реализацию огромного проекта. (Конечно, это не было бы такой проблемой, если бы в LAN Server или Windows NT были хорошие сценарии входа в систему.)
Microsoft слегка усовершенствовала свою двухмерную архитектуру в Windows NT, добавив трастовые (доверительные) связи между доменами и введя глобальные группы. Два этих новшества приводят к тому, что конфигурирование многодоменной среды в NT выполняется значительно проще, чем в LAN Server. Возможность создавать глобальные группы и устанавливать трастовые связи между доменами позволяет получать единый счет для доступа ко всем службам корпоративной сети.
К сожалению, каждая из этих глобальных групп в каждом домене должна поддерживаться отдельно. NT пока не позволяет администраторам осуществлять такие простые действия, как просмотр списков членов глобальных групп компании по каждому домену.
NDS, StreetTalk и NIS+ (Network Information Service Plus подмножество ONC+) обладают полностью иерархической архитектурой. Это позволяет гораздо более гибко выполнять конфигурирование для крупных организаций.
Более того, возможность назначать ресурсам логические имена, не зависящие от их местоположения, значительно упрощает управление этими службами каталогов по сравнению с тем, что предлагают сейчас IBM или Microsoft.
N-уровневое пространство имен
Однако возможности StreetTalk фирмы Banyan ограничены трехуровневым пространством имен. Такие объекты, как пользователи и сетевые ресурсы, могут быть членами групп и корневой организации, без объединения в более крупные или дробления на более мелкие структуры. Для большинства компаний это не является проблемой. Администраторы сети, которым нужно более широкое пространство имен, могут использовать придуманные имена групп или определить атрибуты объектов, чтобы добиться того же эффекта.
К примеру, создав такие группы, как “finap” (Accounts Payable group in Finance группа финансовой организации с платежеспособными счетами) и “finar” (Accounts Receivable group in the same Finance organization группа в той же финансовой организации со счетами, годными к принятию), можно использовать символы-шаблоны в “fin*” для поиска всех сетевых ресурсов.
Как средства NDS фирмы Novell, так и NIS+ фирмы SunSoft позволяют использовать n-уровневые имена, благодаря чему каталоги этих служб превосходно соответствуют любому типу организации независимо от ее размера.
Поддерживая основы
При правильном планировании даже устаревшие модели службы каталогов, предлагаемые Windows NT и LAN Server, могут работать в крупных предприятиях.
Однако плохой проект сети может поставить на колени даже такие мощные службы каталогов, как NDS фирмы Novell.
У каждого администратора сети есть своя собственная версия того, почему секция сети “вылетела из строя”, когда произошла авария на единственном сервере или когда соединение арендованной линии глобальной сети пришло в неисправное состояние.
Обычная проблема, с которой сталкиваются администраторы, это время, требующееся для распространения изменений по всей сети. Например, прежде чем начать пользоваться новым сервером NetWare 4.х в ЛВС, пользователь должен подождать, пока машина будет зарегистрирована в дереве NDS.
Задержки могут быть различными по длительности в зависимости от размера ЛВС и от того, как сконфигурированы службы репликации каталогов.
Поскольку пользователи удаленных узлов постоянно запрашивают далеко расположенные от них серверы для аутентификации, то распределенная структура сегодняшних служб каталогов в сочетании с медленными связями глобальной сети также может стать препятствием.
Там, где трафик надежен, динамически обновляемые базы данных скопированных каталогов могут быть размещены по всей компании.
В некоторых случаях способ организации каталогов влияет на количество административных действий.
Что касается доменов Windows NT, то поддержка трастовых связей с новейшими данными на крупных предприятиях сложна и требует времени, поскольку число трастовых связей в сети NT с каждым дополнительным доменом растет в квадратичной зависимости.
Отличительная черта громоздкость
Если все пользователи доменов запрашивают доступ к общим ресурсам, то корпоративные ресурсы лучше всего разместить в одном центральном домене, а с каждым из оставшихся установить одну трастовую связь. Альтернатива установление трастовых связей между каждым доменом является, мягко говоря, громоздкой.
Новое поколение служб каталогов сети предприятия стало гораздо более гибким и менее требовательным, чем раньше. Например, первоначальную структуру каталогов NetWare 4.0 было невозможно изменить, а теперь благодаря графическим средствам NetWare 4.1 относительно просто произвести удаление и добавление.
Однако, несмотря на улучшения, службы каталогов все еще населены “злыми духами”, которые могут помешать соединению между секциями ЛВС.
Например, домены Windows NT печально известны таинственными исчезновениями трастовых связей, из-за чего необходимо иметь администраторов для каждой вновь определенной трастовой связи или выполнять “хирургические” манипуляции в регистрационном журнале NT.
Майкл Суркан
УБЕДИТЕСЬ, ЧТО В СЛУЖБЕ КАТАЛОГОВ СЕТИ ВАШЕГО ПРЕДПРИЯТИЯ ИМЕЕТСЯ:
- Единая точка подсоединения к системе. Счета пользователя должны создаваться только один раз, и пользователь должен иметь возможность войти в сеть из любой точки и получать доступ к ресурсам независимо от того, где они находятся.
- Графические средства администрирования. Для поддержки комплексности типичного корпоративного каталога должны быть включены изобразительные средства.
- Иерархические каталоги. Должна существовать возможность помещать сетевые ресурсы или объекты в группы.
- Логическое наименование объектов. Сетевые ресурсы должны именоваться логически, а не по месту их расположения.
- Консолидированные объектные базы данных. Для уменьшения перегрузок трафика из-за поиска каталогов необходимы базы данных каталогов, содержащие регулярно обновляемую информацию обо всех распределенных серверах.
- Распределенная архитектура. Каждая отдельная сетевая группа должна иметь возможность управлять своими собственными пользователями и ресурсами.
- Поддержка ПО третьих фирм.
- Основным оправданием для выбора службы каталогов сети предприятия служит надежное снабжение приложениями, поддерживающими каталоги.
РАСТУЩАЯ ПОЛЬЗА
Выгода, которую можно извлечь из службы каталогов, зависит от степени ее использования при интеграции с установленными системами и от дальнейших планов корпорации
Поддержка служб каталогов третьими фирмами
