Стандарты систем управления

7.2.1. Стандартизуемые элементы системы управления

При формализации схемы «менеджер - агент» могут быть стандартизованы следу­ющие аспекты ее функционирования:

• протокол взаимодействия агента и менеджера;

• интерфейс «агент - управляемый ресурс»;

• интерфейс «агент - модель управляемого ресурса»;

• интерфейс «менеджер - модель управляемого ресурса»;

• справочная система о наличии и местоположении агентов и менеджеров, упро­щающая построение распределенной системы управления;

• язык описания моделей управляемых ресурсов, то есть язык описания MIB;

• схема наследования классов моделей объектов (дерево наследования), которая позволяет строить модели новых объектов на основе моделей более общих объек-

7.2. Стандарты систем управления 597

тов, например, модели маршрутизаторов на основе модели обобщенного комму­никационного устройства;

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

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

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

Сегодня на практике применяются два семейства стандартов управления сетя­ми — стандарты Internet, построенные на основе протокола SNMP (Simple Network Management Protocol), и международные стандарты ISO/ITU-T, использующие в качестве протокола взаимодействия агентов и менеджеров протокол CMIP (Common Management Information Protocol).

Стандарты систем управления, основанных на протоколе SNMP, формализуют минимум аспектов системы управления, а стандарты ISO/ITU-T — максимум ас­пектов, как и большинство стандартов, разработанных ITU-T. Традиционно, в ло­кальных и корпоративных сетях применяются в основном системы управления на основе SNMP, а стандарты ISO/ITU-T и протокол CMIP находят применение в телекоммуникационных сетях.

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

Концепции SNMP-управления

В системах управления, построенных на основе протокола SNMP, стандартизуются

следующие элементы:

» протокол взаимодействия агента и менеджера;

• язык описания моделей MIB и сообщений SNMP — язык абстрактной синтакси­ческой нотации ASN.1 (стандарт ISO 8824:1987, рекомендации ITU-T X.208);

• несколько конкретных моделей MIB (MIB-I, MIB-II, RMON, RMON 2), имена объектов которых регистрируются в дереве стандартов ISO.

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

Протокол SNMP и тесно связанная с ним концепция SNMP MIB были разрабо­таны для управления маршрутизаторами Internet как временное решение. Но, как это часто бывает со всем временным, простота и эффективность решения обеспе­чили успех этого протокола, и сегодня он используется при управлении практи­чески любыми видами оборудования и программного обеспечения вычислительных сетей. И хотя в области управления телекоммуникационными сетями наблюдается устойчивая тенденция применения стандартов ITU-T, в которые входит протокол

598 Глава 7 • Средства анализа и управления сетями

CMIP, и здесь имеется достаточно много примеров успешного использования SNMP-управления. Агенты SNMP встраиваются в аналоговые модемы, модемы ADSL, коммутаторы ATM и т. д.

SNMP — это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков, например IPX/SPX. Протокол SNMP используется для получения от сетевых устройств информации об их стату­се, производительности и других характеристиках, которые хранятся в базе дан­ных управляющей информации MIB (Management Information Base). Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB И. Кроме того, сам протокол SNMP также весьма несложен.

Существуют стандарты, определяющие структуру MIB, в том числе набор ти­пов ее объектов, их имена и допустимые операции над этими объектами (напри­мер, «читать»).

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

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

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

Примитивы протокола SNMP

SNMP — это протокол типа «запрос-ответ», то есть на каждый запрос, поступив­ший от менеджера, агент должен передать ответ. Особенностью протокола являет­ся его чрезвычайная простота — он включает в себя всего несколько команд.

• Команда Get - request используется менеджером для получения от агента значе­ния какого-либо объекта по его имени.

• Команда GetNext- request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.

• С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.

• Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устрой­ством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реаль­ное управляющее воздействие — отключить порт, приписать порт определенной

7.2. Стандарты систем управления 599

VLAN и т. п. Команда Set пригодна также для установки условия, при выполне­нии которого агент SNMP должен послать менеджеру соответствующее сооб­щение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентифи­кация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.

• Команда Trap используется агентом для сообщения менеджеру о возникнове­нии особой ситуации.

• Версия SNMP v.2 добавляет к этому набору команду GetBul k, которая позволяет менеджеру получить несколько значений переменных за один запрос.

Структура SNMP MIB

Ha сегодня существует несколько стандартов на базы данных управляющей ин­формации для протокола SNMP. Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB. Кроме этого существуют стандарты для специальных устройств MIB конкретного типа (напри­мер, MIB для концентраторов или MIB для модемов), а также частные MIB конк­ретных фирм-производителей оборудования.

Первоначальная спецификация MIB-I определяла только операции чтения зна­чений переменных. Операции изменения или установки значений объекта являют­ся частью спецификаций MIB-II.

Версия MIB-I (RFC 1156) определяет 114 объектов, которые подразделяются на 8 групп.

• System — общие данные об устройстве (например, идентификатор поставщика, время последней инициализации системы).

• Interfaces — параметры сетевых интерфейсов устройства (например, их количе­ство, типы, скорости обмена, максимальный размер пакета).

• Address Translation Table — описание соответствия между сетевыми и физически­ми адресами (например, по протоколу ARP).

• Internet Protocol — данные, относящиеся к протоколу IP (адреса IP-шлюзов, хо­стов, статистика о IP-пакетах).

• ICMP — данные, относящиеся к протоколу обмена управляющими сообщения­ми ICMP.

• TCP — данные, относящиеся к протоколу TCP (например, о TCP-соединениях).

» UDP — данные, относящиеся к протоколу UDP (число переданных, принятых и ошибочных UPD-дейтаграмм).

• EGP — данные, относящиеся к протоколу обмена маршрутной информацией Exterior Gateway Protocol, используемому в Internet (число принятых с ошиб­ками и без ошибок сообщений).

Из этого перечня групп переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на управление маршрутизаторами, поддерживающими про­токолы стека TCP/IP.

В версии MIB-II (RFC 1213), принятой в 1992 году, был существенно (до 185) расширен набор стандартных объектов, а число групп увеличилось до 10.

600 Глава 7• Средства анализам управления сетями

На рис. 7.6 приведен пример древовидной структуры базы объектов MIB-II. На нем показаны две из 10 возможных групп объектов — System (имена объектов начинаются с префикса Sys) и Interfaces (префикс if). Объект SysUpTime содержит значение продолжительности времени работы системы с момента последней пере­загрузки, объект SysObjectID — идентификатор устройства (например, маршрутиза­тора).

Объект ifNumber определяет количество сетевых интерфейсов устройства, а объект ifEntry является вершиной поддерева, описывающего один из конкретных интер­фейсов устройства. Входящие в это поддерево объекты ifType и ifAdminStatus опре­деляют соответственно тип и состояние одного из интерфейсов, в данном случае интерфейса Ethernet.

В число объектов, описывающих каждый конкретный интерфейс устройства, включе­ны следующие.

• ifType — тип протокола, который поддерживает интерфейс. Этот объект принимает значения всех стандартных протоколов канального уровня, например rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing и т. д.

• ifMtu — максимальный размер пакета сетевого уровня, который можно послать через этот интерфейс.

• ifSpeed — пропускная способность интерфейса в битах в секунду (100 для Fast Ethernet).

• ifPhysAddress — физический адрес порта, для Fast Ethernet им будет МАС-адрес.

• ifAdminStatus — желаемый статус порта:

• up — готов передавать пакеты;

• down — не готов передавать пакеты;

• testing — находится в тестовом режиме.

7.2. Стандарты систем управления 601

• ifOperStatus — фактический текущий статус порта, имеет те же значения, что и ifAdminStatus.

• iflnOctets — общее количество байт, принятое данным портом, включая служеб­ные, с момента последней инициализации SNMP-агента.

• iflnUcastPkts — количество пакетов с индивидуальным адресом интерфейса, дос­тавленных протоколу верхнего уровня.

• iflnNUcastPkts — количество пакетов с широковещательным или мультивеща-тельным адресом интерфейса, доставленных протоколу верхнего уровня.

• ifTn Discards — количество пакетов, которые были приняты интерфейсом, оказа­лись корректными, но не были доставлены протоколу верхнего уровня, скорее всего из-за переполнения буфера пакетов или же по иной причине.

• itln Errors — количество пришедших пакетов, которые не были переданы прото­колу верхнего уровня из-за обнаружения в них ошибок.

Кроме объектов, описывающих статистику по входным пакетам, имеются ана­логичные объекты, но относящиеся к выходным пакетам.

Как видно из описания объектов MIB-II, эта база данных не дает детальной статисти­ки по характерным ошибкам кадров Ethernet, кроме этого, она не отражает изменение характеристик во времени, что часто интересует сетевого администратора.

Эти ограничения были впоследствии сняты новым стандартом на MIB — RMON MIB, который специально ориентирован на сбор детальной статистики по протоколу Ethernet, к тому же с поддержкой такой важной функции, как построение агентом зави­симостей статистических характеристик от времени.

Форматы и имена объектов SNMP MIB

Для именования переменных базы MIB и однозначного определения их форматов используется дополнительная спецификация, называемая SMI — Structure of Management Information. Например, спецификация SMI включает в качестве стан­дартного имя IpAddress и определяет его формат как строку из 4 байт. Другой пример — имя Counter, для которого определен формат в виде целого числа в диа­пазоне от 0 до 2³²-1.

