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

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

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

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

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


Rambler's Top100

  

Хвала Общей информационной модели

Брюс Бордман

Год назад нас горячо пытались убедить в том, что мир вступает в эру Web-конфигурирования, Web-платформ сетевого управления и даже Web-тостеров, а лидирующая роль здесь принадлежит продукту WBEM (Web-Based Enterprise Management). Это стандарт, предложенный корпорацией Microsoft в качестве универсального средства сетевого и системного управления.

Однако новый стандарт встретил, мягко говоря, настороженный прием. За пределами Редмонда он почти не имеет поддержки. Корпорации Hewlett-Packard и IBM по-прежнему успешно продают свои платформы управления большими сетями и системами. Другие же производители начинают поставлять средства управления, основанные на Web-технологиях, но это их собственные разработки. Горькая правда заключается в том, что в большинстве случаев эти продукты являются лишь заменой telnet. Неудивительно, что желание Microsoft представить Web-технологию как новую парадигму сетевого управления не находило отклика: WBEM — это еще далеко не средство управления.

И вот в данной ситуации делается новая попытка разработать стандарт под эгидой Рабочей группы по проблемам управления настольными системами (Desktop Management Task Force — DMTF). Ведущие производители компьютерной индустрии, включая Cisco Systems, Compaq Computer, Hewlett-Packard, IBM, Intel, Microsoft, Novell и Sun Microsystems, собрались, чтобы совместно определить архитектуру управления всем, что относится к сети. И здесь ими сделана ставка на DMTF. (Именно названная группа круто изменила нашу жизнь, разработав спецификацию DMI — Desktop Management Interface.) А поводом для этого была работа, проделанная DMTF по созданию WBEM в прошлом году.

Надо заметить, что в настоящее время в результате естественного развития протокола HMMP (Hyper Media Management Prоtocol) WBEM трансформировался в CIM (Common Information Model). Подробно об истории развития HMMP вы можете узнать по адресу: wbem.freerange.com или www.asia.microsoft.com/ management.

Что такое CIM?

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

Архитектура CIM призвана обеспечить сквозное управление бизнес-приложениями и при этом защитить уже инсталлированную базу протоколов SNMP, DMI, CMIP (Common Management Information Protocol) и собственных средств, созданных на предприятиях. Чтобы достигнуть всеобъемлющего управления, в CIM определены способы подключения управляемых объектов к сети и к вычислительным системам, их место по отношению к остальным объектам. Например, для управляемого приложения в архитектуре клиент—сервер будут контролироваться не только его версия и рабочая среда данной настольной системы, но и его расположение в сети, а также и все необходимые ресурсы серверной части приложения.

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

Один из декларируемых принципов разработки архитектуры CIM — обратная совместимость с существующей системой стандартов CMIP, DMI и SNMP. Для производителей сетевого оборудования, имеющих глубокие проработки в SNMP, сохранение этого стандарта является приоритетным. Группа DMTF очень внимательно следит за тем, чтобы протокол SNMP версий 1 и 2 и следующая его версия 3 не были проигнорированы в архитектуре CIM. При том что CIM в самом деле перекрывает область спецификации SNMP, рабочая группа DMTF предполагает уже в первой версии своего стандарта отразить данные SNMP на модель CIM, возможно даже на уровне баз данных управляющей информации.

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

CIM не указывает, в каком каталоге должны быть данные, касающиеся объектов управления. Архитектура устанавливает набор правил, определяющих, как производитель может представлять объекты управления и их взаимодействие с другими объектами в единой системе. В отличие от сегодняшней организации хранения и доступа к данным в CMIP, DMI, SNMP и частных реализациях здесь не предлагается готовой схемы. Право размещения объектов остается за производителем, но делать это он должен в рамках правил, определяемых CIM. Группа объектов управления в CIM-совместимых системах может описываться в терминах их функций, взаимоотношений и взаимодействий с другими группами, описываемыми CIM.

Кроме описания семантики и синтаксиса данных, касающихся объектов управления, правила CIM определяют метод экспорта, импорта и накопления уже существующих объектов управления. Другими словами, это не просто руководство по организации обмена данными и их поддержки, а скорее набор правил, определяющих, каким образом интегрироваться с уже существующими системами хранения управляющей информации, такими, как CMIP, DMI и SNMP, как адаптировать к CIM собственные средства управления или как использовать комбинацию тех и других. Не случайно документы CIM иллюстрируются примерами из реализаций DMI и MIF (Management Information Format). Естественно, что при этом используются только CIM-совместимые реализации.

А что в ядре?

Базовая структура CIM включает в себя Модель ядра (Core Model), Общую модель (Common Model) и Схему расширения (Extension Schema). Модель ядра представляет собой ту часть информации, которая является общей для всех управляемых данных. Она разработана таким образом, что может использоваться для любых видов управления независимо от их типа или типа управляемых объектов. Общая модель — это группа схемных определений, подразделяемая на системы, приложения и устройства.

Для представления этих моделей используется два типа нотаций — UML (Unified Modeling Language) и MOF (Managed Object Format). UML является графическим формальным языком моделирования, похожим на схемы потоков (flow-chart), однако он сильно отличается от них тем, что позволяет моделировать связи, свойства, функции и иерархию отношений. В архитектуре CIM язык UML позволяет просматривать высокоуровневые связи отдельных участков схемы управления.

