Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Тематический план
Отдел рекламы
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Поддержка протокола SNМР в JАVА-приложениях

Юрий Чашков

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

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

Практически во всех системах управления сетями используется простой сетевой протокол управления (Simple Network Management Protocol, SNMP) [1]. На самом деле это не просто протокол, а целая технология, призванная обеспечить управление и контроль за устройствами и приложениями в сети. С её помощью можно контролировать абсолютно любые устройства, подключенные к компьютерной сети, например датчики пожаротушения или светофоры. К достоинствам протокола SNMP можно отнести его поддержку сетевым оборудованием и системами сетевого управления для широкого круга производителей, а также удачную реализацию структуры параметров сетевых устройств. Однако механизм SNMP-опроса имеет ряд существенных недостатков:

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

· Использование транспортного протокола UDP, не гарантирующего доставку информации.

· Слабая криптографическая стойкость.

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

Одно из архитектурных решений, позволяющих устранить некоторые недостатки управления при помощи SNMP - это применение распределенной системы управления на основе Web-интерфейса. При таком подходе доступ к управляющим приложениям осуществляется при помощи протокола НТТР, а общедоступные клиенты (браузеры) могут заменить часть клиентского ПО, традиционно используемого для целей управления. Кроме того, расположенные в стратегических местах специальные конверторы способны преобразовывать сообщения HTTP в SNMP и обратно, что открывает новые возможности для распределения обязанностей в сфере управления без помощи широкомасштабной платформы управления.

Еще одним достоинством управления сетью на базе Web является то, что системный администратор не привязан к определенной консоли, и может использовать для управления любую машину в сети. Как следствие, упрощается, например, работа по диагностике и наладке сети при обрывах каналов связи или управление территориально распределенной сетью, различные части которой не обязательно должны быть соединены выделенными каналами - вполне будет достаточно каналов Сети. Однако при таком подходе увеличивается вероятность внешнего вторжения. Но, одновременно с этим уменьшается вероятность взлома самого протокола SNMP (в котором пароль доступа передается в незашифрованном виде), так как при этом используются криптографические возможности HTTP протокола. В отличии от SNMP, HTTP базируется на TCP. TCP устанавливает сквозное соединение между двумя узлами и гарантирует подтверждение получения каждого пакет. Благодаря тому, что TCP обеспечивает контроль над всеми соединениями, пакеты можно идентифицировать и шифровать на транспортном уровне. Secure Socket Level (SSL) позволяет защитить любые приложения, такие как ftp или telnet, а не только HTTP. Благодаря вспомогательным сервисам TCP, HTTP позволяет также решать вопросы защиты на прикладном уровне, точнее говоря этим занимается Secure HTTP (S/HTTP). Таким образом, если бы потоки управляющих данных передавались по HTTP, то вопросы защиты SNMP исчезли бы сами собой [2]. При помощи Web технологии можно более полно воспользоваться разграничением прав доступа к информации, что позволяет оперативно самими пользователями без привлечения администратора составлять, например, различные отчеты о функционировании сети.

Вероятно, простейшей реализацией управления на базе Web является привязка Web сервера к высокоуровневым средствам подготовки отчетов, которые экспортируют полученную информацию о состоянии управляемого объекта в формат HTML, и любой человек, имеющий браузер и соответствующие права доступа, может прочитать отчеты. Непосредственно сами приложения могут быть оформлены в виде СGI-скриптов или JАVА-апплетов. Принципиальное отличие этих методов состоит в том, что СGI-скрипты выполняются на Web сервере, а JАVА-апплеты загружаются с сервера и интерпретируются браузером на рабочем месте. В зависимости от специфики решаемой задачи, предпочтение может быть отдано тому или иному способу. Если приложение ориентировано на удобный интерфейс, содержит обновляемые таблицы и динамически рисуемые графики, то следует использовать апплеты. А в случае, если основная задача заключается в проведении вычислительных работ для обработки информации, поступающей с сетевого устройства, то имеет смысл воспользоваться CGI-скриптом. При этом данные будут представляться в виде обновляемых НТМL-страниц. Заметим, однако, что каждое обращение к скрипту вызывает запуск нового процесса. Поэтому, если таких обращений за единицу времени будет много, то JAVA-апплет может оказаться более эффективным средством [3]. Еще одним доводом в применении именно языка JAVA является его основная концепция "написано однажды - работает везде", а также то, что сегодня идет активная разработка варианта спецификаций Java-технологий для приложений реального времени.

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