При описании переменных MIB и форматов протокола SNMP спецификация SMI опирается на формальный язык ASN.1, принятый ISO в качестве нотации для описания терминов коммуникационных протоколов (правда, многие коммуника­ционные протоколы, например IP, PPP или Ethernet, обходятся без этой нотации). Нотация ASN.1 служит для установления однозначного соответствия между тер­минами, взятыми из стандартов, предназначенных для человеческого использова­ния, и теми данными, которые передаются в коммуникационных протоколах аппаратурой. Достигаемая однозначность очень важна для гетерогенной среды, характерной для корпоративных сетей. Так, вместо того чтобы указать, что некото­рая переменная протокола представляет собой целое число, разработчик протоко­ла, использующий нотацию ASN.1, должен точно определить формат и допустимый диапазон переменной. В результате документация на MIB, написанная с помощью нотации ASN.1, может точно и механически транслироваться в форму кодов, ха­рактерных для сообщений протоколов.

Нотация ASN.1 похожа на другие метаязыки, например нормальную Бэкусову форму, используемую при описании языков программирования, в частности Алго-

602 Глава 7 • Средства анализа и управления сетями

ла. Нотация ASN.1 поддерживает базовый набор различных типов данных, таких как целое число, строка и т. п., а также позволяет конструировать из этих базовых типов составные данные — массивы, перечисления, структуры.

Существуют правила трансляции структур данных, описанных на ASN.1, в струк­туры данных языков программирования, например C++. Соответственно, имеются трансляторы, выполняющие эту работу. Примеры описаний данных с помощью ASN.1 приведены ниже при описании протокольных блоков данных SNMP.

Нотация ASN.1 широко используется при описании многих стандартов OSI, в частности моделей управляемых объектов и структуры сообщений протокола CMIP.

Имена переменных MIB могут быть записаны как в символьном, так и в число­вом форматах. Символьный формат используется для представления переменных в текстовых документах и на экране дисплея, а числовые имена — в сообщениях протокола SNMP. Например, символьному имени SysDescr соответствует числовое имя 1, а более точно 1.3.6.1.2.1.1.1.

Составное числовое имя объекта SNMP MIB соответствует полному имени это­го объекта в дереве регистрации объектов стандартизации ISO. Разработчики про­токола SNMP не стали использовать традиционный для стандартов Internet способ фиксации численных параметров протокола в специальном RFC, называемом «Assigned Numbers» (там описываются, например, численные значения, которые может принимать поле Protocol пакета IP, и т. п.). Вместо этого они зарегистриро­вали объекты баз MIB SNMP во всемирном дереве регистрации стандартов ISO, показанном на рис. 7.7.

Как и в любых сложных системах, пространство имен объектов ISO имеет дре­вовидную иерархическую структуру, причем на рис. 7.7 показана только его верх­няя часть. От корня этого дерева отходят три ветви, соответствующие стандартам,

7.2. Стандарты систем управления 603

контролируемым ISO, ITU и совместно ISO-ITU. В свою очередь, организация ISO создала ветвь для стандартов, создаваемых национальными и международны­ми организациями (ветвь org). Стандарты Internet создавались под эгидой Мини­стерства обороны США (Departament of Defence, DoD), поэтому стандарты MIB попали в поддерево dod-internet, а далее, естественно, в группу стандартов управле­ния сетью — ветвь mgmt Объекты любых стандартов, создаваемых под эгидой ISO, однозначно идентифицируются составными символьными именами, начинающи­мися от корня этого дерева. В сообщениях протоколов символьные имена не исполь­зуются, а применяются однозначно соответствующие им составные числовые имена. Каждая ветвь дерева имен объектов нумеруется в дереве целыми числами слева направо, начиная с единицы, и эти числа и заменяют символьные имена. Поэтому полное символьное имя объекта MIB имеет вид: iso.org.dod.internet.mgmt.mib, а полное числовое имя: 1.3.6.1.2.1.

Группа объектов private (4) зарезервирована за стандартами, создаваемыми част­ными компаниями, например Cisco, Hewlett-Packard и т. п. Это же дерево регист­рации используется для именования классов объектов CMIP и TMN.

Соответственно, каждая группа объектов MIB-I и MIB-II также имеет кроме кратких символьных имен, приведенных выше, полные символьные имена и соот­ветствующие им числовые имена. Например, краткое символьное имя группы System имеет полную форму iso.org.dod.internet.mgmt.mib.system, а ее соответствующее числовое имя — 1.3.6.1.2.1. Часть дерева имен ISO, включающая группы объектов MIB, показана на рис. 7.8.

Формат сообщений SNMP

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

SNMP часто рассматривают только как решение для управления сетями TCP/IP. Хотя SNMP чаще всего и работает над UDP (он может также работать и над TCP),

604 Глава 7 • Средства анализам управления сетями

он может работать и над транспортными сетевыми протоколами стека OSI — ТРО, ТР4, CNLS, а также над протоколами МАС-уровня. Растет поддержка протокола SNMP и в других транспортных средах. Например, фирма Novell начала поддер­живать протокол SNMP с версии NetWare 3.11, а некоторые производители обору­дования (например, Bay Networks) реализуют в своих устройствах передачу сообщений SNMP с помощью как IP, так и IPX.

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

