Администрирование Служб Каталогов. Функция Организации Обслуживания [Microsoft Corporation] (doc) читать онлайн







Администрирование Служб Каталогов
Функция Организации Обслуживания


Опубликовано: Октябрь 2002
Переформатировано: Январь 2005
Последнюю информацию смотрите на сайте http://www.microsoft.com/mof








Информация, представленная в данном документе, являет собой текущую точку зрения корпорации Microsoft на рассматриваемые вопросы, на момент издания. Поскольку Microsoft должна реагировать на изменения условий рынка, эту точку зрения не стоит считать обязательной и корпорация Microsoft не может гарантировать точность любой представленной информации после даты публикации.
Данный документ может рассматриваться только как информационное издание. КОРПОРАЦИЯ MICROSOFT НЕ ДАЕТ НИКАКИХ ГАРАНТИЙ, ПРЯМО ИЛИ КОСВЕННО, ОТНОСИТЕЛЬНО ИНФОРМАЦИИ, ПРЕДСТАВЛЕННОЙ В ДАННОМ ДОКУМЕНТЕ.
В соответствии со всеми применимыми законами об авторских правах ответственность за это несет пользователь. Без ограничения прав на авторское право, данный документ может быть воспроизведен, сохранен или иным способом внесен в систему поиска либо передан в какой бы то ни было форме или какими бы то ни было средствами (будь то электронные, механические, фотокопированием, запись на магнитный носитель или иным способом), но только для целей, предусмотренных письменным разрешением корпорации Microsoft.  
Microsoft может являться правообладателем патентов и заявок, поданных на получение патента, торговых марок, авторских прав или прочих объектов права на интеллектуальную собственность, которые могут иметь отношение к содержанию данного документа. Предоставление Вам данного документа не означает передачи какой-либо лицензии на использование этих патентов, торговых марок, авторских прав или других объектов интеллектуальной собственности за исключением использования, явно оговоренного в письменном лицензионном соглашении Microsoft.
Если не сказано иначе, примеры компаний, организаций, продуктов, доменные имена, e-mail адреса, логотипы, лица, места, события, представленные здесь вымышленные, и они не должны ассоциироваться ни с какими реальными компаниями, организациями, названиями продуктов, доменными именами, email адресами, логотипами, людьми, местами или событиями.
 2005 Microsoft Corporation. Все права защищены.
Microsoft, ActiveX, и Visio являются зарегистрированными торговыми марками или торговыми марками корпорации Microsoft в Соединенных Штатах Америки и/или других странах.
Названия действительных компаний и продуктов, упомянутых в данном документе, могут быть торговыми марками соответствующих владельцев.
Содержание
1 1
Краткий обзор 1
2 3
Предисловие 3
3 5
Обзор администрирования служб каталогов 5
4 9
Процессы и функции 9
5 73
Роли и обязанности 73
6 75
Связь с другими SMF 75


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

2
Предисловие
Данное руководство содержит подробную информацию о функции организации обслуживания Администрирования Служб Каталогов (SMF) для создания которой были использованы или предположительно будут использованы технологии Microsoft® для центра обработки и хранения данных или других видов вычислительной среды предприятия. Это одна из более чем 20 SMF, определенных и описанных в Структурах Операций Microsoft (MOF). Данное руководство предполагает, что читатель уже знаком с целью, предпосылками и фундаментальными концепциями MOF, а также с рассматриваемыми технологиями Microsoft.
Обзор MOF и его компаньона, Microsoft Solutions Framework (MSF), можно найти в руководстве MOF Service Management Function Overview . это краткое руководство также предлагает краткое описание каждой функции организации обслуживания в рамках MOF. Подробную информацию о концепциях и принципах каждой из структур также можно найти в технической документации на сайте http://www.microsoft.com/mof.
3
Обзор администрирования служб каталогов
Служба каталогов – один из самых важных компонентов расширенной компьютерной системы. Несмотря на то, что пользователи и администраторы зачастую не знают точного названия объектов, они, возможно, знают один или несколько атрибутов этих объектов, и могут запросить каталог для получения списка объектов, соответствующих атрибутам.
Служба каталогов может:
• Установить защиту, как определено администратором для защиты информации от несанкционированного доступа.
• Разослать каталог по разным компьютерам внутри сети, обеспечив повышение эффективности работы.
• Тиражировать каталог, обеспечив доступ к нему большему количеству пользователей и сделав его устойчивым к повреждению.
• Разделить каталог на многочисленные источники данных (резервы), позволяющие сохранить очень большое количество объектов.
Служба каталогов является как инструментом управления, так и инструментом конечного пользователя. По мере роста числа объектов в сети, служба каталогов становиться необходимой. Служба каталогов является ядром, вокруг которого вращается большой распределенный каталог.
Традиционно, служба каталогов использовалась для присвоения имен и определения местоположения сетевых ресурсов. Эти функции были расширены , и теперь служба каталогов становится важной составляющей инфраструктуры Интернет/интранет (справочные каталоги, белые и желтые страницы, e‑mail директории, и т.д.).
Служба каталогов также позволяет осуществлять отправку e-mail и интеграцию между неравноправными системами электронной почты. Службы каталогов быстро становятся необходимыми для интеграции приложений — выступая, например, как центральный репозитарий для всех баз приложений, доступа и информации безопасности.
Благодаря каталогу возникают новые приложения, что заставляет говорить о каталоге как необходимой части сетевой инфраструктуры. Каталог рассматривается как настраиваемую базу данных специального назначения, к которой могут безопасно подключаться пользователи и приложения для поиска, чтения, добавления, удаления и изменения информации. Затем эта информация автоматически распространяется по другим каталогам серверов сети.
Эти приложения, созданные каталогом зависят от служб сформировавшегося каталога и выполняют три других роли: аутентификацию и авторизацию, присвоение имен и определение местонахождения, и администрирование и управление сетевыми ресурсами.
Цели и задачи
Цель администрирования служб каталогов заключается в обеспечении через простой и организованный процесс доступа к информации, по запросу, полученному через авторизованную программу формирования запросов по сети. Задачи – позволить пользователям и приложениям найти сетевые ресурсы, такие как пользователей, серверы, приложения, инструменты, службы и другую информацию в сети и осуществлять повседневную работу, обслуживание и поддержку каталога предприятия.
Область действия
Область действия администрирования службы каталогов охватывает:
• Запущенные каталогом приложения.
• Метакаталоги.
• Создание и управление пользователями, группами и ресурсами.
• Поддержку повседневной работы, такую как мониторинг, обслуживание и устранение неполадок в каталоге предприятия.
Основные определения
Предупреждение. Указание на значащее событие. Предупреждения определяются правилами работы.
Атрибут. Компьютерная характеристика, обычно определяемая ключом Registry или значением.
Аутентификация. Метод, позволяющий пользователям доказать системе что они являются именно теми, кем себя заявляют. Аутентификация используется в виде паролей, смарт-карт, биометрических данных и т.д.
Авторизация. Процесс подтверждения того, что пользователь имеет необходимые права и разрешения на доступ к ресурсам домена.
Резервное копирование. Этот термин обычно используется в связи с копированием всех файлов на компьютерные диски компьютера, что периодически выполняется для сохранения на магнитных пленках или других сменных носителях (также называемых «дамп»).
Клиент. Компьютерная система или процесс, которая запрашивает сервис другой компьютерной системы или процесс (“сервер”) используя определенный вид протокола и принимающий ответы сервера. Клиент-это часть архитектуры ПО клиент-сервера. Например, рабочая станция, запрашивающая контент файла на файл-сервере – это клиент файл-сервера.
Каталог. Совокупность файлов. Обычно используется в системах с графическим пользовательским интерфейсом (GUI) и предлагает браузер графических файлов, где каталоги обычно отображаются как папки (как маленькие портфели).
Событие. Любое значительное событие в системе или приложении, требующее уведомления пользователя или запись, добавленная в журнал регистрации.
Брандмауэры. Выделенный шлюз с установленными на нем о специальными мерами предосторожности. Цель – защита группы более свободно администрируемых машин от взломщиков. Обычно брандмауэр-это недорогая микропроцессорная рабочая станция UNIX, на которой нет важной информации с модемом и портами сети общего пользования, но которая внимательно следит за подключением к остальным группам абонентов. Особые меры предосторожности могут включать профилактический контроль, обратный вызов и даже полный iron box с ключами для определенных входящих ID или моделей действий.
Упрощенный протокол доступа к сетевым каталогам, протокол LDAP. LDAP разрешает приложениям получить одинаковый доступ к любому каталогу независимо от поставщика каталога или способа его применения. Доступ к большинству каталогов общего пользования может быть получен через протокол LDAP. Приложения, использующие протокол LDAP получают упрощенный доступ к различным информационным данным из несовместимых каталогов.
Метадиректорий. Продукты метадиректория это необходимые каталоги каталогов. Они обеспечивают общую инфраструктуру, которая находится над различными каталогами, направляя запросы и возвращая отклики через одиночный прозрачный пользовательский интерфейс. Метадиректорий обеспечивает интеграцию и унификацию несовместимых каталогов.
Сетевая операционная система(NOS). Операционная система, использующая программное обеспечение для связи с другими компьютерами через сеть. Это позволяет осуществлять обмен между компьютерами такими ресурсами, как файлы, прикладные программы и принтеры.
Сервер. Компьютер, обеспечивающий обслуживание через сеть других, подключенных к нему компьютеров. Самым распространенным примером является файл-сервер, имеющий локальный диск и получающий запросы на обслуживание от удаленных клиентов по считыванию и записи файлов на этот локальный диск.
Простой протокол управления сетью (SNMP). SNMP позволяет осуществлять управление приложением для мониторинга статуса модуля в сети. Он также позволяет осуществлять управление приложением с асинхронным уведомлением через механизм системной ловушки протокола SNMP, при возникновении события или ошибки (т.е. если работа сервера внезапно прерывается).

4
Процессы и функции
В данной главе подробно рассматриваются процессы и функции администрирования службы каталогов SMF.
Обзор хода процесса
В процессе администрирования служб каталогов можно выделить пять основных процессов и ряд подпроцессов:
• Типы каталогов
• Каталоги общего назначения или стандартные каталоги
• Каталоги специального назначения (приложения) и каталоги сетевой операционной системы
• Фокус документа для операций каталога
• Понятие окружения каталога
• Обнаружение наличия окружения
• Проблемы интеграции каталога
• Документирование архитектуры обслуживания каталога
• Мониторинг составляющих каталога
• Управление каталогом
• Обзор управления аппаратными средствами
• Обзор управления ПО
• Обслуживание Вашего каталога
• Создание резервной копии каталога и плана восстановления
• Сочетание методик традиционного резервного копирования и репликации для защиты данных
• Анализ резервного копирования и плана восстановления
• Диагностика и устранение неполадок в архитектуре каталогов
• Обнаружение проблем
• Типы проблем
• Таблица диагностики и устранения неполадок
• Перечень контрольных проверок для поиска неисправностей
• Ниже на схеме показан процесс администрирования обслуживания каталога.

