Методика перепроектирования структуры хранения данных службы каталогов тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат наук Андреев Андрей Васильевич

• Андреев Андрей Васильевич
• кандидат наук
• 2020

Оглавление диссертации кандидат наук Андреев Андрей Васильевич

ВВЕДЕНИЕ

1 СЛУЖБЫ КАТАЛОГОВ И ИХ РАБОЧЕЕ ОКРУЖЕНИЕ

1.1 Вводные замечания

1.2 Службы каталогов

1.3 Служба каталогов OpenLDAP

1.4 Рабочее окружение служб каталогов

1.5 Выводы по разделу

2 АНАЛИЗ ВРЕМЕННОЙ ХАРАКТЕРИСТИКИ СЛУЖБЫ КАТАЛОГОВ

2.1 Вводные замечания

2.2 Встроенные инструменты поиска записей

2.3 Способ вычисления времени отклика на запрос поиска записи к службе каталогов

2.4 Влияние размера записи на время поиска значения атрибута

2.5 Влияние индексирования на время отклика на запрос

2.6 Условия эффективности работы службы каталогов

2.7 Выводы по разделу

3 МЕТОДИКА ПЕРЕПРОЕКТИРОВАНИЯ СТРУКТУРЫ ХРАНЕНИЯ ДАННЫХ СЛУЖБЫ КАТАЛОГОВ

3.1 Иерархическая модель данных

3.2 Сетевая модель данных

3.3 Методика перепроектирования структуры хранения данных службы каталогов

3.4 Метод разбиения множества параметров каталога на подмножества с учётом

приоритета их использования

3.6 Метод перехода от иерархической структуры хранения данных каталога к сетевой

3.7 Система формирования сетевой структуры каталога

3.8 Выводы по разделу

4 СРАВНИТЕЛЬНЫЙ АНАЛИЗ РАЗРАБОТАННОЙ СТРУКТУРЫ СЛУЖБЫ КАТАЛОГОВ И ИСХОДНОЙ ИЕРАРХИЧЕСКОЙ ДЛЯ НЕКОТОРОГО КАТАЛОГА

4.1 Вводные замечания

4.2 Служба каталогов с иерархической структурой хранения данных

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

4.4 Служба каталогов с сетевой структурой хранения данных

4.5 Сравнительный анализ полученных результатов времени отклика на запрос

двух структур каталога

4.6 Эффективность применения индексирования для заданного каталога

4.7 Выводы по разделу

ЗАКЛЮЧЕНИЕ

СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ А

ПРИЛОЖЕНИЕ Б

ПРИЛОЖЕНИЕ B

ПРИЛОЖЕНИЕ Г

ПРИЛОЖЕНИЕ Д

Введение диссертации (часть автореферата) на тему «Методика перепроектирования структуры хранения данных службы каталогов»

ВВЕДЕНИЕ

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

Служба каталогов - программная система, позволяющая осуществлять создание, поиск и редактирование (добавление, удаление, исправление) информации об информационно-вычислительных ресурсах, хранящейся в виде каталога, т.е. списка записей с определенным набором атрибутов. Помимо перечисленного, в каталоге могут быть опубликованы различные информационно-вычислительные ресурсы для организации быстрого и простого их поиска. Кроме того, каталог часто используется для управления доступом к ресурсам и управления самой сетью - групповые политики, программное обеспечение и т.д.. Данная диссертационная работа посвящена исследованию служб каталогов, строящихся на базе протокола LDAP (Lightweight Directory Access Protocol). Самые распространённые службы каталогов - Microsoft Active Directory, OpenLDAP, 389 DS и другие [1]. Различные службы каталогов широко используются малыми, средними и крупными организациями и предприятиями, где служба каталогов является не только средством хранения и поиска учётных записей, но и выступает в роли централизованного механизма аутентификации пользователей и авторизованного доступа ко всем ресурсам сети [2]. Многие продукты, например почтовый сервер Zimbra или Microsoft Active Directory Domain Services, в основе своей архитектуры используют службу каталогов [3]. Также существуют облачные реализации служб каталогов, например, JumpCloud предлагает облачный продукт Directory-as-a-Service, использующий OpenLDAP

Здесь и далее в работе под термином «Службы каталогов» подразумевается набор различных реализаций служб каталогов, таких как Microsoft Active Directory, OpenLDAP, 389 DS, Red Hat DS и так далее, а под термином «Служба каталогов» подразумевается общее определение любой реализации.

Термины «Служба каталогов» и «Служба каталога» или «Службы каталогов» и «Службы каталога» соответственно, предлагается использовать как синонимы, так как служба (программная система) может работать как с одним каталогом, так и с несколькими.

Для любого каталога одним из основных параметров эффективности является время доступа к данным и передачи данных для последующей обработки, будь то телефонный справочник или сервис доменных имён. Актуальность данной проблемы обусловлена растущими объёмами информации, необходимыми для хранения [5], и требованиями к скорости дальнейшей обработки этой информации (поиск, изменение и т.д.).

Высоконагруженная вычислительная сеть - это интенсивно работающая информационно-вычислительная сеть, как правило имеющая весьма развитую инфраструктуру. В её состав обычно входят информационные системы (Интернет сайты, системы информационного оповещения и связи), системы электронного документооборота, файловые хранилища, и так далее. Целью информационной вычислительной сети является эффективное использование всех информационных ресурсов и процессов организаций и предприятий различных отраслей производства. Так, например, для доступа в сеть и работы с сетевыми ресурсами, как правило, используется единая система идентификации пользователей: при входе в сеть пользователь представляется системе, проходит процедуры аутентификации и авторизации и может использовать любые её сервисы без повторной аутентификации. Такая система не только облегчает работу пользователя, но и позволяет более эффективно организовывать работу других сервисов информационной вычислительной сети, например отправку пользователем электронных сообщений, хранение служебной информации пользователя и распределение прав доступа к ней, предоставление пользователю

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

