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

К созданию эффективных систем предоставления гарантированного качества услуг для ресурсоемких
сетевых приложений.
В.А. Васенин, Л. В Ефремова, К.В Сорокин, А.В Лямин, А.А Макаров, К. М Щербатых
Механико-математический факультет, Центр телекоммуникаций и технологий Интернет, Институт механики
МГУ им. М.В. Ломоносова
Постановка задачи
Разработка эффективных систем предоставления гарантированного качества сервиса для критичных сетевых
приложений в мульти–протокольных сетях представляет особую важность для России с ее недостаточно
развитой магистрально – сетевой средой.В настоящее время существует два вида реализации гарантированного
качества обслуживания QoS (Quality of Service) Первое основано на резервировании ресурсов сети, которое
происходит по запросу приложения верхнего уровня и реализуется посредством RSVP (Resource reSerVation
Protocol). Это метод называется Integrated Services (IntServ).Второе основано на приоритезации трафика, которое
реализуется посредством его классификации и дальнейшей обработки в зависимости от класса. Этот метод
называется Differentiated Services (DiffServ).
Первостепенными в числе действий на этом направлении должны стать разработка и испытания на
экспериментальном сетевом полигоне систем, использующих механизмы инициирования и распространения
запросов на QoS в сочетании с различными протоколами на разных уровнях OSI и технологиями, включая
MPLS, COPS. Следующим шагом должен стать выбор наиболее эффективной системы и её распространение за
пределы экспериментальной сети, как модели межпровайдерского взаиможействия.
В качестве первого этапа работ предполагается библиографический поиск, систематизация подходов к
исследованию и результатов в этой области, полученных за рубежом. Постановка задач с учетом реально
существующей инфраструктуры в России и возможностей ее решения на экспериментальном сетевом полигоне
MSUNet.
Вторым этапом необходимы:
апробация средств обработки трафика на узлах сети (маршрутизаторах).
определение перечня технологий для тестирования, включающего следующие.
1. Сложные очереди на портах маршрутизаторов:
а) Fair Queuing;
б) Weighted Fair Queuing;
в) Random Early Detection;
г) Weighted Random Early Detection.
2. Шейпирование траффика.
3. Полисинг траффика.
Для организации испытательного стенда выделено следующее оборудование:
маршрутизатор Cisco 7500 (IOS RSP-JSV-M версии 12.2(2)Т2);
маршрутизатор Cisco 7200 (IOS C7200-JS-M версии 12.2(2)Т2);
2 PC (приемники трафика) на базе процессора Celeron 700MHz , 64Mb, Linux 2.4.4-4GB, дистрибутив Suse
Linux 7.2;
1 PC (генератор трафика) на базе процессора Pentium MMX 233MHz , 64Mb, Linux 2.4.16 , дистрибутив LinuxMandrake RE Spring 2001.
Подключение генератора и приемников трафика к пограничным маршрутизаторам должно быть реализовано на
основе технологии ATM LAN Emulation, а маршрутизаторы должны быть соединены через ATM интерфейсы
point-to-point каналом ATM PVC, который был зашейпирован Unspecified Bit Rate 6 Mbits. Таким образом в
сети будет образовано узкое место, т. к. пропускная способность канала ATM PVC должны стать во много
раз ниже пропускной способности Fast Ethernet. Механизмы предоставления различного качества
обслуживания в этом случае должны быть протестированы на выходном интерфейсе маршрутизатора.
В качестве генератора трафика, по крайней мере на первом этапе, должна использоваться одна из
существующих программ, которая в состоянии обеспечить многопоточность, нетребовательность к системным
ресурсам, а так-же простоту настройки и использования. Основными источником данных о трафике для
дальнейшего анализа может служить вывод программы TCPDUMP версии 3.6.2, которая должна запускаться на
генераторе и приемниках, а также фиксировать каждый пакет который уходит или приходит на интерфейс.
После каждого замера должны сниматься показания с интерфейса маршрутизатора.
Изучение сетевого трафика являются наиболее эффективными лишь тогда, когда трафик исследуется в
условиях, максимально приближенных к реальным. И хотя есть очень распространенное мнение о том, что
эмулировать Интернет трафик невозможно, задача данного исследования в создании условий, при которых
характер трафика наиболее приближен к реальному.
Предпроектные исследования. Генератор трафика.
Для исследования моделей и механизмов, позволяющих предоставлять гарантированный уровень сервиса (QoS)
приложениям, критичным к используемым ресурсам, необходим генератор трафика. При этом следует
принимать во внимание, что характер проводимых исследований требует, чтобы данный генератор порождал
трафик по структуре и характеристикам максимально приближенный к трафику реальной сети. В связи с этим
возникает несколько довольно специфичных, но важных требований к данному типу программного
обеспечения.
Одним из важнейших требований является поддержка «многопоточности», т.е. возможности генерировать
трафик в несколько потоков одновременно. Данное свойство необходимо для того, чтобы симулировать
«выход» трафика от нескольких источников. Причиной является то обстоятельство, что в реальной жизни
источников сетевого трафика как правило много. Тестирование очередей на маршрутизаторах так же
необходимо проводить с использованием многопоточности.
Рассмотрим некоторые технические особенности, связанные с построением генераторов трафика,
использующих «многонитиевые» (threads) концепции. В системах с корректной реализацией потоков
порождение, а именно создание ядром отдельной нити –это операция более «дешевая» с точки зрения ресурсов
процессора, т.к. в этом случае не происходит копирование контекста процесса. Переключение (scheduling)
между потоками также более дешевая операция по сравнению с переключением обычных процессов. Второе
свойство – дешевизна переключения, в случае генераторов трафика имеет очень важное значение. В некоторых
реализациях возможно создание потоков с так называемым real-time scheduling police. Хотя безусловно, ни одна
из свободно распространяемых unix-подобных операционных систем не является real-time системой в полном
объеме. Тем не менее, использование данной возможности может позволить улучшить работу генератора
трафика.
Необходимо отметить, что построение многопоточных генераторов трафика на threads имеет и свои
отрицательные стороны. Например, хотелось бы обеспечить переключение между генерируемыми потоками с
использованием некоторых разумных критериев, в частности, критериев, основанных на математических
моделях трафика. С нашей точки зрения механизм, используемый в ядре, в частности операционной системы
(ОС) Linux, для переключения процессов не достаточно хорошо подходит именно для данной задачи. Причиной
является тот факт, что квант времени, отводимый на работу процесса (а как следствие и на непрерывную
генерацию потока) представляется слишком большим. При этом практически невозможно влиять на порядок и
частоту переключения. Однако исследование этого вопроса представляется отдельной большой задачей,
решение которой может быть предложено в будущем. Также необходимо отметить, что текущая реализация
threads в ядре Linux недостаточно эффективна и, более того, является не совсем posix реализацией. В других
свободно распространяемых unix-подобных операционных системах ситуация с этим не выглядит лучше. На
сегодняшний день положение вещей таково, что более-менее корректная реализация threads существует только в
коммерческих OS, как то: Solaris, Windows NT (2000) и т.д.
Для использования в качестве генератора трафика был выбран пакет Iperf. Выбор в пользу данного
программного продукта был сделан главным образом потому, что он написан с использованием так называемых
threads, что обеспечивает выполнение нашего основного требования к генераторам трафика, а именно
возможности генерировать трафик в несколько потоков.
Вместе с тем, более детальный анализ ситуации указывает на возможность совершенно другого подхода к
построению трафик –генератора. Этот подход может быть основан на использовании некоторых особенностей
построения TCP/IP стека ядер Linux ветки 2.4, а именно, с использованием netfilter. В этом подходе не
предполагается создание threads в обычном смысле этого слова, но предполагается производить некий
специальный NAT (Network address translation) таким образом, что с внешней стороны, т.е. со стороны
маршрутизаторов, это будет выглядеть как работа многонитиевой программы. Scheduling policy в данном случае
тоже будет идти отдельной реализацией, что позволит более точно моделировать трафик. Также представляется
возможным (хотя данный вопрос не был еще до конца продуман) использование для данной задачи механизма
netgraph, предоставляемого ядрами FreeBSD. Данный механизм представляет собой некую альтернативу
традиционной реализацией TCP/IP стека, используемого в UNIX системах ветки BSD. Подчеркнем, что этот
новый подход пока находится в стадии исследования и поэтому для проведение экспериментов использовались
уже существующие реализации, несмотря на все их отмеченные выше недостатки.
Предпроектные исследования. Формирование плана эксперимента.
Рассматривая задачу моделирования сетевого многоканального потока при различных настройках
маршрутизатора, в первую очередь необходимо было сформировать план эксперимента, обеспечивающий
репрезентативные и воспроизводимые в аналогичных условиях данные наблюдений. С этой целью было
проведено:
 изучение необходимого и достаточного времени протекания эксперимента;
 изучение наиболее адекватного режима окончания эксперимента, с учетом того, что время завершения