Рисунок 1. Блок-схема процесса администрирования службы каталога
Типы каталогов
Следующая глава посвящена рассмотрению на высоком уровне технологий текущего каталога и типов каталогов, которые уже либо существуют, либо будут созданы в ближайшем будущем.
Каталоги общего назначения или стандартные каталоги
Каталоги общего назначения, или стандартные каталоги не привязаны ни к какому специальному приложению или сервису, не ассоциируются однозначно, с какой бы то ни было, определенной сетевой операционной системой (NOS), и не используются для каких-то конкретных целей. Эти каталоги, скорее предназначены для удовлетворения потребностей многочисленных требований обслуживания. Примером может служить Упрощенный Протокол Доступа к Сетевым Каталогам (LDAP). Протокол LDAP хорошо подходит для удовлетворения потребностей практически любого приложения, разрешенного каталогом.
Доступ к большинству каталогов общего назначения может быть получен через протокол LDAP. LDAP позволяет приложениям получить доступ к любому каталогу независимо от производителя каталога и того, как он используется. Приложения, использующие протокол LDAP получают упрощенный доступ к многочисленным информационным данным из несовместимых каталогов.
Каталоги специального назначения (Приложения) и директории сетевой операционной системы
Каталоги специального назначения, или каталоги – это каталоги, которые однозначно привязаны к конкретному приложению (или набору приложений). Они отличаются от каталогов общего назначения тем, что они жестко интегрированы в конкретное приложение и используют внутренние интерфейсы и протоколы. Обычно, эти каталоги трудно или невозможно использовать с, каталогами, запускаемыми приложениями, которые они не должны поддерживать.
К этой категории также относятся директории сетевой операционной системы: каталоги, которые специально привязаны к конкретной операционной системе. Хотя большинство NOS-каталогов создаются как внутренние продукты, сегодня большинство из них включают стандарты Интернет (т.е. LDAP), таким образом, позиционируя себя для более широкой поддержки приложений, запускаемых каталогом.
Фокус на документ в операциях с каталогами
Материал, содержащийся в этом документе, сфокусирован на операциях, осуществляемых после внедрения, поддержки, управлении и обслуживании организационного каталога. Это проводится с распознаванием заказчика, который уже имеет один или несколько каталогов общего или специального назначения, используемых для адресации требований бизнеса. Например, компания может иметь online (электронный) каталог, связанный с системой управления трудовыми ресурсами, телефонной системой, системой электронной почты, или системой планирования ресурсов предприятия.
С точки зрения работы, важно начать перемещение в отдельный пункт управления и операции для всех каталогов.
Понимание среды каталога
Лучший способ понять решение используемого каталога – это сделать этот аспект применения таким же важным, как и любой другой – внедрение решения не считается выполненным до тех пор, пока не понят полностью каждый функциональный и тактический аспект каталога, пока оно незадокументировано, неукомплектовано, не отслеживается, не управляется, не поддерживается и не финансируется.
Осознание наличия среды
До того, как будет приведено в действие любое положительное или значащее управление каталогом, необходимо убедиться в том, что он имеет среду, узнать, как она работает, какие части взаимодействуют с другими компонентами, системами или приложениями, и кто отвечает за каждую часть. Просто удивительно, сколько организаций используют одну или несколько служб каталогов не понимая, полностью этих элементов. Большая часть использования каталогов с самого начала испытывает ограничения по бюджету, времени и ресурсами, и от этого серьезно страдают документация и элемент управления.
Многие организации имеют хорошие намерения по апостериорному отказу от документирования использования и внедрения соответствующих механизмов управления (мониторинг, назначение административных обязанностей, обращение к службе поддержки и т.д.). Однако, это непросто из-за быстрого роста и динамического характера бизнес окружения.
Как видно из двух предыдущих абзацев, уровень проактивного сбора экспертных знаний и готовность к работе, по ряду причин встречается не всегда. Но это необходимо делать, и делать это нужно до того, как используемое решение выйдет из-под контроля, и больше не будет отвечать требованиям, ради которых оно было изначально внедрено.
Кризисная ситуация проявляется в виде следующих симптомов:
• ИТ постоянно находится в кризисном режиме, переходя от одного аварийного состояния к другому.
• Развертываемые решения не соответствуют целям надежности и доступности, установленным при определении решения.
• Мощность и/или пропускная способность всегда недостаточны.
В большинстве компаний ИТ находятся в состоянии между идеальной операционной средой и состоянием управления при полном кризисе. Независимо от вашего положения, оставшаяся часть данного документа будет полезна тем, что облегчит оценку операционной готовности и поможет внести изменения, необходимые для достижения целей решения: доступности, надежности, управляемости и удобства обслуживания (ARMS – availability, reliability, manageability, supportability).
Задачи интеграции каталогов
В данном разделе рассматривается использование каталогов и концепция интеграции каталога.
С внедрением многочисленных разнородных каталогов общего и специального назначения задача управления этими каталогами становится проблемой. Управление разнородными каталогами является дорогостоящим, избыточным и нестандартным в подходах и методиках.
Технологии каталогов проработаны то такой степени, что они могут поддерживать автоматизацию делопроизводства на основе каталогов, включая электронную коммерцию и общие вычислительные процессы предприятия.
Как используются сервисы каталогов?
Традиционно, сервисы каталогов используются для назначения имен и определения местонахождения сетевых ресурсов. Новые приложения сервисов каталогов включают корпоративные электронные телефонные книги, «белые»/«желтые» страницы в Интернете, доставку электронной почты и интеграцию между разнородными системами электронной почты, а также центральное хранилище пользовательской информации.
Продукты сервисов каталогов используют сервисы безопасности для отслеживания прав доступа к сетевым ресурсам и информации. Сервисы каталогов обеспечивают эффективный способ управления защитой ресурсов, поскольку каталог предлагает логическое представление всех ресурсов на предприятии. Кроме того, сервисы каталогов могут работать как единая точка входа в сеть. Пользователи могут получить доступ к разрешенным ресурсам после одноразовой аутентификации в сервису каталога.
Можно выделить четыре основные области использования каталогов:
• Аутентификация и авторизация
• Назначение имен и установление местонахождения сетевых ресурсов
• Администрирование и управление сетевыми ресурсами
• Запуск приложений
Аутентификация и авторизация
Инструменты приложений, позволяющие сетевым операционным системам и почтовым программам отслеживать пользователей, их пароли и разнообразную информацию о предпочтениях в настройке различных приложений, были предшественниками каталогов общего назначения.
Сервисы каталогов и сервисы безопасности становятся отдельными компонентами в модели сетевых сервисов. Тем не менее, эти два сервиса тесно связаны, совместно обеспечивая функции аутентификации и авторизации. Сервисы безопасности и сервисы каталогов работают вместе. Сначала каталог должен обеспечить средства аутентификации и доступа, определяющие, кто может иметь доступ к каталогу и вносить в него изменения. Кроме того, каталог является основанием для механизмов безопасности общего назначения.
Аутентификация
Аутентификация позволяет пользователям и приложениям идентифицировать себя путем вызова сервисов безопасности, которые могут подтвердить их идентификационные данные. Традиционно сетевые операционные системы и приложения использовали методы аутентификации на основе паролей, ориентированные на определенную систему. Однако развитие корпоративных локальных сетей и рост Интернета требуют инфраструктуры безопасности общего назначения.
Каталоги должны обеспечивать механизмы аутентификации, управляющие доступом к базе данных каталога. Каталоги могут проводить аутентификацию клиентов с использованием различных способов, включая анонимные подключения, использование открытых паролей или сложное хеширование паролей, а также использование программ шифрования сеансов. Хотя эти методы могут быть важны для защиты содержимого каталога, они представляют собой скорее традиционный механизм аутентификации, ориентированный на определенную систему, чем механизм аутентификации общего назначения.
С бурным ростом электронной коммерции и связи через Интернет, когда все больше внимания придается механизмам аутентификации общего назначения, технология инфраструктуры открытых ключей (PKI) становится стандартом де-факто для аутентификации пользователей и приложений. PKI хорошо подходит для распределенной вычислительной среды такого рода. PKI – важный инструмент для аутентификации в различных приложениях защиты, в частности, в Secure Sockets Layer (SSL), Secure/Multimedia Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET), а также в сервисах цифровой подписи кода средств управления, как для Java, так и для Microsoft ActiveX®. Каталог играет важную роль в поддержке сервисов безопасности, поскольку PKI-продукты будут использовать каталог для хранения, распространения, поиска и извлечения цифровых сертификатов и открытых (а, в некоторых случаях, и секретных) ключей.
Помимо хранения и управления компонентами сервисов PKI, каталог содействует работе других механизмов аутентификации, обеспечивая поддержку предоставления сервиса. В случае систем с секретными ключами, таких как протокол Kerberos версии 5, каталог предоставляет место для хранения уникального идентификатора (UID), и сам проходит аутентификацию сервисом Kerberos. Кроме того, поскольку каталоги общего назначения получают все большее распространение, администраторы безопасности будут использовать свойства наследования каталога для применения корпоративных политик безопасности, хранящихся в этом каталоге.
По мере совершенствования этих взаимодействующих механизмов аутентификации, все более реальной становится единая регистрация, при которой аутентификация пользователя осуществляется одновременно во всех операционных системах, сервисах и приложениях в сети. Хотя аутентификация с полным взаимодействием еще не существует, сервисы каталогов можно использовать для создания впечатления единой регистрации посредством использования сервисов метакаталогов для реализации регистрации в различных средах через модуль доступа. Дополнительные сведения о метакаталогах, их возможностях и их важности приведены ниже в этом документе.
Авторизация
После аутентификации клиентов и приложений в сети сервисами безопасности, необходимо выполнить авторизацию доступа к ресурсам. Как и в случае с аутентификацией, функции авторизации (также известной как управление доступом) в операционных системах, системах сообщений (например, системах электронной почты) и других серверах ориентированы на определенную систему. После аутентификации пользователя такие системы могут также проверить внутренние системы для определения уровня доступа конкретного пользователя к заданному ресурсу, например, к каталогу файловой системы. Однако с появлением механизмов аутентификации общего назначения, каталог будет играть менее важную роль в управлении доступом.
Существует два метода, с использованием которых каталог может поддерживать управление доступом:
• Предоставление приложений-хранилищ для хранения, распространения, поиска и извлечения списков управления доступом (ACL).
• Использование каталога для определения объектов и атрибутов объектов, выполняющих авторизацию доступа приложений и пользователей к определенному сетевому ресурсу.
Например, администратор системы безопасности может объявить, что «все члены группы бухгалтерии могут использовать приложение платежных ведомостей» или что «только сотрудники с зарплатой уровня ‘X’ могут утверждать заявления по компенсации транспортных расходов». Хотя оба метода являются приемлемыми формами управления авторизацией, последний предлагает более простой и последовательный подход к авторизации и внедрению политик безопасности.
Пока группы стандартов каталогов работают над стандартными механизмами списков управления доступом (ACL), у разработчиков есть две альтернативы. Они могут дорабатывать механизмы управления доступом для определенных платформ и создавать в платформенные зависимости в своих продуктах. Или они смогут создавать свои собственные механизмы управления доступом на основе каталога, но ориентированные на определенные приложения.
Если необходимо обеспечить независимость от платформы, последний подход предлагает компромисс между простотой использования (с применением каталога для получения управляемой, масштабируемой инфраструктуры) и гибкостью приложений (что позволяет разработчику настроить определенные требования авторизации под конкретное приложение). С другой стороны, разработка для определенной платформы может сэкономить время и силы, несмотря на то, что создание зависимости от платформ затрудняет поддержку нескольких платформ.
Назначение имен и определение местонахождения сетевых ресурсов
Компетенция и традиционная роль ядра каталога заключается в поиске объектов. Назначение имен и определение местонахождения ресурсов – важная функция, которую каталоги выполняют в сети.
Существуют три основных аспекта функции назначения имен и определения местонахождения ресурсов:
• Стандартное назначение имен
• Независимость определения местонахождения
• Сообщества по интересам
Стандартное назначение имен
Каталоги устанавливают стандартные соглашения о назначении имен в организации. Эти соглашения о назначении имен обеспечивают контекст, в котором сетевые приложения, сервисы и люди находят друг друга.
Преимущество стандартного назначения имен заключается в том, что оно отделяет физическое от логического. Соглашения о назначении имен не требуют понимания подробных характеристик сети (например, построения, маршрутизаторов, концентраторов, подсетей и IP-адресов — все это может быть изменено без уведомления), они описывают сетевые ресурсы в понятных пользователю (и приложению) терминах. В результате пользователи и приложения могут просматривать сеть и свои ресурсы скорее целостно, чем территориально. Люди и приложения на основе каталога могут осуществлять поиск и определять местонахождение ресурсов, не имея знаний о построении сети. Они могут осуществлять поиск по имени. Кроме того, поиск можно осуществлять по атрибуту. Такие возможности позволяют освободить ресурсы от определенной топографии и предоставляют независимость размещению ресурсов.
Независимость местоположения
Независимость местоположения оказывает значительное влияние на многие аспекты сети. Каталог обеспечивает независимость местоположения двумя способами:
• Каталог сохраняет и дублирует настройки приложений, личные адресные книги, закладки, профили, ключи безопасности и прочую пользовательскую информацию.
• Каталог работает с серверами политик и другими инструментами управления системами, дублирующими настройки системы.
Хотя каталог и не содержит всей этой информации, он знает, где хранится информация и помогает сервисам, хранящим информацию, использовать ее должным образом. Такая способность улучшает условия, как для конечных пользователей, так и для системных администраторов. Пользователи и приложения будут иметь одну точку привязки. ИТ-администраторы, с другой стороны, получают возможность осуществлять централизованный контроль и управление корпоративными компьютерами, лицензированием ПО и распространением. ИТ-администраторы также могут осуществлять перемещение, балансировку нагрузки или замену сервисов без изменения конфигурации базовых приложений или физического присутствия за каждым компьютером. Такая способность осуществлять управление сервисами без изменения конфигурации упрощает работу администратора и повышает управляемость и масштабируемость сети.
Например, для корпоративных компьютеров независимость местоположения означает, что пользователи могут подключиться к сети с любого устройства, сохраняя все свои персональные предпочтения и настройки.
Каталог также позволяет другим объектам, таким как приложения или сетевые сервисы, находить требуемые им ресурсы. Что касается распределенных приложений, заданному приложению может потребоваться найти и использовать программный компонент, например, объект COM или CORBA. Включив определение, атрибуты и методы объекта в каталог, разработчики могут создавать распределенные приложения, которыми можно управлять и которые можно изменять централизованно через каталог, вместо того чтобы изменять и заново распространять базовое приложение.
Подобным образом, приложения могут найти требуемые компоненты посредством их поиска в каталоге. Приложению не требуется знать физическое размещение компонента, и при его изменении приложение будет продолжать работать без сбоя.
Сообщества по интересам
Помимо стандартных соглашений о назначении имен и обеспечения независимости размещения, каталоги также могут сохранять дополнительную информацию о людях и организациях. Эта дополнительная информация позволяет инфраструктуре каталога создать чувство сообщества в новой корпоративной системе понятий, включающей клиентов, поставщиков, партнеров, коллег и команды. Каталог делает возможным участие вне зависимости от часовых поясов и географических границ, включая участие внутри организации, охватывающее как интрасети, так и экстрасети.
В некоторых случаях включение человека в сообщество происходит автоматически, например, если речь идет обо всех секретарях компании или обо всех людях, работающих в определенном здании. В других случаях пользователи самостоятельно выбирают сообщества, к которым они хотят присоединиться, будь то списки контактов или группы по интересам или специализации.
Каталоги долгое время играли важную роль в электронных сообществах. Первое сообщество пользователей приложения для коллективной работы было основано на электронной почте – самом простом средстве асинхронной связи. В последнее время средства синхронной связи (так называемый мгновенный обмен сообщениями) позволяет значительно расширить системы обмена сообщениями. С появлением более развитых форм взаимодействия в реальном времени, таких как видеоконференции, групповые авторские инструменты и Интернет-телефония, каталог будет по-прежнему играть важную роль как место встречи этих сетевых сервисов, позволяя людям и приложениям находить друг друга по имени или атрибутам.
Разнородные каталоги и метакаталоги.
Продукты работы с метакаталогами, в общем, представляют собой каталоги каталогов. Они обеспечивают общую инфраструктуру, основанную на различных каталогах, направляя запросы и возвращая ответы через единый прозрачный пользовательский интерфейс. Метакаталоги играют важную роль в интеграции и унификации разнородных каталогов.
Клиенты должны будут поддерживать несколько каталогов, по крайней мере, в ближайшем будущем, поскольку многие из этих каталогов обслуживают определенные функции. Сервисы метакаталогов разрешают фундаментальные проблемы реализации, которые должен разрешать каждый продукт каталога предприятия.
Очень большим и распределенным компаниям метакаталоги могут предложить следующие преимущества по сравнению с автономными сервисами каталогов:
• Сервисы метакаталогов предлагают универсальный способ назначения имен, поиска, организации доступа и защиты ресурсов не только на больших расстояниях и временных промежутках, но и между различными системами.
• Во многих случаях очень дорого, сложно и непрактично объединять все текущие каталоги в один каталог предприятия. Сервисы метакаталогов интегрируют существующие разнородные и многочисленные каталоги, разрешая технические и организационные проблемы, связанные с реализацией каталога.
Однако преимущества метакаталогов значительно ослабляются по мере сокращения каталогов и/или сложности инфраструктуры каталога. Необходимо оценить ИТ-организацию и определить необходимость внедрения метакаталога.
Для того чтобы лучше понять технологию метакаталога, рассмотрим в этом документе концепции метакаталога, включая:
• Синхронизацию.
• Информационное посредничество.
• Информационный поток.
• Присоединение каталога.
• Поддержка нескольких пространств имен.
Синхронизация метакаталога
Синхронизация позволяет метакаталогу объединить содержимое в базу данных метакаталога.
При синхронизации метакаталог должен взаимодействовать с другими подключенными каталогами через хорошо установленные связи. Административное управление связями между каталогами является важным аспектом в повседневном управлении инфраструктурой каталога. Задача объединения содержимого каталога посредством синхронизации и репликации ясно иллюстрирует эту проблему. Основной вопрос состоит в том, кто создает и удаляет присоединенные объекты и каким образом.
Это основные вопросы управления. Сервисы метакаталога должны поддерживать высокую гибкость в реализации и делегировании управления организацией. Планировщики сети должны создать особые связи между метакаталогом и подключенными каталогами, с которыми он взаимодействует.
Управление объектами
Каталог компании содержит множество различных объектов. Эти объекты представляют собой различные ресурсы, включая людей, физические расположения, приложения (такие как серверы баз данных и сообщений) и системы (такие как серверы и рабочие станции).
Вопрос состоит в том, как администратор в каталоге предприятия создает объекты и атрибуты, представляющие объекты и атрибуты, существующие в сети?
В случаях, когда подключенные каталоги управляются централизованно с каталога компании, администраторы сервиса каталогов могут создавать объекты в каталоге компании. В этом случае каталог компании копирует эти объекты в подключенный каталог.
Однако другие отделы или подразделения могут на местах управлять другими подключенными каталогами. В этих случаях подключенный каталог должен иметь возможность создания объектов в каталоге предприятия.
Во всех остальных случаях соответствующие объекты, такие как коды пользователей, будут существовать как в каталоге предприятия, так и в подключенном каталоге. Таким образом, каталог предприятия должен также иметь возможность устанавливать крепкие связи между существующими объектами в подключенных каталогах и объектами в каталоге предприятия. Метакаталог должен позволять осуществлять создание объектов при любых обстоятельствах. Чтобы хорошо понять эти различные динамики, можно представлять метакаталог в одной из трех ролей: главный каталог, подчиненный (или младший) каталог, либо равноправный каталог.
Роль главного каталога
В роли главного каталога метакаталог создает объекты в подключенном каталоге и управляет им. Роль главного каталога позволяет компаниям использовать метакаталог предприятия для централизованного управления любым подключенным каталогом. На рисунке ниже показана роль главного каталога.

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

