Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

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


Rambler's Top100

  

Пора обзаводиться тестовым инструментарием

Майк Фратто

Тестирование сетевого продукта с целью приобретения — дело, иногда требующее бо’льших душевных сил, чем собственно его развертывание в сети. При этом вы должны рассмотреть набор средств и интерфейс продукта, выяснить, насколько хорошо он интегрируется с имеющимися приложениями, и оценить производительность, чтобы убедиться, что у ваших систем достаточно мощности для поддержки “новичка”.

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

Но не стоит отчаиваться, поскольку доскональное тестирование сетевых устройств все же возможно. Мы самолично проделываем это каждый день!

Полную версию данной статьи смотрите во 2-ом номере журнала за 2004 год.

Производительность, задержка и потери

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

В документе RFC 1242 института IEEE, посвященном терминологии тестирования сетевых устройств, пропускная способность определяется как максимальная скорость передачи данных, при которой отсутствуют потери кадров. Однако терминология RFC 1242 относится к устройствам уровня 2 или 3. Подход на основе измерения потерь кадров перестает работать, когда речь заходит о тестировании TCP-ориентированного трафика, поскольку TCP-механизмы контроля ошибок и восстановления сети после перегрузки подразумевают, что содержащиеся в кадрах пакеты могут теряться по дороге и передаваться повторно. При тестировании TCP, как правило, требуется узнать максимальную скорость (выраженную числом битов в секунду), которой можно достичь, прежде чем сеансы начнут выдавать ошибки.

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

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

