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

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

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

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

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


Rambler's Top100

  

Сетевая ловушка, или Платформы управления

Арт Уитман и Брюс Бордман

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

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

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

Трудно выделить какого-то одного производителя средств сетевого управления. Продукты постоянно меняются в лучшую сторону. Мы предлагаем обзор системы NetView фирмы IBM, а также готовящихся к выпуску продуктов фирм Hewlett-Packard, Cabletron и Sun. Сразу заметим, что все они имеют несколько существенных архитектурных изъянов.

Почему так плохо?

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

Получение такой информации, безусловно, полезно. Но стоит ли ради этого покупать рабочую станцию под Unix по цене около 30 тыс. дол., тратить еще тысячи долларов на ПО и привлекать целую группу сотрудников? Конечно, нет. Продукты с такими функциями могли бы стоить около 500 дол., работать на любом ПК или рабочей станции и просто посылать собранную информацию администратору сети, скажем, по электронной почте. Это называется обыкновенным сетевым мониторингом.

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

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

Как насчет SNMP?

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

Все производители систем сетевого управления поддерживают две стандартные базы управляющей информации — MIB-I и MIB-II. Однако не существует поддерживаемых одновременно и производителями систем сетевого управления, и производителями оборудования стандартных MIB для концентраторов, маршрутизаторов, мостов и серверов. В этом и состоит основная проблема. Заплатив 20 тыс. дол. за ПО сетевого управления и 30 тыс. дол. за оборудование, на котором это ПО будет работать, вы в праве рассчитывать найти меню, на котором будет написано "Управление маршрутизаторами" или "Управление концентраторами".

И улучшений здесь не предвидится. Фактически, каждый производитель систем сетевого управления уделяет внимание только своему оборудованию. Если вы приобрели управляющее ПО фирмы HP и хотите управлять маршрутизаторами Bay Networks или, что еще хуже, сервером Sun Microsystems, то вы сильно просчитались. Для управления серверами HP лучше всего подойдет управляющее ПО фирмы HP. Система управления фирмы Cabletron хорошо управляет аппаратурой Cabletron. ПО производства IBM отлично работает с аппаратурой IBM и т. д.

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

Есть ли надежда?

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

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

Разработчики систем управления успешно поработали, улучшив пользовательский интерфейс и сделав системы более масштабируемыми. Теперь им следует вернуться к "фундаменту" систем.

OpenView Network Node Manager версии 4.0

Система OpenView Network Node Manager (NNM) стала лучше с тех пор, как мы просматривали ее в последний раз, значительно лучше. Версия 3.0 была последней из тестированных нами и имела серьезные недостатки: ПО не могло управлять большим количеством станций (оно "выдыхалось" примерно при 1000 станций), плохо масштабировалось и практически не поддерживало аппаратное обеспечение, разработанное не фирмой HP. NNM версии 4.0 работает лучше, но не только благодаря усилиям HP. Процессоры стали существенно быстрее, и оперативная память объемом 64 Мбайт (и более), которая требовалась два года назад, на сегодняшний день стала немного доступнее по цене и более распространена. С другой стороны, мы насчитали, что NNM версии 4.0 поддерживает не менее 147 MIB 47 различных компаний. Возможность работы с фирменными MIB повышает ценность системы сетевого управления, и приятно видеть, что в продукте HP их поддержано так много.

Однако мы были разочарованы недостатками NNM, оставшимися и в новой версии. В то время как вариант продукта для Windows управляет устройствами, работающими и по протоколам TCP/IP, и по протоколу IPX, версия для Unix знает только TCP/IP. (Хотя HP и продает продукт, позволяющий работать NNM в среде NetWare, он, впрочем, все равно основывается на TCP/IP.) HP считает отсутствие поддержки IPX следствием ориентации NNM на управление большими корпоративными сетями. Мы же склонны рассматривать это как ошибку, которую HP должна исправить в ближайшее время. К тому же NNM не поддерживает Windows NT. Поскольку весьма вероятно, что вы захотите работать с Windows NT в сети TCP/IP, то для консоли централизованного управления также было бы целесообразно "дружить" с этой ОС.

Разработанные IETF база управляющей информации RMON и некоторые другие становятся все более важными, а в новой версии NNM нет их поддержки. Такая функция возложена на другие продукты HP. А с добавлением в сеть коммутаторов возможность работы управляющей консоли с RMON MIB превращается просто в необходимость.

Простота использования

Однако HP во многом усовершенствовала свое ПО. Например, добавлена панель инструментов с изменяемой конфигурацией и улучшено средство просмотра списков подсетей. Но ведь нигде не сказано, что работа с ПО ценой 16 тыс. дол. должна быть сложной.

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

Приятно, что HP продолжает делать OpenView более открытым. Вместе с используемой по умолчанию собственной файловой структурой OpenView может также задействовать для хранения информации базы данных Oracle и Ingres. Факультативная поддержка Ingres была и в предыдущих версиях. А вот поддержка Oracle появилась только в новой версии. Вы можете предположить, что использование системы управления реляционными базами данных (СУРБД) увеличит производительность продукта. Но ошибетесь (как ошиблись и мы). По утверждению специалистов HP, работа с файловой системой намного быстрее, чем с СУРБД, и поэтому заказчики обычно используют СУРБД только в том случае, если необходимо выполнять не предусмотренные NNM запросы к собранной ею (NNM) информации.

Производительность все еще остается серьезной проблемой для NNM. Тем не менее HP приложила значительные усилия, чтобы сделать NNM более распределенной. Если раньше с NNM могли общаться не более пяти операторов, то теперь их число увеличилось до 15.

Обнаружение

Раньше NNM обнаруживала по умолчанию объекты всей сети. Теперь этого нет. Начиная с управляющей станции, система обнаруживает подсети (и, следовательно, маршрутизаторы) по уровням. Это весьма хорошее свойство, обеспечивающее более высокую степень контроля над выбранным оборудованием. NNM также проверяет ближайший сервер именований доменов (Domain Name Server — DNS) и преобразует адреса IP в имена хостов, что значительно упрощает определение управляемых узлов. NNM изображает все устройства, имеющие несколько (два и более) соединений с сетью, на верхнем уровне сетевой диаграммы. Это удачный метод размещения: все маршрутизаторы в автоматически получаемой карте оказываются вверху. Наверху оказываются и серверы, подсоединенные сразу к нескольким сетям. В NNM такая возможность реализована недавно, и нам она сразу понравилась.

Понравились также и средства наложения ограничений на выбор управляемых станций. Такое ограничение имеет два преимущества: во-первых, станции, которыми вы не хотите управлять, не отражаются в списке на консоли; во-вторых, при ограничении числа управляемых станций NNM работает быстрее.

Solstice Enterprise Manager версии 1.1

Система сетевого управления SunNet Manager (SNM) фирмы SunSoft, которая последнее время стала слегка отставать по функциональным возможностям от других систем, была несколько усовершенствована. Но вместо того, чтобы серьезно модернизировать продукт, который никогда и не конкурировал по-настоящему с более мощными системами фирм IBM и HP, SunSoft разработала новый — Solstice Enterprise Manager (SEM). SNM теперь предлагается как средство управления небольшими сетями.

Solstice Enterprise Manager версии 1.1 — распределенная, ориентированная на использование агентов система управления большими сетями. Она нацелена на применение в телекоммуникационных и других крупных корпорациях, придающих существенное значение своим глобальным информационным сетям. SEM занимает и будет занимать заметное место в семействе продуктов Solstice фирмы SunSoft. Базы данных SEM, называемые информационными серверами управления (Management Information Servers, или MIS), имеют полностью распределенную структуру. Распределенными являются и консоли SEM. Именно распределенные объектно-ориентированные базы данных выделяют SEM среди других систем, делая ее более масштабируемой и более подходящей для глобальных сетей.

Сделано для больших предприятий

SNM долгое время зависела от собственных, созданных SunSoft агентов, работа которых основана на механизме вызовов удаленных процедур (RPC). При помощи таких агентов информация на SNM поступала фактически по протоколу SNMP. SEM намного гибче: будучи ориентированной на протокол CMIP, она поддерживает также протокол SNMP и агентов RPC. Может показаться удивительным, что компания SunSoft, преданная TCP/IP и стандартам сети Internet, начала создавать продукты, базирующиеся на стандартах Международной организации по стандартам (ISO). Дело в том, что SEM ориентирована на крупные многонациональные корпорации, которые привержены стандартам ISO. Два ключевых стандарта, на которых базируется SEM — OMNIPoint и TMN, — в первую очередь являются телекоммуникационными стандартами.

SunSoft ожидает, что покупатели SEM будут ее активно подстраивать. В ней есть средства для разработки и агентов (SunSoft называет агентов адаптерами протоколов управления), и систем просмотра данных. Имеется панель инструментов Application Launcher, из которой могут запускаться различные приложения, подобные собственной программе просмотра SEM. Программа просмотра написана на базе интерфейса прикладных программ PMI (Portable Management Interface), доступного любому пользователю. SunSoft рассматривает эту программу как пример того, что можно сделать при помощи интерфейса PMI, и ожидает, что многие пользователи напишут новые программы просмотра или значительно модифицируют имеющуюся. Средство просмотра не привязано жестко к ОС Solaris. Возможно организовать консоль управления и на основе Windows.

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

Контроль за событиями

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

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

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

В SEM реализовано иерархическое размещение объектов; группы оборудования (скажем, маршрутизаторы или серверы) могут иметь собственное представление. После того как ваша база данных построена, вы можете экспортировать ее в файл или в базу данных Sybase, Informix или Oracle.

Минимум, необходимый для работы информационных серверов управления SEM, включает компьютер SparcStation 20 с оперативной памятью 96 Мбайт, жестким диском 1 Гбайт и областью подкачки 200 Мбайт. Информационный сервер управления в настоящее время функционирует только в ОС Solaris для платформы SPARC, поскольку для него требуются оба стека протоколов: и TCP/IP, и ISO.

Cabletron Spectrum версии 4.0

Spectrum — лидер среди систем управления, только никто об этом не знает. Известно ли вам, что текущая версия Spectrum (3.1) уже имеет распределенную архитектуру, поддерживающую множество клиентов и серверов, которую большая тройка (HP, IBM и SunSoft) обещает реализовать только в следующих версиях своих продуктов? Не расстраивайтесь. Вы не одиноки!

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

Spectrum часто получает низкую оценку из-за того, что не имеет широкой поддержки третьих фирм. Но давайте, наконец, посчитаем: 136 производителей предлагают 166 приложений для Spectrum, вдобавок к 56 приложениям самой Cabletron. Протестировав альфа-версию новой разработки Spectrum 4.0, которая в 1996 г. уже должна появиться на рынке, мы поняли, что Cabletron начинает год впереди большой тройки. Если фирма выполнит все свои обещания — от создания распределенных приложений до поддержки Windows NT как операционной среды, — то оторвется от конкурентов. Только будет ли кто-нибудь об этом знать?

Обещания, обещания...

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

Cabletron также планирует включить в продукт возможность экспорта информации, хранящейся в собственной базе данных Spectrum на многочисленных серверах, в файлы, базы данных Sybase, Oracle или SAS. Отчеты, составленные на основе этой информации, могут быть также распечатаны или представлены в формате HTML.

Cabletron планирует обеспечить взаимодействие с сетями NetWare при помощи сервера Network Management Gateway Server for IPX. Предполагается также, что управление сервером NetWare будет производиться без загрузки на него модуля NLM или другой программы. И, наконец, возможно, важнейшим обещанием версии 4.0 является перенос Spectrum (и клиентской, и серверной частей) на платформу Windows NT 3.51.

Поиски в сети

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

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

В Spectrum для определения связей между сетевыми устройствами используется так называемый индуктивный метод моделирования (Inductive Modeling Technique — IMT). Этот метод основан на общих моделях объектов, содержащих характеристики большого количества различного сетевого оборудования: концентраторов, маршрутизаторов, зондов RMON и т. д. Идея метода заключается в том, что, зная, какие функции выполняет конкретное устройство, можно определить его связи с другим оборудованием в сети.

Мы также запустили процесс обнаружения всех узлов сети класса В и добавили в карту оставшиеся маршрутизаторы, концентраторы и оборудование ЛВС. При помощи сервера DNS были корректно получены имена обнаруженного оборудования. Результат второго прохода не был таким же точным, как первого, при котором были обнаружены только маршрутизаторы. Но, повозившись примерно час, мы "склеили" топологическую карту сети с точностью 90%. Для наших целей этого было вполне достаточно. Уточнение оставшихся 10% — дело несложное.

Можно и без MIB

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

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

Например, был сообщен параметр загрузки для маршрутизатора Cisco, но, откуда он взят и что означает, было непонятно. Оказалось, что он получен при помощи общей модели для маршрутизатора Cisco. Именно задействовав общую модель, Spectrum про-считала, какая загрузка была у маршрутизатора. Это — весьма полезное свойство, правда, вначале оно немного сбивает с толку.

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

NetView for AIX SNMP Manager