Любое сообщение SNMP состоит из трех основных частей: версии протокола (version), идентификатора общности (community), используемого для группирова­ния устройств, управляемых определенным менеджером, и области данных, в кото­рой собственно и содержатся описанные выше команды протокола, имена объектов и их значения. Область данных делится на блоки данных протокола (Protocol Data Unit, PDU).

Общий формат сообщения SNMP в нотации ASN.1 выглядит следующим обра­зом:

SNMP-Message ::= SEQUENCE {

version INTEGER { version-1 (0)

}. community

OCTET STRING, SNMP-PDUs

ANY }

Область данных может содержать пять различных типов PDU, соответствую­щих пяти командам протокола SNMP:

SNMP-PDUs ::= CHOICE {

get-request

GetRequest-PDU, get-next-request

GetNextRequest-PDU, get-response

GetResponse-PDU, set-request

SetRequest-PDU, trap

Trap-PDU,

И наконец, для каждого типа PDU имеется определение его формата. Напри­мер, формат блока GetRequest-PDU описан следующим образом:

GetRequest-PDU ::= IMPLICIT SEQUENCE { request-id

RequestlD. error-status ErrorStatus,

7.2, Стандарты систем управления 605

error-index

Errorlndex, variable-bindings

VarBindList }

Далее стандарт SNMP определяет соответственно формат переменных блока GetRequest-PDU. Переменная Request ID — это 4-байтовое целое число (используется для установления соответствия ответов запросам), ErrorStatus и Errorlndex — это однобайтовые целые, которые в запросе должны быть установлены в 0. VarBindList — это список числовых имен объектов, значениями которых интересуется менеджер. В нотации ASN.1 этот список состоит из пар «имя - значение». При запросе значе­ние переменной должно быть установлено в nul 1.

Вот пример сообщения протокола SNMP, которое представляет собой запрос о значении объекта SysDescr (числовое имя 1.3.6.1.2.1.1.1).

Как видно из описания, сообщение начинается с кода 30 (все коды шестна-дцатеричные), который соответствует ключевому слову SEQUENCE (последователь­ность). Длина последовательности указывается в следующем байте (41 байт). Далее следует целое число длиной 1 байт — это версия протокола SNMP (в данном случае О, то есть SNMP v.l, a 1 означала бы SNMP v.2). Поле community имеет тип string (строка символов) длиной в 6 байт со значением public. Остальную часть сообще­ния составляет блок данных GetRequest-PDU. To, что это операция Get-request, гово­рит код АО (это значение определено в протоколе SNMP, а не в нотации ASN.1), а общая длина блока данных — 28 байт. В соответствии со структурой блока Getrequest-PDU, далее идет идентификатор запроса (он определен как целое 4-байтовое число). Затем в блоке следуют два однобайтовых целых числа статуса и индекса ошибки, которые в запросе установлены в 0. И наконец, завершает сообщение список объек­тов, состоящий из одной пары — имени 1.3.6.1.2.1.1.1.0 и значения null.

606 Глава 7 • Средства анализа и управления сетями

Спецификация RMON MIB

Новейшим добавлением к функциональным возможностям SNMP является специ­фикация RMON, которая обеспечивает удаленное взаимодействие с базой MIB. До по­явления RMON протокол SNMP не мог использоваться удаленным образом, он допускал только локальное управление устройствами. База RMON MIB обладает улучшенным набором свойств для удаленного управления, так как содержит агреги­рованную информацию об устройстве, не требующую передачи по сети больших объемов информации. Объекты RMON MIB включают дополнительные счетчики ошибок в пакетах, более гибкие средства анализа трендов и статистики, более мощ­ные средства фильтрации для захвата и анализа отдельных пакетов, а также более сложные условия установления сигналов предупреждения. Агенты RMON MIB бо­лее интеллектуальны по сравнению с агентами MIB-I или MIB-II и выполняют зна­чительную часть работы по обработке информации об устройстве, которую раньше выполняли менеджеры. Эти агенты могут располагаться внутри различных комму­никационных устройств, а также быть выполнены в виде отдельных программных модулей, работающих на универсальных персональных компьютерах и ноутбуках. Объекту RMON присвоен номер 16 в наборе объектов MIB, а сам объект RMON объединяет 10 групп следующих объектов.

• Statistics — текущие накопленные статистические данные о характеристиках па­кетов, количестве коллизий и т. п.

• History — статистические данные, сохраненные через определенные промежутки времени для последующего анализа тенденций их изменений.

• Alarms — пороговые значения статистических показателей, при превышении ко­торых агент RMON посылает сообщение менеджеру.

• Hosts — данные о хостах сети, в том числе и о их МАС-адресах.

• Host TopN — таблица наиболее загруженных хостов сети.

• Traffic Matrix — статистика об интенсивности трафика между каждой парой хос­тов сети, упорядоченная в виде матрицы.

• Filter — условия фильтрации пакетов.

• Packet Capture — условия захвата пакетов.

• Event — условия регистрации и генерации событий.

Данные группы пронумерованы в указанном порядке, поэтому, например, груп­па Hosts имеет числовое имя 1.3.6.1.2.1.16.4.

Десятую группу составляют специальные объекты протокола Token Ring.

Всего стандарт RMON MIB определяет около 200 объектов в 10 группах, зафикси­рованных в двух документах — RFC 1271 для сетей Ethernet и RFC 1513 для сетей Token Ring.

Отличительной чертой стандарта RMON MIB является его независимость от протокола сетевого уровня (в отличие от стандартов MIB-I и MIB-II, ориентиро­ванных на протоколы TCP/IP). Поэтому он удобен для гетерогенных сред, исполь­зующих различные протоколы сетевого уровня.

Рассмотрим более подробно группу Statistics, которая определяет, какую ин­формацию о кадрах (называемых в стандарте пакетами) Ethernet может предоста­вить агент RMON. Группа History основана на объектах группы Statistics, так как ее объекты просто позволяют строить временные ряды для объектов группы Statistics.

7.2. Стандарты систем управления 607

В группу Statistics входят наряду с некоторыми другими следующие объекты.

• etherStatsDropEvents — общее число событий, при которых пакеты были проигно­рированы агентом из-за недостатка его ресурсов. Сами пакеты при этом не обя­зательно были потеряны интерфейсом.

• etherStatsOctets — общее число байт (включая ошибочные пакеты), принятых из сети (исключая преамбулу н включая байты контрольной суммы).

• etherStatsPkts — общее число полученных пакетов (включая ошибочные).

• etherStatsBroadcastPkts — общее число хороших пакетов, которые были посланы по широковещательному адресу.

• etherStatsMulticastPkts — общее число хороших пакетов, полученных по мульти-вещательному адресу.

• etherStatsCRCAlign Errors — общее число полученных пакетов, которые имели дли­ну (исключая преамбулу) между 64 и 1518 байт, не содержали целое число байт (alignment error) или имели неверную контрольную сумму (PCS error).

• etherStatsUndersizePkts — общее число пакетов, которые имели длину меньше, чем 64 байт, но были правильно сформированы.

• etherStatsOversizePkts — общее число полученных пакетов, которые имели длину больше, чем 1518 байт, но были тем не менее правильно сформированы.

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

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

• etherStatsCollisions — наилучшая оценка числа коллизий на данном сегменте Ethernet.

• etherStatsPkts640ctets — общее количество полученных пакетов (включая пло­хие) размером 64 байт.

• etherStatsPkts65tol270ctets — общее количество полученных пакетов (включая плохие) размером от 65 до 127 байт.

• etherStatsPkts!28to2550ctets — общее количество полученных пакетов (включая плохие) размером от 128 до 255 байт.

в etherStatsPkts256to5110ctets — общее количество полученных пакетов (включая плохие) размером от 256 до 511 байт.

• etherStatsPkts512to!0230ctets — общее количество полученных пакетов (включая плохие) размером от 512 до 1023 байт.

• etherStatsPktsl024to15180ctets — общее количество полученных пакетов (вклю­чая плохие) размером от 1024 до 1518 байт.

Как видно из описания объектов, с помощью агента RMON, встроенного в по­вторитель или другое коммуникационное устройство, можно провести очень де­тальный анализ работы сегмента Ethernet или Fast Ethernet. Сначала можно получить данные о встречающихся в сегменте типах ошибок в кадрах, а затем целе-

608 Глава 7 • Средства анализам управления сетями

сообразно собрать с помощью группы History зависимости интенсивности этих ошибок от времени (в том числе и привязав их ко времени). После анализа времен­ных зависимостей часто уже можно сделать некоторые предварительные выводы об источнике ошибочных кадров и на этом основании сформулировать более тон­кие условия захвата кадров со специфическими признаками (задав условия в группе Filter), соответствующими выдвинутой версии. После этого можно провести еще более детальный анализ за счет изучения захваченных кадров, извлекая их из объек­тов группы Packet Capture.

Позже был принят стандарт RMON 2, который распространяет идеи интеллек­туальной RMON MIB на протоколы верхних уровней, выполняя часть работы ана­лизаторов протоколов.

Недостатки протокола SNMP

Протокол SNMP служит основой многих систем управления, хотя имеет несколь­ко принципиальных недостатков, которые перечислены ниже.

• Отсутствие средств взаимной аутентификации агентов и менеджеров. Един­ственным средством, которое можно было бы отнести к средствам аутенти­фикации, является использование в сообщениях так называемой «строки сообщества» — «community string». Эта строка передается по сети в открытой форме в сообщении SNMP и служит основой для деления агентов и менедже­ров на «сообщества», так что агент взаимодействует только с теми менеджера­ми, которые указывают в поле community string ту же символьную строку, что и строка, хранящаяся в памяти агента. Это, безусловно, не способ аутентифика­ции, а способ структурирования агентов и менеджеров. Версия SNMP v.2 долж­на была ликвидировать этот недостаток, но в результате разногласий между разработчиками стандарта новые средства аутентификации хотя и появились в этой версии, но как необязательные.

• Работа через ненадежный протокол UDP (а именно так работает подавляющее большинство реализаций агентов SNMP) приводит к потерям аварийных сооб­щений (сообщений trap) от агентов к менеджерам, что может привести к нека­чественному управлению. Исправление ситуации путем перехода на надежный транспортный протокол с установлением соединений чревато потерей связи с огромным количеством встроенных агентов SNMP, имеющихся в установлен­ном в сетях оборудовании. (Протокол CMIP изначально работает поверх на­дежного транспорта стека OSI и этим недостатком не страдает.) Разработчики платформ управления стараются преодолеть эти недостатки. На­пример, в платформе HP OV Telecom DM TMN, являющейся платформой для разработки многоуровневых систем управления в соответствии со стандартами TMN и ISO, работает новая реализация SNMP, организующая надежный обмен сообще­ниями между агентами и менеджерами за счет самостоятельной организации по­вторных передач сообщений SNMP при их потерях.

7.2.3. Стандарты управления OSI

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

7.2. Стандарты систем управления 609

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

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

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

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

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

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

Функциональные области управления системами уже были рассмотрены в раз­деле 7.1, как имеющие общее значение для любых систем управления.

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

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

Агенты и менеджеры

Определения функций агентов и менеджеров в стандартах OSI достаточно хорошо согласуются с определениями систем SNMP, за некоторыми исключениями в тер­минологии. Сообщения, которые агент посылает менеджеру по своей инициативе, называются уведомлениями — notifications.

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

610 Глава 7• Средства анализа и управления сетями

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

ПРИМЕЧАНИЕВ стандартах Internet под объектом понимается отдельный атрибут базы MIB, являющейся моделью управ­ляемого ресурса, а в стандартах ISO объект обозначает всю модель управляемого ресурса.

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

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

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

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

ПРИМЕЧАНИЕНеобходимо отметить, что стандарты управления OSI в значительной степени ориентированы на стек про­токолов OSI (именно стек, а не модель OSI), так же как системы управления SNMP ориентированы на роботу со стеком TCP/IP._____________________________________________________________________

Прикладной уровень стека OSI включает несколько вспомогательных служб общего назначения, которые используются прикладными протоколами и пользо­вательскими приложениями (в том числе и приложениями управления) для авто­матизации наиболее часто выполняемых действий. Это не законченные протоколы прикладного уровня, подобные протоколам ftp, telnet или NCP, с помощью которых пользователь сети может выполнить какое-то полезное действие, а вспомогатель­ные системные функции, которые помогают разработчику прикладного протокола или приложения написать его программу компактно и эффективно. На приклад­ном уровне стека OSI существуют следующие вспомогательных службы.

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

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

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

7.2. Стандарты систем управления 611

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

Управление системами, управление уровнем и операции уровня

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

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

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

Наконец, операции N-уровня сводятся к мониторингу и управлению на основе управляющей информации, содержащейся в коммуникационных протоколах толь­ко данного уровня. Например, данные мониторинга сети, содержащиеся в кадрах STM-n технологии SDH, относятся к операциям N-уровня, а именно физического уровня.

Стандарты на управление N-уровнем и операции N-уровня не входят в набор стандартов управления OSI. Стандарты OSI рассматривают только управление системами с помощью полного семиуровневого стека.

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

Информационная модель управления

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

612 Глова 7 • Средства анализа и управления сетями_________________________________________

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

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

Управляющие знания и деревья знаний

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

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

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

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

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

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

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

7.2. Стандарты систем управления 613

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

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

Использование древовидных баз данных для хранения управляющих знаний

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

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

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

ПРИМЕЧАНИЕ Между деревом наследования и деревом включений нет прямой связи. Например, в дереве включений объект «корпоративный концентратор» может включать объекты «интерфейс Ethernet» и «модуль удален­ного доступа», которые представляют модели реальных модулей, установленных в слоты корпоративного концентратора. В то же время в дереве наследования класс объектов «интерфейсы Ethernet» подчинен классу объектов «интерфейсы», а класс объектов «модуль удаленного доступа» подчинен классу «коммуни-кационное оборудовоние третьего уровня», на основании которого он порожден._____________________

• Дерево имен (naming tree) определяет способ именования объектов в системе управления. Объекты OSI могут иметь имена нескольких типов: относительное отличительное имя (Relative Distinguished Name, RDN), отличительное имя (Distinguished Name, DN), иногда называемое полным отличительным именем (Full Distinguished Name, FDN), и локальное отличительное имя (Local Distinguished Name, LDN). Эти имена связаны с деревом включений, так как определяют имена объектов относительно включающих их объектов. Относитель­ное имя, RDN, соответствует короткому имени, которое однозначно определяет объект среди множества других объектов, подчиненных тому же родительскому

614 Глава 7 • Средство анализа и управления сетями ____________________________________

объекту. Например, имя interface_a является RDN-именем, уникально характе­ризующим объект среди объектов, подчиненных объекту node_a. Полное отли­чительное имя FDN представляет собой последовательность RDN-имен, начинающуюся в вершине глобального дерева имен, то есть дерева, опи­сывающего некоторую глобальную сеть. Наконец, локальное отличительное имя — это последовательность RDN-имен, но начинающаяся не в глобальном корне, а в корне дерева имен локальной системы управления, отвечающей за часть гло­бального дерева имен данной сети. Дерево имен обычно совмещается с деревом включений. Пример дерева включений показан на рис. 7.10. Экземпляр управляемого объекта класса corp-сопс (корпоративный концентратор) имеет имя В1, а также атрибут max-slotes, описывающий максимальное количество слотов данного класса концен­траторов, равный в данном случае 14. В этот объект включено ряд других объек­тов: объекты класса repeater, switch и RAS, которые в свою очередь включают объекты типа interface, описывающие порты модулей концентратора.

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

Правила определения управляемых объектов

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

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

7.2. Стандарты систем управления 615

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

Атрибуты и Группы атрибутов определяют параметры объекта, которые можно читать и узнавать из них о состоянии объекта. Свойства Действия описывают воз­можные управляющие воздействия, которые допускается применять к данному объекту — например, мультиплексировать несколько входных потоков в один вы­ходной. Свойство Поведение описывает реакцию объекта на примененное к нему действие. Уведомления составляют набор сообщений, которые генерирует объект по своей инициативе.

Заполненные шаблоны GDMO определяют представление класса и его свойств.

Заполнение шаблонов выполняется в соответствии с нотацией ASN.1. В отли­чие от стандартов 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, и организации, разрабатывающие платформы и инструмен­тальные средства для систем управления, такие как SunSoft, Hewlett-Packard, Vertel, ISR Global. Для телекоммуникационных сетей в рамках архитектуры TMN разра­ботан стандарт М.3100, который описывает ряд специфических для телекоммуни­кационных сетей классов объектов.

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

В отсутствие одной регистрирующей организации, такой как IETF Internet, использование классов объектов OSI представляет собой непростую задачу.

Протокол CMIP и услуги CMIS

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

616 Глава 7 • Средства анализам управления сетями

жер, а часть — агент. Взаимодействие между менеджером и агентом осуществляется по протоколу CMIP. Услуги, предоставляемые службой CMSIE, называются услу­гами CMIS (Common Management Information Services).

Протокол CMIP и услуги CMIS определены в стандартах Х.710 и Х.711 ITU-T.

Услуги CMIS разделяются на две группы — услуги, инициируемые менеджером (запросы), и услуги, инициируемые агентом (уведомления).

Услуги, инициируемые менеджером, включают следующие операции:

• M-CREATE инструктирует агента о необходимости создать новый экземпляр объекта определенного класса или новый атрибут внутри экземпляра объекта;

• M-DELETE инструктирует агента о необходимости удаления некоторого экземп­ляра объекта определенного класса или атрибута внутри экземпляра объекта;

• M-GET инструктирует агента о возвращении значения некоторого атрибута опре­деленного экземпляра объекта;

• M-SET инструктирует агента об изменении значения некоторого атрибута опре­деленного экземпляра объекта;

• M-ACTION инструктирует агента о необходимости выполнения определенного действия над одним или несколькими экземплярами объектов.

Агент инициирует только одну операцию:

M-EVENT_REPORT — отправка уведомления менеджеру.

Для реализации своих услуг служба CMISE должна использовать службы при­кладного уровня стека OSI — ACSE, ROSE.

Отличие услуг CMIS от аналогичных услуг SNMP состоит в большей гибкости. Если запросы GET и SET протокола SNMP применимы только к одному атрибуту одного объекта, то запросы M-GET, M-SET, M-ACTION и M-DELETE могут применяться к более чем одному объекту. Для этого стандарты CMIP/CMIS вводят такие поня­тия, как обзор (scoping), фильтрация (filtering) и синхронизация (synchronization).

Обзор

Запрос CMISE может использовать обзор, чтобы опросить одновременно несколь­ко объектов. Вводятся четыре уровня обзора:

• базовый объект, определенный своим отличительным именем FDN;

• объекты, расположенные на n-м уровне подчинения относительно базового (сам базовый объект находится на уровне 0) в дереве включения;

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

• поддерево — базовый объект и все ему подчиненные в дереве включения.

Фильтрация

Фильтрация заключается в применении булевого выражения к запросу менеджера. Запрос применяется только к тем объектам и их атрибутам, для которых данное булево выражение верно. Булевы выражения могут включать операторы отноше­ния -, >-, <~, >, < или определенные атрибуты. Возможно построение сложных фильтров на основе объединения нескольких фильтров в один составной.

7.2. Стандарты систем управления 617

Синхронизация

При выполнении запросов к нескольким объектам используется одна из двух схем синхронизации: атомарная или «по возможности». При атомарной схеме запрос выполняется только в том случае, когда все объекты, попадающие в область дей­ствия обзора или фильтра, могут успешно выполнить данный запрос. Синхрониза­ция «по возможности» подразумевает передачу запроса всем объектам, к которым запрос относится. Операция завершается при выполнении запроса любым количе­ством объектов.

Протокол CMIP представляет собой набор операций, прямо соответствующих услугам CMIS. Таким образом, в протоколе CMIP определены операции M-GET, M-SET, M-CREATE и т. д. Для каждой операции определен формат блока данных, пере­носимых по сети от менеджера агенту, и наоборот.

Формат протокольных блоков данных CMIP описывается нотацией ASN.1 и имеет гораздо более сложную структуру, чем блоки SNMP. Например, блок данных операции M-GET имеет поля для задания имен атрибутов, значения которых запра­шивает менеджер, а также поля задания параметров обзора и фильтрации, опреде­ляющих множество экземпляров объектов, на которые будет воздействовать данный запрос. Имеются также поля для задания параметров прав доступа к объекту.

Сравнение протоколов SNMP и CMIP

• Применение протокола SNMP позволяет строить как простые, так и сложные системы управления, а применение протокола CMIP определяет некоторый, достаточно высокий начальный уровень сложности системы управления, так как для его работы необходимо реализовать ряд вспомогательных служб, объек­тов и баз данных объектов.

• Агенты CMIP выполняют, как правило, более сложные функции, чем агенты SNMP. Из-за этого операции, которые менеджеру можно выполнить над аген­том SNMP, носят атомарный характер, что приводит к многочисленным обме­нам между менеджером и агентом.

• Уведомления (traps) агента SNMP посылаются менеджеру без ожидания под­тверждения, что может привести к тому, что важные сетевые проблемы останут­ся незамеченными, так как соответствующее уведомление окажется потерянным, в то время как уведомления агента CMIP всегда передаются с помощью надеж­ного транспортного протокола и в случае потери будут переданы повторно.

• Решение части проблем SNMP может быть достигнуто за счет применения бо­лее интеллектуальных MIB (к которым относится RMON MIB), но для многих устройств и ситуаций таких MIB нет (или нет стандарта, или нет соответствую­щей MIB в управляемом оборудовании).

• Протокол CMIP рассчитан на интеллектуальных агентов, которые могут по одной простой команде от менеджера выполнить сложную последовательность дей­ствий.

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

618 Глава 7 • Средства анализам управления сетями

Выводы

* Существуют два популярных семейства стандартов систем управления: стан­дарты Internet, описывающие системы управления на основе протокола SNMP, и международные стандарты управления открытых систем (OSI), разработан­ные ISO и ITU-T, опирающиеся на протокол управления CMIP. Семейство стан­дартов Internet специфицирует минимум аспектов и элементов системы управления, а семейство стандартов ISO/ITU-T — максимум.

» Системы управления SNMP основаны на следующих концепциях, ориентиро­ванных на минимальную загрузку управляемых устройств:

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

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

• протокол взаимодействия между агентом и менеджером SNMP опирается на простой ненадежный транспортный протокол UDP (для разгрузки управля­емого устройства) и использует два основных типа команд — get для получе­ния данных от агента и set для передачи управляющих воздействий агенту;

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

* Базы управляющей информации MIB в стандартах Internet состоят из дерева атрибутов, называемых объектами и группами объектов.

* Первые MIB Internet были ориентированы на управление маршрутизаторами: MIB-I — только контроль, MIB-II — контроль и управление. Более поздняя раз­работка RMON MIB была направлена на создание интеллектуальных агентов, контролирующих нижний уровень, — интерфейсы Ethernet и Token Ring. Име­на объектов стандартных MIB Internet зарегистрированы в дереве регистрации имен стандартов ISO.

» Стандарты ISO/ITU-T для представления управляемых устройств используют объектно-ориентированный подход. Определено несколько суперклассов обоб­щенных управляемых объектов, на основании которых путем наследования свойств должны создаваться более специфические классы объектов.

* Для описания управляемых объектов OSI разработаны правила GDMO, осно­ванные на формах определенной структуры, заполняемых с помощью языка

ASN.1.

» Для представления знаний об управляемых объектах, агентах и менеджерах системы управления OSI используется три древовидные базы данных: дерево наследования, которое описывает отношения наследования между классами объектов, дерево включения, которое описывает отношения соподчинения меж­ду конкретными элементами системы управления, и дерево имен, которое опре­деляет иерархические имена объектов в системе.

* Протокол CMIP, который является протоколом взаимодействия между агента­ми и менеджерами системы управления OSI, позволяет с помощью одной ко-

7.3. Мониторинг и анализ локальных сетей 619

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