Основы теории каталогов

Современная управляемая вычислительная среда представляет собой не только компьютеры, но и соединяющие их сетевые устройства. Эффективное управление сетью требует множества данных, поступающих из самых разных источников — о различных потребностях пользователей сети и ее текущем состоянии. Более того, управление сетью должно быть распределенным, то есть осуществляться с нескольких точек. Часть этой информации может храниться в каталогах. В DEN предусмотрена методика моделирования сетевых элементов и служб таким образом, чтобы информация для их предоставления и управления могла быть помещена в хранилище любого типа. Как правило, это каталоги, но возможно использование и других типов хранилищ.

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

Каталоги и службы каталогов

В этом разделе кратко описываются каталоги и службы каталогов.

Что такое каталог?

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

Информация в каталогах организована так, как показано на рис. 53.3. Группы объектов образуют иерархическую структуру, которая называется информационным деревом каталога (Directory Information Tree — DIT). DIT состоит из объектов каталога. Каждый такой объект соответствует элементу дерева каталога и может иметь один или несколько атрибутов. Каждый атрибут имеет по меньшей мере одно отличительное значение и, кроме того, может иметь неотличительные значения. Такая структура позволяет извлекать информацию либо по точному соответствию совокупности критериев, либо по более общей совокупности критериев, характеризующей нужную информацию.

Отличительные значения используются для вычисления относительных отличительных имен (Relative Distinguished Names — RDN) и определенных отличительных имен (Fully Qualified Distinguished Names — FQDN). FQDN элемента получается путем добавления RDN этого элемента к FQDN родительского элемента. Таким образом, FQDN на любом уровне представляет собой набор относительных отличительных имен, совокупность которых определяет путь от корня DIT к этому элементу каталога (рис. 53.4).

Модель любого предмета из реального мира может быть представлена в виде одного или нескольких элементов каталога. Каждый элемент каталога является объектом, имеющим ряд характеристик, описывающих информацию, которая содержится в этом объекте. Такие характеристики представлены в виде атрибутов элемента каталога. Например, атрибуты объекта User могут определять имя, фамилию, идентификационный номер сотрудника, его номер телефона и другие данные. Все эти атрибуты есть у любого объекта класса User, но значения по крайней мере некоторых из них различны, чтобы можно было отличать пользователей друг от друга.

Совокупность атрибутов элемента каталога определяется объектным классом, к которому принадлежит этот элемент. Объектный класс определяет обязательные атрибуты элемента (к примеру, значения, которые необходимо присвоить) и дополнительные атрибуты (например, определяемые схемой и не требующие явного присвоения значений). Полное множество объектных классов и атрибутов каталога определяется схемой каталога.

Рис. 53.3. Организация информации в каталоге

 

Рис. 53.4. Элементы каталога, их относительные и определенные отличительные имена

Каждый атрибут имеет специфический тип данных, который ограничивает круг присваиваемых атрибуту значений (в частности, буквенно-цифровая строка). Это называется синтаксисом атрибута. Кроме того, для каждого элемента определен набор правил, определяющих критерии совпадения каждого атрибута с поисковым запросом (например, игнорирование регистра символов в строке). Возможны и многозначные атрибуты. Наконец, все атрибуты имеют идентификаторы объекта, которые их однозначно определяют — идентификаторы ASN. 1.

Свойства каталогов

Каталоги имеют пять основных свойств.

•       Хранение информации оптимизируется из расчета, что чтение происходит гораздо чаще, чем запись.

•    Информация организована в виде иерархической структуры.

•    Информация в каталоге классифицируется в зависимости от атрибутов.

•       Каталоги имеют единое пространство имен для всех ресурсов, информация о которых в них хранится.

•       Каталоги позволяют эффективно распространять информацию в распределенной системе посредством репликации.

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

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

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

Последний пункт является принципиальным для построения информационной инфраструктуры. Сервер каталога имеет возможность контролировать, какая информация, когда и в какие узлы системы распространяется.

Что такое служба каталогов?

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

Службы каталогов созданы для предоставления определенных типов информации для приложений. Несколько служб каталогов могут совместно использовать один каталог. В качестве примера рассмотрим два телефонных справочника, один из которых построен по принципу "белых страниц", а второй — по принципу "желтых страниц". Оба справочника содержат номера телефонов, но в разной форме. Справочник "белых страниц" позволяет найти номер телефона нужного абонента, а справочник "желтых страниц" — получить номера телефонов нескольких организаций, принадлежащих к одной категории.

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

На этом примере видно, что службы каталогов обычно ограничены способом действия. Например, при помощи службы "белых страниц" нельзя (по крайней мере, непросто) узнать имя абонента по его номеру телефона.

Традиционное применение каталогов

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

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

•       Общие функции поиска, такие как поиск по атрибуту (например, "найти телефонный номер Джеймса Смита") и по классификации (к примеру, "Найти все цветные принтеры на третьем этаже").

•       Предоставление важной информации для единой регистрации пользователя при доступе к службам, ресурсам и приложениям.

•       Независимое от расположения ресурса администрирование и управление. Следует отметить, что средства администрирования не обязаны располагаться и управляться централизованно.

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