Компанией SunSoft была предложена инициативная разработка на базе Java под названием Solstice Workshop, и ее составная часть - JMAPI (Java Management API) представляющую собой среду программирования для создания ПО управления сетями и системами на базе Web-технологий. Помимо JMAPI, в состав Solstice Workshop входит база данных и среда программирования на Java. Основными достоинствами Solstice Workshop является то, что JMAPI легко поддается расширению, а язык Java полностью универсален. О своей поддержке JMAPI уже было объявлено сторонними производителями. Средства из этого набора будут обеспечивать поддержку средств, предназначенных для представления данных в стандартном виде. Следует, однако, заметить, что определения классов объектов JMAPI пока что не детализированы. По этому, для того чтобы удовлетворить запросы как пользователей (стремящихся получить в свое распоряжение программы с наиболее широкими возможностями), так и производителей (заинтересованных в переносимости разрабатываемых приложений) понадобятся новые стандарты.

В языке Jаvа имеется встроенная поддержка программирования сетевых приложений, в частности, к стандартным библиотекам сетевого программирования относится библиотека jаvа.net, предоставляющая пользователю все необходимые сетевые интерфейсы. Однако, для создания более эффективных приложений управления сетевыми ресурсами, необходимы библиотеки классов, которые бы реализовывали поддержку протокола SNМР и функций работы с файлами МIВ. В этой области можно выделить три наиболее крупные разработки:

1. Проект компании Webbin (подразделение IBM) по интеграции протоколов SNМР и ICMP в язык Javа [4]. Webbin является платформонезависимым добавлением к Web-серверу, что позволяет системным администраторам и пользователям просматривать, искать, и изменять данные без привлечения дополнительных инструментов. Вся обработка информации и форматирование HTML-документов происходит на стороне HTTP сервера, таким образом, нет потребности в установке дополнительных приложений на стороне клиента. Отличительной особенностью этого пакета является наличие дополнительной возможности, при помощи которой определяется правильность команд и предотвращается подача пользователями некорректных запросов. Однако, несмотря на компактность и простоту в этом пакете имеются некоторые ограничения, например, отсутствуют функции работы с файлами МIВ. К тому же этот проект находится в стадии разработки и пока невозможно гарантировать его стабильную работу, а также сохранение существующих функций в более поздних версиях.

2. Проект компании WestHawk, специализирующейся на управляющих приложениях [5]. В проекте представлен пакет классов поддержки протокола SNМР и описания АSN.1. Пакет полностью обеспечивает все основные функции протокола SNMP (получение информации, установку и удаление пороговых значений). В отличие, например, от пакета AdventNet, он является легковесным (его размер составляет около 1,2 Мбайт), однако здесь не реализованы функции более высокого уровня для поддержки таких технологий, как RMI, CORBA и апплет-серверная архитектура. В связи с этим данный пакет может быть использован при создании небольших приложений, в которых критична скорость выполнения и размер программного кода.

3. Библиотека классов "АdventNet SNMP Package" от компании АdventNet [6]. Это довольно обширный пакет классов, реализующий запросы SNМР, работу с файлами МIВ и архитектурные решения, позволяющие преодолеть ограничения безопасности языка Java. Это бесплатный пакет удовлетворяет всем перечисленным критериям. Кроме того, на данный момент он уже прошел довольно длинную стадию развития (вышла третья версия), имеется служба технической поддержки.

Пакет классов AdventNet SNMP API разрабатывался для расширения применения протокола SNMP совместно с новыми Java технологиями. При помощи последней версии AdventNet SNMP API разработчики управляющего ПО могут воспользоваться возможностями Java Beans, технологиями распределенных вычислений RMI и CORBA, а также строить серверные управляющие приложения и даже апплеты.

Поддержка различных версий протокола SNMP, а также файлов MIB осуществляется в соответствии со стандартами: SNMPv1 - RFC1155 и RFC1157, SNMPv2c - RFC1901 и RFC1907, SNMPv3 - RFC2571 и RFC2572, SNMPv3 USM - RFC2574, SNMPv3 VACM - RFC2575. На рис. 1 приведена структура пакета:

