Управление сетями приходит в Web

Java и протоколы Web способны изменить роль управления сетью и системами.

Компоненты управления сетью и системами собирают невероятный объем данных - излишне много данных. Однако проблемы определения и структурирования таких данных по большей части решены. SNMP MIB-2, RMON MIB, DMI, MIF, а также принятая недавно общая информационная модель (Common Information Model, CIM) применяются повсеместно в качестве базиса для определения соответствующих элементов информации и оснащения аппаратного и программного обеспечения средствами сбора информации.

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

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

Транспорт SNMP имеет предложение Trap, с помощью которого агент может инициировать сеанс со станцией управления. Правильное использование прерываний позволяет свести необходимость в опросах к минимуму, и во многих областях разработки приложений модель событийно-управляемых приложений занимает место модели опроса. Проблема с прерываниями SNMP в том, что никаким способом они не могут быть подтверждены. Например, в ответ на превышение некоторого порога агент отправляет прерывание. Получила ли его станция управления? Должен ли агент повторить прерывание? Никто не знает.

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

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

РЕШЕНИЯ ОТ WEB

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

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

Архитектурным уровнем, благодаря которому приложения могут функционировать, является станция управления, имеющая средства для связи с агентами управления, а также для обработки и хранения информации. Консоли основных платформ управления, таких как HP OpenView, Cabletron SPECTRUM, IBM TME NetView и Sun Solstice, представляют собой отличные примеры станций управления. Эти платформы служат в качестве инструментария разработки для разработчиков приложений, предоставляя общую карту сети, централизованную обработку и протоколирование событий, а также встроенную базу данных. На практике различие между приложениями и станциями управления может оказаться размыто: все производители платформ управления включают те или иные приложения вместе со своим базовым пакетом, а разработчики приложений далеко не всегда используют стандартные средства, предоставляемые платформой.

Транспортный уровень обеспечивает передачу данных от агентов управления к станции управления. В большинстве случаев транспорт по основному каналу (т. е. транспорт по управляемой сети) осуществляется с помощью протокола SNMP по UDP. ManageWise компании Novell и некоторые другие приложения могут использовать IPX в качестве транспорта для SNMP, а отдельные приложения управления Apple - AppleTalk. Приложения управления на базе DMI могут взаимодействовать с удаленными устройствами с помощью механизма вызова удаленных процедур, являющегося частью большинства современных настольных сетевых ОС.

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

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

ПЕРЕСТРОЙКА УПРАВЛЕНИЯ

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

Например, вы можете использовать приложение с интерфейсом командной строки, при использовании которого терминал или ПК с программой эмуляции терминала подключается к последовательному порту. Такой подход позволяет настроить устройство при недоступности сети. Оно необходимо также, если устройство поставляется без преконфигурированного IP-адреса либо поддержки BOOTP или DHCP: невозможно говорить на языке IP с кем-либо, кто его не понимает. Это может быть исключительно символьный интерфейс на базе форм, во многом схожий с экранами традиционных приложений для мэйнфреймов, в которых область экрана заполняется данными вместо прокрутки линий в ответ на ввод команд.

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

Затем это может быть приложение Windows или Macintosh, взаимодействующее непосредственно с устройством, возможно, с помощью SNMP, или DMI, или собственного API. В отличие от эмуляции терминала или telnet, оба из которых платформенно-независимы, данные приложения предусматривают установку клиентского программного обеспечения, выполняющего строго определенную задачу в системе, используемой для мониторинга или конфигурации устройства. Несмотря на этот недостаток, многие производители считают необходимым иметь приложения управления с графическим интерфейсом в силу конкурентных соображений и ввиду быстрого уменьшения числа администраторов, которым символьный интерфейс был бы по нраву.

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

РОЛЬ HTML

Чтобы понять роль, которую технологии Web могут играть в этой области, давайте рассмотрим, какие функции выполняет HTML. Прежде всего, HTML делает то же, что и программа эмуляции терминала. Эмулятор терминала, или телетайп, если уж на то пошло, использует тот или иной управляющий символ в потоке текста для изменения режима принимающего устройства - экрана дисплея или принтера - и подает ему команды. Типичные команды "заставляют последующие символы мигать", "переходить в точку с координатами X, Y" и т. д. Теги HTML во многом аналогичны управляющим последовательностям эмуляции терминала.

Конечно, HTML не ограничивается символьными управляющими последовательностями. Он имеет систему для работы с разного рода двоичными файлами и потоками. Клиент HTML - обычно, но не обязательно браузер Web - может позиционировать графические изображения на экране, форматировать текст с помощью различных шрифтов и стилей и, при наличии соответствующей поддержки, вызывать вспомогательное программное обеспечение для воспроизведения аудио- и видеопотоков или передачи файлов. По сути клиенты HTML заимствуют систему классификации информации у протокола MIME и использует ее для идентификации вспомогательных программ, работающих с соответствующими типами данных. Для идентификации и контроля данных и потоков во всемирной объединенной сети были изобретены универсальные локаторы ресурсов (Universal Resource Locator, URL). Благодаря URL текст становится гипертекстом. URL позволяют не только использовать любые изображения, тексты или данные для ваших собственных страниц (технически, если не законно), но также переходить на любую другую страницу в мире HTTP.