Степень разработанности темы. Начальным этапом исследования стали технические спецификации и стандарты RFC (Request for Comments) и ISO (International Organization for Standardization), описывающие протоколы X.500 и LDAP, являющимися стандартами построения служб каталогов [6]. Оба протокола имеют больше общего, чем различий [7]. К общему между ними относится описание информационной модели и стандартных сервисов, которые являются центральным аспектом для X.500 и LDAP и могут быть представлены следующим образом:

1. Иерархическое пространство имён. LDAP и X.500 оба описывают иерархический каталог с иерархическими именами. Например, имена имеют вид:СК=^п Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US [8, 9].

2. Типизированные компоненты имён. Например, CN (Common Name). Это отличие с другими схемами, такими как схема доменных имён, которые имеют нетипизированные имена [10].

3. Типизированные объекты. Объекты представляются в виде записей в каталоге X.500/LDAP. Данные записи предоставляют тип определяемый как объектный класс, посредствам атрибута "ObjectClass". Типичными объектными классами являются: People, Organizations и Computers. X.500 и LDAP имеют общие типы объектов.

4. Типизированные атрибуты. Информация в объектах состоит из набора типизированных атрибутов. Например, атрибут "telephone number" может иметь несколько значений. В зависимости от типа атрибута он может хранить строковые и не строковые данные, например, фотографию. X.500 и LDAP имеют общие типы атрибутов.

5. Типы операций. X.500 и LDAP имеют общий набор операций обработки и доступа к данным каталога. Операции: чтение, сравнение, поиск, добавление, удаление, изменение записи, изменение имени [11].

Оба протокола начинают свою историю со спецификаций ISO/ITU X.500 1988 года, которые являются результатами работы начатой в 1982 году. Основные понятия данных спецификаций для понимания взаимосвязи X.500 и LDAP могут быть представлены следующим образом:

1. DSA (Directory System Agent) - ядро службы каталогов. Единичный DSA обычно обслуживает только часть имеющейся информации в каталоге;

2. DUA (Directory User Agent) - процесс клиента, который обращается к информации каталога. Это может быть пользовательский интерфейс или встроенный в другое приложение;

3. DAP (Directory Access Protocol) - протокол, который DUA использует для досутпа к одному или более DSA;

4. DSP (Directory System Protocol) - протокол взаимосвязи между DSA

[12].

LDAP (Lightweight Directory Access Protocol) возник из опыта построения каталога X.500 в Интернете в 1989-1991 годах. Маршал Роуз (Marshall Rose) и Тим Хоус (Tim Howes) разработали протоколы для обмена данными между DUA и шлюзом, которые транслируются из LDAP в X.500 DAP [13]. Целью оригинального LDAP было дать простой лёгкий доступ к каталогу X.500, что бы способствовать развитию X.500 DUA и использованию X.500 для широкого круга приложений.

Использование LDAP возросло и стало основным компонентом использования X.500 в Интернет. Было несколько реализаций, но наиболее

значимой и популярной стала свободная реализация, выполненная в университете Мичигана Тимом Хоусом, Марком Смитом (Mark Smith). Данная реализация содержала пакет с набором свободных LDAP DUA. Исходя из этого, большинство поставщиков X.500 DSA начали предоставлять шлюзы, обеспечивающие доступ LDAP по LDAP для DAP преобразования.

Легковесность LDAP по сравнению с X.500 выражается в следующих факторах:

- более простой код;

- имена и атрибуты имеют строковые кодировки. Имена и атрибуты являются всеобъемлющими в протоколе. В X.500 они имеют сложную кодировку ASN.1, в то время как в LDAP они получают простое кодирование строк. Это особо полезно для приложений, которым не нужно обрабатывать детальную структуру имён и атрибутов [14, 15];

- отображение непосредственно в TCP/IP;

- простой API (Application Programming Interface). API опубликовано в RFC 1823 [16, 17];

LDAP зависит от X.500 для определения сервисов распределенных операций. Так как LDAP является протоколом доступа к X.500, а не полноценной службой каталогов, то его можно описать очень коротко. Подробно сервисы описаны в X.500 [18].

Существующие подходы улучшения эффективности работы службы каталогов направлены на уменьшение времени отклика на запрос к данным путём использования различных способов кэширования дисковых подсистем, баз данных, используемых в качестве хранилища данных, а также создания индексов, по строго определённому минимальному набору атрибутов. Данные способы описаны в различных публикациях. Например, в работах Т. Хоуса, а далее в документации таких компаний, как Red Hat, Microsoft и IBM. Полезность данных способов очевидна до определённого количества записей каталога, так как с увеличением общего количества записей увеличивается и количество индексов, требуемых для обработки и хранения, а также размера кэша и периодичность его

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

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

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

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

Предметом исследования являются структуры хранения данных в службе каталогов и методика перепроектирования структуры хранения данных.

Для достижения поставленной цели были сформулированы следующие задачи:

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

2. Предложить структуру хранения данных, позволяющую уменьшить время отклика на запрос за счёт изменения структуры хранения данных с целью уменьшения количества записей для поиска.

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

4. Разработать метод перехода от иерархической структуры хранения данных (без учёта приоритетов использования параметров) к предлагаемой структуре, которая учитывает приоритеты использования параметров.

5. Разработать и протестировать методику перепроектирования структуры хранения данных службы каталогов для уменьшения времени отклика сервера службы каталогов на запросы клиентов к данным.

Основные положения, выносимые на защиту:

1. Методика перепроектирования структуры хранения данных службы каталогов.

2. Метод разбиения множества параметров каталога, хранящихся в службе каталогов, на подмножества с учётом приоритета их использования с целью уменьшения времени отклика на запрос.

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

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

