Владеть или управлять?

Корпоративными сетями невозможно полноценно управлять без помощи распределенной системы управления. Какой подход более эффективен: закрытый или открытый?

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

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

Все крупнейшие производители систем управления сетями, Hewlett-Packard, Cabletron, Computer Associates, SunSoft, IBM, примерно 3-5 лет назад анонсировали выпуск нового поколения своих продуктов в области управления сетями (масштаба Network Management или Enterprise Management). Все эти годы они "кормили" потенциальных покупателей описаниями будущих достоинств своих детищ. И вот к 1996 году на рынке появились Spectrum Enterprise Manager 4.0, Network Node Management 4.1 (Tornado 2), Solstice Enterprise Manager, Unicenter TNG, TME 10 NetView.

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

Мы не будем говорить о том, что в каждом конкретном случае эти свойства реализованы на основе разных архитектурных принципов, а также о том, что подпитываемые обещаниями ожидания во многом не оправдались (по крайней мере на начальном этапе эксплуатации новых продуктов). Это все предмет другого разговора. Мы обратим внимание лишь на одну особенность. Среди упомянутых продуктов лишь Spectrum Enterprise Manager обладает большинством вышеперечисленных свойств уже давно (начиная с версии 3.0). Остальные компании, не успев выпустить свои новые версии, во многом сырые и несовершенные, заговорили о новом поколении систем управления. Что это? Революционная идеология, отметающая предшествующую? Или новое направление продуктов, предназначенное для иных целей и развиваемое параллельно предыдущему? Или же просто маркетинговый прием?

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

ОТ РАСПРЕДЕЛЕННОСТИ СЕРВЕРОВ К РАСПРЕДЕЛЕННОСТИ СЕРВИСОВ

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

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

Идеология и архитектура современных платформ претендуют именно на такой уровень функциональности, поскольку зависимость от производителя в условиях отсутствия стандартов стала сейчас намного более жесткой и критичной. Однако пока претензии того или иного производителя на утверждение стандарта де факто очередной версией своего продукта - не более чем маркетинговый прием. И дело тут хотя бы в том, что принятие подобного стандарта, даже де факто, окажет существенное влияние на принятие других стандартов, связанных с частными аспектами архитектуры систем управления, например CORBA (Common Object Request Broker Architecture), DMI (Desktop Management Initiative), WBEM (Web-Based Enterprise Management) и проч. А в каждой из этих областей работы еще непочатый край.

Что можно ожидать в ближайшем будущем? Каковы перспективы обхода вышеупомянутых сложностей? Маятник качнулся в одну сторону - усложнение продуктов и технологий. Нам кажется, что многое можно понять из анализа конкретных примеров. В качестве отправной точки нашей дискуссии мы выбрали два источника.

1. Обзор перспектив развития Spectrum Enterprise Manager, сделанный в апреле 1997 г. на европейской конференции Cabletron Systems и разработчиков модулей управления и приложений на базе платформы Spectrum Enterprise Manager.

2. Некоторые идеологические аспекты стандарта HyperMedia Management, над разработкой которого трудится комитет, включающий представителей компаний Hewlett-Packard, Computer Associates, SunSoft, IBM/Tivoli, Novell, Intel, Microsoft.

Здесь мы ни в коей мере не претендуем ни на полный обзор будущих функций Spectrum Enterprise Manager, ни на описание новой идеологии управления, разрабатываемой вышеупомянутым конгломератом компаний. Мы лишь попытаемся пролить свет на интересующую нас проблему путем рассмотрения некоторых отдельных ее аспектов.

Начнем со второго из наших примеров (HyperMedia Management). Здесь разработана идеология, архитектура, спецификации, и даже предоставляется инструментарий для написания приложений.

Продукт на базе объектно-ориентированного программирования с участием Microsoft, естественно, ориентируется на опыт и технологии этой компании (что не следует упускать из вида, поскольку для его описания используется "нейтральная" терминология).

Основные идеи.

1. Распределенная система сервисов управления, организованная по трехуровневому принципу: менеджер менеджеров - менеджер - агент.

2. Широкий набор клиентских компонентов, создаваемый с помощью языка вызова интерфейсов серверных компонентов.

3. Собственный протокол для организации взаимодействия всех вышеупомянутых компонентов.

4. Инструментарий для гибкого и широкомасштабного моделирования объектов управления.

5. Собственная система защиты информации.

6. Регламентация взаимодействия с транспортными протоколами.

Какие же базовые технические решения предполагается использовать для реализации этих идей? Приведем несколько примеров.

Что касается взаимодействия с протоколами управления типа SNMP, CMIP и т. д., то это проблема конструирования специальных серверов, с помощью которых в рамках HMMP атрибутам экземпляра объекта ставится в соответствие численное значение того или иного параметра физического устройства. Т. е. то, каким образом из MIB SNMP управляемого устройства извлекается запись и используется в системе моделирования, зависит от сервера, предоставляющего данную запись.

Однако пока речь идет не о реальной системе, а о проекте архитектуры такой системы.

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

Клиент-серверная архитектура платформы базируется на двух компонентах: SpectroGRAPH и SpectroSERVER. Распределенность достигается путем организации единой системы данных на некотором множестве серверов, зоны действия которых (множества устройств, агенты которых управляются сервером) охватывают управляемое множество объектов.

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

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

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

1. специализация серверных компонентов, т. е. каждая базовая функциональная возможность или некоторое их подмножество обслуживается своим типом сервера;

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

3. унификация транспорта между серверными и клиентскими компонентами;

4. стандартизация и унификация графического интерфейса клиентских компонентов.

Какие же базовые технические решения предполагается использовать для реализации этих идей? Приведем несколько примеров.

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

НЕКОТОРЫЕ ВЫВОДЫ

