Системы сетевого/системного управления: принципы создания

Михаил Федотов

 

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

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

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

Обзор задач

Сетевое управление

Напомним, что в настоящее время под собственно сетевым управлением обычно подразумевают совокупность пяти взаимосвязанных задач, в число которых входят:

Управление конфигурацией (Configuration Management), включающее:

Управление безопасностью (Security Management) подразумевает поддержку служб и отчетов обеспечения защиты информации, что предполагает:

Управление сбоями (Fault & Problem Management), в которое входит:

Учет использования ресурсов (Accounting Management) предполагает слежение за использованием и оплатой сетевых услуг, в том числе:

Управление производительностью (Performance Management) — это оценка состояния ресурсов и эффективности их использования, что предполагает:

К продуктам, в той или иной степени реализующим все пять задач сетевого управления, на сегодняшний день относятся:

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

Кроме перечисленных пяти интегрированных продуктов, существует множество решений от сравнительно небольших фирм, в которых реализованы отдельные функции, причем обычно далеко не в полном объеме. При этом продукты третьих фирм не обладают средствами интеграции друг с другом и обычно не поддерживают разработку дополнительных модулей (add-on’s) сторонними разработчиками, не имеют средств работы с внешними базами данных (Oracle, Informix, Ingres) и поддерживают ограниченный спектр сетевых устройств.

Управление распределенными приложениями

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

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

Основным подходом к решению проблемы в настоящее время является разработка MIB (Management Information Base) для приложений, что позволяет при наличии соответствующих программ-агентов работать с этими приложениями так же, как с физическими сетевыми устройствами. При этом приложения становятся SNMP-управляемыми. Подобный подход применяет, в частности, фирма Microsoft для своих DHCP- и WINS-серверов, входящих в состав операционной системы Windows NT. Недостатком данного метода является то, что фактически в этом случае возможно управление только серверной частью распределенного приложения, а учет использования сетевых ресурсов для всех компонентов системы невозможен.

Другим подходом к данной задаче является концепция Web-управления, при котором те же функции, что и в случае с SNMP, выполняются через стандартные браузеры (например, Netscape Navigator или Microsoft Internet Explorer). В таком случае, однако, приходится интегрировать в приложение, которым предполагается управлять, Web-сервер, что является достаточно нетривиальной задачей. Кроме того, отмеченные выше недостатки при этом сохраняются.

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

Мониторинг технического и программного обеспечения

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

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

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

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

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

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

Для решения поставленной задачи с учетом всей необходимой информации в настоящий момент пригодны только экспертные системы, к ведущим производителям которых относятся фирмы Gensym (продукт G2), Talarian (RTWorks), COGSYS. Данные фирмы предлагают не готовые экспертные системы для решения данной задачи, а развитые инструментарии их создания, поддерживающие как традиционные парадигмы (графический интерфейс пользователя, объектная ориентированность, управление по событиям), так и парадигмы искусственного интеллекта (продукционные правила, механизмы прямого и обратного вывода и т.п.).

Управление модернизацией

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

Некоторые функции управления модернизацией выполняют платформы системного/сетевого управления (например, уже упоминавшийся Microsoft System Management Server или CA Unicenter), поддерживающие некоторые функции централизованной установки программного обеспечения, или специализированные пакеты распространения программных средств (Seagate SoftwareInstall и ему подобные). Недостатком всех этих продуктов является то, что они работают только с ПО, не решая при этом никаких оптимизационных задач.

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

Моделирование сетей

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

Модель сети должна обеспечивать:

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

В настоящее время на рынке, насколько нам известно, не существует ни одного универсального продукта, пригодного для полномасштабного моделирования работы сети. Это связано с тем, что точное количественное моделирование сколько-нибудь сложной сети (более 100 узлов) требует огромных вычислительных затрат и при современном состоянии вычислительной техники чрезвычайно трудоемко.

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

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

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

Предлагаемое решение

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

При этом экспертная система (ЭС) является центральным звеном интегрированной среды управления. Она использует информацию из платформы сетевого управления и, в свою очередь, хранит свои данные и результаты работы во внешних СУБД типа Informix или Oracle. Кроме того, ЭС обеспечивает двухсторонний интерфейс с подсистемой точного моделирования сети. В такой конфигурации ЭС выполняет функции мониторинга текущего состояния технического и программного обеспечения, принятия решений по их модернизации и управления процессом модернизации. И, наконец, ЭС объединяет все эти функции в единой распределенной среде с общим интерфейсом.

Одним из возможных кандидатов на создание такой экспертной системы на сегодняшний день является система G2 фирмы Gensym — оболочка, ориентированная на создание экспертных систем реального времени. Эта система обеспечивает:

Кроме того, в настоящее время существует несколько проблемно-ориентированных средств — надстроек над G2, предназначенных для выполнения специфических операций. К ним относятся:

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



Используются технологии uCoz