 |
|
|
|
| |
 к выбору публикации
|
|
|
Какую эффективную скорость передачи данных обеспечивает провайдер?
На примере тестирования беспроводного канала связи иллюстрируется метод измерения эффективной скорости передачи данных в корпоративной сети. Метод основан на совместном использовании программных пакетов FTest 3.х и Observer 6.2.
|
 |
Как оценить качество арендуемого канала связи
Часто корпоративная сеть представляет собой несколько локальных сетей, объединенных с помощью глобальных линий связи. Если глобальные линии связи не являются собственностью компании, у администратора корпоративной сети может возникнуть естественное желание выяснить, каково реальное качество услуг, предоставляемых провайдером? Чаще всего такие вопросы возникают в тех случаях, когда администратор корпоративной сети не имеет полной информации о том, как устроена сеть провайдера, или когда провайдер предоставляет компании не, так называемый, "прозрачный" канал связи, а некую услугу, например, IP - канал.
Чаще всего администраторы корпоративных сетей формулирует вопрос следующим образом: "А действительно ли мне выделен канал 64 Кбит/с (128 Кбит/с, 512 Кбит/с, ...)?". С нашей точки зрения, такая формулировка, по сути, правильного вопроса, не совсем корректна. Возможна, например, ситуация, когда физическая скорость доступа к сети провайдера соответствует заявленной, но, из-за наличия узкого места в сети провайдера, эффективная (результирующая) скорость передачи данных в корпоративной сети может оказаться существенно ниже. (Например, из-за нарушения синхронизации в канале "модем-мультиплексор" на стороне провайдера).
Поэтому мы считаем, что если возникают сомнения в качестве предоставляемых провайдером услуг, то более корректно формулировать вопрос следующим образом.
Вопрос N1. Какова эффективная скорость передачи данных в арендуемом канале связи?
Эффективная скорость учитывает не только скорость между потребителем услуги и ее провайдером, но и скорость передачи данных в самой сети провайдера.
Иногда интересно получить ответы и на другие вопросы.
Вопрос N2. Какова величина накладных расходов в сети провайдера?
Если провайдер предоставляет Вам "прозрачный" канал передачи данных, то в Соглашении об Уровне Обслуживания он оговаривает конкретное значение физической скорости передачи данных. Если же в сети провайдера есть узкое место (или дефект), то могут происходить повторные передачи на транспортном уровне корпоративной сети. В результате этого, эффективная скорость или, другими словами, пропускная способность сети на транспортном (и прикладном) уровне будет снижаться. При этом на физическом уровне скорость сети может соответствовать именно той, которую обещает провайдер.
Вопрос N3. Какую пропускную способность вам реально имеет смысл оплачивать?
Как мы уже говорили выше, если в сети провайдера существует узкое место, но провайдер это отрицает, и по каким-то причинам Вы не можете или не хотите поменять провайдера, то, по крайней мере, Вы можете выяснить, какую пропускную способность Вам имеет смысл оплачивать.
В качестве одного из возможных алгоритмов решения поставленных задач, может быть приведенный ниже алгоритм. Он предполагает совместное использование пакетов FTest 3.x и Observer 6.х. Хотим сразу оговориться, что на Вопрос N2 указанным методом получить ответ можно только в двух случаях. Если провайдер предоставляет "прозрачный" канал связи. Если канальный протокол в сети провайдера, который предоставляет услугу (например IP-канал), не обеспечивает гарантированной доставки сообщений по сети.
|
|
|
1. Организация эксперимента.
Чтобы измерить эффективную скорость передачи данных в канале связи, который объединяет две локальные сети, в одной из них нужно установить Агенты программы FTest, а в другой - тестовый сервер. Место установки станции-монитор не критично, но, по возможности, его следует размещать в той же локальной сети, где установлены Агенты. Иначе обмен служебной информацией между Агентами и станцией-монитор будет проходить по медленному каналу, что, может повлиять на точность результатов измерений.
|
|
|
2. Определяем, исправны ли Агенты.
Прежде чем тестировать канал связи, нужно убедиться в том, что компьютеры Агентов не содержат дефектов. Это можно сделать с помощью теста "FTest by steps", работающего в режиме калибровки. В качестве тестового сервера, в этом случае, следует использовать сервер, который размещен в одной локальной сети с Агентами.
|
|
|
3. Определяем минимальное значение величины накладных расходов.
Величина накладных расходов - это разница в объемах трафика прикладного и физического уровней. Трафик на физическом уровне всегда больше, чем на прикладном уровне. Чем меньше разница, тем эффективней используется канал связи. Но величина накладных расходов зависит не только от качества сети, но и от типа трафика. Для одного типа трафика величина накладных расходов больше, для другого меньше. Тип трафика определяется прикладной задачей.
Поэтому, прежде чем приступить к оценке эффективности использования канала связи, необходимо определить, каково минимальное значение величины накладных расходов. Другими словами, сколько процентов составляют накладные расходы, при отсутствии повторных передач на транспортном уровне сети. Грубую оценку минимальной величины накладных расходов можно получить, измерив величину накладных расходов при работе программы FTest в локальной сети. В глобальной сети величина накладных расходов, как правило, бывает больше чем в локальной, что обусловлено меньшими размерами кадров и большой вероятностью повторных передач на транспортном уровне сети.
Затем, вычисляя разность между накладными расходами в глобальной сети и накладными расходами в локальной сети, мы можем приблизительно оценить, какова величина накладных расходов, являющаяся следствием повторных передач на транспортном уровне сети.
Для измерения объема трафика на физическом уровне сети мы предлагаем использовать анализатор протоколов Observer. В принципе, это можно сделать с помощью любого анализатора протоколов или программы на основе SNMP. Трафик прикладного уровня измеряется программой FTest.
|
|
|
4. Измеряем эффективную скорость передачи данных и величину накладных расходов в глобальном канале связи.
На этом шаге алгоритма выполняется тест "FTest by steps" в режиме калибровки. Как мы уже говорили в п.1 Алгоритма, Агенты должны быть расположены в одной локальной сети, а тестовый сервер - в другой.
Выполняя тест, преследуются три основные цели. Во-первых, с помощью программы FTest, измеряется эффективная скорость передачи данных. Во-вторых, с помощью программы Observer измеряется объем трафика на физическом уровне сети. На основании этих измерений вычисляется величина накладных расходов при передаче данных по каналу связи.
Обращаем Ваше внимание, что в данном случае на основе измерений трафика в локальной сети делается оценка трафика глобальной сети. Такой способ, естественно, позволяет сделать только грубую оценку трафика глобальной сети. Кроме этого он допустим только для "прозрачных" каналов связи и для каналов, в которых работают протоколы канального уровня, не обеспечивающие гарантированной доставки сообщений по сети. Если канальный уровень обеспечивает гарантированную доставку сообщений по сети, то со стороны локальной сети не видны повторные передачи на канальном уровне канала связи.
Многие могут возразить, что определить наличие повторных передач на транспортном уровне можно значительно проще. Для этого достаточно проанализировать канальную трассу с помощью анализатора сетевых протоколов (например, Observer). Действительно, анализируя порядковые номера TCP пакетов, можно точно измерить число повторных передач и, тем самым оценить эффективность работы канала связи. Однако, если делать это без помощи экспертной системы, например NetSense for Observer, то необходимо вручную проанализировать сотни пакетов, что практически невозможно. Поскольку наличие экспертой системы у администратора сети, это скорее исключение, чем правило, мы этот метод не рассматриваем.
|
|
|
5. Определяем, какую физическую скорость имеет смысл оплачивать.
Очевидно, что если эффективная скорость передачи данных оказывается низкой, необходимо предпринять какие-то действия для ее повышения. В частности, можно обратиться к провайдеру или системному интегратору и попросить их выяснить причину низкой эффективной скорости. (Такие услуги оказывает компания ProLAN.) Если же по каким-то причинам Вы не можете договориться с провайдером, то, по крайней мере, вы можете выяснить, какую скорость передачи данных вам имеет смысл оплачивать. Это должно быть число, которое на величину накладных расходов выше эффективной скорости передачи данных. Очевидно, что это число не должно быть СУЩЕСТВЕННО выше эффективной скорости передачи данных.
Проиллюстрируем изложенный метод на примере тестирования работы корпоративной сети одного из предприятий, сегменты которой соединены между собой беспроводным каналом связи, который предоставлен провайдером.
|
|
|
Краткое описание тестируемой сети
Тестируемая сеть представляет собой два сегмента: А и В, соединенные между собой беспроводными линиями связи через сеть провайдера. Доступ к сети провайдера осуществляется через маршрутизаторы "Router A" и "Router B" (см. рисунок 1).
В качестве маршрутизаторов в тестируемой сети используются персональные компьютеры с двумя интерфейсными картами и специальным программным обеспечением. Один из интерфейсов маршрутизатора подключен с сегменту локальной сети, другой - к радиомодему WaveLAN (Lucent Tecnologies), обеспечивая связь с сетью провайдера. Каждый сегмент выполнен на витой паре по спецификации 10BASE-T. Все станции внутри сегмента входят в один коллизионный домен.
Для тестирования беспроводной линии связи между сегментами на рабочих станциях PC1, PC2, PC3, которые находятся в сегменте A, были запущены три Агента. Тестовый сервер и станция-монитор находятся в сегменте B. Для оценки максимальной производительности радиоканала на прикладном уровне мы использовали тест "FTest by steps" в режиме калибровки. Параметры запуска тестов приведены в файлах отчетов.
|
|
|
Тестирование показало...
FTest измеряет интегральные характеристики качества сети и, в частности, эффективную скорость передачи данных. Поэтому, в соответствии с п. 2 алгоритма, перед тестированием глобального канала связи, нужно удостовериться в исправности рабочих станций (Агентов), принимающих участие в его тестировании. (Если они содержат дефекты, то результатам тестирования нельзя будет доверять.) С этой целью мы выполнили тест "FTest by steps" в режиме калибровки для станций PC1, PC2, PC3. Все Агенты были настроены на работу с сервером, размещенным в сегменте A (в том же сегменте, что и Агенты). Результаты этого теста представлены на рисунке 2.
Полученные результаты свидетельствуют, что на компьютерах рабочих станций PC1, PC2, PC3 дефектов нет. Скорости выполнения операций записи имеют значения от 882 КБ/с до 977 КБ/с; скорости выполнения операций чтения - от 906 КБ/с до 973 КБ/с; производительность колеблется в диапазоне 873 КБ/с - 922 КБ/с. Полученные значения соответствуют используемой технологии (10Base-T).
Для измерения эффективной скорости передачи данных (и производительности) по радиоканалу был выполнен тест "FTest by steps" в режиме калибровки. Агенты, расположенные в сегменте A, выполняли файловые операции с тестовым сервером, размещенным в сегменте B. Результаты данного теста приведены на рисунке 3.
Как видно из приведенной диаграммы, при работе всех Агентов достигнута одинаковая производительность сети (22 КБ/с) и близкие значения скоростей чтения и записи.
Как уже говорилось выше, измеряемые программой FTest 3.х параметры характеризуют эффективную скорость сети на прикладном уровне. На физическом уровне скорость сети, естественно, должна быть выше. Чтобы оценить минимальное значение накладных расходов (п.3 Алгоритма), было проведено тестирование, при котором один из Агентов работал с сервером, размещенным в том же сегменте, что и тестовый сервер. Значения параметров запуска теста, были установлены такими же, что и при тестировании глобальной линии передачи данных (см. файлы отчетов).
Тест проходил в несколько шагов. На каждом шаге теста Агент увеличивал предлагаемую нагрузку. Производительность на прикладном уровне измерялась пакетом FTest, интенсивность канального трафика измерялась пакетом Observer 6.2. Полученная зависимость интенсивности трафика на канальном уровне от производительности на прикладном уровне приведена на рисунке 4.
Из рисунка видно, что при эффективной скорости в 22 КБ/с, на физическом уровне интенсивность трафика составляет около 200 Кбит/с. Таким образом, минимальное значение величины накладных расходов составляет: 100%-22*8/200*100%=12%
К сожалению, при тестировании глобальной линии связи у нас не было возможности контролировать трафик на стороне Агентов, поэтому реальную величину накладных расходов при передаче данных по сети провайдера мы определить не смогли. Очевидно, что она должна быть больше 12%.
Нас не информировали, какую физическую скорость компания оплачивает провайдеру в данном случае. Тем не менее, очевидно, что в данном случае не целесообразно оплачивается скорость, которая больше чем 256 Кбит/с.
В заключение, хотим сказать еще несколько слов по поводу интерпретации результатов тестирования.
При работе программ FTest и FTrend выполняются сетевые операции типа "запрос-ответ". Поэтому интегральная скорость передачи данных зависит от двух основных факторов:
- |
задержек при передаче пакетов по сети провайдера;
|
- |
повторных передач, вызванных, в частности, искажением данных при их передачи по сети провайдера.
|
Иногда интересно выяснить, какой именно фактор наиболее значим в каждом конкретном случае. Для этого необходимо запустить программы FTest (а еще лучше FTrend) и Observer на длительное время. Если в результате их работы вы обнаружите, что величина накладных расходов существенно не меняется во времени, то это может свидетельствовать о наличии больших задержек в маршрутизаторах, или о наличии медленных каналов связи "внутри" самой сети провайдера.
Если же величина накладных расходов существенно изменяется во времени, то причина, вероятнее всего, в искажениях информации при ее передаче по линиям связи.
|
|
|
P.S.
Многие могут возразить: "Зачем нужен FTest, если достаточно "пропинговать" удаленный сервер и выяснить, какова скорость передачи данных" в канале связи.
Действительно, для измерения скоростных характеристик сети часто используются утилиты на основе ICMP. Такие утилиты очень эффективны, в частности, в тех случаях, когда необходимо определить наличие связи между станциями сети (или определить, почему связи нет). К сожалению, наиболее мощные утилиты, такие как "pathchar", не работают на платформах MS Windows 95/98/NT.
Если же необходимо оценить эффективность работы канала связи, то большинство ICMP утилит дают очень мало полезной информации. Причина заключается в отсутствии в протоколе ICMP механизмов повторных передач (retransmissions) и механизмов управления потоком данных (flow control). Поэтому вы не всегда сможете определить, почему пакеты ICMP вдруг перестали проходить от одной станции к другой. Кроме того, ни одно реальное пользовательское приложение не работает на основе протокола ICMP.
В большинстве ICMP утилит измеряется время прохождения одного пакета фиксированного размера, который не взаимодействует с протокольным стеком на рабочей станции. Результаты таких измерений могут существенно отличаться от скорости работы станций с сервером в "реальной жизни". Любая реальная транзакция - это десятки и сотни пакетов различных размеров, которые передаются в обоих направлениях и взаимодействуют с протокольным стеком на рабочей станции. Эти пакеты подвержены искажениям, или могут и просто "теряться" в сетевом оборудовании.
Отличие пакетов FTest и FTrend от ICMP утилит, в частности, в том, что FTest и FTrend функционируют на прикладном уровне сети и измеряют реальные характеристики работы сети. Эти характеристики зависят от большого числа параметров: уровня загрузки сети, числа повторных передач на канальном и транспортном уровнях, параметров настройки сетевого оборудования, параметров настройки сетевой ОС и т.п. По этой причине FTest и FTrend позволяют получить существенно больше информации, необходимой для эффективной диагностики сети.
Тем не менее, если других средств нет, то можно воспользоваться и утилитой на основе ICMP. Вольному воля.
|
 |
наверх
|
|