Рисунок 3. Роль подчиненного сервера
Роль равноправного каталога
В обеих ролях либо метакаталог, либо подключенный каталог действительно создает объекты в базе данных метакаталога. При постоянном обслуживании каталога важны обе эти роли. Большинство предприятий уже создали ряд объектов каталога во множестве систем, многие из которых представляют одни и те же ресурсы или людей.
Возьмем, например, код пользователя. Если компания использует электронную почту, жетоны безопасности и базу данных отдела кадров, велика вероятность того, что данные о каждом сотруднике существуют в нескольких из этих сред, если не во всех. Вероятно также, что и соглашения о назначении имен в этих системах также отличаются. Каждый отдельный каталог также содержит пользовательские атрибуты; некоторые из них идентичны (такие как адрес и номер телефона), а другие отличаются (например, атрибуты определенных приложений).
Нет смысла ожидать, что администраторы всех подключенных каталогов изменят существующие соглашения о назначении имен или примут массу новых атрибутов, которыми им придется управлять. Такие изменения не всегда технически возможны или осуществимы. Некоторые каталоги, ориентированные на определенные приложения, не могут поддерживать соглашения о назначении длинных имен или большое количество атрибутов, которые компании могут использовать, например, в метакаталоге. Отраслевые рекомендации заключаются в том, чтобы сохранить локальные соглашения о назначении имен и структуру каталога.
Метакаталог должен быть способен устанавливать связи между объектами в метакаталоге и существующими объектами в различных подключенных каталогах. Такие связи часто называют равноправными связями или ассоциациями, потому что они уравнивают или ассоциируют существующие объекты друг с другом. На рисунке ниже показаны равноправные отношения.

Рисунок 4. Равноправные отношения
Метакаталог может уравнять объект в подключенном каталоге, использующем другие соглашения о назначении имен, с объектом в метакаталоге, установив между ними прочную и четкую связь.
Например, как показано на следующем рисунке, метакаталог может понять, что Jeff Smith, определенный в метакаталоге, является тем же лицом, что и «jsmith» в SMTP-адресе и «Jeff Smith» в базе данных отдела кадров.
Рисунок 5. Функциональность равноправных отношений
Управление атрибутами
Объекты в пространстве имен метакаталога могут иметь одну из трех ролей в отношении к подключенному каталогу: главный объект,подчиненный сервер или равноправный объект. Метакаталог не должен осуществлять принудительное наследование отношений атрибутами этих объектов. В некоторых случаях локальным администраторам или пользователям нужно контролировать атрибуты объектов локально из подключенного каталога, даже если метакаталог выступает в роли главного каталога для объектов в этом каталоге.
В то же время администраторы должны осуществлять гибкое управление атрибутами в самом метакаталоге. Например, во многих случаях атрибуты адреса и номера телефона в пользовательском объекте должны определяться пользователем. Не имеет смысла возлагать функции изменения домашнего адреса и номера телефона пользователя на центрального администратора.
Даже если администратор сервисов каталогов создает пользовательский объект централизованно в пространстве имен метакаталога и затем копирует объект пользователя в подключенный каталог (что целесообразно с точки зрения безопасности), пользователю могут быть предоставлены разрешения для контроля некоторых из его атрибутов. Это можно сделать либо из метакаталога, либо локально через подключенный каталог.
На рисунке ниже показан данный уровень контроля атрибута.

Рисунок 6. Контроль атрибутов
База данных отдела кадров – хороший пример того, как гибкий контроль атрибутов может принести пользу реализациям метакаталога предприятия. Многие компании стремятся сделать базу данных отдела кадров официальным источником для создания пользователей. При приеме новых сотрудников и их добавлении в базу данных отдела кадров, эта база данных может выступать в качестве главного каталога, создавая объекты для этих пользователей в метакаталоге. Но метакаталог может предоставить пользователям контроль над своими личными атрибутами, включая домашний адрес, номер телефона и контактную информацию для экстренных случаев. При изменении пользователем этих атрибутов в метакаталоге, эти изменения могут отразиться в базе данных отдела кадров, даже если она является главным каталогом для создания пользовательских объектов.
Фильтрация объектов и атрибутов
Независимо от отношений между любым заданным подключенным каталогом и метакаталогом, важным аспектом для рассмотрения является то, какая информация и в каком количестве будет передана в метакаталог. Также должен быть способ управления тем, какая информация (и в каком объеме) будет впоследствии передана в другие интегрированные каталоги.
Поскольку многие каталоги имеют особые задачи, нецелесообразно распространять всю информацию из каждого каталога во все остальные каталоги. Объекты, значимые для одного каталога, могут быть бесполезны для другого. Некоторые объекты из подключенных каталогов могут быть бессмысленны даже в метакаталоге, приводя к нежелательному загромождению. В некоторых случаях данные, например, информацию о зарплате или таблицы маршрутизации сети, просто нельзя копировать в другие подключенные каталоги.
Метакаталог должен иметь возможность контролировать уровни импорта и экспорта для каждого конкретного случая. Этот контроль должен быть достаточно гибким, чтобы сохранить либо все содержимое подключенного каталога, либо определенное подмножество этого содержимого. Метакаталог должен также позволять администратору выборочно копировать содержимое метакаталога в любой заданный подключенный каталог. В частности, сервисы метакаталога должны поддерживать фильтрацию как для операций импорта, так и для операций экспорта, как на уровне объекта, так и на уровне объект-атрибут.
Метакаталог может импортировать одни объекты, но исключать другие с использованием фильтров объектов, определенных администратором. На рисунке ниже показана фильтрация объектов во время импорта. Например, системный администратор может пожелать импортировать все пользовательские объекты из NetWare NDS в метакаталог, но не импортировать информацию о маршрутах, хранящуюся в каталоге NetWare. Метакаталог также должен поддерживать такие фильтры объектов при выполнении операций экспорта.

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

Рисунок 8. Фильтрация атрибутов во время импорта
Информационный посредник каталога
Информационное посредничество позволяет метакаталогу получать доступ к данным в других каталогах без фактического сохранения у себя этих данных. Метакаталог выступает в качестве указателя на требуемые данные.
Синхронизация обеспечивает мощный набор возможностей для группировки содержимого каталога при объединении. Поскольку метакаталог дублирует и синхронизирует данные из многих источников, поиск в основном сервисе каталога (а не в самом метакаталоге) обычно локализован, что повышает производительность. Репликация данных в нескольких местах также обеспечивает исключение единой точки сбоя, что повышает общую надежность системы.
Несмотря на эти преимущества, синхронизация и репликация не всегда являются лучшими средствами интеграции каталога. Создание многочисленных копий данных каталога и их репликация в сети могут быть неэффективны при больших объемах информации, особенно если пользователи нечасто обращаются к этим данным.
Обычный подход к решению этих проблем предполагает:
• Создание ссылок на стороне клиента.
• Интеграция функциональных возможностей метакаталога в клиентах и приложениях.
• Информационное посредничество.
Например, LDAP v3 включает ссылки на стороне клиента. При такой модели сервер каталога может направить клиента на другой сервер, если он не имеет информации, которую ищет клиент. Клиент тогда может автоматически продолжить свой поиск, направляя последующие запросы на сервер(ы), заданные в ссылках.
Несмотря на полезность клиент-ориентированных методов, они не полностью удовлетворяют потребности в инфраструктуре каталога предприятия. Ссылки LDAP хороши для направления клиентов в другие каталоги, в частности, на каталоги, находящиеся за пределами предприятия, но они не устраняют потребность в инфраструктуре, которая может рационализировать (реплицировать) содержимое каталога. Кроме того, переложив задачу сбора данных полностью на клиента и приложения, разработчик просто оставляет организацию без инфраструктуры, способной управлять большим количеством каталогов в интегрированной форме.
Поэтому использование сервера метакаталога в качестве информационного посредника становится все более привлекательным. Сервисы посредника включают набор как относительно статичных, так и более динамических операций.
Статичные функции посредника практически эквивалентны концепции цепочек, определенной стандартом X.500. Формирование цепочек позволяет связывать каталоги в режиме реального времени, позволяя серверу каталога осуществлять доступ к данным другого каталога от имени клиента или сервера. Если сервер каталога понимает, какую информацию содержат другие серверы каталогов, он может получить доступ к этим данным от имени своих клиентов. Эта концепция представлена на рисунке ниже.
Рисунок 9. Статический информационный посредник каталога
Клиент каталога запрашивает на сервере метакаталога информацию, которая в действительности находится на сервере приложения или каталога NOS. Поскольку известно содержимое приложения или каталога NOS, метакаталог может получить доступ к информации от имени клиента, после чего передать информацию клиенту. Передача запроса по цепочке или через посредника прозрачна для клиента.
Передача по цепочке может возникнуть как в пределах одного каталога, так и между двумя различными каталогами. Она основана либо на стандартном протоколе, либо на интерфейсах интеграции, основанных на протоколах производителя. Таким образом, сервер метакаталога может предоставлять клиентам прозрачный доступ к информации в других каталогах, что уменьшает необходимость репликации и синхронизации.
Несмотря на то, что при статическом посредничестве или передаче запросов по цепочке в некоторой степени устраняется необходимость репликации и синхронизации, возникают другие проблемы. Например, должна быть установлена и доступна связь между каталогами; при передаче данных между глобальными сетями (WAN) и локальными сетями (LAN) также могут возникать проблемы.
Если связь между WAN или LAN отключена, доступ к данным через посредника будет невозможен. Эту проблему можно разрешить кэшированием данных, однако различия между синхронизацией реплик и синхронизацией кэшей может вызвать другие проблемы.
Поиск по WAN или даже по большой LAN может быть проблематичным. Создание логического множества информации каталога, включающего принимаемое через посредника содержимое, которое можно было бы легко найти в большом предприятии, может быть сложным. Поэтому посредническая модель не может обеспечить надежность работы и доступа в WAN или крупных LAN.
Информационное посредничество также включает возможность поддержки более динамических функций и функций реального времени. В сочетании с моделью событий и объектов общего назначения, сервисы каталогов могут осуществлять посредничество для различных динамических функций. Приложения могут регистрировать определенные типы событий каталога, такие как вход в сеть или изменение определенных атрибутов заданного объекта. Эти события могут вызывать определенные операции, например, операции поиска в базе данных или изменения конфигурации параметров, связанных с заданным маршрутизатором или коммутатором.
Информационный поток в метакаталоге
Метакаталог может либо копировать, либо синхронизировать данные с подключенными каталогами, или же выступать в роли посредника, осуществляющего прозрачный доступ к данным в других каталогах от имени клиентов или других сервисов.
При синхронизации администраторы сервисов каталогов могут импортировать содержимое подключенного каталога в метакаталог. При импорте данных выполняется синхронизация метакаталога с подключенным каталогом. Когда администратор вносит изменения в метакаталог, метакаталог надлежащим образом копирует эти изменения в подключенный каталог. Подобным образом, когда локальные администраторы вносят изменения в подключенный каталог, метакаталог может отразить эти изменения. Метакаталог может также копировать информацию из подключенного каталога в другие подключенные каталоги по мере необходимости.
При посредничестве записи (часто называемые псевдонимами) в базе данных метакаталога содержат указатели на данные в другом подключенном каталогом. Когда клиент осуществляет поиск и доступ к этим данным, сервер метакаталога выступает в качестве посредника, выполняя прозрачное извлечение этих данных от имени клиента и других сервисов.
Метакаталог выполняет такие операции управления и организации доступа к нескольким каталогом одновременно, создавая каталог, более крупный, чем совокупность его составляющих, как показано на рисунке ниже.

Рисунок 10. Информационный поток в метакаталоге
Конечные пользователи могут осуществлять поиск в метакаталоге и находить требуемые им ресурсы вне зависимости от того, в каком каталоге эти ресурсы находятся. Пользователи могут также размещать и изменять информацию в метакаталоге по мере необходимости.
Объединение каталогов
Метакаталог представляет собой объединение всех каталогов в организации; функция объединения позволяет создать общее представление всех людей и ресурсов в организации.
На следующем рисунке эта концепция иллюстрируется на примере использования объекта человека/пользователя.

Рисунок 11. Объединение в каталоге
Объекты в каждом подключенном каталоге определяют только некоторые аспекты/атрибуты пользователя, характерные для данной системы. Например, каталог электронной почты определяет пользователя Fred только относительно системы электронной почты. Он не учитывает данные из каталога отдела кадров или сетевого каталога, определяющие другие аспекты отношений Фреда с организацией. С другой стороны, объект пользователя Fred в метакаталоге представляет его полностью, собрав все его атрибуты из каждого подключенного каталога и объединив их в объект, характеризующий пользователя Fred и его отношения с компанией. Метакаталог выполняет объединение с использованием двух методов интеграции каталогов: синхронизации и посредничества.
Локальные наборы данных поддерживают приложения, и позволяют осуществлять локальный контроль данных. Такое распределение данных приемлемо не только с географической и организационной точки зрения, но также и с точки зрения производительности и приложения.
Хотя объединение включает данные из многих источников, это объединение является настолько же виртуальным, насколько и физическим. База данных метакаталога содержит данные из других каталогов, и может фактически заменить несколько каталогов. Она также синхронизована с данными, хранящимися в других каталогах. Кроме того, в некоторых случаях метакаталог содержит указатели на данные из других каталогов вместо самих данных.
Интеграция пространства имен каталога
Пространство имен – это набор правил, определяющих способ назначения имен объектам каталога. Различия в пространствах имен обычно являются наиболее видимыми отличиями в реализациях каталогов. Например, каталоги могут отличаться как количеством допустимых уровней иерархии, так и длиной (в символах) каждого компонента имени.
Для того эффективной поддержки требований различных сервисов каталогов метакаталог должен поддерживать несколько пространств имен в своем хранилище данных. В частности, база данных метакаталога должна поддерживать пространство имен метакаталога и пространство имен, характерное для каждого подключенного каталога.
Пространство имен метакаталога – это точка, в которой пересекаются все каталоги в организации, формируя каталог предприятия или глобальный каталог.
Помимо пространства имен метакаталога, существуют пространства имен для каждого подключенного каталога. Важно понять разницу между самим подключенным каталогом и пространством имен каталога в базе данных метакаталога. Пространство имен подключенного каталога в базе данных метакаталога включает содержимое подключенного каталога полностью или частично, тогда как подключенный каталог представляет собой отдельный каталог, откуда извлекается информация.
Пространство имен каждого подключенного каталога содержит только объекты и атрибуты из подключенного каталога определенного типа. Другими словами, пространство имен каждого подключенного каталога поддерживает собственное пространство имен среды, из которой исходит содержимое. Эта концепция представлена на следующем рисунке.

