Конвергенция передачи голоса, видео и данных в корпоративных сетях и потребность в сокращении командировочных расходов обусловили повышенный интерес к приложениям IP-телефонии и видеоконференц-связи. Все это, наряду с сохраняющимся стремлением достичь максимальной производительности важнейших корпоративных приложений (даже после урезания IT-бюджетов), заставило сервисы класса best effort безвозвратно кануть в Лету.
Под термином «качество сервиса» (Quality of Service, QoS) подразумевается несколько специфических методов и технологий обработки сетевого трафика. В результате любые попытки реализовать единую стратегию поддержки QoS для всей корпоративной среды наталкиваются на непреодолимые препятствия. Да и приложения, операционные системы и сетевое оборудование частенько оказываются ориентированными на разные механизмы QoS.
Иногда приходится слышать, что выход кроется в расширении суммарной полосы пропускания. Кому-то эта мера и поможет, но не надо забывать, что основная цель применения средств поддержки QoS состоит в передаче всего сетевого трафика с гарантированным соблюдением определенных условий, независимо от физической среды, будь то разделенный канал T1 или соединение Gigabit Ethernet. Для корпоративных заказчиков реализация какой-либо схемы QoS означает, что важнейшим бизнес-данным и трафику реального времени будет отведена та полоса пропускания, которая им необходима, причем вне зависимости от текущих условий функционирования сети (в том числе при внешних атаках, приводящих к отказам в обслуживании).
Внедрение методов QoS способно вдохнуть новую жизнь, казалось бы, в безнадежно перегруженные каналы глобальных сетей или соединения с Internet в тех случаях, когда увеличить общую полосу пропускания нельзя по финансовым соображениям. Именно возможность повышения эффективности использования уже имеющейся пропускной способности и ограниченность ITT-бюджетов заставляют большинство компаний обращать свои взоры на средства обеспечения QoS. Не надо забывать, впрочем, что выбор оптимальной схемы приоритизации трафика всякий раз зависит от конкретной ситуации.
На помощь приходят специальные устройства
Для многих организаций знакомство с миром QoS начинается со специального оборудования, устанавливаемого там, где оно особенно необходимо: это перегруженные сегменты распределенных сетей и соединения с Internet. Мы проанализировали устройства такого класса от пяти производителей, построив аналог корпоративной сети, которая объединяет основную локальную сеть с сетью удаленного офиса по линии frame relay. Корпоративный офис имел выход в Internet по сымитированному каналу DS-3. Наши тесты воспроизводили типичные ситуации, в которых внедрение QoS позволило бы улучшить функционирование перегруженной сети:
- внешнюю DoS-атаку, предпринятую через канал DS-3 с целью снизить производительность корпоративного Web-сервера;
- пакетную передачу трафика видеоконференций и голосовых потоков по перегруженным каналам распределенной сети;
- перегрузку канала DS-3 Web-трафиком и потоками других типов, не позволявшую запустить сеанс дистанционного обучения с передачей файлов в стандарте MPEG-2.
Экстремальные сетевые перегрузки, создававшиеся в каждом тесте, вызывали перебои в функционировании приложений. Так, быстродействие Web-сервера падало практически до нуля, а передача видеоконференц-трафика и осуществление звонков по технологии VoIP оказывались попросту невозможны.
Кроме того, для каждого устройства локальной сети мы измеряли базовую пропускную способность, в том числе для пакетов минимальной длины, поскольку эти продукты изначально рассчитаны на работу в высокопроизводительных сетях. Несмотря на то что большинство изделий не в состоянии корректно обработать основную массу поступающих коротких пакетов (длиной менее 512 байт) с физической пропускной способностью линии, передача по сети значительного числа таких пакетов не является типичной, и это ограничение стоит принять во внимание лишь в том случае, если высокий процент таких пакетов характерен для вашей сети.
Для моделей, рассчитанных на применение исключительно в распределенной сетевой среде, прогон полного набора тестов оказался невозможным.
NetEnforcer 201 и 301
Эти два продукта компании Allot Communications относятся к категории специализированных QoS-устройств для локальных сетей. Оба они имеют по одному внешнему и внутреннему порту с быстродействием 10/100 Мбит/с. Модель 201 поддерживает сетевые конфигурации с пропускной способностью от 2 до 10 Мбит/с, а устройство 301 — со скоростью до 100 Мбит/с. В тестах на базовую производительность степень прохождения 64-байтовых пакетов составила 32%, однако по мере увеличения длины пакетов до 512 байт значение данного показателя линейно возрастало до 100%.
В NetEnforcer реализована двухстадийная схема классификации трафика, основанная на использовании трубок (pipes) и виртуальных каналов, на каждый из которых распространяются определенные правила и действия. Трубки находятся на вершине иерархии и обычно применяются для дифференциации трафика, поступающего от разных узлов. В рамках одной трубки определяется несколько виртуальных каналов, служащих для приоритизации трафика разных пользователей и приложений. Нераспознанный трафик помещается в трубку с самым низким приоритетом. Классификация поступающих пакетов вплоть до седьмого уровня модели OSI поддерживается для нескольких распространенных протоколов, включая не принадлежащие к семейству IP. При помощи протокола Trivial FTP можно осуществить резервное копирование наборов правил и сведений о системной конфигурации, а также разослать их на другие устройства NetEnforcer. Несколько устройств NetEnforcer допускается объединять в общую сеть для резервирования функций QoS.
В тестах на производительность обе модели компании Allot зарекомендовали себя с самой лучшей стороны. Активизировав правила, разрешавшие блокировку трафика UTP, мы обнаружили, что быстродействие сервера HTTP при передаче пакетов других типов осталось на прежнем уровне. Правило, отдававшее предпочтение трафику HTTP (в ущерб любому другому), также оказалось весьма эффективным, а снижение производительности при атаке типа DoS — едва заметным. Модель NetEnforcer 201 испытывалась и на соединении глобальной сети: она успешно расклассифицировала практически все принятые пакеты по именам приложений. Функционирование программ видеоконференц-связи и пакетной телефонии было вполне предсказуемым, хотя это и потребовало перераспределения полосы пропускания.
Управление устройствами NetEnforcer осуществляется при помощи специального ПО, обеспечивающего прекрасно спроектированный графический Web-интерфейс и поддержку Java. Упомянутый интерфейс является довольно мощным инструментарием, хотя и отличается излишней сложностью. Мониторинг, «приближенный» к режиму реального времени, позволяет достоверно определить, какой трафик в данный момент циркулирует в сети и какие наборы правил активизированы. Для доступа к ОС Linux используется интерфейс командной строки (CLI), что придает продуктам Allot Communications дополнительную гибкость. Предлагаемое ПО включает в себя модули мониторинга, классификации трафика, активизации стратегий администрирования и генерации отчетов.
Кроме того, за отдельную плату фирма поставляет дополнительные программные модули, в числе которых NetAccountant (реализует расширенные функции учета, в том числе слежение за распределением полосы пропускания по определенным правилам), CacheEnforcer (поддерживает операции сетевого кэширования) и NetBalancer (предназначен для выравнивания серверной нагрузки). Компания продает также ПО для централизованного управления сразу несколькими узлами NetEnforcer, объединенными в группы по 5, 20, 50 и более устройств.
PacketShaper 2500 и 8500
Модель PacketShaper 8500 компании Packeteer способна распознавать наибольшее число тегов |
Продукты производства Packeteer также представляют собой специализированные QoS-устройства для локальных сетей. Каждое из них имеет по два порта — для входящего и исходящего трафика. Модель 2500 поддерживает скорости передачи в диапазоне от 2 до 10 Мбит/с, а 8500 — быстродействие до 155 Мбит/с (интерфейс OC-3). Как показали измерения базовой производительности, эти изделия способны пропускать более 90% пакетов минимального размера и все 100% пакетов, длина которых составляет не меньше 128 байт.
При первом включении устройства в сеть весь трафик по умолчанию приписывается к одной группе с учетом направления его следования (входящий или исходящий). Распознав пакеты какого-либо определенного типа, PacketShaper автоматически перемещает их из группы, созданной по умолчанию, в список типов расклассифицированного трафика. В большинстве случаев такая схема вполне работоспособна, тем не менее в сети может случайным образом возникнуть поток, который будет передаваться сколь угодно долго, оставаясь в очереди по умолчанию. Для множества протоколов классификация пакетов выполняется вплоть до седьмого уровня, причем продукты Packeteer в состоянии распознать ряд протоколов (IPX, AppleTalk, SNA), не принадлежащих к семейству IP.
Результаты тестов на производительность оказались выше всяких похвал. Обе модели PacketShaper сумели оперативно идентифицировать источник атаки DoS и заблокировать поступление нежелательного трафика. Правила, отдающие предпочтение пакетам HTTP, оказались очень эффективными, причем заметить разницу в быстродействии HTTP-сервера до и в процессе атаки было непросто. При обмене видео- и голосовым трафиком между центральным офисом и филиалом параметры соответствующих потоков были практически идеальными: для их передачи не потребовалось перераспределять имевшуюся пропускную способность, а изменения в конфигурации понадобились минимальные. В завершающем тесте без перераспределения полосы уже не обошлось (для защиты трафика MPEG-2), но этого следовало ожидать, поскольку потоки MPEG-2 весьма чувствительны к любым потерям пакетов или задержкам.
Графический Web-интерфейс, предназначенный для контроля за данными устройствами, разделен на четыре раздела — классификация трафика, анализ, управление и генерация отчетов. Он отличается высокой интуитивностью и крайней простотой в работе. Задавшись целью представить себе более детальную картину происходившего в сети (выяснить названия протоколов и проконтролировать выполнение правил приоритизации), мы были вынуждены переключиться на CLI-интерфейс. Жаль, что до этой информации не добраться через Web-интерфейс.
Для всех моделей PacketShaper доступны модули расширения локальной сети (LAN Extension Modules, LEM), позволяющие подключать эти устройства к дополнительной сети со скоростью передачи 10/100 Мбит/с (для модели 8500 — 1 Гбит/с). В результате уменьшается общее число устройств PacketShaper. Продукты фирмы Packeteer снабжены средствами резервирования и допускают горячую замену компонентов. Для централизованного управления наборами правил и генерации отчетов предлагаются программы PolicyCenter и ReportCenter.
QoSWorks 10000
QoSWorks 10000 производства Sitara Networks — типичный представитель специализированных QoS-устройств |
Эта разработка компании Sitara Networks относится к тому же классу, что и два предыдущих продукта, и поддерживает скорости передачи до 100 Мбит/с. Изделие имеет два порта, один из которых предназначен для подключения к локальной сети, а другой — к каналу глобальной сети. QoSWorks смог обработать лишь 30% поступивших пакетов минимальной длины, но после увеличения последней до 512 байт производительность вплотную приблизилась к пропускной способности физической среды передачи.
Нам удалось поработать с двумя версиями ПО, загружаемого в данное устройство, — это 1.9, уже знакомая пользователям, и 2.0, поставки которой стартовали в июне. Появление второй версии следует расценивать как большой шаг вперед, поскольку в ней реализованы функции классификации трафика седьмого уровня для многих распространенных протоколов, включая H.323 и HTTP, хотя на некоторые одноранговые приложения такая функция пока не распространяется. Кроме того, графический интерфейс на базе Java стал более динамичным: данные мониторинга теперь обновляются раз в минуту.
Устройство QoSWorks показало неплохую производительность. Оно мгновенно распознало источник атаки DoS и заблокировало его. Трафику HTTP был присвоен высший приоритет на прикладном уровне, так что нам не пришлось даже писать специального правила для случая атаки DoS, а быстродействие HTTP-сервера восстановилось на 90%. В испытаниях с каналами глобальной сети приоритизация трафика видеоконференции тоже осуществлялась на прикладном уровне, а голосового трафика — по IP-адресам. После активизации соответствующих наборов правил потери пакетов с видеоинформацией стали минимальными; голосовые же потоки отличались ясностью воспроизведения, хотя имели небольшую задержку. Для трафика реального времени QoSWorks позволяет ограничить размер очереди и тем самым снизить задержку передачи и ее нестабильность, что особенно полезно для хронически перегруженных сетей. Устройство способно пометить трафик, используя поле IP Precedence байта Type of Service (ToS), но не в состоянии присвоить приоритет помеченным таким образом пакетам.
Созданный фирмой Sitara управляющий интерфейс на базе Web прост в использовании и включает в себя разделы для мониторинга трафика, генерации отчетов и формирования наборов правил. Отчеты, выдаваемые практически в режиме реального времени, помогают оценить адекватность заданных наборов правил. А вот различить соединения локальных и глобальных сетей оказалось не так-то просто; этот пункт требует усовершенствования. Во второй версии микропрограммных средств не все интерфейсы переведены на Java, поэтому степень интеграции редактора правил и функций мониторинга нам показалась недостаточной. По заявлению производителя, следующие версии продукта будут свободны от этого изъяна.
Наконец, для централизованного управления правилами компания предлагает ПО QoSDirector, а целям резервирования служит продукт QoSArray, поставляемый отдельно от QoSWorks 10000.
ServicePoint 2040-tmc DSU
Это изделие корпорации Kentrox ориентировано на поддержку механизмов QoS в глобальных сетях и базируется на средствах классификации пакетов и приоритизации трафика, разработанных фирмой Packeteer. Продукт обладает встроенными функциями DSU/CSU, поэтому способен заменить уже существующие устройства DSU/CSU. Он подключается к последовательному выходу маршрутизатора, что упрощает его инсталляцию в распределенную сеть практически любой топологии. Как показали измерения производительности, ServicePoint 2040 пропускает трафик с максимальной скоростью, предусмотренной интерфейсом T1.
Поскольку продукт подключается непосредственно к каналу frame relay, он способен воспринимать события, которые, как правило, недоступны оборудованию локальной сети. Например, это обмен данными между локальными интерфейсами управления (LMI), преобразования DLCI или генерация трафика маршрутизатором (будь то пакеты VoIP, передаваемые в обход телефонных станций, или обновления таблиц маршрутизации). Описываемая модель распознает трафик по идентификаторам DLCI, что заметно облегчает написание правил, «привязанных» к постоянным виртуальным каналам (PVC) сети frame relay. В топологии с концентратором продукт ServicePoint 2040, размещенный в головном офисе компании, может инициировать применение определенных правил к трафику, который передается между сетями филиалов, что при определенных условиях позволит сократить общее число необходимых устройств.
К сожалению, в более сложных тестах на классификацию трафика и его обработку в соответствии с наборами правил мы натолкнулись на ошибку, которая не позволила корректно распознать некоторые типы пакетов. Хотя обнаружение ошибок в процессе тестирования не является чем-то из ряда вон выходящим, в данном случае проявилась функциональная ограниченность продукта Kentrox. Во-первых, трафик должен быть предъявлен устройству до того, как будут сформулированы распространяющиеся на него правила. Другими словами, наборы правил не могут быть написаны заранее либо основываться исключительно на IP-адресах. Во-вторых, если трафик не был распознан средствами классификации, графики и отчеты об использовании полосы пропускания не выводятся вовсе. В итоге достаточно загруженный канал T1 на управляющей консоли порой представляется практически пустым. Впрочем, представители компании уверили нас в том, что обнаруженная ошибка уже устранена в обновленной редакции ПО.
Для администрирования устройств ServicePoint 2040 служит ПО ServicePoint Manager, которое продается отдельно, но совершенно необходимо для целей мониторинга и управления трафиком, проходящим через блоки DSU. Его серверная часть работает под Windows NT или Windows 2000 Server, а клиентская — под Windows 98 и более поздними версиями. Пользовательский интерфейс достаточно интуитивен и предоставляет доступ к широкому спектру функций, включая мониторинг всех блоков DSU в режиме, близком к реальному времени, централизованное хранение и реализацию наборов правил, а также генерацию отчетов. Данное ПО допускает масштабирование до уровня 600 управляемых блоков DSU, однако эта цифра станет еще больше, если установить программные агенты удаленного сбора управляющей информации.
WiseWan 201 и 601
Два представителя семейства WiseWan компании NetReality выпускаются в вариантах для локальных и глобальных сетей. Первый поддерживает скорости передачи до 2 Мбит/с и снабжается либо последовательным интерфейсом, либо портом Ethernet, либо интегрированными функциями DSU/CSU. Для подсоединения к сети служит специальный кабель WiseCable, оставляющий соединение пассивным до тех пор, пока устройство не будет активизировано. Модель WiseWan 601 поддерживает протокол Ethernet и HSSI при скоростях передачи до 52 Мбит/с. Мы проверили работу устройства WiseWan 201 с последовательным интерфейсом, разместив его между маршрутизатором и сетью frame relay, а WiseWan 601 — с двумя интерфейсами Fast Ethernet. Модель 601 успевала обрабатывать все пакеты с установленной скоростью передачи независимо от их размера.
В большинстве тестов результаты, показанные устройствами WiseWan, не вызвали особых нареканий. При имитации атаки DoS пакеты HTTP получили наивысший приоритет, а производительность сервера составила 90% от значения, зафиксированного до начала атаки. Правила, задававшие приоритизацию видеоконференц-трафика (в стандарте H.323) и голосовых потоков, обеспечили требуемое качество голоса и видео даже в перегруженной сети (с минимальными погрешностями в воспроизведении видео).
После отправки в сеть значительного объема трафика, который не был ориентирован на установление соединения (UDP), соблюдение стратегий приоритизации устройством WiseWan, подключенным к «глобальному» порту маршрутизатора, натолкнулось на некоторые затруднения. Причина заключалась в следующем: в отличие от TCP, в протоколе UDP отсутствуют встроенные средства предотвращения перегрузок, поэтому QoS-устройство не может отправить передающему узлу сообщение о необходимости снизить скорость посылки пакетов. А поскольку сам маршрутизатор начинает отбрасывать пакеты только при превышении максимальной скорости последовательного интерфейса, трафик UDP и аналогичных протоколов способен «задавить» все другие. Это сильно осложняет гарантированное выделение приложениям требуемой полосы пропускания при наличии высокоинтенсивного трафика UDP или возникновении нештатных ситуаций (вроде атак DoS). Если такие ситуации нельзя исключить априори, лучше приобрести модификации WiseWan, ориентированные на работу в локальной сети.
Как и в случае с продуктом ServicePoint компании Kentrox, возможность подключения WiseMan к глобальной сети обеспечивает ему ряд уникальных функций. В частности, он способен выдавать информацию о сетевых перегрузках, контролировать несколько сетевых узлов и управлять трафиком, который генерируется маршрутизатором. WiseWan распознает пакеты множества распространенных протоколов — вплоть до седьмого уровня модели OSI.
Управление устройством осуществляется с использованием клиент-серверного приложения WanXplorer (мы тестировали версию 5.2), функционирующего в средах Windows и Solaris и поддерживающего SNMP. В хранящуюся на сервере базу данных помещаются сведения о наборах правил и статистическая информация, автоматически агрегируемая во времени. Для ее извлечения и модификации правил либо перенастройки конфигурации пользователь должен инициировать клиент-серверное соединение. Клиентское ПО или работает как обычное Java-приложение, или доступ к нему осуществляется через браузер.
Пользовательский интерфейс удачно спроектирован и отличается простотой в работе. Для создания и активизации наборов правил, а также перехода от одного набора к другому достаточно нескольких щелчков мыши. Конфигурационные данные хранятся на центральном сервере, что сильно упрощает замену отказавших устройств.
Procurve 9304m
Помимо тестирования специализированных устройств мы исследовали работу маршрутизаторов, наделенных средствами поддержки QoS и успешно работающих во множестве существующих сетей. Набор тестов остался прежним, что позволило выяснить, какие функции будут доступны пользователям за минимальную цену, а то и вовсе бесплатно. В нашем распоряжении оказалось два подобных устройства: Procurve 9304m корпорации Hewlett-Packard (известное также в качестве BigIron 4000 — продукта Foundry Networks) и 7206 VXR компании Cisco. Мы намеренно интересовались только теми функциями, которые типичны для большинства современных маршрутизаторов.
Procurve 9304m — высокопроизводительный коммутатор третьего уровня, обычно устанавливаемый в центральной части корпоративной сети. Он наделен базовым набором функций поддержки QoS, который характерен для сетевых устройств среднего или верхнего ценового диапазона.
Классификация пакетов, задаваемая соответствующим набором правил, может осуществляться на основании IP-адресов, служебных полей IP-пакетов, портов четвертого уровня (либо сразу по трем перечисленным параметрам), а также исходя из идентификатора виртуальной локальной сети, входных портов, MAC-адресов и сокетов протокола AppleTalk. Если трафик не допускает классификации на четвертом уровне (как это имеет место с протоколом H.323), необходимо задать правила классификации по IP-адресам отправителей или получателей. Кроме того, данный коммутатор способен обрабатывать заранее расклассифицированный и помеченный тегами трафик в соответствии со стандартом 802.1p или значением поля IP Precedence. По завершении классификации пакеты могут быть помещены в одну из четырех системных очередей, обслуживание которых выполняется в соответствии со строгой схемой приоритетов или заданных администратором весовых коэффициентов.
Сам производитель рекомендует второй способ — именно он и использовался в наших тестах. Трафику TCP Port 80 был присвоен наивысший приоритет, а все остальные пакеты помещались в очередь с самым низким приоритетом. После «отключения» набора правил Web-сайт вернулся к нормальному режиму функционирования, а отличие производительности от соответствующего значения для неперегруженной сети оказалось незначительным. Поскольку мы работали с соединениями Gigabit Ethernet, для генерации фонового трафика, достаточного для создания перегрузки и обеспечения конкуренции за полосу пропускания с трафиком Web-сайта, пришлось задействовать оборудование компаний Ixia и Spirent.
Тот же тест был запущен для сеанса видеоконференц-связи, проходившего по протоколу H.323 между двумя узлами корпоративной сети. Подобно большинству маршрутизаторов, Procurve 9304m не распознает трафик пятого и более высоких уровней, поэтому мы задали классификацию по IP-адресам. Активизация данного набора правил позволила вернуть качество воспроизведения видео на должный уровень, а искажения были несущественными.
Общий вывод сводится к тому, что реализованные специалистами HP базовые средства поддержки QoS весьма эффективны для прохождения ограниченного набора тестов. Правда, в данном случае вы должны точно знать, какой трафик передается по сети, а такую информацию можно получить лишь с помощью анализатора протоколов или удаленных программных зондов. Проектировщики модели Procurve 9304m и ей подобных с самого начала ориентировались на обработку тегов QoS (вроде значения поля IP Precedence) и приоритизацию трафика на их основе, но никак не на полноценную классификацию всех поступающих пакетов.
Cisco 7206 VXR
Данное устройство, относящееся к классу программных маршрутизаторов, с большой вероятностью можно обнаружить на периферии средней или крупной корпоративной сети. Использование программной основы имеет два важных следствия: реализованный здесь набор функций QoS несравненно богаче, чем в любом коммутаторе третьего уровня, зато быстродействие существенно ниже.
Мы тестировали данное устройство с операционной системой IOS 12.1 и первоначально действовали по той же схеме, что и с продуктом Procurve 9304m. Для распознавания трафика HTTP на фоне пакетов иных типов использовались списки доступа, а для помещения их в очередь — анализ классов трафика и правила приоритизации. В целях удовлетворения различных запросов приложений была выбрана схема очередей с весовыми коэффициентами, которые назначались с учетом класса трафика. (Другие возможные варианты — «взвешивание» потоков, очереди, учитывающие приоритеты или минимизирующие задержку передачи. Чтобы затормозить передачу трафика TCP, можно также использовать алгоритмы предотвращения перегрузок и правила, обеспечивающие передачу с гарантированной скоростью.) Как и в других тестах, даже в экстремальных условиях быстродействие Web-сервера практически не менялось.
Недавно появившаяся в арсенале Cisco технология Network Based Application Recognition (NBAR) позволяет маршрутизатору частично классифицировать даже трафик седьмого уровня — качество, присущее специализированным устройствам. Повторив тест на классификацию Web-трафика по URL-адресам (вместо номеров TCP-портов) с применением NBAR, мы получили те же результаты, однако при этом нагрузка на центральный процессор маршрутизатора заметно возросла. Поскольку теперь классификация осуществлялась для протоколов верхних уровней, нам не составило труда выставить одному URL более высокий приоритет, чем другим. Опять же, до последнего времени такую процедуру поддерживали только специализированные устройства. Конечно, последние распознают большее число протоколов, чем позволяет технология NBAR, однако благодаря модульной архитектуре маршрутизатора поддержка новых протоколов может быть добавлена без обновления системного ПО.
Как отмечалось выше, маршрутизатор Cisco обычно размещается ближе к периферии сети, поэтому зачастую именно на него возлагаются задачи классификации и маркировки трафика. Задав правило маркировки исходящих пакетов при помощи IP Precedence, мы предоставили устройствам, расположенным ближе к ядру сети, возможность распознать уже помеченные потоки. Операция захвата трафика подтвердила, что значение указанного поля установлено корректно.
Работа с продуктом фирмы Cisco требует детального знания типов сетевого трафика. Сказанное означает, что пользователям данного устройства придется обзавестись средствами анализа протоколов, а также подробно разобраться в том, как разные протоколы реагируют на различные сетевые перегрузки, например, каковы различия между поведением HTTP и FTP в экстремальных ситуациях. Применение NBAR облегчает дело, но лишь при условии, что эта технология поддерживает интересующий вас протокол.
Сквозное QoS?
Рассмотренные продукты открывают путь к реализации полномасштабной стратегии в области обеспечения QoS. Применение специализированных устройств или небольших маршрутизаторов для классификации, маркировки и приоритизации трафика, а магистральных маршрутизаторов — для ускоренной транспортировки ключевых потоков позволит охватить механизмами QoS большинство сегментов корпоративной сети. Вне поля зрения останутся лишь настольные компьютеры, поскольку большинство средств QoS не обрабатывают трафик, поступающий от рабочих станций или серверов, до тех пор, пока он не достигнет первого маршрутизатора. Эту ситуацию трудно назвать удовлетворительной, ведь 100-мегабитное восходящее соединение от 24-портового коммутатора, поддерживающего 10/100-мегабитные сети Ethernet, нередко становится узким местом.
Механизмы QoS более всего пригодны для обработки трафика реального времени, и именно на нем пользователям стоит сконцентрировать свое внимание. Если у вас имеется оборудование, распознающее теги 802.1p (например, IP-телефон), и коммутатор, поддерживающий стандарт 802.1p и более одной входной очереди, считайте, что вам повезло, по крайней мере в отношении сервисов, которые допускают маркировку пакетов. Мало того, в ряде последних моделей граничных коммутаторов реализована приоритизация трафика по значениям IP Precedence и DSCP и даже по IP-адресам, что существенно расширяет круг приложений и сервисов, охватываемых схемой QOS.
Но для большинства настольных приложений выбор по-прежнему невелик. Хотя последние версии ОС Windows поддерживают стандарт 802.1p, аналогичная поддержка должна обеспечиваться сетевой картой и ПО, а последнее остается большой редкостью.
Независимые производители (вроде Intel и 3Com) предлагают в дополнение к своим адаптерам, которые соответствуют упомянутому стандарту, ПО, распознающее помеченный трафик. Однако в этом случае соответствующие наборы правил должны использоваться на каждом настольном компьютере. Надо ли говорить, что их регулярное обновление способно отнять уйму времени. К счастью, подавляющее большинство сегодняшних приложений неплохо справляются с кратковременными сетевыми перегрузками, так что поддержка QoS настольными компьютерами, возможно, не столь уж актуальна.
Крис Гриффин (cgriffin@ufl.edu) и Грег Годдард (ggoddard@ufl.edu) — сетевые инженеры Университета шт. Флорида (Гейнсвиль, США).
Процедура тестирования
Для проведения испытаний была построена корпоративная сеть среднего размера. Сети головного офиса и филиалов включали в себя коммутаторы Catalyst 2924 и 3548XL компании Cisco и 2524 фирмы Hewlett-Packard, коммутаторы третьего уровня Cisco 6509 и 5500, HP Procurve 9304m и, наконец, маршрутизаторы Cisco 3660 и 7206 VXR. Сети филиалов подключались к центральному офису по линиям T1 через сеть frame relay, а для выхода в Internet из головного офиса был сымитирован канал DS-3. В результате мы смогли протестировать устройства для локальных и глобальных сетей, внеся минимальные изменения в их исходную конфигурацию.
Каждая сеть состояла из нескольких серверов и рабочих станций, оснащенных ОС Windows 2000, Windows XP и Linux. В сети центрального офиса мы установили систему видеоконференц-связи фирмы Polycom в стандарте H.323, настроенную на работу со скоростью 768 Кбит/с, а также кодек Minerva VNP-201 с производительностью 6 Мбит/с, который поддерживал формат MPEG-2. Парный ему кодек был размещен в сымитированном «облаке» Internet, а второй комплект производства Polycom — в сети филиала. Все офисы были оснащены IP-телефонами Cisco 7960.
Для измерения базовой производительности и доли потерянных пакетов использовались карты 1600/1600T компании Ixia и SmartBits 2000 и 6000B фирмы Spirent. Каждая из них была настроена на дуплексную передачу кадров Ethernet (размером от 64 до 1518 байт) со скоростью 100 Мбит/с. Плата SmartBits 2000 применялась также для имитации атаки DoS, во время которой в сеть поступало огромное число пакетов ICMP и UDP.
Для генерации Web-трафика использовались продукты IxWeb фирмы Ixia и WebAvalanche компании Caw Networks. Они выдавали HTTP-запросы к Web-серверу Apache, инсталлированному на одном из серверов под Linux в головном офисе. Мы интересовались параметрами функционирования сети до и после атаки типа DoS, которая оказывала влияние на скорость обработки HTTP-запросов. Результаты сравнивались с аналогичными данными, полученными до и после активизации правил QoS.
Последующие тесты включали в себя создание перегрузки в «облаке» frame relay при помощи нескольких типичных приложений, например загрузки Web-страниц, передачи файлов по протоколу FTP и Windows-файлов, а также транспортировки трафика между одноранговыми узлами с использованием Kazaa. Степень перегрузки была настолько высокой, что приложения VoIP и видеоконференц-связи по стандарту H.323 просто не могли передать трафик в сеть филиала по каналу T1. Качество воспроизведения голоса и видео до и после активизации правил оценивались субъективно. Распределение сетевых ресурсов между отдельными потоками в сети TCP анализировалось с помощью приложения Iperf.