Научная новизна:

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

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

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

Теоретическая значимость результатов исследования заключается в:

- проведении анализа основных факторов, влияющих на временную характеристику служб каталогов;

- определении условий эффективности работы служб каталогов;

- разработке методики перепроектирования структуры хранения данных служб каталогов для уменьшения времени отклика сервера службы каталогов на запрос клиентов к данным;

- разработке метода разбиения множества параметров каталога, хранящихся в службе каталогов, на подмножества с учётом приоритета их использования;

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

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

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

Апробация работы. Основные научные положения и результаты диссертационной работы докладывались, обсуждались и получили одобрение на научно-методических семинарах кафедры «Вычислительные системы и сети» ГУАП и докладывались на 72-й научной сессии ГУАП (апрель 2019, г. Санкт-Петербург).

Внедрение результатов диссертационной работы. Результаты работы применялись при проектировании и построении тестовых окружений сервисов служб каталогов выпусков Oracle Linux ООО «Оракл Девелопмент СПБ» и при проектировании сетевых решений на базе LWYDSA, разработанных ЗАО «ВизардСофт.Ру».

На специальное программное обеспечение для формирования сетевой структуры хранения данных службы каталогов получено свидетельство о государственной регистрации программ для ЭВМ №2019614753.

Личный вклад автора диссертационной работы заключается в:

- разработке методики перепроектирования структуры хранения данных службы каталогов для уменьшения времени отклика при запросе к данным;

- определению рабочего окружения существующих служб каталогов, основных параметров работы служб каталогов и способов хранения данных, формулированию условий работы служб каталогов;

- проведении анализа временной характеристики службы каталогов на основе встроенных инструментов и методов поиска, а также анализа основных факторов, влияющих на временные характеристики службы каталогов;

- предложении сетевой структуры хранения данных, позволяющей уменьшить время отклика на запрос за счёт изменения структуры хранения данных с целью уменьшения количества записей для поиска.

- предложении и разработке метода разбиения множества параметров каталога, хранящихся в службе каталогов, на подмножества с учётом приоритета их использования с целью уменьшения времени отклика на запрос.

- предложении и разработке метода перехода от иерархической структуры хранения данных (без учёта приоритетов использования параметров) к структуре с учётом приоритетов использования параметров;

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

Публикации по теме диссертации . Материалы, отражающие основное содержание и результаты диссертационной работы, опубликованы в 7 печатных

работах. Из них 3 работы опубликованы в рецензируемых научных журналах, внесённых в перечень ВАК, и 1 работа опубликована в издании, индексируемом в Scopus.

Объем и структура работы. Диссертация состоит из введения, четырёх разделов, заключения. Полный объём диссертации составляет 138 страниц с 24 рисунками и 10 таблицами и приложений, включающих акты внедрения, свидетельство о государственной регистрации программы для ЭВМ, примеры используемого исходного кода. Список используемых источников содержит 60 наименований.

Работа соответствует следующим областям исследований паспорта специальности 05.13.11 «Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей» :

-1 - Модели, методы и алгоритмы проектирования и анализа программ и программных систем, их эквивалентных преобразований, верификации и тестирования.

- 2 - Модели, методы, алгоритмы, языки и программные инструменты для организации взаимодействия программ и программных систем.

- 3 - Системы управления базами данных и знаний.

- 9 - Модели, методы, алгоритмы и программная инфраструктура для организации глобально распределенной обработки данных.

-10 - Оценка качества, стандартизация и сопровождение программных систем.

1 СЛУЖБЫ КАТАЛОГОВ И ИХ РАБОЧЕЕ ОКРУЖЕНИЕ

1.1 Вводные замечания

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

Первоначально Lightweight Directory Access Protocol или сокращено LDAP проектировался и разрабатывался в роли легковесного альтернативного сетевого протокола доступа к существующим на то время службам каталогов DAP. LDAP стандартизирован в виде технических спецификаций - RFC (Requests For Comments). Стандарт был разработан в 1997 году как RFC 2251 и получил широкое распространение в индустрии. Оригинальная спецификация была обновлена в 2006 году. Набор обновленных спецификаций RFC 4510 - 4519 предоставляет более раскрытую, понятную и связную спецификацию протокола. На текущее время последующих обновлений спецификаций добавлено не было.

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

Каталоги в общем и каталоги LDAP в частности ни в коем случае не являются новыми или редкими в мире информационных технологий, а наоборот широко применяются в малых, средних и крупных организациях различного назначения. В данном разделе даётся описание основных идей и рабочего окружения служб каталогов, где архитектура каталога соответствует техническим спецификация RFC 4510 - 4519.

1.2 Службы каталогов

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

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

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

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

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

определенным образом и предназначенный для выполнения только одной конкретной задачи - поиск информации в отсортированном по одному признаку списке записей. АО «ТВСЗ»

Промплощадка

187556, г. Тихвин, Ленинградская область + 7 (81367) 31-680, 31-612

Как упоминалось ранее, этот вид каталога (телефонный справочник) содержит конкретную информацию, организованную особым образом, предназначенную для выполнения одной определённой задачи: это поиск информация о том, как связаться с конкретным предприятием (АО «ТВСЗ»), организованной по знакомому шаблону (адрес и номер телефона). Телефонный справочник разработан таким образом, чтобы человек, используя определённое имя (название организации), мог быстро просмотреть каталог (который упорядочен в алфавитном порядке по названию организации или предприятия) и найти нужную контактную информацию.

Но есть несколько особенностей, которые стоит отметить в записи телефонного справочника:

- данные упорядочены для поиска только по одному критерию: название. Если у вас есть телефонный номер организации или адрес, но не её полное название, то поиск в телефонном справочнике соответствующего телефонного номера или адреса с целью уточнения название организации будет длительным и трудоёмким занятием.

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

