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

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

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

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

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


Rambler's Top100

  

Технология управления распределенными сетями

А. Федотов

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

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

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

Управление в сети осуществляется программными приложениями, которые обычно работают на базе платформ сетевого управления. В качестве примеров платформ сетевого управления приведем системы HP OpenView фирмы Hewlett-Packard, NetView for AIX фирмы IBM, SunNet Manager производства одного из подразделений Sun компании SunConnect, Spectrum компании Cabletron System и NetWare Management System компании Novell (применяется главным образом для организации работ в локальных сетях, построенных на базе семейства операционных систем NetWare.

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

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

Основные понятия

Эти приложения строятся, как правило, на базе технологии удаленного мониторинга (RMON - Remote Monitoring). RMON задействует простой протокол управления сетью SNMP - Simple Network Management Protocol для передачи информации от агентов к управляющей консоли, но имеет свою стандартную информационную базу управления - RMON MIB (Management Information Base). RMON применяют такие широко распространенные приложения сетевого управления как HP OpenView for Windows Workgroup Node Manager, HP OpenView Network Node Manager (Hewlett-Packard), NetWare LANalyzer for Windows 2.1 (Novell), Distributed Sniffer System (Network General) и многие другие.

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

Основная идея технологии удаленного мониторинга состоит в обмене информацией между агентами RMON, работающими в различных сетевых устройствах, и приложениями сетевого управления, размещенными на рабочей станции сетевого администратора (NMS - Network Management Station). Агенты RMON - это резидентные программные модули установленные или загружаемые в управляемые сетевые устройства, такие как маршрутизаторы, мосты, рабочие станции, серверы, ПК, шлюзы, концентраторы, коммутаторы - во все, что может быть подключено к сети. Роль сети NMS состоит в восстановлении, обработке и представлении в удобном для оператора виде информации, полученной от агентов RMON. Как уже отмечалось, установленные на NMS приложения работают совместно с платформами сетевого управления, а RMON обеспечивает интерфейс для передачи статистики и сигнализации между программами-агентами и этими платформами. С помощью коммуникационного протокола SNMP данные от агентов RMON направляется на станцию NMS или на консоль платформы сетевого управления.

Для примера, здесь можно рассмотреть одно из приложений сетевого управления, продукт Distributed Sniffer Systems компании Network General. Эта система состоит из трех основных компонентов: Foundation Manager как станции NMS, Cornerstone Agent как агента RMON, Cornerstone Probe как агента RMON. В центре сети располагается Foundation Manager, который собирает и обрабатывает информацию, поступающую от агентов (Cornerstone Probe, Cornerstone Agent), установленных по всей распределенной сети. Cornerstone Agent - это программный модуль с локальным пользовательским интерфейсом. Он обеспечивает как локальный мониторинг (в том сегменте, где установлен), так и сбор и передачу данных наблюдения на станцию NMS и может быть установлен на любой компьютер с процессором 486, работающий под управлением ОС Windows или OS/2. Cornerstone Probe не имеет пользовательского интерфейса и работает совместно с Foundation Manager, поставляя информацию об удаленных сегментах.

MIB

Средства SNMP позволяют администраторам сети следить за различными сетевыми устройствами при помощи информационных баз управления (Management Information Base - MIB), обеспечивающих стандартное представление собираемых данных. MIB имеют древовидную структуру и определяют группы объектов (каждый управляемый параметр или ресурс представляется как объект). Первая версия информационной базы управления, включающей до 114 объектов в восьми группах, носит название MIB-I.

Изначально стандарт MIB-I предназначался для управления сетью Internet, использующей семейство протоколов TCP/IP, но впоследствии он получил дальнейшее развитие в расширенной редакции, которая получила название MIB-II. Новый стандарт, утвержденный в 1992 году, определяет 185 объектов в десяти группах.

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

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

В процессе стандартизации MIB группой IETF была разработана информационная база управления RMON MIB для удаленного мониторинга локальных сетей Ethernet и Token Ring. RMON MIB, определенная в двух документах: RFC 1271 (для Ethernet), RFC 1513 (для Token Ring), включает более 200 объектов в десяти группах. Ее основное назначение при совместной работе с приложениями сетевого управления - перспективный анализ и диагностика неисправностей в распределенных сегментах сети.

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

Собственно стандарт RMON MIB опрделяет девять групп объектов для Ethernet и Token Ring:

1) статистика (Statistics),

2) история (History),

3) тревоги (Alarms),

4) хосты (Hosts),

5) таблица наиболее производительных сетевых устройств (Hosts Top N),

6) матрица трафика (Traffic Matrix),

7) фильтры (Filters),

8) перехват пакетов (Packet Capture),

9) события (Events);

и одну (десятую) группу, включающую шесть разделов, только для Token Ring:

10.1) управление станций кольца (Ring Station Control),

10.2) таблица станций кольца (Ring Station Table),

10.3) порядок станций кольца (Ring Station Order),

10.4) управление конфигурацией станций кольца (Ring Station Configuration Control),

10.5) конфигурационная таблица станций кольца (Ring Station Configuration Table),

10.6) источник маршрутизации (Source Routing).

протокол SNMP

Остановимся более подробнее на протоколе SNMP. Как мы уже отмечали ранее сбор информации от агентов RMON и связь с ними поддерживается с помощью этого протокола, что является частным случаем его использования.

