close

Вход

Забыли?

вход по аккаунту

?

Bahareva Ushakov Ushakova Shuhman Osnovy programmno konfiguriruemyh setej

код для вставкиСкачать
ФЕДЕРАЛЬНОЕ АГЕНТСТВО СВЯЗИ
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ»
Кафедра «Информатики и вычислительной техники»
Н.Ф. Бахарева, Ю. А. Ушаков, М. В. Ушакова, А.Е. Шухман
ОСНОВЫ ПРОГРАММНОКОНФИГУРИРУЕМЫХ СЕТЕЙ
Учебное пособие
по дисциплине «Проектирование и моделирование сетей ЭВМ» для
магистров направлений «Информатика и вычислительная техника»,
«Управление в технических системах», «Программная инженерия» а
также для аспирантов научных специальностей 05.13.11 и 05.13.15.
Самара
2015
УДК 004.72
ББК 32.973-018я7
О -753
Рекомендовано к изданию методическим советом ПГУТИ,
протокол № , от .05.2015 г.
Рецензент – Заведующий кафедрой программного обеспечения и
управления в технических системах Поволжского государственного
университета телекоммуникаций и информатики
д.т.н., профессор В.Н. Тарасов
О -753
Основы программно-конфигурируемых сетей: учебное пособие /
Н.Ф. Бахарева, Ю. А. Ушаков, М. В. Ушакова, А.Е. Шухман
– Самара: ПГУТИ, 2015. – 111с.
Рекомендовано к изданию Редакционно-издательским советом
федерального государственного образовательного бюджетного
учреждения
высшего
профессионального
образования
«Поволжский государственный университет телекоммуникаций и
информатики» в качестве учебного пособия для магистров,
обучающихся по программам высшего профессионального
образования по направлениям подготовки: «Информатика и
вычислительная техника», «Управление в технических системах», а
также для аспирантов научных специальностей 05.13.11, 05.13.15.
Учебное пособие подготовлено при поддержке гранта РФФИ
(проект № 14-07-97034).
УДК 004.72
ББК 32.973-018я7
© Бахарева Н.Ф.,
Ушакова М. В.,
Шухман А.Е.,
Ушаков Ю. А.
© ПГУТИ, 2015
Содержание
1
Введение в сети с коммутацией каналов ......................................................... 7
1.1 Сравнение традиционных технологий коммутации ........................................ 7
1.2 Недостатки и дополнительные возможности сетей Ethernet ........................ 10
1.3 Программно-конфигурируемые сети .............................................................. 14
1.4 Системы управления сетями ............................................................................ 15
2
Эффективность управления сетевой инфраструктурой ............................... 17
2.1 Понятие эффективности распределенных вычислительных сетей и
компьютерных сетей ................................................................................................. 17
2.2 Производительность распределенных вычислительных систем и сетей .... 19
2.3 Применение теории массового обслуживания к исследованию
вычислительных систем и компьютерных сетей ................................................... 23
2.4 Область применения программно-конфигурируемых сетей ........................ 28
2.5 Распределенные облачные вычисления .......................................................... 29
3
Обзор протокола OpenFlow ............................................................................ 32
3.1 Описание таблиц для протокола OpenFlow .................................................... 32
3.2 Пути анализа потоков трафика для формирования таблиц потоков
OpenFlow .................................................................................................................... 34
3.3 Анализ трафика конвергентных сетей ............................................................ 38
3.4 Методы обеспечения QoS в ПКС .................................................................... 40
3.5 Получение статистической информации о трафике в OpenFlow сетях ....... 48
3.6 Алгоритм сбора статистики OpenFlow ........................................................... 51
4
Cетевые операционные системы для ПКС .................................................... 55
4.1 Обзор традиционных сетевых операционных систем ................................... 55
4.2 Сетевые операционные системы в программно-конфигурируемых сетях . 58
4.3 Проблема выбора сетевой операционной системы ....................................... 62
4.4 Расширение функциональных характеристик за счет интеграции СОС с
облачными сервисами ............................................................................................... 65
4.5 Виртуализация сетей передачи данных .......................................................... 66
4.6 Управление сетевыми ресурсами и потоками данных в ПКС с помощью
сетевой операционной системы ............................................................................... 68
4.7 Использование ПКС для управления сетью ЦОД ........................................ 72
5
Практическое руководство по программно-конфигурируемой сети ........ 75
5.1 Работа с эмулятором mininet ............................................................................ 75
5.2 Внешнее управление таблицами OpenFlow коммутаторов .......................... 84
5.3 Установка и настройка контроллеров ............................................................. 88
5.4 Тестирование работоспособности программно-конфигурируемой сети .... 89
Список использованных источников ...................................................................... 92
Приложение АПример использования контроллера ПКС .................................... 97
Приложение БИсходный код прототипа обеспечения QoS в ПКС .................... 105
Обозначения и сокращения
В настоящей работе использованы следующие сокращения:
АСНИ
автоматизированная система научных исследований;
ИС
испытательный стенд;
ИС ЭО ПКС
испытательный
стенд
для
исследования
эксплуатационных характеристик ЭО ПКС;
ИТ
информационные технологии;
КС
компьютерные сети;
ЛВС
локальные вычислительные сети;
ОС
операционная система;
ОКР
опытно-конструкторская разработка;
ПКС
программно-конфигурируемые сети;
СеМО
сети массового обслуживания;
СМО
система массового обслуживания;
СОС
сетевая операционная система;
СПД
сети передачи данных;
СУБД
система управления баз данных;
СХД
система хранения данных;
УК
узел коммутации;
ЦОД
центр обработки данных;
ЭО ПКС
экспериментальный образец ПКС;
ANCA
adaptive
none-continuous
allocation
(алгоритм
адаптивного несмежного назначения задач);
ARP
address resolution protocol (протокол определения
адреса);
FCFS
firstcome, firstserved (первым пришел первым обслужен)
– алгоритм обслуживания запросов;
MAC
media access control (управление доступом к среде) –
уникальный идентификатор устройства в сети Ethernet;
OSI
open system sinter connection (модель взаимодействия
открытых систем);
QoS
quality of service (качество обслуживания);
SAN
storage area network (сеть хранения данных);
TCP/IP
transport control protocol/internet protocol – стек сетевых
протоколов;
VLAN
virtual local area network (виртуальная локальная сеть).
4
Введение
В настоящее время сетевые устройства работают по принципам,
заложенным на заре развития компьютерных технологий. Современные
требования к компьютерным сетям существенно изменились со времен начала
развития сети Интернет. Существующие сетевые протоколы канального
уровня,
предназначенные
для
расширения
возможностей
сетевой
инфраструктуры Fiber Channel, Infiniband, а также EthernetII, имеют
ограниченные
возможности
по
управлению
трафиком
и
QoS.
Усовершенствованные варианты протокола Ethernet – Converged Enhanced
Ethernet и Cisco Data Center Ethernet включают расширения по управлению
потоками на основе приоритетов, разделению пропускной способности,
управлению перегрузками и логическим состоянием полос передачи данных, по
обеспечению передачи без потерь, а также по одновременному использованию
нескольких параллельных путей передачи данных между узлами. Основные
недостатки данных решений – сложная децентрализованная схема управления
потоками данных, основанная на множестве закрытых протоколов,
значительная стоимость сетевого оборудования, сложность его расширения.
Отдельно следует заметить, что данные решения используют реактивную схему
управления потоками, когда решения по коммутации принимаются во время
передачи потока.
Весьма
перспективным
направлением
технологий
является
использование программно-конфигурируемых сетей (ПКС, от англ. SDN –
Software Defined Network). Принципы ПКС впервые возникли в
исследовательских лабораториях Стэнфорда и Беркли [1] и в настоящее время
развиваются в рамках консорциума Open Network Foundation и европейского
проекта OFELIA[2]. Известен положительный опыт компаний Google и Amazon
по внедрению ПКС в ЦОД.
В основе подхода ПКС лежит возможность динамически управлять
пересылкой данных в сети с помощью открытого протокола OpenFlow. Все
активные сетевые устройства объединяются под управлением сетевой
операционной системы (СОС), которая обеспечивает приложениям доступ к
управлению сетью. Сетевые контроллеры могут быть централизованными,
использовать общие абстракции для пересылки пакетов. Результаты разработки
и исследования современных СОС отражены в работах А. Таваколи, М.
Кассадо, Т. Копонена, С. Шенкера, П. Ванга, Дж. Лю, В. Ли, Я. Ку.
За счет управления пересылкой данных в сети использование ПКС в ЦОД
позволяет реализовать схемы одновременной многопутевой передачи данных,
управление потоками на основе приоритетов, виртуализацию сети, обеспечить
QoS, эффективно распределить нагрузку на сеть. Открытость стандарта
OpenFlow и вынесение логики управления в отдельный контроллер упрощает
программное и аппаратное обеспечение активного сетевого оборудования, что
позволит в будущем производителям снизить его стоимость, а, следовательно, и
уменьшить затраты на создание ЦОД. Централизация и открытость средств
управления ПКС позволяет гибко и эффективно адаптировать работу ЦОД под
5
возникающие потребности бизнеса, что ускоряет внедрение инноваций и
обеспечивает конкурентоспособность компаний.
Наличие
потребности
компаний
в
создании
эффективных
распределенных вычислительных ЦОД, включающих СХД, на основе ПКС,
перспективный характер технологии ПКС, а также отсутствие готовых решений
в этой области являются существенными факторами, определяющими
актуальность этого направления.
Учебное пособие предназначено для магистров, обучающихся по
программам высшего профессионального образования по направлениям
подготовки: «Информатика и вычислительная техника», «Управление в
технических системах» и«Фундаментальная информатика и информационные
технологии», а также для аспирантов научных специальностей 05.13.11,
05.13.15
6
1
Введение в сети с коммутацией каналов
1.1
Сравнение традиционных технологий коммутации
В настоящее время вычислительная сеть является неотъемлемой частью
любой организации, а её отсутствие рассматривается как анахронизм,
существенно снижающий эффективность работы персонала. Особенно важно
наличие вычислительной сети в учебном заведении, так как без использования
информационных и компьютерных технологий давно стало невозможно
обеспечивать учебный процесс и проводить научную работу.
Ядром сети в таких случаях обычно служит неплохой даже по современным
меркам управляемый коммутатор второго или даже третьего уровня OSI. Сеть
построена по топологии расширенная звезда, некоторые сегменты имеют
отдельные маршрутизаторы, серверы и управляемые коммутаторы. Но удел
дорогостоящего оборудования - ядро сети и магистраль. Остальная сеть обычно
построена на неуправляемых коммутаторах, иногда даже без учета соображений
латентности (последовательно более 3-х коммутаторов), магистральных потоков
(корпуса в полном объеме подключаются в обычный порт какого-либо простого
коммутатора) (рисунок 1.1). При современном расширении такие сети
испытывают огромную дополнительную нагрузку, как по данным, так и по
управлению.
Рисунок 1.1 – Типичная сеть масштаба одного кампуса
Некоторые сети структурированы на центральном коммутаторе
посредством технологий 802.1qVLAN (VirtualLAN), как на рисунке 1.2. В этом
случае каждая подсеть автономна и потоки данных с другой подсети могут идти
только через маршрутизатор.
7
Рисунок 1.2 – Разделение сети на сегменты посредством VLAN
Главным требованием, предъявляемым к сетям, является выполнение их
основной функции: обеспечение пользователям потенциальной возможности
доступа к разделяемым ресурсам сети [3]. Все остальные требования связаны с
качеством выполнения основной задачи. Для разных логических типов сетей
приоритетными параметрами могут быть производительность, надежность,
совместимость,
управляемость,
защищенность,
расширяемость,
масштабируемость и их совокупность.
Понятие «качество обслуживания» (QoS, Quality of Service) чаще всего не
идентично понятию «качество сети». Под QoS обычно понимается
производительность и надежность.
Корпоративные сети передачи данных (КСПД) представляют собой
территориально распределенные, соединенные между собой сегменты единой
сети, использующие выделенные централизованные ресурсы и сервисы. Цель
построения корпоративных сетей передачи данных – обеспечение транспорта для
территориально распределенных бизнес-приложений. К таким приложениям
обычно относят сетевые базы данных, информационные порталы, электронную
почту, традиционный файловый обмен, IP телефонию, видеоконференцсвязь и
дистанционное обучение. КСПД - один из важнейших инструментов развития
бизнеса. Качественную и надежную корпоративную сеть имеют, в первую
очередь, географически распределенные компании, бизнес которых зависит от
надежности и гибкости совместной работы ее подразделений [4].
Построение КСПД в общем - это организация связности по протоколу IP
между рабочими станциями и серверами предприятия. Сеть образуется
совокупностью узлов связи, располагаемых на территории офисов или других
точек присутствия предприятия. В основе построения корпоративных сетей
передачи данных положена методология проектирования компании Cisco Systems
на основе композитной сетевой модели предприятия. Данное решение – это
модульный подход к построению структуры сети. Методология решения
позволяет строить как небольшие сети, объединяющие несколько офисов, так и
крупные, включающие сотни узлов.
Развивая сеть путем добавления новых модулей или узлов, подход
обеспечивает предсказуемость качественных характеристик сети и требует
минимальных усилий и средств для поиска и устранения неисправностей.
8
В основе композитной модели (рисунок 1.3) лежит принцип разделения сети
на модули (декомпозиции). Каждый характеризуется свойственными только ему
функциями и особенностями реализации. Ключевым компонентом, связующим
узлы КСПД, является услуга связи, которая обеспечивает передачу трафика между
узлами. Виды услуг связи, используемые при организации каналов между узлами,
делятся на следующие группы:
1) выделенные линии связи – оптические или медные кабели,
соединяющие узлы сети заказчика (это могут быть как свои, так и
арендуемые линии связи);
2) выделенные каналы данных – каналы данных предоставляемые
оператором связи поверх своей сети передачи данных:
 Frame Relay (PVC);
 ATM (PVC);
 E1/E3/STM-1;
 Ethernet VLAN;
3) услуги по соединению на базе «группового» доступа:
 IPVPN;
 VPLS – Virtual Private LAN Service. Технология позволяет эмулировать
распределенную ЛВС поверх сети Оператора;
 сеть «Интернет».