Рисунок 12. Поддержка нескольких пространств имен
Эти различные пространства имен можно рассматривать как разные «представления» данных в базе данных метакаталога. Пространство имен метакаталога представляет всеохватывающее представление каталога предприятия, разработанное администратором. Различные пространства имен подключенных каталогов дают точное представление определенных типов объектов и атрибутов в базе данных так, как они выглядят в подключенном каталоге. Содержимое пространства имен подключенного каталога представляется администратору так же, как и в самом подключенном каталоге. Основными причинами использования пространства имен подключенного каталога являются:
• Повседневные потребности системного администратора.
• Управление на основе каталога.
• Централизованное управление каталогом.
Представим администратора, использующего метакаталог для управления подключенным каталогом. При возникновении проблем с этим каталогом администратору не требуется постоянно использовать пространство имен метакаталога для управления подключенным каталогом. Администратору следует использовать такое представление метакаталога, которое позволит ему сразу перейти к проблеме. Пространство имен подключенного каталога позволяет администраторам работать с подмножеством метакаталога, относящимся к определенной системе.
Поддержка нескольких пространств имен также необходима для модели управления полностью на основе каталога. Поддержка нескольких пространств имен позволяет администраторам разместить объекты подключенного каталога до фактической интеграции этих объектов в пространство имен метакаталога. После этого администраторы могут просматривать подключенный каталог в привычном формате, а также в формате пространства имен метакаталога. Например, если метакаталог включен и работает, скорее всего, каталоги на основе NOS и каталоги приложений постепенно, по очереди, будут интегрироваться в метакаталог. Администратор должен иметь возможность интегрировать содержимое целевого каталога в пространство имен метакаталога таким образом, чтобы не повредить метакаталог.
Поддержка нескольких пространств имен также необходима для реализации модели централизованного управления каталогом. Поскольку она поддерживает и пространство имен метакаталога, и пространство имен каждого подключенного каталога, база данных метакаталога может содержать объекты каталога, которые не находятся в пространстве имен метакаталога. Хотя при этом не выполняется копирование этих объектов в другие подключенные каталоги, метакаталог предоставляет администратору возможность управления этими объектами из пространства имен подключенного каталога.
Задача управления идентификационной информацией
Метакаталог также предлагает решение задачи управления идентификационной информацией. Сведения, представленные в этом разделе, представляют собой продолжение предыдущего обсуждения.
Как показано на следующем рисунке, идентификационная информация – это сводка информации о людях, приложениях и ресурсах, которая в большинстве ИТ-компаний рассредоточена по каталогам и базам данных. Примерами идентификационных данных, связанных с людьми, являются имена, электронные адреса, зарплаты и названия должностей. Идентификационная информация приложений включает сетевые адреса, по которым клиенты могут находить серверы. Также она включает списки сервисов, предоставляемых приложениями. Сетевые ресурсы, такие как принтеры, также имеют идентификационные атрибуты, указывающие их расположение и поддерживаемые возможности печати.





Рисунок 13. Проблема управления идентификационной информацией
Проблемы управления идентификационной информацией
Разнообразие идентификационных данных и множество мест, где эти данные находятся, вызывают следующие проблемы управления:
• Не все идентификационные данные хранятся в каталогах или показываются через интерфейс сервиса каталогов, такой как протокол LDAP. Многие системы, например, показывают идентификационную информацию только через специальные программные интерфейсы приложений (API).
• Зачастую идентификационная информация дублируется в нескольких местах, и различные ее варианты, если они не проверяются, со временем могут выпасть из синхронизации.
• Количество мест, где компании должны управлять идентификационными данными, увеличивается с каждым дополнительным приложением и платформой.
• Как правило, не существует единого места, из которого администраторы и приложения могли бы осуществлять доступ или управление идентификационной информацией.
Эти проблемы затрудняют внедрение сложных и интегрированных решений по управлению идентификационной информацией. Если оставить среду предприятия в таком состоянии, это приведет к увеличению издержек и сложности администрирования.
Общие сценарии управления идентификационной информацией
Большинство крупных компаний уже работают с каким-либо проектом управления идентификационной информацией. Общие меры в этом направлении включают:
• Приложения глобальных адресных книг. Синхронизация информации почтовых ящиков между различными каталогами электронной почты внутри компании позволяет пользователям определять местонахождение других пользователей, и направлять им сообщения через различные системы.
• Решения по найму на работу/увольнению. Копирование информации о новых принятых на работу сотрудниках во все системы, требующие идентификационные данные, способствуют быстрой настройке обслуживания. Во избежание нарушения безопасности, системы так же быстро должны выполнять противоположные операции при увольнении сотрудника.
• Приложения электронной коммерции. Синхронизация идентификационной информации предприятия, в частности, цифровых сертификатов для поставщиков и пользователей экстрасети, обеспечивается каталогами, находящимися за пределами брандмауэров.
• Инициативы единой регистрации. Управление информацией об имени пользователя, пароле и правах доступа в разных платформах и приложениях.
Требования решений
Раньше многие компании пытались создать единый каталог для хранения всей идентификационной информации предприятия. Большинство этих усилий были безуспешны по нескольким простым причинам:
• Многие приложения невозможно легко настроить на использование каталогов.
• Существуют веские причины (например, требования репликации и безопасности), по которым некоторые приложения должны хранить идентификационные данные в собственных форматах.
• Политические границы препятствуют полному объединению данных, даже если это технически возможно.
Это предполагает, что идентификационные данные, по-прежнему будут существовать в разных местах. Компании должны найти способы заставить разные сервисы каталогов и хранилища приложений работать вместе. Если предположить большое количество хранилищ идентификационных данных, решение управления идентификационными данными должно обеспечивать:
• Подключение к разным типам идентификационных данных.
• Управление потоком идентификационных данных между хранилищами.
• Механизмы поддержки целостности данных по всей инфраструктуре управления идентификационной информацией.
Требования к связи
Чем к большему числу сервисов каталогов, баз данных и приложений может подключиться решение управления идентификационной информацией, тем полезнее это решение. Как показано на следующем рисунке, неизвестные данные в одном хранилище могут быть получены из другого. Решение управления идентификационной информацией может подключиться к заданному хранилищу, если оно может:
• Получать информацию об изменениях в хранилище.
• Добавлять новые объекты в хранилище.
• Удалять объекты из хранилища.
• Изменять значения атрибутов существующего объекта.
Рисунок 14. Требования к связи
Сложное решение должно иметь возможность подключиться к данным в:
• Стандартных сервисах каталогов через протокол LDAP v3.
• Существующих популярных приложениях электронной почты и сервисах каталогов, не совместимых с LDAP.
• Приложениях планирования и управления ресурсами предприятия (ERP).
• Базах данных с использованием таких средств доступа, как Microsoft SQL Server™.
• Приложениях с использованием программного интерфейса приложения (API).
Поток управления информацией
Поток управления информацией представляет собой процесс управления перемещением идентификационной информации между хранилищами. Для управления этим перемещением поток управления информацией должен иметь возможность:
• Определять изменения в идентификационных данных и копировать изменения в другие хранилища.
• Собирать данные из различных хранилищ в метакаталоги, содержащие целостное представление идентификационных данных предприятия.
• Отслеживать изменения расположения связанных объектов в деревьях каталогов и других хранилищах при периодической реорганизации.
Обработка событий изменения
События изменения возникают каждый раз, когда администраторы, пользователи или приложения добавляют, удаляют или изменяют часть идентификационных данных в хранилище. При отсутствии управления изменения идентификационных данных быстро становятся неорганизованными. Поэтому, решения по управлению идентификационными данными должны содержать средства обнаружения изменений, выполнения необходимых преобразований формата данных и последующего обновления всех хранилищ, которые должны отобразить изменения. Например, если администратор добавляет нового сотрудника в базу данных отдела кадров, это событие изменения должно вызвать отображение этого добавления в системах, используемых этим человеком. На рисунке ниже показано распространение изменения в других каталогах и приложениях.

Рисунок 15. Обработка событий изменения
Возможности объединения данных
Хотя идентификационная информация, в большинстве случаев, рассредоточена по всему предприятию, каталоги, содержащие объединенные идентификационные данные из множества других хранилищ, могут быть очень полезными. Концепция метакаталога впервые была предложена The Burton Group, которая использовала термин «объединение» для обозначения совокупного представления идентификационных данных предприятия.
Используя метакаталог, приложения могут осуществлять доступ к разной информации в одном месте, используя единый метод доступа и единую модель безопасности, вместо того чтобы взаимодействовать с каждым исходным хранилищем по отдельности.
Кроме того, метакаталоги обеспечивают максимальную эффективность, поскольку данные могут храниться в индексированном виде. Во время выполнения нет необходимости извлекать данные из удаленных источников через глобальные подключения. Для достижения максимальной пользы средства объединения данных должны быть способны:
• Осуществлять сбор и объединение информации из множества источников, включая каталоги, базы данных и приложения.
• Группировать связанную информацию, даже если она хранится в разных местах с применением различных способов. Например, данные о пользователе Jeff Smith могут храниться в разных системах под такими именами, как Jeff Smith, jsmith и smithj, как показано на рисунке ниже.
• Передавать изменения обратно на источники, когда пользователи или приложения вносят изменения в объединенное представление. Это означает, что метакаталоги должны быть интегрированы с инфраструктурами обработки событий изменения.

Рисунок 16. Объединение данных в метакаталоге
Отслеживание связанных объектов
Когда администраторы осуществляют развертывание решений управления идентификационной информацией, они должны сообщить механизму управления идентификационной информацией, что Jeff Smith, jsmith и smithj – одно и то же лицо. После этого, как видно на следующем рисунке, механизм должен иметь возможность отслеживания связей по мере периодической реорганизации идентификационных данных. Решение не должно потерять пользователя просто потому, что он изменил положение в структуре дерева каталога, например, при переходе из бухгалтерии в отдел продаж.

Рисунок 17. Отслеживание связанных объектов
Управление целостностью
Управление целостностью – это процесс обеспечения целостности данных, предполагающий, что данные не будут повреждены при изменении и не потеряют синхронизацию с хранилищем. Функции управления целостностью должны иметь возможность:
• Поддерживать связи владения для идентификационных данных.
• В случае ошибок действовать адекватно.
• Поддерживать целостность ссылок в идентификационных данных.
Владение
Важным аспектом управления идентификационной информацией в предприятии является признание связей принадлежности, которые должны поддерживаться между приложениями и данными. Например, имя почтового ящика принадлежит системе электронной почты, содержащей почтовый ящик. В большинстве компаний система отдела кадров владеет данными, определяющими, является ли человек действительным сотрудником. При отсутствии инфраструктуры управления идентификационными данными, эти связи владения сохраняются по умолчанию, потому что никакие приложения не имеют возможности доступа и изменения данных электронной почты и отдела кадров. Однако при развертывании коннекторов синхронизации и управления информационным потоком ситуация изменяется.
Рассмотрим случай, когда информация почтового ящика синхронизируется с каталогом отдела кадров через коннектор, как показано на рисунке ниже.

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

