Модель сетевого управления ISO OSI

 

Модель сетевого управления ISO OSI Management Framework — определена в документе ISO/IEC 7498-4: Basic Reference Model, Part 4, Management Framework. Она является развитием общей семиуровневой модели взаимодействия открытых систем для случая, когда одна система управляет другой.

Документ ISO/IEC 7498-4 состоит из пяти основных разделов.

• Термины и общие концепции.

• Модель управления системами.

• Информационная модель.

• Функциональные области управления системами.

• Структура стандартов управления системами.

Стандарты ISO в области управления используют специальную терминологию, которой в свою очередь воспользовались создатели Internet в протоколе SNMP (Simple Network Management Protocol — простой протокол управления сетью). Эта терминология вследствие фактического применения всеми пользователями такой глобальной и открытой системы передачи информации стала фактическим стандартом [8, 9].

Согласно документам OSI обмен управляющей информацией с помощью протокола управления (Management Protocol) происходит между субъектами приложений управления системами (Systems Management Application Entities, SMAE). Субъекты SMAE расположены на прикладном уровне семиуровневой модели OSI и являются элементами службы управления. Под субъектом в модели OSI понимается активный в данный момент процесс (протокол) какого-либо уровня, участвующий во взаимодействии. Примерами SMAE являются агенты и менеджеры систем управления ИС.

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

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

В модели OSI границы между менеджерами и агентами не очень четкие. Субъект SMAE, выполняющий в одном взаимодействии роль менеджера, в другом взаимодействии может иметь роль агента, и наоборот. Модель OSI не определяет способы взаимодействия агента с управляемыми объектами. В модели OSI также не говорится о том, как агент взаимодействует с управляемыми объектами, которые находятся за пределами управляемой системы, т. е. объектами, с которыми нужно взаимодействовать через сеть. В таких случаях может потребоваться, например, чтобы один агент запросил данные о некотором объекте от другого агента. Порядок такого рода взаимодействия также не определяется моделью OSI.

Чтобы менеджер и агент смогли взаимодействовать, каждый должен иметь определенные знания о другом. Эти знания модель OSI называет контекстом приложения (Application Context). Контекст приложения описывает элементы прикладного уровня модели OSI, которые используются агентами и менеджерами.

Прикладной уровень модели OSI включает в себя несколько вспомогательных служб общего назначения, которые используются прикладными протоколами и пользовательскими приложениями (в том числе и приложениями управления) для автоматизации наиболее часто выполняемых действий. Эти вспомогательные службы не представляют собой законченные протоколы прикладного уровня модели OSI, как протоколы. FTAM (File Transfer, Access and Management — протокол для доступа к файлам), CMIP (Common Management Information Protocol, протокол общей управляющей информации), MHS (Message Handling System — система управления сообщениями). С помощью перечисленных протоколов пользователь сети может выполнить какое-то полезное действие. Вспомогательные же системные функции помогают разработчику прикладного протокола или приложения написать его программу компактно и эффективно. На прикладном уровне модели OSI существуют следующие вспомогательные службы.

ACSE (Association Control Service Element). Эта служба отвечает за установление соединений между приложениями различных систем. Соединение (сессия, сеанс) на прикладном уровне OSI носит название ассоциации. Ассоциации бывают индивидуальными и групповыми (shared).

RTSE (Reliable Transfer Service Element). Служба осуществляет поддержку восстановления'диалога, вызванного разрывом нижележащих коммуникационных служб, в рамках ассоциации.

ROSE (Remote Operations Service Element). Организует выполнение программных функций на удаленных машинах. Является аналогом службы RPC (Remote Procedure Call — вызов удаленных процедур).

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

Основная модель управления OSI включает:

• управление системами;

• управление N-уровнем;

• операции N-уровня.

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

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

Управление N-уровнем ограничено управляемыми объектами какого-то определенного уровня семиуровневой модели. Протокол управления использует при этом коммуникационные протоколы нижележащих уровней. Управление N-уровнем полезно, когда нет возможности использовать все семь уровней OSI. В этом случае допускается пользоваться протоколом управления N-уровня, который строго предназначен для данного уровня.

Операции N-уровня сводятся к мониторингу и управлению на основе управляющей информации, содержащейся в коммуникационных протоколах только данного уровня. Например, данные мониторинга сети, содержащиеся во фреймах STM-n (Synchronous Transport Module — синхронный транспортный модуль), технологии SDH (Synchronous Digital Hierarchy — синхронная цифровая иерархия), относятся к операциям N-уровня, а именно физического уровня. Стандарты на управление N-уровнем и операции N-уровня не входят в набор протоколов управления OSI. Протоколы OS1 рассматривают управление системами с помощью полного семиуровневого стека.