Рисунок 1.3 - Основные модули узла КСПД
Принципиальная разница между этими типами услуг заключается в
различном механизме передачи трафика между сетевыми узлами клиента. В
первом случае используются выделенные каналы связи, то есть трафик проходит
строго по определенным направлениям. В случае группового доступа трафик
может проходить произвольно между любыми офисами. Второй способ
обеспечивает лучшие скоростные характеристики передачи трафика и
оптимальное «дешевое» использование полосы пропускания.
Узлы сетей передачи данных можно классифицировать в три группы:
центральный узел, отделение/крупный узел, конечный узел.
9
Центральные узлы – это наиболее крупные узлы сети. На данных узлах
осуществляется консолидация информационных ресурсов, размещается основная
масса серверов приложений, развертываются выделенные подсистемы
безопасности, и осуществляется стыковка с внешними сетями.
Отделение/крупные узлы – "основная масса" сети. Здесь размещаются
информационные ресурсы, имеющие только локальное значение и
предоставляющие сервисы только локально - абонентам данного узла.
Конечный узел – данный тип узла является самым маломощным. В его
составе нет никаких информационных ресурсов и серверов приложений. Данные
узлы предназначены только для подключения пользователей.
Классификация типов узлов весьма условная, но она помогает добиться
большей легкости при первичной декомпозиции при проектировании. Например,
в крупных компаниях – системных интеграторах – принято следующее деление –
конечный узел (SOHO, Small office or Home office) до 48 задействованных портов
СПД или абонентов, отделение – до 300, центральный узел – все, что более 300.
1.2
Недостатки и дополнительные возможности сетей Ethernet
Большинство экспертов уверены в том, что технология Ethernet станет
основой [5] для построения единой конвергентной сетевой инфраструктуры
ЦОД. Институт IEEE [6] разрабатывает стандарты, которые должны обеспечить
гарантированную полосу пропускания и контроль потока для трафика с учетом
его приоритета, а также более усовершенствованные механизмы управления
потоками. С этими нововведениями Ethernet сможет заменить в ЦОД
существующие сети Fibre Channel [7] и Infiniband [8], а также существенно
повысить производительность работы новых Storage Area Network (SAN)
[9]систем на основе iSCSI [10].
Поддержка мобильности виртуальных машин, технология Fibre Channel
over Ethernet (FCoE) [11] и другие новые приложения требуют построения
крупномасштабных сетей, функционирующих на втором уровне модели OSI
[12].
Постоянно совершенствуясь, Ethernet превратился сегодня в наиболее
масштабируемую и экономически эффективную технологию для построения
сетей TCP/IP.
Трафик ЛВС менее всего зависит от характеристик сети, но активно
использует свойственные Ethernet технологии широковещательной/групповой
рассылки, виртуальных ЛВС (Virtual Local Area Network, VLAN). Для
эффективной работы SAN необходима малая задержка и передача пакетов без
потерь. Для реализации высокопроизводительных вычислительных систем
(High-Performance Computing Cluster, HPCC [13]) требуется еще меньшая
задержка и широкая полоса пропускания. Последние достижения в области
технологии iSCSI привели к тому, что все больше заказчиков рассматривают ее
как надежное решение для сетей SAN.
Благодаря своей гибкости, Ethernet сегодня доминирует в большинстве
сетевых сред. Современные технологии обеспечивают скорость 10 Гбит/с (на
10
один канал), в ближайшем будущем скорость возрастет до 100-Гбит/с, а в более
отдаленной перспективе возможно появление терабитного варианта Ethernet. В
результате в настоящее время Ethernet рассматривается в качестве основного
кандидата для конвергентной инфраструктуры ЦОД.
Традиционные Ethernet сети обладают архитектурными недостатками,
связанными с принципом доступа к несущей среде: непредсказуемым временем
задержки, увеличением нагрузки на центральные процессоры серверов,
снижением производительности существующей инфраструктуры в результате
использования части пропускной способности сети для передачи трафика сети
хранения; проблемами с обеспечением безопасности передаваемого трафика.
Традиционная технология Ethernet не пригодна для передачи критичного к
потерям трафика, в частности, трафика сетей хранения, не может играть роль
надежного транспорта канального уровня.
Над вопросом усовершенствования традиционного протокола Ethernet на
протяжении ряда лет работали несколько организаций. Итогом их труда стал
набор усовершенствований, получивших название Converged Enhanced Ethernet
(CEE), Data Center Bridging (DCB) [14] и Cisco Data Center Ethernet (DCE). В их
основе лежат одни и те же базовые спецификации. Вместе с тем необходимо
учитывать, что DCE содержит расширенный набор возможностей по сравнению
с CEE и DCB.
Data Center Ethernet представляет собой архитектуру на базе набора
открытых стандартов расширений Ethernet, которая предназначена для
улучшения и расширения функционала классического Ethernet в соответствии с
требованиями, предъявляемыми к Ethernet как к конвергентному транспорту
современного ЦОД.
DCE включает в себя два основных компонента: набор расширений
Ethernet и аппаратные средства, обеспечивающие внутреннюю передачу
трафика без потерь (Lossless Ethernet Switch Fabric).
Термин Lossless Ethernet определяет тип коммутаторов Ethernet, которые
имеют ряд дополнительных функциональных возможностей, основной из
которых является возможность передачи данных без потерь, вследствие
перегрузок сети (lossless). В lossless сетях, достаточно важно блокировать
операции I/O, поскольку в отличие от TCP/IP потеря одного пакета, обычно
ведет к прерыванию передачи последовательности данных и требует повторной
передачи всей последовательности протоколом верхнего уровнявместо
повторной передачи только нескольких потерянных блоков.
Cisco Data Center Ethernet (Cisco DCE) включает в себя два основных
компонента: набор расширений Ethernet и аппаратные средства,
обеспечивающие внутреннюю передачу трафика без потерь. Набор расширений
Cisco DCE содержит как обязательный, так и опциональный функционал.
К обязательному функционалу относятся следующие расширения:
а) механизм управления потоком на основе приоритетов (Priority-based
Flow Control, PFC) [15]. PFC расширяет функционал стандартного механизма
PAUSE (описанного в стандарте IEEE 802.3x). Если механизм PAUSE вызывает
прекращение передачи всего трафика по каналу Ethernet, то механизм
11
PFCразделяет его на восемь виртуальных полос (virtual line) и позволяет
управлять передачей трафика на основе приоритетов раздельно для каждой
линии. Таким образом, можно создать линию без потерь (losslesslane) для
чувствительного к потерям трафика (такого как Fibre Channel) и использовать
остальные линии в стандартном режиме сброса пакетов для обычного трафика
IP. Механизм Priority-based Flow Control описан в стандарте IEEE 802.1Qbb
[15];
б)Enhanced Transmission Selection (ETS) обеспечивает управление
разделением пропускной способности консолидированного канала для разных
типов линий, решая задачу совместной передачи разных типов трафика без
ущерба для качества. Этот инструмент описан в стандарте IEEE 802.1Qaz [16];
в)Data Center Bridginge Xchange (DCBX) [63] отвечает за обнаружение и
автоматическое согласование ряда параметров, включая управление полосой и
потоком по классам, а также управление перегрузками и логическим
состоянием полос. Кроме того, с помощью механизма DCBX
взаимодействующие устройства определяют совместимость соседнего
устройства с DCE, т.е. очерчивают логическую границу домена DCE в сети
ЦОД. Механизм Data Center Bridginge Xchange описан в стандарте IEEE
802.1Qaz;
г) Layer 2 Multi-Pathing (L2MP). В отличие от классического протокола
Spanning Tree, блокирующего множественные соединения между узлами,
механизм L2MP обеспечивает возможность одновременного использования
нескольких параллельных путей, благодаря чему пропускная способность
расходуется более эффективно. Механизм Layer 2 Multi-Pathing описан в
стандарте IEEE 802.1Qau [17].
Вторая составляющей архитектуры DCE — «коммутационная фабрика
без потерь» (Lossless Ethernet Switch Fabric) — является не менее важной, чем
набор расширений Ethernet. Для того чтобы обеспечить реальную передачу
трафика Ethernet без потерь, необходимо реализовать два обязательных
требования: механизм приостановки передачи трафика по каналу в
соответствии с классом трафика, такой как PFC, и метод приостановки трафика
от входящего к исходящему порту через внутреннюю коммутационную
фабрику.
Передача трафика без потерь внутри коммутационной фабрики
достигается за счет объединения механизма PFC для приостановки трафика на
входном порту коммутатора и механизма управления очередями на выходном
порту коммутатора для предотвращения передачи пакетов внутри фабрики в
случае недоступности выходного порта (механизм Virtual Output Queues, VOQ
[18]). Таким образом, при соблюдении двух упомянутых выше требований
реализуется полноценный сквозной Ethernet без потерь.
Технология Brocade Virtual Cluster Switching (VCS) [19] позволяет
компаниям уменьшить сложность и снизить стоимость их сетевой
инфраструктуры за счет использования новой архитектуры Ethernet-фабрики
для ЦОД. VCS увеличивает масштабируемость и эффективность использования
сети, кардинально упрощает архитектуру и увеличивает доступность
12
приложений, что необходимо для современных центров обработки данных,
использующих виртуализацию.VCS включает набор динамических сервисов
расширяющих функционал и обеспечивающих защиту инвестиций заказчиков,
что делает эту технологию основой для построения сетей виртуальных ЦОД в
соответствии с рисунком 1.4.
Рисунок 1.4– Ethernet-фабрика VCS
Ethernet-фабрика позволяет обойти такие ограничения традиционной
многоуровневой архитектуры ЦОД как:
а) образование петель трафика при неправильной настройке протокола
STP;
б) блокировку части портов и невозможность их использования для
передачи трафика;
в) задержки и потери пакетов при изменениях топологии сети;
г) сложность в настройке большого количества устройств.
VCS позволяет отойти от идеологии настройки и функционирования
коммутаторов как самостоятельных устройств, имеющих собственные уровни
управления и передачи данных. Теперь коммутаторы работают в составе
фабрики, имеющей единый интерфейс управления и передачи данных вне
зависимости от количества подключенных к фабрике устройств, количества и
типа соединений между ними. Новые коммутаторы, подключаемые к фабрике,
присоединяются и настраиваются автоматически без вмешательства
администратора. Снаружи фабрика выглядит как логически единый коммутатор
с множеством внешних портов.
Одним из прогрессивных методов канальной коммутации в Интернет
является технология многопротокольной коммутации на основе меток
(Multiprotocol Label Switching — MPLS). MPLS-масштабируемый независимый
механизмом передачи данных. В сети MPLS, пакетам данных присваиваются
особые метки. Решение о передаче пакета данных другому узлу сети
(коммутация) осуществляется только на основании метки без необходимости
13
изучения пакета данных. Такая технология сделала возможным создание
виртуального канала связи независимо от среды передачи и использующего
любой протокол канального и сетевого уровней.
Классификация трафика по нескольким параметрам позволяет
маршрутизировать трафик каждого класса по специально оптимизированному
пути администратором сети.
При точном планировании маршрутов и правил технология MPLS
обеспечивает высокий уровень контроля над трафиком. Это является
предпосылкой к более производительной работе сетей, позволяет гарантировать
качество услуг, позволяющее адаптировать сеть к потребностям пользователей.
Критерии, применимые в MPLS сетях для классификации пакетов, различаются
в зависимости от задач.
1.3
Программно-конфигурируемые сети
Компьютерные сети в ЦОД, как правило, строятся на базе протокола
Ethernet. В основе работы коммутатора Ethernet лежит принцип программного
управления на основе таблицы коммутации. Управление таблицами
коммутации дает возможность произвольным образом управлять поведением и
скоростными характеристиками и отдельного коммутатора, и параметрами
передаваемых потоков данных в масштабах всей сети Ethernet [20].
При обработке пакетов данных коммутатор Ethernet обращается к
таблице коммутации. На основании полученной информации, в том числе
адреса порта получателя, параметров качества обслуживания, коммутационная
матрица осуществляет дальнейшую обработку и передачу данных на целевой
выходной порт в соответствии с рисунком 1.5.
Рисунок 1.5 – Обработка и продвижение данных в коммутаторе
Основная идея ПКС состоит в том, чтобы, не изменяя существующего
сетевого
оборудования,
отделить
(перехватить)
управление
этим
оборудованием (маршрутизаторами и коммутаторами) за счет создания
специального программного обеспечения, которое может работать на обычном
отдельном компьютере и находится под контролем администратора Сети.
Для реализации этой идеи специалистами из Стенфорда и Беркли был
разработан открытый протокол OpenFlow [21] для управления маршрутизацией
и коммутацией в Сети, не ориентированный на продукты какого-то отдельного
14
производителя. С помощью этого протокола специалисты сами могут
определять и контролировать: кто с кем, при каких условиях и с каким
качеством может взаимодействовать в Сети. Все маршрутизаторы и
коммутаторы объединяются под управлением Сетевой Операционной Системы
(СОС), которая обеспечивает приложениям доступ к управлению сетью и
которая постоянно отслеживает конфигурацию средств Сети.
В коммутаторе OpenFlow реализован только уровень передачи данных.
Вместо процессора обработки используется более простой контроллер, в задачи
которого входит принятие поступающего кадра, извлечение из него MACадреса и немедленная передача кадра коммутационной матрице, если адрес есть
в таблице. Если адрес отсутствует, коммутатор отправляет запрос на
центральный контроллер сети OpenFlow и на основании ответа добавляет
необходимые записи в таблицу коммутации. После этого коммутатор
осуществляет обработку кадра.
Концепция гибридного коммутатора OpenFlow [22] предполагает
наличие в коммутаторе и традиционного уровня управления, и контроллера
OpenFlow. Это позволяет реализовать функциональность OpenFlow в
действующих сетях Ethernet и, в частности, осуществлять разработку нового
программного обеспечения и протоколов, не мешая работе остальных
пользователей сети.
1.4
Системы управления сетями
Согласно рекомендациям ISO 7498-4 [12] существуют следующие
функции средств управления сетью:
а) управление именованием и конфигурацией сети, заключается в
настройке компонентов сети, таких как идентификаторы и сетевые адреса,
местоположение, настройка параметров сетевых операционных систем,
создание и поддержание схемы сети в актуальном состоянии.
б) обработка ошибок, заключается в поиске неисправностей в работе
сети и устранении их последствий.
в) определение производительности, заключается в оценке на основе
накопленных статистических данных о работе сети времени отказа и трафика.
Позволяет планировать расширение сети.
г) управление безопасностью, заключается в сохранении целостности
данных, контроле доступа к данным, аутентификации, ключей шифрования,
управлении внешним доступом, полномочиями и паролями, стыковка с
другими сетями.
д) мониторинг работы сети, заключается в надзоре за имеющимся
оборудованием и ресурсами.
Вышеуказанные функции средств управления сетью охватывают не
только анализ и мониторинг работы сети, которые нужны для ее настройки, но
и различные меры воздействия на сеть, такие как управление структурой сети и
безопасностью. Обычно создание плана настройки и модернизации сети
рассматривается отдельно от системы управления сетью, несмотря на то, что
15
существуют системы управления, включающие в себя экспертные системы. Их
задача состоит в определении совместно с администратором сети плана по ее
настройке. На сегодняшний момент среди систем управления просматриваются
два направления:
а) объединение функций управления системами с сетями в одном
программном средстве;
б) разделение системы управления на несколько разрозненных
контроллеров, которые собирают информацию о работе сети и состоянии
устройств и систем и выполняют некоторые управляющие действия.
Протокол SNMP (Simple Network Management Protocol)[23] является
одним из наиболее распространенных протоколов управления сетью. Основным
преимуществом этого протокола является независимость от производителей,
простота и доступность. Он позволяет получать от устройств информацию об
их состоянии, производительности и других параметрах, хранящихся в базе
данных сетевых устройств - Management Information Base (MIB) [24]. Структура
этой базы определяется набором имен переменных, их типов и допустимыми
операциями над ними.
Сравнение компьютерных сетей с программно-конфигурируемыми
сетями на основе технологии OpenFlow демонстрирует значительные
преимущества последних для построения вычислительных центров обработки
данных, т.к. программно-конфигурируемые сети с помощью стандартного
способа управления таблицами потока в маршрутизаторах позволяют
эффективно организовывать потоки данных в сетях за счет их группировки и
изоляции, что дает возможность эффективно управлять и локализовать трафик
исполняющихся в центрах обработки данных вычислительных задач.
16
2
Эффективность управления сетевой инфраструктурой
2.1 Понятие эффективности
сетей и компьютерных сетей
распределенных
вычислительных
В общем случае показатель эффективности функционирования
компьютерной сети (КС) как человеко-машинной системы представляет собой
количественно (реже качественно) оцениваемую характеристику с учетом
выходных временных, точностных и надежностных показателей трудовой
деятельности человека-оператора (пользователей, управленческого и
обслуживающего персонала сети); параметров и характеристик (аппаратных,
программных и информационных средств сети, рассматриваемых с системных
позиций);
параметров
и
характеристик,
определяющих
условия
функционирования сети. Далее рассматриваются только количественно
оцениваемые показатели эффективности КС.
Показатели эффективности сети W определяются процессами ее
функционирования, они являются функционалом от этого процесса. В
соответствии с конкретизацией понятия эффективности показатели множества
W разделяются на три группы:
W={Wц, Wт, Wэ},
(2.1)
где Wц – показатели целевой эффективности функционирования сети, или
эффективности использования сети по целевому назначению, количественная
мера соответствия сети своему назначению;
Wт – показатели технической эффективности сети, количественная мера,
отражающая техническое совершенство КС;
Wэ – показатели экономической эффективности функционирования КС,
количественная мера экономической целесообразности использования сети.
Принадлежность того или иного показателя эффективности к одной из
указанных групп не всегда бывает однозначной. Это определяется назначением
сети и целями ее исследования.
Любая компьютерная сеть, используемая той или иной организацией (или
отдельными людьми), прямо или опосредованно участвует в достижении целей
деятельности этой организации, в решении конкретных задач. Показатели
целевой эффективности КС (Wц) предназначены для количественной оценки
степени этого участия. С их помощью оценивается эффект (целевой результат),
получаемый за счет решения тех или иных прикладных задач с использованием
общесетевых ресурсов (аппаратных, программных, информационных), а не с
использованием других, менее эффективных, средств [25].
Показатели множества Wц отличаются большим многообразием. Для их
количественной оценки применяются самые различные единицы измерения.
Примеры показателей целевой эффективности:
а) временные показатели целевого использования сетевых структур в
управлении деятельностью предприятия, характеризующие повышение
оперативности управления. Это повышение достигается использованием
вычислительных мощностей сети для оперативной реализации алгоритмов
17
управления и коммуникационных средств для доставки результатов выработки
управленческих решений по назначению;
б) точностные (Wтн), надежностные (Wн) и временные (Wв) показатели,
применяемые в системах специального назначения для оценки эффективности
использования в них сетевых структур. Например, прирост (за счет
использования сети) вероятности выполнения некоторого задания, сокращение
времени на выполнение этого задания, повышение точности решения
некоторой задачи;
в) показатели целевой эффективности КС при решении задач
планирования хозяйственной деятельности на различных уровнях (отрасль,
подотрасль, объединение, фирма, предприятие).
Могут быть две группы этих показателей:
1) показатели эффективности использования ресурсов сети для
составления краткосрочных, текущих планов. Эффект определяется тем, что
разработка планов при этом осуществляется быстрее, точнее и полнее, с учетом
большего количества факторов;
2) показатели эффективности использования сетевых структур для
составления долгосрочных, перспективных планов. В этом случае эффект
определяется не только тем, что разработанный с применением КС
перспективный план будет получен быстрее и окажется точнее и полнее, но и
тем, что он вообще стал возможным благодаря использованию сетевых
ресурсов;
г) показатели, характеризующие повышение качества продукции,
технология производства которой включает использование КС (например,
использование ЛВС на предприятиях);
д) показатели, характеризующие экономику производства продукции с
применением сетевых структур (например, повышение производительности
труда, увеличение объема выпускаемой продукции, снижение ее
себестоимости, увеличение доли экспортируемой продукции), если цель
использования КС заключается именно в улучшении характеристик
производственно-хозяйственной деятельности предприятия или организации. В
этом случае показатели целевой эффективности одновременно являются и
показателями экономической эффективности.
Показатели технической эффективности КС (Wт) используются для оценки
компьютерной сети как сложной аппаратно-программно-информационной
кибернетической человеко-машинной системы при работе ее в различных
режимах и условиях. При этом не принимается во внимание эффект,
получаемый за счет реализации результатов решения задач (удовлетворения
запросов) пользователей сети. Оцениваются только технические возможности
КС. Оценка с помощью показателей Wт может осуществляться как для всей
сети, так и отдельных ее систем, подсистем, звеньев и узлов.
Примеры показателей технической эффективности КС:
а)Тзс – суммарная задержка в сети, вносимая в передачу данных
пользователя, т.е. время доставки сообщения от отправителя к получателю. Эта
18
задержка зависит от длины маршрута, скорости передачи электрических
сигналов, несущих информацию, пропускной способности канала связи,
времени на прием, обработку и передачу информации в каждом
промежуточном узле связи;
б) Vп – скорость передачи пакетов: количество пакетов, передаваемых по
сети за единицу времени;
в) Vпд – фактическая пропускная способность сети: средний поток данных,
фактически передаваемых через сеть (измеряется в Кбит/с, Мбит/с). В отличие
от физической пропускной способности канала или линии связи Vк, которая
определяется возможностями и свойствами передающей среды и является
одним из главных ее параметров, фактическая пропускная способность зависит
от величины Vк, но также определяется и многими другими факторами,
например, используемыми методами доступа в передающую среду, загрузкой
канала, задержкой передаваемой информации в промежуточных узлах связи.
Показатели экономической эффективности использования КС (Wэ). Для
оценки экономической эффективности всей сети или отдельных ее элементов и
звеньев могут использоваться две группы показателей: интегральные
показатели и частные показатели.
2.2
и сетей
Производительность распределенных вычислительных систем
Эффективность вычислительных систем и сетей в значительной мере
определяется
их
производительностью.
Компьютерные
сети
как
распределенные системы обладают высокой производительностью, что в свою
очередь достигается за счет распараллеливания вычислительных работ между
несколькими рабочими станциями сети.
Выделим несколько основных показателей производительности сети:
- время ответа (отклика, реакции);
- пропускная способность;
- задержка передачи пакета и вариация задержки передачи (джиттер).
Время реакции сети, определяемое как интервал времени между
возникновением запроса пользователя к какому-либо сетевому приложению и
получением ответа на этот запрос, является, вообще говоря, основным
показателем производительности сети с точки зрения любого пользователя
сети. Этот показатель зависит от многих факторов: от загрузки сегментов сети,
включая сервер, коммутаторы и маршрутизатор, через которые проходит
данный запрос, от типа приложения, от времени дня и других.
В связи с этим используют также усредненную величину этого
показателя, так называемую средневзвешенную оценку времени реакции сети
по пользователям, серверам и времени дня [25].
Как составляющие, во время реакции сети обычно входят время
подготовки запросов на рабочих станциях пользователей, время передачи
запросов между пользователями и сервером через сегменты сети, время
обработки запросов на сервере, время передачи ответов от сервера к
19
пользователю и время обработки получаемых от сервера ответов на рабочей
станции пользователя.
При общем анализе производительности сети важно знать эти
составляющие времени реакции. Именно они позволяют оценить показатели
производительности отдельных элементов сети, выявить ее узкие места и, если
таковые имеются, то решить вопросы по модернизации сети для устранения
узких мест.
Пропускная способность сети или ее сегмента характеризуется объемом
данных в битах, переданных сетью или ее сегментом в единицу времени
(обычно в секунду). Таким образом, пропускная способность измеряется либо в
битах в секунду, либо в пакетах в секунду. Она связана со скоростью передачи
пакетов между различными узлами сети по каналам связи и поэтому
характеризует функцию транспортировки сообщений. Пропускная способность
выступает в качестве входного параметра при расчетах показателей
производительности сети, в том числе времени реакции сети.
В научной литературе выделяют мгновенную, максимальную и среднюю
пропускную способность [25].
Средняя пропускная способность определяется делением общего объема
переданных данных на время их передачи, например, час, день или неделя.
Мгновенная пропускная способность определяется за очень короткий
промежуток времени (от 10 мс до 1 с).
Максимальная пропускная способность – это наибольшая пропускная
способность, измеренная в течение заданного периода наблюдения. Она в
основном характеризует возможность сети справляться с пиковыми
нагрузками, когда все пользователи одновременно подключаются к сети и
формируют свои запросы к файлам и базам данных.
При проектировании, настройке и оптимизации сети на базе пилотных
сетей используют такие показатели, как средняя и максимальная пропускные
способности. Они позволяют оценить работу сети на большом промежутке
времени, в течение которого чередуются пики и спады интенсивности трафика.
Обычно пропускную способность измеряют между любыми двумя узлами
сети, например, между рабочей станцией пользователя и сервером, а также
между входным и выходным портами маршрутизатора. При анализе
производительности сети необходимо знать пропускную способность
отдельных элементов сети и ее сегментов.
В связи с последовательным способом передачи пакетов сообщений
узлами сети пропускная способность составного пути в сети будет равна
минимальной из пропускных способностей составляющих участков маршрута.
Поэтому для повышения пропускной способности составного пути необходимо
анализировать самые медленные участки.
Из теории массового обслуживания известно, что если средняя
интенсивность передаваемого по составному пути трафика будет выше средней
пропускной способности самого медленного участка, то очередь пакетов к
этому устройству будет расти теоретически до бесконечности. На практике же
20
передача пакетов продолжится лишь до тех пор, пока не заполнится его буфер,
а затем пакеты просто будут отброшены.
При исследовании компьютерных сетей также используют общую
пропускную способность сети, определяемую средним объемом информации
(количеством пакетов), переданной между всеми узлами сети в единицу
времени. Эту общую пропускную способность сети и принимают за ее
производительность. По аналогии, в теории вычислительных систем, под
производительностью вычислительной системы понимают среднее количество
заданий, решаемых системой в единицу времени.
Задержка передачи пакетов определяется как интервал времени между
моментом поступления пакета на вход какого-либо сетевого ресурса или
сегмента сети и моментом появления его на выходе этого ресурса или сегмента
сети. Этот показатель производительности в теории массового обслуживания
равносилен времени пребывания требования в системе, равное времени
ожидания требования в очереди плюс время его обслуживания.
Максимальная задержка передачи и вариация задержки являются также
качественными показателями сети. Обычно не все типы трафика чувствительны
к задержкам передачи. Например, в локальных вычислительных сетях,
задержки не превышают сотен миллисекунд. Такие задержки передачи пакетов,
порождаемые файловой службой, службой электронной почты или службой
печати, мало влияют на качество этих служб с точки зрения пользователя сети.
Иное дело наблюдается при передаче голосовых и видеоданных в
мультисервисных сетях, когда задержки передачи пакетов могут приводить к
значительному
снижению
качества
предоставляемой
пользователю
информации [25].
Для распределенного вычислительного ЦОД помимо характеристик
производительности, отражающих работу сети в целом, большое значение
имеют показатели, учитывающие обработку вычислительных задач, а также
функционирование СХД.
К числу характеристик производительности, принимающих во внимание
вычислительные задачи, можно отнести:
а) время выполнения эталонного набора задач;
б) среднюю загруженность вычислительных ядер при выполнении
эталонного набора задач.
Время выполнения эталонного набора задач определяется как разность
между временем завершения исполнения последней задачи и временем запуска
первой задачи из набора. Данный интегральный целевой показатель позволяет
количественно оценить прикладную составляющую эффективности работы
распределенного вычислительного ЦОД на сформированном наборе
пользовательских вычислительных задач. Эталонный набор должен включать
параллельные прикладные задачи с высокой интенсивностью обмена трафиком,
отражающие специфику использования современных вычислительных ЦОД. К
числу последних можно отнести кодирование видео и аудио данных,
компьютерное моделирование, синтез белковых структур, цифровую обработку
сигналов, виртуальные испытательные стенды.
21
Показатель средней загруженности вычислительных ядер при
выполнении эталонного набора задач характеризует процент использования
(загрузки) вычислительных ядер реальных или виртуальных узлов ЦОД.
Существуют вариации в вычислении данного показателя – можно учитывать
загрузку абсолютно всех вычислительных ядер системы на протяжении всего
расчетного времени или исключать из рассмотрения загрузку свободных
вычислительных ядер в те моменты времени, когда очередь задач
вычислительной системы пуста. Использование второго варианта позволяет
снизить влияние особенностей набора задач, в том числе учесть время простоя
ресурсов вычислительной системы в начале и в конце выполнения задач
эталонного набора.
К числу показателей, характеризующих производительность работы СХД
распределенного вычислительного ЦОД, можно отнести установившуюся
скорость чтения данных и установившуюся скорость записи при выполнении
эталонного набора задач. Данные характеристики вычисляются следующим
образом: промежуток времени обработки задач эталонного набора разбивается
на небольшие интервалы равной длины, на каждом из них определяются
средние значения скорости чтения и записи, а затем для определения
соответствующих установившихся значений вычисляются максимумы средних
величин по всем интервалам. В отличие от средних значений чтения и записи
по всему промежутку времени обработки задач данные показатели являются
более репрезентативными.
В процессе функционирования распределенного вычислительного ЦОД
также возникают непроизводительные инфраструктурные издержки, связанные
с обслуживанием эталонного набора задач. Они могут быть описаны с
помощью следующих показателей:
а) среднее время вычисления прогнозных значений коммуникационных
параметров задачи;
б) среднее время вычисления оптимального расписания выполнения
задач.
Первый показатель отражает среднее время, затрачиваемое системой на
моделирование состояния компьютерной сети и определение эффективного
способа перенастройки параметров маршрутизации под каждую задачу
эталонного набора. Второй – среднее время, которое тратит планировщик
системы на пересчет текущего расписания при возникновении одного из
событий – появления в очереди новой задачи из эталонного набора или
завершения уже запущенной.
К числу основных непроизводительных показателей эффективности,
характеризующих
особенности
функционирования
распределенных
вычислительных ЦОД, можно отнести сбалансированность загрузки ресурсов:
вычислительных ядер, оперативной памяти, дисковых накопителей. С точки
зрения целей исследования наиболее адекватной характеристикой является
сбалансированность загрузки вычислительных ядер (реальных или
виртуальных), которая определяется, как вариация показателя средней
загруженности вычислительного ядра по всем вычислительным ядрам системы
22
на протяжении всего расчетного времени. Небольшие значения данной
характеристики позволяют судить о равномерной загрузке вычислительных
ресурсов ЦОД.
Показатели эффективности вычислительных систем и компьютерных
сетей могут быть определены как проведением экспериментов на реальных
системах и сетях, так и путем их математического моделирования.
2.3 Применение теории массового обслуживания к исследованию
вычислительных систем и компьютерных сетей
Поступление данных в компьютерных сетях имеет вероятностный
характер при детерминированной их обработке в каналах связи и узлах
коммутации. Поэтому модели теории массового обслуживания широко
используются для анализа и проектирования компьютерных сетей.
Применяя методы системного анализа, теории сложных систем и теории
вычислительных систем, проектирование любой информационной системы
можно представить как решение последовательности проектных задач синтеза
и анализа системы и ее составляющих. Математическое моделирование
является одним из наиболее распространенных методов исследования
процессов функционирования сложных систем. В настоящее время известно
достаточно большое количество методов и способов построения
математических моделей и моделирующих алгоритмов систем, как на
вероятностной,
так
и
детерминированной
основе.
Наиболее
распространенными из них являются системы и сети массового обслуживания.
В терминах теории массового обслуживания (ТМО) описываются многие
реальные системы: вычислительные системы, компьютерные сети и их узлы, и
многие другие. В таких системах возможны очереди и отказы в обслуживании.
В вычислительных системах и компьютерных сетях роль обслуживающего
прибора играют ЭВМ, рабочие станции, каналы передачи данных (линии
связи), коммутаторы и маршрутизаторы, а роль заявок (требований) – задания,
запросы, пакеты данных и др. Источником заявок служат различные терминалы
и рабочие станции пользователей. При этом операционная система отдельной
ЭВМ или сетевая операционная система исполняет функции диспетчера,
определяя очередность решения задач[26].
Усложнение взаимодействия устройств и процессов в распределенных
вычислительных системах, к которым относятся и компьютерные сети, не
позволяют их исследовать только с помощью классических методов и моделей
массового обслуживания. Для этих целей эффективнее использовать сети
массового обслуживания (СеМО), в рамках которых хорошо отображаются
стохастические процессы функционирования компьютерных сетей.
СеМО представляет собой совокупность конечного числа N
обслуживающих узлов, в которой циркулируют требования, переходящие в
соответствии с заданной маршрутной матрицей из одного узла в другой. Под
узлом СеМО понимают систему массового обслуживания (СМО), состоящую
из K одинаковых приборов (каналов). Эти отдельные СМО отображают
23
функционально ресурсы реальной компьютерной сети (рабочие станции,
каналы передачи данных, коммутаторы и маршрутизаторы), связи между СМО
– структуру сети. Если поступающее требование застает все обслуживающие
приборы узла занятыми, то требование занимает очередь в буфере и ожидает
начала обслуживания.
Для графического представления СеМО используется граф, вершины
которого (узлы) соответствуют отдельным СМО, а дуги отображают связи
между узлами по аналогии со структурой компьютерной сети.
Маршрутная матрица P{pij} определяет структуру сети, предопределяя тем
самым переходы требований между узлами СеМО в соответствии с
переходными вероятностями pij,где pij вероятность того, что требование после
обслуживания в узле i перейдет в узел j. Вид матрицы Pзависит от того,
является СеМО открытой (разомкнутой) или замкнутой. В открытой сети
присутствует внешний источник требований, которые после поступления в сеть
и завершения обслуживания в ней, покидают сеть. Если внешний источник
принять за узел сети с номером 0, то будет выполнено равенство Nj0 p ij  1
(i=0,1,…,N).
Поступающий из внешнего источника в сеть поток требований
описывается законом распределения интервалов времени между соседними
требованиями. Если эти интервалы независимы и одинаково распределены, то
данный поток называется рекуррентным. Примером такого потока является
пуассоновский поток с функцией распределения F(t)=1-e-λt, где λ –
интенсивность потока.
Для определения интенсивностей всех потоков, циркулирующих в
открытой СеМО рассмотрим структуру i-го узла СеМО в соответствии с
рисунком 2.1.
Рисунок 2.1- Полная структура потоков в i-м узле СеМО
На рисунке 2.1 точка А – точка композиции (агрегирования) потоков,
точка В – точка декомпозиции (вероятностного разрежения) агрегированного
потока. Здесь приняты следующие обозначения:
i – номер узла СеМО (i=1,2,…,N);
N – число узлов СеМО;
λi– интенсивность потока на входе и выходе из i-го узла СеМО;
24
λ0i– интенсивность потока от внешнего источника;
pij– вероятности переходов из i-го узла в j-й узел (j=1,2,…,N);
μm –интенсивность обслуживания m-го прибора узла (m=1,2,…,K);
K – число обслуживающих приборов (каналов) узла.
Справедливы следующие уравнения равновесия потоков в сети массового
обслуживания в стационарном режиме:
N
λ i  λ 0i   p jiλ j (i  1,..., N) .(2.2)
j1
Из рисунка 2.1 и уравнений (2.2) следует, что на входе i-го узла
агрегируются (знак  ) разреженные выходные потоки (pjiλj) от других узлов.
Решение систем линейных алгебраических уравнений позволяет определить
интенсивности λiисредние значения интервалов времен между соседними
1
требованиями τi  λ i для каждого потока в сети массового обслуживания. Это
означает декомпозицию СеМО на отдельные узлы, что позволяет определить
все основные показатели производительности как узлов, так и всей сети
массового обслуживания.
Параметр ρ i ,характеризующий соотношение интенсивности входящего
потока и интенсивности обслуживания и называемый коэффициентом загрузки
i-го узла, играет важную роль в теории массового обслуживания
ρi  λ i /μ i .
Среднее время ожидания требования в очереди перед i-м узлом равно
Wi 
ρ i /μ i
,
1  ρi
а средняя задержка требования в i-м узле равна
Ti 
1/μ i
.
1  ρi
Среднюю длину очереди требований можно определить по формуле
Литлла
N λ W ,
qi
i i
а среднее количество требований N i вi-м узле - по формуле
N i  ρ i /(1  ρ i ) .
Зная характеристики отдельных узлов сети, нетрудно рассчитать
характеристики всей сети в целом, используя известные результаты теории
вычислительных систем. Для этого через α i  λ i /λ 0 (i=1,...,N) обозначим
коэффициенты передач требований, где λ 0 - интенсивность внешнего
источника требований, а значения интенсивностей λ i получаются решением
25
системы линейных уравнений. Тогда среднее время ожидания требования в
сети
N
Wс   α i Wi ,
i 1
а среднее время пребывания требования в сети
N
Tc
  α i Ti ,
i 1
где Wi и Ti - соответственно средние времена ожидания и пребывания
требований в i -ом узле (i=1,...,N).
Общая длина всех очередей в сети
N
N cq   N qi ,
i 1
а общее количество требований в сети
Nc
  Ni .
