Домой
НОМЕРА ЖУРНАЛА
  
2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100


  

Современные нюансы управления сетями

Современные нюансы управления сетями. Часть I

В. Ю. Саякин

Чтобы лучше понять специфику требований, предъявляемых сегодня к системам управления, позвольте вернуться на пять—семь лет назад, с тем чтобы проанализировать сущность происходящих тогда на рынке процессов. В середине 90-х годов, когда наметился значительный рост числа операторов и сервис-провайдеров, их усилия были сконцентрированы на развитии сервисов проводной и беспроводной (сотовой и спутниковой) телефонии и передачи данных. И хотя до продвинутых решений по управлению сервисами (Service Level Management — SLM) было еще далеко, стала очевидной необходимость создания мощных интегрированных решений по управлению сетями.

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

· простота инсталляции и быстрота внедрения ПО управления,

· интуитивно понятный графический интерфейс,

· быстрая локализация событий и неисправностей,

· сбор информации о событиях и неисправностях от любых элементов сети в режиме реального времени,

· гибкие возможности по мониторингу сетевых сервисов (независимо от сложности нижележащих платформ и систем),

· возможность внесения изменений в режиме реального времени,

· масштабируемость при расширении и усложнении инфраструктуры.

Следует вспомнить и о тенденциях рынка TMN-решений в то время. В середине 90-х годов многие специалисты еще возлагали большие надежды на то, что удастся довести до конца решение всех вопросов, относящихся к теоретическим и практическим аспектам TMN, после чего рынок обязан-таки наводниться массой готовых систем. Но, к сожалению, этого не произошло и большинство TMN-систем управления остались громоздкими и чрезвычайно "тяжелыми" с точки зрения их внедрения. Клиентов, которые были готовы к двухгодичному и даже боўльшим срокам разработки и внедрения у себя систем управления, было не так уж много. Нелишне сказать и о том, что необходимость знать языки программирования (в основном C++) отпугивала их еще больше, несмотря на наличие некоторых вспомогательных средств разработчика в виде моделей и шаблонов, а также на прямо-таки гипнотизирующие заклинания поставщиков относительно неисчерпаемых возможностей такого подхода.

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

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

Ядро и основные процессы

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

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

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

В рамках общей системы управления (далее будем под этим понимать систему управления неисправностями, дополненную некоторыми вспомогательными функциями) отдельные системы управления (SNMP и не-SNMP) становятся стратегическими элементами, которые сводят воедино информацию, поступающую, например, только от оборудования передачи данных или только от телефонных коммутаторов. Задачей общей системы является реализация push-модели доставки событийной информации. Функциональность ядра системы во многом опирается на использование "легких" наборов кода, называемых пробниками (probes), которые, в свою очередь, собирают так называемые трэпы (trap — формируемый управляемой стороной в силу внутренних причин специфический блок данных в виде SNMP-пакетов) и события от нижележащих сетевых элементов (Network Elements — NE) и систем управления (Element Management Systems — EMS, Network Management Systems — NMS). Пробники приводят поступающие данные к единому формату (нормализуют) и направляют их в активную резидентную базу данных.

Общая архитектура системы показана на рис. 1. Она состоит из четырех основных элементов, два из которых мы уже рассмотрели выше. Нужно упомянуть также о клиентах, которые позволяют операторам просматривать и обрабатывать данные, и о шлюзах, пропускающих информацию к внешним приложениям и обратно. В качестве таких приложений обычно выступают реляционные БД (Oracle, Sybase, Informix) и системы класса TTS (Trouble-Ticketing System).