Более подробное, текстовое описание обеспечивает нотация MOF-грамматика для определения классов, иерархий, значений, связей, доменов и всего остального, относящегося к объектам управления. Это не интерфейс прикладного программирования и не какой-нибудь специальный язык, а скорее способ задания спецификаций в архитектуре CIM. MOF-конструкции могут быть даже прокомпилированы с целью проверки синтаксиса. Если же такая конструкция имеет конкретные данные, то компиляция позволяет проверить и ее семантику.

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

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

Для учета специфики продуктов отдельных производителей, не укладывающейся в общие принципы хранения данных и доступа к ним, определяемые Общей моделью, используется Схема расширения. Она очень напоминает Enterprise MIB Extension в SNMP, но, вместо того чтобы полностью оставить вопросы хранения и доступа на усмотрение производителя, CIM-расширения будут все же проектироваться по принципам, заданным в Модели ядра и Общей модели. Так, при разработке собственного расширения производитель коммутатора будет обязан поддерживать элементы данных Модели ядра и Общей модели и использовать синтаксис MOF. В результате, даже если приложение не «понимает» детали расширения, оно будет «знать» его место и функции в сети. Специалисты из DMTF признают, что, пока спецификации Общей модели не «созрели», в своей работе они будут ориентироваться как раз на расширения, предлагаемые производителями.

Взгляд на DEN

Изначально группой DMTF в архитектуру CIM была включена и Общая модель сети (Network Common Model), однако позже, по решению комитета по спецификации DEN (Directory Enable Networks), она была изъята. Как бы странно это ни выглядело, но большинство тех, кто участвовал в создании CIM, включая Cisco, разрабатывали также и DEN, используя те же инструменты — UML и MOF. Комитет сосредоточил усилия не только на спецификации DEN, но и на проблемах размещения данных управления и доступа к ним в локальных и распределенных сетях разного масштаба. Согласно утверждениям DMTF, этот процесс должен в итоге закончиться разработкой CIM. В версии CIM 2.1 предусмотрена интеграция DEN в Общую модель сети.

Для того чтобы архитектура CIM стала реальным стандартом, необходимо провести целый ряд разработок, это касается интерфейса прикладного программирования, единой терминологии, вопросов безопасности и единого транспортного протокола. Что касается единого «транспорта», то здесь еще многое неясно, но есть признаки того, что DMTF рассматривает возможность использования в качестве такового протокол XML (Extensible Markup Language). Таким образом, все коммуникации в CIM должны будут опираться на язык разметки XML, что, в свою очередь, обеспечит разработчиков более простыми средствами доступа в приложениях к данным CIM.

XML — это развитие ветви языка SGML (Standardized General Markup Language), который берет свое начало от языка GML, разработанного IBM для создания и редактирования документов на больших ЭВМ. Разметка языка XML должна быть определена в соответствии с требованиями CIM. Использование XML независимо от языка программирования позволит прочитать любые данные, записанные по правилам архитектуры CIM и касающиеся приложения или агента. Протокол выглядит несколько избыточным, но разработчику это дает возможность создавать свои приложения с использованием любого национального языка или собственного CIM-совместимого метода, что значительно снизит усилия по созданию различных методов доступа для приложений, разработанных с помощью технологий COM, CORBA, Java и т. п.

Будущее

Конечно, архитектура CIM пока еще довольно «сырая». Даже если учесть всю гигантскую работу, проделанную DMTF, она все еще остается общей моделью. Windows 98 обеспечит первую обкатку CIM, затем последует сервер SMS (Systems Management Server) 2.0 и, наконец, операционная система Windows NT 5.0, полностью соответствующая спецификациям CIM. Помимо Microsoft, пока единственным производителем, объявившим поставку на рынок агентов систем сетевого управления для Windows NT 5.0, является фирма EccoSystems. Платформа системного управления TME 10 NetView фирмы Tivoli Systems (подразделение IBM. — Прим. ред.) способна обнаруживать CIM-совместимые объекты. По неофициальным данным, Cisco, Compaq, IBM и Novell тоже готовятся к выпуску совместимых с CIM продуктов.

Мы протестировали раннюю бета-версию SMS 2.0 и нашли, что CIM-совместимость была заложена еще в WBEM. Используя Excel, мы организовали доступ к инвентаризационной базе данных, хранящей сведения об оборудовании рабочих мест. Это ничего не добавляет к характеристике продукта с точки зрения информативности, однако дает возможность убедиться в том, что данные CIM становятся легкодоступными.

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





  
10 '1998
СОДЕРЖАНИЕ

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

• Наперегонки со светом

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

• Недорогие серверы на базе Pentium II

• Экранировать или не экранировать?..

• Интеграция NetWare и Windows NT

• Локальная сеть - кварц или медь?

• RAID: концепция живет и развивается

• Новые программные средства закрывают брешь в управлении Windows NT

бизнес

• NT-серверы IBM вырываются вперед

• SMCC расширяет каналы сбыта

• Слияние двух надежд

интернет и интрасети

• Ingram - поставщик услуг электронной коммерции

• Лоцманы в море информации

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

• Бум пропускной способности

• Технология ATM и современные корпоративные сети

• Хвала Общей информационной модели

• Объектное расширение реляционной СУБД: зачем и как (Часть II. Как?)

• Выбираем пограничный коммутатор ATM

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

• Интернет и ТфОП: вопросы подключения маршрутизаторов к городским АТС

• Проблемы внедрения технологии DSL

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

• Средства контроля безопасности на базе протокола IP

• Резервирование в централизованных системах бесперебойного электропитания

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

• Аспекты техобслуживания цифровых УПАТС



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