N
i 1
Приведенные
выше
результаты
составляют
основу
теории
экспоненциальных сетей. Сеть массового обслуживания называется
экспоненциальной, если входящие потоки требований в каждую СМО сети
пуассоновские, а времена обслуживания в любой СМО сети, имеют
экспоненциальное распределение. Это позволяет считать, что этапы
обслуживания независимы между собой и не зависят ни от параметров
входящего потока, ни от состояния сети, ни от маршрутов следования
требований. Во всех остальных случаях СеМО является не экспоненциальной.
В настоящее время теория экспоненциальных СеМО наиболее
разработана, и ее широко применяют как для исследования компьютерных
сетей, так и для исследования различных вычислительных систем.
В научной литературе СеМО классифицируют по многим признакам в
соответствии с рисунком 2.2. Если требования приходят в сеть от внешнего
источника и уходят из сети, то сеть называется разомкнутой. Если требования
не приходят в сеть и из нее не уходят, сеть называется замкнутой. Число
требований в замкнутой сети постоянно.В замкнутой СеМО циркулирует
фиксированное число требований, а внешний источник требований
отсутствует. Временные характеристики в такой СеМО измеряются
относительно псевдонулевой точки, которая выбирается на внешней дуге такой
сети.
26
Рисунок 2.2– Классификация СеМО
Важную роль в теории СеМО играет дисциплина обслуживания, которая
задает порядок выбора из очереди требования из буфера к освободившемуся
прибору. При этом выбираются требования одинакового приоритета. Основные
наиболее часто используемые дисциплины обслуживания: FIFO (First Input–
First Output), первым пришел – первым обслужен; LIFO (Last Input–First
Output), последним пришел – первым обслужен; RAND (Random), случайный
выбор из очереди. К примеру, дисциплина LIFO реализуется в буфере,
организованном по принципу стека.
В комбинированной сети постоянно циркулирует определенное число
требований и кроме них в ней присутствуют требования, поступающие от
внешних независимых источников. Например, в модели локальной
вычислительной сети, подключенной к Интернету, в качестве внешнего
источника требований выступает Интернет, кроме того, в такой СеМО
циркулируют требования (запросы), порождаемые в сети пользователями.
Поэтому такие сетевые модели широко используются при исследовании
компьютерных сетей как распределенных вычислительных систем.
В однородной сети всегда циркулируют требования одного класса, а в
неоднородной сети - требования различных классов. Требования относятся к
разным классам, если они различаются законом распределения длительности
обслуживания в узлах или же различаются маршрутами в сети. Такое может
происходить также в комбинированных СеМО, как было отмечено выше.
Следует отметить, что для случая произвольных законов распределений
интервалов поступления между требованиями и их обслуживания, теория сетей
массового обслуживания не располагает конечными результатами. Для этого
случая можно использовать теоретически обоснованные методы и алгоритмы
27
на основе математических операций над потоками и двумерной диффузионной
аппроксимации СМО [27], реализованные в программной системе «Анализ
производительности компьютерных сетей на основе аппроксимативного
подхода», разработанные авторами [28, 29].
На основе анализа принципов организации управления с помощью ПКС в
центрах обработки и хранения данных можно утверждать, что для оценки
эффективности функционирования таких систем с помощью расчетов
показателей производительности можно использовать математические методы
и модели, основанные на последних результатах теории массового
обслуживания.
2.4
Область применения программно-конфигурируемых сетей
На сегодняшний день самой перспективной областью применения
программно-конфигурируемых сетей являются центры обработки данных,
поскольку их трафик может полностью менять свою структуру в зависимости
от нагрузок и конфигурации программного обеспечения. Перенастройка
политик без централизации всего управления была бы крайне затруднительна.
Отдельной нишей являются виртуализированные и облачные ЦОД.
В виртуализированных и облачных ЦОД принцип выделения ресурсов
подразумевает
использование произвольной виртуальной машиной
произвольных ресурсов в недетерминированном порядке, что не позволяет
эффективно заранее настроить сеть. В такой динамической модели
виртуальные машины находятся в ЦОД, но функционируют так, как если бы
они были организованы в логические серверные пулы в сети каждого клиента,
несмотря на случайный порядок, в котором они создавались и распределялись
на вычислительные узлы.
Использование ПКС может распространяться на контроль границы сети,
включать в себя возможность балансировки нагрузки на множестве каналов
связи, идущих от коммутационных стоек. Без ПКС эта задача выполняется с
использованием традиционных протоколов маршрутизации на основе
состояния канала или на основе расширений протокола Spanning Tree.
Распределенная глобальная ПКС может снять ограничение на масштабы
физических кластеров.
Также ПКС может управлять трафиком на основе абонентов и
приложений при доступе к провайдерам услуг, которые разделяют ресурсы
между ЦОД. Это снижает затраты и ускоряет развертывание фиксированных и
мобильных служб доступа.
Коллективное использование несколькими операторами общей сетевой
инфраструктуры становится распространенной практикой. В рамках проекта
Nando ученые испанского Университета страны Басков доказали, что с
помощью OpenFlow и префиксов Ethernet PF можно не только строить
мультиоператорские сети Ethernet второго уровня, но и значительно снизить
затраты на создание сети, надежно разделить трафик разных абонентов и
операторов и предотвратить неавторизованный доступ. Используя связку
28
протоколов SIP/OpenFlow, можно будет не только устанавливать IP-адреса
отправителя и получателя, но и программным способом коммутировать
необходимые потоки и каналы данных в операторских сетях — не исключено,
еще до начала передачи данных.
В рамках проекта OpenRoads [30] разработчики Стэнфордского
университета, используя эшелонированные сети OpenFlow из коммутаторов,
точек доступа WiFi и базовых станций WiMAX, на практике
продемонстрировали бесшовный, без разрыва соединения, роуминг между
беспроводными сетями передачи данных разных стандартов.
2.5
Распределенные облачные вычисления
Облачные вычисления (Cloud Computing) – тип ИТ-услуги, поставляемой
в виде масштабируемой эластичной услуги с помощью сетевых технологий. На
базе облачных вычислений как технологии строятся облачные услуги.
Модели облачных услуг включают в себя несколько основных принципов
и множество их модификаций:
а) Инфраструктура как услуга (IaaS, Infrastructure as a service). Этот
подход позволяет предоставлять пользователям практически любые ресурсы
вычислительной инфраструктуры. В облаке есть возможность устанавливать и
запускать произвольное программное обеспечение, такое как операционные
системы, прикладное программное обеспечение. Пользователь контролирует
операционные системы, системы хранения данных и приложения, межсетевой
экран. Контроль и управление всей инфраструктурой осуществляется облачным
провайдером.
б) Платформа как услуга (PaaS, Platform as a service). Эта модель
позволяет пользователям развертывать приложения, разработанные с
использованием определенных языков программирования для структур и
инструментов на облаке. У пользователя также нет контроля над
инфраструктурой, но он полностью контролирует развернутые приложения. В
состав платформ входят программные средства разработки программного
обеспечения, например системы управления базами данных, интерпретаторы и
компиляторы языков программирования. Все это предоставляется облачным
провайдером.
в) Программное обеспечение как услуга (SaaS, Software as a service). Эта
модель позволяет пользователям получать доступ к приложениям, работающим
на облачной инфраструктуре. Пользователь не управляет инфраструктурой или
приложениями, за исключением ограниченного применения определенных
доступных параметров.
г) Аппаратное обеспечение как услуга (MaaS, Metal as a service). Эта
модель предназначена для быстрого распространения операционных систем с
одинаковым набором на нескольких серверах с использованием подходов,
используемых в облачных платформах. MaaS позволяет представить кластер в
виде набора ресурсов. Они могут запрашиваться в любой момент. В отличие от
облачных платформ, выделение ресурсов происходит на уровне физических
29
серверов, а не виртуальных машин. Администратор объединяет несколько
серверов в набор, а затем происходит подача команд с помощью вебинтерфейса или через командную строку на развертывание служб, например,
сервера базы данных, веб-сервера. В результате, пользователь получает сервера
с необходимой преднастроенной конфигурацией.
д) Безопасность как услуга (SEaaS, Security as a Service)–модель
обеспечения безопасности, предусматривающая использование удаленной
системы, находящейся в собственности третьей стороны (одного или
нескольких поставщиков услуги). Поставщик обеспечивает функции
безопасности, основанные на разделяемых технологических услугах, которые
потребляются в рамках модели «один ко многим» с оплатой по факту
использования объема потребленных услуг. В этой схеме могут быть
задействованы некоторые элементы оборудования заказчика, если того требует
поставщик телекоммуникационных услуг.
Компания Oracle также выделяет модель «База данных как услуга»
(DBaaS, Database аs a service), при которой заказчику предоставляется доступ к
созданной базе данных по предварительному требованию. Oracle предлагает
два варианта DBaaS: произвольная база данных и «база данных в облаке», в
котором создается виртуальный компьютер (IaaS) с установленной СУБД
(MaaS) и создана требуемая база данных. Интеграция как услуга (IaaS2,
Integration as a service) является интеграцией ряда функций (обеспечение
безопасных коммуникаций, интеграция данных, приложений, облачных
инструментов), поставляемой в виде услуги.
Все модели услуг могут работать на любой из следующих моделей
развертывания:
а) частные облака, предназначены для использования только в одной
организации, могут управляться самой организацией или третьей стороной,
физически располагаться как на территории организации, так и на внешней
территории;
б) общественные облака, открыты для широкой общественности,
находятся в управлении провайдера облака;
в) гибридные облака, представляющие собой объединение двух или более
облаков (частных и общественных), облака связаны друг с другом таким
образом, что данные и приложения могут перемещаться;
г) сообщество облаков, их инфраструктура поделена между несколькими
организациями, и она поддерживает конкретные сообщества.
Таким образом, чтобы облачные вычисления были эффективными, нужно
внести изменения в следующих областях:
а) Инфраструктура. Большинство инфраструктур в наше время либо
уже являются виртуальными, либо идут к этому. Инфраструктура становится
программируемой, серверы и приложения становятся подвижными.
б) Приложения. Виды приложений, которые работают на облаке,
приводят к изменениям сети. Многие приложения активно работают с
данными, используют параллельную и распределенную обработку, а также
другие функции.
30
в) Доступ. Возможен доступ с использованием виртуальных рабочих
столов, а также мобильных устройств.
г) Трафик. Использование облачных вычислений приводит к появлению
новых типов трафика для переноса данных между серверами.
Анализ сервисов/приложений, применяемых для управления сетевой
инфраструктурой в ПКС, показал необходимость использования виртуализации
и облачных технологий для построения вычислительных ЦОД.
31
3
Обзор протокола OpenFlow
3.1
Описание таблиц для протокола OpenFlow
OpenFlow-совместимые коммутаторы делятся на два типа: OpenFlow-only
(только OpenFlow) и OpenFlow-hybrid (OpenFlow-гибрид). Коммутаторы типа
OpenFlow-only поддерживают только операции OpenFlow, в этих коммутаторах
все пакеты обрабатываются обработчиком OpenFlow и не могут быть
обработаны чем-либо еще.
Коммутаторы типа OpenFlow-hybrid поддерживают все операции
OpenFlow и обычные операции коммутации Ethernet, т.е. традиционную
коммутацию второго уровня, VLAN, маршрутизацию третьего уровня, ACL и
QoS.
Эти коммутаторы должны обеспечивать механизм разделения вне
OpenFlow, который направляет трафик либо через обработчик пакетов
OpenFlow, либо через обычный обработчик пакетов. Например, коммутатор
может использовать теги VLAN или входящий порт пакета, чтобы определить,
следует ли обрабатывать пакет с помощью одного обработчика или другого,
или он может направить все пакеты обработчику OpenFlow.
OpenFlow-обработчик
каждого
OpenFlow-коммутатора
содержит
несколько таблиц потоков, а каждая таблица потоков содержит несколько
записей. OpenFlow-обработчик определяет, как пакет взаимодействует с этими
таблицами потоков в соответствии со схемой, представленной на рисунке 3.1.
Рисунок 3.1–Прохождение пакета через конвейер обработки [31]
OpenFlow-коммутатор может иметь только одну таблицу потоков, в этом
случае конвейер обработки значительно упрощается. Таблицы потоков в
OpenFlow-коммутаторах последовательно нумеруются, начиная с нуля.
Конвейерная обработка всегда начинается с первой таблицы потоков, пакет
сначала сравнивается с записями таблицы потоков с номером ноль. Другие
таблицы потоков могут быть использованы в зависимости от результата
сравнения с первой таблицей.
Если пакет совпадает с записью в таблице потоков, то выполняется
соответствующий этой записи набор инструкций. Инструкции в записи потока
могут явно перенаправлять пакет в другую таблицу потоков, где тот же процесс
повторяется снова. Записи потока могут перенаправлять пакет только в ту
таблицу, номер которой больше собственного номера таблицы, другими
32
словами, конвейерный процесс может идти только вперед, а не назад.
Очевидно, что записи последней таблицы конвейера не могут содержать
инструкции перехода на другую запись (Goto). Если соответствующая запись
потока не направляет пакеты в другую таблицу потоков, конвейер обработки
останавливается в этой таблице. Когда конвейерная обработка прекращается,
пакет обработан соответствующим набором действий и обычно отправлен.
Если пакет не соответствует ни одной записи в таблице потоков, то эта
таблица пропускается. Поведение в случае пропуска таблицы зависит от
настроек этой таблицы, по умолчанию – это отправка пакетов контроллеру
через канал управления, другой вариант – удаление пакета. Также возможен
случай, что при пропуске таблицы обработку пакетов следует продолжать, в
этом случае пакет обработается следующей по порядку таблицей.
В таблице 3.1 показаны поля для сравнения входящих пакетов. Каждая
запись может содержать либо конкретное значение, либо значение ANY (любой
пакет).
Таблица 3.1 – Поля пакетов для участия в процессе коммутации
№пп
Название поля
Расшифровка
1
2
3
1
IngressPort
Входящий интерфейс пакета
2
Metadata
Метаданные
3
Ethersrc
Ethernet адрес источника
4
Etherdst
Ethernet адрес получателя
5
Ethertype
Версия протокола Ethernet
6
VLAN id
Идентификатор сети VLAN
7
VLAN priority
Приоритет сети VLAN
8
MPLS label
Метка протокола MPLS
9
MPLS traficclass
Класс трафика протокола MPLS
10
IPv4 src
IP адрес источника
11
IPv4 dst
IP адрес получателя
12
IPv4 ToSbits
Приоритет пакета
14
TCP/ UDP / SCTP src port
Номер
порта
протокола
TCP/UDP/SCTP источника пакета
15
ICMP Type
Тип протокола ICMP
16
TCP/ UDP / SCTP dst port
Номер
порта
протокола
TCP/UDP/SCTP получателя пакета
17
ICMP Code
Код протокола ICMP
Если коммутатор поддерживает технологию битовых масок в полях
«Ethersrc», «Etherdst», «IPv4 src», «IPv4 dst», такие маски позволяют более
точно указать совпадения. В дополнение к заголовку пакета, совпадения могут
также быть выполнены в отношении входящего интерфейса и поля метаданных.
Метаданные могут быть использованы для передачи информации между
таблицами в коммутаторе.
33
3.2 Пути анализа потоков трафика для формирования таблиц
потоков OpenFlow
В общем случае сети передачи данных практически невозможно построить
таким образом, чтобы отследить и зафиксировать каждый пакет, переданный
узлом сети [26]. Для этого необходимы специализированные технические
решения и дорогостоящее высокопроизводительное оборудование, дополненное
мощным вычислительным центром и вместительным хранилищем результатов.
Также, довольно проблематично разделить трафик на отдельные логические
сессии, например, выделить сессию работы конкретного пользователя с
конкретным ресурсом.
Если сеть построена с уменьшенной структуризацией, то есть основная
часть сети расположена в зоне около четырех-пяти подсетей, то данные
маршрутизаторов будут полезны только для анализа трафика между подсетями.
Тогда как при такой логической топологии трафик, скорее всего, будет
распределен по правилу 80/20, то есть 80 процентов внутри сегмента, и только 20
процентов наружу сегмента. Таких сетей в области малых и средних организаций
подавляющее большинство.
В этом случае основной инструмент для сбора статистики – SNMP счетчики
коммутаторов сегмента. Если сеть построена на оборудовании нескольких фирм
(в большинстве случаев), видов счетчиков два: количество пакетов в секунду за
период наблюдения на интерфейсе (кол-во / с) и количество байт (бит) в секунду
за период наблюдения на интерфейсе (bandwith). С помощью этих двух счетчиков
невозможно построить реальную картину прохождения трафика по сети, однако,
можно построить модель сети, которая будет хотя бы повторять объемы потоков
через определенные порты коммутатора.
При применении метода двумерной диффузионной аппроксимации в
качестве метода моделирования системы массового обслуживания каждый
коммутатор можно представить в виде отдельной СМО с определенным внешним
трафиком. Так как большинство сетей строится на основе физической топологии
«расширенная звезда», сеть имеет древовидную структуру. Вследствие этого
внешний трафик коммутатора легко отследить на определенных портах.
Рассмотрим сеть, состоящую их четырех коммутаторов, соединенных по
схеме «звезда» в соответствии с рисунком Рисунок 3.2.
34
PC1
PC2
PC3
1234567 8
PC4
1234567
Коммутатор1
PC6
PC5
PC7
1234567
8
PC7
8
Коммутатор3
Коммутатор2
Internet
Server1
Server2
Server3
Рисунок 3.2– Пилотная сеть
При такой схеме можно однозначно определить, какими портами
коммутаторы связаны между собой. Исходящий трафик порта UpLink будет в
точности совпадать с входящим трафиком соответствующего порта коммутатора
следующего уровня, куда подключен искомый коммутатор.
Например, исходящий трафик порта восемь коммутатора один будет в
точности совпадать с входящим трафиком порта пять центрального коммутатора.
Обратные трафики также должны совпадать. Учитывая это, возможно заменить
сеть коммутаторов эквивалентным единым коммутатором с уже известными
связями внутри себя в соответствии с рисунком 3.3.
PC4
PC1
PC2
PC6
PC5
PC7
Коммутатор0
PC3
PC7
1
2
3
4
5
Коммутатор1
6
7
8
9 10 11 12 13 14 15
16
17 18 19 20 21 22 23
Коммутатор2
Коммутатор3
25 26 27 28 29 30 31
24
Internet
Server3
Server2
Server1
Рисунок 3.3– Схема трафика точка-точка
35
Если трафик идет от компьютера PC1 на сервер Server1, то при отсутствии
посторонних трафиков выборки, входящий и исходящий трафик будут совпадать
в той или иной мере, в зависимости от задержек. Оценить степень совпадения
можно, рассчитав коэффициент корреляции между входящим трафиком порта
один нового виртуального коммутатора и исходящим трафиком порта 26. При
этом поток затронет порты восемь и 26, так как они связаны кабелем напрямую,
но, учитывая это, при поиске ушедшего трафика они не используются.
Как только будет найден исходящий порт с наивысшим значимым
коэффициентом корреляции, принимается решение о соответствующей
вероятности попадания исследуемого трафика в этот порт. Все остальные порты,
на которых коэффициенты корреляции выше 0,3 также участвуют в расчете
вероятностей. После расчета все вероятности необходимо нормализовать, чтобы
их сумма равнялась единице.
Если сеть большая, потоки пересекаются в достаточно большом числе мест,
мультиплексируются в буферах коммутатора и теряют свою индивидуальность. В
этих условиях необходимо разбивать интервал наблюдения на зоны и искать
зависимости нетипичного пикового трафика узла.
Например, возьмем два графика трафиков на портах один и 26 в
соответствии с рисунком 3.4.
Рисунок 3.4– График входящего трафика первого порта и исходящего 26
порта
Коэффициент корреляции равен 0.437, то есть весьма низок. К тому же на
других портах наблюдаются большие шумы, которые тоже отразились на
остальных коэффициентах корреляции в соответствии с рисунком3.
 0.596 0.118 0.437
xrr   0.089 0.889 0.188


 0.357 0.280 0.992
Рисунок 3.5– Матрица корреляции для портов один, 25 и 26.
36
Корреляция для элемента xrri,j определяется как корреляция входящего
трафика i-ого элемента и исходящего трафика j-ого элемента. По диагонали –
корреляция входящего и исходящего трафиков для одного порта. Она обычно
очень высока вследствие пропорциональности работы протокола TCP. В
соответствии с рисунком 3.6 показаны графики для портов восемь и 26.
Рисунок 3.6– График на портах восемь и 26
При разбиении на интервалы для создания временных срезов (по 100, 200
секунд) наблюдается неравномерность в коэффициентах корреляции потоков на
порты в зависимости от номера интервала, что говорит об изменениях в
маршрутной матрице во времени. Возьмем один из срезов активного поведения
трафика – от 1100 с до 1200 с в соответствии с рисунком 3.7 коэффициент
корреляции входящего трафика первого порта и исходящего порта 26 равен 0,918.
 0.980 0.369 0.918
xrr   0.270 0.966 0.336


 0.857 0.442 0.997
Рисунок 3.7– Матрица корреляции для портов один, 25, 26
Следовательно, в этот срез времени можно найти источник этого скачка с
высокой вероятностью. Главное, таким образом можно определить, что в данный
порт этот скачок трафика не пришел. По пути от обратного можно также найти
порт с таким же скачком. Если такого скачка не наблюдается на других портах,
значит, это был мгновенный распределенный запрос с нескольких машин, и
отследить его практически невозможно. Такие моменты, как кратковременный
скачок трафика, являются нестационарным поведением сети, и статистическими
методами построить в таких режимах маршрутную матрицу не представляется
возможным.
После отсева незначимых коэффициентов, а также приравнивания к нулю
элементов главной диагонали (коммутатор никогда не пошлет пакет в тот
интерфейс, откуда он пришел), получаем следующую матрицу корреляции для
интервала 1100 с – 1200 с в соответствии с рисунком 3.8.
37
 0.000 0.369 0.918
p1   0.000 0.000 0.336


 0.857 0.442 0.000