Причины применения DEN в интеллектуальных сетях

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

Однако стандартов синхронизации не существует (каждый работает по- своему), и у каждого варианта есть свои ограничения. Следует отметить, что над этой проблемой сейчас работает группа по созданию протокола репликации и обновления (LDAP Duplication and Update Protocol — LDUP) при IETF. LDUP определяет информационную модель, использованную при разработке протокола репликации, который сейчас проходит синхронизацию. Эта работа должна завершиться к концу 2000 г. Более подробную информацию о LDUP можно получить по адресу http://www.ietf.org/html.charters/ldup-charter.html.

Вторая проблема заключается в отсутствии стандарта на представление информации. Например, есть много способов представления общей информации о пользователе. Кроме того, существует тенденция разрабатывать приложения по принципу "дымохода". Такие приложения стремятся представить информацию в соответствии с набором соглашений об именовании и структурами, наиболее удобными в данном случае. Это выгодно для отдельного приложения, но создает трудности при совместном использовании и повторном использовании информации разными программами (рис. 53.5).

Рис. 53.5. Интеграция приложений, построенных по принципу "дымохода", весьма затруднена

Как видно из рис. 53.5, увеличение количества несовместимых баз данных, каждая из которых предназначена для обслуживания определенных потребностей приложений, значительно усложняет интеграцию. В первую очередь, проблема заключается в дальнейшем использовании хранилищ, ориентированных на конкретное приложение. Дело в том, что данные в таких хранилищах частично совпадают, но используются различные правила хранения и именования. Это вызывает проблемы синхронизации, поскольку теперь все копии данных должны обновляться одновременно; однако это не просто, так как они находятся в разных форматах и представлениях. Кроме того, одни и те же данные рассматриваются по-разному. Наконец, последним камнем преткновения является интеграция. Если все приложения станут использовать частные версии одной и той же модели данных, как они будут ими обмениваться? Обратите внимание, что это также ограничивает возможность совместного и повторного использования приложениями одних и тех же данных.

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

•       Сетевые элементы и службы представлены стандартным образом, что позволяет различным приложениям использовать одни и те же данные.

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

Как сейчас осуществляется, например, единое управление сетью? Иногда для управления различными элементами среды используют HP/Openview и одно или несколько приложений Cisco (предположим, что это Windows NT) для настройки устройств Cisco во всей сети. Возникает проблема: эти два типа приложений должны использовать одни и те же данные, но такое практически невозможно по следующим причинам.

•       Разные приложения представляют одну и ту же информацию по-разному, поскольку имеют различную структуру.

•    Приложения работают на различных платформах.

•    Приложения написаны на разных языках.

•    У каждого приложения свой пользовательский интерфейс.

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

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

•    Администратору достаточно изучить только одно приложение.

•       При изменении одного из приложений нет необходимости перестраивать интерфейсы API.

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

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

Распределение интеллектуальных функций между сетевыми приложениями

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

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

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

Модель политик DEN

Распределение ресурсов в соответствии с принятыми в компании правилами ведения бизнеса является критически важным требованием. Модель политик DEN определяет континуум политик, каждая из которых оптимизирована для представления различной информации. Например, цель деятельности предприятия может определяться администратором, что делает ее аппаратно и алгоритмически независимой. Рассмотрим в качестве примера следующее правило.

ЕСЛИ

Абонент подписан на "золотой" пакет услуг, ТО

Разрешить использование NetMeeting и обеспечить первоочередное обслуживание КОНЕЦ

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

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

ЕСЛИ

IP-адрес источника = 172.3.128.0/15 ТО

Присвоить речевым данным метку EF, а обычным данным — метку AF11 КОНЕЦ

Это правило аппаратно-независимо в том смысле, что может применяться к разным устройствам.

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

•       Настроить компонент так, чтобы его можно было использовать для условной передачи потоков данных.

•       Настроить компонент таким образом, чтобы он мог непосредственно влиять на потоки данных.

• Изменять действия компонента в зависимости от сетевых или системных событий (таких, как повреждение канала связи).

Теперь набор политик можно преобразовать, например, в набор команд CLI для конкретного устройства.

Преимущество такого подхода заключается в том, что он обеспечиввет многократно используемый шаблон. Вместо того чтобы пытаться выполнить преобразования для каждого интерфейса каждого сетевого устройства, можно разработать набор шаблонов, управляемых политиками, и отделить аппаратно-независимые правила от аппаратно- зависимых правил. Именно такой подход использует рабочая группа политик IETF для управления и подготовки QoS (см. http://www.ietf.org/html.charters/policy-charter.html).

Использование каталогов в интеллектуальной сети

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

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

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

3.        Каталоги упрощают поиск информации, если неизвестно точное расположение или имя объекта, где хранится нужная информация. Служба каталогов представляет собой нечто большее, чем просто служба имен, такая как DNS. Служба каталогов позволяет осуществлять как поиск, так и извлечение именованной информации.

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

Проблемы современных служб каталогов

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

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

Литература:

Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1040 с.: ил. – Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100