Управляемый объект — это представление OS1 о ресурсе в целях управления. Конкретный управляемый объект — это экземпляр (instance) некоторого класса управляемых объектов. Модель управления OSI широко использует объектно- ориентированный подход. Класс управляемых объектов — это набор свойств, которые могут быть обязательными или условными. С помощью описания одного класса управляемых объектов, например коммутаторов, можно создать другой класс управляемых объектов, например коммутаторов, поддерживающих технологию VLAN (Virtual Local Area Network — виртуальная локальная сеть), унаследовав все свойства класса коммутаторов, но добавив новые атрибуты.

Для управления ресурсами менеджер и агент должны быть осведомлены о деталях этих ресурсов. Детализация представления управляемых объектов, которые требуются для выполнения функций управления, хранится в базе данных, известной как MIB (Management Information Base — база данных информации управления). Базы данных MIB OSI хранят не только описания классов управляемых объектов, но и характеристики сети и ее элементов. Базы MIB содержат характеристики каждой части управляемого оборудования и ресурсов. MIB также включает в себя описание действий, которые могут выполняться на основе собранных данных или же вызываться внешними командами. Базы MIB позволяют внешним системам опрашивать, изменять, создавать и удалять управляемые объекты (реальные ресурсы сети при этом, естественно, продолжают работать). Протокол CMIP и локальные интерфейсы управления обеспечивают доступ к этим возможностям.

Протоколы OSI определяют синтаксис информации, хранящейся в MIB, и синтаксис интерфейсов для обмена данными.

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

Такие данные называются в модели OSI разделяемыми управляющими знаниями (shared management knowledge) между менеджером и агентом. (В системах на основе протокола SNMP организация этих данных не стандартизована, и в каждой конкретной системе управления эти данные хранятся в индивидуальной форме.) Разделяемые управляющие знания должны быть известны до установления ассоциации между

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

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

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

Три типа управляющих знаний и, соответственно, три типа объектов описывают эти знания.

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

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

Знания об экземплярах (Instance Knowledge) обеспечивают информацию о конкретных экземплярах управляемых объектов, имеющихся в управляемой системе.

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

Дерево наследования (Inheritance Tree) называется также деревом регистрации. Описывает отношения между базовыми и производными классами. Подчиненный класс наследует все характеристики суперкласса и дополняет их специфическими расширениями (дополнительными атрибутами, поведениями и действиями). Классы объектов OSI регистрируются в том же дереве, что и объекты MIB Internet. Дерево наследования может быть глобальным, т. е. начинаться с корня, представляющего весь мир, или локальным, имеющим корень, соответствующий верхнему уровню объектов данной организации или сети. Все управляемые объекты OSI должны быть зарегистрированы в глобальном дереве ISO (в котором зарегистрированы объекты MIB-I, MIB-II, RMON-Remote MONitoring — удаленное наблюдение). Объекты, представляющие собой международные стандарты, регистрируются в международной ветви дерева, а частные модели, разработанные производителями систем управления, регистрируются в ветвях дерева, начинающихся с ветви «private».

Дерево включений (Containment Tree) описывает отношения включения управляемых объектов реальной системы.

Дерево имен (Naming Tree) определяет способ именования объектов в системе управления. Объекты OSI могут иметь имена нескольких типов: относительное отличительное имя (Relative Distinguished Name, RDN), отличительное имя (Distinguished Name, DN), иногда называемое полным отличительным именем (Full Distinguished Name, FDN), и локальное отличительное имя (Local Distinguished Name, LDN). Эти имена связаны с деревом включений, так как определяют имена объектов относительно включающих их объектов. Относительное имя RDN соответствует короткому имени, которое однозначно определяет объект среди множества других объектов, подчиненных тому же родительскому объекту. Например, имя interface а является RDN-именем, уникально характеризующим объект среди объектов, подчиненных объекту node а. Полное отличительное имя FDN представляет собой последовательность RDN-имен, начинающуюся в вершине глобального дерева имен, т. е. дерева, описывающего некоторую глобальную сеть. Наконец, локальное отличительное имя — это последовательность RDN-имен, но начинающаяся не в глобальном корне, а в корне дерева имен локальной системы управления, отвечающей за часть глобального дерева имен данной сети.

Дерево имен обычно совмещается с деревом включений.

Пример дерева включений показан на рис. 2.2. Экземпляр управляемого объекта класса corp-conc (корпоративный концентратор) имеет имя В1, а также атрибут max-slotes, описывающий максимальное количество слотов данного класса концентраторов, равный в данном случае 14.

Рис. 2.2. Пример дерева включений

 

В этот объект включен ряд других объектов: объекты класса repeator, switch и RAS, которые в свою очередь включают объекты типа interface, описывающие порты модулей концентратора.

Имя класса объекта позволяет обратиться к описанию класса и узнать полный список атрибутов этого класса или ссылку на родительский класс, у которого наследуются все или некоторые атрибуты. Имя экземпляра объекта дает информацию о принадлежности конкретного модуля или интерфейса определенному коммуникационному устройству, например имя В1.Е1.Р2 определяет второй порт модуля репитера Е1, входящего в состав корпоративного концентратора В1.

Классы управляемых объектов OSI должны определяться в соответствии со стандартом GDMO (Guidelines for the Definition of Managed Objects — правила определения управляемых объектов), являющимся стандартом ISO 10165—4.

В GDMO определяется несколько шаблонов — пустых форм, которые заполняются для описания определенного класса управляемых объектов. В шаблоне класса перечисляются комплекты свойств (PACKAGES), которые составляют класс. Шаблон комплекта свойств PACKAGE перечисляет Атрибуты,

Группы атрибутов, Действия, Поведение и Уведомления, т. е. свойства, сгруппированные для удобства описания класса объектов. Отношения наследования между классами описываются с помощью шаблона связывания имен.

Атрибуты и Группы атрибутов определяют параметры объекта, которые можно читать и узнавать из них о состоянии объекта.

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

Свойство Поведение описывает реакцию объекта на примененное к нему действие.

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

Заполненные шаблоны GDMO определяют представление класса и его свойств. Заполнение шаблонов выполняется в соответствии с нотацией ASN. 1 (Abstract Syntax Notation One — язык для описания абстрактного синтаксиса данных). В отличие от стандартов SNMP, использующих только подмножество типов данных ASN.1, в GDMO и CMIP применяется полная версия ASN.1.

На основании правил GDMO определено несколько международных стандартов на классы управляемых объектов. Документы Definition of Management Information (DMI, ISO/IEC 10165-2:1991) и Generic Management Information (GMI, ISO/IEC CD 10165-5:1992) являются первыми определениями MIB на основе окончательной версии GDMO. Эти MIB могут рассматриваться как ISO-эквивалент для Internet MIB II, так как они создают основу для построения более специфических MIB. Например, DMI определяет класс объектов, называемый Тор, который является верхним суперклассом. Он содержит атрибуты, которые наследуются всеми другими классами управляемых объектов. Определены также классы объектов System и Network, занимающие верхние позиции в дереве наследования, так что любой агент должен понимать их атрибуты. В 1992 году была завершена работа и над более специфическими классами объектов — объектами сетевого и транспортного уровней (ISO/IEC 10737-1 и ISO/ IEC 10733).

В настоящее время многие организации работают над созданием классов объектов на основе GDMO. Это и международные организации по стандартизации — ISO, ITU-T, ANSI, ETSI, X/Open Company, и организации, разрабатывающие платформы и инструментальные средства для систем управления, такие как SunSoft, Hewlett-Packard, Vertel, ISR Global. Для гелекоммуникационных сетей в рамках архитектуры TMN (Telecommunication Management Network — система управления сетями операторов электросвязи) разработан стандарт М.3100, который описывает ряд специфических для телекоммуникационных сетей классов объектов.

Описания классов управляемых объектов OSI регистрируются как в частных ветвях дерева ISO — ветвях компаний Sun, Hewlett-Packard, IBM и пр., так и в публичных ветвях, контролируемых ISO или другими международными органами стандартизации. Из-за отсутствия одной регистрирующей органи- шции, такой как IETF, использование классов объектов OSI представляет собой достаточно сложную задачу.

Модель управления ISO FCAPS

FCAPS (Fault Configuration Account Performance Security) — модель Международной организации по стандартизации, в которой отражены ключевые функции администрирования и управления сетями (обеспечивающей подсистемы ИС) и не рассматриваются вопросы администрирования функциональной или организационной подсистем. Модель учитывает то, что современные ИС — это системы передачи цифровой информации и предназначены для описания функций администрирования только таких систем. Согласно модели FCAPS все аспекты администрирования сети ИС можно описать при помощи пяти видов функций [26]. Соотношение моделей FCAPS и TMN, которая будет кратко рассмотрена далее, отражено на рис. 2.3.

В рекомендациях ITU-T Х.700 и в стандарте ISO 7498-4 описаны пять функциональных групп модели FCAPS:

(F) Fault Management (управление отказами) — обнаружение отказов в устройствах сети, сопоставление аварийной информации от различных устройств, локализация отказов и инициирование корректирующих действий;

(С) Configuration Management (управление конфигурированием) — возможность отслеживания изменений, конфигурирования, передачи и установки программного обеспечения на всех устройствах сети;

(A) Accounting Management (управление учетом) — возможность сбора и передачи учетной информации для генерации отчетов об использовании сетевых ресурсов;

(Р) Performance Management (управление производительностью) — непрерывный источник информации для мониторинга показателей работы сети (QoS (Quality of Service, Качество обслуживания), ToS (Terms of Service, Тип обслуживания)) и распределения сетевых ресурсов;

(S) Security Management (Управление безопасностью) — возможность управления доступом к сетевым ресурсам и защитой от угроз.

Управление отказами

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

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

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