Рисунок 3.8– Матрица корреляции для портов один, 25, 26 после удаления
незначимых и недостоверных результатов
Ненулевые элементы матрицы на пересечении i столбца и j строки
означают, что существует вероятность того, что трафик был передан с i на j порт
коммутатора.
Поскольку таблицы действий OpenFlow в общем случае эквивалентны
маршрутной матрице, предлагается использовать предварительное моделирование
и анализ потоков на реальной сети для составления оптимальных путей
следования трафика и определения расчетных характеристик каналов связи.
Протокол OpenFlow использует таблицы поиска в современных Ethernet
коммутаторах и маршрутизаторах. Эти таблицы потока, выполненные в
строчной развертке, которые реализуют брандмауэры, NAT, QoS или в срезах
статистических данных, варьирующиеся между различными поставщиками.
OpenFlow идентифицирует общие наборы функций, которые поддерживаются
большинством коммутаторов и маршрутизаторов. Для всех сетевых устройств
независимо от их спецификации можно использовать идентификацию как
единый набор функций и стандартный способ управления таблицами потока.
Каждая таблица OpenFlow может формироваться на основе анализа временных
срезов сетевого трафика или на основе статистических данных о трафике,
однако пока нет эффективных путей формирования таблиц при динамически
изменяющейся сети в условиях виртуализации центров обработки данных.
OpenFlow также может использоваться в корпоративных сетях, где
изоляция исследуемого трафика является основной задачей. Потоки создаются
и сохраняются централизованной архитектурой, названной контроллером.
3.3
Анализ трафика конвергентных сетей
При анализе сложных сетевых структур в большинстве случаев применяют
классический подход с использованием пуассоновских потоков заявок и
экспоненциальное распределение времени обработки заявки [32]. Однако, в
большинстве случаев сложных высоконагруженных сетей такой подход дает лишь
очень приближенный результат. Поэтому для повышения адекватности модели
сети, уточнения входных характеристик для моделирования, необходимо четко
отделять различные классы потоков друг от друга [33]. Кроме того, делать это
необходимо с учетом постоянно изменяющегося характера трафика, его
периодичности, «часов пик».
Основной целью обеспечения высокого качества обслуживания
конвергентной сети является критичность голосового и видео трафика к любым
38
задержкам и требовательность к выделенной полосе пропускания. После
выявления требований к какому-либо сегменту сети (количество одновременных
вызовов, сетевые приложения, время отклика) необходимо проанализировать
возможности оборудования и существующую ситуацию. В ряде случаев это
приходится делать уже на существующем сегменте сети. Чтобы выявить основные
тенденции трафика, его пики, пики конкретных приложений, возможности
конкретных типов трафика взаимодействовать с различными политиками и
типами QoS необходимо [34]:
а) разделить логические потоки, узел-узел и приложение-приложение;
б) определить вероятностные характеристики каждого логического потока
для последующего анализа;
в) определить суточные, часовые и иные циклы периодичности в поведении
трафика.
Самым важным здесь является определение вероятностных характеристик.
Без них невозможно проводить моделирование сегмента сети для получения
стресс-характеристик по каждому приложению и не будет возможности
предсказать параметры производительности, время отклика приложения и
стабильность этих параметров во времени.
Определение вероятностных характеристик реального трафика сталкивается
со многими проблемами. Любая методика тестирования существующей сети
существенно зависит от имеющихся в распоряжении системного администратора
технических и программных средств. В большинстве случаев для обнаружения
дефектов сети и анализа существующего трафика достаточным средством
является анализатор сетевых протоколов.
Для выявления ошибок от канального уровня до уровня приложения
измерения необходимо проводить при одновременной генерации анализатором
протоколов собственного трафика. Генерация трафика позволяет выявить
имеющиеся недостатки и создает условия для их проявления. Генерация должна
быть управляемой по интенсивности и закону распределения.
Этот метод называется «стресс-тестирование» сети и позволяет довольно
быстро на реальном сегменте определить его предельные характеристики и
возможности. Данный подход является самым универсальным, потому как
используется метод планирования эксперимента на реальном оборудовании. Весь
эксперимент будет занимать несколько минут, после него будут определены все
основные параметры оборудования и каналов связи в требуемых режимах и с
требуемыми типами трафика.
После получения каким-либо образом суммарных данных о трафике в виде
отдельных заголовков пакетов, необходимо выделить отдельные потоки [35]
(клиент-сервер, приложение-приложение, АТС-АТС). Для планирования
активного эксперимента (стресс-тестирования или комбинации его с потоками
Netflow/SFlow [36]) необходимо знать вероятностные характеристики каждого из
потоков, и, в первую очередь, вид распределения. Если речь идет о внедрении
голосовых услуг или перевода связность АТС на VoIP поток [37], то голосового
трафика может и не быть в общем потоке. Тогда необходимо задать его вручную.
39
3.4
Методы обеспечения QoS в ПКС
Основа реализации качества обслуживания (QoS) базируется на контроле
входа и выхода пакета из устройства. Какая единица данных при этом
используется – поток или пакет – не имеет значения, реализации QoS сводится
к определению приоритетов конкретных пакетов. Контроль над прохождением
пакетов через сеть доступен только в пределах центра обработки данных
(ЦОД), за пределами ЦОД вся ответственность ложится на провайдеров
телекоммуникационных услуг.
Кроме того, QoS предназначен для решения связанных с сетью вопросов,
таких как перегрузка каналов и потеря пакетов, которые в конечном итоге
приводят к снижению производительности приложений. Перегрузка каналов и
потери пакетов могут произойти по ряду причин, например, превышение
максимальной пропускной способности, высокий коэффициент загрузки (это
делает их неспособными к эффективной обработке входящих пакетов [38, 39]),
а также при неправильной конфигурации сетевых устройств.
Некоторые типы QoS, например, ограничение полосы пропускания, могут
помочь в решении проблемных ситуаций. Управление полосой пропускания
может уменьшить проблемы, связанные с ограниченной пропускной
способностью каналов связи, но только каналов между ЦОД и Интернет. Если
пропускная способность ограничена на другом конце канала («последняя миля»
провайдера), этот метод не улучшит производительность, так как контроллер
OpenFlow не имеет сведений об этих ограничениях. OpenFlow контроллер
будет применять правила вслепую по отношению к трафику за пределами
центра обработки данных.
Вне контекста приложений QoS редко дает заметное улучшение в
производительности с точки зрения конечного пользователя. Контекст является
необходимым для того, чтобы применять правильные методы и политику в
нужное время, чтобы обеспечить оптимальную производительность для
пользователей конкретного приложения.
Большинство коммутаторов и маршрутизаторов сегодня поставляются с
некоторой встроенной поддержкой QoS. Некоторые продукты поддерживают
только тип DiffServ (RFC-2474 и RFC-2475, небольшое количество очередей и
политик), другие поддерживают тысячи очередей и большое количество
политик. На практике при реализации QoS в сетях с коммутацией потоков
поток отображается на класс трафика QoS, то есть поток получает
идентификатор уже имеющегося класса.
В настоящее время существует два основных типа QoS услуг: ограничение
скорости на входе и гарантирование минимальной пропускной способности на
выходе. Первая обычно делается на основе измерений скорости входного порта
или потока, после превышения определенной скорости пакеты отбрасываются в
соответствии с некоторым алгоритмом [40]. Ограничение минимальной
гарантированной полосы пропускания означает, что каждому потоку будет
доступна определенная часть от имеющейся пропускной способности. По
40
умолчанию восемь очередей на физическом порту имеют следующие
минимально-гарантированные полосы пропускания от целого канала:
а) первая очередь (lowp riority): 2%;
б) вторая очередь (low priority): 3%;
в) третья очередь (normal priority): 30%;
г) четвертая очередь (normal priority): 10%;
д) пятая очередь (medium priority): 10%;
е) шестая очередь (medium priority): 10%;
ж) седьмая очередь (high priority): 15%;
и) восьмая очередь (high priority): 20%.
Спецификация OpenFlow 1.0.0 предусматривает поддержку ограниченного
функционала в области QoS. На каждый порт можно подключить одну или
несколько очередей. Каждый поток ассоциируется с конкретной очередью.
Обработка в очереди происходит в соответствии с настройкой конкретной
очереди. По умолчанию все очереди имеют настройку на предоставление
минимальной гарантированной пропускной способности, другие типы очередей
не поддерживаются текущей версией OpenFlow.
Для обеспечения QoS в свойствах конкретного потока существует поле IP
ToS, в нем содержится шести битный DSCP идентификатор, Input VLAN
Priority для приоритезации одного VLAN над другим. Для обработки потока
существуют следующие действия:
а) OFPAT_SET_VLAN_PCP устанавливает приоритет VLAN 802.1q;
б) OFPAT_SET_NW_TOS устанавливает новое значение DSCP потоку;
в) OFPAT_SET_QUEUE устанавливает новый идентификатор очереди для
данного потока, другими словами ассоциирует конкретный поток с очередью
вне зависимости от DSCP и VLAN Priority.
Для настройки самих очередей QoS, необходимы особые команды, не
относящиеся к OpenFlow. Очереди настраиваются средствами операционной
системы коммутатора (через специальные команды или посредством внешних
утилит). OpenFlow-контроллер может только запросить информацию об
очередях на конкретном порту: количество очередей, их тип, количество
пакетов в очереди. Также можно запросить статистику по всем очередям
коммутатора: переданные пакеты, переданные байты, количество переполнений
очереди. Каждая очередь имеет определенный размер в байтах и тип – простая
FIFO очередь или с ограничением по гарантированной полосе пропускания.
Для второго типа очереди настраивается гарантированная полоса пропускания
в процентах (одна единица измерения равна 0.1 процента) от максимально
доступной полосы пропускания порта коммутатора.
Таким образом, существует два шага для работы с QoS в OpenFlow –
настройка очередей на коммутаторах с привязкой к портам или без нее и
связывание конкретных потоков.
Существует альтернативный метод обеспечения QoS – перенаправить
обработку пакетов конкретного потока на операционную систему коммутатора,
и тот обработает их классическими методами. Это возможно только на
41
коммутаторах c одновременной поддержкой OpenFlow обработки пакетов и
обычной обработки пакетов.
Однако базовая концепция QoS предполагает, что все пакеты всегда идут
по одному направлению в течение довольно длительного времени, если
топология сети статична, а путь между двумя точками детерминирован. Сети
OpenFlow не позволяют применять сложные механизмы QoS именно из-за
недетерминированности топологии и путей следования пакетов. К тому же
очень часто при глубокой интеграции виртуализированных ресурсов в ЦОД
требования к обеспечению требуемых показателей работы сети кардинально
меняются в процессе работы для разных виртуальных сетей.
В связи с описанными ограничениями реализации QoS предлагается
использовать первый подход к реализации – настройка очередей на
коммутаторах и сопоставление битов QoS и конкретных потоков на
контроллере. Затем всю обработку QoS наиболее рационально перенести на
операционную систему коммутатора в соответствии с битами QoS, что
позволит максимально использовать все преимущества дополнительных
возможностей очередей коммутаторов.
Для корректной настройки параметров QoS необходима точная
информация о трафике в сети. В протокол OpenFlow встроена возможность
анализа проходящего трафика средствами измерений. Все измерения
записываются в таблицу измерений, которая состоит из записей измерений,
определяющих измерения для каждого потока. Измерения для каждого потока
позволяют OpenFlow реализовывать различные простые операции QoS, такие
как ограничение скорости, и могут быть объединены с очередями каждого
порта для реализации сложных структур QoS, таких как DiffServ или для
последующего анализа.
Контроллер может уведомить коммутатор о различных типах обработки
очередей:
а) удаление (отбрасывание) пакета. Этот тип обработки может быть
использован для определения диапазона ограничения скорости.
б) изменение DSCP. Этот тип позволяет уменьшать приоритет DSCP в IPзаголовке пакета. Используется для определения простого ограничителя
DiffServ.
Для управления произвольным коммутатором OpenFlow любого
производителя существует linux-утилита dpctl, позволяющая добавлять,
удалять, просматривать данные о потоках, очередях, счетчиках. Для реализации
QoS на уровне OpenFlow (программном уровне) необходимо создать очередь и
настроить ее параметры. Так как очередь в OpenFlow может быть только с
политикой WFQ [40 ] (Weighted Fair Queue, взвешенная справедливая
очередь) с нижней границей скорости потока, команда для настройки очереди
для третьего приоритета на втором порту коммутатора IP=10.1.1.1 для
минимальной гарантированной скорости 1000 Кбит/с будет выглядеть
следующим образом:
#dpctlmod-queuetcp:10.1.1.1:6633 3 2 1000
42
Для классификации конкретного потока можно использовать как уже ранее
присвоенный ToS/DSCP, так и присвоить эти параметры непосредственно
OpenFlow препроцессором или просто перенаправить в нужную очередь
(локальная классификация). Правило для приоритезации (ассоциации с третьей
очередью) пакета от 10.0.0.2 к 10.0.0.3 выглядит следующим образом:
#dpctl add-flow tcp:10.1.1.1:6633 "ip, nw_dst=10.0.0.3, nw_src=10.0.0.2,
action=mod_vlan_pcp:3, output:23"
где mod_vlan_pcp задает приоритет пакета (номер очереди) при обработке.
При необходимости изменить ToS можно использовать параметр
mod_nw_tos:<tos>;
output задает номер исходящего порта (коммутация).
Минимальная гарантированная скорость на порту задается при
дополнительной настройке физической очереди. Просто перенаправить пакет в
физическую очередь №3 порта 23 коммутатора можно командой:
#dpctl add-flow tcp:10.1.1.1:6633 "ip, nw_dst=10.0.0.3,nw_src=10.0.0.2,
action=enqueue:23:3, output:23"
где enqueue - номер очереди конкретного порта. Параметр enqueue
поддерживается не всеми коммутаторами.
Для создания ограничения сверху конкретного потока используется
следующая запись другой утилиты, входящей в состав продукта OpenvSwitch:
# ovs-ofctl add-limiter tcp:10.1.1.1:975 123 drop 512 kbps
где 123 – номер ограничителя;
drop – реакция на превышение лимита;
512 kbps – размер виртуального канала.
После создания ограничителя необходимо связать конкретный трафик с
ним:
#ovs-ofctl add-flow tcp:10.1.1.1:975 "priority=32769,idle_timeout=0,ip,
nw_dst=10.0.0.3,nw_src=10.0.0.2, action=rate_limit:123,output:23"
где rate_limit - номер ограничителя.
Как видно из приведенных примеров, настройка QoS для большой сети с
множеством потоков и динамической топологией является сложной и
нетривиальной задачей, к тому же ограниченной ручным созданием и
настройкой очередей.
В больших сетях нет возможности контроллеру управлять выделением
ресурсов каждому потоку трафика и применять QoS на конкретный поток
данных. Коммутаторы имеют ограничение на количество записей в таблице
OpenFlow, поэтому целесообразно использовать группировку (агрегацию)
нескольких потоков в единую логическую группу и управление выделением
ресурсов на эту группу. Большинство QoS политик классификации работают
именно по этому принципу. В OpenFlow существуют понятия aggregative VLAN
и aggregativeflow, которые позволяют применять правила агрегации на уровне
коммутатора и контроллера, не теряя при этом данные отдельного потока.
Контроллер должен постоянно проводить мониторинг всей сети с целью
обеспечения глобального управления ресурсами. Например, все коммутаторы
могут пересылать LLDP, DHCP, ARP пакеты на контроллер, который всегда
43
будет иметь у себя полную актуальную топологию сети со всеми связями и
конечными устройствами. При необходимости, контроллер может рассчитать
места внедрения или удаления политик QoS, заново рассчитывать оптимальные
маршруты с учетом применения QoS и требований приложений.
Кроме того, предлагается регулярно делать копию таблиц OpenFlow с
коммутаторов и проводить их анализ для выявления несоответствий.
Дополнительно во многих коммутаторах предоставляется возможность запроса
QoS конфигурации.
Для обеспечения функции глобального управления производительностью
и качеством обслуживания сети необходима единая модель, в которой будет
учитываться топология, полоса пропускания и настройки QoS для каждого
потока.
Предлагаемая модель применения политик QoS должна основываться на
базовых возможностях коммутаторов в области качества обслуживания –
ограничителях скорости и статических очередях с приоритетами. Ограничитель
скорости в OpenFlow коммутаторах реализован с некоторыми отличиями от
RSCP в обычных коммутаторах.
Введем следующие обозначения: f0 – поток данных, rf0 – требуемая
пропускная способность, df0 – допустимая задержка. Для обеспечения потоку f0
требуемой скорости rf0 необходимо вычислить остаточную пропускную
способность arf как разность максимально доступной пропускной способности
C и суммы текущих (пиковых) скоростей остальных потоков sum fi (С-∑  )..
Затем проводится сравнение, не превышает ли rf0 остаточной полосы
пропускания arf.
Данное ограничение вставляется на коммутаторе, куда впервые попадает
искомый поток данных. Делается это с той целью, чтобы ограничить влияние
потока на сеть. Однако при глобальном управлении сетью минимизация
задержек на протяжении всей сети представляет собой проблему. В
большинстве OpenFlow коммутаторов на каждый физический порт приходится
восемь очередей. Очередь с номером восемь – самая низкоприоритетная.
Предположим, что на одну из очередей (q8) порта восемь ассоциированы
шесть потоков f1-f6 с произвольными приоритетами (у f1-f3 приоритет q=6, у f4-f6
q=4). Добавляется еще один поток f0, который ассоциируется с очередью q5 с
приоритетом пять. Задержка потока f0 – df0 – зависит от того насколько быстро
прибывают пакеты в очередях с такими же или более высокими приоритетами и
от того, насколько быстро канал сможет отправить пакеты. Затребованная
пропускная Rq:8 способность порта определяется как сумма всех пропускных
способностей rfi, i=q..8.
Простая задача вычисления df0 определяется как зависимость f (q5, R5:8,C8),
где q-приоритет очереди ассоциированной с потоком f0 (q5=5), Rq:8 – сумма
пиковых пропускных способностей rf5...rf8 для всех очередей с приоритетом
пять и выше.
Каждый коммутатор на пути следования пакета добавляет свой вклад в
задержку. Более приоритетные потоки прибавляют задержки менее
приоритетным потокам (f4-f6 прибавляют задержку потоками f1-f3). При
44
добавлении f0 потокам f1-f3 задержка еще больше увеличивается. На следующем
по пути коммутаторе контроллер может не найти место в очереди для потока f0,
если другой похожий поток с тем же или более высоким приоритетом на том же
физическом порту уже подходит к верхнему пределу максимальной задержки.
Контроллер должен учитывать взаимодействие потоков, проходящих по
одному пути и будущее взаимодействие потоков на следующих по пути
коммутаторах для решения задачи ассоциации потока с очередью.
Оптимальное распределение потоков по очередям и назначение им
приоритетов является сложной вычислительной задачей. Расчет этих
параметров в соответствии с требованиями по задержкам потока f0 не должен
нарушать требования к остальным потокам. Кроме того, необходимо
уменьшать время установки новых потоков в таблицу коммутатора.
Данная технология предназначена для максимизации обеспечения
требований по производительности новых потоков при минимизации
количества отклоненных потоков.
По всему пути следования потока f0 на каждом исходящем порту
ассоциируется очередь. Путь следования и очереди выбираются по
минимальной вероятности потери потока. Очередь назначается в соответствии
с выбранным приоритетом на конкретном порту. Если приоритет будет
установлен в максимум, поток будет иметь наименьшую задержку, но
наибольшее влияние на остальные потоки и наоборот.
На каждом порту необходимо вычислить наивысший возможный
приоритет для потока f0, при котором еще возможно минимальное влияние на
остальные потоки, и минимально возможный приоритет, при котором в
текущей ситуации возможно выполнить требования по производительности
потока f0. Диапазон приоритетов от меньшего к большему назовем lowf0...hif0.
Для каждого значения приоритета можно вычислить значение задержки в
текущих условиях для текущих уровней загрузок портов и потоков. Затем
проводится серия расчетов для решения задачи минимизации ∑ (q, Rq:8,
C)min при qmin для каждого порта следования потока каждого
коммутатора и диапазона  = 0 ∙∙∙ ℎ0 . Особенностью является обратно
пропорциональная нелинейная зависимость задержки Df от приоритета q
После расчета вариантов прямого трафика необходимо рассчитать еще и
обратный трафик (ответный трафик).
Особенностью такого подхода является возможность динамической
ассоциации приоритета потока на порт коммутатора в условиях постоянно
меняющегося трафика. Структурная схема взаимодействия модуля прототипа
обеспечения QoS с СОС и обязательными компонентами системы показана на
рисунке 3.9.
45
Web-интерфейс
работы с БД
django
Объектная
модель
ORM django
СУБД
sqlite3
Объектный
интерфейс СУБД
ORM django
Система сбора
статистики
MRTG
Коммутатор
Модуль Nox
snmp
Модуль
(прототип) QoS
Модуль Nox
pyswitch
Модуль NOX
networking
Модуль Nox
topology
Модуль NOX
core
Рисунок 3.9 – Структурная схема взаимодействия компонентов системы
Управление модулем обеспечения QoS осуществляется через Вебинтерфейс, предоставляемый стандартными средствами Веб-приложений
платформы Django. Через Веб-интерфейс возможно добавление, изменение и
просмотр сведений о потоках, для которых будет гарантированы параметры
QoS. Модуль обеспечения QoS регулярно выполняет проверку изменений в БД
и вносит изменения в таблицу потоков OpenFlow для заданных потоков
данных. Контроллер NOX с подключенными модулями snmp, topology
выполняет свои обычные функции, модуль pyswitch имеет дополнение в виде
вызова модуля обеспечения QoS при добавлении нового потока в коммутатор.
Система сбора статистики MRTG по протоколу SNMP собирает статистику с
коммутаторов (загрузку портов, размеры очередей), через интерфейс модуля
NOXsnmp эти сведения заносятся в систему и используются модулем
обеспечения QoS для расчета параметров потоков.
Как уже отмечалось ранее, существует два действия для обеспечения QoS
в OpenFlow –настройка очередей на коммутаторах и связывание конкретных
потоков. Существует альтернативный метод обеспечения QoS– передача
обязанностей по обработке пакетов конкретного потока операционной системе
коммутатора. Это возможно только на коммутаторах, поддерживающих как
традиционную обработку пакетов, так и обработку с помощью OpenFlow в
соответствии с рисунком 3.10.
46
Обеспечение QoS
Другие политики QoS
Правило 1 - Перевод всех
пакетов в операционную
систему коммутатора
Минимальная
пропускная способность
для потока
Настройка очередей на
каждом коммутаторе
Ассоциирование
очередей с портами
Правило 1
Ассоциирование
потока
с
очередью
Команда NORMAL
Обработка обычными
средствами
коммутатора
Правило 2
Ассоциирование
потока
с
очередью
Правило 3
Перевод обработки
операционную
коммутатора
Команда FLOOD
Обработка
обычными
средствами
коммутатора,
рассылка на все доступные
порты
потока в
систему
Рисунок 3.10 – Схема обеспечения QoS в OpenFlow коммутаторе
Однако базовая концепция QoS предполагает, что все пакеты всегда идут
по одному направлению в течение довольно длительного времени, топология
сети статична, путь между двумя точками детерминирован. Сети OpenFlow не
позволяют
применять
сложные
механизмы
QoS
именно
из-за
недетерминированности топологии и путей следования пакетов. К тому же, как
правило, при глубокой интеграции виртуализированных ресурсов в ЦОД
требования к обеспечению требуемых показателей работы сети меняются в
процессе работы кардинально для разных виртуальных сетей.
В связи с описанными ограничениями реализации QoS предлагается
использовать первый подход к реализации – настройка очередей на
коммутаторах и сопоставление битов QoS и конкретных потоков на
контроллере. Затем всю обработку QoS наиболее рационально перенести на
операционную систему коммутатора в соответствии с битами QoS, что
позволит максимально использовать все преимущества дополнительных
возможностей очередей коммутаторов.
47
3.5
Получение статистической информации о трафике в OpenFlow
сетях
Для корректной настройки параметров QoS необходима точная
информация о потоках трафика в сети. В протокол OpenFlow встроена
возможность анализа проходящего трафика средствами измерений. Все
измерения записываются в таблицу измерений, которая состоит из записей
измерений, определяющих измерения для каждого потока. Измерения для
каждого потока позволяют OpenFlow реализовывать различные простые
операции QoS, такие как ограничение скорости, и могут быть объединены с
очередями каждого порта для реализации сложных алгоритмов QoS, таких как
DiffServ или для последующего анализа.
Измеритель (meter) оценивает скорость пакетов, назначенных ему, и
позволяет управлять скоростью этих пакетов. Измерители присоединяются
непосредственно к записи потока (в отличие от очередей, которые прилагаются
к портам). Любая запись потока может указать измерение в наборе инструкций,
измеритель оценивает и управляет скоростью совокупности всех записей
потоков, к которым он прикреплен. В одной таблице может использоваться
несколько измерителей, но особым способом (непересекающиеся множества
потоков записей). Несколько измерителей может быть использовано в том же
наборе пакетов, путем использования их в последовательных таблицах потока.
Каждая запись измерений определяется идентификатором измерений и
содержит:
а) идентификатор измерений: 32-битное беззнаковое целое число,
однозначно определяющее измерение;
б) диапазоны измерений: неупорядоченный список диапазонов
измерений, где каждый диапазон измерений определяет скорость диапазона и
способ обработки пакетов;
в) счетчики: обновляются, когда пакет обрабатывается измерителем.
Каждое измерение может иметь один или несколько диапазонов. Каждый
диапазон определяет скорость, при которой он действует, и способ обработки
пакетов. Пакет обрабатывается в одном диапазоне измерений на основе
текущей скорости, определенной измерителем; измеритель применяет
диапазон, наименьшая указанная скорость которого ниже, чем текущая
измеренная скорость. Если текущая скорость ниже, чем скорость, указанная для
любого диапазона, то не используется никакой диапазон.
Каждый диапазон измерений определяется своей скоростью и содержит:
а) тип диапазона: определяет, как обрабатывается пакет;
б) скорость: используется измерителем для выбора диапазона измерений,
определяет минимальную скорость, при которой диапазон может
использоваться;
в) тип конкретных аргументов: некоторые диапазоны могу иметь
дополнительные аргументы.
48
В спецификации отсутствует тип диапазона «Обязательный». Контроллер
может запросить коммутатор, какие дополнительные
типы диапазонов
измерения поддерживаются:
а) удалить (отбросить) пакет. Может быть использован для определения
скорости диапазона ограничения скорости
б) DSCP-примечание. Уменьшить приоритет отбрасывания DSCP-полей
в IP-заголовке пакета. Может использоваться для определения простого
ограничителя DiffServ.
Счетчики могут поддерживаться для каждой таблицы, записи, порта,
очереди, группы, измерения или диапазона измерений. OpenFlow-совместимые
счетчикимогут быть реализованы в программном обеспечении и
поддерживаются путем опроса аппаратных счетчиков с более ограниченным
диапазоном. Таблица 3.2 содержит набор счетчиков, определяемых
спецификацией OpenFlow. Коммутатор не требует поддержки всех счетчиков, а
только тех, что указаны в таблице.
Таблица 3.2– Список счетчиков
Наименование измеряемого параметра
В таблице потоков
Количество ссылок (активных записей)
Поиск пакетов
Соответствие пакетов
В записи потоков
Полученные пакеты
Полученные байты
Продолжительность (секунд)
Продолжительность (наносекунд)
В портах
Полученные пакеты
Переданные пакеты
Полученные байты
Переданные байты
Потери приема
Потери передачи
Ошибки приема
Ошибки передачи
Ошибки выравнивания полученных пакетов
Полученные ошибки переполнения
Полученные ошибки целостности
Коллизии
49
Размер поля
(биты)
32
64
64
64
64
32
32
64
64
64
64
64
64
64
64
64
64
64
64
Продолжение таблицы 3.2
Наименование измеряемого параметра
Продолжительность (секунд)
Продолжительность (наносекунд)
В очередях
Переданные пакеты
Переданные байты
Переданные ошибки переполнения
Продолжительность (секунд)
Продолжительность (наносекунд)
В группах
Количество ссылок (записи потока)
Количество пакетов
Количество байт
Продолжительность (секунд)
Продолжительность (наносекунд)
В наборе групп
Количество пакетов
Количество байт
В измерениях
Количество потоков
Количество входящих пакетов
Количество входящий байт
Продолжительность (секунд)
Продолжительность (наносекунд)
В диапазонах измерений
Количество пакетов в диапазоне
Количество байт в диапазоне
Размер поля
32 (биты)
32
64
64
64
32
32
32
64
64
32
32
64
64
32
64
64
32
32
64
64
Длительность обозначает количество времени, когда запись, группа,
очередь или измерение были установлены в коммутаторе, и должна
отслеживаться с точностью до секунды. Поле «полученные ошибки» – это
сумма всех полученных ошибок и коллизий, определенных в таблице, а так же
любых других, не попавших в таблицу.Счетчики зацикливаются без
переполнения индикатора. Если конкретный числовой счетчик не доступен в
коммутаторе, его значение должно быть установлено как максимальное
значение поля (беззнаковый эквивалент минус 1).
При использовании OpenFlow в высоконагруженных сетях с
мультимедийным трафиком актуальна проблема обеспечения качества
обслуживания на выделенные потоки трафика. Реализация QoS в OpenFlow
позволяет использовать простые очереди с приоритетами как в разных потоках,
так и внутри одного потока данных. В текущих версиях реализации OpenFlow в
коммутаторах нет возможности динамически настраивать сами очереди, есть
50
возможность настраивать классы трафика, динамическую приоритезацию
потоков.
3.6 Алгоритм сбора статистикиOpenFlow
Любой коммутатор с поддержкой OpenFlow обеспечивает работу как SNMP
протокола, так и OpenFlowOF_STAT таблиц со статистикой потоков. Кроме того,
большинство коммутаторов поддерживают работу локального контроллера,
отвечающего на запросы сетевого контроллера.
Стандартные средства локального контроллера позволяют получать
следующие сведения:
а) полную таблицу потоков;
б) список всех таблиц;
в) список портов;
г) статистику портов;
д) состояние портов;
е) скорость портов.
Средства SNMP позволяют получать сведения обо всех компонентах
аппаратного и программного обеспечения коммутатора. Основные сведения,
которые необходимы для точной маршрутизации и управления сетью следующие:
а) количество пакетов,прошедших через порт;
б) количество байтов, переданных через порт;
в) средняя скорость в пакетах/с;
г) средняя скорость в байтах/с;
д) загрузка процессора и памяти коммутатора;
е) длины очередей портов.
Имея данные о среднем количестве пакетов в секунду за период времени (на
входе и выходе интерфейса) и объем трафика за тот же период легко перейти к
необходимой в моделировании величины среднего периода времени между
пакетами (и его дисперсии). Для этого от среднего количества пакетов N
переходим к длине интервала времени между пакетами  для каждого временного
среза.
t
(3.1)