Имя организации: АО «ТВСЗ»

Адрес: Промплощадка

Город: Тихвин

Облась: Ленинградская Почтовый индекс: 187556 Страна: Российская Федерация Номер телефона: [phone] Номер телефона: [phone]

В таком виде информация обозначается более явным способом, где каждому значению предшествует идентификатор, который явно обозначает тип предоставленной информации. АО «ТВСЗ» теперь идентифицируется как имя организации. Информация также разбита на более мелкие части (город и область на отдельных строках), а некоторая информация, которая была подразумеваема в предыдущей записи (например, страна), была сделана явной. И там, где две части информации (два телефонных номера) изначально были сжаты в одну строку, теперь они разделены, что делает информацию более явной.

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

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

Запись - это единица или объект каталога, в которой хранится информация об отдельном элементе в каталоге. Опять же, полезно использовать идеи, найденные в других каталогах: запись в телефонном справочнике описывает конкретную единицу информации в этом справочнике. Аналогичным образом, запись в каталоге LDAP содержит информацию о конкретной единице, не смотря на то, что точная цель этой единицы не указана (поскольку протокол описывает

каталог общего назначения). Это может быть человек, или компания, или какая-то виртуальная сущность, подобная объекту Java.

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

Список литературы диссертационного исследования кандидат наук Андреев Андрей Васильевич, 2020 год

СПИСОК ЛИТЕРАТУРЫ

1. List of LDAP software [Электронный ресурс] // https://en.wikipedia.org/wiki/List_of_LDAP_software

2. Microsoft Active Directory [Электронный ресурс] //https://discovery.hgdata.com/product/microsoft-active-directory

3. Zimbra Directory Service (LDAP) [Электронный ресурс] // https://wiki .zimbra.com/wiki/Zimbra_Directory_Service_(LDAP)

4. Top 5 Challenges with OpenLDAP [Электронный ресурс] // https://jumpcloud.com/blog/top-5-challenges-with-openldap/

5. Bohn, R., James. S. How Much Information? // Report on American Consumers 2009

6. RFC 4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Roadmap [Электронный ресурс] // https://tools.ietf.org/html/rfc4510

7. RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol [Электронный ресурс] // https://tools.ietf.org/html/rfc4511

8. RFC 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models [Электронный ресурс] // https://tools.ietf.org/html/rfc4512

9. RFC 4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms [Электронный ресурс] // https://tools.ietf.org/html/ rfc4513

10. RFC 4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names [Электронный ресурс] // https://tools.ietf.org/html/rfc4514

11. RFC 4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters [Электронный ресурс] // https://tools.ietf.org/html/rfc4515

12. RFC 4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator [Электронный ресурс] // https://tools.ietf.org/html/rfc4516

13. RFC 4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules [Электронный ресурс] // https://tools.ietf.org/html/rfc4517

14. RFC 4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation [Электронный ресурс] // https://tools.ietf.org/html/rfc4518

15. RFC 4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications [Электронный ресурс] // https://tools.ietf.org/html/rfc4519

16. RFC 4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) [Электронный ресурс] // https://tools.ietf.org/html/rfc4520

17. RFC 4521 Considerations for Lightweight Directory Access Protocol (LDAP):Extension [Электронный ресурс] // https://tools.ietf.org/html/rfc4521

18. ISO/IEC 9594 Information technology - Open Systems Interconnection -TheDirectory: Models [Электронный ресурс] // https://www.iso.org/standard/72557.html

19. Gary Anderson, Articles and Tips: How to Configure and Optimize eDirectory LDAP Servers [Электронный ресурс] // https://support.novell.com/techcenter/articles/ana20000904.html

20. Glenn W., Simpson M.T. Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure / W. Glenn, M. T. Simpson - Microsoft Press, 2004. - 459p.

21. Butcher M. Mastering OpenLDAP: Configuring, Securing and Integrating Directory Services / M. Butcher - Packt Publishing, 2007. - 484 p.

22. Андреев А.В. OpenLDAP как замена AD / А.В. Андреев // Linux Format. - 2011. - № 3 (142). - С. 40-43

23. Андреев А.В. Службы с LDAP-аутентификацией / А.В. Андреев // Linux Format. - 2011. - № 5. - С. 40-43

24. Инструменты хранения и обработки данных [Электронный ресурс] // https : //www.openldap.org/doc/ admin24/backends .html

25. Sobell G. M. A Practical Guide to Fedora and Red Hat Enterprise Linux, Seventh Edition / G.M. Sobell - Prentice Hall, 2014. - 1338 p.

26. Van Baarsen J. GitLab Cookbook / J. Van Baarsen - Packt Publishing, 2014. - 172 p.

27. Kalsi T. Cover Practical Linux Security Cookbook / T. Kalsi - Packt Publishing, 2016. - 276 p.

28. Ахо В.А., Хопкрофт Э.Д., Ульман Д.Д. Структуры данных и алгоритмы / В.А. Ахо, Э.Д. Хопкрофт, Д.Д. Ульман - М. : Издательский дом «Вильямс», 2001. - 384 с.

29. Overview of the Searching Algorithm [Электронный ресурс] - // https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/ Administration_Guide/Managing_Indexes.html#About_Indexes-Overview_of_the_Searching_Algorithm

30. 389 Directory Server Documentation [Электронный ресурс] // https://directory.fedoraproject.org/docs/389ds/documentation.html

31. Windos Server 2003 [Электронный ресурс] // https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755809(v=ws.10)

32. Лав Р. Linux системное программирование / Р. Лав. - 2-е изд. - СПБ.: Питер, 2014 - 448 с.

33. Документация ядра GNU/Linux [Электронный ресурс] // https://www.kernel.org/doc/Documentation/filesystems/proc.txt

34. Yadava H. The Berkeley DB Book / H. Yadava - Apress, 2007. - 444 p.

35. Tuning [Электронный ресурс] // https://www.openldap.org/doc/admin24/tuning.html

36. Eckstein R., Carter G., Ts J. Using Samba / R. Eckstein, G. Carter , J. Ts O'Reilly Media, Inc., 2007, 600 p.

37. Indexing Attributes in the Directory [Электронный ресурс] // https://docs.oracle.eom/cd/E15217_01/doc.1014/e12490/perform.htm#CFHICJI

38. Managing Indexes [Электронный ресурс] // https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/ Administration_Guide/Managing_Indexes.html

39. Lowe-Norris A., Desmond B., Richards J., Allen R. Active Directory / A. Lowe-Norris, B. Desmond, J. Richards , R. Allen - O'Reilly Media, Inc., 2008, 866 p.

40. LDAP Setup and Configuration Guide [Электронный ресурс] // https://docs.oracle.com/cd/E19455-01/806-5580/6jej518pd/index.html

41. LDAP Indexes [Электронный ресурс] // https://ldapwiki.com/wiki/LDAP %20Indexes

42. Гордеев А.В., Андреев А.В. Структура каталога как фильтр поиска записей службы каталогов OpenLDAP / А.В. Гордеев, А.В. Андреев // Информационно-управляющие системы. - 2019. - № 2. - С. 52-56. https://doi.org/10.31799/1684-8853-2019-2-52-56

43. Miller R. B. Response Time in Man-Computer Conversational Transactions. / R. B. Miller // International Business Machines (IBM) Corporation, Fall Joint Computer Conference, Poughkeepsie, New York. - 1968. - Vol. 1. - p. 267-277. https://doi.org/10.1145/1476589.1476628

44. Shneiderman B. Designing the user interface: Strategies for effective humancomputer interaction, 1st edition / B. Shneiderman - Addison-Wesley,Reading, MA., 1987. - 448 p.

45. Seow S. C. Designing and Engineering Time: The Psychology of Time Perception in Software / S.C. Seow — Addison-Wesley, 2008, 198p.

46. Doherty R., Sorenson P. Keeping Users in the Flow: Mapping System Responsiveness with User Experience / R. Doherty, P. Sorenson // Procedia Manufacturing. - 2015. - №3. - p. 4384-4391. 10.1016/j.promfg.2015.07.436.

47. Hoxmeier J., DiCesare C. System Response Time and User Satisfaction: An Experimental Study of Browser-based Applications / J. Hoxmeier, C. DiCesare -AMCIS 2000 Proceedings, 2000, 347 p.

48. Stupak, N. Time delays and system response times in human-computer interaction: Thesis / Noah Stupak - Rochester Institute of Technology, 2009 - 104p.

49. Kohrs C., Angenstein N., Brechmann A. Delays in Human-Computer Interaction and Their Effects on Brain Activity / C. Kohrs, N. Angenstein, A. Brechmann // PLoS ONE 11(1): e0146250, https://doi.org/10.1371/journal.pone.0146250

50. Howes Т., Smith М., Good G. Understanding and Deploying LDAP Directory Services / T. Howes, M. Smith , G. Good - Addison-Wesley Professional, 2003. - 899 p.

51. Jain R. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling / R. Jain - Wiley, 1991. -685 p.

52. Карпова И.П. Базы данных. Учебное пособие. / И.П. Карпова -Московский государственный институт электроники и математики (Технический университет). - М., 2009. - 131 с.

53. Бураков П.В., Петров В.Ю. Введение в системы баз данных: Учебное пособие. / П.В. Бураков, В.Ю. Петров - СПб: СПбГУ ИТМО, 2010. - 128 с.

54. Liu L., Ozsu M.T. Encyclopedia of Database Systems / L. Liu, M.T Ozsu.-Springer US, 2009. - 3748 p.

55. Celko J. Trees and Hierarchies in SQL for Smarties, 2nd Edition / J. Celko -Morgan Kaufmann, 2012. - 296 p.

56. Андреев А.В. Оптимизация службы каталогов OpenLDAP: дис. ... маг. тех. и тех.: 20.07. 2011. / А.В. Андреев - СПбГУАП, Санкт-Петербург, 2011 - 90 с.

57. Татт У. Теория графов / У. Татт - М. : Мир, 1988. - 424 с.

58. Karasulu A. Aliases and Search [Электронный ресурс] // https://people.apache.org/~akarasulu/alias-dereferencing.pdf

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

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

ПРИЛОЖЕНИЕ А Исходный код функции do_search() клиента ldapsearch