Наконец, клиент HTML знает, как обращаться с наиболее гибким видом двоичных данных - исполняемым кодом. Если клиент HTML имеет виртуальную машину Java (Java Virtual Machine, JVM), то он может безбоязненно выполнять программу на Java: наличие JVM гарантирует, что программа не несет никакого вреда клиенту. Клиенты на базе Windows (и, по всей видимости, другие со временем) могут выполнять программы ActiveX, а те, в свою очередь, осуществлять любые действия, поддерживаемые ОС, - без свойственных Java ограничений, определяемых требованиями защиты.

Вторая фундаментальная технология Web - это HTTP. В отличие от SNMP, HTTP базируется на TCP. TCP устанавливает сквозное соединение между двумя узлами и гарантирует подтверждение получения каждого пакета. Благодаря тому, что TCP обеспечивает контроль над всем соединением, пакеты можно идентифицировать и шифровать на транспортном уровне. Secure Sockets Layer (SSL) позволяет защитить любые приложения, такие как ftp или telnet, а не только HTTP. Благодаря вспомогательным сервисам TCP, HTTP позволяет также решать вопросы защиты на прикладном уровне, точнее говоря, этим занимается Secure HTTP (S/HTTP). Таким образом, если бы потоки управляющих данных передавались по HTTP, то вопросы защиты SNMP исчезли бы сами собой.

Как общепризнанный стандарт Internet, HTTP реализован практически во всех операционных системах. Если клиент может отправлять запросы и ответы HTTP, принимать отклики HTTP, отображать или иным образом представлять страницы HTML, выполнять приложения Java и, возможно, ActiveX, то он может предоставлять данные с серверов Web, расположенных в любом месте, где есть Internet. Таким образом, общедоступный клиент (как правило, реализованный на всех программных платформах браузер Web) может заменить часть клиентского программного обеспечения, традиционно используемого для целей управления. Встроенный сервер HTTP позволяет конфигурировать и следить за состоянием устройства с помощью браузера. Кроме того, расположенные в стратегических местах продукты способны конвертировать сообщения HTTP в сообщения SNMP и обратно, что открывает новые возможности для распределения обязанностей в сфере управления без помощи широкомасштабной платформы управления.

СТАТИСТИКА В WEB

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

У многих ведущих производителей продуктов для управления сетями есть соответствующие предложения по поддержке удаленной генерации отчетов с помощью браузеров Web. Netscout Systems (ранее Frontier Software) предлагает WebCast для своих приложений на базе RMON. Concord Communications имеет WebLink для своей линии приложений подготовки отчетов о рабочих характеристиках сети Network Health. Network General предлагает возможность просматривать отчеты своего менеджера уровня сервиса через Web. Платформы HP OpenView с OVwww и Cabletron SPECTRUM с WebApps поддерживают отчеты на базе Web. По сути Optivity Web компании Bay Networks является пакетом подготовки статистических отчетов.

Некоторые из этих продуктов просто вставляют теги HTML в имеющиеся отчеты и помещают их в соответствующий каталог. При несколько более сложном подходе страницы HTML создаются на лету на основании хранящейся в базе данных информации с помощью CGI, Netscape API (NSAPI), Information Server API (ISAPI) или специфического для базы данных инструментария (возможно, в ответ на конкретный запрос или при указании тех или иных параметров). Дальнейшее небольшое улучшение достигается посредством загрузки апплетов в браузер с сервера; эти апплеты используются, как правило, для отображения статистики управляющей информации в графическом виде в реальном времени. Типичная транзакция HTTP приводит к однократному обновлению страницы; в случае отсутствия апплетов пользователь был бы вынужден постоянно обновлять экран браузера для наблюдения за изменением значений параметров. Эти загружаемые программки автоматически опрашивают сервер, поддерживая текущее соединение, что HTTP не может обеспечить сам по себе.

Другой очевидный шаг, который производители могут сделать, - это встроить поддержку HTTP и HTML в устройства и приложения. При такой поддержке браузер может дополнить либо заменить некоторые или все интерфейсы консолей, предоставляемые в настоящее время производителями для начальной настройки, текущей конфигурации и простого мониторинга. Например, приложения на базе браузера ClickStart компании Cisco Systems работают с ISDN-маршрутизаторами 1003 и 1004, поставляемыми со встроенными серверами Web. Маршрутизатор можно подключить к сети Ethernet и линии ISDN и сконфигурировать его с помощью браузера Web, расположенного в любом месте сегмента сети.

