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

Маршрутизаторы и концентраторы правят миром сетей, но все чаще и чаще вместо них используют коммутаторы. Так что же предпочесть?

РАЗВЕРТЫВАНИЕ RMON: КЛЮЧ К УПРАВЛЕНИЮ КОММУТАЦИЕЙ
RMON для коммутаторов

Наилучший выбор для соединения сетей колеблется, согласно некоему естественному закону природы, между мостами и маршрутизаторами. В настоящее время коммутаторы (это название получили многопортовые мосты, возможно, с теми или иными функциями маршрутизаторов) одерживают победу в этом затяжном конфликте - согласно данным Strategic Network Consulting, даже Cisco Systems, оплот маршрутизации, во втором квартале 1997 года получила больший доход от продажи коммутаторов, чем от маршрутизаторов.

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

Давайте посмотрим на цифры. Цена управляемого коммутируемого порта на 10 Мбит/с в коммутаторе с портом для каскадирования на 100 Мбит/с приближается к 100 долларам. С помощью маршрутизации сегментировать сеть на всем пути до отдельного пользователя вообще нецелесообразно. Помимо того факта, что наиболее дешевые порты маршрутизатора дороже по крайней мере в три или четыре раза портов коммутатора, административная нагрузка по управлению одним узлом на каждом порту оказывается просто нетерпимой. Даже если сеть, микросегментированная с помощью маршрутизаторов, передает только трафик TCP/IP, сочетание высокой стоимости и ограниченной производительности, множество подсетей и обязанностей по конфигурации делают ее неработоспособной.

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

Как правило, коммутируемая сеть - это плоская сеть. Если каждый узел подключен к своему собственному коммутируемому порту, то конфликты в сети практически исключены: только приходящий трафик будет конкурировать с исходящим трафиком. Для сравнения в традиционном разделяемом сегменте или кольце пропускная способность, доступная каждому узлу, меняется обратно пропорционально числу узлов. Например, сеть 10BaseT с 25 узлами может предоставить в среднем 400 Кбит/с для каждого узла, в то время как узел с выделенным портом коммутатора получает 10 Мбит/с.

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

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

КОНТРОЛЬ ЗА СЕТЬЮ

Традиционно разделяемая среда, такая как коллизионный сегмент Ethernet или кольцо Token Ring, была базовой единицей управления. При подключении в любом месте сегмента или кольца анализатор протоколов собирал информацию об обмене сообщениями между всеми узлами. Агент SNMP на концентраторе собирает статистику о трафике, ошибках и широковещательных сообщениях во всем сегменте. Зонд RMON, другой тип сетевого монитора, представляющий собой карманное диагностическое устройство, собирает данные о всех значительных событиях в разделяемой среде. Эти устройства выполняют контрольно-измерительную функцию - основную работу по сбору данных, необходимую для управления сетью.

Аналогичные приборы требуются и для управления сетью. Число сегментов или колец возросло, причем если учитывать еще магистральные сегменты - настолько, что иногда превышает число узлов. Как результат, необходимое количество приборов умножается, а ведь многие автономные зонды RMON для обычного 10BaseT стоят более 2000 долларов за штуку.

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

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

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

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

УПРАВЛЕНИЕ ВИРТУАЛЬНЫМИ ЛОКАЛЬНЫМИ СЕТЯМИ

Наиболее полезные виртуальные локальные сети тесно связаны с коммутируемыми сетями. Однако реализация виртуальных сетей полностью меняет методы управления. Виртуальные сети определяют логические (настраиваемые широковещательные) домены, которые накладываются на возможные планы вашей сети. Скорее всего платформа управления сетью имеет IP-центрическую карту сети. Иногда она позволяет создать карту на базе IPX. При применении виртуальных локальных сетей их топология может не соответствовать другим планам (см. Рисунки 1 и 2). В то же время вы, по всей видимости, будете заинтересованы в мониторинге трафика и генерации предупреждений для каждой виртуальной сети в отдельности.

По состоянию на середину 1997 года все виртуальные сети на базе коммутаторов являются нестандартными. Комитет IEEE 802.1Q распространил несколько черновых проектов. Когда работа будет завершена, пользователи получат независимый от производителя метод информирования о членстве в виртуальной сети с помощью поля метки в каждом кадре. Аналогичная работа в комитете 802.1p должна завершиться разработкой стандарта для многоадресных объявлений о членстве в виртуальной сети с учетом роли виртуальных сетей как ограничителя широковещательного трафика. До воплощения этих стандартов в виде интероперабельного программного и аппаратного обеспечения виртуальные сети могут быть реализованы лишь в коммутируемой среде с продуктами от одного поставщика.

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

