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

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

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

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

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


Rambler's Top100

  

Согласье меж стандартами управления

Брюс Бордман

Поднимите руку те, кто верит, что стандарты управления помогут вам в управлении вашей сетью. Что, никого не нашлось? Так мы и думали. На словах стандарты эти выглядят замечательно, но полученные при попытках их реализации шрамы развили в нас здоровый скептицизм. Разрабатывавшиеся с самыми добрыми намерениями стандарты, типа DMI (Desktop Management Interface), SNMP и... (впишите сюда своего фаворита), так и не достигли успеха по множеству причин, не потому, что они плохие, а из-за сложности реализации положенной в их основу стратегии. Немало нашего брата “купилось” на подобные стратегии, например на базовую связующую среду (framework) или открытую архитектуру, которые так и не обрели законченную форму. Теперь же перед фирмами-производителями встала задача обеспечения гарантированного качества обслуживания (QoS - Quality of Service). И разрабатывающие стандарты группы кооперируют свои усилия не только для обеспечения этого нового требования, но и для решения проблемы сетевого управления.

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

Гарантированное качество обслуживания без головной боли

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

Пока все это лишь благие намерения. Однако рабочие группы DMTF (Distributed Management Task Force) и IETF работают сейчас над стандартами, обещающими такую технологию сетевого управления, которая бы обеспечивала сквозную совместимость разных стандартов. Комитеты WBEM (Web-Based Enterprise Management) и Policy Framework, входящие соответственно в DMTF и IETF, кооперируют свои усилия для реализации универсальной базовой связующей среды управления. Уже созданы модели данных, общие методы доступа и разбиения на группы. Цель при этом поставлена самая глобальная: управление абсолютно всем, что относится к сети!

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

WBEM

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

Так, фирма Cisco Systems размещает данные о загрузке ЦПУ иначе, чем это делает компания Nortel Networks, а структура данных Nortel, в свою очередь, отличается от той, что используется в компании Enterasys Networks. Да и отображаться такая информация может разными способами - как общим числом используемых ЦПУ (процент использования), так и общим числом доступных ЦПУ.

Группа DMTF занялась указанной проблемой в 1996 г., начав с определения значения управляющих данных. Результатом этой работы стала общая информационная модель CIM (Common Information Model). Вскоре CIM разрослась и превратилась в сложную, полномасштабную архитектуру управления WBEM, получившую широкий резонанс в прессе, потому что в работе над ней участвовали такие столпы сетевой индустрии, как BMC Software, Cisco, Compaq Computer, Computer Associates, Hewlett-Packard, IBM, Intel, Microsoft, Novell, Sun Microsystems и Tivoli Systems. А вскоре под всеобъемлющим контролем WBEM оказались и XML и DEN (Directory-Enabled Networking).

Важно понимать, что CIM представляет собой лишь общее описание, но не реализацию. Она позволяет отображать форматы CMIP (Common Management Information Protocol), COM (Component Object Model), CORBA (Common Object Request Broker Architecture), DMI, HEMS (High-Level Entity Management System), Java, SNMP на произвольный фирменный формат хранения данных. Модель CIM - это транслятор данных, позволяющий их нормализовать.

Очевидно, что единый метод доступа к CIM-данным необходим для еще большего упрощения процесса управления. Здесь свою роль должен сыграть стандарт XML. Группой DMTF был разработан метод установления соответствий между XML DTD (Document Type Definitions) и CIM. Применение этого метода не только дает возможность размечать данные структурированными дескрипторами (что является своего рода самодокументированием), но и позволяет управляющему приложению использовать новые определения CIM/XML без программирования новых API и не прибегая к другим методам сбора данных.

Разумеется, при этом в приложение нужно добавить соответствующую логику, причем только один раз, а работать она будет для всех экземпляров, с которыми это приложение может столкнуться, независимо от того, каким образом конкретный производитель создает или хранит данные. Это скорее текстовое представление, чем программа, - следовательно, основная логика приложения, собирающего и использующего данные, не потребует изменений. Сбор дополнительных данных может выполняться за пределами откомпилированного кода приложения, что обеспечит боўльшую гибкость многократного использования методов приложения.

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