static int dosearch(

LDAP *ld,

char *base,

int scope,

char *filtpatt,

char *value,

char **attrs,

int attrsonly,

LDAPControl **sctrls,

LDAPControl **cctrls,

struct timeval *timeout,

int sizelimit ) {

char *filter; // Объявление всех переменных

int rc, rc2 = LDAP_OTHER;

int nresponses;

int nentries;

int nreferences;

int nextended; int npartial;

LDAPMessage *res, *msg;

ber_int_t msgid;

char *retoid = NULL;

struct berval *retdata = NULL;

int nresponses_psearch = -1;

int cancel_msgid = -1;

struct timeval tv, *tvp = NULL;

struct timeval tv_timelimit, *tv_timelimitp = NULL;

if( filtpatt != NULL ) { // Проверка входных параметров

size_t max_fsize = strlen( filtpatt ) + strlen( value ) + 1, outlen;

filter = malloc( max_fsize );

if( filter == NULL ) {

perror( "malloc" );

return EXIT_FAILURE; }

outlen = snprintf( filter, max_fsize, filtpatt, value ); if( outlen >= max_fsize ) {

fprintf( stderr, "Bad filter pattern: \"%s\"\n", filtpatt ); free( filter );

return EXIT FAILURE;

}

if ( verbose ) {

fprintf( stderr, _("filter: %s\n"), filter ); // Проверка входных параметров }

if( ldif < 2 ) { // Проверка входных параметров

printf( _("#\n# filter: %s\n#\n"), filter ); }

} else {

filter = value; }

if ( dont ) { // Проверка входных параметров

if ( filtpatt != NULL ) {

free( filter ); }

return LDAP_SUCCESS; }

if ( timelimit > 0 ) { tv_timelimit.tv_sec = timelimit; tv_timelimit.tv_usec = 0;

tv_timelimitp = &tv_timelimit; }

rc = ldap_search_ext( ld, base, scope, filter, attrs, attrsonly, // Инициализая дополнительных

sctrls, cctrls, tv_timelimitp, sizelimit, &msgid ); // параметров для поиска if ( filtpatt != NULL ) {

free( filter ); }

if( rc != LDAP_SUCCESS ) {

tool_perror( "ldap_search_ext", rc, NULL, NULL, NULL, NULL );

return( rc );

}

nresponses = nentries = nreferences = nextended = npartial = 0;

res = NULL;

if ( timelimit > 0 ) {

/* disable timeout */

tv.tv_sec = -1;

tv.tv_usec = 0;

tvp = &tv; }

while ((rc = ldap_result( ld, LDAP_RES_ANY, // Цикл while который работает до

sortattr ? LDAP_MSG_ALL : LDAP_MSG_ONE, // обработки всех записей, проверяя

tvp, &res )) > 0 ) // возвращаемые сообщения от службы

{ // каталогов

if ( tool_check_abandon( ld, msgid ) ) {

return -1;

}

if( sortattr ) {

(void) ldap_sort_entries( ld, &res,

( *sortattr == '\0' ) ? NULL : sortattr, strcasecmp );

}

for ( msg = ldap_first_message( ld, res ); о суще ствляется

// Цикл в котором

msg != NULL;

// переход по всем записям каталога,

msg = ldap_next_message( М, msg ) ) // начиная с первой записью, полученной

{ // при вызове функции ldap_first_message()

if ( nresponses++ ) putchar('\n'); if ( nresponses_psearch >= 0 ) nresponses_psearch++; switch( ldap_msgtype( msg ) ) {

case LDAP RES SEARCH ENTRY:

// Перебор полученного сообщения // Обработка сообщений типа

nentries++; // LDAP_RES_SEARCH_ENTRY

print_entry( ld, msg, attrsonly );

break;

case LDAP_RE S_SEARCH_REFERENCE: // Обработка сообщений типа

nreferences++;

print_reference( ld, msg );

break;

case LDAP RES EXTENDED:

nextended++;

print_extended( ld, msg ); if ( ldap_msgid( msg ) == 0 ) {

// LDAP RES SEARCH REFERENCE

// Обработка сообщений типа

// LDAP RES EXTENDED

/* unsolicited extended operation */

goto done; }

if ( cancel_msgid != -1 && cancel_msgid == ldap_msgid( msg ) ) { printf(_("Cancelled \n"));

prmtf(_("cancel_msgid = %d\n"), cancel_msgid);

goto done; }

break;

case LDAP_RES_SEARCH_RESULT: // Обработка сообщений типа

/* pagedResults stuff is dealt with * in tool_print_ctrls(), called by

// LDAP RES SEARCH RESULT

* print_results(). */

rc2 = print_result( ld, msg, 1 );

if ( ldapsync == LDAP_SYNC_REFRESH_AND_PERSIST ) {

break;

}

goto done;

// Переход к выводу результатов поиска

case LDAP RES INTERMEDIATE:

// Обработка сообщений типа

npartial++;

// LDAP RES INTERMEDIATE

ldap_parse_intermediate( ld, msg, &retoid, &retdata, NULL, 0 );

nresponses_psearch = 0;

if ( strcmp( retoid, LDAP_SYNC_INFO ) == 0 ) { printf(_(" SyncInfo Received\n")); ldap_memfree( retoid ); ber_bvfree( retdata );

break; }

print_partial( ld, msg ); ldap_memfree( retoid ); ber_bvfree( retdata );

goto done; // Переход к выводу результатов поиска

}

if ( ldapsync && sync_slimit != -1 && nresponses_psearch >= sync_slimit ) { BerElement *msgidber = NULL; struct berval *msgidvalp = NULL; msgidber = ber_alloc_t(LBER_USE_DER); ber_printf(msgidber, "{i}", msgid); ber_flatten(msgidber, &msgidvalp); ldap_extended_operation(ld, LDAP_EXOP_CANCEL, msgidvalp, NULL, NULL, &cancel_msgid); nresponses_psearch = -1;

}

}

ldap_msgfree( res ); }

done: // Вывод результатов поиска

if ( tvp == NULL && rc != LDAP_RES_SEARCH_RESULT ) {

ldap_get_option( ld, LDAP_OPT_RESULT_CODE, (void *)&rc2 ); }

ldap_msgfree( res );

if ( pagedResults ) {

npagedresponses += nresponses;

npagedentries += nentries;

npagedextended += nextended;

npagedpartial += npartial;

npagedreferences += nreferences;

if ( ( pr_morePagedResults == 0 ) && ( ldif < 2 ) ) {

printf( _("\n# numResponses: %d\n"), npagedresponses );

if( npagedentries ) { // Вывод обработанных типов записей

printf( _("# numEntries: %d\n"), npagedentries ); }

if( npagedextended ) {

printf( _("# numExtended: %d\n"), npagedextended ); }

if( npagedpartial ) {

printf( _("# numPartial: %d\n"), npagedpartial ); }

if( npagedreferences ) {

printf( _("# numReferences: %d\n"), npagedreferences ); }

}

} else if ( ldif < 2 ) { // Вывод обработанных типов записей

printf( _("\n# numResponses: %d\n"), nresponses );

if( nentries ) printf( _("# numEntries: %d\n"), nentries );

if( nextended ) printf( _("# numExtended: %d\n"), nextended );

if( npartial ) printf( _("# numPartial: %d\n"), npartial );

if( nreferences ) printf( _("# numReferences: %d\n"), nreferences ); }

if ( rc != LDAP_RES_SEARCH_RESULT ) {

tool_perror( "ldap_result", rc2, NULL, NULL, NULL, NULL ); }

return( rc2 );

}

