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

Что коммутаторы дают одной рукой, то другой забирают. Зачем нужна производительность, если возникшую проблему невозможно локализовать?

РАЗДЕЛЯЕМЫЕ СЕТИ НА 100 МБИТ/С ПРЕДСТАВЛЯЮТ СОБОЙ АЛЬТЕРНАТИВУ КОММУТИРУЕМЫМ СЕТЯМ
Поделись с другим

ДВА ВЗАИМОСВЯЗАННЫХ СТАНДАРТА INTERNET СЛУЖАТ ОСНОВОЙ ДЛЯ МНОГИХ СИСТЕМ УПРАВЛЕНИЯ
SNMP и RMON

Марк Маллинз, менеджер по оборудованию LANMeter в компании Fluke, любит рассказывать историю об одном заказчике. Покупатель рассчитывал на то, что прибор станет большим подспорьем в диагностировании проблем с сетью. В силу ряда причин тестовое оборудование было доставлено только через несколько недель. Вскоре после получения продукта заказчик позвонил в Fluke в недоумении и бешенстве - LANMeter не выполнял тестов и не отображал статистику, как это было продемонстрировано торговым представителем. На какую удочку он попался?

Fluke - консервативная компания, имеющая длительную историю в области тестового и измерительного оборудования. Не в стиле компании обманывать доверчивых покупателей с помощью завлекательных демонстраций. Представитель Fluke оказался достаточно сообразительным, чтобы спросить, изменилось ли что-нибудь в сети со времени демонстрации LANMeter. Нет, ничего, был ответ, разве только они установили новый концентратор, "коммутирующий концентратор", в серверной комнате. Но ведь это не имеет никакого отношения к проблеме, не так ли?

В ЧЕМ ПРОБЛЕМА?

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

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

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

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

Некоторые производители коммутаторов используют объединительную панель ATM для выполнения коммутации кадров, а эмуляция локальной сети в ATM обеспечивает естественный переход к виртуальным сетям от унаследованных сетей. Проблема с ATM в том, что эта ориентированная на соединение технология передачи ячеек не вполне отвечает концепциям управления разделяемыми сетями. Широковещание, как таковое, отсутствует, за исключением тех случаев, когда это надо для связи с разделяемыми сетями. Вместо маршрутов мы имеем виртуальные соединения. Различные дискуссии об ATM RMON (AMON) и предложения по "управлению соединениями" (circuit steering), с помощью которых инструменты для тестирования локальных сетей могли бы получить власть над ATM, имеют место, но никто не возьмет на себя смелость утверждать, что стандарт появится в ближайшее время.

ВОЗМОЖНЫЕ РЕШЕНИЯ

Зонды RMON стоят около 1500 долларов для 10Base-T и более для других технологий канального уровня типа Token Ring, FDDI и 100Base-T. В теории зонд можно подключить к каждому сегменту, но это приведет к тому, что затраты на инструментарий управления для такой системы превысят в несколько раз затраты на сам коммутатор (цена в расчете на порт составляет от 200 до 600 долларов). Вы можете даже поместить анализатор протокола (например Distributed Sniffer) на каждый порт, но эти устройства еще дороже, чем зонды RMON.

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

Зеркалирование трафика через все порты на порт для мониторинга - это некий способ воссоздания прежней разделяемой сети для целей управления. Проблема в том, что оборудование для мониторинга предназначается главным образом для работы на скоростях 10 Мбит/с или 16 Мбит/с, но даже прибор для мониторинга на 100 Мбит/с вряд ли справится с трафиком загруженного 16- или 24-портового коммутатора с одним или более портами для каскадирования на 100 Мбит/с. Кроме того, если зеркалировать весь трафик на один порт, то этот порт с ним не справится. Просто так данную проблему решить не удастся.

ВСТРОЕННЫЕ СРЕДСТВА RMON

Цены на коммутирующие устройства, как большинство цен в компьютерном мире, снижаются благодаря тому, что процессы, выполняемые программным обеспечением на микропроцессорах общего назначения, были адаптированы под специальное оборудование - специализированные интегральные схемы ASIC. То же самое происходит с агентами RMON - некоторые или даже все группы базы управляющей информации RMON MIB могут быть реализованы на микросхемах и включены непосредственно в коммутатор. Эти аппаратные агенты RMON увеличивают стоимость порта коммутатора лишь на несколько долларов, в особенности если они реализуют только несколько из простейших групп RMON. Альтернативный метод состоит во включении некоторых из простейших групп на каждый порт и добавлении управляющего ЦПУ для их обслуживания. Практически в каждом новом коммутаторе на рынке, по крайней мере, некоторые из групп RMON реализованы на микросхемах. Наценка сравнительно мала, а потребность в управлении велика настолько, что администраторы сетей довольно часто отказываются покупать коммутаторы без встроенных средств RMON.