Если перефразировать определение RFC 1242, то задержка — это временной интервал между моментом, когда последний бит пакета вошел в тестируемую систему, и моментом, когда первый бит ее покинул. Данное определение подходит для устройств хранения и переадресации данных. К этой категории относятся маршрутизаторы, коммутаторы, распределители нагрузки и устройства защиты, так как они сначала получают пакеты данных, сохраняют их в буфере, неким образом обрабатывают, а затем отсылают. Задержка представляет проблему как для обработки транзакций, происходящей в базах данных, так и для интерактивного режима обработки данных, например с помощью telnet или SSH (Secure Shell). Протестировать задержку особенно трудно, но получить по ней достоверные цифры вполне возможно, если разместить тестируемые устройства рядом, как мы и поступили при тестировании коммутаторов Fibre Channel среднего уровня (см.: High on Fibre на сайте http://www.nwc.com/1325/1325f5.html).

Потери — это всего лишь число сброшенных пакетов или, в случае TCP, сеансов. Потери тестируемой системы могут проявляться в том, что она просто не принимает новый трафик или, наоборот, сбрасывает старый, поставив его в очередь и отдав предпочтение новому. Именно потери обычно являются ограничивающим фактором при тестировании пропускной способности.

И разумеется, производительность системы во время выполнения теста может сильно варьироваться в зависимости от объема трафика. Большинство устройств уровня 2 и 3, сталкиваясь с большим объемом трафика, превосходящим их емкость, попросту начинают сбрасывать пакеты, что и приводит к потерям. Задержка, как правило, не проявляется до тех пор, пока емкость системы не будет почти полностью исчерпана и не возникнет перегрузка.

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

Трафик против транзакций

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

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

Генераторы трафика — это мощные источники битовых потоков (так называемые бластеры). Они предназначены для тестирования устройств, работающих на уровнях 2 и 3. Преимущество генераторов трафика, например SmartBits компании Spirent Communications и Chassis компании Ixia Communications, — в их способности создавать пакетный трафик, точно соответствующий спецификации, и пересылать пакеты со скоростью, близкой к скорости линии связи. Для недавнего обзора коммутаторов 10 Gigabit Ethernet (см.: Сети и системы связи. 2003. № 5. С. 34) мы воспользовались генератором 1600T компании Ixia, чтобы протестировать производительность и механизмы QoS. Задав значения в полях заголовка IP, в частности IP-адрес и ToS/DiffServe для QoS, мы испытали коммутаторы 10 Gigabit Ethernet на разнообразных видах трафика при высоких скоростях передачи.

Важно отметить, что, помимо содействия в тестировании производительности, генераторы трафика обеспечивают стабильный фоновый трафик. Испытывая коммутаторы 10 Gigabit Ethernet и Fibre Channel среднего уровня, мы использовали генераторы трафика для создания нагрузки на тестируемую систему при различных типах трафика, при этом второй инструмент измерял производительность. В этом случае, как и при тестировании производительности, генератор трафика должен создать надлежащую нагрузку на тестируемую систему, иначе фоновый трафик окажется бесполезным.

Распространенной ошибкой является использование генератора трафика для пересылки UDP-пакетов (User Datagram Protocol) через МЭ на основе технологии контекстной фильтрации пакетов (Stateful Packet-Filtering — SPF), а для измерения производительности — инструментария для работы с TCP. Проблема в том, что UDP-трафик не порождает такой же нагрузки на МЭ, как TCP-трафик того же объема.

Генераторы трафика часто имитируют TCP-трафик, используя случайные числа для начального номера последовательности ISN (Initial Sequence Number), счетчика приращения последовательности, генерации порта источника и т. п. Однако полученный трафик может вести себя не совсем так, как требует стандарт TCP. Если тестируемая система активно отслеживает TCP-состояние, то действие генератора не даст того эффекта, какого вы ожидали.

Генераторы транзакций, напротив, реализуют полный сетевой стек и часто взаимодействуют с имеющимися серверами в качестве клиента. Такие генераторы, используемые преимущественно для тестирования HTTP, в большинстве своем поддерживают и другие распространенные протоколы приложений, включая потоковое мультимедиа, SMTP, FTP и POP3. Генераторы транзакций могут выполнять тестирование в замкнутом цикле, где тестовое средство действует и как клиент и как сервер или в разомкнутом цикле, где оно действует как клиент и используется для тестирования серверной системы. Названия контрольных параметров производительности, предоставляемых генераторами транзакций, аналогичны тем, которые выдают генераторы трафика, — пропускная способность, задержка, потери, но есть некоторое отличие в том, как измеряются задержка и потери.

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

Когда стоит вернуться к реальности

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

Сгенерированные бластерами искусственные пакеты должны поддерживаться устройствами уровня 2 и 3, если тестируемая система не отслеживает состояние сеанса или только частично задействует для обработки информацию заголовка пакета, кроме адресного, другие поля редко используются. Особую важность реализация протокола приобретает при тестировании TCP-устройств, которые отслеживают состояние сеанса и проверяют значения соответствующих полей. Инструменты тестирования, создающие искусственный TCP-трафик, такие, как SmartWindow и SmartTCP компании Spirent, бесполезны при тестировании устройств, снабженных TCP-средствами. Более того, значения полей TCP-сеанса, в частности номеров последовательностей, должны быть надлежащим образом выбраны и приращены на протяжении всего TCP-сеанса, иначе устройство с TCP-функциями, скорее всего, не сможет правильно обработать такие пакеты.

Так, у нас возникли проблемы с генераторами искусственного TCP-трафика при тестировании МЭ с контекстной фильтрацией пакетов, так как эти МЭ отслеживают состояние сеанса. Генератор не мог должным образом завершать TCP-соединения, в результате МЭ продолжал поддерживать их в открытом состоянии, потерянные же пакеты не восстанавливались, что опять-таки приводило к тому, что соединения оставались открытыми. Кроме того, генератор трафика повторно использовал начальные номера последовательности, это приводило к коллизиям, когда номер ISN и IP-адрес соответствовали уже существующим соединениям. В совокупности эти три проблемы доставили нам массу неприятностей. Учитесь на наших ошибках: уж лучше сразу отказаться от неподходящего инструмента, чем потом с ним мучиться!

Искусственный трафик также работает с полнофункциональными IP-стеками, но при этом транзакции лишь имитируются. Тестирование приложений посредством искусственного трафика хорошо подходит для устройств уровня 4, где IP-стек ведет себя так, как ожидается, но устройства, работающие на прикладном уровне, вряд ли правильно обработают эти транзакции. Например, ориентированные на работу с приложениями МЭ, они не смогут корректно обработать искусственный трафик приложений, поскольку отслеживают их состояние.

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

Чтобы выяснить, правильно ли функционирует данный инструмент, нужно сначала понять, как действительно работает протокол. Воспользуйтесь своим анализатором пакетов для захвата и анализа трафика на одном-двух каналах. Затем проделайте захват и анализ этого трафика с помощью тестового инструмента. Поищите отклонения, вроде номеров последовательностей и их приращений, начинающихся с “1”, необычные комбинации флагов протокола и прочие странности в его поведении.

Хорошо, когда есть цель

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

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

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

Распространенной практикой при тестировании производительности является использование пакетов большой длины, поскольку в этом случае сетевые устройства обычно показывают лучшие результаты. Однако, готовя обзор по VPN-оборудованию, мы проводили тестирование производительности систем на разных “смесях” типов трафика и с удивлением обнаружили, что Cisco 7140 более эффективно работает на малых пакетах. Когда мы обратились к Cisco за объяснениями, нам ответили, что обработка трафика в продукте была специально оптимизирована для малых пакетов, поскольку именно они являются самыми распространенными. Такие особенности оборудования не выявишь при тестировании на пакетах одной фиксированной длины.

Потерянные сеансы и транзакции

Потери можно измерить несколькими способами. Не надо забывать, что в TCP имеются механизмы компенсации потерь, такие, как повторная передача и оконное управление квитированием. Протокол TCP может скрыть эффект от потерь, если иметь в виду традиционный сброс пакетов. Это вполне приемлемый факт, поскольку при тестировании транзакций некоторые потери являются частью нормального функционирования сети. Однако рост числа повторных передач может служить признаком того, что в некоей части тестируемой системы возникла перегрузка. Повторные передачи приводят к снижению пропускной способности TCP (ведь до места добирается меньший объем данных) и/или к увеличению задержки, поскольку каждому установленному TCP-соединению приходится дожидаться прихода данных.

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

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

Другие инструменты

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

• Обычно мы говорим о тестировании производительности приложений в “чистой” тестовой среде, но в работе сетевых приложений часто возникают сбои, когда им приходится бороться с потерями пакетов, задержкой, флуктуациями и фрагментацией. Однако тестирование на линиях с ухудшенными характеристиками, как минимум, сильно затрудняет повторяемость эксперимента. Мы использовали продукт фирмы Shunra для моделирования WAN-трафика при различных характеристиках линии, таких, как полоса пропускания, задержка и потери. Средства имитации приложений, например Chariot компании NetIQ, хорошо подходят для тестирования устройств уровня 3 и 4, но, поскольку транзакции лишь имитируются, они не могут хорошо работать на уровнях сеансов, представления данных и прикладном, так как являются статичными (см.: Фратто М. Тестируем системы предотвращения вторжений уровня сети // Сети и системы связи. 2004. № 1. С. 76).

• Работа приложения в смоделированной сети покажет вам, как оно поведет себя в схожей ситуации. Мы воспользовались специальным пакетом Fragroute, моделируя хакерский трaфик для тестирования способности устройств защиты к сборке потоков трафика и распознавания открытых попыток вторжения. Так, ПО Fragroute может дробить пакеты на крошечные фрагменты, дублировать их или переупорядочивать, задавать IP-опции и проделывать еще массу других трюков.

• Прежде чем начать игры с пакетами, хотелось бы увидеть, что делает тестируемая система. Средства анализа протоколов играют важную роль в выявлении и решении сетевых проблем, а настольные анализаторы протоколов, в частности Sniffer компании Network Associates и EtherPeek компании Wild Packets, просто незаменимы для анализа сетевого трафика. Оба анализатора поддерживают декодирование широчайшего набора протоколов и обладают исключительно гибкими средствами фильтрации пакетов. У продукта с открытым исходным текстом Ethereal средств несколько меньше, особенно в плане экспертного анализа, но у него хорошие декодеры протоколов, и он был перенесен на множество ОС. Ну а для приверженцев интерфейса командной строки подходящим средством станет tcpdump, тоже перенесенный, как и Ethereal, на множество ОС.

• Поскольку большинство сетевых адаптеров сбрасывают ошибочные кадры, то для мониторинга всего трафика, проходящего через некую точку на линии, мы воспользовались устанавливаемыми прямо на линии анализаторами протоколов, такими, как устройство Sniffer Distributed s400 Model EG2S компании Network Associates. Модель EG2S, встраиваемая в линию и использующая внешнюю консоль для захвата пакетов и анализа данных, справляется с захватом всего трафика, идущего по полнодуплексным гигабитовым линиям. Оборотная сторона использования этой модели — отсутствие анализа пакетов в режиме реального времени..





  
2 '2004
СОДЕРЖАНИЕ

бизнес

• "Коммунальные вычисления". Вы верите в их возможность?

• Доктрины производителей

• На пути к электронному голосованию

инфраструктура

• Телефоны VoWLAN: готовность номер один

• Инженерная инфраструктура центра данных, или Решения NCPI

• Пора обзаводиться тестовым инструментарием

• iSCSI-сети хранения данных

информационные системы

• Когда применение SOAP становится неэффективным

• Программные средства технической поддержки клиентов

сети связи

• Новые IP-телефоны

• УАТС как услуга

кабельные системы

• Медиаконвертеры позволяют модернизировать сеть, не обременяя бюджет

• Соблюдайте правила установки огнезадерживающих средств

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

• Вооружитесь камерами и замками

• Говоря на языке SAML


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх