Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
ДОМОЙПОДПИСКАГДЕ КУПИТЬСТАТЬИRambler's Top100   
 
 
 
    
ЖУРНАЛ
   
Главная
Архив новостей
Новый номер
Архив статей
Адреса в интернет

РУБРИКАТОР
   
• Колонка редактора
• Только на сервере
• Локальные сети
• Бизнес
• Корпоративные сети
• Услуги сетей связи
• Защита данных
• Системы
   учрежденческой связи

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

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

РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Тематический план
Отдел рекламы

E-MAIL


Rambler's Top100

  

Внедрение приоритизации трафика в сети Ethernet

Эрик Холл

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

Именно в такой ситуации службы контроля за перегрузками сети и приоритизации трафика становятся необходимыми. Не относитесь к ним как к излишней роскоши: их внедрение весьма перспективное направление развития сетевых инфраструктур.

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

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

Чтобы решить эту проблему, институт IEEE разработал два проекта стандартов, обеспечивающих возможность реализации данных служб. Первый из них -- 802.1p -- это расширение стандарта моста 802.1D; в нем описывается, как должна происходить приоритизация трафика в мосте уровня MAC независимо от поддерживаемых им среды и технологии передачи данных. Второй -- 802.1Q определяет способ передачи трафика ВЛВС (виртуальных ЛВС) и поддерживает приоритизацию трафика в сетях Ethernet. Используя соответствующие стандарту 802.1Q кадры Ethernet и совместимые со стандартом 802.1p коммутаторы, можно реализовать полнофункциональные службы приоритизации трафика.

Три "заветных" бита

Как уже отмечалось, проект стандарта 802.1p определяет, каким образом приоритизация трафика должна быть реализована в мостах MAC-уровня.

Осуществить это планируется путем использования 3-битового независимого от типа сетевой технологии приоритета пользователя. Принимаемый мостом кадр может быть проверен на наличие в нем предусмотренной в той или иной сетевой технологии информации о приоритете трафика, которая затем отображается на систему приоритетов стандарта 802.1p (в соответствии с таблицей, определенной спецификацией 802.1p). При передаче кадра в сеть его уровень приоритета 802.1p может быть преобразован в приоритет используемой сетевой технологии передачи данных. Такой механизм обеспечивает создание стандартной и независимой от типа сетевой технологии службы приоритизации.

Использование 3-битового идентификатора позволят определить восемь различных уровней приоритета (от 0 до 7), отображаемых на системы приоритетов, имеющихся в некоторых сетевых технологиях. Например, все восемь уровней приоритета 802.1р напрямую отображаются на соответствующее число уровней приоритета, предусмотренных в стандартах 802.4 и 802.6. Однако в стандарте 802.9 отсутствуют числовые приоритеты, а стандартом 802.12 определена только пара числовых уровней приоритета.

Технология Ethernet не имеет системы приоритизации вообще, поскольку ориентирована на конкурентный доступ узлов сети к совместно используемой среде передачи данных. Этот недостаток можно устранить с помощью поддержки стандарта 802.1Q, в котором предусмотрено добавление в заголовок кадра Ethernet 4 байт данных. В них содержатся различные поля, в основном относящиеся к данным ВЛВС, но одно поле - длиной 3 бита - представляет собой идентификатор уровней приоритета. Оно дает возможность использовать восемь таких уровней, соответствующих системе приоритетов стандарта 802.1p. В заголовке кадра Ethernet поля 802.1Q размещаются между адресом отправителя и полем с информацией о длине кадра полезной нагрузки 802.3 (кадр Ethernet) или о типе протокола более высокого уровня (кадр Ethernet II).

Реализация и совместимость

В настоящее время сетевые фирмы создают первые версии продуктов, поддерживающие стандарты 802.1p и 802.1Q. Поскольку многие производители коммутаторов Ethernet уже реализовали службы приоритизации собственной разработки, включить поддержку стандарта 802.1p в свои продукты не составит для них большего труда, но обеспечить поддержку дополнительных полей 802.1Q в заголовке пакета Ethernet им будет значительно труднее. Более того, они должны найти способ обеспечить обратную совместимость с существующим сетевым оборудованием.

