 |
Сервер Информационных Технологий содержит море(!) аналитической информации |
Сервер поддерживается |
|---|
|
Сервер Информационных Технологий содержит море(!) аналитической информации |
Сервер поддерживается |
|---|
Подобно большой организации, большая корпоративная сеть нуждается в централизованном хранении как можно более полной справочной информации о самой себе (начиная с данных о пользователях, серверах, рабочих станциях и кончая данными о кабельной системе). Естественно организовать эту информацию в виде базы данных, ведение которой поручить сетевой операционной системе. Данные из этой базы могут быть востребованы многими сетевыми системными приложениями, в первую очередь системами управления и администрирования. Кроме этого, такая база полезна при организации электронной почты, систем коллективной работы, службы безопасности, службы инвентаризации программного и аппаратного обеспечения сети, да и для практически любого крупного бизнес-приложения.
Хотя полезных применений единой справочной службы много, она нужна по крайней мере для эффективного решения задачи администрирования, то есть ведения учетной информации на пользователей сети и определения прав доступа этих пользователей к разделяемым ресурсам сети. Эта задача всегда решалась каким-либо способом во всех многопользовательских операционных системах, не обязательно сетевых. В локальных версиях UNIX имеются файлы с предопределенными именами, хранящие эту информацию - например, файл /etc/passwd хранит информацию о пользователях и их паролях, а также о группах пользователей.
В идеале сетевая справочная информация должна быть реализована в виде единой базы данных, а не представлять собой набор баз данных, специализирующихся на хранении информации того или иного вида, как это часто бывает в реальных операционных системах. Например, в Windows NT имеется по крайней мере пять различных типов справочных баз данных. Главный справочник домена (NT Domain Directory Service) хранит информацию о пользователях, которая используется при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных поддерживают разрешение низкоуровневых адресов: WINS - устанавливает соответствие Netbios-имен IP-адресам, справочник DNS - сервер имен домена - оказывается полезным при подключении NT-сети к Internet, и наконец, справочник протокола DHCP используется для автоматического назначения IP-адресов компьютерам сети. Ближе к идеалу находятся справочные службы, поставляемые фирмой Banyan (продукт Streettalk III) и фирмой Novell (NetWare Directory Services), предлагающие единый справочник для всех сетевых приложений.
Единая база данных, хранящая справочную информацию, предоставляет все то же многообразие возможностей и порождает все то же множество проблем, что и любая другая крупная база данных. Она позволяет осуществлять различные операции поиска, сортировки, модификации и т.п., что очень сильно облегчает жизнь как администраторам, так и пользователям. Набор разрозненных баз данных не предоставляет такого прозрачного доступа к ресурсам сети, как это имеет место в случае использования ОС NetWare 3.x с ее базой bindery, локальной для каждого сервера. В последнем случае пользователь должен заранее знать, на каком сервере находится нужный ему ресурс и производить логическое подключение к этому серверу для получения доступа к этому ресурсу. Для того, чтобы получить доступ к ресурсам какого-нибудь сервера, пользователь должен иметь там свою учетную информацию, которая дублируется таким образом на всех серверах сети. В единой базе данных о каждом пользователе существует только одна запись.
Но за удобства приходится расплачиваться решением проблем распределенности, репликации и синхронизации, которые возникают при построении крупномасштабной базы данных для большой сети.
Реализация справочной службы над полностью централизованной базой данных, хранящейся только в виде одной копии на одном из серверов сети, не подходит для большой системы по нескольким причинам, и в первую очередь из-за низкой производительности и низкой надежности такого решения. Производительность будет низкой из-за того, что запросы на логический вход всех пользователей будут поступать в единственный сервер, который при большом количестве пользователей обязательно перестанет справляться с их обработкой, то есть такое решение плохо масштабируется в отношении количества пользователей и разделяемых ресурсов. Надежность также не может быть высокой в системе с единственной копией данных. Кроме снятия ограничений по производительности и надежности, желательно, чтобы структура базы данных позволяла производить логическое группирование ресурсов и пользователей по структурным подразделениям предприятия и назначать для каждой такой группы своего администратора.
Проблемы сохранения производительности и надежности при увеличении масштаба сети решаются за счет использования распределенных баз данных справочной информации. Разделение данных между несколькими серверами снижает нагрузку на каждый сервер, а надежность при этом достигается за счет наличия нескольких копий (называемых часто репликами) каждой части базы данных. Для каждой части базы данных можно назначить своего администратора, который обладает правами доступа только к объектам своей порции информации о всей системе. Для пользователя же (и для сетевых приложений) такая распределенная база данных представляется единой базой данных, которая обеспечивает доступ ко всем ресурсам сети вне зависимости от того, с какой рабочей станции осуществил свой вход в сеть пользователь.
Существует два подхода к организации справочной службы сети: доменный и глобальный. Рассмотрим эти подходы на конкретных примерах - доменной справочной службе ОС Windows NT и глобальной справочной службе NDS ОС NetWare. Естественно, это не единственные операционные системы, где такие службы имеются - доменная служба реализована в Microsoft LAN Manager и IBM LAN Server, а глобальная справочная служба - в ОС Banyan VINES (служба Streettalk III). Более того, существует стандарт X.500, разработанный МККТТ для глобальной справочной службы почтовых систем, который с успехом может применяться и применяется для хранения любой справочной информации.
Домен - это основная единица администрирования и обеспечения безопасности в Windows NT. Для домена существует общая база данных учетной информации пользователей (user accounts), так что при входе в домен пользователь получает доступ сразу ко всем разрешенным ресурсам всех серверов домена.
Доверительные отношения (trust relationships) обеспечивают транзитную аутентификацию, при которой пользователь имеет только одну учетную запись в одном домене, но может получить доступ к ресурсам всех доменов сети.
Рис. 3.20. Доверительные отношения между доменами
Пользователи могут входить в сеть не только из рабочих станций того домена, где хранится их учетная информация, но и из рабочих станций доменов, которые доверяют этому домену. Домен, хранящий учетную информацию, часто называют учетным, а доверяющий домен - ресурсным.
Доверительные отношения не являются транзитивными. Например, если домен А доверяет домену В, а В доверяет С, то это не значит, что А автоматически доверяет С.
В домене должен находится сервер, выполняющий роль основного контроллера домена (primary domain controller). Этот контроллер хранит первичную копию базы данных учетной информации пользователей домена. Все изменения, производимые в учетной информации, сначала производятся именно в этой копии. Основной контроллер домена всегда существует в единственном экземпляре. Пользователь, который администрирует домен, не должен явно задавать имя компьютера, который выполняет роль основного контроллера, утилита, в помощью которой осуществляется администрирование (в Windows NT это User Manager for Domains), должна по имени домена самостоятельно, в соответствии с заранее разработанным протоколом провести диалог с основным контроллером домена и сделать нужные изменения в его базе данных.
Кроме основного контроллера в домене могут существовать несколько резервных контроллеров (backup domain controllers). Эти контроллеры хранят реплики базы учетных данных. Все резервные контроллеры в дополнение к основному могут обрабатывать запросы пользователей на логический вход в домен.
Резервный контроллер домена решает две задачи:
Если сеть состоит из нескольких сетей, соединенных глобальными связями, то в каждой сети должен быть по крайней мере один резервный контроллер домена.
Обычный сервер (не основной или резервный контроллер домена) может быть членом домена, а может и не быть. Если он принимает участие в домене, то он пользуется учетной информацией, хранящейся на контроллере домена. Если же нет - то доступ ко всем его ресурсам имеют только пользователи, которые заведены в базе учетной информации этого сервера.
Механизм доменов можно использовать на предприятии различными способами. В зависимости от специфики предприятия можно объединить ресурсы и пользователей в различное количество доменов, а также по-разному установить между ними доверительные отношения.
Microsoft предлагает использовать четыре типовые модели использования доменов на предприятии:
Модель с одним доменом
Эта модель подходит для организации, в которой имеется не очень много пользователей, и нет необходимости разделять ресурсы сети по организационным подразделениям. Главный ограничитель для этой модели - производительность, которая падает, когда пользователи просматривают домен, включающий много серверов.
Использование только одного домена также означает, что сетевой администратор всегда должен администрировать все серверы. Разделение сети на несколько доменов позволяет назначать администраторов, которые могут администрировать только отдельные серверы, а не всю сеть.
Таблица 3.1.
Преимущества и недостатки модели с одним доменом
| Преимущества | Недостатки | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Наилучшая модель для предприятий с небольшим числом пользователей и ресурсов Централизованное управление пользовательской учетной информацией Нет нужды в управлении доверительными отношениями Локальные группы нужно определять только однажды | Низкая производительность, если домен имеет слишком много пользователей и/или серверов Невозможность группирования ресурсов | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Модель с главным доменом
Эта модель хорошо подходит для предприятий, где необходимо разбить ресурсы на группы в организационных целях, и в то же время количество пользователей и групп пользователей не очень велико. Эта модель сочетает централизацию администрирования с организационными преимуществами разделения ресурсов между несколькими доменами.
Главный домен удобно рассматривать как чисто учетный домен, основное назначение которого - хранение и обработка пользовательских учетных данных. Остальные домены в сети - это домены ресурсов, они не хранят и не обрабатывают пользовательскую учетную информацию, а поставляют ресурсы (такие как разделяемые файлы и принтеры) для сети. В этой модели пользовательскую учетную информацию хранят только основной и резервный контроллеры главного домена.
Рис. 3.21. Модель с главным доменом
Таблица 3.2.
Преимущества и недостатки модели с главным доменом
| Преимущества | Недостатки | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Наилучшая модель для предприятия, у которого не очень много пользователей, а разделяемые ресурсы должны быть распределены по группам Учетная информация может централизованно управляться Ресурсы логически группируются Домены отделов могут иметь своих администраторов, которые управляют ресурсами отдела Глобальные группы должны определяться только один раз (в главном домене) | Плохая производительность, если в главном домене слишком много пользователей и групп Локальные группы нужно образовывать в каждом домене, где они используются | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Модель с несколькими главными доменами
Эта модель предназначена для больших предприятий, которые хотят поддерживать централизованное администрирование. Эта модель в наибольшей степени масштабируема.
В данной модели имеется небольшое число главных доменов. Главные домены используются как учетные домены, причем учетная информация каждого пользователя создается только в одном из главным доменов. Сотрудники отдела Автоматизированных Информационных Систем (АИС) предприятия могут администрировать все главные домены, в то время как ресурсные домены могут администрировать сотрудники соответствующих отделов.
Рис. 3.22. Модель с несколькими главными доменами
Каждый главный домен доверяет всем остальным главным доменам. Каждый домен отдела доверяет всем главным доменам, но доменам отделов нет необходимости доверять друг другу.
Так как все ресурсные домены доверяют всем главным, то данные о любом пользователе могут использоваться в любом отделе предприятия.
Использование глобальных групп в этой модели несколько сложнее, чем в предыдущих. Если нужно образовать глобальную группу из пользователей, учетная информация которых хранится в разных главных доменах, то фактически приходится образовывать несколько глобальных групп - по одной в каждом главном домене. В модели с одним главным доменом нужно образовать только одну глобальную группу.
Чтобы упростить решение этой проблемы, целесообразно распределять пользователей по главным доменам по организационному принципу, а не по какому-либо иному, например, по алфавитному.
Таблица 3.3.
Преимущества и недостатки модели с несколькими главными доменами
| Преимущества | Недостатки | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Наилучшая модель для предприятия с большим числом пользователей, и центральным отделом АИС. Хорошо масштабируется. Ресурсы логически группируются. Домены отделов могут иметь своих администраторов, которые управляют ресурсами отдела. | Как локальные, так и глобальные группы должны определяться по нескольку раз в каждом учетном домене. Необходимо управлять большим количеством доверительных отношений. В одном домене локализуются не все данные о пользователях. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Модель с полными доверительными отношениями
Эта модель обеспечивает распределенное администрирование пользователей и доменов. В этой модели каждый домен доверяет каждому. Каждый отдел может управлять своим доменом, определяя своих пользователей и глобальные группы пользователей, и учетная информация о них может использоваться во всех доменах предприятия.
Рис. 3.23. Модель с полными доверительными отношениями
Из-за резкого увеличения числа доверительных отношений эта модель не подходит для больших предприятий. Для n доменов нужно установить n(n-1) доверительных отношений.
К этой модели полностью применим термин "доверие". Для создания доверительных отношений с другим доменом администратор действительно должен быть уверен, что он доверяет администратору того домена, особенно если он дает некоторые права глобальным группам другого домена. Как только такие права даны, местный администратор зависит от того, не добавит ли удаленный администратор в глобальную группу нежелательных или непроверенных пользователей в будущем. При администрировании главных доменов такая опасность также имеется. Но риск здесь ниже из-за того, что пользователей в главные домены добавляют сотрудники центрального отдела АИС, а не произвольно назначенный администратором сотрудник функционального отдела предприятия.
Таблица 3.4.
Преимущества и недостатки модели с полными доверительными отношениями
| Преимущества | Недостатки | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Наилучшим образом подходит для предприятий, на которых нет централизованного отдела АИС Хорошо масштабируется в отношении количества пользователей. Каждый отдел имеет полное управление над своими пользователями и ресурсами. Как ресурсы, так и пользователи группируются по отделам. | Модель не подходит для предприятий с централизованным отделом АИС. Нужно управлять очень большим количеством доверительных отношений. Каждый отдел должен довериться администраторам других отделов, что те не включат в состав своих глобальных групп нежелательных пользователей. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Служба NDS ОС NetWare 4.x - это глобальная служба справочников, использующая распределенную объектно-ориентированную базу данных сетевых ресурсов. База данных NDS содержит информацию о всех сетевых ресурсах, включая информацию о пользователях, группах пользователей, принтерах, томах и компьютерах. NetWare использует эту информацию для обеспечения доступа к этим ресурсам.
База данных NDS заменяет справочник bindery предыдущих версий NetWare. Справочник bindery - это "плоская" или одноуровневая база данных, разработанная для поддержки одного сервера. В ней также использовалось понятие "объект" для сетевого ресурса, но трактовка этого термина отличалась от общепринятой. Объекты bindery идентифицировались простыми числовыми значениями и имели определенные атрибуты. Однако для этих объектов не определялись явные взаимоотношения наследования классов объектов, поэтому взаимоотношения между объектами bindery устанавливались администратором произвольно, что часто приводило к нарушению целостности данных.
База данных службы NDS представляет собой многоуровневую базу данных, поддерживающую информацию о ресурсах всех серверов сети. Для совместимости с предыдущими версиями NetWare в службе NDS предусмотрен механизм эмуляции базы bindery.
Служба NDS представляет собой значительный шаг вперед по сравнению с предыдущими версиями за счет:
Распределенность заключается в том, что информация не хранится на одном сервере, а разделена на части, называемые разделами (partitions). NetWare хранит эти разделы на нескольких серверах сети (рисунок 3.24). Это свойство значительно упрощает администрирование и управление большой сетью, так как она представляется администратору единой системой. Кроме этого, обеспечивается более быстрый доступ к базе данных сетевых ресурсов за счет обращения к ближайшему серверу.
Рис. 3.24. Разделы базы данных NDS
Реплика - это копия информации раздела NDS. Можно создать неограниченное количество реплик каждого раздела и хранить их на разных серверах. Если один сервер останавливается, то копии этой информации могут быть получены с другого сервера. Это увеличивает отказоустойчивость системы, так как ни один из серверов не отвечает за всю информацию базы данных NDS.
Прозрачность заключается в том, что NDS автоматически создает связи между программными и аппаратными компонентами, которые обеспечивают пользователю доступ к сетевым ресурсам. NDS при этом не требует от пользователя знаний физического расположения этих ресурсов. Задавая сетевой ресурс по имени, вы получите к нему корректный доступ даже в случае изменения его сетевого адреса или места расположения.
Глобальность NDS заключается в том, что после входа вы получаете доступ к ресурсам всей сети, а не только одного сервера, как было в предыдущих версиях. Это достигается за счет процедуры глобального логического входа (global login). Вместо входа в отдельный сервер пользователь NDS входит в сеть. После чего он получает доступ к разрешенным для него ресурсам сети. Информация, предоставляемая во время логического входа, используется для процесса идентификации пользователя. Позже, при попытке пользователя получить доступ к ресурсам, таким как серверы, тома или принтеры, фоновый процесс идентификации проверяет, имеет ли пользователь право использовать данный ресурс.
Объектно-ориентированный подход
В NDS информация о сетевых ресурсах организована с помощью объектов. Каждый объект представляет собой ресурс, такой как принтер, том, пользователь или сервер.
Объекты организованы в иерархическую структуру, соответствующую структуре организации, отражающую реальные информационные потоки и потребности разделения ресурсов. Одни объекты представляют физические сущности, например объект-пользователь представляет пользователя, а объект-принтер представляет принтер. Другие объекты представляют логические понятия, такие как группы или очереди к принтерам.
Еще одна категория объектов, в которую входят, например, объекты типа отдела предприятия, помогают организовывать и упорядочивать другие объекты.
Объекты имеют атрибуты, в которых хранится индивидуальная для данного объекта информация, например, имя и телефон пользователя или место расположения факса и т.п.
Дерево каталогов
NDS использует для хранения информации логическую структуру, называемую деревом каталогов (Directory Tree, DT). Эта иерархическая структура имеет корневой элемент (root) и ветви (рисунок 3.25). Администратору сети NetWare 4.x предоставляется удобная графическая утилита NetWare Administrator, работающая в среде Windows, наглядно представляющая каждый объект дерева каталогов NDS в виде иконки и отражающая связи между объектами. Пользователи также получают удобства прозрачного доступа к ресурсам всей сети, если они пользуются оболочкой NetWare для Windows, которая поддерживает диалог с NDS и представляет доступные пользователю ресурсы в виде вложенных пиктограмм.
Дерево каталогов содержит объекты двух типов:
Объекты-контейнеры содержат или включают другие объекты. Они используются для логического упорядочивания и организации других объектов дерева.
NDS содержит объекты-контейнеры трех типов, которые можно использовать для организации дерева объектов:
Рис. 3.25. Типичная структура дерева каталогов NDS
Объекты-листья не содержат другие объекты, они используются для представления конечных сетевых ресурсов, таких как компьютеры, тома, принтеры, пользователи и группы пользователей. В NDS определены еще и такие типы объектов-листьев, как:
Служба NDS и файловая система
Служба NDS предназначена для управления такими сетевыми ресурсами, как серверы и тома NetWare, но она не обеспечивает управление файловой системой. Файлы и каталоги не являются объектами службы NDS. Однако они представляются в виде иконок при использовании графической утилиты NetWare Administrator. Одним из атрибутов объекта-тома является месторасположение физического тома, который содержит файлы и каталоги. Таким образом, объект-том представляет собой связь между NDS и файловой системой.
Служба NDS предоставляет средства для поиска объектов в ее базе данных сетевых ресурсов. Можно делать запросы, типичные для баз данных, например, поиск пользователей, живущих на одной улице и т.п. Можно также сделать запрос о значениях всех атрибутов какого-либо конкретного объекта.
NDS также использует синхронизацию часов между всеми серверами сети для обеспечения правильного порядка событий в сети.
Имена и контексты
В именовании объектов служба NDS использует те же принципы, что и файловые системы MS DOS и UNIX. Объект-лист имеет краткое имя, называемое Common Name (CN). Оно может состоять максимум из 64 символов, включая пробелы. Поэтому имя принтера "Быстрый, но часто ломающийся Epson" является законным. Аналогом полного имени файловой системы MS DOS является так называемое "различимое имя" - Distinguished Name. Различимое имя представляет собой конкатенацию всех имен объектов, расположенных на пути этого объекта к корню дерева. Составляющие различимого имени отделяются друг от друга точкой. В отличие от полных имен MS DOS крайней левой составляющей различимого имени является краткое имя объекта, а крайней правой составляющей - имя корневого объекта. Например,
Vova S.NetProgrammers.Microsoft.US
представляет собой различимое имя объекта-пользователя с сетевым именем Vova S, работающего в сетевом отделе фирмы Microsoft, расположенной в США. Возможен и другой вариант записи различимого имени с указанием типов объектов:
CN=Vova s.Ou=NetProgrammers.O=Microsoft.C=US.
Такой вид записи более содержателен.
Средства защиты объектов в NDS
Служба NDS определяет права доступа одних сетевых объектов к другим. Различаются права доступа к объекту в целом и права доступа к его атрибутам.
По отношению к объектам существует следующий набор прав:
По отношению к атрибутам объектов используются такие права:
С каждым объектом связан список управления доступом (ACL), в котором определяются права доступа к данному объекту со стороны других объектов.
Права доступа наследуются в дереве объектов сверху вниз, поэтому права объекта-контейнера наследуются входящими в него объектами. Для достижении необходимой гибкости в наделении объекта правами используется маска наследования (Inheritance Mask), с помощью которой можно заблокировать некоторые наследуемые права. С помощью наследования прав доступа главный администратор дерева, имеющий доступ ко всем его объектам, может назначить администратора поддерева, который получит права доступа ко всем объектам данного поддерева. Если поддерево соответствует какой-либо структурной единице предприятия (что и подразумевается), например отделу, то это будет администратор отдела, управляющий пользователями и ресурсами данного отдела.
После подробного рассмотрения свойств дерева каталогов NDS можно уточнить понятия раздела (partition) и реплики (replica). Раздел представляет собой поддерево общего дерева сети. Для определения раздела необходимо выбрать объект-контейнер в общем дереве, который будет корневым объектом данного раздела. Создание раздела уменьшает объем хранимой на сервере информации базы данных NDS за счет исключения редко используемой информации и делает доступ к локальным объектам более быстрым, хотя объекты, находящиеся в других разделах, также доступны всем клиентам сети.
Реплика - это точная копия определенного раздела, хранящаяся на различных серверах. Наличие нескольких реплик обеспечивает отказоустойчивость ОС NetWare 4.x, а также ускоряет доступ к информации при перенесении реплики с подключенного через глобальную сеть сервера на локальный сервер.
Существуют три типа реплик: главная реплика (master replica), вторичная реплика (read/write replica) и реплика только для чтения (read-only replica).
Главная реплика позволяет проводить над ней такие операции, как создание нового раздела, слияние разделов и удаление раздела.
Вторичная реплика разрешает обновлять информацию об объектах, добавлять новые объекты, но не разрешает создавать новые разделы.
Реплика только для чтения позволяет только читать информацию из ее базы и проводить операции поиска.
В сети может существовать произвольное количество реплик. При изменения информации в какой-либо реплике автоматически запускается процесс обновления всех остальных реплик. Этот процесс называется процессом синхронизации службы каталогов (DSS).
Любой сервер NetWare, поддерживающий службу NDS, называется сервером имен.