CC BY
12
С. В. Малахов, аспирант кафедры программного обеспечения и управления в технических системах, ФГБОУ ВПО «Поволжский государственный университет телекоммуникаций и информатики» e-mail: malakhov-sv@psuti.ru
В. Н. Тарасов, доктор технических наук, профессор, заведующий кафедрой программного обеспечения и управления в технических системах,
ФГБОУ ВПО «Поволжский государственный университет телекоммуникаций и
информатики»
e-mail: vt@ist.psati.ru
ЭКСПЕРИМЕНТАЛЬНЫЕ ИССЛЕДОВАНИЯ ПРОИЗВОДИТЕЛЬНОСТИ СЕГМЕНТА ПРОГРАММНО-КОНФИГУРИРУЕМОЙ СЕТИ
Исследования выполнены при поддержке Министерства образования и науки Российской Федерации в рамках проекта № 07.514.11.4153 ФЦП «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2013 годы».
В работе проводилось измерение задержки обработки пакетов при отсутствии записи в таблице OpenFlow коммутатора и потерь пакетов при обработке в OpenFlow контроллере NOX на экспериментальном сегменте программно-конфигурируемой сети (ПКС).
Ключевые слова: контроллер NOX, программно-конфигурируемые сети, протокол OpenFlow, коммутатор OpenFlow, задержки и потери пакетов, сетевая операционная система (СОС).
До недавнего времени действующая архитектура сетей развивалась по мере выявления проблем - к стеку протоколов TCP/IP добавлялся новый, который эту проблему решал.
В сетях новой архитектуры - программно-кон-фигурируемых сетях (ПКС), рассматривается возможность разделения функции управления и передачи данных.
При продвижении кадров данных коммутатор Ethernet подает запрос к таблице коммутации. Затем на основании полученной информации, в том числе адреса порта получателя, параметров качества обслуживания и т. д., коммутационная матрица осуществляет дальнейшую обработку и передачу данных на целевой выходной порт (рис. 1)[1].
В обычном коммутаторе Ethernet одновременно реализуются и управление и передача данных. Уровень управления представлен встроенным контроллером, уровень передачи данных - таблицей коммутации и коммутационной матрицей [2]. Обладая некоторыми интеллектуальными функ-
циями, микроконтроллер сам принимает решения о продвижении кадров на основе собранной им информации о структуре сети, которая зачастую имеет лишь отдаленное отношение к подлинной топологии сети. Непосредственно управлять принятием решений нельзя - можно лишь конфигурировать микроконтроллер, задавая определенные наборы правил и приоритетов. Это накладывает заметные ограничения на функциональность коммутатора и всей сети. В частности, для организации связей «каждый с каждым» в такой сети не обойтись без коммутаторов третьего уровня -маршрутизаторов (рис. 2).
Сейчас администраторы вручную настраивает оборудование по заданным параметрам и любые дальнейшие изменения осуществляются преимущественно на аппаратном уровне.
1. Уровни управления и передачи данных в OpenFlow коммутаторах
Протокол OpenFlow используется для управления сетевыми коммутаторами (маршрутизато-
Таблица коммутации
Входяший пакет Коммутационная матр нца
Рис. 1. Обработка и передача данных в коммутаторе Ethernet
рами) с центрального устройства - контроллера сети (например, с сервера или даже персонального компьютера). Это управление заменяет или дополняет собой работающую на коммутаторе (маршрутизаторе) проприетарную программу (осуществляющую построение маршрута, создание карты коммутации и т. д.). Контроллер используется для управления таблицами потоков коммутаторов, на основании которых принимается решение о передаче принятого пакета на конкретный порт коммутатора [3].
Рис. 2. Функциональная схема традиционного коммутатора Ethemet и сети «каждый с каждым»
В OpenFlow коммутаторе реализован только уровень передачи данных. Задача коммутатора состоит в принятии поступающих данных, извлечение их адресов и, если адресат есть в таблице коммутации, немедленной передачи данных коммутационной матрице. Иначе коммутатор по защищенному каналу отправляет запрос на Центральный контроллер сети ОрепРІо-- и на основании полученной от него информации вносит необходимые изменения в таблицу коммутации, после чего осуществляется обработка полученных данных (больше оборудование не перенастраивается руками, а перенастраивается с помощью ПО).
Рис. 3. Коммутатор OpenFlow использует для заполнения таблиц потоков центральный контроллер сети
Центральный контроллер имеет точную информацию о структуре и топологии сети. Это позволяет оптимизировать продвижение пакетов данных и, в частности, прокладывать связи «каждый с каждым» на канальном уровне, не прибегая к 1Р-маршрутизации (рис. 3). Также становится возможным «коммутировать» каналы передачи данных на всем пути от источника до пункта на-
значения. В результате по сети передаются потоки данных, а не отдельные пакеты [2].
В терминологии ПКС таблица коммутации получила название FlowTable (таблица потоков). У каждого контроллера своя уникальная FlowTable, эту таблицу он заполняет только на основании информации, полученной от центрального контроллера. Центральный контроллер, в свою очередь, строит таблицы потоков, взаимодействуя с ПО более высокого уровня - платформами виртуализации центров обработки данных и др.
В сетях новой архитектуры ПКС все маршрутизаторы и коммутаторы объединяются под управлением Сетевой Операционной Системы (СОС), которая обеспечивает приложениям доступ к управлению сетью и которая постоянно отслеживает конфигурацию средств сети, мониторинг, доступ и управление ресурсами всей сети [4]. Примером таких систем является NOX.
NOX это часть системы программно-конфигу-рируемых сетей. Это система для создания приложений управления сетью, которые позволяют управлять одним или несколькими OpenFlow коммутаторами. Система NOX работает на аппаратном обеспечении и предоставляет программную среду, которая может управлять крупными сетями на гигабитных скоростях. NOX является первым и самым распространённым контроллером OpenFlow [5].
Более практически, NOX позволяет:
• NOX предлагает сложную функциональность сети (управление, прозрачность, контроль, контроль доступа и т.д.);
• Разработчики могут добавить свое собственное программное обеспечение управления;
• NOX представляет собой центральную программную модель для всей сети - одна программа может контролировать переадресацию на всех коммутаторах сети;
• NOX может быть расширен как в C++ или Python. Текущая версия содержит множество примеров приложений и встроенные библиотеки, которые обеспечивают полезные функции сети, такие как хост отслеживание и маршрутизация [6].
Протокол OpenFlow решает также проблему зависимости от сетевого оборудования какого-либо конкретного поставщика, поскольку ПКС(SDN) использует общие абстракции для пересылки пакетов, которые СОС использует для управления сетевыми коммутаторами [2].
Openflow (открытый поток) - протокол (и технология) управления процессом обработки данных, передающихся по компьютерной сети маршрутизаторами и коммутаторами.
2. Постановка задачи
Нами ставилась задача измерения задержки обработки пакетов и потерь при отсутствии за-
писи в таблице OpenFlow коммутатора и потерь пакетов при обработке в OpenFlow контроллере КОХ.
Для исследования поведения задержки и потери пакетов было решено построить экспериментальный сегмент сети в составе:
• коммутатор OpenFlow НР 3500;
• сервер (ОЗУ 4Гб, 9 сетевых интерфейсов, ЦП 2.9 Ггц).
Ниже представлена экспериментальная схема сегмента сети с пропускной способностью 1 Гб/с. На сервере подняты три гигабитных сетевых интерфейса, которые подключены к OpenFlow коммутатору.
Контроллер КОХ доступен на сетевом интерфейсе еШ0, а интерфейсы еШ1 и еШ2 выполняют задачи клиентских машин.
Рис. 4. Экспериментальная схема сети
Такая сетевая структура позволяет добиться наименьшей задержки, так как в ней отсутствуют лишние промежуточные звенья (которые вносят свои задержки).
В ходе эксперимента будем фиксировать время отправки пакета с интерфейса е!Ь1 и время приема на интерфейсе еШ2. Также на интерфейсе еШ2 получим сведения о количестве полученных пакетов. Эти статистики понадобятся для нахождения времени задержки и потерь пакетов.
Для проведения теста понадобятся инструменты: iperf (для генерации ТСР и/или UDP трафиков), для выполнения программы запускается клиентская часть на сетевом интерфейсе еШ1 и серверная на еШ2 [7], и понадобится программа tcpdump,которая запускается на интерфейсе еШ2 для мониторинга [8].
3. Настройка OpenFlow коммутатора для решения поставленной задачи
Интерфейс е!Ъ0 задействован с 1Р адресом
11.1.1.1 через консоль сервера командой: ifconfigeth0 11.1.1.1 ир
На этом интерфейсе будет находится Open-Flow контроллер, к которому будет обращаться OpenFlow коммутатор.
Аналогичным образом настраиваются и два другие интерфейса, ethi и eth2.
На сервере в консоли, командой: cu -s 9600 -l /dev/ttyS0
Таким образом подключаемся к коммутатору для настройки.
Добавляем порт №i в виртуальную сеть и для сети назначаем IP адрес, с той же подсети, что и контроллер:
vlan 1 name vlan1
ip address 11.1.1.2 255.255.255.0
untagged 1
Создаем vlan2 и добавляем туда произвольные порты i9 и 2O.
Указываем, какой сетью будет управлять контроллер OpenFlow:
openflow vlan2 controller tcp:11.1.1.1:6644 openflow vlan2 enable
Установка интервала автоматического подключения коммутатора к контроллеру (в нашем случае 2O с.):
openflowvlan2 backoff 20 Сохраняем настройки коммутатора writememory
На этом этапе настройка сетевого оборудования завершается.
4. Проведение эксперимента и анализ полученных результатов
Запустим на сервере контроллер NOXс помощью команды:
./noxcore -iptcp:6644 switch Укажем на сервере сетевой интерфейс, где будет происходить захват пакетов. По умолчанию
- ethO, для выбора всех интерфейсов - any. В случае отсутствия локальной сети, можно воспользоваться интерфейсом обратной связи lo. В нашем случае интерфейс eth2. tcpdump -i eth2 -n
Для генерации TCP и UDP трафика запустим кроссплатформенную консольную клиент-серверную программу iperf. На сервере запускаем с параметром -s, а на клиентской машине-с.
Полученные выходные данные показывают начальное время отправки пакета с клиента и время получения на сервере, а также количество переданных пакетов и дошедших за время сеанса. Экспортируем для дальнейшей обработки в MicrosoftExcel.
Построим график функции по полученным данным. Период сессии составляет iOOO пакетов (длина пакета выставлена по умолчанию и равна 64 байта).
На графике видно, что с увеличением количества передаваемых пакетов растет задержка. Причем задержка наблюдается после передачи примерно i6O-ro пакета. Отметим, что размер пакетного буфера данного коммутатора составляет 36 МБ [iO].
Рис. 5. Задержки пакетов. Горизонтальная ось показывает количество пакетов, вертикальная ось
время в секундах
Рис. 6. Потери пакетов за сессию
По количеству принятых и переданных пакетов, времени между передачей следующего пакета можно найти потери пакетов за сессию.
Построим график потерь в ШагеойЕхсе!
Из графика (рис. 6) видно, что потери растут с увеличением задержек, причем потери наблюдаются также начиная примерно с 160-го пакета.
Если произвести эксперимент, не запуская контроллер, то потери и задержки наблюдаться не будут, согласно спецификации к коммутатору НР 3500, 1000 Мб/с время ожидания: < 3,4 мкс (размер пакета 64 байта) [10].
Выводы
При отсутствии записей в таблице потоков
OpenFlow коммутатора задержки и потери довольно большие (см. рис. 5 и 6). Если же заранее внести записи, то можно ожидать, что значения задержек и потерь уменьшатся. Это связано с обработкой пакетов на контроллере и созданием правил, по которым в дельнейшем будет «двигаться» пакет.
Согласно полученным результатам использование протокола OpenFlow на начальном этапе развития для малых сетей не целесообразно. По причинам высокой стоимости оборудования и развертывания программно-конфигурируемой сети очень высока, а также вполне справляется со своими задачами традиционное сетевое оборудование.
Литература
1. Программно-аппаратная идиллия, или OpenFlow [Электронный ресурс]. - URL: http://www.osp. ru/lan/2011//09/13010353. - Дата доступа: 05.02.2013.
2. Программно-конфигурируемые сети - как это работает? [Электронный ресурс]. - URL: http:// habrahabr.ru/post/149126. - Дата доступа: 05.02.2013.
3. OpenFlow Switch Specication [Электронный ресурс]. - URL: http://www.openflow.org/documents/ openflow-spec-v1.L0.pdf. - Дата доступа: 01.2013.
4. Программно-конфигурируемые сети [Электронный ресурс]. - URL: http://www.osp.ru/os/2012/09/ 13032491. - Дата доступа: 01.02.2013.
5. Martin Casado, Nick McKeown, Natasha Gude, Ben Pfaff, Justin Pettit, Scott Shenker NOX: Towards an Operating System for Networks - ACM Computer Communications Review. - April. - 2008. - P. 1-2.
6. AboutNOX [Электронный ресурс]. - URL: http://www.noxrepo.org/nox/about-nox. - Дата доступа:
01.02.2013.
7. Iperf [Электронный ресурс]. - URL: http://iperf.sourceforge.net // Сайт iperf. - Дата доступа:
01.02.2013.
S. TCPDUMPDOCUMENTATION [Электронный ресурс]. - URL: http://www.tcpdump.org/tfdocumen-tation. - Дата доступа: 09.02.2013.
9. OpenFlow Tutorial [Электронный ресурс]. - URL: http://www.openflow.org/wk/index.php/OpenFlow _Tutorial#Controller_Choice:_NOX_w.2FPython.// Сайт OpenFlow. - Дата доступа: 09.02.2013.
10. Серия коммутаторов HP 3500 и 3500 yl, Технические характеристики [Электронный ресурс].
- URL: http://h10010.www1.hp.com/ /wwpc/ru/ru/sm/WF06a/12883-12883-4172267-4172278-4172278-3457354.html?dnr=1. - Дата доступа: 09.02.2013.