Рисунок 19. Управление отказами
Например, если изменяются должность, зарплата и лимит затрат сотрудника, а метакаталог не может обновить должность сотрудника в приложениях, идентификационные данные будут в беспорядке. Обычно это означает, что администратор должен изучить ситуацию и внести исправления.
В системах баз данных эта проблема обычно разрешается с использованием транзакций, обеспечивающих успешное выполнение всех обновлений их откат. К сожалению, большинство сервисов каталогов и интерфейсов программирования приложений не поддерживают транзакции. Это означает, что решения по управлению идентификационной информацией должны найти другие способы, обеспечивающие отображение изменений во всех хранилищах, например, использование журнальных механизмов обеспечения требуемого состояния, продолжающих запрашивать изменения до их утверждения.
Целостность на уровне ссылок
Еще одна проблема, которую решения по управлению идентификационными данными разделяют с базами данных, заключается в поддержке целостности ссылок между хранилищами. Целостность на уровне ссылок касается необходимости поддерживать связи между значениями связанных фрагментов данных в различных местах. Например, решения по управлению идентификационными данными должны обеспечивать согласованность должности сотрудника с лимитом затрат в системе снабжения. Базы данных разрешает эту проблему с помощью сохраненной процедуры и запускают средства, позволяющие администраторам выполнять бизнес-правило при каждом изменении значений данных.
В настоящее время сервисы каталогов не предоставляют подобных средств. Поэтому решения по управлению идентификационной информацией должны обеспечивать способность выполнения бизнес-правил, отклоняющих изменения, не соответствующие требованиям целостности на уровне ссылок. Только метакаталог может разрешить все эти проблемы.
Метакаталог как корпоративное решение
Если Интернет/интрасеть, внутренняя электронная почта и другие каталоги содержат идентификационную информацию только о некоторых людях где–то, метакаталог может содержать идентификационную информацию обо всех и везде. Метакаталог позволяет интегрировать любое количество разнородных хранилищ идентификационных данных практически в любом формате. Таким образом, метакаталог становится корневым источником идентификационной информации внутри предприятия. Метакаталог обеспечивает рациональное и унифицированное представление объектов идентификационных данных, включающих атрибуты из разных каталогов. Такая интеграция позволяет снизить административные расходы, устранить дублирование, уменьшить противоречия и сделать идентификационную информацию общедоступной. Метакаталог является достаточно гибким для того, чтобы адаптироваться к любой организации, структуре, политике и стилю управления предприятия, и достаточно динамичным для изменения вместе с ними.
Источники
Метакаталог собирает идентификационную информацию из других подключенных каталогов и хранилищ предприятия. Практически все системы электронной почты, баз данных и прочие приложения каталогов могут экспортировать свое содержимое в определенной форме. Метакаталог может собирать эти данные посредством обмена файлов, почтовых сообщений или оперативной передачи на основе протоколов. Администратор каталогов или конечный пользователь может добавить другую идентификационную информацию метакаталога.
Содержимое
Обычно считается, что каталоги содержат идентификационную информацию о людях, такую как адреса электронной почты, но такое представление является ограниченным. Метакаталог может содержать гораздо больше информации о любом реальном объекте. Объектами могут быть:
• Физические объекты, такие как люди или компьютеры.
• Концептуальные объекты, такие как организации или отделы.
• Географические объекты, такие как страны/регионы или города.
• Цифровые объекты, такие как документы и файлы для оперативного просмотра.
Единственное требование метакаталога состоит в том, что эти объекты должны быть организованы в некоторую иерархическую структуру. Например, человек может быть описан как часть отдела, который является частью организации, которая находится в домене Интернета или в стране/регионе. В многонациональной компании сотрудник может быть частью подразделения, расположенного в стране/регионе, находящемся ниже корпорации в организационной структуре.
Сотрудник не обязательно занимает нижний уровень в иерархии. Например, документ или персональный компьютер сотрудника может также быть представлен элементом каталога ниже элемента сотрудника в этом дереве.
Управление
Управление содержимым и безопасностью метакаталога может быть централизованным, распределенным или представлять их комбинацию. Метакаталог может быть создан таким образом, чтобы изменения некоторых элементов выполнялись только в подключенном каталоге и затем импортировались в метакаталог. Изменения других элементов могут быть выполнены только в метакаталоге и затем скопированы в подключенный каталог. Разные люди могут управлять разными частями метакаталога. Такой уровень управления распространяется не только на элементы, но и на отдельные атрибуты. Поэтому конечные пользователи могут частично управлять собственной идентификационной информацией, например, номером телефона или адресом. Метакаталог не навязывает какую-либо модель управления. Он позволяет создать каталог, управление которым соответствует реалиям организации и ее требованиям к безопасности и управлению доступом.
Документирование архитектуры сервисов каталогов
Точное документирование развертывания сервисов каталогов крайне важно для управления, поддержки, эксплуатации и обслуживания решения каталога. Прежде чем приступить к активному управлению, эксплуатации, поддержке или обслуживанию чего-либо, нужно сначала понять, что это такое, как оно работает, кто за что отвечает и как оно работает при нормальной нагрузке.
Шесть значений «сигма»
Шесть значений «сигма», взятые из одноименной книги (Harry, Mikel, Ph.D и Richard Schroeder. Six Sigma. Doubleday Press, февраль 2000) предполагают следующее:
• Ты не знаешь того, что ты не знаешь.
• Ты не можешь сделать то, что не знаешь.
• Ты не узнаешь до тех пор, пока не измеришь.
• Ты не измеришь до тех пор, пока не оценишь.
• Ты не оценишь то, что не измеришь.
Эти значения ясно иллюстрируют необходимость понять, что имеешь, а также значение, связанное со способностью оказать значительное влияние на то, что имеешь. Эти значения также показывают ответственность и учет ИТ-средств. В следующем разделе рассматриваются операции и документация.
Операции и документация
Точное документирование каталога и его сервисов поддержки является очень важным. Полное и точное документирование архитектуры и схемы каталога – первый шаг к эффективной работе каталога.
Документирование – это не одноразовый процесс; документирование каталога – это повседневная работа, которая должна проводиться при возникновении изменений. Помимо очевидных повседневных требований управления каталогом компании, есть более серьезные проблемы, возникающие при приобретении и продаже бизнеса.
Хорошая документация обеспечивает следующие преимущества:
• Усовершенствование управления операциями
• Улучшение обслуживаемости систем
• Упрощение модернизации системы
• Улучшение подготовки оперативной группы
Документацию, создаваемую и используемую оперативной группой, как правило, можно классифицировать по источникам, к которым относятся поставщики оборудования и ПО, служба поддержки, разработчики приложений и команда поддержки.
Что и как документировать
Важно отметить, что документирование архитектуры каталога состоит из множества взаимосвязанных компонентов. К ним относятся следующие:
• Схемы, иллюстрирующие физическое размещение серверов каталогов.
• Схемы, указывающие логический поток данных в каталоге и за его пределами.
• Копии файлов конфигураций с описаниями их использования.
• Пошаговые инструкции операций.
• Службы сервиса и технической поддержки.
• Схемы устранения неполадок и пользовательские прикладные системы.
• Руководства по оборудованию и ПО сторонних производителей.
Далее последовательно приведены примеры того, что эти компоненты могут подразумевать.
Руководства поставщиков оборудования и программного обеспечения
Хранение и обслуживание копий всех руководств поставщиков по продуктам и решениям на основе каталога является крайне важным (это касается как оборудования, так и ПО). Они должны храниться в центральной библиотеке службы поддержки, чтобы обеспечить их доступность для всех сотрудников, групп или отделов, ответственных за эксплуатацию, администрирование или обслуживание каталога. Они должны обновляться по мере изменения версий аппаратных средств и ПО.
Руководства по эксплуатации
Существуют различные виды руководств по эксплуатации, в зависимости от целевой группы. В следующих разделах представлено несколько примеров того, как можно объединить документацию в рабочее руководство, зависящее от потребностей группы.
Сервисная служба
Предположим, что сервисная служба (поддержка 1-го уровня) реагирует на проблемы клиента и выступает в качестве службы высокоуровневого наблюдения для системы мониторинга. Для этой группы необходимо создать четкий комплект документации. Он включает:
• Информацию о расположении серверов и компонентов каталога в сети.
• Первые шаги по устранению неполадок (в пределах соответствия этого вида деятельности данной группе) в случае проблем с каталогом.
• Четкие процедуры передачи, в том случае, если проблема выходит за пределы возможностей поддержки 1 уровня.
• Инструкции по соответствующему уведомлению клиентов, если отказ затрагивает конечных пользователей.
Конечно же, все это полностью зависит от возможностей сервисной службы, размера организации, а также от готовности других групп поддержки осуществлять мониторинг и реагировать на проблемы каталога.
Группа операций каталога
Группа операций каталога (поддержка 2-го уровня) – это группа, отвечающая за обслуживание сервера, резервное копирование и восстановление, а также за мониторинг (производительности, состояния и т.д.).
Служба операций каталога должна быть снабжена четкими, последовательными и актуальными руководствами, описывающими:
• Информацию относительно местоположения серверов и компонентов каталога в сети.
• Информацию о логических потоках данных в каталоге.
• Информацию обо всех процессах и программах, обеспечивающих поддержку сервисов каталога.
• Информацию обо всем оборудовании, обеспечивающем поддержку сервисов каталога.
• Инструкции по устранению неполадок (в пределах соответствия этого вида деятельности данной группе) в случае проблем с каталогом.
• Четкие процедуры передачи, в том случае, если проблема выходит за пределы возможностей поддержки 2-го уровня.
• Инструкции по соответствующему уведомлению клиентов, если отказ затрагивает конечных пользователей.
Группа архитектуры каталога
Группа архитектуры каталога включает разработчиков систем, инженеров и всех сторонних консультантов или системных интеграторов, помогающих в разработке, развертывании, поддержке и модернизации каталога. Этой группе нужны официальные руководства по эксплуатации, содержащие следующее:
• Подробную информацию относительно местоположения серверов и компонентов каталога в сети.
• Подробную информацию о логических потоках данных в каталоге.
• Подробную информацию обо всех процессах и программах, обеспечивающих поддержку сервисов каталога.
• Подробную информацию обо всем оборудовании, обеспечивающем поддержку сервисов каталога.
• Подробные инструкции по устранению неполадок, позволяющие разрешить любую проблему, котораяможет возникнуть в каталоге.
• Порядок информирования групп поддержки 1-го и 2-го уровня о том, как лучше всего уведомить клиентов и руководство о проблемах, исправлениях и времени на устранение неполадок.
Не все службы поддержки могут быть построены в точном соответствии с приведенными выше примерами, но очень важно, чтобы каждый уровень поддержки имел точную и актуальную информацию для максимально эффективного выполнения задач поддержки решения на основе каталога.
Восходящая документация (Физическая структура)
Для начала важно понять физическую схему (архитектуру) развертывания каталога. При наличии более одного каталога и переходе к решению на основе метакаталога в целях упрощения и централизации управления, а также консолидации служб для облегчения работы приложений каталога, необходимо выполнить подробное документирование всех решений на основе каталога, попадающих под это описание.
Вполне возможно, что компания по системной интеграции, активный посредник, консультационная фирма или производитель каталога, помогавшие на начальных стадиях проектирования и развертывания, смогут помочь и на этом важном этапе. В лучшем случае, у вас уже есть схема физической структуры (проект инфраструктуры, план архитектуры, размещение серверов, сервисов и т.д.) в комплекте документов по проектированию и развертыванию каталога. Если это не так, запросите всю имеющуюся документацию по проекту.
Существуют различные инструменты и утилиты, которые могут помочь в создании схемы решения на основе каталога. Например, программа создания чертежей и схем Microsoft Visio® Technical Edition уже многие годы используется для создания планов развертывания компьютеров и сетей. Несмотря на ее многочисленные преимущества, существует еще множество других хороших программ, простых в использовании и обновлении. Каким бы образом ни была получена эта информация, главное, чтобы она была точной и актуальной.
Нисходящая документация (Логическая структура)
Понимание логического потока информации через каталог (процессах, приложениях, инструментах автоматизации, и т.д.) так же важно, как и понимание физической структуры (расположения серверов в сети). Если вы не понимаете в полной мере, как работает каталог, как с логической, так и с физической точки зрения, вы не сможете осуществлять активный мониторинг его производительности, целостности и надежности. Кроме того, будет невозможным надлежащим образом устранять неполадки при их появлении.
После составления схемы физической архитектуры, следующий этап состоит в том, чтобы вернуться назад и записать:
• Где находятся данные (местоположение баз данных).
• Где находятся и выполняются определенные процессы.
• Где находятся файлы конфигурации.
• Порядок выполнения для всех процессов и функций.
• Способ ввода данных в каталог. Это включает все возможные источники ввода данных — от высокоуровневых программных записей или модификаций до низкоуровневых изменений на уровне пользователей.
• Все приложения каталога, инструменты и утилиты, напрямую поддерживающие или использующие каталог.
Помимо документирования всех компонентов процесса, составляющих каталог, нужно также составить точный план перемещения данных в системе, а также схему зависимостей между процессами и приложениями каталога. Чтобы продумать, какая информация подлежит обязательному документированию, нужно, как минимум, знать следующее:
• Размещение баз данных. Необходимо знать расположение и функции всех баз данных, связанных с каталогом, являются они централизованными или распределенными, их размер, файловую систему, в которой они расположены, систему управления базами данных (поставщик и версия) и целевых пользователей, которых обслуживает база данных.
• Место расположения и выполнения определенных процессов. Нужно также иметь сведения обо всех процессах в каталогах или связанных с каталогами, работающих в контексте каталога, обеспечивая работу сервисов и процедур автоматизации, обслуживание или поддержку приложений. Если они были разработаны внутри предприятия, необходимо иметь всю информацию по поддержке и программам. То же относится и к приложениям, инструментам, утилитам и программам сторонних производителей, интегрированным в решение на основе каталога. Убедитесь, что вы располагаете всей информацией о версиях, пакетах обновлений, исправлениях, а также информацией по обновлениям, относящейся к требуемым программам или процессам.
• Где находятся файлы конфигурации. Это больше относится к плану аварийного восстановления, но является достаточно важным, чтобы повторить здесь; необходимо иметь точный и актуальный набор всей конфигурационной информации, относящейся к каталогу (сюда относятся, например, схема, специальные настройки сервера, файлы конфигурации и т.д.).
• Порядок выполнения всех процессов и функций. Все процессы или программы, выполняющиеся в пространстве каталога, имеют определенный порядок выполнения, и могут иметь конфликты с другими программами, процессами и/или приложениями. Важно иметь представление о существующих конфликтах и зависимостях. Тщательное документирование и понимание этого элемента значительно облегчает устранение неполадок и влияет на своевременное восстановление в случае возникновения проблем.
• Как осуществляется ввод и извлечение данных из каталога. Этот элемент включает в себя возможные источники ввода и вывода данных, от программных записей или модификаций до изменений на уровне пользователей. Необходимо всегда знать, откуда поступают данные в каталог. Автоматизация функций ввода стандартных данных может сэкономить время и средства и значительно сократить количество ошибок оператора в каталоге, однако автоматизация также затрудняет устранение неполадок. Вы должны знать, откуда поступает вводимая в каталог информация, а также возможные источники вывода содержимого (возможны проблемы безопасности!).
• Все приложения, инструменты и утилиты на основе каталога, либо напрямую поддерживающие, либо использующие каталог. Нужно также иметь сведения обо всех приложениях, инструментах и утилитах, работающих в контексте каталога, обеспечивая работу сервисов, процедур автоматизации, текущее обслуживание, поддержку приложений или обслуживание конечного пользователя. Если они были разработаны внутри предприятия, необходимо иметь всю информацию по поддержке и программам. Если они были приобретены или разработаны сторонним производителем, убедитесь, что вы располагаете всей информацией о версиях, пакетах обновлений, исправлениях, а также информацией по обновлениям, относящейся к требуемой программе или процессу.
Мониторинг компонентов каталога
Мониторинг – единственный показатель состояния используемого решения каталога. Опыт показывает, что компании, не использующие активный мониторинг, всегда становятся жертвами кризисных ситуаций (аварий, которые можно было предвидеть и избежать), сразу же попадая в незавидное положение, когда им приходится срочно реагировать на ситуации, в которых клиенты страдают от сбоев и отказов в обслуживании. Как часто об отказе в обслуживании сообщает клиент или конечный пользователь (обычно звонком в службу поддержки, указывая на проблемы с подключением или доступом к системе или сервису)? При небольших дополнительных усилиях можно реализовать схему активного мониторинга, которая определенно сэкономит время и средства, а также значительно повысит качество работы клиентов.
Введение в мониторинг
Каталог является ядром вычислительной среды, и используется клиентами для входа в сеть, аутентификации в сервисах и приложениях, а также для поиска других пользователей и ресурсов в сети. Сбои в работе сервисов каталога приводят к простою пользователей и приложений, что означает потерю производительности и денег.
Осуществляя мониторинг каталога, можно сразу же узнать о сбое в работе, а в некоторых случаях даже до того, как это случится. Используя более сложные инструменты мониторинга, можно еще более эффективно прогнозировать неполадки, видеть, где имеет место снижение производительности, и использовать полученную информацию для настройки системы.
Система мониторинга включает три элемента:
• Устройства и сервисы, подлежащие мониторингу.
• Решение или система мониторинга.
• Процессы оповещения, уведомления и передачи, определяющие реакцию на событие.
Это показано на следующем рисунке и более подробно разъяснено ниже.
Рисунок 20. Компоненты системы активного мониторинга
Модуль зондирования устройств и приложений. Этот элемент представляет собой функцию или процесс, ответственный за периодическую проверку состояния контролируемого сервиса, устройства, узла, приложения или другой системы. Если устройство не отвечает, генерируется оповещение, указывающее отказавшее устройство и характер неисправности.
Модуль корреляции событий. Этот элемент получает данные от модуля зондирования и коррелирует эти данные для определения основной причины. Затем он подавляет любые события, которые могли произойти в результате других событий. Например, отказ маршрутизатора отразится на работе всех узлов, систем и устройств, расположенных ниже этого устройства, что сделает их временно недоступными. После подавления косвенных событий, модуль создает одно или несколько оповещений и направляет их в модуль уведомления.
Модуль уведомления. Этот модуль получает оповещения от модуля корреляции и генерирует уведомления для ответственных за реагирование (заданных предварительно). Кроме того, этот модуль может генерировать уведомления для системы автоматического реагирования, запрограммированной на перезагрузку сервиса или принятие других мер по устранению неполадок.
Система мониторинга, показанная на рисунке выше, представляет концептуальную модель. Люди или программные приложения могут заниматься выполнением любых элементов этой модели. Цель состоит в максимальной автоматизации этих элементов и их реализации в связанном, предсказуемом решении, отвечающее за определенные потребности мониторинга.
Типы мониторинга и систем мониторинга
Существует три основных типа мониторинга:
• Мониторинг неисправимых ошибок
• Мониторинг исправимых ошибок
• Мониторинг производительности
Неисправимые ошибки возникают в результате отказа оборудования или сети (т.е. при аварии на сервере каталога или отказе диска, вызвавшего сбой в работе каталога или сервиса).
Исправимые ошибки обычно возникают в связи с проблемами данных или программирования, вызванными некорректными или противоречивыми данными в каталоге.
Мониторинг производительности сообщает важные сведения о производительности системы, выявляя узкие места, точки конфликтов и общее снижение производительности. Мониторинг производительности также может предоставлять информацию о средних уровнях, позволяя определить тенденции, что полезно при выборе времени проведения планирования ресурсов или выполнения обновления инфраструктуры каталога.
Существует множество коммерческих систем мониторинга, которые наверняка включают все или большинство из описанных выше основных элементов. Выбранное решение зависит от таких факторов, как решение на основе каталога, продукты, их построение (централизованное или распределенное) и соглашения об уровне обслуживания с руководством и клиентами.
Методы мониторинга
Существует несколько способов реализации мониторинга. В данном разделе рассматриваются наиболее популярные и надежные методы.
Протокол SNMP (Simple Network Management Protocol). Несмотря на то, что основное применение SNMP состоит в управлении сетевым оборудованием (коммутаторами, концентраторами, маршрутизаторами), этот протокол также можно использовать для мониторинга и управления приложениями и процессами, выполняющимися на серверах и других устройствах поддержки. SNMP позволяет приложениям управления осуществлять мониторинг состояния объекта в сети. Кроме того, можно осуществлять асинхронное уведомление приложения управления с использованием SNMP-ловушек при возникновении определенных событий или ошибок (например, если серверный процесс неожиданно прервется).
LDAP-зондирование. Один из наиболее простых и полезных способов мониторинга каталога заключается в его зондировании путем подключения с клиентской системы и применения LDAP-команд и/или запросов. Например, простой инструмент зондирования может подключиться к каталогу и осуществить поиск заданного элемента (элемент устанавливается специально для этой цели). Если время реакции не превышает заданный период, каталог считается работоспособным. Если нет, инструмент зондирования может генерировать ошибку (либо оповещение, либо специальное уведомление).
Инструменты зондирования, ориентированные на определенную операционную систему. Большинство операционных систем поставляется с инструментами, обеспечивающими мониторинг соответствующих сервисов, включая собственные сервисы каталогов. Информация такого типа может помочь определить, когда в каталоге возникнет проблема из-за операционной системы.
Косвенный мониторинг. Мониторинг приложений, непосредственно затрагивающих каталог (использующих или осуществляющих к нему доступ), представляет скорее взгляд конечного пользователя на реагирование и надежность системы.
Анализ файлов журналов. Можно автоматически сканировать файлы журналов каталога на наличие событий, указывающих на состояние ошибки. Кроме того, можно осуществлять мониторинг условий, указывающих на проблемы производительности. Анализ файлов журналов также является прекрасным методом активного мониторинга.
Общие принципы мониторинга
Этот раздел содержит подробное описание некоторых фундаментальных концепций и принципов мониторинга каталога.
Незаметный мониторинг
Необходимо всегда понимать побочные эффекты стратегии мониторинга. Плохо разработанное или реализованное решение может оказать неблагоприятное воздействие на производительность или эксплуатацию решения на основе каталога. В целом, нужно стремиться сделать решение как можно более незаметным, получая при этом всю требуемую информацию.
Как же сделать решение незаметным? Во-первых, решение должно быть как можно более легковесным и предоставлять при этом всю релевантную информацию. Например, при использовании метода зондирования, достаточно извлечь один элемент, доказывающий работоспособность каталога, вместо нескольких элементов. Кроме того, зондирование следует осуществлять только тогда, когда это крайне необходимо для достижения адекватного реагирования. Это уменьшает дополнительную нагрузку на каталог, а также способствует ограничению дополнительной нагрузки на сервисы. Зондирование каталога каждые пять секунд даст информацию об отказе гораздо быстрее, но может оказать заметную нагрузку на сервисы. Зондирование раз в минуту или раз в 15 минут, как правило, дает лучшие результаты. Частота зондирования, конечно же, зависит от существующих соглашений об уровне обслуживания.
Каскадные отказы
Возникший отказ также может вызвать возникновение других оповещений в системе мониторинга. Например, отказ одного набора реплицируемых серверов каталога может увеличить нагрузку на остальные серверы, что, в свою очередь, вызовет возникновение оповещений от работающих серверов. В этом случае можно отключить второстепенные сервисы или приложения, чтобы уменьшить нагрузку на оставшиеся серверы. Кроме того, следует еще раз провести проверку возможностей ресурсов и принять меры на случай повторного возникновения такого же отказа.
Ведение записи проблем
Постройте мониторинг таким образом, чтобы обеспечить точную запись событий и проблем. Например, при использовании коммерческой системы сетевого управления и мониторинга, регистрирующей события в стандартном формате, следует периодически извлекать записи, соответствующие каталогу, накапливая и архивируя эти журналы на центральном узле для последующего периодического просмотра. Эти извлеченные журналы предоставляют важные данные о тенденциях, позволяющие выявить повторяющиеся проблемы (причинную информацию), помогающие с планированием ресурсов и предоставляющие ценную информацию относительно общей надежности и доступности системы каталогов.
Поддержка письменного плана
И, наконец, для каждого типа или случая отказа, события или проблемы создается письменный план, предусматривающий своевременные, точные, последовательные ответные действия, допускающие многократное использование. Сделаем акцент на выражении «допускающие многократное использование». Если не собирать информацию о повторяющихся событиях и не выполнять последовательный план по разрешению этих проблем, тогда время, ресурсы и деньги будут потрачены впустую!
Технологии уведомления
Активный сбор информации о событиях в режиме реального времени будет бесполезен, если не уведомлять ответственные стороны, чтобы они могли применить план действий. Уведомление о событиях преследует следующие четыре цели:
• Уведомление сторон, ответственных за исправление проблемы
• Уведомление сторон, ответственных за администрирование системы
• Уведомление сторон, затронутых событием
• Уведомление каждой из сторон надлежащим образом
Как только проблема обнаружена, система должна уведомить ответственных за ее исправление. Ответственными обычно являются специалисты высокого уровня, например, разработчики системы, инженеры или консультанты, выполнившие разработку и развертывание системы. В зависимости от типа и серьезности проблемы и сложности ответного действия на событие, это также может быть системный администратор или технический специалист, обученный адекватно отреагировать на сбои в работе каталога. Как правило, этот тип уведомления является срочным, особенно для ответственных каталогов непрерывного использования в режиме 24×7. Обычно такие уведомления поступают в форме телефонного звонка или сообщения на пейджер.
Система уведомления также должна уведомить группу, ответственную за администрирование каталога. Этот тип уведомления носит информационный характер и может передаваться в виде сообщения электронной почты; это позволит ответственной группе узнать о проблеме, над которой ведется работа. Очень важно, чтобы между ответственными за исправление проблемы и группой, обеспечивающей административную поддержку, было тесное взаимодействие.
Пользователей и клиентов также можно уведомить об отказе; хуже всего, если пользователь или клиент первый уведомит о проблеме. Хотя клиентам необязательно знать подробности проблемы, лучше чтобы они были информированы о перерыве в работе (или ожидаемом перерыве) и имели информацию о продолжительности перерыва. Такие уведомления могут направляться в виде сообщений электронной почты. С другой стороны, если событие повлияло но систему электронной почты, можно использовать веб-страницу с описанием информации о перерывах в работе системы, сообщения телефонной голосовой почты или просто уведомить персонал службы поддержки, чтобы клиенты могли получить информацию, позвонив в службу поддержки.
Действия
После того, как событие было зафиксировано, и нужные люди были должным образом уведомлены, необходимо предпринять следующие меры:
• Свести к минимуму общее воздействие.
• Устранить проблему.
• Определить, что случилось и почему.
• Произвести анализ основной причины.
• Разработать формальный план, обеспечивающий долгосрочное решение и пригодный для многократного использования, на случай повторного возникновения подобного события.
Все это может показаться само собой разумеющимся, однако эти действия составляют критически важный этап, который часто игнорируют в связи с постоянным кризисным состоянием или ограниченностью ресурсов. Если же реализовать превентивные меры, описанные в других разделах этого документа, можно считать, что большая часть работы уже выполнена.
За исключением средств анализа основной причины, большинство инструментов и средств, необходимых для обеспечения долгосрочного и надежного решения, уже входят в число повседневных операций. Дополнительные сведения о принятии необходимых мер приведены в разделах «Управление каталогом» и «Обслуживание каталога».
Управление каталогом
Управление решением на основе каталога связано с повседневным процессом обеспечения безопасности, защиты и правильной работы программных и аппаратных компонентов. Безопасность и защита программных и аппаратных компонентов – чрезвычайно важные вопросы. Они подробно рассматриваются в документации по обеспечению безопасности MOF.
Архитектура сервисов каталогов содержит две основные области: физические (аппаратные) компоненты и программные компоненты. Активное управление обеспечивает надежность, доступность, удобство обслуживания и предсказуемость. В следующих разделах рассматриваются вопросы управления оборудованием и программным обеспечением каталога и способы реализации этих преимуществ.
Обзор управления оборудованием
Управление оборудованием напрямую связано с более ранним разделом о документировании архитектуры каталога. Как говорилось выше, невозможно управлять системами, если неизвестны их расположение, функции, зависимости и взаимосвязи с другими процессами, функциями или приложениями. Если вы еще не завершили этап документирования плана управления, пожалуйста, вернитесь к нему и завершите этот процесс, прежде чем пытаться реализовать любой из процессов управления оборудованием, описанных в этом разделе.
Эта тема также тесно связана с разделом, посвященным мониторингу, в том, что активное управление элементами оборудования является настолько эффективным, насколько эффективны процессы мониторинга состояния системы.
Обзор управления программным обеспечением
Управление программным обеспечением также напрямую связано с более ранним разделом о документировании архитектуры каталога. Как уже говорилось выше, невозможно управлять неизвестными системами. Если вы еще не завершили этап документирования плана управления, нужно вернуться к нему и завершить этот процесс, прежде чем пытаться реализовать любой из процессов управления программным обеспечением, описанных в этом разделе.
Как и в случае управления оборудованием, управление программным обеспечением также тесно связано с разделом, посвященным мониторингу, в том, что активное управление программным компонентом является настолько эффективным, насколько эффективны процессы мониторинга состояния системы.
Подводя итог, можно сказать, что управление оборудованием и ПО сервисов каталогов предполагает наличие точных знаний о том, что установлено, какова его функция и насколько хорошо оно выполняет функции, ради которых оно было установлено. Такое управление также предполагает реализацию процессов, когда можно использовать имеющиеся ресурсы поддержки с учетом иерархии в случае возникновения проблем. Это подразумевает определение многоуровневой системы поддержки, соответствующей архитектуре и ориентированной на существующие группы поддержки.
Основными вопросами, на которые нужно обратить внимание при разработке модели поддержки каталога, являются следующие:
• Насколько централизована или распределена архитектура каталога?
• Какие уровни избыточности и/или отказоустойчивости заложены каждый функциональный компонент системы (как в оборудовании, так и в ПО)?
• Существует ли центральная служба поддержки, обеспечивающая передовую поддержку при получении оповещения об отказе (либо от решения мониторинга/уведомления, либо от конечного пользователя)?
• Как реализовано делегирование административных ролей в каталоге?
Обслуживание каталога
Этот раздел подробно описывает процесс обслуживания каталога и сервисов, которые его поддерживают. Этот этап плана управления детализирует повседневный процесс защиты каталога посредством резервного копирования и восстановления, после чего разрешает более широкую проблему аварийного восстановления. Что касается аварийного восстановления, план должен включать шаги, процессы и методологии, предполагающие готовность к авариям, предотвращение аварий и только затем аварийное восстановление. Такой подход к созданию плана снижает вероятность применения пункта восстановления.
Создание плана резервного копирования и восстановления каталога
Данные, хранящиеся в каталоге, являются или очень скоро станут важными для базовых операций и производительности организации. Если каталог по какой-то причине становится недоступным (например, из-за неисправности оборудования или повреждения данных), предприятие испытает снижение производительности и финансовые потери. Разработка надежных процедур резервного копирования и восстановления каталога и компонентов системы поддержки гарантирует целостность важных данных каталога и конфигурационной информации.
Разработка самих процедур резервного копирования и восстановления в равной степени важна. Простое наличие процесса резервного копирования на ленту без четкого, лаконичного и тщательно выполняемого плана восстановления, регулярно проверяемого ответственными за процесс, повышает риск потери данных и/или серьезного отказа системы при попытке внедрения этих компонентов на ходу.
Основные принципы резервного копирования и восстановления каталога
Подобно файловым системам, данные каталогов хранятся на устройствах хранения большой ёмкости, например, жестких дисках. Эти данные могут быть повреждены или нарушены по любой из следующих причин:
• Отказ дискового носителя или контроллера (аппаратный сбой дискового устройства или дискового контроллера).
• Программные ошибки или отклонения (проблемы в программах или оперативном коде каталога, составляющем сервис каталога).
• Выполнение ошибочных операций приложениями на основе каталога (приложения, осуществляющие прямой доступ или управление данными каталога, предоставляя ошибочную информацию или выполняя неправильное удаление, изменение или добавление информации).
• Ошибка оператора (не требует объяснений – представляет наиболее частую причину повреждения или потерь!).
• Кража (несанкционированный доступ или манипуляции с данными каталога или его конфигурацией – возможна как изнутри компании, так и снаружи).
• Авария (как правило, стихийные бедствия, включая наводнения, пожары, землетрясения, а также вызванные действиями людей, например, саботаж).
Если какое-либо из перечисленных событий нанесло ущерб каталогу, необходим способ восстановления работоспособного состояния. Это может выполняться путем восстановления каталога (данных и конфигурации) с резервной копии, созданной до повреждения каталога.
Существует два способа резервного копирования каталога:
• Использование традиционных носителей, например, магнитной ленты или технологий зеркального отображения дисков.
• Применение метода репликации.
Резервное копирование и восстановление с использованием традиционных носителей
Точно так же, как и для файловых систем, хранящихся на дисковых подсистемах, для данных каталога и файлов конфигурации могут быть созданы резервные копии на традиционных носителях, например, на магнитной ленте. Можно также выполнить резервное копирование на отдельный диск, локальный или сетевой. Такие резервные копии можно использовать для восстановления потерянных или поврежденных данных в случае прекращения работы сервиса.
Резервное копирование каталога отличается от резервного копирования файловых систем в следующем:
• Файловые системы обычно значительно крупнее каталогов и требуют защиты гораздо большего объема информации. Это означает, что архивация более крупной файловой системы может потребовать использования более мощной системы накопителей на лентах, тогда как архивацию каталога можно просто выполнить на другом диске. Однако очень большие каталоги (некоторые из которых имеют многогигабайтные размеры) также могут потребовать использования решений с более высокой емкостью (например, магнитных лент).
• В отличие от файловых систем, для каталогов часто выполняется репликация для обеспечения балансировки нагрузки, отказоустойчивости, и локализации доступа в распределенной среде (с целью повышения производительности). Важно понимать трудности, связанные с восстановлением реплики каталога с ленты. В большинстве случаев лучше воссоздать поврежденную реплику с данных в равноправных копиях; данные в равноправных копиях могут быть более актуальными.
• Существующие инструменты резервного копирования каталогов обычно не поддерживают добавочное резервное копирование, при котором на ленту копируются только те данные, которые были изменены с момента последнего резервного копирования. В будущем, возможно, ситуация измениться, но в настоящее время каталоги обычно копируются целиком.
• Сервис каталогов может располагаться на нескольких распределенных серверах. Для защиты каталога нужно либо осуществлять резервное копирование для каждого сервера в отдельности, либо выполнять резервное копирование всех данных каталога с единого центрального узла.
Помимо носителей на магнитных лентах, описанных выше, можно использовать технологию зеркального отображения дисков для защиты данных. Зеркальное отображение представляет технологию, при которой данные, записанные на основной диск, также записываются на дополнительный диск. В случае повреждения основного диска, дополнительный диск можно использовать в качестве резервной копии.
Независимо от технологии, необходимо использовать такие носители, которые можно регулярно транспортировать за пределы предприятия. Резервная копия будет бесполезна, если она будет повреждена в результате того же стихийного бедствия.
Резервное копирование и восстановление с использованием технологий репликации
Несмотря на то, что традиционные технологии резервного копирования и восстановления представляют эффективный метод защиты от потери данных, они имеют один большой недостаток: восстановление большого количества данных может занять несколько часов. Такая задержка в восстановлении рабочей системы может идти вразрез с существующими обязательствами по обеспечению доступности и надежности. Использование репликации в качестве средства обеспечения отказоустойчивости и избыточности данных может помочь избежать дорогостоящих простоев, связанных с традиционными технологиями восстановления.
Реплики представляют собой оперативные копии данных каталога. В случае отказа сервера, равноправные реплики обеспечивают непрерывность обслуживания и доступа к данным на время восстановления сервера. После того, как сервер будет восстановлен, он может быть возвращен в работу в качестве сервера реплики. При адекватной структуре репликации (количестве серверов и их распределению по архитектуре) пользователи не пострадают от отказа одного сервера (он вообще может даже не узнать о возникшей проблеме).
Репликация каталога имеет еще одно преимущество: поскольку реплики каталогов обычно всегда актуальны, не нужно беспокоиться о восстановлении устаревшей копии каталога и последующем добавочном обновлении или синхронизации с другими копиями каталога. Несмотря на такое явное преимущество, необходимо также помнить о том, что большинство каталогов поддерживают «свободную» согласованность, при которой изменения, выполненные в каталоге, сначала сохраняются в одной реплике, и лишь спустя какое-то время копируются на остальные серверы реплик. Нужно понимать, что нет гарантии того, что все реплики будут всегда содержать последние изменения. Согласованность и синхронизация данных являются проблемами структуры и основаны на определенных требованиях к производительности.
Существует два вида репликации: с одним хозяином и с несколькими хозяевами. В операции с одним хозяином только один сервер (хозяин) может принимать изменения в каталоге, все остальные реплики имеют доступ только для чтения. В случае отказа сервера-хозяина, в каталог нельзя внести изменения до тех пор, пока хозяин не будет восстановлен или другая реплика не будет повышена до роли хозяина (при условии, что решение каталога поддерживает такое повышение).
Репликация с несколькими хозяевами представляет собой гораздо более надежное, гибкое и простое в восстановлении решение, поскольку любая реплика в наборе может принимать и обрабатывать изменения в каталоге. В среде с несколькими хозяевами в случае отказа хозяина, его просто отключают для восстановления, после чего снова подключают в качестве реплики.
Сочетание традиционных технологий резервного копирования и технологий репликации для защиты данных
Хотя репликация представляет собой наиболее эффективную форму защиты данных в реальном времени, традиционное резервное копирование является наилучшим способом полного восстановления, например, в случае аварии на предприятии, которое также позволяет восстанавливать поврежденные или неправильные данные в каталоге.
Наилучший подход состоит в сочетании этих двух методов для обеспечения наиболее широкого и гибкого подхода к защите данных. Использование репликации для синхронизации и обновления в масштабах сети, балансировки нагрузки и отказоустойчивости является передовым методом в технологиях распределенного каталога. Однако периодическое выполнение централизованного резервного копирования всего каталога и конфигурационной информации на традиционные носители обеспечивает дополнительный уровень защиты. Хранение копий этих носителей за пределами предприятия гарантирует, что, вне зависимости от вида аварии, можно будет восстановить полную работоспособность системы. Некоторые компании сами предоставляют услуги хранения за пределами предприятия, чередования, сбора и доставки пленок. Другие предпочитают задействовать сторонних поставщиков таких услуг за определенную плату. Независимо от того, что выберите Вы, просто сделайте это!
Анализ плана резервного копирования и восстановления каталога
Первый шаг в создании плана защиты данных состоит в оценке текущей и ожидаемой рабочей ситуации. После этого будет легко ответить на следующие вопросы, призванные помочь оценить потребности в защите данных.
• Каковы возможные сценарии отказа? Исходя из аспектов существующей среды, архитектуры и инфраструктуры, модели администрирования, структуры, предыдущих отказов и простоев, а также уязвимости по отношению к аварийным ситуациям, описанным выше в этом разделе, где существует наибольший риск потери или повреждения данных?
• Что собой представляют и где находятся критически важные данные? Определены ли критически важнее данные (данные каталога и конфигурационные файлы)? Известно ли точное расположение каждого сервера реплики и всех конфигурационных файлов в сети?
• Как часто следует проводить резервное копирование? Как было сказано ранее, решения по резервному копированию различаются в зависимости от используемого решения каталога. Чаще всего поставщики программ резервного копирования предлагают рекомендации по резервному копированию своих каталогов (данных, приложений и конфигурационных файлы). Однако следует внимательно изучить эти вопросы и определить расписание выполнения резервного копирования, исходя из требований производительности, надежности, доступности и уменьшения возможных последствий.
• Следует ли использовать сочетание традиционных методов и технологий репликации? Следует ли использовать описанное выше сочетание традиционной формы резервного копирования (на пленку) с репликацией для защиты данных? Каким образом будет осуществляться хранение традиционных носителей с резервными копиями за пределами предприятия?
• Как проверяются резервные копии? Резервные копии абсолютно бесполезны, если в случае необходимости невозможно будет выполнить восстановление с них; необходимо периодически проверять данные восстановления и процесс (план действий для выполнения восстановления), чтобы гарантировать целостность резервных копий, носителей и особенно готовность и реагирование персонала с точки зрения плана восстановления.
• Сколько времени потребуется для полного восстановления в случае серьезной аварии? Учитывается ли время восстановления в соглашениях об уровне сервиса с потребителями? Сообщается ли клиентам ожидаемое время восстановления (при наихудшем сценарии)?
Устранение неполадок в архитектуре каталога
Время от времени в каталоге могут возникать сбои. В зависимости от типа и сложности проблемы, она может вызвать что угодно, от незначительного ухудшения работы до полного отказа сервиса каталога. Когда что-то идет не так, основная задача заключается в том, чтобы свести к минимуму повреждения, как можно быстрее восстановить полную работоспособность каталога, и установить причину, чтобы предпринять меры для предотвращения повторного появления проблем.
Проблемы с каталогом можно разделить на 3 категории:
• Проблемы в результате отказов оборудования или ПО
• Проблемы производительности
• Проблемы с данными каталога
В этом разделе рассматривается каждая из этих трех категорий с целью повышения уровня компетентности и возможностей активного реагирования на проблемы посредством устранения неполадок.
Обнаружение проблем
Первое что нужно сделать: прежде чем перейти к процессам устранения неполадок, важно понять, как обнаружить проблемы в каталоге. Ниже перечислено несколько основных способов обнаружения проблем в сервисе каталога:
• Система мониторинга (если она есть) может автоматически обнаружить отказ или снижение производительности каталога или сервиса поддержки и направить уведомление.
• Служба поддержки или операций может заметить проблему с каталогом при выполнении стандартных функций обслуживания каталога.
• Администраторы зависимых сервисов (например, системы сообщений, отдела кадров и баз данных) могут заметить и сообщить о проблемах с каталогом или сервисами поддержки.
• Конечные пользователи могут заметить проблему и сообщить о ней в сервисную службу. При отказе сначала может поступить сообщение о проблеме с зависимым сервисом (например, с системой сообщений), однако в действительности сбой может иметь место в каталоге.
Неисправность может быть обнаружена одной, несколькими или всеми вышеназванными источниками одновременно. Например, если сервер каталога становится недоступным, система управления сетью или мониторинга может сообщить о проблеме в то же время, когда конечные пользователи будут звонить в сервисную службу. Как уже было сказано выше, конечные пользователи могут сообщать о проблемах с доступом к зависимым сервисам.
Группа операций может сообщить о проблемах при выполнении плановой процедуры обслуживания или обновления данных. В любом случае, процесс обнаружения проблемы должен также осуществлять корреляцию событий, чтобы понять основную проблему, влияющую на зависимые процессы.
В идеале, нужно стремиться уменьшить вероятность того, что конечный пользователь обнаружит и сообщит о проблеме первым. Это достигается реализацией хорошо продуманного плана мониторинга и уведомления. Это требует тщательного планирования, но дает отличные результаты.
При возникновении проблемы необходимо должным образом связаться с конечными пользователями, сервисной службой, группой операций, системными администраторами и руководством, ответственными за соглашения об уровне сервиса для поврежденных систем. Сообщения могут:
• Указывать наличие проблемы.
• Указывать предполагаемое время исправления и восстановления сервиса.
• Указывать альтернативные действия и источники обслуживания, которые можно использовать, пока не будут восстановлены основные сервисы.
Необходимо заранее распланировать, как оповещать все затронутые и заинтересованные стороны в случае неисправности или сбоя. К числу наиболее распространенных способов относятся публикация информации об отказе на веб-сайтах, отправка общих или ориентированных на группу/приложение сообщений по электронной почте, размещение информации об отказе в тематических конференциях Usenet, а также предоставлении информации о состоянии посредством голосовой почты по телефону.
Типы проблем
Как уже было сказано выше, существует три основных категории проблем каталога. В следующем разделе мы рассмотрим эти типы проблем более подробно, предоставив некоторую информацию об основных причинах и решениях, что поможет в решении этих проблем, если они возникнут.
Отказ каталога
Первый тип проблемы – отказ каталога. Это случается, когда сервисы каталога полностью или частично становятся недоступными. Такое может произойти, если один или несколько серверов каталога становятся недоступными в результате проблем с сетью или из-за неисправности аппаратного или программного обеспечения сервера. При отказе каталога пользователи не получают какое-либо обслуживание.
Причины отказов каталога
Причины отказов каталога можно разделить на две основные категории: отказы оборудования и отказы ПО. Что касается оборудования, отказать могут сетевые компоненты, такие как маршрутизаторы, коммутаторы, сетевые карты и кабели, а также компоненты сервера: процессоры, память, дисковые системы и источники питания. Отказ также может произойти в результате отсутствия электропитания.
К отказам ПО относятся ошибки операционной системы или программ, приложений и сервисов, осуществляющих поддержку каталога. Также возможен отказ других программ, также выполняющихся на сервере каталога, вызвавший отказ сервиса каталога.
Последствия отказов каталога
При отказе каталога пользователи и приложения на основе каталога не получают никакого доступа к сервису каталога. Поскольку LDAP является клиент-серверным протоколом, отказ будет обнаружен как ошибка подключения к сервису каталога. Существует три основных симптома отказа каталога: превышение лимита времени подключения, отказ в подключении и зависание подключения.
Разрешение проблем отказа каталога
Если причиной отказа каталога является неисправность оборудования, обычно достаточно заменить и перезапустить отказавшую систему. Например, еслиотказ произошел по причине неисправности источника питания, нужно заменить отказавший модуль и перезапустить сервер/сервис.
Отказы не всегда просто исправлять. Предположим, что отказ вызвал не только прерывание работы сервиса каталога, но и привел к повреждению данных при выходе системы из строя. Тогда нужно совсем другое решение проблемы, чем простая замена неисправного компонента и перезапуск устройства. В этом случае нужно планировать нечто большее, чем простая замена оборудования. Нужно также рассмотреть целостность данных, доступность, надежность и отказоустойчивость в контексте плана аварийного восстановления. Все эти вопросы связаны с соглашениями по уровню сервиса: рассмотрите толерантность группы к простою, после чего проектируйте избыточность оборудования и механизмы перемещения при сбое, а также размещение запасных деталей на месте. Помимо отказа оборудования, следует также согласовать действия при отказе такого типа с ответственными за план аварийного восстановления.
Проблемы производительности
Другая распространенная проблема имеет место при низкой производительности каталога. Низкая производительность может проявляться несколькими способами: низкой может быть общая производительность каталога или же быстродействие определенного типа операций каталога, например, обновления номера телефона. Проблемы производительности могут быть постоянными или периодическими. Устранение неисправностей такого типа требует тщательного анализа и специального внимания к деталям.
Причины проблем производительности
Наиболее распространенной причиной низкой производительности сервисов каталога является неправильная конфигурация программного обеспечения. Неправильно сконфигурированный сервер каталога может работать неэффективно или же вообще не работать. Например, большинство программ серверов каталога используют кэш оперативной памяти для временного хранения часто используемых команд и данных. При недостаточном размере кэша сервер может реагировать медленно или не реагировать совсем (зависать).
С другой стороны, при слишком большом кэше могут иметь место излишние операции подкачки, оказывающие негативное влияние на систему виртуальной памяти сервера. В этом случае нужно выполнить соответствующий анализ системы и настроить все параметры, влияющие на производительность, чтобы достичь оптимальной работы системы. Производитель продукта каталога может предоставить инструкции по настройке, что которые помогут повысить производительность. Кроме того, следует выполнить дополнительную настройку для достижения соответствия требованиям развертывания (в частности, по использованию решения).
Другая распространенная проблема возникает при отсутствии соответствующего индексирования для операций поиска в каталоге, выполняемых сервером. Большинство продуктов каталога поддерживают поиск по любому атрибуту. Однако скорость поиска для неиндексированных атрибутов будет низкой, поскольку серверу в этом случае потребуется просмотреть каждую запись в базе данных для обнаружения соответствующих элементов. Если сервер тратит много времени на выполнение простых запросов, проверьте, не использует ли клиент неиндексированные атрибуты в фильтрах поиска.
И, наконец, могут иметь место ошибки в программном обеспечении сервера каталогов или операционной системе, вызывающие снижение производительности. Производители программного обеспечения все больше используют Интернет для информирования потребителей о пакетах обновлений и исправлениях, а также для публикации баз знаний с полной и полезной информацией о своих продуктах. Кроме того, конференции Usenet являются замечательным ресурсом информации об известных ошибках, проблемах, альтернативных действиях и исправлениях. Необходимо знать обо всех ресурсах информации и исправлений от производителя и в Интернете, относящихся к данному продукту.
Последствия проблем производительности
Последствия проблем производительности варьироваться от незначительного ухудшения работы сервиса до полного отказа системы. Эти симптомы могут оказать неблагоприятное воздействие на всех пользователей в равной мере или только на небольшое количество пользователей. Например, неправильная настройка кэша может вызвать низкую производительность для всех пользователей и приложений каталога, тогда как отсутствие индекса атрибута может вызвать низкую производительность только для пользователей, часто выполняющих запросы по этому атрибуту.
Разрешение проблем производительности
При исправлении проблем производительности важно делать это последовательно и обдуманно. Ведите подробные записи с точным описанием возникшей проблемы, после чего попробуйте воссоздать проблему. Если проблему нельзя воспроизвести, рассмотрите различия между средами. Подключены ли среды к одному и тому же серверу? Проходят ли они аутентификацию или подключаются анонимно? Расположены ли они близко к серверу сети? Попытайтесь поочередно устранить все различия до тех пор, пока не получится точно воссоздать проблему пользователя.
Исправление проблемы может быть несложным делом, если нужно просто внести небольшие изменения в конфигурацию, или же сложным процессом, если обнаружена ошибка в программе, требующая обновления одного из приложений поддержки каталога.
Если исправление невозможно, существуют ли краткосрочные альтернативные варианты? Можно ли смягчить воздействие проблемы, изменив некоторым образом конфигурацию каталога?
Независимо от используемого способа устранения проблемы, найдите время для документирования проблемы, причины, любых краткосрочных исправлений или альтернативных действий, и долгосрочного решения. Проблемы с ПО могут быть достаточно сложными; и чем больше будет возможностей обмена сведениями об устранении неисправностей между операторами, тем группа будет более эффективной в предоставлении высококачественные решения пользователям.
Проблемы с данными каталога
Проблемы с данными каталога могут возникнуть из-за недостаточности, избытка или неточности информации. В худшем случае, файлы базы данных сервера каталога могут быть повреждены из-за ошибок ПО, дефектов или ошибок операционной системы. В целом, эти проблемы представляют наиболее распространенную категорию проблем с данными каталога.
Проблемы с данными часто являются следствием других проблем, таких как неправильная конфигурация ПО. В других случаях, проблемы с данными могут быть результатом неправильных действий администраторов каталога (либо администраторов корневого уровня, либо администраторов определенных приложений каталога). Сами по себе проблемы с данными могут привести к другим проблемам. Например, если ошибочно изменить атрибуты управления доступом, пользователи, возможно, не смогут получить доступ к данным, которые они имеют право просматривать, или могут получить неверную информацию или информацию, которую они не имеют права просматривать.
Причины проблем с данными каталога
Появление в каталоге неверных данных означает что кто-то (или что-то) ввел их туда. Например, данные о работающем сотруднике могут быть ошибочно удалены вместо данных уволившегося сотрудника. В более широком масштабе, процесс автоматического обновления, осуществляющий согласование с записями в базе данных отдела кадров, может, в результате ошибки, переписать неверную информацию о сотруднике в каталог.
Обычные инструменты мониторинга не обнаруживают проблемы такого типа, если только данные не повреждены настолько, что происходит фатальный сбой на сервере или сервер перестает запускаться. Обычно о таких проблемах узнают от конечных пользователей, если только не осуществляется активный мониторинг качества данных, что сделать довольно трудно.
В целях профилактики рассмотрите вариант разработки инструментов мониторинга качества данных в каталоге или встраивания инструментов проверки в средства синхронизации каталога с внешними источниками данных. Такие инструменты могут выявлять проблемы до того, как они будут обнаружены и сообщены конечными пользователями или создадут более серьезные проблемы в виде полного отказа каталога.
Последствия проблем с данными каталога
При попадании неправильных данных в каталог, приложения могут начать работать нестабильно или некорректно. Например, при ошибочном удалении записи, соответствующей действительному пользователю, электронные сообщения пользователя могут возвращаться отправителю, потому что пользователь не будет распознаваться агентом поиска и перенаправления в сервисах каталогов.
В целом, если работа каталога выглядит корректной, но пользователи жалуются на неправильную и нестабильную работу, нужно начать проверку содержимого соответствующих записей каталога.
Даже более неуловимые ошибки могут возникнуть, если каталог содержит информацию о сетевых ресурсах, например, файловых серверах или принтерах. При удалении или повреждении записей каталога, соответствующих этим устройствам, сервисы, обеспечиваемые данными устройствами, будут недоступны.
Кроме того, при повреждении файлов базы данных симптомы могут как малозаметными, так и очень явными. Могут пропасть все записи каталога (очевидный симптом), или же некоторые записи или атрибуты могут не выдаваться при выполнении определенных типов запросов. Надежное серверное ПО может предотвратить большинство таких проблем, но ошибки оператора могут привести к несогласованности данных, внося хаос при попытке использования каталога для обычных операций.
Если повреждение малозаметно, оно может какое-то время оставаться незамеченным. Имея дело с поврежденными данными, всегда будьте готовы к тому, что повреждение случилось давно, и только сейчас было замечено.
Разрешение проблем с данными каталога
Если было определено, что имеет место проблема с данными каталога, первое, что нужно сделать – определить масштаб повреждения. Для этого иметь представление о том, что на самом деле должно быть в каталоге. Для начала можно просмотреть содержимое каталога. Является ли правильным количество записей в каталоге? Если записей слишком мало, это свидетельствует о том, что удаляются, и может иметь смысл закрыть некоторые или все автоматизированные или зависимые сервисы или приложения. Например, если отсутствуют записи для всего отдела или группы, возможно, будет разумно закрыть сервисы электронной почты для этой группы, чтобы их почта не возвращалась отправителям, когда сервис не сможет найти нужные записи каталога.
Если есть сомнение, самое безопасное – закрыть пострадавшие серверы. Приложения каталога (хорошо разработанные) обычно замечают, что каталог недоступен, выдают соответствующее сообщение об ошибке, после чего пытаются выполнить эту же операцию позже. Если проблемный сервер не закрыт и при этом недоступен или содержит неверные данные, приложение, осуществляющее доступ или использующее каталог, может также отказать по причине использования неправильных данных.
Как только будет известен масштаб повреждений, нужно приступить к восстановлению. Выбор способа восстановления зависит от масштаба повреждения, наличия информации о причине, а также объема и точности информации, связанной с содержимым каталога. Например, если отсутствует только одна запись пользователя, возможно, лучше всего просто заново создать пользователя и восстановить атрибуты безопасности и приложений. Если был удален весь каталог из-за ошибочного процесса или слишком уставшего оператора, лучше всего сразу же перейти в режим аварийного восстановления и начать восстановление каталога в соответствии с планом восстановления.
После восстановления каталога нужно проанализировать, что случилось, выполнив анализ основной причины в соответствии со следующим списком:
• Как были повреждены данные — была ли это ошибка автоматического процесса или ошибка оператора?
• Была ли проблема вызвана слиянием, объединением или синхронизацией данных?
• Содержат ли файлы журналов какую-либо информацию, указывающую на проблему?
• Существует ли записи в журнале аудита безопасности, которые могли бы указать причину проблемы?
Какой бы ни была причина и насколько сложным и трудоемким ни было восстановление, необходимо полностью разобраться в том, что произошло, и предпринять соответствующие меры для предотвращения повторения проблемы в будущем.
Блок-схема устранения неполадок
На следующей блок-схеме представлены шаги, необходимые для выполнения соответствующего коррективного управления в форме устранения неполадок.