Остановимся еще немного на функциональности и "идеологии" работы пробников (рис. 2). Они являются по своей сути пассивными "слушателями", которые идентифицируют и собирают информацию из баз данных MIB SNMP и из не поддерживающих протокол SNMP источников. Собираемая информация о событиях преобразуется в единый формат и затем с помощью ориентированного на соединения транспортного протокола направляется в ядро системы. Пробники способны взаимодействовать непосредственно с системами управления сетевыми элементами (EMS), а также с платформами сетевого управления разных фирм (такими, как Siemens ENMS, Lucent ITM-SC, ECI/eNM, Nortel Meridian, Ericsson ETNA-NEM, NEC INC100, Алькател 1353SH, Newbridge 46020, Tivoli TME 10, HP OpenView NNM и Vantage Point, Aprisma Spectrum, Solstice Domain/Enterprise Manager, Novell ManageWise, Veritas NerveCenter, BMC Patrol и др.).

Важно, чтобы пробники были универсальными (помимо традиционного протокола SNMP, они должны "понимать" CMIP, ASCII, TL1, Logfile, Syslog), тогда их можно легко интегрировать

с разнообразными программными средствами управления. Еще можно упомянуть, пробники должны идентифицировать все события от управляющих систем, так называемые "необработанные события" (raw events), а также осуществлять их предобработку. Примером такой предобработки служит трансляция идентификаторов trap-сообщений.

Очевидно, что ядро системы должно работать на широком наборе популярных операционных систем, имеющих функции параллельной обработки и распределения заданий, таких, как Solaris, HP-UX, IBM AIX, Windows 2000. Оно также должно поддерживать возможность обработки нескольких десятков тысяч событий в секунду одновременно с их дедупликацией посредством использования полей-идентификаторов.

Конфигурационные правила, которыми должны изобиловать подобного рода системы, могут базироваться на языке SQL, причем его "программистские" свойства надо скрыть от операторов путем использования интуитивно понятных интерфейсов drag-and-drop.

Управление IP-сетями

Как уже было сказано выше, существенной особенностью общей системы управления является интеграция с разнообразными специфическими системами/платформами IP-управления. Одной из таковых является HP OpenView NNM — наиболее распространенный в России продукт этого класса. Как известно, HP OpenView NNM позволяет получать специфические виды сетевого окружения, при этом каждая иконка карты сети представляет собой узел или группу узлов, элементы которой объединены по принципу IP-адресации или по иным топологическим принципам. Визуализация сетевого представления является основной особенностью этого продукта.

Давайте рассмотрим те преимущества, которые могут быть достигнуты в результате интеграции общей системы управления с системой управления IP-сетями (HP OpenView NNM).

Начнем с того, что трансляция данных HP OpenView NNM в логические представления дает возможность операторам работать в среде сервисов и концептуальных (определенных пользователем) представлений. Это обогащает отображения, существующие исключительно в терминах IP на топологических картах. Важно отметить возможность попадания в список событий (EventList) путем нажатия на иконку, представленную на карте NNM. Поддерживается и обратный вариант — при просмотре EventList нажатием на выбранном сообщении запускается меню выбора действия и устанавливается соответствующая связь с узлом, отображенным на топологической карте. Таким образом, для взаимодействия систем не требуется отдельного их запуска и повторной регистрации.

В рамках общей системы можно получать событийную информацию не только от HP OpenView NNM, но и от элементов, которые не отображаются в OpenView, например от телефонных коммутаторов, не поддерживающих протокол SNMP (при этом обеспечивается корреляция информации SNMP и не-SNMP). Еще можно упомянуть, интеграция с многочисленными разрозненными системами IP-управления, отвечающими за свои локальные участки, позволяет перейти к единой высокопроизводительной консоли управления. При этом возможна установка "легких" клиентов (desktops) для операторов вместо создания в системе IP-управления распределенных карт сети или использования X-клиентов (что тоже не исключается). Нужно сказать и о возможности использования информации из внешних баз данных, например при построении системы с расширенной функциональностью (скажем, SLA).

Перечислим еще ряд преимуществ интеграции общей системы управления с системой управления IP-сетями (HP OpenView NNM):

· конвертация всей trap-информации в один и тот же формат для всех без исключения сообщений;

