 |
|
|
|
| |
 к выбору публикации
|
|
|
Увидеть слона целиком. Часть II
С. С. Юдицкий,
В. И. Швецов,
С. И. Кузубов |
 |
После того как мы проиллюстрировали методику сквозной диагностики сетей на примере каналов связи сети (см.: Сети и системы связи. 2000. № 10. С. 66) мы хотели бы рассмотреть вопросы диагностики рабочих станций сети. Напомним, что предлагаемая методика достаточно наглядна и строится исходя из прагматических соображений. В общих словах она основана на трех обязательных составляющих: знание того, как компонент сети должен работать; умение объективно определить, как он работает реально и умение определить, почему он работает не так, как надо. И в соответствии с данной методикой первый вопрос звучит так...
|
 |
Как должна работать станция?
Ответ на этот вопрос зависит от двух факторов: что мы будем понимать под термином “рабочая станция” и что выберем в качестве основного критерия ее адекватной работы. Рабочая станция — это сложная система, в состав которой входит множество компонентов: сам компьютер, сетевой адаптер, драйвер сетевого адаптера, сетевая операционная система и многое другое. Поэтому термином “рабочая станция” мы обозначим компьютер конкретной конфигурации, на котором установлены конкретные сетевой адаптер, драйвер и операционная система.
Теперь поговорим о критериях. В общем случае критериев как минимум два. Первый — это обеспечение требуемого времени реакции конкретного пользовательского приложения.
В соответствии с первым критерием вопрос можно сформулировать следующим образом: как должна работать станция заданной конфигурации в конкретной сети, чтобы время реакции пользовательского приложения “Х” не превышало n секунд? Второй критерий — отсутствие дефектов на рабочей станции. В соответствии со вторым критерием вопрос можно сформулировать так: как должна работать станция заданной конфигурации в конкретной сети при условии, что ни один из ее компонентов не содержит дефектов?
Ответ на первый вопрос мы рассмотрим в третьей части статьи. Здесь же мы поговорим о том, как должна функционировать исправная станция. Чтобы это определить, необходимо иметь некий признак, на основании которого делаются выводы о ее исправности. Таким признаком может быть, например, величина скорости выполнения станцией файловых операций в сети.
Вы можете поинтересоваться, а почему именно “файловых”, а не каких-то других. Прежде всего потому, что если в каком-либо компоненте рабочей станции есть дефект, то с вероятностью, близкой к 100%, он проявится в низкой скорости выполнения файловых операций. Немаловажно и то, что последние являются довольно распространенным типом сетевых операций и что скорость их выполнения несложно измерить.
Из сказанного выше следует, что не очень конкретный вопрос: как должна работать станция при отсутствии дефектов, — можно сформулировать достаточно точно: с какой скоростью исправная рабочая станция должна выполнять файловые операции в сети? Очевидно, что никаких стандартов на этот счет нет. Но если понимать принципы работы сети, то можно вывести несколько базовых правил, соблюдение которых будет свидетельствовать об отсутствии на рабочей станции дефектов. Вот некоторые из них.
1. |
Если станции работают с сервером по очереди, скорость выполнения файловых операций каждой станцией должна быть прямо пропорциональна производительности компьютера станции и производительности ее сетевого адаптера.
|
2. |
Если станции работают с сервером по очереди, то скорость выполнения файловых операций каждой из них должна соответствовать теоретической пропускной способности коллизионного домена/сегмента сети, в котором станция расположена. Например, станция находится в коллизионном домене Ethernet — следовательно, ее скорость, как правило, должна быть в диапазоне 800—1150 Кбайт/с.
|
3. |
Если все станции работают с сервером одновременно, то максимальная производительность всех станций должна соответствовать теоретической пропускной способности сети.
|
4. |
Ни в одном из режимов работы станции скорость выполнения операций чтения не должна отличаться от скорости выполнения операций записи более чем на 30%.
|
5. |
Если все станции работают с сервером одновременно и при этом увеличивают интенсивность запросов к серверу, то число ошибок канального уровня, измеряемое в ходе теста анализатором сетевых протоколов или SNMP-консолью, не должно существенно увеличиваться с ростом загрузки сети и не должно превышать 0,01% от числа переданных пакетов. (Именно ошибок, а не коллизий.)
|
6. |
Если рабочие станции работают с сервером по очереди, то число ошибок канального уровня, измеренное в процессе работы каждой станции анализатором сетевых протоколов или SNMP-консолью, должно быть равно нулю.
|
|
|
|
Как реально работает станция в сети
Реальную работу станции можно проверить с помощью стрессового тестирования, т. е. посредством выполнения набора специальных тестов, создающих высокую нагрузку на сеть. Из приведенных выше правил следует, что для локализации дефектов в рабочих станциях необходимо, как минимум, два типа тестов. В тестах первого типа все станции должны работать по очереди. Это позволяет локализовать дефекты сети, не являющиеся следствием взаимного влияния одних станций на другие. Учитывать же подобные влияния необходимо с помощью тестов второго типа, в которых все станции должны работать одновременно.
По своей сути стрессовое тестирование схоже с проверкой компьютера на стенде после его сборки. Сеть тестируется при отсутствии пользовательских приложений. На всех рабочих станциях должны быть запущены специальные тестовые программы, создающие дозированную нагрузку на сеть и измеряющие скорость и пропускную способность сети при этой нагрузке.
Для стрессового тестирования сети мы обычно используем программный пакет FTest 3.10, именно для этого и созданный компанией ProLAN (см. “Тестов не бывает слишком много...”). Другие фирмы, например Tolly Group, для аналогичных целей используют пакет Chariot 3.1 компании Ganymede Software. Несмотря на существенную разницу в стоимости и функциональных возможностях этих пакетов, принципы их работы и методика использования очень близки.
Кроме пакета FTest 3.10, для проверки выполнения правил 5, 6 в сети должно быть установлено средство, измеряющее число ошибок канального уровня и загрузку канала связи.
С этой целью мы чаще всего используем анализатор протоколов Expert Observer компании Network Instruments, хотя подойдет и любой другой анализатор протоколов или программа на базе SNMP. Достоинством пакета Expert Observer является наличие встроенной экспертной системы, что в ряде случаев оказывает дополнительную поддержку в локализации дефекта сети.
Результатом стрессового тестирования сети с помощью пакета FTest 3.10 является так называемый “Паспорт скоростных характеристик сети”. В нем приводятся измеренные пакетом FTest значения скорости и пропускной способности сети в различных тестовых режимах. “Паспорт скоростных характеристик” сети как раз и дает ответ на вопрос, как реально работает сеть.
|
|
|
Почему станция работает не так, как надо
Перефразируя слова классика, можно сказать, что все исправные рабочие станции исправны одинаково, а каждая дефектная рабочая станция дефектна по-своему. Поэтому с точки зрения методологии диагностики сети самое важное — убедиться, что именно рабочая станция — а не сервер или канал связи — является причиной плохой работы сети. Установив это, уже гораздо проще локализовать в ней дефектный компонент. Неисправный узел удобнее всего найти методом замены, т. е. последовательно заменять подозрительные компоненты другими, каждый раз при этом повторяя тестирование.
Обычно, имея в своем распоряжении анализатор протоколов Observer и программу FTest, отличить дефект рабочей станции от дефектов канала связи не составляет особого труда. Сначала нужно определить, является ли низкая скорость работы конкретной станции следствием ошибок передачи данных на канальном уровне сети (это можно сделать, анализируя статистическую информацию о сетевом трафике с помощью анализатора протоколов). Если да, то в канале связи имеет место явный дефект. А если нет?
Как мы уже говорили, кроме явных, в сети могут быть скрытые дефекты. В отличие от явных их невозможно обнаружить путем анализа только статистической информации о сетевом трафике — необходимо захватить канальную трассировку и декодировать содержащиеся в ней протоколы. Практика показывает, что скрытые дефекты встречаются чаще именно в рабочих станциях. Как же локализовать такие дефекты?
Выше уже шла речь о том, что для локализации скрытых дефектов необходимо (и достаточно) наличие двух типов диагностических средств. Это программа типа FTest и анализатор сетевых протоколов. Если поиск дефектов сети сравнить с локализацией неисправности в электронном устройстве, то FTest можно сопоставить с генератором тестовых импульсов, а анализатор протоколов — с осциллографом. Однако в отличие от генератора пакет FTest не только осуществляет генерацию сигналов (трафика), но еще и измеряет время их прохождения по устройству (т. е. время реакции сети).
Генерируемый программой FTest трафик — это повторяющаяся последовательность одной и той же пачки пакетов. Параметры, с которыми запущен тест, определяют число пакетов в пачке и их направленность.
На рис. 1 показан пример канальной трассировки, записанной при работе программы FTest и обработанной с помощью программы NetSense for Observer. Параметры теста были заданы следующим образом: размер файла — 64 Кбайт, размер записи — 4096 байт, доля операций чтения — 50%. При таких значениях параметров станция работает с сервером с максимальной производительностью, а влияние дисковой подсистемы сервера на производительность минимально.
Из рисунка видно, как осуществляется обмен пакетами между рабочей станцией и сервером. Синим цветом показаны пакеты, направленные от рабочей станции к серверу, зеленым — от сервера к рабочей станции.
Рабочая станция осуществляет запись на сервер пачкой из трех пакетов с суммарной длиной 4322 байт, что с учетом служебной информации соответствует заданному размеру записи (4 Кбайт). Просмотр всей трассировки показывает, что в среднем половина пачек передается от рабочей станции к серверу, а другая половина — в обратном направлении, что соответствует параметрам теста.
Предположим, что в процессе испытаний сети выяснится, что какая-то станция работает не так, как этого ожидали. Например, не соблюдается правило 4 и скорость операций записи в несколько раз ниже скорости операций чтения. Низкая скорость выполнения файловой операции может быть в двух случаях. Первый из них: пакеты по какой-то причине теряются, и рабочая станция или сервер их повторяют — это называется повторными передачами на транспортном уровне сети (transport retransmissions). Второй: рабочая станция или сервер (либо какое-то другое устройство между станцией и сервером) вносят большую задержку при передаче данных. Постепенно перемещая анализатор протоколов по тракту “рабочая станция — сервер” и просматривая канальную трассировку с помощью анализатора протоколов, мы всегда можем установить причину низкой скорости передачи данных.
Проиллюстрируем сказанное на примере диагностики простейшей сети (рис. 2), состоящей из одной рабочей станции, одного коммутатора и одного сервера.
Первое, с чего следует начать, это посмотреть, есть ли повторные передачи на транспортном уровне сети. При этом не имеет значения, в какой точке тракта “рабочая станция — сервер” будет собираться канальная трассировка. Важно, от кого идут повторные передачи кадров — от станции или от сервера. Например, если вы собираете канальную трассировку в точке “А” и видите, что только рабочая станция осуществляет повторные передачи, то это будет означать, что кадры теряются в сервере, коммутаторе или где-то между ними.
Если повторные передачи на транспортном уровне отсутствуют, то следует выяснить, существуют ли задержки при передаче пакетов и кто их вносит. При этом крайне важно определить, в какой точке сети выполняется трассировка.
На рис. 3 показана канальная трассировка, собранная на серверном порте коммутатора (порт “В”). Параметры теста идентичны описанным выше. Из данных трассировки видно, что при обмене пакетами между рабочей станцией и сервером возникают паузы.
При выполнении операции записи рабочая станция (193.0.0.5) передает на сервер (193.0.0.3) содержимое записи в пачке из трех пакетов: 164—166. В ответном пакете 167 сервер подтверждает прием не всей пачки, а только двух ее первых пакетов. Последний пакет остается неподтвержденным. Это и является причиной задержки. Не получив подтверждения сервера о приеме всех данных, рабочая станция не завершает операцию записи. Выждав паузу 200 мс, она в соответствии с алгоритмом Delayed Acknowledgments посылает серверу пакет 169 с информацией об объеме переданных и принятых данных. Только после этого сервер подтверждает прием полученных от рабочей станции данных и операция записи завершается. Возникающие таким образом паузы приводят к снижению скорости выполнения операций записи.
Еще раз хотим обратить ваше внимание, что относительно просто поставить диагноз, почему станция работает не так, как надо, можно только в тех случаях, когда заранее известно, как станция должна работать, и в данном случае вы можете этого добиться, задавая различные параметры теста. Таким образом, выявить дефект, анализируя трассировку тестового трафика, существенно проще, чем при анализе трассировки трафика пользовательского приложения.
|
|
|
Примеры скрытых дефектов рабочих станций
Многие могут возразить, что стрессовое тестирование сети, о котором шла речь выше, сложно осуществить с организационной точки зрения. К сожалению, в России это действительно так. Причина, как нам кажется, в том, что в основном у заказчика работ на создание вычислительной сети нет четкого понимания того, что можно и нужно требовать при ее приемке. Если кабельная система после инсталляции, как правило, тестируется, то все остальные компоненты сети — нет. Такое положение вещей является по меньшей мере странным, поскольку, как показывает опыт, вероятность наличия скрытого дефекта рабочей станции ненамного меньше вероятности явного дефекта кабельной системы.
К наиболее распространенным скрытым дефектам рабочих станций следует отнести три типа дефектов: две разновидности дефекта сетевого адаптера, следствием которых могут быть низкая производительность рабочей станции в сети или монополизация коллизионного домена сети, и дефект драйвера сетевого адаптера, который порождает “перекос” в скоростях выполнения операций чтения и записи.
|
|
|
Дефект сетевого адаптера (низкая производительность рабочей станции)
Рассмотрим пример работы теста “FTest all stations” в небольшой сети, состоящей из одного коллизионного домена (рис. 4).
На графике показана зависимость производительности станций сети от нагрузки на сеть, на рисунке, в частности, видно, что поведение рабочей станции PC14 существенно отличается от поведения остальных станций. С увеличением нагрузки на сеть производительность рабочей станции РС14 падает практически до нуля.
Это свидетельствует о скрытом дефекте сетевого адаптера. Хотим особо обратить ваше внимание на то, что подобные дефекты не сопровождаются какими-либо ошибками на канальном уровне сети. В результате если вы будете анализировать статистическую информацию о сетевом трафике, то не увидите каких-либо проявлений неисправности. Именно поэтому дефект называется скрытым.
Следствием данного дефекта является то, что при одновременной работе в сети неисправной и нормальных станций последние не дают возможности дефектной станции передавать данные в сеть. На скорости работы исправных станций такой изъян вроде бы сказываться не должен. Однако если на дефектной станции выполняется некое сетевое приложение, предполагающее совместный доступ нескольких рабочих станций к общим данным на сервере, то дефектный сетевой адаптер будет замедлять работу всех остальных станций сети.
|
|
|
Дефект сетевого адаптера (монополизация коллизионного домена сети)
Данный дефект является полной противоположностью предыдущего.
На рис. 5 показана зависимость производительности рабочих станций от предлагаемой нагрузки на сеть, полученная при диагностике сети 10Base2 с помощью теста “FTest all stations”. Как видно на рисунке, рабочая станция PC2 линейно наращивает свою производительность во всем диапазоне предлагаемых нагрузок. Производительность же остальных рабочих станций при определенном значении предлагаемой нагрузки стабилизируется. Это означает, что станция PC2 получает в свое распоряжение такую полосу пропускания, которая ей требуется, отнимая тем самым полосу пропускания у других станций данного коллизионного домена.
Можно предположить две наиболее вероятные причины столь “агрессивного поведения” станции PC2. Первая заключается в том, что неисправный сетевой адаптер перед началом передачи данных в канал связи “слушает” паузу не 9,6 мкс (как этого требует алгоритм CSMA/CD), а несколько меньшее время. В результате он начинает передачу несущей в канал связи раньше других. Остальные же станции, действуя по правилам и “увидев” несущую в канале связи, откладывают свою передачу данных. Таким образом, дефектный сетевой адаптер передает свои данные “когда хочет”, монополизируя тем самым канал связи. Остальные же сетевые адаптеры могут передавать данные только в те моменты времени, когда “молчит” неисправный сетевой адаптер.
Другой причиной “агрессивного поведения” станции PC2 может быть некорректная отработка так называемого алгоритма отката. Это алгоритм, который каждый сетевой адаптер, согласно правилам CSMA/CD, должен отрабатывать после возникновения коллизии. Каждый контроллер при этом выжидает случайный промежуток времени, длительность которого пропорциональна числу предшествующих коллизий. Если дефектная станция не выдерживает этого промежутка времени и начинает пытаться передавать данные раньше, то она также может монополизировать канал связи.
|
|
|
Дефект драйвера сетевого адаптера
Рассмотрим пример работы теста “FTest by steps” в режиме калибровки фрагмента коммутируемой сети (рис. 6).
В данном случае производительность и скорость выполнения операций чтения на рабочей станции PS12-7 существенно ниже, чем на остальных. Поскольку в этом тесте все агенты работают строго по очереди, такое поведение станции PS12-7 в общем случае можно было бы объяснить тремя причинами: дефектом кабельной системы, дефектом порта коммутатора и дефектом рабочей станции. Как показывает наш опыт, именно перекос в скорости выполнения операций чтения и записи чаще всего свидетельствует о наличии неисправного драйвера сетевого адаптера. Более подробно эти и другие дефекты описаны в разделе “База Знаний” сервера компании ProLAN (http://www.prolan.ru/KnowledgeBase_D.html).
Об авторах:
Юдицкий Сергей Семенович,
генеральный директор
компании ProLAN
E-mail: ssy@testlab.ipu.rssi.ru
Швецов Валерий Иванович,
Кузубов Станислав Игоревич
эксперты компании ProLAN
Телефоны: (499) 334-8851, (495) 913-3067
|
 |
наверх
|
|