Конфигурирование сети на основе правил

Инициатива DEN, входящая в состав спецификации WBEM и тесно с нею связанная, состоит под эгидой DMTF, а применяется группой IETF. В спецификации DEN определяется организация хранения CIM-совместимых данных управления на основе правил, хранимых в справочнике, доступ к которому осуществляется по протоколу LDAP. Входящая в IETF рабочая группа Policy Framework Working Group начала эту работу в 1998 г. Ее целью было создание на базе правил QoS интегрированной среды, реализующей механизм дифференцированного обслуживания DiffServ (Differentiated Services).

Члены рабочей группы Policy Framework также работают и в составе рабочей группы DMTF над спецификацией WBEM. Такое “перекрестное опыление” не является формальным, поскольку в указанных организациях не существует официального назначения на должности, хотя самая тесная координация действий сотрудников налицо.

Результатом их усилий станет, например, возможность сохранять информацию конфигурирования QoS-правил протокола DiffServ в справочнике NDS фирмы Novell. Тогда доступ к этим данным получит приложение управления на базе правил, которое со своей стороны сможет их применить в маршрутизаторах сети. Реальные механизмы и протоколы, изменяющие передачу трафика маршрутизатором (в зависимости от QoS), могут быть получены посредством интерфейса CLI, службы COPS (Common Open Policy Service) или SNMP. При этом хранение и администрирование таких данных остается в пределах справочника и доступ к ним осуществляется по протоколу LDAP, что делает их доступными и для других приложений управления, “понимающих” язык CIM. Это, в свою очередь, открывает возможности для использования данных открытого аудита и управления сетевого использования.

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

И главное здесь - обозначить четыре общие группы, или уровня, к которым могут применяться правила, - это “Домен” (Domain), “Механизм” (Mechanism), “Реализация” (Implementation Specific) и “Экземпляр” (Instance Specific).

“Домен” соотносится со специфической областью или технологией, такими, как обеспечение безопасности, гарантированное качество обслуживания или управление ресурсами. “Механизм” - уже уровнем ниже, в конкретном домене, и отражает определенную технику, например механизм WRED (Weighted Random Early Detection), входящий в домен DiffServ. “Реализация” - это расширения к стандартным механизмам, сделанные производителями. Этот уровень позволяет производителям вводить свои новшества (что очень напоминает фирменные расширения SNMP). Самый нижний уровень - “Экземпляр”. Он характеризуется параметрами, определяющими действия конкретного интерфейса.

Простая схема: SNMPConf

Протоколу SNMP не грозит, что его заменит спецификация WBEM или стандарт DiffServ - напротив, SNMP хорошо работает как механизм для конфигурирования правил, в том числе для определения и задания методов, необходимых сетевой инфраструктуре для приоритизации трафика, определения доступа, создания избыточности или установления любых других конфигураций. Входящая в IETF рабочая группа SNMPConf (SNMP Configuration) занимается развитием и расширением SNMP, с тем чтобы упростить автоматизацию упомянутых задач конфигурирования и сделать ее не зависящей от требований конкретного производителя.

А почему, собственно, SNMP? CIM - это объектно-ориентированная схема данных с классами и отношениями между ними, с гибкими и богатыми структурами данных, хотя базы данных SNMP MIB в сравнении с ней более понятны нынешним специалистам благодаря своей простоте и отсутствию отношений между объектами.

Протокол SNMP привлекателен также как способ конфигурирования, поскольку позволяет контролировать унаследованные сетевые инфраструктуры, включая ATM, Frame Relay и Token Ring, для которых рабочая группа DMTF (где заправляют фирмы-производители) никогда не удосужится создать CIM-схему: это ведь не новые, перспективные технологии, сулящие рост доходов, а значит, они окажутся в самом хвосте списков “очередников”, которым собираются уделить внимание. Прежде чем пытаться решить, что лучше - WBEM или SNMP, следует осознать, что SNMP будет продолжать работать как механизм и протокол управления сетевой инфраструктурой, который может быть использован WBEM-совместимым приложением и в то же время применяться и как самостоятельный инструмент.