· возможность группировать специфические базы данных MIB в классы (например, Сisco, Nortel и др.) и упрощение процедур выбора пунктов меню, имеющих отношение к тому или иному типу оборудования;

· представление информации через механизмы фильтрации событий в реальном режиме времени и в едином формате (при этом сохраняется полная синхронизация с HP OpenView Event Browser);

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

Чтобы реализовать вышеперечисленные преимущества, необходим специальный пробник, но внесение изменений в сам продукт (HP OpenView NNM) не требуется. Кстати, подобные интеграционные задачи могут быть поставлены в отношении не только продукта HP OpenView NNM, но и других средств управления IP-средой (таких, как Tivoli TME 10, Aprisma Spectrum, Solstice Domain/Enterprise Manager и др.). Помимо этого, в ряде случаев могут потребоваться средства интеграции, позволяющие собирать напрямую SNMP trap-сообщения, syslog-сообщения или иные ASCII-данные.

Подводя итог сказанному в отношении интеграции со средствами управления IP-средой, естественно возникает вопрос: а разве нельзя попытаться реализовать по крайней мере некоторые из вышеприведенных интеграционных преимуществ на базе продуктов одной фирмы, например HP, перейдя к использованию продукта HP OpenView Vantage Point? С точки зрения создания более мощного событийно-ориентированного решения, безусловно, можно, но наша задача шире: мы говорим о построении общей системы, которая не ориентирована только лишь на традиционные задачи корпоративного IP-управления.

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

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

· мониторинг производительности, операций с дисками, сетевого ввода-вывода, использования процессора и памяти;

· мониторинг параметров файловых систем прежде всего с точки зрения использования дискового пространства (например, с активацией действий по удалению core-файлов);

· мониторинг процессов (например, httpd, sendmail и др.) на предмет соответствия заранее установленным параметрам с возможностью активизации предопределенных действий (таких, скажем, как рестарт);

· мониторинг системных log-файлов и log-файлов приложений;

· мониторинг и управление специализированными приложениями (Oracle, R/3 и пр.);

· мониторинг Интернет-сервисов (HTTP/HTTPS, FTP, SMTP, POP3, IMAP4, DNS, NNTP, DHCP, LDAP, RADIUS и т. п.).

Мониторинг Интернет-сервисов может рассматриваться как одна из задач управления серверами и приложениями, но его можно вынести в особую категорию задач, связанных с построением систем SLM, о которых речь будет идти ниже. Здесь же отметим, что средства мониторинга Интернет-сервисов должны предоставлять не только информацию о их доступности, но и такие важные для анализа временныўе параметры, как Lookup time (время поиска), Connect time (время соединения), Response Time (время отклика) и Download time (время загрузки).

Наиболее известными в России решениями в области управления серверами и приложениями являются продукты таких компаний, как BMC, HP, IBM. При построении интегрированной системы управления можно организовать взаимодействие с этими системами через специализированные пробники, а можно использовать аналогичные по функциональности компоненты компании Micromuse.

Управление безопасностью

Как известно, базовым элементом защиты сетевых ресурсов от злоумышленников являются межсетевые экраны (firewall). Лидирующие позиции на этом рынке сегодня занимают такие продукты, как FireWall-1/Provider-1 компании CheckPoint и Cisco Secure PIX Firewall компании Cisco Systems.

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

Основными задачами интеграционной части общей системы управления (рис. 3) являются:

· перехват всех log-cообщений и их просмотр в реальном времени;

· обнаружение вторжений, включая распознавание атак на любых уровнях;

· ответные действия на обнаруженные атаки (посылка предупреждающих сообщений (alarm) по электронной почте, на пейджер или закрытие сессии).