Рисунок 21. Блок-схема устранения неполадок
Контрольный список устранения неполадок
Используйте следующий контрольный список всякий раз, когда возникает проблема в каталоге. Он включает три типа проблем, рассмотренных выше, и несколько вопросы, связанных с безопасностью. Вопросы безопасности в данном документе не рассматриваются. Дополнительные сведения см. в руководстве MOF Security Administration Service Management Function.
Отказы каталога
• Имеет ли место истечение периода ожидания подключения для клиентов, или же сервер отклоняет их подключение?
• Все ли компоненты сети (маршрутизаторы, концентраторы, коммутаторы, кабели) между клиентом и сервером работают исправно?
• Работает ли компьютер сервера каталога? Если нет, можно ли определить источник проблемы – оборудование или программное обеспечение?
• Работают ли все аппаратные компоненты сервера каталога? Если нет, существуют ли журналы операционной системы или сервера, указывающие на неисправность оборудования?
• Работает ли процесс сервера каталога? Если да, не имеет ли место более высокий показатель использования процессора этим процессом чрезмерная активность дисковой системы?
• Если сервер каталога не работает, произошел ли сбой при обработке определенного типа клиентского запроса? Происходит ли этот сбой каждый раз при получении/обработке такого запроса? Такой запрос может представлять собой атаку типа «отказ в обслуживании».
Проблемы производительности
• Относится ли низкая производительность только к определенным типам операций каталога или к серверу в целом?
• Поддерживает ли сервер каталога индексирование соответствующих атрибутов?
• Не является ли использование ресурсов процессом сервера каталога слишком интенсивным? Становится ли оно интенсивным сразу после запуска или же возрастает постепенно?
• Настроены ли размеры кэша каталога (если он есть) соответствующим образом (чтобы он не был ни слишком большим, ни слишком маленьким)?
• Не вызваны ли проблемы производительности другими процессами, выполняющимися на сервере каталога?
• Не перегружен ли каталог? Является ли нагрузка на каталог запланированной? Если нагрузка является чрезмерной, связана ли она с определенным клиентским процессом или процессом запроса?
Проблемы с данными каталога
• Отсутствуют ли данные или данные неправильны?
• Выглядят ли данные серьезно поврежденными? Такое повреждение указывает на серьезную проблему с оборудованием или ПО.
• Повреждены ли данные определенным образом? Например, не были ли ошибочно удалены некоторые записи? Можно ли определить источник ошибочной модификации путем изучения журналы сервера или каталога?
Проблемы безопасности
• Есть ли следы вторжения, например, подключения от неожиданного или неавторизованного компьютера или клиента? Есть ли неожиданные модификации записей каталога?
• Указывают ли журналы сервера на неожиданную активность или доступ?
• Не подвергается ли каталог атаке типа «отказ в обслуживании»? Такая атака переполняет имеющиеся ресурсы каталога или сервера. Известен ли источник атаки?
5
Роли и обязанности
Основные роли и связанные с ними обязанности администрирования сервисов каталогов были определены в соответствии с отраслевыми рекомендациями. Организациям может потребоваться совмещать некоторые роли, в зависимости от размера компании, организационной структуры и базовых соглашений об уровне сервиса между ИТ-отделом и предприятием, которое он обслуживает.
Ниже описаны роли и обязанности, связанные с сервисом каталога.
Администратор каталога
Администратор каталога является владельцем процесса с полной ответственностью за процесс администрирования каталога. Администратор каталога входит в кластер ролей эксплуатации, определенный в командной модели MOF.
В зависимости от структуры процесса и/или мер по реорганизации, менеджер сервисов каталога несет полную ответственность за процесс, так как он является владельцем процесса, обеспечивающим как руководство, так и учет этого процесса, а также все действия, выполняемые при выполнении процесса администрирования каталога.
Таким образом, администратор каталога отвечает за все меры по изменению процесса, оказывающие влияние на администрирование каталога и его работу. Администратор каталога также должен иметь возможность уделять достаточно времени работе над усовершенствованию процесса, а также поддержанию хороших связей с топ-менеджерами различных подразделений компаний и сторонами, заинтересованными в успехе предприятия.
Администратор каталога:
• Определяет все стратегии администрирования, интеграции и эксплуатации.
• Обеспечивает соответствие интеграции и зависимостей для всех приложений.
• Обеспечивает точность и актуальность документации каталога предприятия.
• Обеспечивает точное представление ресурсов каталога в CMDB.
• Создает новые объекты каталога.
• Управляет схемами базы данных каталога.
• Осуществляет мониторинг репликации данных для обеспечения своевременной репликации.
• Копирует данные на магнитную ленту и другие носители данных.
• Осуществляет мониторинг ресурсов, доступности и производительности каталога.
Разработчик каталога
Разработчик каталога отвечает за создание структуры, позволяющей каталогу предоставлять корректную информацию там, где она нужна. Хорошая структура предоставляет пользователям информацию с минимальным использованием ресурсов (пропускной способности сети, ресурсов процессора и памяти, а также времени оператора).
Разработчик каталога:
• Разрабатывает инфраструктуру каталога таким образом, чтобы она соответствовала требованиям уровня сервиса.
• Создает схему базы данных каталога.
• Создает перечень изменений, необходимых для существующей схемы базы данных, в целях соответствия новым требованиями предприятия.
• Разрабатывает требования для сетевой инфраструктуры для обеспечения репликации данных.
6
Связь с другими SMF
По мере увеличения роли каталога в работе вычислительной среды, важно понимать, каким образом поддержка каталога влияет на другие операционные процессы. Представленный ниже график изображает связь между администрированием сервисов каталогов и другими MOF SMF в квадранте эксплуатации.