Очевидно, что изменение структуры кадра Ethernet влечет за собой возникновение серьезных проблем. Ведь он теряет совместимость со всеми традиционными устройствами Ethernet, ориентированными на старый формат кадра. В самом деле, из-за того, что данные 802.1Q размещаются перед полем с информацией о длине полезной нагрузки (или типе протокола), традиционный сетевой продукт не обнаружит эту информацию на привычном месте и вместо нее "прочитает" число x8100 -- значение по умолчанию нового поля "Тег протокольного идентификатора" (Tag Protocol Identifier) в кадрах 802.1Q. Мы обнаружили, что сетевой анализатор Surveyor фирмы Shomiti Systems успешно декодирует данные 802.1Q, но все остальные анализаторы, которые мы пытались использовать, определяли тип кадра 802.1Q либо как "неизвестный", либо как "Wellfleet" (компания Wellfleet одно время применяла тип х8100).

Источником проблем является не только изменение в размещении полей заголовка кадра Ethernet, но и увеличение максимальной длины данного кадра. Многие сетевые устройства не способны обрабатывать кадры длиннее 1518 байт. Между специалистами возникли споры по поводу того, нужно ли максимальный размер кадра Ethernet удлинять на 4 байт, или следует укоротить на 4 байт максимальный размер полезной нагрузки и таким образом скомпенсировать увеличение заголовка. Спецификация 802.1Q предусматривает оба подхода, поэтому производителям самим предстоит обеспечивать взаимную совместимость своих продуктов.

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

Как мы тестировали

Для того чтобы определить, насколько сильно приоритизация трафика влияет на работу перегруженной сети, мы задействовали Ethernet-коммутатор CoreBuilder 3500 фирмы 3Com и подключили к нему компьютеры, оснащенные совместимыми со стандартом 802.1Q адаптерами Ethernet той же фирмы.

CoreBuilder 3500 имеет четыре различные очереди пакетов и поддерживает множество сред передачи данных. Он также совместим со стандартами 802.1p и 802.1Q. Каждый порт этого коммутатора может взаимодействовать как с традиционным сетевым устройством, так и с оборудованием, поддерживающим стандарт 802.1Q. CoreBuilder 3500 обрабатывает уже приоритизированные пакеты или сам приоритизирует их, назначая трафику того или иного протокола заданный уровень приоритета. Например, для того чтобы присвоить трафику системы Notes более высокий уровень приоритета, по сравнению с потоком данных RealAudio, нужно активизировать в коммутаторе фильтры пакетов этих приложений, а затем установить для них желаемые уровни приоритетов.

Сетевые платы фирмы 3Com поддерживают стандарт 802.1Q с помощью произведенного ею же ПО DynamicAccess. В настоящее время данное ПО совместимо с Windows 95 и Windows NT, а также поддерживает протоколы IP и IPX в сетях Ethernet и Token Ring. Предполагается, что последующие его версии будут работать под управлением Unix и NetWare, а также поддерживать адаптеры FDDI.

В ходе тестирования два клиентских компьютера фирмы Dell Computer, оснащенные 200-МГц процессорами, пересылали UDP и TCP-пакеты на сервер Dell PowerEdge с 266-МГц процессором. Компьютеры передавали данные со скоростями до 100 Мбит/с, а сетевой интерфейс сервера имел пропускную способность, равную 10 Мбит/с, что позволило нам создать довольно сильные перегрузки в серверном сегменте. Мы меняли уровни приоритетов клиентских компьютеров и подсчитывали пакеты, полученные от каждого из них.

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

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

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

Большинство программ для работы с электронной почтой или с базами данных используют протокол TCP, поэтому с целью эффективного использования приоритизации в этих приложениях необходимо реализовать ее поддержку на всех оконечных узлах сети. Впрочем, это положительно скажется даже на тех приложениях, которые фиксированы на протокол UDP (к ним относятся, например, системы передачи речи по протоколу IP).

Возможности оборудования очень важны...

Такая же ситуация возникла и при проведении другого теста, в котором мы подключали сервер к традиционному коммутатору (не совместимому с 802.1Q), а клиентские компьютеры (с различными уровнями приоритетов) оставили подсоединенными к коммутатору CoreBuilder 3500. Оба этих коммутатора были связаны между собой.