IBM хочет видеть SystemView, включающую и NetView for AIX 4.x, всеобъемлющим продуктом, лидирующим в области систем сетевого и системного управления и имеющим открытую и распределенную архитектуру. Планируется сделать все составляющие SystemView продукты объектно-ориентированными и базирующимися на стандартах. Версия 4.х нацелена как раз на это. Участие IBM в программе работ COSE — это стратегический ход, направленный на то, чтобы обеспечить SystemView, а следовательно, и NetView, преимущества перед другими системами сетевого и системного управления. Продукт IBM поддерживает не только MIB-II, но и протокол CMIP, и интерфейс прикладных программ, соответствующий предварительному варианту версии 2 протокола SNMP.

Архитектурные нюансы

Протестировав NetView for AIX 4.x, мы поняли, что IBM, подобно HP и SunSoft, идет по правильному пути. Но ее продукту еще предстоит догнать по функциональным возможностям систему Spectrum. Однако, где IBM преуспела, так это в поддержке баз данных: NetView работает с DB2/6000, Informix, Ingres, Oracle и Sybase.

IBM также разделила серверную и клиентскую части NetView 4.0. Каждый сервер может работать с 30 клиентскими станциями, а это в два раза больше, чем в продукте HP. Но NetView все еще отстает от Spectrum, которая поддерживает связь нескольких клиентов с несколькими серверами. IBM заявляет, что с новой версией NetView, работающей по архитектуре клиент—сервер, совместимы все приложения, созданные третьими фирмами для версии 3.0. К сожалению, у нас не было ни одного приложения для NetView 3.0, чтобы проверить эту совместимость.

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

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

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

Построение карт

Мы запустили процесс автообнаружения, выбрав сперва маршрутизатор, с которого необходимо начать этот процесс. Используя информацию сервера DNS и хранимую в маршрутизаторе информацию протокола ARP, программа корректно нарисовала карту сети. К сожалению, из-за того, что все оборудование размещалось на одном и том же уровне, она получилась громоздкой и неудобной. Для получения иерархической карты сети мы использовали средство Collection Facility, которое появилось лишь в новой версии NetView. Collection Facility просто выделяет на карте, полученной в процессе автообнаружения, логическую группу подсетей IP и переносит ее на новую пустую карту. Мы обозначили новую карту одной пиктограммой, которую и поместили вверху полной карты.

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

Навигационное дерево (Navigation Tree) — древовидное представление сетевой топологии высокого уровня, расположенное в специальном окне на экране, делает навигацию еще проще. Оно показывает уже пройденные вами пути и позволяет быстро перейти в открывавшуюся перед этим часть карты. Может быть, было бы лучше и первоначальное исследование сети начинать из этого окна. Но тогда будет нарушена цель — иметь небольшое дерево, изображающее наиболее часто посещаемые (и определяемые) пользователем участки сети.

Контроль за событиями

Средства аварийного оповещения и инициирования различных событий в версии 4.х значительно улучшены. Условия, определяющие выдачу оповещения или начало любого события, могут задаваться с применением любых деталей, включая переменные MIB. Эта гибкость, конечно, требует понимания структуры MIB конкретного устройства. Но в целом степень детализации для задания условий выдачи сигналов оповещения хорошая.

Цель окна Control Desk — обеспечить быстрый доступ к приложениям. По умолчанию из него выполняются приложения аварийного оповещения, но в это окно можно перетащить пиктограмму любого приложения. Мы инициировали несколько сигналов оповещения, которые Control Desk изобразил в виде размещенных в стопке карточек. После устранения проблемы, вызвавшей сигнал оповещения, NetView автоматически удалял соответствующую карточку из Control Desk. Для продолжительных проблем есть возможность просмотреть или напечатать журнал событий, связанных с конкретным сигналом оповещения или устройством.

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


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




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

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

• Сладкие сети

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

• Сценарии входа в сеть

• Высокоскоростные сетевые адаптеры

• Службы NetWare и новые средства разработки приложений

• Cisco и 3Com в одном проекте

• Массивы RAID: емкость и производительность

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

• "Штормящая" сеть

• Суперсерверы широкого пользования

• Catalyst 5000 фирмы Cisco

• Сетевая ловушка, или Платформы управления

• Установка и настройка средств удаленного доступа Windows 95

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

• Пейджеры

• Беспроводные мосты

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

• Стратегия многопроцессорной обработки

• Доступ к базам данных по низкоскоростным каналам

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

• Мир TCP/IP. Протоколы UDP и TCP

• Как улучшить Web-страницу?

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

• Руководство по выбору ИБП

• Голосование без обмана

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

• Семейство BayStack, Цветные струйные принтеры DeskJet 1600C и DeskJet 1600CM, Дисковый массив StorageWorks RAID Array 230 ...



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