Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.sao.ru/hq/vch/RusDoc/lsok/glava_10.htm
Дата изменения: Tue Mar 17 15:23:07 1998 Дата индексирования: Tue Oct 2 07:07:57 2012 Кодировка: koi8-r Поисковые слова: astro-ph |
![]() |
Сервер поддерживается Центром Информационных Технологий (095) 932-9212, 932-9213, 939-0783 E-mail: info@citforum.ru |
Сервер Информационных Технологий содержит море(!) аналитической информации
|
---|
Коммутаторы - это сложные многофункциональные устройства, играющие ответственную роль в современных сетях. Поэтому поддержка функций централизованного контроля и управления, реализуемого протоколом SNMP и соответствующими агентами, практически обязательна для всех классов коммутаторов (кроме, может быть, настольных коммутаторов, предназначенных для работы в очень маленьких сетях).
Для поддержки SNMP-управления коммутаторы имеют модуль управления, в котором имеется агент, ведущий базу данных управляющей информации. Этот модуль часто выполняется на отдельном мощном процессоре, чтобы не замедлять основные операции коммутатора.
Наблюдение за трафиком
Так как перегрузки процессоров портов и других обрабатывающих элементов коммутатора могут приводить к потерям кадров, то функция наблюдения за распределением трафика в сети, построенной на основе коммутаторов, очень важна.
Однако, если сам коммутатор не имеет отдельного агента для каждого своего порта, то задача слежения за трафиком, традиционно решаемая в сетях с разделяемыми средами с помощью установки в сеть внешнего анализатора протоколов, очень усложняется.
Обычно в традиционных сетях анализатор протоколов (например, Sniffer компании Network General) подключался к свободному порту концентратора и видел весь трафик, передаваемый между любыми узлами сети.
Если же анализатор протокола подключить к свободному порту коммутатора, то он не увидит почти ничего, так как ему кадры передавать никто не будет, а чужие кадры в его порт также направляться не будут. Единственный вид трафика, который будет видеть анализатор - это трафик широковещательных пакетов, которые будут передаваться всем узлам сети. В случае, когда сеть разделена на виртуальные сети, анализатор протоколов будет видеть только широковещательный трафик своей виртуальной сети.
Для того, чтобы анализаторами протоколов можно было по-прежнему пользоваться и в коммутируемых сетях, производители коммутаторов снабжают свои устройства функцией зеркального отображения трафика любого порта на специальный порт. К специальному порту подключается анализатор протоколов, а затем на коммутатор подается команда через его модуль SNMP-управления для отображения трафика какого-либо порта на специальный порт.
Наличие функции зеркализации портов частично снимает проблему, но оставляет некоторые вопросы. Например, как просмотреть одновременно трафик двух портов, или как просматривать трафик порта, работающего в полнодуплексном режиме.
Более надежным способом слежения за трафиком, проходящим через порты коммутатора, является замена анализатора протокола на агенты RMON MIB для каждого порта коммутатора.
Агент RMON выполняет все функции хорошего анализатора протокола для протоколов Ethernet и Token Ring, собирая детальную информацию об интенсивности трафика, различных типах плохих кадров, о потерянных кадрах, причем самостоятельно строя временные ряды для каждого фиксируемого параметра. Кроме того, агент RMON может самостоятельно строить матрицы перекрестного трафика между узлами сети, которые очень нужны для анализа эффективности применения коммутатора.
Так как агент RMON, реализующий все 9 групп объектов Ethernet, стоит весьма дорого, то производители для снижения стоимости коммутатора часто реализуют только первые несколько групп объектов RMON MIB.
Управление виртуальными сетями
Виртуальные сети порождают проблемы для традиционных систем управления на SNMP-платформе как при их создании, так и при наблюдении за их работой.
Как правило, для создания виртуальных сетей требуется специальное программное обеспечение компании-производителя, которое работает на платформе системы управления, такой как, например, HP Open View. Сами платформы систем управления этот процесс поддержать не могут, в основном из-за отсутствия стандарта на виртуальные сети. Можно надеяться, что появление стандарта 802.1Q изменит ситуацию в этой области.
Наблюдение за работой виртуальных сетей также создает проблемы для традиционных систем управления. При создании карты сети, включающей виртуальные сети, необходимо отображать как физическую структуру сети, так и ее логическую структуру, соответствующую связям отдельных узлов виртуальной сети. При этом по желанию администратора система управления должна уметь отображать соответствие логических и физических связей в сети, то есть на одном физическом канале должны отображаться все или отдельные пути виртуальных сетей.
К сожалению, многие системы управления либо вообще не отображают виртуальные сети, либо делают это очень неудобным для пользователя способом.