N,
где t - время наблюдения.
Дисперсия вычисляется аналогичным образом:
3
D  D N 
t .
(3.2)
Таким образом, получаем математическое ожидание и дисперсию
распределения времени между пакетами отдельно на входе и выходе интерфейса.
51
Остается открытым вопрос о согласовании результатов, полученных из
разных источников. Протокол SNMP дает более достоверную информацию,
однако не все показатели работы программного обеспечения доступны через него.
Статистика, касающаяся количества байт на поток, например, по заявению
производителей, может отличаться от реальности до 20%. Тогда как количество
пакетов на поток рассчитывается точно.
Очень часто, в пик нагрузки, многие коммутаторы не справляются с
расчетами, и результаты оказываются резко завышенными. Такие результаты
резко выделяются на фоне общей информации на порядок. В борьбе с грубыми
погрешностями измерений, если они не были обнаружены в процессе измерений,
используют три подхода:
а) исключение резко выделяющихся аномальных измерений из
дальнейшей обработки;
б) использование робастных методов обработки;
в) группирование выборки позволяет резко снизить влияние аномальных
наблюдений, а иногда и практически исключить влияние грубых ошибок
измерений.
Все программы для сбора информации по SNMP могут хранить ее в БД,
однако, учитывая большой объем данных, это не всегда целесообразно.
Наилучшим решением является хранить данные в формате RRD
(RoundRobinDatabase, кольцевая база данных), обеспечивающим хранения
данных за большие периоды времени не требующего для этого большого
объема памяти. Поддержку RRD имеют все промышленные программы для
сбора информации по SNMP. Проблемой в этом случае является синхронизация
сведений SNMP и Openflow счетчиков. В соответствии с рисунком 3.11
показаны пути поступления статистической информации в программные
модули.
БД RRD
Модуль с
использованием
статистики
Анализатор
MRTG
Анализатор
SNMP-агент
Контроллер
OpenFlow
SNMP счетчики
Коммутатор
OpenFlow счетчики
Рисунок 3.11 – Структурная схема движения информации
52
Второй особенность является обнуление некоторых счетчиков SNMP
после чтения из них, что предоставляет возможность иметь только текущие
сведения. В соответствии со всеми ограничениями и особенностями был
разработан алгоритм получения статистических данных из обоих источников и
формирования единого объекта со всеми сведениями. Алгоритм представлен в
соответствии с рисунком 3.12.
Начало
Файлы с данными SNMP
Адреса коммутаторов OpenFlow
Настройки
системы
Пиковые
данные
+
Запрос
данных по
SNMP
Выбираем из
настроек
системы имя
нужного файла
Выбираем из
настроек
системы адрес
коммутатора
Выбор нужного
периода времени
Выбор нужного
показателя
Посылка
запроса на
данные
Получение
списка
данных
Нормирование
данных
Формирование
объекта с
данными
Формирование
объекта с
данными
Получение
данных из
объекта
Использование
данных
Конец
Рисунок 3.12 – Алгоритм получения статистических данных
53
Данные из разных источников обрабатываются в соответствии со
спецификой источника, затем все они помещаются в соответствующие
поляединого объекта. Для получения данных из объекта необходимо знать тип
статистики (пиковая или накопительная), и свойство множественности
значений (единичное измерение или хранимая серия измерений).
В случае использования только одного канала статистики нет возможности
полностью прогнозировать поведения сети, строить модель сети и создавать
рекомендации другим модулям для оптимального использования ресурсов сети.
Особенно это касается статистических сведений о потоках, для которых важно
правильное назначение приоритета QoS, минимальной гарантированной
пропускной способности и сведений о загрузке портов и очередей.
Пакет программ OFLOPS используется для генерации пакетов по
заданному правилу, он же определяет факт реакции коммутатора посредством
перехвата пакетов канала управления. OFLOPS является платформой
тестирования OpenFlow коммутаторов и имеет множество измеряемых
параметров. Эта платформа разрабатывалась для измерений высокой точности,
и, при работе в системе реального времени, позволяет достичь существенного
уменьшение систематической погрешности. Платформа является модульной,
что позволяет измерять только те величины, которые требуются по условиям
эксперимента. Кроме того, по протоколу SNMP возможно регулярное снятие
статистики любого параметра работы коммутатора.
Использование частотомера и системы реального времени в АСНИ
позволяет обеспечить высокую точность измерений, а автоматизация
проведения исследований позволяет многократно повторять эксперименты в
одинаковых условиях, уменьшая погрешность измерений.
54
4
Cетевые операционные системы для ПКС
4.1
Обзор традиционных сетевых операционных систем
Сетевая операционная система в общем смысле – операционная система,
обеспечивающая обработку, хранение и передачу данных в информационной
сети. Сетевая операционная система определяет взаимосвязанную группу
протоколов верхних уровней, обеспечивающих основные функции сети:
адресацию объектов, функционирование служб, обеспечение безопасности
данных, управление сетью.
Иными словами, сетевая операционная система – операционная система,
в которуювстроены возможности для работы в компьютерных сетях. К ним
относятся:
а) поддержка различных сетевых протоколов модели ISO/OSI;
б) поддержка протоколов маршрутизации и сетевых протоколов
авторизации;
в) поддержка сетевого оборудования и фильтрации сетевого трафика;
г) поддержка доступа к удалённым ресурсам, например, принтерам,
системам хранения данных по сети, и наличие в системе сетевых служб,
позволяющих удалённым пользователям использовать ресурсы компьютера.
Примерами наиболее распространённых сетевых операционных систем
могут служить:
а) Различные UNIX-подобные системы, такие как Solaris, FreeBSD и
GNU/Linux;
б) Novell NetWare;
в) Microsoft Windows (95, NT, XP, Vista, Seven).
В общем смысле для сетевых операционных системможно выделить
следующие основные задачи: разделение ресурсов сети (например, дисковые
пространства сетевых устройств, принтера сети) и администрирование сети. А
системный администратор, при помощи сетевых функций сетевой ОС,
определяет общие ресурсы, назначает пароли и права доступа для каждого
пользователя или группы пользователей. В результате сетевые ОС можно
разделить на две группы: сетевые ОС для серверов и сетевые ОС для
пользователей.
Существуют специальные сетевые ОС, которым приданы функции
обычных систем (например, GNU/Linux с установленным графическим
пользовательским
интерфейсом)
и
обычные
ОС
(например,
MS Windows 98/XP/Vista/7), которым приданы сетевые функции. Сегодня
практически все современные ОС имеют встроенные сетевые функции.
Кроме того, в отдельный класс можно выделить сетевые операционные
системы, встраиваемые в специальные сетевые устройства (маршрутизаторы и
коммутаторы), такие как:
а)
JUNOS компании Juniper Networks;
б)
IOS компании Cisco Systems;
в)
ZyNOS компании ZyXEL;
55
г)
OpenWrt;
д)
FreeWRT.
Рассмотрим их более подробно:
а) JUNOS – сетевая операционная система, которая используется в
оборудовании производства компании Juniper Networks. Сетевая ОС JUNOS
разработана на основе 4-ой версии свободной ОС FreeBSD [42].
В JUNOS имеется возможность устанавливать дополнительное ПО,
которое распространяется в виде пакетов, подписанных действительным
сертификатом Juniper Networks.
Пользовательскаясреда представляет собой полноценную рабочую среду
с набором классических (для Unix-like ОС) утилит. Однако любые изменения в
конфигурации допускается
вносить только при помощи специальной
программы – «cli».
Командный интерфейс JUNOS разрешает исполнять команды и вводить
конфигурацию. Конфигурация состоит из директив конфигурирования той или
иной подсистемы. Директивы могут состоятьиз вложенных элементов, которые
описывают настройку отдельных компонент. Например, конфигурация
Ethernet-интерфейса может иметь вложенные настройки для отдельных
подсетей, которые, так же, могут иметь вложенные настройки для различных
версий протоколов (например, IPv4 и IPv6).
Узлы конфигурации, которыене содержат вложенных элементов,
заканчиваются точкой с запятой.Узлы с вложенными элементами задают их с
помощью фигурных скобок и при этом точка с запятой не ставится.
JUNOS предлагается в трех версиях, которые различаются лицензией:
1) JUNOSCanadaandU.S. –известнаятакже как «Domesticversion», не
предназначалась для экспорта в другие страны кроме Канады и США, но, в
текущий момент, в рамках контракта на техническую поддержку, эту версию
можно получить,обратившись в службу поддержки с дополнительному
запросу.При этом важным условием для использования является то, что
полученная копия не будет использована в странах из специального списка,
опубликованного госдепом США;
2) JUNOS Worldwide – распространяетсясовместно с оборудованием Juniper
Networks; лицензия этой версии позволяет использовать JUNOS в любой
стране, но имеет значительные ограничения на применение криптографических
алгоритмов (например, отсутствует поддержка SSH);
3) JUNOS-FIPS – версия, которая соответствует федеральным стандартам по
обработки информации в США.
б) Cisco IOS (Ciscointernetworkoperationsystem) – сетевая ОС,
применяемая в маршрутизаторах Cisco, и некоторых сетевых коммутаторах.
Cisco IOS – многозадачная сетевая операционная система, которая выполняет
функции сетевого коммутации, маршрутизации, управления и передачи данных
[43, 44].
Рабочая среда Cisco IOS также представляет собой интерфейс командной
строки CLI (Commandlineinterface). Интерфейс IOS имеет набор многословных
команд.Доступность команд определяется «режимом» и уровнем привилегий
56
данного пользователя. Режим «Global configuration mode» (режим глобальной
конфигурации) – предоставляет возможность для изменения системных
настроек и настроек сетевого интерфейса. У всех командимеется определённый
уровень привилегий от 0 до 15, и к ним могут обращаться только пользователи
с данным уровнем привилегий. Через интерфейс CLI можно определять
доступность команд для каждого уровня привилегий.
в) ZyNOS – это сетевая операционная система, являющаяся
собственностью корпорации ZyXEL. Она является платформой всех
маршрутизаторов этой корпорации, и обеспечивает сетевые сервисы и
приложения. Она построена модульным способом, поэтому разработчикам
легко добавлять в неё новые функции [45].
В зависимости от устройства ZyNOS имеет Web-интерфейс или
интерфейс командной строки. Доступ к Web-интерфейсу осуществляется путем
подключения сетевого кабеля между компьютером и свободным интерфейсом
на устройстве и введением IP-адреса устройства в строке адреса в веббраузере. На некоторых устройствах для доступа к интерфейсу командной
строки используется последовательный порт RS-232, подключение по которому
осуществляется с помощью протоколов удаленного доступа SSH или Telnet.
г) OpenWrt – сетевая операционная система, основанная на Linux, и
предназначенная, в основном, для домашних маршрутизаторов. Изначально
поддержка оборудования ограничивалась лишь серией LinksysWRT54G, но
сейчас увеличилась и включает в себя устройства и архитектуры других
производителей, в том числе и x86. Рабочая среда OpenWrt в основном
применяется интерфейс командной строки, но одной из возможностей
расширения функционала является веб-интерфейс [46].
Разработка OpenWrt стала возможной в связис применением
производителем программного обеспечения лицензии GNUGeneralPublicLicense
(GNUGPL), которая обязует разработчиков публиковать все производные
продукты под той же лицензией.
Главной отличительной чертойOpenWrt является полная поддержка
файловой системы JFFS2, что, в сою очередь, позволяет применять для
управления пакетами менеджер пакетов ipkg (в новых версиях opkg). Все эти
особенности делает OpenWrt легко адаптируемой и настраиваемойсетевой ОС
для каждого конкретного случая.
д) FreeWRT – дистрибутив [47] Linux для встраиваемых систем, таких как
беспроводные маршрутизаторы фирмы Linksys и Asus. Это версия проекта
OpenWrt. В отличие от OpenWrt, котораяпредназначена в основном для не
больших компаний и домашних пользователей, FreeWRT предназначена для
профессионального рынка. Эта достигается благодаря проверенному и более
стабильному коду, и постоянному циклу релиза. Поддержка FreeWRT более
доступна для разработчиков и для людей, которые заинтересованы в проекте.
Доступность осуществляется с помощью листов рассылки по электронной
почте, IRC-каналов, блогов и jabber-контактов.
FreeWRT применяетлибо JFFS (записываемую корневую файловую
систему) либо SquashFS как основу файловой системы, доступной только для
57
чтения в сочетании с частью файловой системы, доступной для записи.
ДополнительноеПО распространяется в виде пакетов, и может быть
установлено с помощью системы управления пакетами ipkg, похожей на dpkg.
FreeWRT поддерживает огромное количество периферийного оборудования
(такого как веб-камеры, принтеры, переносные винчестеры). Кроме того,
имеются большие возможности по использованию скриптовых языков, которые
в сочетании с доступным ПО обеспечивают работу большого числа сервисов
(сетевое хранилище, принт-сервер, сервер мультимедиа).
4.2 Сетевые
операционные
конфигурируемых сетях
системы
в
программно-
В основе ПКС лежит представление о компьютерной сети, как сети,
имеющей «плоскость данных», которая отвечает за пересылку пакетов на
основе состояния в каждом коммутаторе, и «плоскости управления», которая
отвечает за вычисление, «планирование» и управление пересылкой [48]. В
сетях новой архитектуры все маршрутизаторы и коммутаторы объединяются
под управлением единой сетевой операционной системы (СОС), которая
обеспечивает приложениям доступ к управлению сетью в соответствии с
рисунком 4 и постоянно отслеживает конфигурацию средств сети.
Рисунок 4.1– Схема ПКС
В отличие от традиционного толкования термина СОС как операционной
системы, интегрированной со стеком сетевых протоколов, в данном случае под
СОС понимается программная система, обеспечивающая мониторинг, доступ,
управление, ресурсами всей сети, а не конкретного узла, и СОС (или
58
контроллер) является основным, звеном ПКС-сети. Операционная система не
управляет сетью, она предоставляет программный интерфейс (API) для
управления. Таким образом, фактически решение задач управления сетью
выносится на уровень приложений, реализованных на основе API сетевой
операционной системы.
СОС формирует данные о состоянии всех ресурсов сети и обеспечивает
доступ к ним для приложений управления сетью. Эти приложения управляют
разными аспектами функционирования сети, включая построение топологии,
принятие маршрутизирующих решений, балансировку нагрузки.
Для реализации этой идеи был разработан открытый протокол OpenFlow
для управления сетевым оборудованием, не ориентированный на продукты
какого-то отдельного поставщика. С помощью этого протокола специалисты
сами могут определять и контролировать, какие узлы, при каких условиях и с
каким качеством могут взаимодействовать в сети.
OpenFlow (англ. открытый поток) — открытый протокол и технология
управления процессом обработки данных, которые передаются по
компьютерной сети коммутаторами и маршрутизаторами. Схема работы
протокола OpenFlow представлена в соответствии с рисунком 4.2
Рисунок 4.2– Схема работы протокола OpenFlow
Протокол применяется для управления работой сетевых коммутаторов
(маршрутизаторов) с центрального устройства – контроллера сети (например, с
выделенного сервера или даже с обычного персонального компьютера). Это
управление полностью заменяет или дополняет собой работающую на
коммутаторе (маршрутизаторе) прошивку (специальная программа, встроенная
производителем, котораяосуществляет построение маршрута, и создает карты
коммутации). Контроллер применяется для управления таблицами потоков
коммутаторов (маршрутизаторов).На основании таблиц потоков принимается
решение о передаче принятого пакета на конкретный порт коммутатора, или
его игнорирование. В результате в сети устанавливаются прямые сетевые
соединения с минимальными задержками и требуемыми параметрами передачи
данных.
Протокол OpenFlow решает также проблему зависимости от сетевого
оборудования какого-либо конкретного поставщика, поскольку ПКС
59
использует абстракции для пересылки пакетов, которые сетевая операционная
система использует для управления сетевыми коммутаторами.
В настоящее время разработан целый ряд сетевых операционных систем,
реализующих протокол OpenFlow.
а) NOX является платформой управления сетью, обеспечивающей
высокоуровневый программируемый интерфейс, с помощью которого можно
управлять сетью и/или создавать приложения для управления сетью. Так как
NOX является контроллером OpenFlow, то управление сетью производится на
уровне потоков и подразумевается, что контроллер определяет, как каждый
поток маршрутизируется в сети [49].
В отличие от стандартных средств построения сети (таких как создание
маршрутизаторов на основе Linux), NOX позволяет централизованно
программировать модель для всей сети. NOX предназначен для поддержки как
крупных корпоративных сетей с сотнями коммутаторов (с поддержкой многих
тысяч узлов), так и небольших сетей из нескольких узлов.
Ядро NOX предоставляет приложениям абстрактное представление
сетевых ресурсов, включая топологию сети и расположение всех
обнаруженных узлов.
Основные цели NOX:
1) обеспечить платформу, которая позволяет разработчикам и
исследователям вводить новшества в домашних или корпоративных сетях,
используя реальные сетевые аппаратные средства. Разработчики на NOX могут
управлять всеми подключениями в сети, включая передачу, маршрутизацию,
контроль узлов и пользователей, которым разрешается связь. Кроме того, NOX
может влиять на любой поток.
2) предоставить нужное сетевое программное обеспечение операторам.
На текущий момент можно централизованно управлять всеми коммутаторами
сети, разрешением на уровне пользователей и на уровне узлов с помощью
механизма политик.
б) Maestro – СОС для организации приложений для управления сетью
[50]. Maestro обеспечивает интерфейсы для реализации модульных приложений
управления сетью, для доступа и изменения состояния сети, а также
координации их взаимодействия.
Платформа Maestro предоставляет интерфейсы для:
1) внедрения новых пользовательских функций управления путем
добавления построенных из модулей компонентов управления;
2) поддержания состояния сети от имени управляющих компонентов;
3) компоновки компонентов управления, определяя последовательность
исполнения и общее состояние компонентов сети.
Кроме того, Maestro пытается использовать параллелизм на единственной
машине, чтобы улучшить производительность системы. Основной
особенностью сети является то, что OpenFlow контроллер отвечает за
начальную установку каждого потока, связываясь с подчиненными
коммутаторами. Таким образом, производительность контроллера может быть
узким местом. В разработке Maestro пытается уменьшить усилия
60
программистов по управлению распараллеливанием, выполняет большую часть
утомительного и сложного управления распределением рабочей нагрузки и
планирования рабочих потоков. Проект Maestro переносим и масштабируем,
поскольку разработан с использованием платформы Java и поддерживает
многопоточность.
в) Beacon – быстрый кроссплатформенный модульный, основанный на
Java, контроллер OpenFlow, который поддерживает и работу на основе событий
и на основе потоков [51].
Главные особенности:
1) устойчивость – Beacon был в разработке в течение полутора лет и
использовался в нескольких научно-исследовательских проектах, сетевых
классах и испытательном стенде. Beacon в настоящее время функционирует на
100 виртуальных и 20 физических коммутаторах в экспериментальном ЦОД и
работал в течение многих месяцев без сбоев.
2) кроссплатформенность – Beaconнаписан на Java и работает на многих
платформах от высококачественных многоядерных серверов Linux до
телефонов на Android.
3) динамичность – пакеты Beacon могут быть запущены / остановлены /
обновлены / установлены во время выполнения не прерывая другие
независимые пакеты.
г) Trema – платформа контроллера OpenFlow, которая включает все
необходимое для создания контроллеров OpenFlow на Ruby и/или C [52].
Платформа включает весь исходный код Trema, необходимый для
самостоятельной разработки контроллеров OpenFlow. Дерево исходных кодов
включает все основные библиотеки и функциональные модули, которые
работают интерфейсами коммутаторов OpenFlow. Также включено несколько
примеров контроллеров OpenFlow, разработанных с помощью Trema, а для
отладки имеется плагин для wireshark.
д) SNAC– контроллер OpenFlow, который использует веб-интерфейс
менеджера сетевой политики, чтобы управлять сетью [53]. Он включает гибкий
язык определения политики и удобный для пользователя интерфейс для
конфигурирования устройств и отслеживания событий. Он построен как
модуль NOX, однако требует определенную версию базового контроллера
NOX.
е) Helios– представляет собой расширяемый контроллер OpenFlow,
разработанный корпорацией NEC и рассчитанный на исследователей в области
ПКС. Он включает в себя специализированную программную оболочку,
позволяющую производить различные экспериментальные исследования.
ж) BigSwitch– контроллер OpenFlow с закрытым исходным кодом,
основанный на контроллере Beacon [54]. Контроллер BigSwitch использует
удобную в использовании консоль централизованного управления сетью, что
позволяет использовать контроллер в условиях развитой инфраструктуры
крупного предприятия.
61
4.3
Проблема выбор сетевой операционной системы
Для выбора сетевой операционной системы необходимо сравнить
характеристики рассмотренных контроллеров OpenFlow. Выберем в качестве
критериев следующие характеристики: язык программирования для разработки
контроллера, наличие документации по использованию контроллера,
открытость исходного кода контроллера и возможность поддержки
многопоточности.
Значения критериев для семи рассмотренных контроллеров приведены в
таблице 4.1. Сравнительный анализ значения критериев показывает, что
наиболее удобными для исследования и использования сетевыми
операционными системами являются контроллеры NOX и Beacon, потому что
они имеют открытый исходный код и хорошо документированы.
Таблица 4.1 – Сравнение контроллеров OpenFlow
Открытость
Язык
Качество
Контроллер
исходного
разработки документации
кода
NOX
C++/Python
Хорошее
Открытый
Maestro
Java
Плохое
Открытый
Beacon
Java
Хорошее
Открытый
Trema
C/Ruby
Плохое
Открытый
SNAC
C++/Python
Плохое
Закрытый
Helios
C
Хорошее
Закрытый
BigSwitch
Java
Хорошее
Закрытый
Многопоточность
Поддерживается
Поддерживается
Поддерживается
Поддерживается
Нет поддержки
Нет поддержки
Нет поддержки
Закрытость исходного кода не позволяет вносить в контроллер какиелибо изменения, что не соответствует поставленной задаче по дальнейшему
развитию сетевой операционной системы. В связи с этим контроллеры SNAC,
Helios и BigSwitch не могут быть использованы для дальнейшего развития.
Отсутствие хорошей документации по сетевой операционной системе не
позволяет эффективно расширять ее возможности, как следствие, контроллеры
Trema и Maestro, которые мало документированы, также необходимо
исключить из дальнейшего рассмотрения.
Для дальнейшего выбора сетевой операционной системы рассмотрим
результаты тестов производительности контроллеров Maestro, Beacon и NOX на
тестовом стенде, приведенные в работе [55]. Конфигурация включает в себя
два двухпроцессорных сервера (один для контроллера, другой для запуска
тестовых задач и перехвата пакетов) в следующей конфигурации:
 процессоры Intel Xeon E5405, в каждом процессоре находится по 4
вычислительных ядра;
 оперативная память– 4 гигабайта;
 cетевые интерфейсы: 2 интерфейса со скоростью 1 гигабит/с;
 операционная система: LinuxDebian Squeeze 32 бит;
62
 версия интерпретатора Java: Sun Java 1.6.0_24.