Этот протокол разработан еще в 1988 году группой исследователей и инженеров под руководством координационного совета сети Internet (IAB - Internet Activities Board) для работы в сетях TCP/IP. Коротко говоря, SNMP используется для получения от сетевых устройств информации об их статусе, производительности и их характеристиках. Разработчики постарались сделать SNMP достаточно простым, чтобы его реализация была простой и недорогостоящей, и открытым для дальнейших изменений и расширений. Именно его функциональная открытость и обеспечила ему широкую популярность.

Благодаря своим качествам протокол SNMP стал индустриальным стандартом для сбора и передачи информации RMON от распределенных сегментов к центральному узлу управления. Согласно семиуровневой модели взаимодействия открытых систем (OSI) является протоколом прикладного SNMP (седьмого уровеня) и использует транспортные услуги протокола User Datagram Protocol (UDP) (см. рис. 2). В настоящее время SNMP может работать и в сетях фирм Novell (IPX) и Apple (AppleTalk).

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

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

Протокольная независимость обусловлена тем, что RMON работает только на МАС подуровне канального уровня модели OSI. Следовательно, эта технология может без особых затруднений использоваться в гетерогенных сетях. Даже если различные сегменты сети предприятия работают с разными протоколами сетевого уровня, RMON позволяет собирать и контролировать данные со всех этих сегментов.

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

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

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

Приведем конкретный пример. Предположим, что пользователи одного из сегментов вашей сети стали испытывать затруднения, связанные с увеличением времени ответа приложений. Что необходимо сделать, чтобы решить данную проблему? Для иллюстрации рассмотрим работу DSS. Используем функцию "МАР" центральной консоли (Foundation Manager) для отображения трафика в каждом сегменте и определения: какие узлы работают с какими серверами; каков процент трафика, приходящегося на маршрутизаторы, серверы, другие узлы сегмента; какова загрузка серверов. Функция "МАР" использует стандартную группу Traffic Matrix информационной базы управления RMON MIB для определения реального плана сетевого трафика. Из рассмотрения плана сетевого трафика становится ясно, что наибольшая загрузка приходится на один из трех серверов (Bob), и, скорее всего, он является причиной замедления времени ответа приложений. Далее с помощью средств фильтрации выделим наиболее активные узлы, обращающиеся к серверу Bob и определим количество пакетов принятых и переданных сервером. Проанализировав полученные данные, можно прийти к выводу, что увеличение времени ответа испытывают те пользователи, которые наиболее часто обращаются к серверу Bob. Наибольший объем трафика для этого сервера проходит через маршрутизатор. Следовательно, значительное количество пользователей этого сервера работает в других сегментах сети. Можно предложить два способа минимизации времени ответа: первое, переместить наиболее активных пользователей в сегмент сервера Bob; второе, выделить наиболее активный сегмент и подключить к нему данный сервер.

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

Допустим, что происходит необъяснимое периодическое ухудшение производительности сети и непонятно что или кто вызывает эту проблему. Скорее всего, ее можно объяснить наличием "мощных" пользователей. Для выяснения причины проблемы необходимо узнать кто использует большую часть полосы пропускания и почему. Воспользуемся функцией Network Matrix приложения Foundation Manager, которая опирается на информацию групп Filter и Packet Capture, для получения картины обмена информацией между пользователями. Это приложение в окне размещает пары обменивающихся данными узлов по убыванию их доли в разделении полосы пропускания. Наиболее активные пары будут указаны в вершине таблицы. Кроме того, здесь же отражается количество переданных пакетов и байтов от источника к приемнику и вид сетевого протокола. В нашем случае при анализе этой таблицы оказалось, что господин Федоров периодически передает господину Иванову файлы большого объема, используя разные протоколы. В эти моменты происходит значительное ухудшение характеристик сети. Для уменьшения влияния на остальных пользователей администратор может настоятельно рекомендовать этим господам передавать большие файлы во время наименее активной эксплуатации сети (например, ночью в автоматическом режиме).

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


распечатать статью




  
1 '1996
СОДЕРЖАНИЕ

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

• Говорит и показывает Интервидение

открытые системы

• Мир TCP/IP. Internet Protocol

• Пятая волна компьютеризации: открытые сети общего пользования

• DCE. Скорее жива, чем мертва?

• Ява - остров восходящего солнца

• Проблемы маршрутизации трафика в Internet

• Удаленный доступ по PPP

• Будущее мультимедиа в Internet

• Интеграция Unix и Windows NT средствами NFS

• Internet: каково же будущее?

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

• Переход к коммутируемым сетям

• Загадка маршрутизатора

• Мост над бурным потоком

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

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

• Дисковые массивы RAID типа SCSI-to-SCSI

• Ленточные системы с автоматической сменой кассет

• Сетевые адаптеры Ethernet для шины PCI

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

• Системы низкоорбитальных спутников

• Кодирование речи в цифровой телефонии

• Архитектура и функциональные модули сетей SDH

приложения клиент-сервер

• Однопользовательские СУРБД

• SQL Server 6.0: взаимодействие клиента с сервером

• Комплексная автоматизация производства на основе систем SCADA

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

• А в вашей сети живут драконы?

• Испытание антивирусных программ для NetWare

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

• RAID без компромиссов, Эмулятор SunPC для DOS и Windows, Коммутатор LinkSwitch 1000 фирмы 3Com, Маршрутизаторы 7500 фирмы Cisco, MultiNet for Windows фирмы TGV



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