МДК 03.01. Лекция Введение
 Скачать 1.66 Mb.
|
|
СТРЕССОВОЕ ТЕСТИРОВАНИЕ СЕТИ  Основное отличие стрессового тестирования сети от тестирования устройств (в лабораторных условиях) заключается в том, что его задача состоит в проверке работоспособности уже купленных вами устройств в конкретных условиях эксплуатации (для конкретной кабельной системы, уровня шума, качества питающего напряжения, используемого оборудования и ПО и т. п.). Как и тестирование кабельной системы, стрессовое тестирование сети должно быть обязательной процедурой перед вводом сети в промышленную эксплуатацию. В настоящее время это делается крайне редко. Единственным обнадеживающим моментом остается тот факт, что еще несколько лет назад и кабельная система очень редко тестировалась перед вводом сети в эксплуатацию. Цель стрессового тестирования сети состоит, во-первых, в выявлении дефектов оборудования и архитектуры сети и, во-вторых, в определении границ применимости существующей архитектуры сети. Замечание №1. Стрессовое тестирование сети всегда должно предшествовать постановке сети на обслуживание. Результаты стрессового тестирования сети являются ориентиром при проведении упреждающей диагностики. Чтобы сделать правильные выводы о состоянии сети по результатам наблюдения за параметрами ее работы с помощью средств диагностики, вы должны знать, каковы максимально допустимые значения этих параметров именно для вашей сети. Достоверные выводы о причинах неадекватного поведения сети сделать очень сложно, если вы точно не знаете, какова допустимая утилизация канала связи для обеспечения нормального времени реакции эксплуатируемого прикладного ПО или как пропускная способность вашего коммутатора или сервера зависит от длины кадров, типа протоколов, числа широковещательных и групповых пакетов, режима коммутации и т. п. Замечание №2. Основными инструментами для стрессового тестирования сети являются генераторы трафика, анализаторы сетевых протоколов и стрессовые тесты. Генераторы трафика могут быть чисто программными или программно-аппаратными. Суть работы генератора трафика заключается в том, что, задавая параметры, направление и интенсивность трафика, вы создаете в сети дозируемую нагрузку с определенными параметрами трафика (длиной кадров, типом протокола, адресом источника и приемника и т. п.). Примером программного генератора трафика является Frame Thrower компании LANQuest. Он работает на обычном ПК и может генерировать трафик для сетей Ethernet, Token Ring, FDDI, ATM. Примером аппаратного генератора трафика является устройство PowerBits компании Alantec для сетей Ethernet и FDDI. Генераторы трафика встраиваются во многие анализаторы сетевых протоколов, например в Sniffer компании Network Associates, DA-30 компании Wandel&Goltermann, HP Analyzer компании Hewlett-Packard, Observer компании Network Instrumens и др. На Рисунке 1 показаны параметры, задаваемые в генераторе трафика программы Observer.
Стрессовые тесты — это специальное программное обеспечение для эмуляции работы в сети различных приложений. Стрессовыми такие тесты называются потому, что при их работе в сети создается высокая нагрузка. Иногда они называются инструментарием для тестирования клиент-серверных приложений. Примерами стрессовых тестов для эмуляции работы с файлами в сети являются MS-Test компании Microsoft, NetBench и ServerBench компании Ziff-Davis, Perform3 компании Novell, FTest компании "ПроЛАН". Примерами более сложных стрессовых тестов для эмуляции работы в сети конкретных приложений могут служить EMPOWER компании Performix, QA Partner компании Segue, AutoUser Simulater компании "ПроЛАН". В данной статье мы рассмотрим, как можно провести стрессовое тестирование сети с помощью распределенного программного анализатора протоколов Distributed Observer компании Network Instruments и стрессового теста типа программы FTest компании "ПроЛАН" или Perform3 компании Novell на примере тестирования гипотетической сети, изображенной на Рисунке 2. Предлагаемая в данной статье методика не является "истиной в последней инстанции", а служит лишь иллюстрацией возможных методов решения описанных выше задач.
| |||||||||||||||||||
 | ОРГАНИЗАЦИЯ СТРЕССОВОГО ТЕСТИРОВАНИЯ Предположим, что установленный в центре сети коммутатор имеет порты Fast Ethernet и Ethernet, причем серверы MAIN и BASE подключены к первым, а концентраторы и пользователи — ко вторым. Предположим также, что в сети используются различные типы протоколов, такие, как TCP/IP, NetBEUI/ NetBIOS и IPX/SPX. Для простоты описания эксперимента мы будем считать, что центральный коммутатор имеет зеркальный порт (mirror port), куда можно перенаправлять трафик с любого порта центрального коммутатора для его анализа. Замечание №3. Первым этапом стрессового тестирования сети является оценка работоспособности основных устройств в условиях высоких пиковых нагрузок. Тестированию целесообразно подвергать не все устройства, а только те, что имеют важное значение с точки зрения пропускной способности и надежности сети. Мы обычно называем этот этап тестирования "калибровкой главного устройства сети". Поскольку в сети, изображенной на Рисунке 2, надежность центрального коммутатора определяет надежность всей сети, то мы должны знать, какова способность центрального коммутатора выдерживать высокие пиковые нагрузки и какова при этом будет поддерживаемая скорость для разного типа трафика. Основной интерес представляет не само значение пропускной способности, выраженное в Мбит/с, а возможность потери кадров коммутатором. Значение совокупной пропускной способности устройства (aggregate bandwidth), которое производители приводят в документации, мало информативно, так как документация обычно умалчивает о том, при каких условиях и для какого типа трафика проводились измерения. Наверняка эти условия были наилучшими для данного устройства. Кроме этого, важное значение имеет оценка вероятности того, что при определенных условиях какой-то порт коммутатора отключится из-за высокой нагрузки (что иногда и происходит), и коммутатор необходимо будет перезапустить в "холодном режиме". Чтобы получить достоверные результаты, эксперимент по стрессовому тестированию сети должен быть правильно спланирован. Одним из возможных сценариев является описанный ниже. Центральный анализатор протоколов (Distributed Observer) подключается к зеркальному порту коммутатора, куда по очереди перенаправляется трафик с разных доменов сети. Удаленные агенты устанавливаются по одному в каждый коллизионный домен тестируемой конфигурации и настраиваются только на генерацию конкретного типа трафика в заданном направлении (по конкретным МАС-адресам). Если станции домена А должны работать c сервером MAIN по протоколу TCP/IP, то агент домена А надо настроить на генерацию TCP-трафика (далее тестовый трафик) в домен сервера MAIN. При этом генерация трафика должна осуществляться не по MAC-адресу сервера MAIN, а на MAC-адрес специально установленной для данных целей станции. Такую станцию будем называть "Приемником". Задача станции "Приемник" состоит в снятии нагрузки с сервера, так как в данном эксперименте мы проверяем устойчивость работы коммутатора, а не сервера. Для организации встречного трафика из домена MAIN в домен А удаленный агент анализатора из домена MAIN должен быть настроен на генерацию TCP-трафика по МАС-адресу станции "Приемник" из домена А. При этом генератор трафика лучше не устанавливать на сервер MAIN, дабы не создавать ему дополнительную нагрузку. Аналогично все остальные агенты настраиваются на генерацию тестового трафика интересующих вас протоколов. Чтобы создать наихудшие для коммутатора условия, размер кадров можно установить равным минимально допустимому. Чем больше портов коммутатора и, соответственно, удаленных агентов анализатора протоколов будет участвовать в эксперименте, тем большую нагрузку вы создадите и, соответственно, более точные результаты получите. Настроив и запустив генерацию тестового трафика со всех удаленных агентов, на ее фоне следует запустить одно или несколько приложений, которые вы планируете использовать в сети. Тем самым вы дополнительно проверите устойчивость работы приложений к высоким нагрузкам в сети. Например, какое-нибудь приложение, работающее с сервером MAIN, можно запустить на станции BOSS, находящейся в домене А. При этом центральный анализатор протоколов должен поочередно настраиваться на сбор и запись в файл трафика со всех портов коммутатора, где работают приложения: сначала из домена А, затем из домена MAIN, и так далее по всем доменам тестируемой конфигурации. Теоретически центральный анализатор протоколов можно установить в одном из доменов сети, а каждый удаленный агент — заставить одновременно с генерацией трафика производить запись трафика. Но этого делать не рекомендуется, так как в этом случае нет гарантии того, что агент, производящий генерацию трафика, не окажется перегружен и не будет терять кадры. После сбора и запаси в файлы пакетов со всех портов коммутатора они обрабатываются, например, с помощью программы NetSense for Observer. Цель обработки — определение числа повторно переданных пакетов на транспортном уровне во время работы конкретного приложения. Колонка Е (см. Рисунок 3) показывает число зафиксированных повторных передач пакетов при работе станции BOSS с сервером MAIN. Именно число повторно переданных пакетов является тем интегральным критерием, который свидетельствует о потере кадров.