Система хорошо работала во время испытаний с использованием протокола UDP (в нем клиенты просто "проталкивали" пакеты сквозь коммутатор CoreBuilder 3500 на традиционный коммутатор), но, как и раньше, при работе с TCP скорость передачи оказалась относительно невысокой. В этом случае подтверждения приема пакетов, передаваемые сервером через традиционный коммутатор, задерживались в CoreBuilder 3500. Проблему удалось решить, включив поддержку приоритизации на порте последнего, подсоединенном к традиционному коммутатору.

Тестовая среда с поддерживающим и не поддерживающим стандарт 802.1Q коммутаторами была рекомендована нам фирмой 3Com. Сети такого типа будут широко использоваться при переходе к приоритизации трафика. Важно представлять себе, что такая среда может оказать заметное отрицательное влияние на параметры TCP-соединений, которые сильно зависят от того, имеется ли у узлов на концах этих соединений возможность быстро передавать данные. Чтобы свести к минимуму это влияние. включайте поддержку приоритизации на всех подключенных к сети портах.

Еще один аспект, который может повлиять на эффективность приоритизации трафика, -- число очередей, поддерживаемых коммутатором, и возможности последнего по их обработке. Например, коммутатор CoreBuilder 3500 имеет только четыре очереди, хотя стандарт 802.1Q предусматривает восемь уровней приоритета. В результате мы были вынуждены с каждой из очередей ассоциировать по нескольку уровней приоритетов, что уменьшило гибкость управления трафиком. Чтобы в полной мере воспользоваться возможностями приоритизации, предусмотренными стандартами 802.1p и 802.1Q, вам потребуется оборудование с восемью очередями.

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

...Однако пропускная способность сетевого канала важнее

Самая серьезная проблема, из тех, с которыми мы столкнулись, возникла в условиях длительного тестирования. Чем дольше мы передавали данные, тем чаще низкоприоритетный узел просто "отваливался" от сети. Выяснилось, что при длительной перегрузке высокоприоритетный узел постепенно "забирал" себе все ресурсы коммутатора, и поэтому все чаще и чаще терялись пакеты с низким уровнем приоритета.

В случае применения протокола UDP потери для низкоприоритетной клиентской машины совершенно не имели значения: она посылала и посылала пакеты, "не заботясь" о их дальнейшей судьбе. При этом серверу "казалось", что ее трафик просто остановился. С использованием протокола TCP ситуация была иной: передав несколько пакетов и не получив подтверждений их приема, клиентская машина разрывала связь с сервером.

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

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

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


Бензиновые пилы бензопила.




  
11 '1998
СОДЕРЖАНИЕ

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

• Наперегонки со светом

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

• Внедрение приоритизации трафика в сети Ethernet

• Удаленная загрузка Windows 95

• В эпоху интеллектуальных зданий

• Консолидация информационно-вычислительных ресурсов

• Коммутаторы для рабочих групп: мал золотник, да дорог

• Цифровые мультиметры на страже безопасности

• Место коаксиальных кабелей вне локальных сетей

• Один дюйм или два?

бизнес

• О российском канале дистрибуции

• Профессор сетевых технологий

• Oracle побеждает в SQL-гонке

интернет и интрасети

• Приоритизация трафика в сетях IP

• Отладка работы PPP-соединений

• ISP все еще решают проблему пиринга

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

• Тестируем связующее ПО МОМ

• Платформам сетевого управления недостает лидера

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

• IP-телефония: проблем хватает

• Предоставление услуг IN на сети МГТС

• Спутники облегчают доступ ко Всемирной паутине

• Мониторинг трафика Frame Relay: выгода налицо

• DSL: скорость и средства для ее контроля

• DSL: трудная дорога к стандартам

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

• ИБП для централизованной системы бесперебойного гарантированного электроснабжения

системы учрежденческой связи

• Отечественные УАТС: с оптимизмом — в будущее

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

• PairView "найдет" потерянные пары; Простота и эффективность Novell Replication Services 1.21;



 Copyright © 1997-2001 ООО"Антонюк Консалтинг". Тел. (095) 234-53-21. Факс (095) 974-7110. вверх