Использование рабочей группой SNMPConf разработанных в рамках Policy Framework уровней абстракции создает не зависящий от производителя метод управления сетевой конфигурацией. Цель проекта состоит в том, чтобы схема управления на основе правил применялась с помощью уже существующей технологии, насколько это возможно. Указанные уровни абстракции уже использовались при определении наилучшего с практической точки зрения документа для сетевой конфигурации. В сущности, это список требований, применяющихся при оперативном конфигурировании сетевой инфраструктуры. Данное конфигурирование не зависит от знания специфики элемента управления конкретного производителя - CLI, API или MIB.

Взаимодействие между Policy Framework и SNMPConf не распространяется на протокол, используемый для реализации правил. Хотя представители рабочей группы Policy Framework отмечают, что не собираются определять такой протокол и в своем проекте использовали базы данных и DiffServ MIB и DiffServ PIB (Policy Information Base), однако для доказательства жизнеспособности своей работы Policy Framework сосредоточила усилия на протоколе COPS и на разработках рабочей группы RAP (Resource Allocation Group). Впрочем, это не означает, что протокол SNMP вовсе не будет использоваться. Так, в первоначальном проекте Policy Framework было намечено, каким образом могли бы применяться стандарты COPS, SNMP, HTTP или даже CLI.

В этой части работа SNMPConf направлена на усиление связующей базовой среды SNMP за счет управления базами данных MIB средствами языка сценариев Perl. Группа SNMPConf определяет Policy MIB, которая будет решать, каким интерфейсам конкретного сетевого устройства требуется конфигурация на основе правил, а затем применять соответствующую схему, обеспечивающую работу этого устройства по правилам. Предпочтение было отдано языку Perl (а не Си или Java) в силу его простоты, понятности и переносимости.

Работа команды SNMP PUT, которая будет выполнять изменение конфигурации устройства в соответствии с правилами, зависит от создания библиотек методов и MIB фирм-поставщиков. Чтобы доказать работоспособность этого механизма, рабочая группа SNMPConf создает базу данных методов DiffServ Policy MIB. Она должна устанавливать соответствия между Policy MIB и DiffServ MIB.

Простота этого подхода лучше всего видна на примере. Пусть Policy MIB определяет следующие булевские конструкции: Policy Filter и Policy Action, которые сначала выбирают объект применения правил, а затем применяют соответствующее правило. В этом им помогают входящие в Policy MIB новые MIB-таблицы, определяющие роли, возможности, пропускную способность и время. Например, чтобы выбрать интерфейсы, имеющие связь с Интернет, вам следует использовать следующий фильтр: [if (((type == interface) || (type == circuit)) && roleMatch(“internet”))]. Интерфейсы, отвечающие этому фильтру, могут выполнить следующее действие: свести Microsoft-трафик к нулю и тем самым предотвратить его передачу по каналам территориально распределенной сети.

Рассмотрим еще один пример: все Cisco-маршрутизаторы можно сконфигурировать так, чтобы им был задан доступ к работе с определенной версией IOS. В этом случае Policy Filter будет выглядеть следующим образом: [if ((type=system) && (strcmp(getstring(sysOID), “1.3.6.1.4.1.9”)) && roleMatch(“access”))], а возможное действие - например, так: [“set string(ciscoImageVersion.0, “12.1”)”]. Параметр roleMatch представляет собой текстовую строку, содержащую неформальную информацию. Такого рода информация делится на четыре класса: административный (политический, в частности руководящий, торговый или эксплуатационный), финансово-юридический (бесплатный, жизненно важный или демо), географический (юго-запад, третий этаж или 11-й район) и архитектурный (канал, резервная линия или магистраль). Это всего лишь текстовая строка, поступающая в БД Policy MIB конкретного устройства.

Конец истории?

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

