Сетевая модель данных службы каталогов Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 519.688

А. В. Андреев

Санкт-Петербургский государственный университет аэрокосмического приборостроения

Сетевая модель данных службы каталогов

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

Ключевые слова: служба каталогов, иерархическая модель данных, сетевая модель данных, алгоритм Дейкстры.

Введение

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

Информация об определенном объекте (ресурсе) хранится как значения атрибутов этого объекта.

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

OpenLDAP — это служба каталогов, которая позволяет нам работать с различными сетевыми ресурсами (пользователями, компьютерами, принтерами, зонами DNS, а также всем, что необходимо вам для работы).

Вся работа осуществляется по протоколу LDAP (англ. Lightweight Directory Access Protocol). Это сетевой протокол для доступа к службе каталогов Х.500, разработанный IETF как облегчённый вариант ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции авторизации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей.

Любая запись в каталоге LDAP состоит из одного или нескольких атрибутов и обладает уникальным именем (DN — англ. Distinguished Name). Уникальное имя состоит из одного или нескольких относительных уникальных имен, разделённых запятой. Относительное уникальное имя имеет вид «ИмяАтрибута=значение». На одном уровне каталога не может существовать двух записей с одинаковыми относительными уникальными именами. Для хранения записей OpenLDAP использует базу данных Berkeley DB, но доступны различные модули для хранения данных в других БД.

Структуры хранения данных каталога Стандартная структура хранения данных каталога

Служба каталога, как и большинство каталогов, имеет структуру организации хранения данных в виде ориентированного граф-дерева (рис. 1), где у каждого «родителя» есть один «потомок». Данная структура детально описана в стандарте протокола RFC 4512 и использует иерархическую модель данных.

Такую структуру можно описать графом G = ( V., Е), где V(G) — множество вершин графа V(G) = (vd,vp,vo,..-,Vi), E(G) — множество дуг графа , E(G) = ({vd,vp},{vp,vo},...,{vp,Vi}).

dc=domain

о

о People

uid=squser

uid=smbuser2+squid

uid=user

Рис. 1. Пример стандартного дерева каталога

Вершины обозначаются согласно принадлежности к тину записи:

Vd — вершина корневого элемента de,

vp — вершина-родитель для группы записей (ou=People),

Vi — вершина-потомок для записи в каталоге,например, uid=smbuser,

г — количество записей, г = 1... п.

Поиск записей в таком графе осуществляется по всему дереву службы каталогов, таким образом время поиска каждой записи будет прямо пропорционально зависеть от общего числа записей каталога. Чаще всего при настройке каталога и сервисов взаимодействующих с ним выбирают одну ветку для хранения и поиска записей ou People. В таком случае время ответа на запрос к каталогу будет связан с содержанием ветки ou People, а именно количеством записей в ней. Данная особенность связана со способом хранения и получения информации в Berkeley DB, которая используется по умолчанию в службе каталогов OpenLDAP.

Сетевая модель данных структуры каталога

Современная версия клиентской и серверной частей LDAP, описанная в RFC 4511, позволяет хранить, записывать, осуществлять поиск записи в разных ветках каталога, а сервисам-службам работать с ними. Группируя записи по их общим параметрам (атрибутам и объектным классам, используемым сервисам), можно построить более упорядоченную структуру хранения данных. Более того, отслеживая изменения в активности сервисов, можно организовать адаптивную службу каталогов, меняющую свою структуру в зависимости от динамики запросов к ней.

Но следует учитывать тот факт, что для начальной поддержки работоспособности всех сервисов существует необходимость хранения записей или ссылочных записей («алиасов») в ветке ou People.

Таким образом, можно сформировать новую структуру каталога, использующую уже сетевую модель данных (рис. 2).

Рассмотрим такую структуру хранения данных службы каталогов с корневым элементом de domain, в которой записи сгруппированы но используемым сервисам-службам. С данным каталогом работают два сервиса: файловый сервер (ветка ou Samba) и прокси-сервер (ветка ou Squid). Как видно из рисунка, записи, используемые только одним каким-то сервисом, хранятся в соответствующей ему ветке (ou Samba,de domain и ou Squid,de domain), a для записей, используемых в обоих сервисах, используется специальная запись alias.

dc- domain

alias

uid=smbu ser2 -f-sq и ¡ d

Рис. 2. Предлагаемая структура хранения данных

Предлагаемая структура хранения данных является ориентированным граф-деревом GUÍ = (V,Е"'), где V (GiU) — множество вершин графа V Uí(GUÍ)=(va ,vp ,vo,.. .,Vi ,vao,.. ,,vaj ,voo,..-,vos), E UÍ(GUÍ) — множество дуг графа, дуги которого различны для каждого отдельного каталога, и имеет несколько родительских вершин (ou Samba,ои Squid,alia«) для вершины-потомков (uid smbuser,uid smbuser2+squid,uid squid), где Vd — вершина корневого элемента de, vp — вершина-родитель для группы записей (ou=People), Vi — вершина-потомок для записи в каталоге, например, uid=smbuser, vaj — вершины-ссылки, они же alias, vos — вершины-службы, i — количество записей, i = 1... п, j — количество записей-ссылок, s — количество сервисов, работающих с каталогом.

Методика поиска принадлежности вершин

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

Процесс определения вершин, требующих перестроения в дереве каталога, можно разделить на несколько этапов:

1. определение используемых сервисов;

2. определение важности того или иного сервиса;

3. определение используемых атрибутов и объектных классов;

4. группирование записей но важности сервиса и используемым атрибутам.

Для определения используемых сервисов прежде всего следует определиться с набором ролей сервера. Например, для роли файлового сервера используется сервис samba. Чаще всего используют такое соответствие:

- файловый сервер сервис samba;

- прокси-сервер сервис squid;

- почтовый сервер сервисы postfix и dovecot;

- сервер аутентификации РАМ.

Данное соответствие позволит четко определить вид записей в каталоге. Например:

dn: uid user,ou People,dc example,de com mail: user ©example. com given Name: user

sn: user cn: user user sambaAcctFlags: [UD ] mgrp Deliver To: user objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: posixAccount objectClass: mailgroup objectClass: sambaSamAccount uidNumber: 10022 gidNumber: 10022 homeDirectorv: /home/user loginShell: /bin/bash

sambaSID: S-1-5-21-2098741869-3465982337-3637863451-10022 sambaNTPassword: EE42945FD699570D2DA4C2A0BE29D3B5 sambaLMPassword: 8131BC5135B26C62C81667E9D738C5D9

sambaPasswordHistorv: 00000000000000000000000000000000000000000000000000000000 00000000

sambaPwdLastSet: 1362051479 userPassword::

elNTSEF9R0tPSmclaFd5Z09JWVJBYVY3MGx3QURjTnhNZUxpSmxTVHFtRkE9PQ= uid: user

Каждый сервис имеет свои специфические свойства:

- количество необходимых атрибутов,

- вид работы (чтение/запись на жесткий диск или иной носитель данных, запросы поиска к СУБД).

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

Касательно загруженности системы данный порядок сохраняется.

Имея эти данные, можно определить «числовые критерии сервисов» из условия, что наименьшее число — это наиболее критичный сервис. Таким образом, имеем:

- файловый сервер — критерий равен 1;

- почтовый сервер — 2;

- прокси-сервер — 3;

- сервер аутентификации — 4.

Данные загруженности по сервисам представлены в табл. 1.

Так как каждый атрибут связан с определенным классом или группой классов, несложно определить частоту использования того или иного сервиса для различных операций с каталогом (чтение, изменение, удаление). Для определения точного множества необходимых атрибутов и классов удобно воспользоваться табл. 2 «Атрибуты для различных сервисов» и формулой 1, полученными в более ранних исследованиях.

Для точного определения необходимых атрибутов удобно воспользоваться формулой (3):

С = ((Bi\Bi+i)...(Bn-i\Bn))(Bn\((Bi\Bi+i )...(Bn-i\Bn))), (1)

Таблица 1

Нагруженность системы при различный сервисах

Сервис Аутентифика- Добавление Удаление Отправка Прием

ция пользова- пользова- J^QTJ'PkJ

ЬсПз теля ЬёЬ теля ЬсПз bdb bdb

squid СРИ- 70%,ФС-70% - - - -

samba СРИ- СРи- СРи- - -

(smbldap- 84%,ФС-92% 86%,ФС- 79%,ФС-

tools) 100% 100%

postfix СРИ- - - CPU- CPU-

+ 73%,ФС-69% 73%,ФС- 73%,ФС-

dovecot 72% 75%

pam СРИ- 71%,ФС-71% - - - -

postfix СРИ- - - CPU- CPU-

+ 75%,ФС-70% 77%,ФС- 74%,ФС-

courier- 75% 78%

imap

Таблица2

Атрибуты для различных сервисов

Файловый сер- Кри- Почтовый Кри- Прокси- Кри- Сервер Кри-

вер (атрибуты) те- сервер (ат- те- сервер те- аутенти- те-

рий рибуты) рий (атрибуты) рий фикации (атрибуты) рий

uid 1 uid 2 uid 3 uid 4

uidNumber uidNumber шегРавб-даоМ userPassword

gidNumber gidNumber uidNumber

homeDirectorv homeDirectorv gidNumber

СП userPassword homeDirectorv

sn mail СП

description loginShell

displavName gecos

objectClass description

modifyTimestamp objectClass

Samba*

userPassword

loginShell

gecos

shadowMax

memberUid

где г = 1... п, п — количество сервисов,

В г — множество атрибутов для определенного сервиса, С — уникальное множество атрибутов.

Таким образом, выделяются множества атрибутов и классов, необходимых для работы сервисов.

По полученным данным заполняются табл. 3 «Записи сервисов» и табл. 4 «Записи каталога с учетом критерия сервиса», из которых принимается решение о переносе вершины записи в одну или другую ветку каталога.

Т а б л и ц а 3

Записи сервисов

запись атрибут класс атрибута частота появления атрибута сервис, который запрашивал атрибут

Т а б л и ц а 4

Записи каталога с учетом критерия сервиса

запись сервис частота использования сервиса критерий сервиса

Построение сетевой модели данных структуры каталога

Определив раннее множество вершин V' требующих перестроения, можно для каждой записи ы построить граф новых связей С'%=(V'%,Е'¿).

Рис. 3. Дополнительные подграфы вершин

Выделив вершины V' строится граф с исходной в ершиной V' вершинами «али асов» vaj и вершиной-родителем групп уоо, вершинами-родителями для «алиасов» ьр, по\,..

Следует отметить, что «алиаеов» у записи может быть несколько, соответственно у каждого «алиаса» будет своя вершина-родитель но у каждой записи будет «алиас»

для вершины ьр.

Выделяются подграфы С¿=(V\,Е'¿), где вершины V\=,ур,уа0,••а^,шо,••и дуги Е'г=({V'г,-тоо},...,{у'г{у'г,уоо},{уао,ур},{уа1,у0г},...,{уа^,УОз-г}), где

г = 0... И,

N — количество вершин-записей в каталоге,

2 = 1... т,

т — количество «алиаеов» для записи или количество веток, в которых хранится запись.

Добавление дуг сервисов к исходному графу

Для того чтобы связать полученные графы вершин и основное дерево каталога, добавим к исходному графу С дуги Е^(С")" = (ус!,уоо,...,уо^-\) и вершины Уг(Си)и={{у(1,уо0}, ..., {vd,voj-l}), задающие новые ветки.

Объединив множества вершин и дуг, получим новый граф С"(Е", V"):

V " = V и V "%

Е" = Е и Е "г С" = (Е ",У")

Рис. 4. Дополнительные дуги

Удаление дублирующихся записей-вершин

Перед объединением графа С'^ и основного графа С необходимо удалить дублирующиеся записи-вершины ы для V'г и дуги {ьг,ьр} в ветке ои=Реор1е.

Удаление вершины. Пусть С = (Е, V) — граф и V € V. Удалить вершину V из графа С — это значит построить новый граф С" = (Е", V"), в котором V" = V\{-и} и Е" получается из Е удалением всех ребер, инцидентных вершине V.

Рис. 5. Удаление дублирующихся вершин

Объединение графов

Графы вершин С\ для каждых вер шин объединяются с графами О'":

V"' = V" и У\,

Е"' = Е" и Е\, С"' = (Е "' ,У "').

В результате чего получим новую структуру каталога, использующую сетевую модель данных, изображенную на рис. 2.

Модифицированный алгоритм поиска наименьшего пути Дейкстры

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

Для поиска кратчайших) пути в дереве каталога необходимо ввести определение веса перехода а, которое будет использоваться далее.

а — некоторое число, определяющее затраты, такт перехода из одной вершины в другую. Также введем следующие обозначения: 8 — начальная вершина, £ — конечная вершина, х — текущая вершина.

Положим для начальной вершины а(в) = 0. Вес первой дуги из ве ршины въх а(в, х1) = 1. Тогда для любой другой вершины с учетом механизма поиска в службах каталогов

а(8,х^ = 1 + а(в, х—1), (2)

где 1 вес первой дуги,

1) — вес дуги для вершины Хг-\. Алгоритм поиска наименьших) пути:

Шаг 1. Перед началом выполнения алгоритма все вершины и дуги не окрашены. Каждой вершине х присваивается некое число й(х), равное длине кратчайшего пути из вершины-источника пж, включая все вершины, ранее записанные в службу каталогов.

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

Соответственно d(s) = 0, a d(x) = œ для всех вершин, отличных от вершины-источника s. Вершину s окрашиваем и временной переменной у присваиваем s (у = s), у — последняя окрашенная вершина.

Вершина-источник — это вершина, заданная при поиске, чаще всего ou=People.

Шаг 2. Для каждой неокрашенной вершины х следующим образом пересчитать величину d(x):

d(x) = min{d(x), d(y)} + a(y, x). (3)

Если d(x) = œ для всех вер шин х, такого пути нет. В противном случае окрасить ту вершину ж, для которой величина d(x) является наименьшей. Также окрасить дугу, ведущую в выбранную на данном шаге вершину ж. Меняем значение у = х.

Для современных служб каталогов величина d(xi) будет равна величине веса дуги вершины Xi, так как во время перехода по графу будут закрашены все дуги и вершины, записанные раннее в текущей ветке каталога:

d(xi) = a(s,xi) a(s,Xi), (4)

где N — количество вершин в поиске.

Шаг 3. Если у = t (конечная вершина поиска), закончить процедуру. Кратчайший путь из вершины s в t найден. Иначе перейти к шагу 2.

Рассмотрим стандартную структуру каталога, изображенную на рис. 1.

В данной случае s — это вершина ou=people, t — вершина uid=squser.

Определим веса дуг, согласно формуле 2:

a(people, smbuser) = 1 a(people, smbuser + squid) = 1 + a(people, smbuser) = 2 a(people, user) = 1 + a(people, smbuser + squid) = 3

a(people,squser)=l+a(people,user)=4a(people, squser) = 1 + a(people,user) = 4

Согласно формуле (4) d(squser) = 4

Таким образом, кратчайший путь для вершины uid=squser будет самым длинным по сравнению с другими вершинами графа.

Рассмотрим предлагаемую структуру каталога, изображенную на рис. 2.

В предлагаемой структуре каталога — графе — поиск уже ведется от специально созданной вершины ou=Squid.

Для неё определим веса дуг:

a(squid, squser) = 1

Величина d(squser) = 1.

В данном случае путь до вершины uid=squser будет короче, чем при стандартном графе. При таком построение графа поиск записи будет осуществляться быстрее.

Заключение

Предлагаемая структура хранения данных требует в дальнейшем более детального изучения. В данном представлении сетевая модель является избыточной из-за дублирования записей в ветке ou=People, что приведет к большим затратам для хранения данных на жестком диске. Но для основной задачи — минимизации времени ответов на запросы — является предпочтительней стандартной, иерархической.

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

Литература

1. Tamm У. Теория графов. — М. : Мир, 1988.

2. Майника, Э. Алгоритмы оптимизации на сетях и графах. — М. : Мир, 1981.

3. Кристофидес Н. Теория графов. Алгоритмический подход. — М. : Мир, 1975.

4. Robinson I., Webber J., Eifrem E. Graph Databases. — O'Reilly, 2013.

Поступим в редакцию 11.09.2013.