Несколько иная модель реализована в Java Based Pipeline Configurator (JBPC) компании Ascend Communications, предоставляющей графический интерфейс, способный заменить инструментарий компании для конфигурации маршрутизатора на базе эмуляции терминала или telnet. JBPC использует пакетную загрузку для отправки команд агенту SNMP в устройстве и сбора текущей информации о конфигурации. Генерация файлов HTML происходит на клиенте, так что HTTP не задействуется. В скобках отметим, что возможности защиты HTTP действуют только во время сеансов HTTP, поэтому устройства, общающиеся по SNMP с браузером Web, конвертирующем информацию из SNMP в HTML для ее отображения, не более защищены, чем обычная архитектура SNMP.

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

ПРИМЕНЕНИЕ ШЛЮЗА

Один из новых способов, с помощью которого приложения управления могут работать с Web, состоит в создании шлюза между SNMP и HTML на сервере, причем этот сервер может не совпадать с консолью управления и другими серверами Web. Примером реализации такого подхода служит Resource Manager компании Cisco. Он следит за доступностью, производит опись межсетевых устройств Cisco, а также MIB-2-совместимых устройств, отслеживает версии программного обеспечения IOS и анализирует сообщения системного журнала. Пользователи с соответствующими полномочиями могут просматривать отчеты обо всех устройствах SNMP в своем домене - однако они не могут изменить конфигурацию. Resource Manager позволяет также автоматизировать поиск, выбор и развертывание нового программного обеспечения маршрутизаторов и коммутаторов от Cisco Connection Online - источника заплаток, обновлений и ресурсов технической поддержки компании Cisco. В настоящее время Resource Manager работает на сервере Sun Solaris; Cisco планирует выпустить версию на базе Windows NT. Браузеры, поддерживающие Java и JavaScript, в том числе Netscape Naviga-tor 3.0 и Internet Explorer 3.01, работают с Resource Manager.

Intraspection от Asante Technologies использует архитектурный подход, сходный с применяемым Cisco, но подход Asante гораздо более амбициозен. Intraspection - это шлюз между SNMP и HTML на базе сервера, снабженный апплетами Java для обновления статистических данных в реальном времени. Сервер Intraspection общается по SNMP с устройствами MIB-2, а также с расширениями MIB для Standard Bridge, Standard Repeater и Ethernet-like Interface. Более того, Asante предоставляет комплект разработчика программного обеспечения, с помощью которого другие производители могут писать Personality Modules; эти программы выводят на экран точные графические изображения устройств конкретного производителя и поддерживают специфические для данного производителя расширения MIB. Из браузера пользователи могут выполнять команды SNMP Set и Get - т. е. могут изменять конфигурацию, а также следить за статистикой. Intraspection может даже получать прерывания SNMP и помещать их в базу данных ODBC. Кроме того, он способен автоматически обнаруживать устройства в сети.

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

Еще один шлюз между SNMP и HTML предлагается подразделением по сетевым периферийным решениям компании Hewlett-Packard - именно оно разработало JetAdmin для сетевых принтеров HP. Web JetAdmin 3.0 поставляется в виде демона HTTP вместе с программным обеспечением Web JetAdmin, так что отдельный сервер Web для взаимодействия с клиентами на базе Web не нужен. Программное обеспечение сервера Web JetAdmin для Sun Solaris, HP-UX, OS/2 Warp и Windows NT взаимодействует с HP и другими Printer MIB-совместимыми принтерами по SNMP; пользователи общаются с сервером при помощи браузеров Web. С помощью новой версии администраторы могут устанавливать и конфигурировать сетевые принтеры, а также следить за сбойными ситуациями и статусом. Благодаря новым усовершенствованиям на базе Java браузер может иллюстрировать такие состояния в виде открытых ящиков с бумагой.

БУДУЩЕЕ УПРАВЛЕНИЯ НА БАЗЕ WEB

Технология на базе Web приобрела огромное значение в том, что касается предоставления соответствующей управляющей информации широкой аудитории. Разработки на базе браузеров для конфигурации отдельных устройств будут, несомненно, продолжать появляться, но в настоящее время преимущество этих инструментов по сравнению с традиционными подходами, с точки зрения пользователя, не столь существенно. Применение встроенных серверов Web и транслирующих шлюзов имеет, по всей видимости, огромный потенциал для улучшения управления вообще. Протокол HTTP далеко не идеален и нуждается в усовершенствовании, но HTTP и его последователи могут сыграть важную роль в деле защиты управления, тем самым ликвидируя важнейший недостаток приложений управления. Рабочая группа по управлению настольными системами DMTF уже одобрила версию 1.0 для CIM, определяющую схему для объектов управления, включающую SNMP MIB, DMI MIF и CMIP MIB.

Технологии на базе Web повернули управление сетями и системами с проторенной колеи, так что мы можем надеяться на появление автоматизированных самовосстанавливающихся сетей с большим основанием, чем до появления HTML, HTTP и Java.