Обнаружив потерю кадров, вы должны определить причину. В общем случае причин может быть несколько: перегрузка коммутатора, искажение данных при их передаче по каналу связи, слишком большое число эмулируемых коммутатором коллизий (эффект back pressure), несоблюдение коммутатором стандарта CSMA/CD. Эффект back pressure заключается в эмулировании коммутатором коллизий при перегрузке входного буфера. Вследствие этого после 16 последовательных коллизий драйвер сетевой платы на компьютере, где работает приложение, прекратит передачу кадра. Несоблюдение коммутатором стандарта CSMA/CD заключается в том, что коммутатор не выдерживает паузы в 9,6 микросекунд перед посылкой очередного кадра. В результате коммутатор будет непрерывно передавать данные, и никакая другая станция в этот момент в канал связи выйти уже не сможет. Такой эффект называется "блокировкой канала". Поэтому при обнаружении повторных передач на транспортном уровне тот же самый трафик должен быть проанализирован с целью определения числа ошибок и повторных передач на канальном уровне. Это также может быть сделано с помощью программы NetSense for Observer (см. Рисунок 4). В результате анализа трафика вы сможете установить причину потери кадров от приложения на станции BOSS.
Повторяя эксперимент и задавая различные параметры и интенсивность тестового трафика, вы можете построить зависимость между параметрами тестового трафика и числом повторно переданных пакетов на транспортном уровне. В результате вы сможете определить, при каких параметрах трафика и утилизации портов коммутатора пакеты начинают повторно передаваться на транспортном уровне и чем это вызвано. Замечание №4. Значения параметров тестового трафика, при которых повторная передача пакетов на транспортном уровне дает о себе знать, могут служить в качестве ориентира при наблюдении за работой сети в процессе ее эксплуатации (для упреждающей диагностики). Эти значения с запасом в 10% должны быть введены как пороговые в диагностическое средство. Если в процессе эксплуатации сети значения параметров трафика превысят пороговые значения, то диагностическое средство информирует об этом событии администратора сети. Нам часто задают вопрос, почему при низкой утилизации портов коммутатора (чаще всего Fast Ethernet или FDDI) и при отсутствии канальных ошибок сеть тем не менее периодически сбоит. Ответ прост. Наблюдение утилизации портов с помощью telnet или программ на базе SNMP дает усредненное, а не пиковое значение утилизации — так уж устроены SNMP-агенты. Однако именно при пиковых значениях утилизации коммутатор или станции могут терять кадры, вследствие чего пакеты передаются повторно на транспортном уровне. Замечание №5. Вторым этапом стрессового тестирования сети является оценка устойчивости сервера и рабочих станций к высоким нагрузкам в сети. Цель эксперимента — определение условий, при которых потеря кадров происходит именно на рабочих станциях и на сервере вследствие их перегрузки или скрытых дефектов. Второй этап следует проводить после установки и подключения рабочих станций пользователей. Стрессовая нагрузка, которой сеть подвергается на втором этапе, должна быть на 10–15% меньше нагрузки, при которой пакеты на первом этапе начали повторно передаваться на транспортном уровне. Это даст вам гарантию того, что повторная передача вызывается отнюдь не потерей кадров в коммутаторе. Для этого на станциях пользователей в разных доменах сети необходимо одновременно с работой приложений запустить стрессовый тест типа Perform3 или FTest. В зависимости от размеров сети тест следует запускать в одном или нескольких доменах одновременно. Суть работы программы FTest заключается в том, что станции будут взаимодействовать с сервером с постепенно увеличивающейся по интенсивности нагрузкой. В случае программы Perform3 нагрузка сразу будет максимальной, поэтому использование FTest более предпочтительно. При отсутствии указанных тестов вы можете просто запустить циклическую перекачку длинных файлов на сервер и обратно. На этом этапе агенты анализатора протоколов надо настроить не на генерацию трафика, а на сбор пакетов. Это позволит вам измерить число канальных ошибок и коллизий и число повторно переданных пакетов на транспортном уровне в каждом домене сети. Анализ трафика позволит локализовать скрытые дефекты в рабочих станциях и на сервере и определить, в какой степени сервер и коммутатор сбалансированы друг с другом по производительности и какой запас пропускной способности имеется у каждого из них. Полученные на первом этапе пороговые значения параметров трафика должны быть скорректированы с учетом результатов, полученных на втором этапе. | ||||||||||||||||||
| | |||||||||||||||||||