Недавно появилось еще одно возможное решение проблемы невидимых сетевых сегментов. Обычные сетевые узлы - рабочие станции и серверы - с мощными процессорами и многозадачными операционными системами типа Unix, Windows NT, OS/2, NetWare и Windows 95 имеют достаточную мощность для временного выполнения агента RMON при возникновении проблем в сегменте. Они даже в состоянии осуществлять мониторинг на постоянной основе.

Поняв связь между RMON и коммутаторами кадров, легко видеть, почему в начале 1996 года 3Com потратила 65 млн. долларов на покупку Axon Networks, а Bay Networks приобрела Armon Networking за 33 млн. долларов. Судя по всему, эти два сетевых гиганта осознали, что технология RMON слишком крепко связана с их стратегическими интересами. Настолько крепко, что они больше не могут себе позволить покупать ее на открытом рынке - лучше иметь эти ресурсы внутри компании. С другой стороны, Cisco продолжает сотрудничество с Frontier Software в области RMON, и во время написания статьи Cisco еще не добавила Frontier к длинному списку своих приобретений.

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

Задача управления коммутируемыми сетями не осталась без внимания Network General, ведущего производителя инструментов для анализа протоколов. Просмотр множества коммутируемых сегментов с помощью анализатора протоколов Sniffer может оказаться просто потерей времени. Несмотря на то, что Network General, продавая нестандартизованные зонды Distributed Sniffer, была традиционно далека от мира RMON и SNMP, она начала присматриваться и приноравливаться к этим стандартам управления. (Дополнительную информацию о стандартах управления можно найти во врезке "SNMP и RMON".) Компания объявила об архитектуре Total Network Visibility для сбора данных от агентов SNMP и RMON, Expert Sniffers, серверов Novell и NT и даже от баз данных и другого прикладного программного обеспечения. Experience Technology Engine будет анализировать и сводить вместе эти данные. (Experience Technology Engine - программный слой ниже серии новых приложений управления, среди которых монитор состояния сети, диспетчер диагностики, анализатор тенденций и диспетчер приложений.)

Enterprise LANMeter компании Fluke представляет собою портативный прибор с жидкокристаллическим экраном и клавиатурой. Он предназначен для тестирования кабеля и проверки работы сетевых плат и концентраторов: его программное обеспечение может анализировать и отображать часть собираемой сетевыми мониторами информации, в том числе статистику по кадрам и протоколам и таблицу адресов маршрутизатора. LANMeter всегда умел собирать данные от агентов MIB-2 и RMON в сетях IP. Новая опция SwitchWizard Option позволяет отображать статистику о нескольких портах коммутатора одновременно. Он способен определять и составлять список всех MAC-адресов на порту коммутатора. В случае устройств с агентами SNMP и RMON LANMeter может отображать информацию об ошибках не только для портов Ethernet на 10 Мбит/с и Token Ring, но и для портов Fast Ethernet и FDDI. SwitchWizard - программное обновление для Enterprise LANMeter - жизненно необходимый инструмент для тех пользователей, кому приходится иметь дело с коммутируемыми сетями.

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

Однако все далеко не так безоблачно. Cisco, Cabletron, Bay Networks, 3Com, Digital Equipment и IBM, не говоря о других, приступили к реализации архитектур виртуальных сетей, причем эти виртуальные сети не взаимодействуют друг с другом. Процесс стандартизации ATM RMON завяз в обсуждениях. В определенной степени стандартизация протоколов управления стала заложником рыночной баталии за будущее маршрутизации и коммутации. Сообразительные и настойчивые поставщики могут добиться заметных успехов в деле построения полностью управляемых самовосстанавливающихся сетей, однако никакого конца глубинным сдвигам, в результате которых все новые и новые проблемы возникают перед администраторами сетей, не предвидится.

РАЗДЕЛЯЕМЫЕ СЕТИ НА 100 МБИТ/С ПРЕДСТАВЛЯЮТ СОБОЙ АЛЬТЕРНАТИВУ КОММУТИРУЕМЫМ СЕТЯМ

Поделись с другим

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

Порты повторяющего концентратора 100Base-T в среднем дешевле коммутируемых портов на 10 Мбит/с. Концентраторы поддерживают как проводку Категории 3, так и проводку Категории 5. В принципе, возможна некоторая заминка при замене сетевых плат, но многие администраторы сетей уже установили сетевые платы на 10/100 Мбит/с в новые системы после того, как разница в цене с платами на 10 Мбит/с стала составлять менее 20%.

Разделяемая сеть на 100 Мбит/с может иметь даже меньшее время отклика, чем выделенный канал на 10 Мбит/с. Несмотря на вероятность конфликтов в сети на 100 Мбит/с для каждой данной транзакции, скорость передачи пакетов может оказаться выше. Пользователи же сегмента на 10 Мбит/с никогда не смогут достичь пропускной способности больше номинальной.