Рисунок 22. связь с другими SMF в оперативном квадранте
Администрирование систем
Администрирование систем связано с моделью администрирования, используемой в организации. Некоторые организации предпочитают модель, в которой все ИТ-функции выполняются с одного узла командной специалистов, работающих на этом узле. Другие организации предпочитают распределенную модель филиалов, где как технологии, так и обслуживающий персонал географически рассредоточены. Администрирование систем изучает преимущества и недостатки каждой модели. Каждая модель администрирования систем имеет уникальные требования к каталогу. Например, учетные записи пользователей, хранящиеся в каталоге, возможно, должны располагаться близко к пользователям, чтобы свести к минимуму время входа регистрации. Модель распределенного управления может также потребовать делегирования доступа к объектам в каталоге.
Администрирование безопасности
Администрирование безопасности включает информацию, необходимую для планирования, выбора, реализации, управления и обзора средств безопасности. Оно также включает процессы и процедуры, необходимые для реагирование на события безопасности. Это особенно важно для работы каталога, поскольку в настоящее время каталог предоставляет множество функций безопасности.
Мониторинг и контроль сервиса
Мониторинг и контроль сервиса подразумевает мониторинг различных аспектов производительности системы, обеспечивая соответствие соглашениям об уровне сервиса. Администраторы, отвечающие работу систем мониторинга, должны следить за тем, чтобы каталог не стал слишком большим, и что он не использует пропускную способность сети чрезмерно.
Администрирование сети
Администрирование сети связано с обслуживанием физических компонентов, составляющих сеть организации, таких как серверы, маршрутизаторы, коммутаторы, брандмауэры, и т.д. Репликация каталога может потребовать значительную часть пропускной способности сети. Пропускная способность сети оказывает влияние на структуру каталога.
Управление конфигурациями
Управление конфигурациями связано с отслеживанием версий используемого внутреннего ПО. Для администраторов важно иметь четкое представление о том, какие версии операционной системы, системы управления базами данных и приложений, работают на компьютерах сети. С точки зрения сервисов каталогов, управление конфигурациями контролирует то, какая версия каталога выполняется, какие версии приложений каталога используются, и какие версии программ поддержки, собственных программ и инструментов сторонних производительности выполняются.
Управление доступностью
Управление доступностью связано с общей доступностью системы относительно времени простоя. Поскольку работа большинства организаций в настоящее время невозможна при отказе системы, чрезвычайно важно, чтобы администратор выполнял надлежащую настройку и мониторинг системы, чтобы максимально увеличить время работы системы и среднее время между авариями. Управление доступностью напрямую связано с соглашениями об уровне сервиса и обеспечивает соответствие обещанным уровням надежности и доступности каталога для руководства и конечных пользователей.
Управление мощностью
Управление мощностью является критически важной функцией для текущей и дальнейшей эксплуатации каталога. Управление мощностью связано с планированием дополнительных ресурсов по мере роста использования текущих системных ресурсов и приближения к точке полного использования ресурсов. Критически важно, чтобы производительность (время отклика) и масштабирование каталога отвечали потребностям как существующих, так и будущих пользователей.
Управление непрерывностью ИТ-сервиса
Планирование непрерывности тесно связано с перемещением при сбое и восстановлением. Перемещение при сбое и восстановление связаны с автоматическим переходом на другой сервер при временном отказе главного сервера и возвращением на главный сервер, когда он снова будет доступен, что особенно важно по мере увеличения роли каталога в работе вычислительной среды. В контрасте с этим, управление непрерывностью ИТ-сервиса имеет дело с авариями в более крупном масштабе. Планирование непрерывности ИТ-сервиса занимается тем, что случается при отказе всего информационного центра в связи с прекращением подачи электроэнергии, наводнениями, пожарами, террористическими актами и т.д. При необходимости внедрения плана непрерывности восстановление каталога является одной из основных задач.