Результаты сравнения контроллеров приведены на рисунке 4.3, взятом из
источника [55]. Обозначения: NOX – обычная версия контроллера NOX без
поддержки многопоточности, NOX_d – многопоточная и хорошо
оптимизированная версия контроллера NOX, maestro – контроллер maestro,
beacon – контроллер beacon.
Как видно из графика на рисунке 4.3 наибольшую пропускную
способность показал контроллер NOX.
На основании данных таблицы 4.1 и графика в соответствии с рисунком
4.3 имеет смысл использовать для исследования и расширения сетевую
операционную систему NOX в качестве контроллера OpenFlow, поскольку
контроллер NOX имеет открытый исходный код, написан на языке
программирования C++, хорошо документирован и показывает наиболее
высокую производительность в сравнении с другими контроллерами OpenFlow.
Рисунок 4.3 – Сравнение производительности контроллеров OpenFlow
Таким образом, в результате сравнительного анализа семи современных
сетевых операционных систем (контроллеров OpenFlow) для дальнейшего
исследования и расширения выбрана СОС NOX, демонстрирующая
значительные функциональные возможности, наивысшую производительность,
имеющая хорошую документацию, открытый исходный код.
63
При росте количества данных, обрабатываемых контроллером, возникает
значительное увеличение нагрузки на процессоры сервера. Распределение
нагрузки на несколько вычислительных ядер уже реализовано во всех
актуальных версиях контроллеров, однако этого может оказаться недостаточно
для большого количества одновременных запросов. Кроме того, при
реализации контроллеров не учитывается возможность существования
холодного резерва, и, как следствие, нет механизма репликации сведений о
существующих потоках и адресах.
Отсутствие репликации означает невозможность динамического
распределения нагрузки, переключения ресурсов на менее загруженные
контроллеры. При переключении вся информация теряется и, затем,
накапливается заново. Концепция кластерных служб, широко использующаяся
при создании масштабируемых приложений, подразумевает наличие единого
хранилища данных, системы локальных хранилищ, реплицирующихся с
главным хранилищем по требованию, системы диспетчеризации сообщений от
главной службы – распределителя нагрузки.
Рассмотрим хранилище данных более детально. Основное отличие
кластерного подхода – все данные хранятся в оперативной памяти, все действия
с данными выполняются в оперативной памяти. Управляющий узел сам
принимает решения о записи на жесткий диск изменений в БД. На всех узлах с
контроллерами запущены экземпляры сервера СУБД, настроенного на работу с
кластерным хранилищем. При этом сервер работает в режиме «ленивого»
чтения, то есть сохраняет на какое-либо время использованные данные на
стороне клиента.
Сетевое хранилище БД имеет автоматически-резервируемую структуру
хранения данных, серверы СУБД логически соединены с каждым узлом
кластерного хранилища данных. В случае отказа одного из узлов хранилища
выполнение транзакций продолжается на другом узле. Все узлы, используемые
для хранения данных, могут быть продублированы. В случае отказа одного из
узлов всегда есть еще один узел с теми же данными. Управляющий узел также
может быть продублирован. Отказ управляющего узла (даже если он один)
никак не влияет на работу остальных узлов такого кластера. В случае если
обнаружен отказ одного из узлов(недоступность его по сети, отказ жесткого
диска), он автоматически помечается как недоступный, и все остальные узлы
кластера оповещаются об этом.
Для обеспечения целостности данных используется непрерывное ведение
протокола всех выполненных транзакций и локальные контрольные точки. По
мере достижения определенного количества проведенных транзакций все
данные сохраняются на жесткий диск, и
файл протокола очищается.
Распределитель нагрузки имеет холодный резерв, который активируется
компонентом наблюдения. При активации резервного распределителя нагрузки
мастер-служба СУБД на резервном узле подключается к СУБД и активирует
все соединения с узлами хранилищами БД. Все коммутаторы с поддержкой
OpenFlow имеют возможность настроить до трех адресов контроллера для
64
резервирования, первый адрес настраивается на интерфейс узла с основным
распределителем нагрузки, второй адрес должен быть настроен на интерфейс
узла с резервным распределителем нагрузки.
4.4 Расширение
функциональных
интеграции СОС с облачными сервисами
характеристик
за
счет
В настоящее время все облачные сервисы используют альтернативные
реализации виртуальной сети между экземплярами виртуальных машин внутри
группы. ДляVMwareVCloud, XenCloudPlatform –
этоOpenVSwitch,
дляOpenStack – Quantum, дляRedHatEnterpriseLinux – LinuxBridge.
Архитектуры CiscoBlade, SunBlade проводят перенос коммутации
в
физические управляемые коммутаторы вместо виртуальных. Наиболее
универсальным решением является использование OpenVSwitch как полностью
управляемого, независимого коммутатора с поддержкой OpenFlow.
OpenVSwitch имеет программные дополнения, добавляющие совместимость со
всеми популярными платформами для коммутации в облачных структурах.
Поддержка OpenFlow позволяет интегрировать любую промышленную
облачную систему с существующей программно-конфигурируемой сетью.
Рассмотрим самую распространенную платформу с открытым исходным
кодом для облачных систем OpenStack. Для создания виртуальных подсетей для
групп виртуальных машин используется программная система Quantum, в
которой кроме сетевых функций, реализованных на базе LinuxBridge, есть
функции, отвечающие за взаимодействие с контроллером OpenStack,
гипервизорами виртуальных машин, контроллерами вычислительных узлов
nova-compute, контроллерами узлов хранения данных glance и swift. Поэтому
полностью
заменить
систему
Quantumна
другую
представляется
нецелесообразным. Однако существует решение для замены LinuxBridge на
OpenVSwitch, позволяющее расширить функционал и создать единую сеть под
единым управлением из физических и виртуальных коммутаторов. В
соответствии с рисунком 4.5 виртуальный коммутатор независим от остальных
компонентов.
65
Внешние сети
Сервер DHCP
СУБД
Контроллер
облачной
системы
OpenStack
Сервер
Quantum
Локальная сеть
ЦОД
Вычислительный узел
Виртуальная
машина
Виртуальный
интерфейс
Виртуальный
коммутатор
Преобразователь
трафика
Linux Bridge
Физический
интерфейс
Клиент
Quantum
Рисунок 4.5 – Структурная схема модулей, входящих в архитектуру Quantum
Основная задача виртуального коммутатора – передать трафик от
источника до приемника. В облачных системах могут существовать подсети
разных пользователей с одинаковыми адресами, поэтому передача трафика
между узлами без создания виртуального туннеля невозможна. Для этого
можно использовать преобразователь трафика LinuxBridge. При использовании
OpenFlow в виртуальном коммутаторе Quantum пропадает необходимость
выполнять какие либо преобразования трафика, за исключением случаев
коммутации с другим ЦОД при распределенной архитектуре. При этом
контроллер OpenFlow управляет трафиком непосредственно от источника до
приемника на всем протяжении пути, что позволит обеспечить требуемые
параметры качества обслуживания и производительности.
4.5
Виртуализация сетей передачи данных
Виртуализированные сети открывают новые, недоступные в обычных
сетях возможности. В этом случае соответствующие сетевые службы
отделяются от физической сетевой инфраструктуры. Данный подход
реализуется с помощью управляемых коммутаторов, функциональность
которых позволяет поддерживать виртуальные локальные сети (Virtual Local
Area Network, VLAN). В области беспроводных локальных сетей тоже имеются
возможности для виртуализации типа Multi-SSID (несколько идентификаторов
беспроводной сети на одной точке доступа).
При виртуализации сетей виртуализация может распространяться и на
глобальную сеть, охватывать маршрутизаторы Интернет. Основное
преимущество виртуализации сетей заключается в возможности многократного
использования физической сетевой инфраструктуры. На основе физической
сети создается несколько логических сетей, которые используют общую
аппаратную инфраструктуру, но в остальном они почти полностью
изолированы.
66
Виртуализация сетей реализуется с применением двух различных
методов. В случае VLAN и Multi-SSID виртуализации подвергается среда
передачи (канальный уровень), которая преобразуется в многократно
используемую среду. Беспроводная точка доступа с несколькими логическими
сетями создаетодновременноработающие изолированные зоны.Эти технологии
реализуются на канальном уровнемодели OSI. Такой вид виртуализации
ограничивается локальной сетью предприятия.
Взаимодействие на базе IP все чаще выходит за границы одной локальной
сети, и перемещается в глобальную сеть. В этих условиях виртуализации
VLAN и Multi-SSID оказывается недостаточно.
Следующий шаг в развитии виртуализации сетей — виртуализация на
третьем уровне, отделение данных от физической среды передачи данных:
создание IP сетей и маршрутизация пакетов данных между этими сетями IP.
При этом используется маршрутизатор, позволяющий создать множество
виртуальных маршрутизаторов. Каждый виртуальныймаршрутизатор может
настраиваться только для своей сети. Следующий уровень виртуализации
предполагаетодновременно реализовать разные приложения с собственными
настройками для маршрутизации и качества обслуживания.
Наибольшее распространение виртуализация сетей получила при
виртуализации ресурсов. Гипервизор может создать один или несколько
виртуальных сетевых адаптеров для каждой виртуальной машины. Эти
адаптеры будут видны в виртуальной машине как физические, но в
действительности они только предоставляют интерфейс к реально
существующему сетевому адаптеру. Гипервизор также позволяет динамически
создать виртуальную сеть с виртуальными коммутаторами, чтобы обеспечить
настраиваемую связь между конечными точками виртуальных машин.
Виртуальный коммутатор – это ключевой компонент, необходимый для
виртуализации сетевой инфраструктуры. Виртуальный коммутатор соединяет
виртуальные сетевые адаптеры с физическими сетевыми адаптерами,
установленными на сервере, и, что более важно, связывает одни виртуальные
сетевые адаптеры с другими для локального взаимодействия в рамках сервера.
Новый класс коммутаторов называется распределенным виртуальным
коммутатором (distributed virtual switch) и применяется для соединения
серверов таким способом, чтобы аппаратная архитектура стала прозрачной для
использующих её приложений. Виртуальный коммутатор на одном сервере
может прозрачно для пользователей подключиться к виртуальному
коммутатору на другом сервере.
Один из наиболее важных проектов в этой области – проект OpenVSwitch,
реализующий виртуальную коммутацию на базе протокола OpenFlow.
OpenVSwitch – это многоуровневый виртуальный коммутатор с открытым
исходным кодом. OpenVSwitch поддерживает наиболее популярные
гипервизоры, включая KVM, VirtualBox, Xen и XenServer. OpenvSwitch состоит
из службы-коммутатора и сопутствующего модуля ядра, который управляет
процессом поточной (flowbased) коммутации.
Другая технология используется в гипервизоре VMWareESXi – VXLAN
67
(Virtual eXtensible LAN), которая предоставляет расширенный механизм
создания виртуальных сетей VLAN в крупных ИТ-инфраструктурах,
объединяющих несколько ЦОД. VXLAN – это замена VLAN для создания
прозрачной мобильной сетевой среды для виртуальных машин, имеющих
возможность перемещаться между ЦОД. Стандартная концепция VLAN
позволяет использовать только до 4096 виртуальных сетей для логической
изоляции классов систем, что в крупных инфраструктурах иногда оказывается
недостаточно. Технология VXLAN – это способ создания новых логических
сетей в рамках уже существующих IP-сетей. В одной VXLAN-сети виртуальная
машина уникально идентифицируется двумя следующими параметрами:
а) VXLANNetworkIdentifier
(VNI)
–
24-битный
идентификатор
виртуальной сети;
б) MAC-адрес машины.
Соответственно, в одной VXLAN-сети не может быть машин с
одинаковым MAC-адресом, но в разных VXLAN-сетях они могут существовать.
Реализована технология в программных коммутаторах vSwitch, работающих на
уровне ядра ОС, а также в распределенном коммутаторе VMware Distributed
Switch, который объединяет несколько коммутаторов vSwitch в целях
обеспечения централизованного управления сетевой инфраструктурой.
Виртуализация сети становится все более значимой и постоянно
развивается, как и другие формы виртуализации. Стоимость развертывания
экспериментальных топологий сетей, строгие требования изоляции трафика
предприятия, а также увеличивающиеся требования вычислительной мощности
для виртуальных серверов делают виртуализацию ключевым фактором, как в
секторе исследований, так и в индустрии (корпоративных сетях и центрах
обработки данных). Однако при виртуализации центров обработки данных
возникает проблема виртуализации и сетевых потоков для динамического
изменения конфигурации сети, которая может быть решена за счет
использования динамической настройки OpenFlow оборудования.
4.6 Управление сетевыми ресурсами и потоками данных в ПКС с
помощью сетевой операционной системы
Производительность СОС измеряется как количество обслуженных
запросов типа «PacketIn» в единицу времени. Кроме того, в каждой СОС
существует ограничение на максимальное число коммутаторов, подключенных
к одному экземпляру приложения. Схема тестирования производительности
зависит от режима измерений. Для тестирования применяется программа
«cbench» [54], которая эмулирует некоторое количество коммутаторов. При
тестировании полезной производительности после посылки каждого события
«PacketIn» виртуальный коммутатор ожидает ответа и после этого повторяет
запрос. При тестировании полной производительности коммутатор не ожидает
ответа, а сразу же посылает новое событие. Алгоритм работы показан нас
рисунке4.6.
68
Послать и принять событие «PacketIn» может только виртуальный
коммутатор, эмулируемый программой cbench. Но все остальные действия
должен выполнять командный интерпретатор с соответствующим логики
измерения исполняемым кодом.
Начало
Ввод
параметро
в
i=1
Exp_no=1
i<=N
Параметры:
а) L – размер серии экспериментов;
б) M – время одного эксперимента;
в) N – количество эмулируемых коммутаторов;
г) T=1 – установить режим тестирования максимальной
производительносии, иначе режим полезной
произвоительности;
д) L=1 - эмулировать ответы ARP, иначе не эмулировать.
Установка номера
эксперимента
А
Установка
сессии с
контролле
ром
i=i+1;
TimeBegin=Now
Установка
времени
начала
эксперимента
Рисунок 4.6 – Алгоритм тестирования производительности контроллера
69
А
Номер коммутатора
Sw_no=1
Количество принятых ответов
от контроллера
PktIn_cnt[Sw_no]=1
Буфер не заполнен
Да
Посылка
PacketIn
коммутато
ром Sw_no
Нет
Прием
ответа
коммутатор
ом Sw_no
Если время эксперимента
превысило заданное
значение
Now-TimeBegin>M
Ответ принят?
Нет
Да
PktIn_cnt[Sw_no]+=1
Счетчик ответов
от коммутатора
Sw_no
T==1
Да
Нет
Sw_no+=1
Нет
Sw_no>N
Следующий коммутатор
Если номер коммутатора
превысил максимальное
значение
Да
Нет
Now-TimeBegin>M
Если время эксперимента
превысило заданное значение
Да
PktIn_cnt
Exp_no+=1
Если количество
экспериментов в серии
превысило заданное
значение
Вывод вектора результатов
эксперимента
Exp_no>L
Да
Нет
Конец
Продолжение рисунка 4.6
70
Задержки, возникающие при различных методах управления
коммутаторами, могут являться показателем эффективности управления. В
общем виде систему контроллер-коммутатор можно представить в виде сети
массового обслуживания в соответствии с рисунком 4.7.
Рисунок4.7 – Схема системы коммутатор-контроллер
Задержка обработки первого пакета в серии определяется { S1 ,  C , S2 }, то
есть коммутатор два раза обрабатывает различные пакеты для передачи одного
пакета данных. При этом S{1, 2}   C , в среднем различие составляет несколько
порядков. Поэтому эффективность работы системы определяется количеством
обращений к контроллеру. Поскольку при планировании
задач в
распределенной вычислительной системе заранее известны узлы, возможно
использовать метод «ProActive» управления системой для минимизации
обращений к контроллеру. Однако максимальное количество простых потоков
в одном коммутаторе одновременно не превышает 1700 для коммутаторов под
управлением прошивки Pronto, около 1500 для коммутаторов HP. Поэтому
важно соблюсти баланс между количеством постоянных записей в таблице
OpenFlow и временных, удаляемый по истечению времени неактивности. Пусть
p(contr) – доля трафика, попадаемого в контроллер на обработку по отношению
к общему трафику. При p(contr)=0.04 будем считать, то система работает в
режиме «ProActive», при p(contr)=1 в режиме «ReActive». На рисунке 4.8
показана зависимость среднего времени полной обработки пакета T от
величины p(contr). Как видно из графика для величины загрузки 0.8
наблюдается двукратная разница при значениях p(contr), равных 0.5 и 1. Но
при меньших значениях, например при 0.2, разница не такая большая.
71
Рисунок 4.8 – Зависимость задержки от p(contr)
Существующая система планирования задач в связке с модулем
управления контроллера позволяет достигнуть значения p(contr) не выше 0.5,
что позволяет оптимально использовать как ресурсы контроллера, так и
коммутаторов.
4.7
Использование ПКС для управления сетью ЦОД
Для построения ЦОД как правило используются архитектурные сетевые
решения, отличные от решений для локальных сетей передачи данных.
Серверные фермы, как правило, используют двойное резервирование для всех
компонентов, включая связи, коммутаторы, сетевые карты. Коммутаторы
втаких ЦОД должны поддерживать множественные пути, что противоречит
принципу работы протоколов семейства Spanning-TreeProtocol (STP). Для
расширения функционала такие коммутаторы должны поддерживать
расширения DataCenterEthernet (DCE) или быть программно-управляемыми.
Большинство ведущих производителей уже предлагают программноуправляемые решения в комплекте с различными СОС, иногда СОС включается
в состав коммутатора, как в CiscoNexus [56]. В этом случае контроллер запущен
на отдельном процессоре коммутатора.
При использовании ПКС становится возможным заранее задавать пути
прохождения потоков данных, что позволяет управлять эффективностью
сетевой инфраструктуры. Основным критерием эффективности работы сетевой
инфраструктуры принято считать параметры производительности. В число
таких параметров входит пропускная способность, межконцевая задержка,
параметры QoS (вариативность задержки, размеры очередей).
Для измерения размеров очереди используются либо стандартные
запросы статистики очередей OpenFlow, либо специфические запросы по SNMP
протоколу. Основная проблема заключается в том, что каждый производитель
72
оборудования своим образом обеспечивает поддержку очередей в OpenFlow. В
большинстве случаев очереди на портах существуют в аппаратной части и
поддерживают только стандартную обработку, предусмотренную механизмами
приоритезации. С помощью OpenFlow возможно только перенаправить нужный
поток в нужную очередь, а в некоторых случаях и это возможно только
косвенно через задание полей VLAN_PCP.
Измерение времени обработки пакета выполняется модулем
openflow_action_delay в два этапа. Сначала генерируются пакеты, для которых
создается простое правило перенаправления в требуемый порт коммутатора и
измеряются интервалы времени между генерацией пакета и получением того
же пакета на другом интерфейсе, при этом таблица потоков коммутатора
остается неизменной, и событие «PacketIn» генерируется только на первый
пакет. Затем в таблицу потоков вносятся изменения, изменяется порт
перенаправления
пакета,
и
добавляются
несколько
определенных
пользователем действий над пакетом перед действием на перенаправление.
Время во втором этапе фиксируется таким же образом, как и на первом этапе
измерения. Затем при сравнении времен вычисляется средняя величина
времени на обработку одного действия в таблице OpenFlow. Модуль имеет
настраиваемую интенсивность генерации пакетов, настраиваемый список
определенных пользователем действий для добавления в таблице на втором
этапе измерений. Модуль сразу рассчитывает среднее, дисперсию и
коэффициент вариации времени.
Модуль openflow_packet_in используется для оценки производительности
коммутатора по сообщениям «PacketIn», определяющим формирование новой
записи в таблице OpеnFlow посредством запроса на контроллер. Для измерений
модуль очищает всю таблицу коммутатора и начинает генерацию пакетов с
заданной интенсивностью и размером. Одновременно по протоколу SNMP
снимаются данные о загрузке процессора, потерях пакетов, по окончании
эксперимента автоматически рассчитывается среднее, дисперсия и
коэффициент вариации времени реакции и пропускной способности.
Модуль openflow_reactive позволяет оценить производительность связки
коммутатор-СОС. Для этого с заданной интенсивностью генерируются пакеты
со случайными адресами и заданным размером. Затем фиксируются времена
генерации пакета, получения сообщения «PacketIn» от коммутатора, отправки
записи о потоке контроллером и время получения пакета на другом интерфейсе.
На время эксперимента контроллер использует модуль эмуляции
концентратора для того, чтобы не генерировать ARP пакеты. Модуль имеет
настраиваемый генератор интервалов времени между исходящими пакетами.
По окончании рассчитываются среднее, дисперсия и коэффициент вариации
каждого интервала времени и пропускной способности.
Модуль openflow_echo_delay позволяет оценить задержку в канале
управления коммутатором со стороны контроллера. Для этого по заданной
интенсивности генерируется запрос «Echo», на который коммутатор должен
ответить таким же пакетом, время отклика фиксируется. По окончании
73
рассчитываются среднее, дисперсия и коэффициент вариации каждого времени
отклика.
В приложении А рассмотрен пример применения такого подхода при
обеспечении QoSдля каждого потока в отдельности. Управление происходит
через поля VLAN_PCPи создания приоритезуемых очередей на каждом порту
коммутатора. В приложении Б приведен исходный код модуля для контроллера
POX.
74
5
Практическое
конфигурируемой сети
5.1
руководство
по
программно-
Работа с эмулятором mininet
Виртуальное окружение mininet является симулятором топологии на
виртуальных хостах. Это виртуальная машина для системы OracleVirtualBox,
которая заранее готова к работе. Исходный материал с полной документацией
можно найти на сайте Openflow.org, а полный учебник по работе с mininet и
образ
для
виртуальной
машины
–
по
адресу:
http://www.openflow.org/wk/index.php/OpenFlow_Tutorial.
Mininet — это образ Ubuntu с уже установленными контроллером,
пакетным перехватчиком и эмулятором mininet. Установим образ на Virtualbox.
Рисунок 5.1 – Создание виртуальной машины
После запуска VirtualBox необходимо нажать кнопку создать (поле 1 на
рисунке 5.1), написать название виртуальной машины и выбрать тип LinuxUbuntu, как показано в поле 2 рисунка 5.1. Объем памяти установить не менее
512Мб (поле 3), для жетского диска установить значение «Использовать
существующий жесткий диск» (поле 4), нажать кнопку выбора файла (поле 5).
Необходимо выбрать скачанный образ Mininet и нажать кнопки «Открыть»,
потом «Создать».
75
После создания необходимо настроить на виртуальной машине
интерфейсы, через которые можно открывать ssh сессии.
Для этого в VirtualBox выделяем виртуальную машину с mininet,
нажимаем кнопку «Настроить» (рисунок 5.2), далее на вкладке «Сеть» (поле 1
рисунка 5.2) выбираем вкладку «Адаптер 2» (поле 2) и ставим галку напротив
«Включить сетевой адаптер» (поле 3). Затем из выпадающего списка (поле 4)
выбираем «Внутренняя сеть».
Рисунок 5.2 – Настройка адаптера 2 виртуальной машины
После этого, для возможности доступа к Интернет и внутренней сети
необходимо настроить адаптер 1 (рисунок 5.3). Во вкладке сверху (поле 1)
выбрать «Адаптер 1», затем тип адаптера – «Сетевой мост» (поле 2), в
выпадающем списке физических адаптеров (поле 3) выбрать нужный (Ethernet
или WiFi адаптер). После настройки необходимо применить параметры
нажатием кнопки «Ok».
Теперь необходимо запустить виртуальную машину двойным щелчком
мыши на названии виртуальной машины. После запуска (рисунок 5.4) будет
доступна консоль Linux.
76
Рисунок 5.3 – Настройка адаптера 2 виртуальной машины
Необходимо ввести логин и пароль по умолчанию, для 32-битного образа
пользователь openflow пароль openflow, для 64-битного образа это
соответственно (mininet, mininet). Обратите внимание, что при вводе пароля
символы не отображаются.
Рисунок 5.4 – Внешний вид консоли виртуальной машины
77
Для проверки сетевых интерфейсов необходимо использовать команду
«ifconfig -a» (рисунок 5.5).
Рисунок 5.5 – Проверка сетевых параметров виртуальной машины
Если адресов нет, как на рисунке 11, необходимо выполнить команду на
получение адресов через DHCP «sudodhclienteth0», «sudodhclienteth1» в
соответствии с именами интерфейсов. После выполнения необходимо
проверить факт получения адресов (рисунок 5.6 поле 1).
Рисунок 5.6 – Местонахождение адреса в выводе команды ifconfig
78
После этого можно подключиться любым SSH клиентом, например
PUTTY (рисунок 5.7).
Адрес в поле 1 должен соответствовать адресу в выводе команды
«ifconfig», как на рисунке 6 поле 1. Тип протокола – SSH (поле 2). После
нажатия кнопки «Open» откроется окно (рисунок 5.8) с предложением ввести
логин и пароль.
Для полноценного использования необходимо установить графическую
среду. Это происходит только при подключении к Интернет. Если в сети не
используется прокси-сервер, то можно просто приступать к выполнению
команд установки, иначе необходимо прописать прокси-сервер, перед этим
войти в режим root командой «sudosu», ввести пароль и выполнить команды:
«export
http_proxy=«http://адрес_сервера:порт_сервера»
и
«export
ftp_proxy=«http://адрес_сервера:порт_сервера».
Рисунок 5.7 – Настройка SSH клиента
79
Рисунок 5.8 – Подключение по SSH
Если прокси сервер требует авторизацию, то команда будет выглядеть как
«exporthttp_proxy=«http://логин:пароль@адрес_сервера:порт_сервера»
и
«exportftp_proxy=«http://логин:пароль@адрес_сервера:порт_сервера».
После настройки можно запустить установку графического интерфейса
командой «sudoapt-getupdate» и «sudoapt-getinstallxinitflwm»
Графический интерфейс можно запустить только из самой виртуальной
машины, но не из SSH клиента.
Для работы с mininet можно использовать следующие ключи запуска (см.
таблицу 5.1).
Таблица 5.1 – Ключи запуска mininet
Команда
Действие
-h, --help
Вывод справки
Выбор типа программно-управляемого коммутатора.
Варианты: [kerneluserovsk]
Задает адрес запуска mininet
Задает тип контрооллера. Варианты:
[nox_dumpnonerefremotenox_pysw]
Задает параметры топологии. Варианты:
[treereversedsinglelinearminimal] через запятую могут
указываться аргументы ,arg1,arg2,...argN
Закрывает mininet и очищает все виртуальные машины
Включает формирование разных МАС адресов для хостов
Запустить консоли в графическом режиме для каждого
хоста
Заранее установить arp записи в хосты в статичном
режиме
Адрес контроллера
--switch=
--host=
--controller=
--topo=
-c, --clean
--mac
-x, --xterms
--arp
--ip=
80
Продолжение таблицы 5.1
Команда
Действие
--port=
--prefixlen=
Порт контроллера
Длина маски для автоматического распределения адресов
Например, для создания топологии, показанной на рисунке 5.9,
необходимо выполнить следующую команду:
sudo mn --topo single,3 --mac --switch ovsk --controller remote
Контроллер C0
Ip=127.0.0.1
TCP port=6633
Интерфейс для
внешнего управления
Ip=127.0.0.1
TCP port=6634
OpenFlow
коммутатор S1
s1-eth0
s1-eth2
s1-eth1
h2-eth0
H2
Хост 1
Ip=10.0.0.2
h4-eth0
h3-eth0
H3
Хост 2
Ip=10.0.0.3
H4
Хост 3
Ip=10.0.0.4
Рисунок 5.9 – Топология с 3 узлами и 1 коммутатором
При входе в mininet отображается консоль управления, начинающаяся со
строки «mininet>»
Список команд представлен в таблице 5.2.
81
Таблица 5.2 – Список команд управления mininet
Команда
Описание
dump
intfs
Отображает все IP адреса устройств, их интерфейсы
Отображает список интерфейсов устройств
Измеряет производительность обмена по TCP между
первым и последним хостом
Измеряет производительность обмена по UDP между
первым и последним хостом
Показывает схему соединений устройств
Позволяет создать новую связь. Синтаксис: «link
устройство1 устройство2 [up|down]»
Показывает список устройств
Выполняет команду, но не отображает информацию о
результате
Посылает ICMP пакеты между первыми двумя хостами
Посылает несколько ICMP пакетов между всеми хостами по
очереди и показывает результат
Выполняет любую команду на языке Python
Закрывает mininet
Читает список команд из указанного после команды файла
Открывает в графическом режиме отдельное окно с
консолью соответствующего хоста. Синтаксис команды:
«xterm узел1 узел2 …». Команды работают только в
графическом режиме виртуальной машине (см. рисунок 17)
Выполняет произвольную команду в операционной системе
Выполняет внешнее управление коммутаторами, синтаксис
будет рассмотрен ниже.
Настраивает сетевые параметры указанного перед командой
хоста. Синтаксис команды: «хост1 ifconfig параметры»
Выполняет команду ping на указанном хосте. Синтаксис
команды «хост1 ping хост2»
iperf
iperfudp
net
link
nodes
noecho
pingpair
pingall
py
quit, exit
source
xterm, gterm
sh
dpctl
ifconfig
ping
Для получения помощи по командам можно воспользоваться знаком «?»
(рисунок 5.10), для подробной помощи можно набрать «helpкоманда».
82
Рисунок 5.10 – Список и синтаксис команд mininet
При необходимости использовать графический интерфейс (для команд
xterm, gterm) необходимо запустить его командой «startx» (рисунок 5.11), после
запуска нажать правой кнопкой мыши на пустом месте рабочего стола и
выбрать «OpenTerminalHere» для запуска консоли. В консоли графического
режима можно работать так же, как и в текстовом режиме.
Рисунок 5.11 – Графический режим
83
Для запуска консоли виртуального хоста необходимо использовать
команду xterm. Она запускает отдельное окно с консолью, в которой находится
полноценный Linux на виртуальной машине (рисунок 5.12).
Рисунок 5.12 – Консоль xterm виртуального хоста
Весь набор команд Linux работает в этой консоли, включая ifconfig, ping,
iperf, vi, sh и т.д.
По умолчанию, если не используется внешний контроллер (нет параметра
«--controller=remote»), коммутатором можно управлять через команду «dpctl»,
рассмотренной в следующем разделе.
5.2
Внешнее управление таблицами OpenFlow коммутаторов
Программа «dpctl» используется для внесения изменений, просмотра и
мониторинга таблиц OpenFlow. Основные команды показаны в таблице 5.3.
Таблица 5.3 – Команды dpctl
Команда
show
status
Описание
Показывает информацию о коммутаторе. Синтаксис команды
«dpctlshowtcp:адрес:порт», где «адрес» – это адрес коммутатора
(127.0.0.1 в mininet), а «порт» - управляющий TCP порт
коммутатора (6634 в mininet)
Показывает статистику по таблицам, портам и коммутатору в
общем. Синтаксис аналогичен команде «show», но после команды
можно использовать название статистики для фильтрации вывода
84
Продолжение таблицы 5.3
Команда
dump-desc
dump-flows
dump-ports
dump-queue
dump-tables
add-flow
add-flows
add-queue
mod-flows
Описание
Показывает суммарную информацию о аппаратном
обеспечении и прошивке коммутатора. Синтаксис
аналогичен команде «show»
Показывает все записи в таблицах потоков на
коммутаторе. Синтаксис аналогичен команде «show»,
после команды можно ставить условия фильтрации по
номеру потока, например «(X=11,12,13)»
Показывает все интерфейсы на коммутаторе. Синтаксис
аналогичен команде «show»
Показывает все программные очереди пакетов на
коммутаторе. Синтаксис аналогичен команде «show»
Показывает статистику по таблицам OpenFlow.
Синтаксис аналогичен команде «show»
Добавляет запись в таблицу потоков. Синтаксис
команды: «dpctladd-flowtcp:адрес:порт
in_port=порт1,actions=output:порт2», где in_port=порт1 –
это условие применения записи к потоку, поле
output:порт2 – это реакция записи на поток, в данном
случае перенаправить поток на другой порт коммутатора
(порт2) если поток пришел из указанного интерфейса
(порт1)
Добавляет запись в таблицу потоков. Синтаксис
команды: «dpctladd-flowtcp:адрес:порт файл», где «файл»
– это файл с записями потоков
Добавляет программную очередь коммутатора.
Синтаксис команды: «dpctladd-queuetcp:адрес:порт
интерфейс номер_очереди скорость», где «интерфейс» –
это порт коммутатора, «номер_очереди» – уникальный
идентификатор очереди, «скорость» – минимальная
гарантированная пропускная способность в Кб/с
Изменяет реакцию на совпадение с полем сравнения
потока. Синтаксис команды «dpctlmodflowstcp:адрес:порт список_условий новое_действие», где
«список условий» – полное перечисление поле сравнения
потока как было указано при создании записи командой
«add-flow», «новое_действие» – любое стандартное
действие, которое будет заменено в таблице потоков.
Если список условий указан в общем, то будут изменены
все потоки, для которых это поле будет хотя бы частично
совпадать с полем сравнения
85
Продолжение таблицы 5.3
Команда
mod-queue
mod-port
del-flows
del-queue
monitor
execute
ping
benchmark
Описание
Позволяет изменять минимальную гарантированную
пропускную способность конкретной очереди. Синтаксис
команды «dpctlmod-queuetcp:адрес:порт интерфейс
номер_очереди скорость», где параметры аналогичны
команде «add-queue»
Синтаксис команды «dpctlmod-portstcp:адрес:порт
номер_порта команда», где номер порта – число, команда –
одно из значений «up», «down», «flood», «noflood».
Удаляет поток или группу потоков. Синтаксис команды
«dpctldel-flowstcp:адрес:порт маска», где «маска» – условие
или часть условия поля сравнения потока, при совпадении с
которой поток удаляется
Удаляет очередь. Синтаксис команды «dpctldelqueuetcp:адрес:порт интерфейс номер_очереди», где
параметры аналогичны команде «add-queue»
Выводит на экран пакеты, пришедшие на коммутатор
Выполняет произвольную команду в ОС коммутатора.
Синтаксис «dpctlexecutetcp:адрес:порт команда», где
«команда» – произвольная строка в кавычках
Показывает время отклика коммутатора. Синтаксис
аналогичен команде «show»
Измеряет производительность коммутатора или
контроллера. Синтаксис «dpctlbenchmarktcp:адрес:порт
размер_пакета количество», где «размер_пакета» – размер
пакета, посылаемого для проверки производительности, а
«количество» – это количество таких пакетов. Результат
возвращается в виде суммарного времени выполнения
посылки всех команд и пакетов, а также в вид средней
производительности в пакетах/с
Список полей для создания списка условий применения конкретной
записи о потоке к пакету при добавлении и изменении записей (действия «addflow», «add-flows», «mod-flows», «del-flow») приведен в таблице 5.4.
Таблица 5.4 – Поля для фильтрации записей OpenFlow
Поле проверки
in_port
Meta
eth_dst
eth_type
Описание
Входящий порт коммутатора
Произвольные метаданные
МАС-адрес получателя
Тип фрейма
86
Продолжение таблицы 5.4
Поле проверки
eth_src
vlan_vid
vlan_pcp
ip_dscp
ip_ecn
ip_proto
ip_src
ip_dst
tcp_src
tcp_dst
udp_src
udp_dst
sctp_src
sctp_dst
icmp_code
icmp_type
arp_op
arp_spa
arp_tpa
arp_sha
arp_tha
ipv6_src
ipv6_dst
ipv6_flabel
icmpv6_code
icmpv6_type
Описание
МАС-адрес отправителя
Номер VLAN сети
Приоритет VLAN сети
Поле DSCP для QoS
Поле IP ECN для сообщениях о перегрузке
сети
Тип подпротокола IP
IP адрес источника
IP адрес получателя
TCP порт источника
TCP порт получателя
UDP порт источника
UDP порт получателя
SCTP порт источника
SCTP порт получателя
Тип ICMP пакета
Код ICMP пакета
Тип ARP пакета
Адрес IP источника ARP пакета
Адрес IP получателя ARP пакета
Адрес МАС источника ARP пакета
Адрес МАС получателя ARP пакета
IPv6 адрес источника
IPv6 адрес получателя
IPv6 метка потока
Тип пакета ICMPv6
Код пакета ICMPv6
Список сравнений не ограничивается только приведенными полями,
каждый производитель вправе добавлять собственные поля для сравнения.
Однако список действий над потоками стандартен и представлен в таблице 5.5,
хотя производители коммутаторов OpenFlow вправе дополнять его.
Таблица 5.5 – Список действий над потоком.
Действие
output
mpls_ttl
mpls_dec
push_vlan
pop_vlan
Описание
Перенаправить поток в другой порт коммутатора. Требует
указания номера порта (например «output:10»)
Установить значение MPLS TTL
Уменьшить на единицу значение MPLS TTL
Инкапсулировать пакет в VLAN с указанным номером
Декапсулировать пакет из VLAN
87
Продолжение таблицы 5.5
Действие
Описание
push_mpls
pop_mpls
queue
group
nw_ttl
nw_dec
set_field
Инкапсулировать пакет в MPLS пакет с указанным тегом
Декапсулировать пакет из MPLS
Ассоциировать пакет с указанной очередью
Группировать запись в группу записей
Установить указанное значение поля IP TTL
Уменьшить на единицу значение поля IP TTL
Установить произвольное значение поля пакета
Все действия могут выполняться последовательно, если их указано
несколько, например действие «queue:1,output:10» означает ассоциацию с
первой очередью и перенаправление в десятый порт.
5.3
Установка и настройка контроллеров
Контроллер NOX. Контроллер необходимо устанавливать на
виртуальную или физическую ОС Ubuntu 11.04, на версии 12.04 и выше
возможны проблемы совместимости. Для установки необходимых библиотек
можно воспользоваться автоматизированной установкой зависимостей, для
этого необходимо выполнить следующие команды:
а) команду «cd /etc/apt/sources.list.d» для перехода в нужный каталог;
б) команду «sudowgethttp://openflowswitch.org/downloads/debian/nox.list»
для закачки списка серверов обновлений;
в) команду «sudoapt-getupdate» для обновления списка пакетоа;
г)
команду
«sudoapt-getinstallnox-dependenciesgitlibboost-thread-dev»
дляустановкинеобходимыхбиблиотек;
д) команду
«sudoapt-getinstalllibtbbdev&&wgethttp://citylan.dl.sourceforge.net/project/boost/boost/1.48.0/boost_1_48_0
.tar.bz2 &&tar --bzip2 -xf ./boost_1_48_0.tar.bz2 &&cdboost_1_48_0 &&
./bootstrap.sh
--prefix=/usr&&sudo
./b2
install
»
дляустановкиостальныхбиблиотек;
е) команду «wgethttp://ftp.gnu.org/gnu/autoconf/autoconf-2.68.tar.bz2 &&tar
--bzip2
-xfautoconf-2.68.tar.bz2
&&cdautoconf-2.68/
&&
./configure&&make&&sudomakeinstall» дляустановкипрограммыautoconf;
ж) если подключение к Интернету происходит через прокси-сервер, то
через «gitclone» скачиваться не будет:
1) способ, когда подключение к Интернету без прокси сервера.
Команду
«gitclonehttp://github.com/noxrepo/nox&&cdnox&&
./boot.sh&&mkdirbuild&&cdbuild&& ../configure&&make» для скачивания и
компиляции исходного кода контроллера NOX;
2) способ, когда подключение к Интернету через прокси-сервер.
Команду
«sudo
apt-get
install
unzip
&&
wget
88
http://github.com/noxrepo/nox/archive/verity.zip && unzip verity.zip && mv noxverity nox && cd nox && ./boot.sh && mkdir build && cd build && ../configure
&& make»
После компиляции запуск контроллера осуществляется командой
«./src/nox_core –iptcp:6633 switch», при этом запускается только приложение
«switch». При прототипировании лучше использовать приложение «pyswitch»,
написанное на языке python и не требующее перекомпиляции. Некоторые
аргументы запуска NOX: «-t» –количество потоков; «-d» –запуск в фоновом
режиме; «-v» –выводить информацию о подключении на экране.
Если контроллер запущен в фоновом режиме, то по окончанию работы
его нужно остановить выполнив команды:
а) ps –ax|grep nox;
б) kill -9 «id».
КонтроллерFloodlight. Floodlight написан на Java и, следовательно,
работает в JVM. Перед установкой контроллера сначала потребуется
установить, необходимые для работы, библиотеки:
а) JDK (JavaDevelopmentKit) – бесплатно распространяемый компанией
OracleCorporation (ранее SunMicrosystems) комплект разработчика приложений
на языке Java, включающий в себя компилятор Java (javac), стандартные
библиотеки классов Java, примеры, документацию, различные утилиты и
исполнительную систему Java (JRE);
б) Ant – утилита для автоматизации процесса сборки программного
продукта, является платформонезависимым аналогом утилиты make.
Для установки контроллера необходимо выполнить следующие команды:
а) команду «sudo apt-get install build-essential default-jdk ant python-dev
git», с помощью этой команды устанавливаем необходимые библиотеки и
утилиты;
б) команду «git clone git://github.com/floodlight/floodlight.git && cd
floodlight && ant», для загрузки ветки из git, и выполнения сборки проекта.
Результатом сборки стал исполняемый jar файл floodlight.jar. Запустить
контроллер можно командой «java -jartarget/floodlight.jar».
5.4 Тестирование работоспособности
конфигурируемой сети
программно-
Для проверки работоспособности программно-конфигурируемой сети
необходимо сначала запустить контроллер, затем систему mininet с указанием
адреса контроллера и типа контроллера «remote» командой «sudo mn -topo=linear,3 --mac --controller remote --ip=192.168.56.1». Эта команда создаст
виртуальную сеть из трех коммутаторов и трех узлов. Коммутаторы включены
последовательно. При правильной настройке команда «pingall» должна
выполниться с результатом, как показано на рисунке 5.13.
89
Рисунок 5.13 – Результат выполнения команды «pingall»
Самым доступным способом реализовать OpenFlow коммутатор являются
альтернативные прошивки OpenWRT для бытовых маршрутизаторов. На сайте
http://www.openflow.org/wp/openwrt/ можно получить последнюю версию
программного обеспечения для рзличных аппаратных платформ или
скомпилировать свою версию из исходного кода. После смены ПО на
маршрутизаторе необходимо настроить протокол OpenFlow в соответствии с
рисунком 5.14, где 192.168.1.102 – адрес контроллера.
Рисунок 5.14 – Настройка OpenFlow на OpenWRT
Настройка OpenFlow на коммутаторах существенно отличается.
Коммутатор обрабатывает пакеты в каждой виртуальной сети VLAN отдельно в
соответствии с настройками, для включения OpenFlow одна сеть VLAN должна
иметь IP адрес и должна быть возможность коммуникации между этой сетью и
контроллером. Остальные VLAN можно использовать как OpenFlow сети.
На коммататорах HPProcurve для этого необходимо выполнить команду
«openflow номер_vlan controller tcp:адрес:порт», где «номер_vlan» – это номер
той сети, которая будет под управлением OpenFlow, «адрес:порт» – адрес
контроллера. В таблице 5.6 показаны основные команды настройки таких
коммутаторов
Таблица 5.6 – Команды настройки коммутаторов HP
Команда
Описание
Включает и выключает OpenFlow в
сети «vlan_id»
Задает таймаут «backoff»
соединения с сервером в сети
«vlan_id»
openflow<vlan_id> {enable/disable}
openflow<vlan_id>backoff <backoff>
90
Продолжение таблицы 5.6
Команда
Описание
openflow sw-rate <rate>
openflow hw-rate <rate>
openflow <vlan_id> listener ptcp:<tcp_port>
Задает предел производительности
при обработке пакетов в
программном режиме
Задает предел производительности
при обработке пакетов в
аппаратном режиме
Задает возможность удаленного
управления коммутатором при
помощи команды dpctl в сети
«vlan_id»
Коммутаторы HP не имеют встроенных средств управления записями
OpenFlow, для этого необходимо использовать команду «dpctl» на контроллере.
Коммутаторы NEC имеют другую команду для включения OpenFlow на
VLAN «setvsi номер_vlan список_портов tcp адрес:порт», где «список_портов»
– это перечисленные через запятую без пробелов номера портов для работы в
OpenFlow.
91
Список использованных источников
1 Смелянский, Р.Л. Проблемы современных компьютерных сетей / Р.Л.
Смелянский [Текст] // Труды XIX Всероссийской научно-методической
конференции «Телематика 2012». — СПб : СПБГУИТМО, 2012. — Т. 1.
2 OFELIA: OpenFlowinEurope [Электронный ресурс] // Веб-сайт
организации "OFELIA". – Электрон.дан. — 2010.
Режим доступа:
http://www.fp7-ofelia.eu/. Загл. с экрана. (Дата обращения: 01.08.2012)
3 Виртуализация [Электронный ресурс] // Википедия.  Электрон.дан.
— 2012.  Режим доступа :http://ru.wikipedia.org/wiki/Виртуализация.  Загл. с
экрана.  (Дата обращения: 21.08.2012)
4 Олифер, Н.А. Средства анализа и оптимизации сетей [Электронный
ресурс] / Олифер Н.А. , Олифер В.Г. // citforum.ru.  Электрон.дан. — 2008.
Режим доступа :http://citforum.ru/nets/spsmp/spsmpred_24.shtml.  Загл. с
экрана.  (Дата обращения: 27.07.2012)
5 Тарасов, В. Н. Анализ производительности компьютерных сетей на
основе аппроксимационного подхода / В. Н. Тарасов, Н. Ф. Бахарева. —
Свидетельство о гос. регистрации программы для ЭВМ № 2010613539,
Роспатент, М., 28.05.2010 .
6 IEEE is the world's largest professional association for the advancement of
technology [Электронныйресурс] // Сайтинститута IEEE. Электрон.дан. —
2012.  Режим доступа :http://www.ieee.org/index.html.  Загл. с экрана. 
(Дата обращения: 04.08.2012)
7 Fibre Channel [Электронный ресурс] // Википедия.  Электрон.дан. —
2012.  Режим доступа :http://ru.wikipedia.org/wiki/Fibre_Channel.  Загл. с
экрана.  (Дата обращения: 12.07.2012)
8 InfiniBand [Электронный ресурс] // Википедия.  Электрон.дан. —
2012.  Режим доступа :http://ru.wikipedia.org/wiki/InfiniBand.  Загл. с экрана.
 (Дата обращения: 12.07.2012)
9 Storage area network. [Электронный ресурс] // Википедия. 
Электрон.дан.
—
2012.
Режим
доступа
:
http://en.wikipedia.org/wiki/Storage_area_network.  Загл. с экрана.  (Дата
обращения: 12.07.2012)
10 iSCSI [Электронный ресурс] // Википедия.  Электрон.дан. — 2012.
 Режим доступа :http://en.wikipedia.org/wiki/ISCSI.  Загл. с экрана.  (Дата
обращения: 12.07.2012)
11 Липпит, М. Технология FCoE [Электронный ресурс] / М. Липпит,
Э. Смит, Э. Пейн, М. А. Де Кастро // Веб-сайт fcoe.ru.  Электрон.дан. — 2011.
 Режим доступа :http://www.fcoe.ru/russian/fcoe-tehnology.  Загл. с экрана.
 (Дата обращения: 04.08.2012)
12 ISOIEC 7498-4 [Электронныйресурс] // Веб-сайторганизации
"InternationalElectrotechnicalCommission". Электрон.дан. — 1999.  Режим
92
доступа: http://webstore.iec.ch/preview/info_isoiec7498-4%7Bed1.0%7Den.pdf. 
Загл. с экрана.  (Дата обращения: 01.08.2012)
13 High-Performance Computing Cluster [Электронныйресурс] // Wikipedia.
Электрон.дан. — 2011.  Режим доступа :http://en.wikipedia.org/wiki/HPCC.
 Загл. с экрана.  (Дата обращения: 12.08.2012)
14 IEEE 802.1 DataCenterBridging [Электронныйресурс] // Сайтcisco.com.
Электрон.дан.
—
2011.

Режим
доступа
:http://www.cisco.com/en/US/netsol/ns783/index.html.  Загл. с экрана.  (Дата
обращения: 15.07.2012)
15 802.1Qbb - Priority-based Flow Control [Электронныйресурс] // IEEE
802 LAN/MAN Standards Committee. Электрон.дан. — 2011. Режим доступа
:http://www.ieee802.org/1/pages/802.1bb.html.  Загл. с экрана.  (Дата
обращения: 21.07.2012)
16 802.1Qaz - Enhanced Transmission Selection [Электронныйресурс] //
IEEE 802 LAN/MAN Standards Committee. Электрон.дан. — 2011. Режим
доступа :http://www.ieee802.org/1/pages/802.1az.html.  Загл. с экрана.  (Дата
обращения: 11.08.2012)
17 802.1Qau - CongestionNotification [Электронныйресурс] // IEEE 802
LAN/MANStandardsCommittee. Электрон.дан. — 2011. Режим доступа
:http://www.ieee802.org/1/pages/802.1au.html.  Загл. с экрана.  (Дата
обращения: 24.08.2012)
18 Ling, J. Virtual output queue (VoQ) management method and apparatus /
J. Ling, J. C. Calderon, J. M. Caia, A. T. Huang, V. Joshi // US7295564 : Патент. —
USA, 13.11.2007.
19 Технология Brocade Virtual Cluster Switching [Электронныйресурс] //
Веб-сайткомпании Brocade. Электрон.дан. — 2012. Режим доступа :
http://brocade.ocs.ru/-vcs.  Загл. с экрана.  (Дата обращения: 21.07.2012)
20 Башилов, Г. Программно-аппаратная идиллия или OpenFlow /
Г. Башилов // Журнал сетевых решений/LAN. — Москва : Открытые системы,
2011. — c. 9.
21 Intro to OpenFlow [Электронныйресурс] // Open Networking Foundation.
Электрон.дан.
—
2011.
Режим
доступа
:
https://www.opennetworking.org/standards/intro-to-openflow.  Загл. с экрана. 
(Дата обращения: 15.07.2012)
22 Концепция организации локальных сетей [Электронный ресурс] //
hisd.ru.

Электрон.дан.
—
2008.
Режим
доступа
:
http://hisd.ru/konzep/lok43.htm.  Загл. с экрана.  (Дата обращения:
15.07.2012)
23 Иваненко, С. Введение в SNMP [Электронный ресурс] // citforum.ru.

Электрон.дан.
—
2012.
Режим
доступа
:http://citforum.ru/internet/articles/art_11.shtml.  Загл. с экрана.  (Дата
обращения: 21.07.2012)
93
24 ManagementInformationBase [Электронный ресурс] // Википедия.
Электрон.
дан.
—
2009.
Режим
доступа
:http://ru.wikipedia.org/wiki/Management_Information_Base.  Загл. с экрана. 
(Дата обращения: 23.08.2012)
25 Олифер, Н. А. Основы сетей передачи данных[Текст] / Н. А. Олифер,
В. Г. Олифер. — Интернет-Университет информационных технологий, 2003.
— 246 c.
26 Вишневский,
В. М.
Теоретические
основы
проектирования
компьютерных сетей. / В. М. Вишневский. – Москва : Техносфера, 2003. — 512
c.
27 Бахарева, Н. Ф. Моделирование трафика в компьютерных сетях с
помощью потоков событий / Н. Ф. Бахарева // Известия ВУЗов.
Приборостроение. — 2010. — Т. 53, 12. — C. 13-22.
28 Тарасов, В. Н. Компьютерное моделирование вычислительных
систем. Теория, алгоритмы, программы / В. Н. Тарасов, Н. Ф. Бахарева,
А. Л. Коннов. — Оренбург : ИПК ОГУ, 2004. — 183 c.
29 Тарасов, В. Н. Анализ производительности компьютерных сетей на
основе аппроксимационного подхода / В. Н. Тарасов, Н. Ф. Бахарева. —
Свидетельство о гос. регистрации программы для ЭВМ № 2010613539,
Роспатент, М., 28.05.2010 .
30 Yap, K.K. TheStanfordOpenRoadsDeployment [Электронный ресурс] /
K. K. Yap, M. Kobayashi, D. Underhill // Сайт Стенфордского университета. 
Электрон.дан.
—
2009.
Режим
доступа
:
http://www.stanford.edu/~seethara/papers/wintech09.pdf.  Загл. с экрана. 
(Дата обращения: 31.07.2012)
31 Trema readme [Электронныйресурс] // Trema - OpenFlow controller
framework.
Электрон.дан.
—
2012.

Режим
доступа
:https://github.com/trema/trema/blob/develop/README.md.  Загл. с экрана. 
(Дата обращения: 24.07.2012)
32 Chen, S. Nahrstedt K. An Overview of Quality of Service Routing for
Next-Generation High-Speed Networks: Problems and Solutions / S. Chen, K.
Nahrstedt // IEEE Network. — IEEE Network, 1998. — с. 64-79.
33 Клейнрок, Л. Теория массового обслуживания / Л. Клейнрок. —
Москва : Машиностроение, 1979.  432 с.
34 Подворный, П.В. Качество обслуживания абонентов при
беспроводном доступе в телекоммуникационных сетях железнодорожного
транспорта: дис. канд. техн. наук / П. В. Подворный. — Москва, 2006. — 132 с.
35 Цыбаков, В.И. Разработка и исследование метода расчета качества
обслуживания
пользователей
широкополосной
интегрированной
мультисервисной корпоративной сети : дис. канд. техн. наук / В. И. Цыбаков. —
Москва, 2005. — 174 с.
36 Kontesidou, G. OpenFlow Virtual Networking: A Flow-Based Network
Virtualization Architecture / G. Kontesidou, K. Zarifis. — Sweden : Master of
Science Thesis Stockholm, 2009. — 79 c.
94
37 Березко, М. П. Информационные процессы: Математические модели
исследования алгоритмов маршрутизации в сетях передачи данных / М. П.
Березко, В. М. Вишневский. — Москва: Институт проблем передачи
информации, 2001. — Т. 1.  120c.
38 Gail, R. Queueing Systems: Problems and Solutions / R. Gail, L.
Kleinrock. — John Wiley and Sons, 1996. – 413 c.
39 Pournaghshband, V. Controlling Applications by Managing Network
Characteristics / V. Pournaghshband, L. Kleinrock, P. Reiher, A. Afanasyev //
Proceedings of IEEE ICC 2012 Communication and Information Systems Security
Symposium. — 2012
40 QoS without Context: Good for the Network, Not So Good for the End user
[Электронныйресурс] // Сайт devcentral. — Электрон. дан. – 2012. Режим
доступа
:
https://devcentral.f5.com/weblogs/macvittie/archive/2012/06/06/qoswithout-context-good-for-the-network-not-so-good.aspx. – Загл. с экрана. - (Дата
обращения: 13.08.2012)
41 Kim, W. Automated and Scalable QoS Control for Network Convergence /
W. Kim, P. Sharma, J. Lee, S. Banerjee, J. Tourrilhes, S. J. Lee, P. Yalagandula. —
Princeton University, 2011. 435 c.
42 Junos [Электронный ресурс] // Wikipedia.  Электрон.дан — 2012. 
Режим доступа: http://en.wikipedia.org/wiki/Junos.  Загл. с экрана.  (Дата
обращения 24.07.2012)
43 Cisco IOS [Электронный ресурс] // Wikipedia.  Электрон.дан. —
2012.  Режим доступа: http://ru.wikipedia.org/wiki/Cisco_IOS.  Загл. с экрана.
 (Дата обращения 12.08.2012)