Что касается управления, то для полного управления разделяемой высокоскоростной сетью один монитор или зонд RMON вполне достаточен. Необходимость просмотра множества отдельных сегментов отпадает. При всем при том, что управление разделяемой сетью на 100 Мбит/с имеет много общего с управлением разделяемой сетью на 10 Мбит/с, сделать это с помощью тех же самых инструментов нельзя. Например, анализатор протоколов Sniffer компании Network General не годится для сбора всех кадров при скорости передачи 100 Мбит/с. Вместо этого компания рекомендует установить фильтры для выделения только представляющего интерес трафика. Имеются и зонды RMON для сетей 100Base-T, но стоят они значительно дороже, чем зонды для более медленных сетей. Конечно, если тестеры не способны диагностировать проблемы при частоте 100 МГц, проку от них в сетях на 100 Мбит/с мало. В настоящее время портативные диагностические инструменты используются для работы в сетях Ethernet на 10 Мбит/с и Token Ring на 16 Мбит/с - хотя LANMeter компании Fluke имеет аппаратную опцию для тестирования кабеля при частоте 100 МГц и может собирать данные SNMP MIB-2 и RMON о высокоскоростных портах, несмотря на отсутствие полноценного интерфейса на 100 Мбит/с.

Учитывая все факторы, нельзя утверждать, что коммутируемые сети на 10 Мбит/с (или коммутируемые сети Token Ring) в любой ситуации лучше (или дешевле), чем разделяемые сети на 100 Мбит/с. Однако коммутация получила непропорциональную популярность в умах и в прессе. И все же не забывайте о том, что разделяемая высокоскоростная сеть, возможно, будет лучше соответствовать вашим требованиям.

ДВА ВЗАИМОСВЯЗАННЫХ СТАНДАРТА INTERNET СЛУЖАТ ОСНОВОЙ ДЛЯ МНОГИХ СИСТЕМ УПРАВЛЕНИЯ

SNMP и RMON

SNMP имеет два главных компонента: транспортный механизм для перемещения данных управления по сети и схему или шаблон данных, известный как база управляющей информации, или MIB. Удаленный мониторинг (RMON) - это расширенная база управляющей информации для поддержки приложений, которым необходимо больше данных, чем SNMP MIB-2 способна предоставить. (Дополнительную информацию см. в статье "Алмаз неограненный" в декабрьском номере LAN Magazine/Русское издание за 1995 год).

Когда в 1988 году стандарт SNMP был принят, необходимая агенту SNMP MIB-2 вычислительная мощь была чересчур велика для тогдашних процессоров. Современные процессоры же достаточно мощны, так что реализация MIB-2 не требует значительных затрат вычислительных ресурсов. Объекты или переменные MIB-2 опрашиваются приложением управления, а оно, со своей стороны, хранит и манипулирует полученными данными.

Однако RMON MIB содержит более сложные типы данных. Агент RMON, использующий транспортный механизм SNMP для связи с приложением управления, производит более сложную обработку данных, чем агент MIB-2. Например, RMON MIB имеет группу n первых хостов topn, для которой агент должен ранжировать определенное число хостов в соответствии с другими статистическими данными, например числом кадров или числом ошибок.

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

В то же время сегмент при наличии в нем агента RMON способен сообщить о трафике в сети, а не только о трафике к интерфейсу конкретного устройства; причем RMON позволяет анализировать обмен данными, а не просто совокупный поток данных. Агент RMON может сообщить статистику по каждому хосту (MAC-адресу) в сегменте (а не по одному устройству с установленным на нем агентом).

Агентам SNMP MIB-2 необходимо открыть сеансы с управляющими приложениями, причем оба участника должны быть на линии во время сеанса постоянно. Агенты RMON работают в автономном режиме. Они могут собирать и анализировать данные даже при отсутствии соединения с управляющим приложением.

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

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

Окончательная стандартизация RMON-2 ожидается уже более года. Слыша "на днях" из месяца в месяц, вряд ли кто-нибудь поверит каким-либо прогнозам. Версия 2 расширяет возможности RMON MIB до сетевого и прикладного уровней, причем последний включает все уровни над первым. Таким образом, диалоги и матрицы диалогов сетевого уровня, а также диалоги и матрицы диалогов прикладного уровня будут рассматриваться стандартным образом. Заметим, что большинство используемых сегодня зондов и приложений RMON собирают и накапливают на верхних уровнях статистику и анализируют ее. Проблема в том, что высокоуровневые расширения MIB не стандартизованы, а значит, взаимодействие зондов и приложений различных производителей практически невозможно. Давно ожидаемая стандартизация RMON-2 сделает высокоуровневый анализ реальным в случае сетей с зондами от различных поставщиков и откроет новые возможности разработчикам приложений для RMON.