ПРИЛОЖЕНИЕ Б Исходный код тестового сценария для раздела 2

#! /usr/bin/python

import ldap import sys import time import random

number_of_entries = 150000 step = 10000

def main():

con = ldap.initialize('ldap://localhost:389') dn = "cn=admin,dc=example,dc=com" pw = "123456" con.simple_bind_s(dn, pw) for i in range(1,number_of_entries, step): for user_id in range(i,i+step): username = 'User' + str(user_id)

add_record = [ # формирование записи

('objectclass',

[b'top',b'person',b'organizationalPerson',b'inetOrgPerson',b'posixAccount']), ('uid', [username.encode('utf-8')]), ('cn', [(username+'_').encode('utf-8')] ), ('sn', [(username+'--').encode('utf-8')] ), ('userpassword', [b'secret']), ('ou', [b'People']),

('mail', [(username+"@example.com").encode('utf-8')]), ('uidNumber', [str(step+user_id).encode('utf-8')]), ('gidNumber', [str(step+user_id).encode('utf-8')]), ('homeDirectory', [('/home/'+username).encode('utf-8')]), ('loginShell', [b'/bin/bash'])

]

con.add_s('uid='+username+',ou=People,dc=example,dc=com', add_record) search_1_attr(i+step,i)

def search_1_attr(N, iteration): # функция поиска одного атриба записи filename = './test4_1_filter_' + str(iteration) + '.txt' con = ldap.initialize('ldap://localhost:389') dn = "cn=admin,dc=example,dc=com" pw = "123456" con.simple_bind_s(dn, pw) base_dn = 'ou=People,dc=example,dc=com'

results = dict()

for user_id in range(1,N,1000):

username = 'User' + str(random.randrange(1,N)) filters = 'uid='+username attrs = ['ou'] ts1 = time.time()

result = con.search_s( base_dn, ldap.SCOPE_SUBTREE, filters, attrs ) ts2 = time.time() results[str(result)] = ts2-ts1 with open(filename,'w+') as f: for k,v in results.items(): f.write(k + '=' + str(v) + '\n')

if_name_== "_main_":

main()

ПРИЛОЖЕНИЕ B Примеры исходного кода тестовых сценариев для раздела 4

#! /usr/bin/python

'''Тестовый сценарий для иерархической структуры'''

import ldap

import sys

import time

import random

number_of_entries = 150000 step = 10000

def main():

con = ldap.initialize('ldap://localhost:389') dn = "cn=admin,dc=example,dc=com" pw = "123456" con.simple_bind_s(dn, pw) for i in range(1,number_of_entries, step): for user_id in range(i,i+step): username = 'User' + str(user_id)

if random.getrandbits(1) == 0: # print("samba")

add_record = [

('objectclass',

[b'top',b'person',b'organizationalPerson',b'inetOrgPerson',b'posixAccount',b'sambaSamA ccount']),

(' givenName', [username.encode('utf-8')]), ('uid', [username.encode('utf-8')]), ('cn', [(username+'_').encode('utf-8')] ), ('sn', [(username+'--').encode('utf-8')] ), ('sambaAcctFlags', b'[UD ]'),

('sambaSID',

[('S1521209874186934659823373637863451'+str(user_id)).encode('utf-8')]),

('sambaNTPassword',b'EE42945FD699570D2DA4C2A0BE29D35'),

('sambaLMPassword',b'8131BC5135B26C62C81667E9D738C5D9'),

('sambaPasswordHistory',b'000000000000000000000000000000000000 0000000000000000000000000000'),

('sambaPwdLastSet', b'1362051479'),

('userpassword', [b'secret']),

('ou', [b'People']),

('uidNumber', [str(step+user_id).encode('utf-8')]), ('gidNumber', [str(step+user_id).encode('utf-8')]), ('homeDirectory', [('/home/'+username).encode('utf-8')]), ('loginShell', [b'/bin/bash'])

]

elif user_id%2==0: print("Alias") add_record = [

('objectclass',

[b'top',b'person',b'organizationalPerson',b'inetOrgPerson',b'posixAccount',b'sambaSamA ccount',b'proxyAccount']),

('proxyAccess', [b'TRUE']),

(' givenName', [username.encode('utf-8')]),

('uid', [username.encode('utf-8')]),

('cn', [(username+'_').encode('utf-8')] ),

('sn', [(username+'--').encode('utf-8')] ),

('sambaAcctFlags', b'[UD ]'),

('sambaSID',

[('S1521209874186934659823373637863451'+str(user_id)).encode('utf-8')]),

('sambaNTPassword',b'EE42945FD699570D2DA4C2A0BE29D35'),

('sambaLMPassword',b'8131BC5135B26C62C81667E9D738C5D9'),

('sambaPasswordHistory',b'000000000000000000000000000000000000 0000000000000000000000000000'),

('sambaPwdLastSet', b'1362051479'),

('userpassword', [b'secret']),

('ou', [b'People']),

('uidNumber', [str(step+user_id).encode('utf-8')]), ('gidNumber', [str(step+user_id).encode('utf-8')]),

('homeDirectory', [('/home/'+username).encode('utf-8')]), ('loginShell', [b'/bin/bash'])

]

else:

# print(" squid")