44 Release Notes for Cisco IOS Release 15.2S [Электронныйресурс] //
Cisco.com.
Электрон.дан.
—
2012.

Режим
доступа
:http://www.cisco.com/en/US/docs/ios/15_2s/release/notes/152SRN.pdf.  Загл. с
экрана.  (Дата обращения 14.07.2012)
45 ZyNOS [Электронный ресурс] // Wikipedia.  Электрон.дан. — 2012.
 Режим доступа :http://en.wikipedia.org/wiki/ZyNOS.  Загл. с экрана. 
(Дата обращения 08.07.2012)
46 OpenWRT
Linux
distribution
for
embedded
devices
[Электронныйресурс] // OpenWRT. Электрон.дан. — 2012.  Режим доступа
:http://kamikaze.openwrt.org/docs/openwrt.html.  Загл. с экрана.  (Дата
обращения 15.07.2012)
47 FreeWRT [Электронный ресурс] // Wikipedia.  Электрон.дан. —
2012.  Режим доступ а: http://ru.wikipedia.org/wiki/FreeWRT.  Загл. с экрана.
 (Дата обращения 13.08.2012)
48 OpenFlow [Электронный ресурс] // Wikipedia.  Электрон.дан. —
2012.  Режим доступа :http://en.wikipedia.org/wiki/OpenFlow.  Загл. с экрана.
 (Дата обращения: 21.07.2012)
95
49 NOX-Classicwiki [Электронныйресурс] // NOXNetworkControlPlatform.
Электрон.дан. — 2012.  Режим доступа :https://github.com/noxrepo/noxclassic/wiki.  Загл. с экрана.  (Дата обращения: 04.08.2012)
50 Using and Programming Maestro [Электронныйресурс] // A scalable
control platform writen in Java which supports OpenFlow switches.
Электрон.дан.
—
2012.

Режим
доступа
:http://maestroplatform.googlecode.com/files/programming.pdf.  Загл. с экрана.  (Дата
обращения: 09.08.2012)
51 Erickson, D. What is Beacon? [Электронный ресурс] / D. Erickson //
Beaconhome.
 Электрон. дан. —
2012.  Режим доступа :https://openflow.stanford.edu/display/Beacon/Home. 
Загл. с экрана.  (Дата обращения: 15.07.2012)
52 Trema readme [Электронныйресурс] // Trema - OpenFlow controller
framework.
Электрон.дан.
—
2012.

Режим
доступа
:https://github.com/trema/trema/blob/develop/README.md.  Загл. с экрана. 
(Дата обращения: 24.07.2012)
53 Simple Network Access Control (SNAC) [Электронныйресурс] // Open
Networking Foundation. Электрон.дан.
— 2012. Режим доступа
:http://www.openflow.org/wp/snac/.  Загл. с экрана.  (Дата обращения:
16.08.2012)
54 Cbench - benchmarkingtoolforcontrollers [Электронныйресурс] //
СайтCbench. — Электрон. дан. – 2013.
– Режим доступа:
https://github.com/andi-bigswitch/oflops/tree/master/cbench. – Загл. с экрана. –
(Дата обращения: 01.03.2013)
55 Перепелкин, Д.А. Разработка алгоритмов адаптивной маршрутизации
в корпоративных вычислительных сетях [Текст] / Д.А. Перепелкин, А.И.
Перепелкин // Вестник Рязанской государственной радиотехнической академии
–2006. – №19. – С. 114–116.
56 CiscoNexusPresentation[Электронный ресурс] // Сайт Cisco. —
Электрон.
дан.
–
2012.
–
Режим
доступа:
http://www.cisco.com/web/UA/training/events/pdf/nexus_metinvest_amarchen.pdf .
– Загл. с экрана. – (Дата обращения: 01.03.2013) , 2012
96
Приложение А
Пример использования контроллера ПКС
Для примера рассмотрим прототип модуля динамического обеспечения
QoS в сетях с централизованным программным обеспечением на основе
протокола OpenFlow версии 1.0.0 и выше. Такие сети отличаются
возможностью
задавать
правила
классификации
потоков
трафика
непосредственно на контроллере. Прототип представляет собой модуль,
подключаемый к контроллеру, получающий информацию о статистике
соединений, нагрузке на портах коммутаторов, существующую схему
обеспечения QoS. Данный модуль использует алгоритм Shortest Span First для
реализации оптимального перераспределения трафика, приоритетов,
гарантированных полос пропускания при добавлении нового потока данных с
заранее заданными требованиями по QoS.
Прототип реализован на базе стандартного модуля l2_learning
контроллера OpenFlow NOX и совместим с контролерами NOX, NOX-w/python.
Потоки, не прописанные по требованиям QoS, обрабатываются в контроллере
на общих основаниях и помещаются в коммутаторы в неприоритетные очереди
(с приоритетом 0 – best effort). Для управления заранее заданными значениями
QoS для каждого потока используется платформа Django, объектноориентированная СУБД sqlite3 и механизмы отображения объектов в таблицы
БД, реализованные на базе библиотек django. Для добавления и изменения
данных в прототипе используется веб-интерфейс «django administration panel»,
все действия проходят в ручном режиме.
Прототип работает под управлением операционной системы Ubuntu и
может использоваться для обеспечения QoS в центрах обработки данных с
заранее заданными высокоприоритетными потоками трафика, такими как
трафик СУБД, голосовой и мультимедиа трафик.
Программа написана на языке программирования Python.
Для функционирования модуля необходимо следующее программное
обеспечение сторонних разработчиков:
а) NOX (с установленными модулями topology, pyswitch, snmp) –
контроллер OpenFlow.
б) Django – платформа для веб-приложений с открытым программным
кодом на языке Python.
в) SQLite3 – объектно-ориентированная СУБД.
Программа предназначена для управления приоритетами vlan_pcp в
потоках трафика ПКС с целью обеспечения QoS.
В соответствии с
рисунком А.1 показана функциональная схема
программы.
97
Список потоков
Данные о потоках и
требованиях к ним
Взаимодействие с
оператором
СУБД
СУБД
Запоминаемые данные
из модуля topology
Пропускная
способность, задержка,
приоритет, максимально
доступная пропускна
способность
Построение полного графа
Структурная
схема
графа
Построение пути
Оптимальный
подграф
СУБД
Граф
Данные о длине
очередей
Данные о загрузках
интерфейсов
Расчет минимально
возможного приоритета для
обеспечения требуемого
диапазона задерки
Оптимальный
подграф
А
Рисунок А.1 – Функциональная схема программы
98
Список
минимально
возможных
приоритетов по
всему пути потока
Данные об ограничителях
скорости
А
Данныео загрузках портов
Проверка требований по
пропускной способности
потока на всем пути
следования
Сведения о
минимальной
остаточной
пропускной
способности
Оптимальный
подграф
Оптимальный
подграф
Список минимально
возможных
приоритетов по
всему пути потока
Список для каждого
коммутатора сведений
о потоке и
модификации полей
QoS
Формирование записей в
таблицу OpenFlow
Список для каждого
коммутатора
модификаций
очереди
Сведения о
минимальной
остаточной
пропускной
способности
БД
Запрос сведений о потоках из
БД
Пропускная способность,
задержка, приоритет,
максимально доступная
пропускная способность
Продолжение рисунка А.1
На основе топологии сети, требований по максимальной задержке и
минимальной пропускной способности происходит построение подграфа на
топологии. Используя размер очередей на портах в связях линейных
коммутаторов и значение средней задержки пакетов в очередях, направленным
ребрам графа можно присвоить составные веса, основывающиеся на
совокупности задержки и полосы пропускания. Далее в подграфе производится
расчет оптимального пути, а также расчет для каждого исходящего порта
минимально и максимально возможного приоритетов, при которых
обеспечивается задержка и пропускная способность. После выбора
оптимального сочетания приоритетов происходит установка правил для
каждого коммутатора.
Укрупненная схема алгоритма программы реализуется в соответствии с
рисунком А.2.
99
Начало
Входные
данные
- топология
- требования по максимальной задержке
- требования по минимальной полосе пропускания
- источник, приемник
Построение
подграфов на
топологии
Статистические
данные
-размер очередей на портах в
связях в линейных коммутаторах
-средняя задержка пакетов в
очередях
Присвоение
направленным
ребрам подграфа
составных весов
Расчет
оптимального
пути
Расчет минимально
и максимально
возможного
приоритета
На каждом исходящем порту расчет
минимально и максимально возможного
приоритета, при которых обеспечивается
задержка и пропускная способность
OSP
Выбор оптимального
сочетания
приортетов
Установка правил
Конец
Рисунок А.2 – Укрупненная схема алгоритма программы
Детальное описание принципа функционирования блока «Построение
подграфов на топологии» представлено в пункте 4.2. Схематическое описание
блока «Выбор оптимального сочетания приоритетов» осуществляется в
соответствии с рисунком А.3.
100
OSP
Начало
Входные
данные
D[f0] – максимальная задержка для расчетного потока
R[f0] – минимальная полоса пропускания для расчетного потока
R[fi] – минимальная полоса пропускания для остальных потоков
Q – приоритет расчетного потока, IP источника, IP Приемника
C – максимально доступная пропускная способностьспособность
Построение графа
i=1
S=0
A
i<length (Rf)
S=S+Rf[i]
i=i+1
A
Arf=C-S
Вычисление
остаточной
пропускной
способности
j=1
R[j:8]=S
Low[f0]=0
Hi[f0]=8
А
Рисунок А.3 – Алгоритм выбора оптимального сочетания приоритетов
101
А
Приоритет R[f0] > приоритета D[f0]?
нет
да
Route
Route
Расчет оптимального
пути
Расчет оптимального
пути
R[f0]<=Arf
нет
C
j<=Q
R[f0]=Rf[0]*0,95
да
B
j<=Q
Df=f(Q,R[j:8],C)
Df=f(Q,R[j:8],C)
Low[f0]=0
да
нет
нет
да
Low[f0]=0
да
Df>=D[f0]
да
Df>=D[f0]
Df<D[f0] И
Rf[0]<=R[Low:8]
нет
нет
да
Low[f0]=j
нет
Df<D[f0]
да
Low[f0]=j
R[j:8]=R[j:8]-R[fj]
нет
R[j:8]=R[j:8]-R[fj]
j=j+1
j=j+1
Hi[f0]=j
Hi[f0]=j
C
нет
B
Low[f0]=0
да
нет
Low[f0]=0
Hi[f0]=8
да
да
Df[0]=D[f0]*0,95
D[f0]=D[f0]*0,95
В
Продолжение рисунка А.3
102
нет
Low=Hi
R[f0]=R[Hi:8]
В
i=0
D
i<Количества
коммутаторов
Вычисление G[i],
INP[i], OUT[i]
Gi=Подграф пути (порты) с
коммутатором i
INPi=Входящие порты из Gi
OUTi=Исходящие порты из Gi
Match_Gi=Список портов из
INPi
Match_Gi=Match_Gi+ IP
адреса
Action_Gi=(Исходящий порт=OUTi)
Action_Gi = (Приоритет=Low)
i=i+1
D
OSP
Конец
Продолжение рисунка А.3
Сведения об очередях и загрузках периодически программой MRTG по
протоколу SNMP загружаются из коммутатора и помещаются в БД MRTG.
Коммутатор проверяет свою таблицу потоков, и если соответствующая запись
не обнаружена, то коммутатор посылает пакет в контроллер NOX. NOX
преобразует пакет в объекты, заполняет их и передает своим подключенным
модулям для коммутации (pyswitch). Модуль Pyswitch проверяет в
соответствующем списке наличие совпадений. Если совпадения найдены, то
соответствующие записи OpenFlow передаются коммутатору, иначе
направляется запрос в модуль QoS, который посылает запрос о наличии
соответствующей записи в БД интерфейса управления системой. Если запись
не найдена, то управление передается pyswitcg, который просто выполняет
коммутацию. Если же запись существует, то модуль QoS вызывает алгоритм
нахождения оптимальных параметров. На выходе получается набор правил для
каждого коммутатора в топологии. Эти правила передаются в модуль pyswitch,
который устанавливает их во все доступные коммутаторы.
103
Для вызова программы необходимо скопировать файл прототипа модуля
QoS в папку nox/src/nox/netapps/qos. Туда же необходимо скопировать файлы
makefile.am и meta.json из папки nox/src/nox/apps/examples. Затем в файле
nox/configure.ac.in необходимо найти строку «ACI_PACKAGE([netapps],» и
добавить в конец имя модуля «qos,» (запятую ставить обязательно). Затем в
папке nox необходимо выполнить команду gmake&&make.
Для запуска nox с модулем qos необходимо перйти в папку nox/src и
выполнить команду «./nox_core –v –iptcp:6633 qospyswitchtopology».
Новый класс обработчика пакетов OpenFlowl2-multy регистрируется в
классе core модуля OpenFlow. Входным методом из NOX в модуль qos является
метод ConnectionUp, возникающий при подключении нового коммутатора.
Обработчик пакетов направлен на стандартный метод packetIn класса Switch.
Входными данными для программы является информация из БД, которую
модуль объектно-реляционного отображения (ORM) преобразует в классы и
семейства классов, сведения из OpenFlow, которые NOX преобразует в
объектную модель, а также входные данные OpenFlow.
Выходными данными являются объекты OFP-match и OFP-action,
представленныев виде текстовой строки.
104
Приложение Б
Исходный код прототипа обеспечения QoS в ПКС
/* Название: Прототип средства обеспечения QoS в программно-конфигурируемых
сетях
*/
from django.core.management import setup_environ
from mysite import settings
setup_environ(settings)
from flew.models import Flow
from nox.core import core
import nox.openflow.libopenflow_01 as of
from nox.lib.revent import *
from collections import defaultdict
from nox.openflow.discovery import Discovery
from nox.lib.util import dpidToStr
import time
log = core.getLogger()
# Adjacency map. [sw1][sw2] -> port from sw1 to sw2
adjacency = defaultdict(lambda:defaultdict(lambda:None))
# Switches we know of. [dpid] -> Switch
switches = {}
# ethaddr -> (switch, port)
mac_map = {}
# [sw1][sw2] -> (distance, intermediate)
path_map = defaultdict(lambda:defaultdict(lambda:(None,None)))
FLOOD_HOLDDOWN = 5
def _calc_paths ():
"""
Essentially Floyd-Warshall algorithm
"""
sws = switches.values()
path_map.clear()
for k in sws:
for j,port in adjacency[k].iteritems():
if port is None: continue
path_map[k][j] = (1,None)
path_map[k][k] = (0,None) # промежуточное расстояние
"""
for i in sws:
105
for j in sws:
a = path_map[i][j][0]
if a is None: a = "*"
print a,
print
"""
for k in sws:
for i in sws:
for j in sws:
if path_map[i][k][0] is not None:
if path_map[k][j][0] is not None:
ikj_dist = path_map[i][k][0]+path_map[k][j][0]
if path_map[i][j][0] is None or ikj_dist < path_map[i][j][0]:
path_map[i][j] = (ikj_dist, k)
"""
print "--------------------"
for i in sws:
for j in sws:
print path_map[i][j][0],
print
"""
def _get_raw_path (src, dst):
if len(path_map) == 0: _calc_paths()
if src is dst:
# We're here!
return []
if path_map[src][dst][0] is None:
return None
intermediate = path_map[src][dst][1]
if intermediate is None:
# непосредственносвязаны
return []
return _get_raw_path(src, intermediate) + [intermediate] + \
_get_raw_path(intermediate, dst)
def _check_path (p):
for i in range(len(p) - 1):
if adjacency[p[i][0]][p[i+1][0]] != p[i][1]:
return False
return True
def _get_path (src, dst, final_port):
if src == dst:
path = [src]
else:
path = _get_raw_path(src, dst)
if path is None: return None
path = [src] + path + [dst]
r = []
for s1,s2 in zip(path[:-1],path[1:]):
port = adjacency[s1][s2]
106
r.append((s1,port))
r.append((dst, final_port))
assert _check_path(r)
return r
class PathInstalled (Event):
"""
Fired when a path is installed
"""
def __init__ (self, path):
Event.__init__(self)
self.path = path
class Switch (EventMixin):
def __init__ (self):
self.connection = None
self.ports = None
self.dpid = None
self._listeners = None
self._connected_at = None
for flow in Flow.objects.all():
self._AddFlowFromModel(flow)
def _AddFlowFromModel(self, flow):
# Добавление исходящего потока
msg = of.ofp_flow_mod()
msg.match = of.ofp_match()
msg.match.dl_type = ethernet.IP_TYPE
msg.match.nw_src = str(flow.internalip)
msg.match.nw_dst = str(flow.externalip)
msg.match.in_port = flow.internalport
msg.idle_timeout = flow.idletime
msg.hard_timeout = flow.hardtime
msg.actions.append(of.ofp_action_output(port = flow.externalport))
self.connection.send(msg)
# Добавление входящего потока
msg = of.ofp_flow_mod()
msg.match = of.ofp_match()
msg.match.dl_type = ethernet.IP_TYPE
msg.match.nw_src = str(flow.externalip)
msg.match.nw_dst = str(flow.internalip)
msg.match.in_port = flow.externalport
msg.idle_timeout = flow.idletime
msg.hard_timeout = flow.hardtime
msg.actions.append(of.ofp_action_output(port = flow.internalport))
self.connection.send(msg)
def __repr__ (self):
return dpidToStr(self.dpid)
107
def _install (self, switch, port, match, buf = None, pcp=None):
msg = of.ofp_flow_mod()
msg.match = match
msg.idle_timeout = 10
msg.hard_timeout = 30
msg.actions.append(of.ofp_action_output(port = port))
msg.buffer_id = buf
switch.connection.send(msg)
def _install_path (self, p, match, buffer_id = None):
for sw,port in p[1:]:
self._install(sw, port, match)
self._install(p[0][0], p[0][1], match, buffer_id)
core.l2_multi.raiseEvent(PathInstalled(p))
def install_path (self, dst_sw, last_port, match, event):#buffer_id, packet):
p = _get_path(self, dst_sw, last_port)
if p is None:
log.warning("Can't get from %s to %s", match.dl_src, match.dl_dst)
import nox.lib.packet as pkt
if (match.dl_type == pkt.ethernet.IP_TYPE and
event.parsed.find('ipv4')):
log.debug("Dest unreachable (%s -> %s)",
match.dl_src, match.dl_dst)
from nox.lib.addresses import EthAddr
e = pkt.ethernet()
e.src = EthAddr(dpidToStr(self.dpid))
e.dst = match.dl_src
e.type = e.IP_TYPE
ipp = pkt.ipv4()
ipp.protocol = ipp.ICMP_PROTOCOL
ipp.srcip = match.nw_dst
ipp.dstip = match.nw_src
icmp = pkt.icmp()
icmp.type = pkt.ICMP.TYPE_DEST_UNREACH
icmp.code = pkt.ICMP.CODE_UNREACH_HOST
orig_ip = event.parsed.find('ipv4')
d = orig_ip.pack()
d = d[:orig_ip.hl * 4 + 8]
import struct
d = struct.pack("!HH", 0,0) + d
icmp.payload = d
ipp.payload = icmp
e.payload = ipp
msg = of.ofp_packet_out()
108
msg.actions.append(of.ofp_action_output(port = event.port))
msg.data = e.pack()
self.connection.send(msg)
return
self._install_path(p, match, event.ofp.buffer_id)
log.debug("Installing path for %s -> %s %04x (%i hops)", match.dl_src, match.dl_dst,
match.dl_type, len(p))
def _handle_PacketIn (self, event):
def flood ():
""" Floods the packet """
if self.is_holding_down:
log.warning("Not flooding -- holddown active")
msg = of.ofp_packet_out()
msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD))
msg.buffer_id = event.ofp.buffer_id
msg.in_port = event.port
self.connection.send(msg)
def drop ():
# Очисткабуфера
if event.ofp.buffer_id is not None:
msg = of.ofp_packet_out()
msg.buffer_id = event.ofp.buffer_id
event.ofp.buffer_id = None # Меткаобнуляется
msg.in_port = event.port
self.connection.send(msg)
packet = event.parsed
loc = (self, event.port)
oldloc = mac_map.get(packet.src)
if packet.effective_ethertype == packet.LLDP_TYPE:
drop()
return
if oldloc is None:
if packet.src.isMulticast() == False:
mac_map[packet.src] = loc # Learn position for ethaddr
log.debug("Learned %s at %s.%i", packet.src, loc[0], loc[1])
elif oldloc != loc:
if loc[1] not in adjacency[loc[0]].values():
log.debug("%s moved from %s.%i to %s.%i?", packet.src,
dpidToStr(oldloc[0].connection.dpid), oldloc[1],
dpidToStr( loc[0].connection.dpid), loc[1])
if packet.src.isMulticast() == False:
mac_map[packet.src] = loc # Learn position for ethaddr
log.debug("Learned %s at %s.%i", packet.src, loc[0], loc[1])
elif packet.dst.isMulticast() == False:
log.warning("Packet from %s arrived at %s.%i without flow",# -- dropping",
109
packet.src, dpidToStr(self.dpid), event.port)
if packet.dst.isMulticast():
log.debug("Flood multicast from %s", packet.src)
flood()
else:
if packet.dst not in mac_map:
log.debug("%s unknown -- flooding" % (packet.dst,))
flood()
else:
dest = mac_map[packet.dst]
match = of.ofp_match.from_packet(packet)
self.install_path(dest[0], dest[1], match, event)
def disconnect (self):
if self.connection is not None:
log.debug("Disconnect %s" % (self.connection,))
self.connection.removeListeners(self._listeners)
self.connection = None
self._listeners = None
def connect (self, connection):
if self.dpid is None:
self.dpid = connection.dpid
assert self.dpid == connection.dpid
if self.ports is None:
self.ports = connection.features.ports
self.disconnect()
log.debug("Connect %s" % (connection,))
self.connection = connection
self._listeners = self.listenTo(connection)
self._connected_at = time.time()
@property
def is_holding_down (self):
if self._connected_at is None: return True
if time.time() - self._connected_at > FLOOD_HOLDDOWN:
return False
return True
def _handle_ConnectionDown (self, event):
self.disconnect()
pass
class l2_multi (EventMixin):
_eventMixin_events = set([
PathInstalled,
])
def __init__ (self):
self.listenTo(core.openflow, priority=0)
self.listenTo(core.openflow_discovery)
def _handle_LinkEvent (self, event):
def flip (link):
return Discovery.Link(link[2],link[3], link[0],link[1])
l = event.link
110
sw1 = switches[l.dpid1]
sw2 = switches[l.dpid2]
# Валидация всех потоков и путей информации
clear = of.ofp_flow_mod(match=of.ofp_match(),command=of.OFPFC_DELETE)
for sw in switches.itervalues():
if sw.connection is None: continue
sw.connection.send(clear)
path_map.clear()
if event.removed:
if sw2 in adjacency[sw1]: del adjacency[sw1][sw2]
if sw1 in adjacency[sw2]: del adjacency[sw2][sw1]
for ll in core.openflow_discovery.adjacency:
if ll.dpid1 == l.dpid1 and ll.dpid2 == l.dpid2:
if flip(ll) in core.openflow_discovery.adjacency:
adjacency[sw1][sw2] = ll.port1
adjacency[sw2][sw1] = ll.port2
break
else:
if adjacency[sw1][sw2] is None:
if flip(l) in core.openflow_discovery.adjacency:
adjacency[sw1][sw2] = l.port1
adjacency[sw2][sw1] = l.port2
bad_macs = set()
for mac,(sw,port) in mac_map.iteritems():
if sw is sw1 and port == l.port1:
if mac not in bad_macs:
log.debug("Unlearned %s", mac)
bad_macs.add(mac)
if sw is sw2 and port == l.port2:
if mac not in bad_macs:
log.debug("Unlearned %s", mac)
bad_macs.add(mac)
for mac in bad_macs:
del mac_map[mac]
def _handle_ConnectionUp (self, event):
sw = switches.get(event.dpid)
if sw is None:
# Новыйкоммутатор
sw = Switch()
switches[event.dpid] = sw
sw.connect(event.connection)
else:
sw.connect(event.connection)
def launch ():
if 'openflow_discovery' not in core.components:
import nox.openflow.discovery as discovery
core.registerNew(discovery.Discovery)
core.registerNew(l2_multi)
111
Документ
Категория
Без категории
Просмотров
0
Размер файла
2 174 Кб
Теги
shuhman, programma, setej, konfiguriruemyh, osnovy, bahareva, ushakova
1/--страниц
Пожаловаться на содержимое документа