В качестве основного способа интеграции с межсетевыми экранами сегодня, честно говоря, рассматривается использование интерфейса OPSEC Log Export API (LEA), который в случае с продуктом компании CheckPoint позволяет устанавливать взаимодействие и с firewall-модулем, и с сервером управления CheckPoint. Взаимодействие с системой Cisco PIX Firewall обычно сводится к посылке log-сообщений через SYSLOG-интерфейс.

Архитектура OPSEC (Open Platform for Secure Enterprise Connectivity), служащая для создания безопасной распределенной среды, поддерживается сегодня многими разработчиками решений в области безопасности. При взаимодействии с компонентами OPSEC можно использовать схемы аутентификации, что повышает защищенность общей системы управления.

Помимо используемого для извлечения и экспорта log-сообщений интерфейса LEA, важна также поддержка протокола SAMP (Suspicious Activity Monitoring Protocol), который позволяет блокировать сессии, инициированные злоумышленниками.

Несколько подробнее остановимся на ключевых функциях интеграционных компонентов продукта Netcool компании Micromuse.

Firewall Log Consolidation позволяет дедуплицировать log-сообщения и показывать их в отфильтрованном виде с выделением наиболее важных событий. Преимущества этой функции очевидны. Согласитесь, в высшей степени неэффективно вручную просматривать десятки тысяч сообщений, многие из которых фактически дублируют друг друга (как, например, в случае обнаружения попыток сканирования портов).

Firewall Log Enrichment "обогащает" полученные log-сообщения дополнительной информацией, имеющейся в общей системе управления, в частности справочной информацией о заказчиках или бизнес-процессах.Real-time Intrusion Detection поддерживает различные механизмы обнаружения вторжений уже в рамках общей системы управления. Назовем два наиболее важные из них. Первый — это обнаружение "известных нарушителей", скажем неудачных попыток прохождения некоторыми пользователями через систему защиты (небезынтересно сохранять информацию о таких случаях в БД и генерировать предупреждения). Второй — обнаружение "ненормального поведения". Так идентифицируются атаки типа Denial of Service, Suspicious Activity, сканирование хостов/портов, использование паролей типа guest и др. Делается это путем сравнения "ненормального поведения" с существующей базой правил в рамках общей системы управления. Эти правила могут применяться к выбранным сетевым профилям (описывающим различные узлы или группы узлов), что позволяет строить более гибкую адаптируемую систему.Real-time Attack Response действует после идентификации атаки для посылки сигнала предупреждения по электронной почте или на пейджер. Кроме этого, благодаря поддержке OPSEC SAMP возможно автоматическое выполнение операций на межсетевом экране по блокированию подозрительных действий до момента их более детального рассмотрения администратором.

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

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

***

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

(Продолжение следует)

Об авторе
Саякин Вадим Юрьевич,
генеральный директор компании NV Consulting
Телефон: (095) 999-0132
E-mail: svy@nvconsulting.net

  
2 '2002
СОДЕРЖАНИЕ

от редактора

• Автомобиль - это не роскошь, а средство общения

бизнес

• Окупаемость инвестиций. Иногда это пустые слова

• Плавание за золотым руном

компьютерные сети

• Не стоит прогибаться под изменчивый мир?

• iSCSI - новая эра в развитии сетей хранения данных

• Точки доступа, соответствующие стандарту 802.11b

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

• Интеграция приложений на основе Web

• Выбор технологии и системы спутниковой связи для корпоративной или ведомственной сети

• Станут ли Windows и другие платформы более открытыми благодаря Web-службам?

• Персонализация электронного взаимодействия

сети связи

• VoDSL. От "коробок" - к решениям

• Современные аспекты управления сетями. Часть I

• Классика и модерн ИС

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

• Механизмы защиты корпоративных сетей

• Персональные межсетевые экраны

• Межсетевое экранирование как услуга

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

• О привязанности к поставщикам услуг связи

• Планирование поставок: внедрение специализированного ПО встречает сопротивление

• StormWatch - надежная защита для корпоративных сетей


• Калейдоскоп


  вверх