Мало того, единственным местом, где данные о виртуальной сети на основе нескольких коммутаторов могут быть собраны, является канал между коммутаторами, или магистраль. В крупной сети магистраль почти наверняка имеет пропускную способность 100 Мбит/с и выше. Высокоскоростные зонды еще далеко не так распространены, как зонды для обычных локальных сетей, а кроме того, они значительно дороже. Во время написания этой статьи многие поставщики объявили о коммутаторах Gigabit Ethernet, а вот о зондах с такой пропускной способностью пока еще никто не заявлял.

КОНФИГУРАЦИЯ И АДМИНИСТРИРОВАНИЕ

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

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

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

32-разрядных IP-адресов назначение адресов подсетям носит изотерический характер и зависит от наличия опыта в двоичной арифметике. Как следствие, перемещения, добавления и изменения в IP-сетях требуют много труда, времени и денег, и при этом вы не гарантированы от ошибок. Кроме того, перенумерация сети в случае смены оператора Internet или принятия новой политики безопасности - просто неподъемная задача для многих администраторов сети.

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

Однако некоторые новые технологии "коммутации третьего уровня" достигли той точки, когда виртуальная сеть, состоящая из случайных IP-адресов, будет не такой уж экзотической возможностью. Например, SecureFast Virtual Networking компании Cabletron, реализованная в уже доступных коммутаторах и серверах, использует модель сервера маршрутов вместо традиционной маршрутизации между членами виртуальной сети в различных подсетях. Первый пакет от отправителя к получателю поступает на сервер маршрутов для вычисления. Однако коммутатор запоминает маршрут, так что последующие пакеты коммутируются на втором уровне. При полномасштабном определении виртуальной сети на базе IP-адресов

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

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

ЧТО ДЕНЬ ГРЯДУЩИЙ НАМ ГОТОВИТ?

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

Одно из наиболее обещающих применений таких динамических виртуальных сетей - это DynamicAccess компании 3Com с предоставлением нескольких классов услуг для инфраструктур на базе Ethernet и Token Ring в соответствии с определенными правилами. Например, конкретным пользователям и высококритичным приложениям может быть присвоен наивысший приоритет. Флаг приоритета выставляется сетевой платой конечного узла, так что правила действуют из конца в конец сети, а не только на маршрутизаторах и коммутаторах внутри сети. Кроме того, DynamicAccess служит базисом для Fast IP, "сквозной" технологии 3Com, благодаря которой трафик между подсетями может использовать любые доступные быстрые коммутируемые каналы вместо маршрутизируемых каналов. По существу DynamicAccess и FastIP определяют виртуальную сеть на время диалога.

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

РАЗВЕРТЫВАНИЕ RMON: КЛЮЧ К УПРАВЛЕНИЮ КОММУТАЦИЕЙ

RMON для коммутаторов

RMON MIB - это своего рода модульная структура для сбора данных о сети. Из девяти групп RMON, имеющих отношение к Ethernet, четыре, известные как мини-RMON, формируют базис для наиболее распространенных и необходимых функций мониторинга и оповещения. Это группы Statistics, History, Alarms и Events.

Следующие три группы RMON - Hosts, Hosts Top N и Traffic Matrix - собирают статистику о картине трафика между узлами в сегменте. Для магистрального коммутатора при большом объеме совокупного трафика или для канала к серверу статистика и предупреждения или события на основании этих групп были бы весьма ценными. Реализация производителем только первых четырех групп RMON в настольных коммутаторах вполне оправдана, в особенности если эти коммутаторы имеют порт для перевода трафика на другой зонд RMON со всеми реализованными группами. Магистральные коммутаторы иногда имеют зонд RMON со своим процессором для групп картины трафика вместе с аппаратными реализациями первых четырех групп на каждом порту.

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

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

Управляемая коммутируемая сеть должна поддерживать по меньшей мере четыре группы мини-RMON, а в магистральных сегментах - все группы RMON (еще лучше RMON-2); приложения RMON основных поставщиков в полной мере используют преимущества MIB. Другие любопытные инструменты управления, в том числе Service Level Manager компании Network General, Network Health компании Concord Communications, Enterprise LANMeter компании Fluke и продукт для управления приложениями Optimal Networks, используют преимущества RMON в сети.