передачи данных по различным каналам могло довольно сильно отличаться;
 изучение необходимого числа повторных, однотипных экспериментов, для проверки устойчивости
экспериментальных наблюдений.
Сравнение 3 различных сроков эксперимента (6 минут, 12 минут и 24 минуты) показали, что 6-ти минутные
эксперименты не обеспечивают сопоставимости результатов. Причина этого во влиянии на данные эффектов
начала и завершения работы генератора трафика. 12-ти минутные наблюдения дали вполне приемлемые
результаты, а 24-х минутные наблюдения не внесли качественных улучшений в однородность 12-ти минутных
экспериментов.
Для сравнения репрезентативности экспериментов были исследованы и сопоставлены серии из четырех
экспериментов для каждой из настроек маршрутизатора. Сравнение внутри этих серий показало, что выбранные
параметры эксперимента позволяют получать устойчивые, сопоставимые результаты.
Сравнение различных режимов работы маршрутизатора с точки зрения COS.
В качестве одного из основных показателей COS был выбран механизм потерь пакетов в для различных
режимов работы маршрутизатора. Обработка экспериментальных данных показала, что модели потерь пакетов
на канале при многоканальной передаче данных существенно отличаются при различных режимах работы
маршрутизатора. В одних случаях объем потерь для каждого из каналов является практически константой и не
зависит от объема переданных по каналу данных. В других случаях, объем потерь пропорционален объему
переданных по каналу данных. Полученные результаты позволяют судить, на сколько приемлемы те или иные
настройки режимов очереди с точки зрения требований, предъявляемых к COS.
Заключение.
На данном этапе проведена отработка методики тестирования различных режимов настройки маршрутизатора с
точки зрения COS. Определены необходимые алгоритмы стохастического анализа результатов тестирования и
получены первые результаты дающие представление о COS при различных настройках маршрутизатора.