Весь набор классов основывается на низкоуровневом API com.adventnet.snmp.snmp2. В пакете реализованы все основные функции протокола SNMP (получение данных от агента, установка ловушек и т.д.), а также вводятся описания переменных SNMP в терминах языка ASN.1 (такие как SnmpOID, SnmpInteger и др.). Использовать это низкоуровневое API для написания собственных программ рекомендуется в случаях построения приложений реального времени, которые ограничены временем реакции на внешнее воздействие и размерами программного кода.

Пакет com.adventnet.snmp.mibs обеспечивает поддержку работы Java программ с файлами MIB. Пакет используется для получения информации о структурной организации файла MIB, а также поддерживаемых переменных SNMP агентом.

Пакет com.adventnet.snmp.beans состоит из компонентов AdventNet SNMP Java Beans, которые могут быть импортированы в любую интегрированную среду разработки Java приложений. По утверждению производителей, использование этого пакета является самым простым способом создания управляющих приложений и апплетов.

Пакет com.adventnet.snmp.ui поддерживает множество полезных функций необходимых для построения управляющих GUI приложений. Этот пакет был разработан при помощи swing компонентов, а в некоторых случаях он напрямую расширяет классы swing.

Пакет com.adventnet.snmp.rmi обеспечивает поддержку такой Java технологии как удаленный вызов процедур (RMI), что позволяет создавать распределенные и серверные Java приложения для выполнения SNMP-запросов. В данном случае вся тяжесть работы с SNMP агентами ложиться на серверную часть приложения. К примеру, серверное приложение может быть запущено на Web-сервере, в то время как апплеты выполняют только RMI запросы на выполнение SNMP операций. Серверная часть также может загружать файлы MIB, а все клиенты будут иметь доступ к этой информации без необходимости постоянной загрузки этих файлов. Нужно также отметить, что RMI API построен на основе пакета com.adventnet.snmp.beans.

Пакет com.adventnet.snmp.corba обеспечивает CORBA доступ к SNMP API. Подобно RMI, CORBA API позволяет удаленному клиенту запрашивать сервер на выполнение SNMP операций и получать от него ответы.

Отдельно нужно отметить наличие такого пакета как com.adventnet.snmp.sas, который позволяет обходить ограничения безопасности, накладываемые на апплеты (в частности, запрет связываться только с тем сервером, с которого он был загружен). SNMP Applet Server (SAS) позволяет апплету принимать и отправлять SNMP пакеты любому управляемому устройству. Однако при этом необходимо, чтобы SAServer был запущен там же где и Web-сервер, на котором находятся апплеты.

Простой протокол управления сетью (Simple Network Management Protocol, SNMP) был разработан для управления сетями поддерживающих стек протоколов ТСРЛР и создавался как протокол без установления соединения с целью обеспечения управления на пользовательском уровне Он позволяет вести наблюдение загрузки отдельных сегментов сети пакетами UDP, TCP, IСМР, регистрируя количество ошибок по каждому из активных интерфейсов.

Протокол удаленного мониторинга сети (Remote Network Monitoring, RMON) спроектирован для наблюдения за сетью в целом. Он определен в документе RFC 1757, выпущенном в феврале 1995 года, дополняющим RFC 1271. Инфраструктура RMON опирается на клиент-серверную архитектуру. При этом в роли "клиента" выступает приложение, выполняемое на управляющей станции, а в роли "сервера" - устройства мониторинга, распределенные по сети и занятые сбором информации. Сбор информации осуществляется аппаратно-программными агентами, данные от которых поступают на управляющий компьютер.

Вся управляющая информация для контроля активного сетевого оборудования содержится в базе управляющей информации (Management Information Base, МIВ), которая используется управляющей станцией и представляет собой перечни и согласованные описания объектов данных, поддерживаемых конкретным устройством. Переменные в базе классифицированы по тематике, при этом каждое поддерево содержит определенную тематическую подгруппу переменных.

Средства работы с сетями

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