add_record = [

('objectclass',

[b'top',b'person',b'organizationalPerson',b'inetOrgPerson',b'proxyAccount']), ('uid', [username.encode('utf-8')]), ('proxyAccess', [b'TRUE']), ('cn', [(username+'_').encode('utf-8')] ), ('sn', [(username+'--').encode('utf-8')] ), (' givenName', [username.encode('utf-8')]), ('userpassword', [b'secret'])

]

print("Adding: " + str(user_id))

con.add_s('uid='+username+',ou=People,dc=example,dc=com', add_record) search_samba(i+step,i) search_squid(i+step,i)

def search_samba(N, iteration):

filename = './samba_h_' + str(iteration) + '.txt' con = ldap.initialize('ldap://localhost:389') dn = "cn=admin,dc=example,dc=com"

pw = "123456" con.simple_bind_s(dn, pw)

base_dn = 'ou=People,dc=example,dc=com' results = dict()

for user_id in range(1,N,1000):

username = 'User' + str(random.randrange(1,N))

filters = '(&(uid='+username+')(objectclass=sambaSamAccount))'

attrs = ['sambaSID']

ts1 = time.time()

result = con.search_s( base_dn, ldap.SCOPE_SUBTREE, filters, attrs ) ts2 = time.time() results[str(result)] = ts2-ts1 with open(filename,'w+') as f: for k,v in results.items(): f.write(k + '=' + str(v) + '\n')

def search_squid(N, iteration):

filename = './squid_h_' + str(iteration) + '.txt' con = ldap.initialize('ldap://localhost:389') dn = "cn=admin,dc=example,dc=com" pw = "123456" con.simple_bind_s(dn, pw)

base_dn = 'ou=People,dc=example,dc=com' results = dict()

for user_id in range(1,N,1000):

username = 'User' + str(random.randrange(1,N))

filters = '(&(uid='+username+')(objectQass=proxyAccount))'

attrs = ['proxyAccess']

ts1 = time.time()

result = con.search_s( base_dn, ldap.SCOPE_SUBTREE, filters, attrs ) ts2 = time.time() results[str(result)] = ts2-ts1 with open(filename,'w+') as f: for k,v in results.items(): f.write(k + '=' + str(v) + '\n')

if_name_== "_main_":

main()

#! /usr/bin/python

'''Тестовый сценарий для сетевой структуры''' import ldap import sys import time

import random

number_of_entries = int(sys.argv[1]) start = int(sys.argv[2]) ind_name = sys.argv[3] step = 10000

def main():

search_samba(number_of_entries,start) search_squid(number_of_entries,start)

def search_samba(N, iteration):

filename = './samba_ind_n_' + ind_name + '_' + str(iteration) + '.txt'

con = ldap.initialize('ldap://localhost:389')

dn = "cn=admin,dc=example,dc=com"

pw = "123456"

con.simple_bind_s(dn, pw)

base_dn = 'ou=samba,dc=example,dc=com'

results = dict()

for user_id in range(1,N,1000):

username = 'User' + str(random.randrange(1,N)) filters = '(uid='+username+')' attrs = ['sambaSID']

ts1 = time.time()

result = con.search_s( base_dn, ldap.SCOPE_SUBTREE, filters, attrs ) ts2 = time.time() results[str(result)] = ts2-ts1 con.unbind()

with open(filename,'w+') as f: for k,v in results.items(): f.write(k + '=' + str(v) + '\n')

def search_squid(N, iteration):

filename = './squid_ind_n_' + ind_name + '_' + str(iteration) + '.txt'

con = ldap.initialize('ldap://localhost:389')

dn = "cn=admin,dc=example,dc=com"

pw = "123456"

con.simple_bind_s(dn, pw)

base_dn = 'ou=squid,dc=example,dc=com'

results = dict()

for user_id in range(1,N,1000):

base_dn = 'ou=squid,dc=example,dc=com' username = 'User' + str(random.randrange(1,N)) filters = '(uid='+username+')' attrs = ['proxyAccess', 'aliasedObjectName'] ts1 = time.time()

result = con.search_s( base_dn, ldap.SCOPE_SUBTREE, filters,attrs) ts2 = time.time() search_time = ts2-ts1

if (len(result)>0) and ('aliasedObjectName' in result[0][1].keys() ): print "Alias", result attrs = ['proxyAccess']

base_dn = result[0][1]['aliasedObjectName'][0] print base_dn tsa1 = time.time()

result = con.search_s( base_dn, ldap.SCOPE_SUBTREE, attrlist=attrs ) print result tsa2 = time.time() search_time += tsa2 - tsa1 results[str(result)] = search_time con.unbind()

with open(filename,'w+') as f: for k,v in results.items(): f.write(k + '=' + str(v) + '\n')

if_name_== "_main_":

main()

ПРИЛОЖЕНИЕ Г Свидетельство о государственной регистрации программы для ЭВМ

ПРИЛОЖЕНИЕ Д

АКТ

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

Настоящий акт составлен в том, что основные результаты диссертационной работы Андреева A.B. "Методика перепроектирования структуры хранения данных службы каталогов":

• методика перепроектирования структуры хранения данных службы каталогов;

• метод разбиения множества параметров каталога, хранящихся в службе каталогов, на подмножества с учётом приоритета их использования с целью уменьшения времени отклика на запрос;

• метод перехода от иерархической структуры хранения данных без учёта приоритетов использования параметров к структуре с учётом приоритетов использования параметров на основе анализа основных параметров работы службы каталогов и способов хранения данных, - были использованы при проектировании и построении тестовых окружений сервисов служб каталогов выпусков Oracle Linux, что позволило значительно эффективнее использовать сетевые ресурсы, уменьшив время отклика на запрос к наиболее приоритетным данным.

Директор по разработке ПО 8 апреля 2019 г.

Исаенко В.Н.