С самого начала оговоримся, что ни о каком сравнении продуктов речи быть не может, хотя бы потому, что, во-первых, WBEM представляет собой не платформу управления, а проект архитектуры такой платформы и, во-вторых, SPECTRUM - не платформа управления на базе Web. Мы анализируем перспективы двух архитектурных решений, призванных в ближайшем будущем решать очень сходные задачи.

Таким образом, направление, выбранное Cabletron Systems, - это постепенное наращивание мощности платформы управления (без всяких скачков) на пути, заранее предусмотренном в архитектуре платформы. Преимущества здесь очевидны: постепенно обучается и приучается к технологии рынок, растет уровень разработчиков, накапливается опыт тестирования и проч.

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

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

Рассмотрим ситуацию, когда подразделения предприятия, для которого строится система управления (Enterprise Management System), разнесены в пространстве, а коммуникации, их соединяющие, предприятию не принадлежат. В этом случае оба приведенных здесь примера особенно близки по функционированию. Программные продукты, реализующие клиентские и серверные компоненты WBEM, также потребуют затрат на рабочие станции и управленческий трафик, как и компоненты будущего SPECTRUM. Эти компоненты будут включать библиотеку типов моделей и инструментарий настройки системы управления. Что касается уровня агрегирования представлений управляемой системы или легкости использования инструментария настройки, то сейчас нет никаких данных для их прогнозирования, но вряд ли они будут существенно отличаться. Самое главное, что стремление сделать управление более простым натыкается на непреодолимую преграду. Ведь в конечном итоге задача управления сначала решается абстрактно в виде выбора объектов управления и задания целей управления с последующей конкретизацией основных принципов или правил (management polices). Соблюдение этих принципов первично и при оперативной работе с системой как на этапе настройки, так и в режиме повседневной эксплуатации. Достаточно заметить, что методы моделирования и организации отображения модели на экране пользователя базируются на упомянутых принципах.

Как реализуется распределенное управление сейчас на самых мощных платформах управления? Пусть администратор имеет самые широкие полномочия на всю систему. В имеющихся инсталляциях множество серверов либо невелико (до нескольких десятков), либо "регулярно" устроено, т. е. состоит из однотипных фрагментов. Т. е. можно считать, что администратор знает место нахождения всех серверных компонентов, их зоны опроса и множества моделируемых объектов. Например, в SPECTRUM на консоли клиента можно получить со всех серверов несвязное множество иерархически организованных сколь угодно сложных моделей, отображающих фрагменты управляемого объекта (т. н. Landscapes), например соответствующие организационным подразделениям или географически разнесенным частям предприятия (см. Рисунок 1).

Эти "ландшафты" в свою очередь сами являются моделями объектов и обновляются с заданной регулярностью.

Что касается систем архивирования и рассылки информации о событиях в сети (к примеру, предупредительных сообщений), то здесь распределенность на уровне баз данных реализуется автоматически. Клиент может быть настроен на фиксированное множество типов событий, и ему незачем знать, какие серверы собирают информацию с моделируемых объектов, связанных с тем или иным событием.

В Solstice Enterprise Manager имеется база типов данных (Meta Data Repository, MDR) для хранения типов моделей управляемых объектов и дерево управляющей информации (Management Information Tree) для организации доступа ко всей информации на сервере Management Information Server (MIS). Распределенность в Solstice Enterprise Manager обеспечивается путем формирования по принципу файловой системы NFS одной MIS на основе другой. Таким образом, в принципе администратор может создать виртуальное дерево MIT, ветвями которого являются реальные MIT распределенных серверов системы (см. Рисунок 2). Это дает целостный взгляд на всю сеть любому клиенту (но пока нет такого же механизма генерации отчетов). Использование принципа NFS означает, что между БД серверов взаимодействие осуществляется на уровне операций с файлами.

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

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

Однако само понятие "построение" изменится. Визуализация, например, модели сети на клиентском месте - это упорядочение точек входа в совокупность клиентских компонентов процедур, серверные части которых находятся на одном или нескольких серверах. Реальные данные о составляющих модели (атрибуты моделей и их значения) лежат на сервере и там же независимо от пользователя обрабатываются как единое целое в рамках принятой методики моделирования. В случае SPECTRUM при этом возможно наличие "физических" (а не виртуальных!) специализированных серверов сервисов (а не серверов данных!) для работы с этим "единым целым". В случае же WBEM возникает иерархия рroxy-серверов.

Кроме того, распределенность только тогда станет реальной, когда не будет узких мест в каналах передачи сети, обслуживающей систему управления. А это значит, что, например, сервер сервисов моделирования в SPECTRUM или некоторый тип HyperMedia Object Manager верхнего уровня иерархии будет содержать инструкцию в виде набора пространственных и временных транзакций с распределенными в сети данными о моделях.

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

Гарантия сопряжения различных удаленных частей системы управления (даже проектируемых и настраиваемых раздельно) - одно из основных преимуществ полностью распределенной системы управления. И хотя в случае WBEM эта гарантия выглядит абсолютно естественно, нет никаких оснований видеть в ней слабое место SPECTRUM, тем более что бурно развивающаяся технология CORBA предоставляет и внедряет в практику все новые и новые возможности в этом направлении.

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

Т. е. SPECTRUM в ближайшем будущем (а WBEM по самой сути своей с самого начала) окажется в ситуации, когда продается не только программный продукт, но и коммуникационные услуги и аппаратная поддержка части системы управления.

Обратим внимание на то, что в обоих примерах упор сделан именно на ядро системы для облегчения создания третьими фирмами модулей управления и максимального использования заложенной в систему "интеллектуальности". Это путь, по которому в отличие от SunSoft или Hewlett-Packard пошла несколько лет назад при создании своей системы управления Cabletron.

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