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

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

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

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

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


Rambler's Top100

  

Возвращаясь к проблемам удаленного мониторинга

Питер Морриси

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

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

Чтобы избежать этого, производители снабдили некоторыми функциями RMON каждый порт коммутатора. Сейчас большинство этих устройств имеют группы статистики и истории RMON на каждом порте, а некоторые из них — группы событий и аварийных сообщений, извещающих станцию сетевого управления только тогда, когда статистика достигает пороговой величины. Это более масштабируемая система, чем система постоянного опроса всех портов коммутатора. Группа статистики запускает счетчики базовой загрузки и статистики ошибок на каждом порте, а группа истории позволяет хранить выборки указанных данных, которые могут понадобиться для оценки тенденций. Теоретически это выглядит хорошо, так как с помощью производимых в настоящее время улучшенных наборов специализированных микросхем (Application Specific Integrated Circuits — ASIC) удаленного мониторинга можно осуществить все перечисленное без серьезных дополнительных затрат, но в действительности это связано с определенным риском.

Первая проблема — упрощение идентификации портов и установление их соответствия реальным физическим соединениям. RMON осуществляет это с помощью более старой базы управляющей информации — MIB2 (RFC 1213), разработанной первоначально для маршрутизаторов. Она включает в себя элемент, в котором есть так называемая ifIndex — таблица для каждого интерфейса на устройстве. Их нумерация в таблице производится последовательно, начиная с 1 или 0. Однако эти числа не вполне соответствуют физическим номерам портов на коммутаторе, делая проблематичной интерпретацию данных RMON. Модульный коммутатор еще больше усложняет дело: добавление платы может изменить последовательность номеров. Каждый интерфейс в ifIndex способен включать свое описание, позволяя поставщикам для облегчения проблемы помещать в указанное поле данные — такие, как скорости портов и описания сред передачи.

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

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

***

Полную версию данной статьи смотрите в 4-м номере журнала за 2000 год.





  
4 '2000
СОДЕРЖАНИЕ

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

• Молодым везде у них дорога

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

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

• Измерители оптических потерь

• Проблемы с разъемами категории 6

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

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

• Как лечить "последнюю милю" внутрипроизводственных сетей

• IP-телефония. Как обеспечить качественную передачу речи. Часть 2

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

• LinkView Classic - классика сетевой диагностики, ProCurve 8000: со временем только лучше, Программное обеспечение SiteNet MultiLink для источников бесперебойного питания, ViPNet - сеть для особо важных приложений, Best 5000: "чистое" питание VIP-систем

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

• Управление сетевой производительностью - дорого, но мило

• Способы модернизации сервера

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

бизнес

• Датские уроки экономного электропитания

• 3Com меняет структуру каналов сбыта

электронная коммерция

• Ищите разумный компромисс

• Коммутаторы, распределяющие нагрузку

• Господство на вертикальных рынках

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

• Платформы сетевой безопасности

• Преступление и наказание


• КАЛЕЙДОСКОП



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