SunNet Manager использует объектно-ориентированный подход к представлению вычислительной сети. Каждый компонент сети характеризуется текущим состоянием и выполняемыми функциями. Управляемые объекты могут быть различными - от сетевых интерфейсов до серверов. Более того, пользователь при необходимости может сам описать новый объект и добавить его к числу управляемых. Традиционным достоинством SunNet Manager считается заложенная в его архитектуре программная независимость от используемого стека протоколов, а также возможность организации распределенного управления сетью. В этом случае вся тяжесть управления ложится на машины, на которых запущены специальные агенты-посредники. Каждая из таких вычислительных систем контролирует свою группу объектов посылая диспетчеру лишь необходимую информацию, разгружая центральную управляющую станцию и снимая ограничения на количество управляемых объектов.

DECmcc Director - система управления сетью, в которой реализована модель управления, разработанная компанией DЕС. Ядро менеджера - объектно-ориентированный прикладной программный интерфейс, основанный на удаленном вызове процедур. В состав DECmcc Director входят следующие компоненты: прикладной программный интерфейс, основные средства управления, пользовательский интерфейс и общая структура управляющей информации. Конструктивно он состоит из пяти основных элементов: исполнительная часть; хранилище управляющей информации (объектно-ориентированная база данных, в которой хранится информация об устройствах, действиях администратора, и состояниях сети); функциональный модуль (реализует специфические приложения для конфигурирования и обработки ошибок); модуль представлений (модуль при помощи информации, полученной из базы данных определяет, какие атрибуты и команды соответствуют выбранному объекту и предоставляет возможность управления объектом); модуль доступа (обеспечивает доступ к типовым элементам сети: маршрутизаторам, модемам, мостам и не сетевым элементам, таким как сетевые операционные системы, приложения, и базы данных). Главным недостатком этой системы управления можно считать отсутствие возможности добавления собственных подпрограмм и функциональных модулей; а также невозможность создания распределенной системы управления.

Ссылки на использованные источники

1. J. Case, M. Fedor, M. Schoffstall, J. Davin A Simple Network Management Protocol (SNMP). Request for Comments 1157, SNMP Research Inc., May 1990.

2.Штайнеке С. Управление приходит в Web // LAN/Журнал сетевых решений. -1997. -№12 стр.105-109

3.Применение технологии JAVA для мониторинга сетевых устройств через протоколы SNMP / В.В. Коноплев, М.Ю. Захаров, Р.Р. Назиров. -М.: Ин-т косм. исслед. РАН, 1999. - 20 с.: ил.

4. http://alphaworks.ibm.com/tech/webbin/

5. http://www.westhawk.co.uk/resources/

6. http://www.adventnet.com/products/snmp/


Юрий Чашков (chashkov@mail.ru)
старший преподаватель, аспирант
Московского института электроники и математики (МИЭМ).





  
5 '2002
СОДЕРЖАНИЕ

бизнес

• Управление проектами как новая философия бизнеса

• Информационные услуги - новое направление развития "Электросвязи"

локальные сети

• Коаксиальный кабель: что скрывается за видеосигналом?

• Внешняя коммуникационная кабельная инфраструктура предприятия и ее заземление

• Эволюция технологий расширения компьютеров и соединения их компонентов

• Переключатели KVM - центральные пункты управления

корпоративные сети

• Серверы дискуссий открывают возможности сотрудничества в Web

• Технология ESI снижает расходы и повышает производительность

системы учрежденческой связи

• DECT и Закон

услуги сетей связи

• Технология PLC - телекоммуникации по сетям электропитания

• Тестируем инструменты мониторинга производительности сети

• Оптические иллюзии и реалии

• Проблемы передачи данных в сетях мобильной связи

защита данных

• ИБП от мала до велика

• FireProof защитит от DoS-атак

новые продукты

• DCS "входит" в Интернет; OptiX 155/622H - мал, да удал; Новые "дети" Allied Telesyn; Новая серия ИБП NeuHaus; Система беспроводного доступа от INTRACOM S.A.; IP-видеотелефон BVP 8770 - привлекателен и доступен

только на сервере

• Volkswagen развивает собственную виртуальную биржу

• Поддержка протокола SNMP в JAVA-приложениях


• Калейдоскоп



 Copyright © 1997-2005 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх