Лекция №8

Вид материала

Подобный материал:

Лекция № 8

21.04.2009

Денисов

Сегодня вторая ознакомительная лекция, похожая на первую.

Мы переходим к практической части, это стандарты SNMP.

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

На первой лекции мы рассмотривали вопросы появления систем управления в целом, как класса, как разделв общей науке ИТ, то сегоджня мы буем говрить о конкретной системе стандартов.

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

Семейство стандартов SNMP не исключение, примерно в 85-86 году

Что бы стандартизовать область сетевых технологий международная организации по стандартизации (ISO) замутила глобальных проект по стандартизации всего что только можно. Один из них – OSI. В рамках этой гиганской рабоыт была создана концепция автоматизированной системы управления. X.700. Выжимки из неё были в первой половине курса. Она была полностью объектно-оринтирована. Но как многие вещи в ISO разрабатывалось кабинетными учеными. Поэтому примерно к 85 году стало ясно, что усилия OSI буксуют. Рабочая группа по системам управления поняла что сейчас, когда стандарты не готовы было принято решение разработать семейство стандартов что бы управлять сетями на базе TCP/IP которые бы выполняли функции возлагавшиеся на X.700. Придумать систему управления сетями TCP/IP. В ноябре 87 года опубликован SNMP. К этому моменту было уже несколько систем сетевого управления, разработанные производителями сетевого оборудования, которые работали только с этим оборудованием, и которые использовались мало. Но был еще один протокол, созданный совсем не для сетевого управления – ICMP. Все его сообщения прозволяли достаточно неплохо контролировать базовую связность сетей (доступны-не доступны) Как ни странно никто из разработкичво TCP/IP. Поэтому первое желание – расширить стандарт ICMP для вклбчения в него функции по мониторингу узлов. Это HMP (Host Monitoring Protocol). После публикации запроса на предложения по стандарту, на его основе был разработан стандарт под названием HEMS (High-level Entity Management system). Стандарт до боли напоминал сьтендарт ICMP. Он его расширял, это был точно такой же протокол сетевого уровня, основанный на запросах и ответах, но он бы High-level, то есть у нему добалялась возможность передачи высокоуровневых объектов. Другим предложением было расширение коммерческой разработки SGMP (Simple Gateway Monitoring Protocol). Gateway – шлюз, штука стоящая на границе сети. Это очень типовая вещь, функция любого гейтвея хорошо стандартизуема. Ждя него был разработан некий стандарт, который учитивал стандарты OSI. (На основаниит этого SGMP был разработан стандарт SNMP.) Последнее предложение постепило от самого комитета и называлось СМOT (CMIP Over TCP/IP, CMIP – Common Management Information Protocol). Заточен под TCP/IP. Этот стандарт был наиболее насыщен. Сохранял объектно-ориентированную среду, кроме того все данные легко переводились на др стандарт.

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

В начале 88 года было принято странное решение. Разрабатывать одновременно стандарты SNMP и CMOT. При этом из стандарта SNMP предполагалось использовать только протокол, который у него был специфицирован, а структуру управляющей информации и спецификацию базы упр информации взять из стандарта CMOT. Это решение было краткосрочным. А в качестве более долгосрочной перспективы было решено разрабатывать CMOT, тогда перебираться с одного на другое было бы просто (достаточно заменить протокол). На практике выяснилось что объем работ, оказалось что объем работ необходимых для адаптации CMIP для TCP/IP очень велик, что структура управляющей информаыции достаточно сложная и в 1988 году было принято решение окончательно разделить эти разработки. И тогда стандарт SNMP стал развиваться очень быстро. И к концу 1988 года была опубликована первая версия международного стандарта SNMP. Стандарт CMOT несколько лет пытались разрабатывать, однако SNMP оказался настолько простым, удобным в реализации, (при всех своих недостатках), и развивался настолько быстро, что в начале 90х годов, выяснилось что на стандарт OSI никто не собирается переходить и темп разработки CMOT безнадежно отставал от темпов разработки SNMP.

Таким образом, SNMP остался единственным стандартом.

К концу 90 года около 50% поставляемого управляемого оборудования поддерживало стандарт SNMP. Количество систем управления поодерживающих SNMP к середине 90х годов исчислялось десятками. И сейчас известных систем можно назвать больше 10 штук, несмотря на естественный отбор. А просто утилит и конкретных стециальных приложений, которые позволяли бы взаимодействовать с оборудованием стандарта SNMP то их сотни и тысячи. Так что стандарт показал ствою жизнеспособность.

Краткий обзор того что входит в этот стандарт и как в целом работает семейство SNMP.

Начнем с SNMP v.1

На практике он используется достаточно редко (хотя и поддерживается всем оборудованием). Хотя он прост, проще, чем версии 2 и 3. Лучше чем остальные принципы показывает основополагающие принципы, которые в него закладывались, когда этот стандарт создавался.

Итак, SNMPv1 строится на основе трех документов.

RFC 1155 – структура управляющей информации SNMP, Structure and identification of management information
RFC 1213 – Management Information Base-2
RFC 1157 – Simple Network Management Protocol

Первый документ – структура управляющей информации. Это способ описания объектов в базе управляющей информации.

RFC 1213 определяет конкретную стандартную базу управляющей информации. База управляющей информации это с одной стороны конкретная база, которая описывает текущее состояние устройства, а с другой стороны это конкретный документ, которые эту конфигурацию, эту базу описывает. Тут имеется в виду второе. ER диаграмма (entity relationship). Заметим, что база управляющей информации у агента всегда одна, но она моэет поддерэивать несколько таких спецификаций (как сервер БД может хранить несколько БД). Таким образом, SMNP поддерживает несколько таких баз управляющей информации.

RFC 1157 это собственно спецификация протокола SNMP.

Архитектура протокола SNMP.

В целом архитектура SNMP соответсвует архитектуре семейств стандарта OSI. Точно так же есть станция сетевого управления, набор управляемых элементоа, внутри этих элементов работают агенты, таких агентов Мб много, все эти штуки связаны друг с другом через нашу сеть. Связаны они с помощью нашего конктерного протокола SNMP. На станции сетевого управления существует своя база управляющей информации и есть набор приложений сетевого управления. Эта архитектура нам до боли знакома. Необходимо отметить стандартизацию. Не стандартизируется все что происходит на станции сетевого управления. Жизнь стандарта SNMP начинается с момента отправки или приема сообщения SNMP. Абсолютно не регламентирует внутреннюю структуру агента и БД. Только внешнюю структуру. Стандартизован интерфейс.

SNMP – стандарт, основанный на сообщениях.

SNMP содержит три вида операций: trap, set, get

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

Set – изменить значение в базе управляющей информации.

Trap – асинхронно известить станцию сетевого управления о наступлении каких-то существенных условий.

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

SNMP поддерживает всего пять сообщений.

Get-request, позволяет считать значение одного или нескольких объестов из базы управляющей информации
get-next-request, позволяет считать одного или нескольких значений следующих в лексикографическом порядке за указанным
set-request, позволяет изменить значение одного или нескольких элементов.
get-response, ответ на сообщения 1-3. содержит результаты запросов 1-2 или 3
trap, асинхронно извещает станцию сетевого управления о наступлении исключительного условия.

Сообщения 1-3 идет от станции сетевого управления к агенту системы сетевого управления. Сообщения 4-5 наоборот.

SNMP v1 не содержит средств для стандартизации этих сообщений.

Стратегия сбора данных – опросы управляемые извещениями (как по-английски?)

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

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

Стандарт SNMP поддерживает понятие прокси, однако это понятие не раскрывается стандартами.

Протокол SNMP это протокол прикладного уровня, который опирается на протокол UDP. Это протокол ненадежный, но он проще и менее перегружен, чем TCP.

Blog

Лекция №8