Для реализации стандарта WBEM больше всех сделала компания Microsoft: она первой начала снабжать Windows 98 программным интерфейсом CIM-расширений, а в Windows 2000 таких расширений еще больше. Встроенный в Windows 2000 CIM-интерфейс winmgmt.exe автоматически стартует при обнаружении SMS-станцией управления. Все данные, хранящиеся в журнале событий (Event Log), реестре и PerfMon, доступны и как CIM-данные для XML-запросов. В будущем гибкость CIM-модели позволит, например, проводить опрос CIM-совместимых принтеров на предмет количества бумаги или того, какая форма находится в печати. По полученной информации может быть принято решение об отправке задания на печать на принтер, отвечающий необходимым требованиям.

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

Нас совсем не удивило признание CIM компанией Microsoft, поскольку именно она раньше всех начала популяризировать эту технологию, но мы были совершенно потрясены тем фактом, что Sun Microsystems реализовала CIM в своей ОС Solaris 8. Представители же фирмы объяснили это тем, что Sun является одним из членов - учредителей DMTF и она реализовала DMI в Solaris 8. Но мы все же не ожидали, что стандарт управления, с энтузиазмом принятый Microsoft, будет так интенсивно внедряться в продуктах Sun. Что ж, это сулит хорошее будущее кроссплатформенному управлению. ОС Solaris 8 поддерживает объекты Core, System, физические и виртуальные устройства модели CIM. По словам представителей компании Sun, в следующем выпуске ОС будет реализована и так называемая модель пользователя (User Model). Это означает, что информация о ЦПУ, памяти, IP-адресе и типе сетевого адаптера станет доступной через XML-запросы к CIM. Кроме того, Sun снабжает свою реализацию CIM специальными библиотеками, доступными из инструментария разработчика.

Компания Intel реализует CIM в своих материнских платах, а Compaq - в программе Insight Manager. С некоторых пор доступность CIM-данных обеспечили и другие компании: Cisco - в своем продукте CiscoWorks, Tivoli - в NetView, а Hewlett-Packard - в Vantage Point и ManageX.

Чего по-прежнему не хватает, так это способа корреляции данных из различных областей сетевого управления. До нас дошли слухи о продукте для управления разнородными сетевыми объектами компании Hewlett-Packard, но от ее разработчиков нам так и не удалось добиться ни слова на эту тему. Впрочем, многие фирмы-производители заявляют, что ко II кварталу 2001 г. намерены выпустить продукты, объединяющие в себе функции сетевого и системного управления.

Трудно оставаться оптимистом, пока стандарты еще находятся в стадии определения. Слишком много мы видели в прошлом проектов грандиозных стандартов, которые так и не получили практической реализации. Однако массовая тяга фирм-производителей к созданию WBEM-продуктов с учетом усилий рабочих групп Policy Framework и SNMPConf дает надежду на то, что сетевое управление ждут самые блестящие перспективы, и притом в самом недалеком будущем. Мы, как и вы, ждем этого с большим нетерпением.





  
14 '2000
СОДЕРЖАНИЕ

колонка редактора

• Когда в товарищах согласья нет

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

• Пусть ваши кабели никогда не пересекаются!

• Тестируем серверы NAS среднего уровня

• Анатомия беспроводных сетей стандарта IEEE 802.11b

• Решения на базе миниатюрных оптических разъемов - готовность № 1

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

• Магистрали света: основные идеи

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

• Совместное использование служб справочника и DHCP

• Переход на Active Directory: средства миграции

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

• LinkProof: один ISP хорошо, а два лучше; Debian - это 100% свободы; Новый NetServer для малого и среднего бизнеса

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

• Десятикратно увеличенная мощь

• Согласье меж стандартами управления

• Анализаторы и зонды для WAN-сетей

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

• Как защитить вашу территорию изнутри

• Proxy/NAT-решения для небольших офисов

электронная коммерция

• Выбирая электронную биржу, поинтересуйтесь ее владельцами

• Электронные биржи в момент кризиса

• Кому можно доверить корпоративный Web-узел?

бизнес

• OpenView Communication - шаг навстречу конвергенции

• Как дотянуться до регионов

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

• Тестируем IP-УАТС



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