ОГЛАВЛЕНИЕ - psuti.ru · конфигурируемых сетей и...
TRANSCRIPT
2
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ .............................................................................................................. 5
1. АНАЛИЗ КОНЦЕПЦИИ ПРОГРАММНО-КОНФИГУРИРУЕМЫХ СЕТЕЙ
................................................................................................................................. 14
1.1 Архитектура систем коммутации пакетов. Плоскости управления и
данных в системах коммутации пакетов ......................................................... 14
1.2 Работы по стандартизации архитектуры программно-конфигурируемых
сетей ..................................................................................................................... 21
1.2.1 ONF TR-502 ............................................................................................ 21
1.2.2 ITU-T Y. 3300 ......................................................................................... 23
1.2.3 IRTF RFC 7426 ....................................................................................... 26
1.2.4 Области дальнейшей стандартизации ПКС и перспективы
исследований ................................................................................................... 29
1.3 Сетевые операционные системы программно-конфигурируемых сетей32
1.3.1 Архитектура сетевой операционной системы OpenDaylight ............ 33
1.3.2 OpenDaylight как распределенная сетевая операционная система ... 42
1.3.3 Коммерческие СОС на базе OpenDaylight .......................................... 49
1.4 Выводы и результаты .................................................................................. 54
2. АНАЛИЗ МНОГОЯДЕРНЫХ АППАРАТНЫХ ПЛАТФОРМ ПКС-
КОНТРОЛЛЕРОВ ................................................................................................. 55
2.1 Реализация параллелизма в современных центральных процессорах ... 55
2.2 Аппаратные платформы на базе процессоров Intel Xeon E3 и Xeon E5 58
2.3 Метрики параллельных вычислений ......................................................... 67
2.4 Закон Амдала ................................................................................................ 69
2.4.1 Модель ускорения многоядерных ЦП на основе закона Амдала для
многоядерных систем ..................................................................................... 70
3
2.4.2 Модель ускорения многоядерных ЦП с поддержкой Hyper-Threading
........................................................................................................................... 73
2.5 Выводы и результаты .................................................................................. 74
3. РАЗРАБОТКА МОДЕЛИ ЗАДЕРЖКИ ОБРАБОТКИ СЛУЖЕБНОГО
ТРАФИКА В ПРОГРАММНО-КОНФИГУРИРУЕМЫХ СЕТЯХ НА ОСНОВЕ
ПРОТОКОЛА OPENFLOW.................................................................................. 76
3.1 Протокол взаимодействия контроллера и коммутаторов программно-
конфигурируемой сети OpenFlow .................................................................... 76
3.2 OpenFlow-коммутатор ................................................................................. 85
3.3 Классификация задержек служебного трафика протокола ARP в
программно-конфигурируемых сетях .............................................................. 89
3.4 Среда моделирования Mininet .................................................................... 95
3.5 Экспериментальное установление алгоритма обработки ARP-запросов
.............................................................................................................................. 97
3.6 Экспериментальное выявление зависимости задержки передачи
служебного трафика от задержки контроллера .............................................. 99
3.7 Выводы и результаты ................................................................................ 102
4. ИССЛЕДОВАНИЕ МАСШТАБИРОВАНИЯ ЗАДЕРЖКИ ПКС-
КОНТРОЛЛЕРА НА АППАРАТНЫХ ПЛАТФОРМАХ С
МНОГОЯДЕРНЫМИ ЦЕНТРАЛЬНЫМИ ПРОЦЕССОРАМИ .................... 103
4.1 Разработка методики проведения тестирования..................................... 103
4.2 Анализ программного обеспечения для тестирования ПКС-контроллера
............................................................................................................................ 105
4.3 Экспериментальный стенд и методология исследования...................... 107
4.4 Экспериментальное сравнение масштабирования задержки ПКС-
контроллера на аппаратных платформах с ЦП Xeon E3 и Xeon E5 ........... 111
4
4.5 Экспериментальная апробация способа применения модели ускорения
многоядерных ЦП для оценки уровня задержки обработки служебного
трафика при масштабировании размера сети ............................................... 116
4.6 Выводы и результаты ................................................................................ 123
ЗАКЛЮЧЕНИЕ ................................................................................................... 126
ТЕРМИНЫ И АББРЕВИАТУРЫ ...................................................................... 128
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ ........................................... 131
ПРИЛОЖЕНИЕ А. Программа автоматизации тестирования контроллеров
программно-конфигурируемых сетей на базе протокола OpenFlow ............. 150
ПРИЛОЖЕНИЕ Б ................................................................................................ 155
Копия свидетельства о государственной регистрации программы для ЭВМ
............................................................................................................................... 155
ПРИЛОЖЕНИЕ В ............................................................................................... 156
Процедура установки и настройки СОС OpenDaylight ................................... 156
ПРИЛОЖЕНИЕ Г. Экспериментально измеренные задержки ПКС-
контроллера и рассчитанные на основе них значения ускорения,
эффективности и доли линейных операций ..................................................... 160
ПРИЛОЖЕНИЕ Д. Акты о внедрении результатов работы .......................... 168
5
ВВЕДЕНИЕ
Актуальность темы исследования. Все большее проникновение
информационных технологий в жизнь человеческого общества приводит к
проблеме постоянного роста передаваемого трафика в сети Интернет. Так, по
данным Министерства связи и массовых коммуникаций Российской
Федерации [46], в период с 2010 г. по 2016 г. объем услуги связи «Доступ к
сети Интернет» увеличился в пять раз и достиг цифры в 32470 Пбайт в год, что
показано на рисунке 1а.
Рисунок 1. а) Динамика увеличения объема переданного трафика в сети
Интернет (источник: Минкомсвязи РФ); б) Динамика роста ежемесячных
объемов трафика в глобальной сети (источник: Cisco VNI)
Кроме того, происходят изменения в поведении и предпочтениях
абонентов сетей. Согласно аналитической оценке Cisco VNI [64], растёт доля
трафика, генерируемого мобильными устройствами. К 2020 году объем
глобального трафика, ежемесячно генерируемого мобильными устройствами,
достигнет величины 30564 Пбайт на фоне 130758 Пбайт, создаваемых
устройствами с фиксированным проводным доступом, что показано на
рисунке 1б. Россия не отстает от глобальных тенденций: если в 2014 году один
мобильный абонент потреблял порядка 0,5 Гб трафика в месяц, то в 2016 году
эта цифра составляла уже 1,13 Гб, то есть за два года произошло удвоение
6
мобильного трафика на одного абонента [19]. Наблюдается и рост
потребления так называемого «тяжелого» контента, а именно видеотрафика.
Растущие объемы передаваемого трафика приводят к тому, что сети
становится динамическими и зачастую требуют быстрых реакций на
изменение их состояния. Этому препятствует высокая сложность управления
сетью ввиду наличия большого числа производителей оборудования, каждый
из которых разрабатывает собственную аппаратную платформу, команды
конфигурирования, а также проприетарные протоколы взаимодействия
устройств. В результате этапы проектирования и пуско-наладочных работ т.н.
мультивендорских сетей занимают довольно существенные временные
промежутки, поскольку требуется учитывать все особенности взаимодействия
устройств и протоколов. Подход же с построением сети на базе оборудования
одного производителя приводит к зависимости эксплуатирующей сеть
организации от производителя устройств.
Каждый сетевой узел поддерживает в актуальном состоянии
собственное локальное представление о сети с помощью специализированных
протоколов. Однако в случае необходимости изменения конфигурации сети
администратор лишен инструмента, предоставляющего глобальный взгляд на
сеть, и вынужден менять настройки каждого отдельного устройства.
Существующие протоколы, подобные SNMP и NetFlow, призваны решать
скорее задачи мониторинга, а не управления сетью.
Вышеперечисленные факторы делают сеть негибкой, неспособной
быстро меняться в зависимости от условий. Упростить управление сетью
могло бы наличие единого центра управления, позволяющего осуществлять
настройку политик безопасности, маршрутизации, качества обслуживания, а
также мониторинг параметров сетевых узлов. Идея подобной концепции была
предложена в 2006 году специалистами из университетов Стенфорда и Беркли
и получила название Software-Defined Networks (SDN), а в русскоязычной
среде устоялся термин программно-конфигурируемые сети (далее-ПКС). В
рамках данной концепции роль центра управления сетью выполняет
7
контроллер программно-конфигурируемой сети (далее-ПКС-контроллер),
представляющий собой программно-аппаратный комплекс, состоящий из
стандартного сервера с x86-совместимой архитектурой и сетевой
операционной системы. ПКС-контроллер осуществляет управление сетевыми
узлами с помощью стандартизированного протокола, наиболее
распространенным из которых является OpenFlow.
О преимуществах внедрения в эксплуатацию программно-
конфигурируемых сетей можно судить на основе опыта зарубежных телеком-
операторов и IT-компаний. В частности, Telecom Italia удалось сократить
эксплуатационные расходы, увеличить скорость развертывания новых услуг и
в целом повысить эффективность использования ресурсов
телекоммуникационной сети благодаря централизации управления ресурсами
[139].
Согласно опубликованному Правительством РФ в 2014 году перечню
приоритетных научных задач, исследования в области программно-
конфигурируемых сетей и виртуализации сетевых сервисов имеют ключевое
значение для социально-экономического развития страны [25]. В 2017 году
ПАО «Ростелеком» протестировал возможности мультивендорной
транспортной ПКС на базе оборудования Huawei, NEC и Nokia. Тестирование
показало, что внедрение ПКС позволяет значительно сократить время заказа,
настройки и активации сервисов с нескольких недель или месяцев до
нескольких часов. [36].
Степень разработанности темы. Исследовательской группой IMT-
2020 в рекомендации ITU-R M.2083-0 [82] определены требования к
разрабатываемой технологии сетей 5G и отмечается необходимость создания
гибкой сетевой инфраструктуры на основе ПКС. Кроме того, разработчиками
документа говорится о потребности понижения сетевой задержки «end-to-end»
в пределах одного сегмента сети до уровня 1 мс. Cогласно данным сайта Open
Signal [112], средняя задержка сетей 4G Германии колеблется от 37 мс до 49
мс, в то время как в Индии – от 66 мс до 79 мс. Таким образом, достижение
8
заданного уровня сетевой задержки является весьма серьезной научно-
технической задачей.
На сегодняшний день концепция программно-конфигурируемых сетей
имеет определенные недостатки, выявленные различными исследователями. В
частности, в работах Смелянского Р.Л., Шалимова А.В. [93, 51], Владыко А.Г.,
Киричка Р.В. [2], A Tootoonchian, R. Sherwood, S. Gorbunov, M. Casado, R.
Sherwood [144], O. Salman, I. H. Elhajj [132], Y. Zhao [150] рассмотрены
проблемы производительности ПКС-контроллеров и сделан ряд выводов:
-каждый ПКС-контроллер может осуществлять управление
ограниченным числом сетевых узлов;
-существенное влияние на производительность ПКС-контроллера как
программно-аппаратного комплекса оказывается язык программирования, на
котором написана сетевая операционная система (СОС).
При этом в указанных работах авторы были сфокусированы на таком
параметре производительности ПКС-контроллеров, как пропускная
способность (скорость обработки потоков): показаны зависимости этого
параметра производительности от числа коммутаторов в сети и количества
МАС-адресов в их памяти, числа ядер процессора. Однако касательно второго
ключевого параметра производительности – задержки ПКС-контроллера –
были осуществлены замеры только минимального, среднего и максимального
времени обработки OpenFlow-пакета. В работах Тарасова В.Н., Малахова С.В.
показано, что при отсутствии в коммутаторах правил обработки OpenFlow-
пакетов (реактивный режим работы) задержка в ПКС превосходит задержку в
традиционных сетях с коммутацией пакетов в 1,5 раз [23], а также что потери
пакетов растут с ростом задержки [24]. S. El-Geder в своем исследовании [71]
на примере контроллера под управлением СОС OpenDaylight показал, что при
отсутствии в коммутаторах правил обработки OpenFlow-пакетов круговая
задержка (RTT) и коэффициент потери пакетов (PLR) могут быть снижены в
3,3 и 3,1 раза соответственно для линейной топологии из 128 OpenFlow-
коммутаторов путем использования кластера ПКС-контроллеров.
9
Таким образом, можно сделать вывод, что в настоящее время
недостаточно исследовано влияние аппаратной многоядерной платформы
ПКС-контроллера на задержку обработки OpenFlow-пакетов.
Объектом исследования являются программно-конфигурируемые
сети.
Предметом исследования является задержка обработки OpenFlow-
пакетов контроллером программно-конфигурируемых сетей.
Цель и задачи исследования. Исследование задержки обработки
OpenFlow-пакетов ПКС-контроллером и выявление закономерностей
изменения данной задержки.
Для достижения поставленной цели требуется решение следующих
задач:
1. Провести анализ стандартов в области сетевых архитектур ПКС,
анализ архитектуры и технических спецификаций сетевой операционной
системы ПКС-контроллера.
2. Проанализировать модель ускорения многоядерных процессоров на
основе закона Амдала, определить границы её применимости, выявить
факторы, способные ограничивать рост ускорения.
3. Разработать модель задержки обработки служебного трафика
протокола OpenFlow.
4. Осуществить экспериментальное исследование задержки обработки
OpenFlow-пакетов ПКС-контроллером.
5. Разработать способ применения модели ускорения многоядерных
процессоров для оценки уровня задержки обработки служебного трафика при
изменении размера сети.
Научная новизна.
1. Показана возможность использования закона Амдала для описания
ускорения ПКС-контроллера на многоядерных ЦП.
2. Разработана модель задержки обработки служебного трафика
программно-конфигурируемых сетей на базе протокола OpenFlow для
10
обеспечения их эффективного функционирования. Выявлена зависимость
задержки обработки служебного трафика от задержки ПКС-контроллера.
3. Разработан способ определения числа ядер платформы ПКС-
контроллера, при котором рационально увеличение управляемого сегмента
сети.
4. Показано, что эффективность использования многоядерных
процессоров может быть увеличена путем использования технологии
логической многопоточности Hyper-Threading при достаточной сложности
вычислительной задачи.
Методы исследования. Для решения поставленных задач и достижения
поставленной цели использованы теория сетей связи, теория вычислительных
систем, методы математического и компьютерного моделирования
инфокоммуникационных сетей, а также программирования на языке высокого
уровня Python.
Основные положения, выносимые на защиту.
1. Модель оценки задержки обработки служебного трафика программно-
конфигурируемых сетей на базе протокола OpenFlow показала, что
количественное снижение данной задержки возможно за счет снижения
задержки, вносимой контролером.
2. Показано, что возможно использовать закон Амдала для описания
теоретической верхней границы ожидаемого ускорения на многоядерных
платформах при фиксированном размере сегмента управляемой сети.
3. Показано, что увеличение числа коммутаторов в управляемом
сегменте рационально в том случае, когда доля последовательных операций,
совершаемых многоядерным ЦП ПКС-контроллера, перестает убывать.
4. Показано, что способом повышения эффективности использования
многоядерных процессоров в ПКС-контроллере при достаточной сложности
вычислительной задачи является использование технологии логической
многопоточности Hyper-Threading.
11
Соответствие рассматриваемой специальности. Содержание
диссертационной работы соответствует следующим пунктам паспорта
специальности 05.12.13 – Системы, сети и устройства телекоммуникаций:
пункту 3 - Разработка эффективных путей развития и
совершенствования архитектуры сетей и систем телекоммуникаций и
входящих в них устройств.
пункту 4 - Исследование путей совершенствования управления
информационными потоками.
пункту 11 - Разработка научно-технических основ технологии создания
сетей, систем и устройств телекоммуникаций и обеспечения их эффективного
функционирования.
пункту 14 - Разработка методов исследования, моделирования и
проектирования сетей, систем и устройств телекоммуникаций.
Личный вклад. Основные научные результаты теоретических и
экспериментальных исследований, выводы, изложенные в диссертационной
работе, получены автором самостоятельно. Автору работы принадлежит
разработка программного средства автоматизации тестирования контроллеров
программно-конфигурируемых сетей на базе протокола OpenFlow.
Теоретическая и практическая значимость работы. Теоретическая
значимость работы заключается в предложении использования закона Амдала
для описания ускорения ПКС-контроллера на многоядерных ЦП и в
предложенной модели задержки обработки служебного трафика программно-
конфигурируемых сетей на базе протокола OpenFlow. Практическая
значимость работы состоит в разработке способа определения числа ядер ЦП
ПКС-контроллера, при котором рационально увеличение управляемого
сегмента сети и в доказательстве использования технологии Hyper-Threading
как способа увеличения эффективности использования многоядерных ЦП.
Степень достоверности полученных результатов. При проведении
экспериментальных исследований автор четко следовал указаниям
рекомендации IETF draft Benchmarking Methodology for SDN Controller
12
Performance. Для исключения человеческого фактора при обработке
результатов эксперимента было создано программное средство,
зарегистрированное Федеральной службой по интеллектуальной
собственности. Достоверность полученных результатов подтверждается
соответствием теоретических и экспериментальных исследований.
Апробация результатов. Основное содержание диссертационной
работы докладывалось и обсуждалось на XXII Международном форуме МАС
2018 «Экономика в условиях цифровой трансформации» (Международная
академия связи, г. Москва, 2018); Международной научно-технической
конференции "Пром-Инжиниринг 2017" (СПбПУ им. Петра Великого, г.
Санкт-Петербург, 2017); XX Всероссийской научно-технической
конференции «Современные проблемы радиоэлектроники» (СФУ, г.
Красноярск, 2017); VI,VII, IX Всероссийских научно-практических
конференциях «Проблемы передачи информации в инфокоммуникационных
системах» (ВолГУ, г. Волгоград, 2015, 2016, 2018), XXI научно-практической
конференции молодых ученых, аспирантов и студентов Национального
исследовательского Мордовского государственного университета им. Н.П.
Огарёва (г. Саранск, 2017).
Исследования, проводимые автором по теме диссертационной работы,
были удостоены II места на молодежном конкурсе инноваций и
инновационных проектов – Новое поколение 2016/2017, организованного
Международной общественной академией связи, Общественным советом при
Федеральном агентстве связи, Профсоюзом работников связи России.
Публикации. Содержание и результаты диссертационной работы
отражены в 14 опубликованных работах. Публикации включают в себя 5
статей в научных изданиях, рекомендованных ВАК, 1 статья, входящая в базы
WoS/Scopus/IEEEXplore, 6 трудов и тезисов докладов на Международных и
Всероссийских конференциях и форумах, 1 статья в журнале, индексируемом
в РИНЦ, 1 свидетельство о регистрации программы ЭВМ.
13
Структура и объём работы. Диссертационная работа изложена на 169
страницах текста и включает содержание, введение, четыре главы,
заключение, приложения, библиографический список из 150 наименований. В
приложениях к диссертации представлены код разработанной программы
автоматизации тестирования, свидетельство о регистрации программы для
ЭВМ, процедура установки и настройки сетевой операционной системы,
экспериментальные данные в табличном виде, акты о внедрении результатов
работы.
14
1. АНАЛИЗ КОНЦЕПЦИИ ПРОГРАММНО-
КОНФИГУРИРУЕМЫХ СЕТЕЙ
1.1 Архитектура систем коммутации пакетов. Плоскости
управления и данных в системах коммутации пакетов
Перед анализом концепции ПКС необходимо рассмотреть основные
принципы внутреннего устройства или архитектуры существующих систем
коммутации, осуществляющих прием, обработку и передачу сетевых пакетов.
Данные операции выполняются коммутаторами и маршрутизаторами,
реализующими при этом функциональность канального и сетевого уровней
модели OSI [9] соответственно.
Рисунок 2. Этапы обработки PDU
Рассмотрим общий случай обработки фрагмента данных или PDU на
сетевом коммутационном узле. Весь путь PDU делится на входной тракт и
выходной тракт. Первым делом после поступления PDU на входной тракт узла
осуществляется отделение заголовка, определяемого протоколом, от полезной
нагрузки или декапсуляция. Полезная нагрузка (PDU без заголовка) находится
в буфере в ожидании завершения анализа заголовка, осуществляемого с целью
определения дальнейшего пути PDU (или вообще его уничтожения, например,
в случае, если размер пакета отличается от определенного протоколом). После
завершения анализа, заголовок превращается в метаданные (или временный
заголовок) и присоединяется к полезной нагрузке, после чего подаётся на
входную очередь. Входная очередь необходима для избегания перегрузки
выходного тракта. PDU ждёт разрешение на продвижение в выходную
15
очередь. В том случае, если выходных трактов несколько, необходима
коммутационная фабрика, задачей которой является передача PDU на
требуемый выходной тракт. Выходной тракт так же имеет выходную очередь,
в которой PDU ожидает выходной обработки (например, применения политик
QoS) и формирования заголовков. Последним этапом осуществляется
присоединение заголовков к нагрузке или инкапсуляция, после чего PDU
готов к передаче.
Из рассмотренной процедуры обработки PDU чётко видно разделение
задач коммутационного узла на два различных класса:
анализ заголовков PDU с целью определения его дальнейшего
пути;
физическое продвижение PDU в соответствии с результатами
анализа его заголовка.
В связи с этим в архитектуре систем коммутации принято выделять [59,
95, 32, 56, 63] две плоскости, реализующих различный функционал сетевого
коммутационного узла: плоскость управления (control plane) и плоскость
данных (data plane). Плоскость управления реализует логику работы сетевого
устройства, определяя с помощью различных служебных протоколов
(например, ARP, STP, OSPF, RIP и др.) правила для дальнейшего продвижения
пакета данных. Для решения этой задачи могут использоваться достаточно
сложные алгоритмы, такие как алгоритм Дейкстры [70]. Далее определенные
с помощью специальных протоколов правила пересылки заносятся в таблицы.
Задача плоскости данных заключается в передаче полезного трафика через
сетевое устройство в соответствии с установленными правилами. Исходя из
особенностей решаемых каждой плоскостью задач, производители систем
коммутации достаточно давно [63] осознали, что разделение данных
плоскостей и реализация их на различных аппаратных компонентах позволит
повысить производительность.
Рассмотрим реализацию функционала плоскостей управления и данных
на примере коммутатора. Коммутатор - это сетевое устройство, выполняющее
16
фильтрацию и пересылку кадров данных на основе полей, содержащих адреса
канального уровня. Как известно [33, 49, 34], основными показателями
производительности коммутаторов наряду с пропускной способностью и
задержкой передачи кадра являются скорость фильтрации и скорость
продвижения кадров. Для того, чтобы коммутатор мог реализовывать
перечисленные операции на скорости порта (wire-speed), в устройствах
данного типа используются отдельные интегральные схемы специального
назначения ASIC (англ. application-specific integrated circuit). ASIC имеет
заранее предопределённый набор функций, которые выполняются аппаратно.
Алгоритм работы зашит в неё на этапе производства и не может быть изменён
в дальнейшем. ASIC выполняет однотипные рутинные операции, такие как
преобразование поступающих на физический порт электрических импульсов
в последовательность бит, подсчёт количества принятых и отправленных
кадров. Применение ASIC позволяет достигать достаточно высоких
показателей производительности коммутаторов. Коммутатор может иметь в
своем составе как одну, так и несколько микросхем ASIC, например, работу
каждых 12 портов контролирует собственная микросхема ASIC.
Программирование логики работы ASIC выполняет плоскость управления,
функционирующая на базе центрального процессора общего назначения.
Такая архитектура схематично изображена на рисунке 3. Примерами
коммутаторов, имеющих подобную архитектуру, могут быть Cisco Catalyst
2960/3650/3850 [32].
Рисунок 3. Плоскости управления и данных в архитектуре коммутатора
17
Стоит отметить, что если коммутатор обладает функционалом третьего
(сетевого) уровня OSI, т.е. способен маршрутизировать трафик между
подсетями, то его плоскость управления способна реализовывать более
широкий функционал, чем у коммутатора канального уровня.
В случае объединения нескольких физических коммутаторов в
логический стек фактически получается ситуация, при которой плоскость
управления главного коммутатора в стеке управляет несколькими
плоскостями данных ведомых коммутаторов. Команды плоскости управления
при этом пересылаются на ведомые коммутаторы через стековый канал связи,
как показано на рисунке 4, после чего плоскость данных каждого коммутатора
в стеке способна выполнять принятые инструкции и осуществлять пересылку
кадров данных. Создание стека коммутаторов позволяет несколько упростить
администрирование сетевого оборудования и повысить отказоустойчивость
сети.
Рисунок 4. Плоскости управления и данных в стеке коммутаторов
18
Маршрутизатор также обладает функционалом и плоскости управления,
и плоскости данных. Маршрутизатором называют сетевое устройство,
функционирующее на третьем (сетевом) уровне OSI, предназначенное для
объединения сетей и реализующее различные дополнительные сервисы, такие
как трансляцию адресов NAT, списки контроля доступа ACL, обнаружение
вторжений IDS. Отличительной особенностью маршрутизатора, показанной
на рисунке 5, является тот факт, что в нем функционал как плоскости
управления, так и плоскости данных выполняется на базе процессоров общего
назначения (при этом прочие ресурсы системы, такие как память, также
являются разделяемыми). В результате маршрутизатор, по сравнению с
коммутатором, является более гибким, функциональным и интеллектуальным
устройством, но обладающим меньшей производительностью [35].
Примерами устройств с такой архитектурой являются маршрутизаторы серий
Cisco 800, 1900, 2900.
Рисунок 5. Плоскости управления и данных в архитектуре маршрутизатора
Современные маршрутизаторы, такие как серия Cisco ISR 4400 [61], для
увеличения производительности снабжаются многоядерными процессорами,
при этом плоскости управления и данных могут выполняться на различных
процессорных ядрах. При разработке высокопроизводительных
маршрутизаторов, в тех случаях, когда возможностей многоядерных
процессоров общего назначения недостаточно, производители прибегают к
заимствованию элементов архитектуры коммутаторов, а именно
19
специализированных микросхем [59]. Однако в данном случае речь идет не об
использовании ASIC, обеспечивающих высокую производительность, но
слабую функциональность, а о применении особого класса микросхем –
сетевых процессоров (англ. Network Processor Unit - NPU). Одна из последних
разработок компании Cisco в этой области способна обеспечить пропускную
способность до 400 Гбит/с в полнодуплексном режиме [62].
Таким образом, плоскости управления и данных в современных
коммутационных узлах – это не только и не столько функциональные
абстракции. Эти плоскости физически реализуются на различной аппаратной
базе в рамках одного устройства. Подобное разделение позволило отвязать
передачу данных от работы протоколов и построения сети, что в результате
привело к значительному повышению масштабируемости и
отказоустойчивости.
Объединение функционала плоскостей управления и данных в одном
устройстве исторически вытекает из семи архитектурных принципов,
заложенных при разработке стека TCP/IP в ходе проекта ARPANET, активное
участие в котором принимало Управление перспективных исследовательских
проектов Министерства обороны США DARPA (англ. Defense Advanced
Research Projects Agency). Данные принципы в порядке убывания значимости
изложены Д. Кларком в [65]:
1. Отказоустойчивость – сеть должна продолжать функционировать
при потере какого-либо узла или сегмента;
2. Разнообразие сервисов коммуникации;
3. Архитектура Интернета должны быть способна объединять
различные сети;
4. Распределенное независимое управление сетевыми ресурсами;
5. Экономическая эффективность или рентабельность архитектуры;
6. Расширяемость и возможность простого подключения к сети;
7. Учет использования сетевых ресурсов.
20
Именно ставка на отказоустойчивость в силу интересов военного
ведомства привела к тому, что современные системы коммутации являются
устройствами с высокой степенью автономности, лишенные единого центра
управления. В результате каждое устройство имеет собственное локальное
представление о сети, которое поддерживает в актуальном состоянии,
обмениваясь информацией с соседними устройствами с помощью различных
служебных протоколов. Однако данный подход помимо достоинства в виде
отказоустойчивости имеет и ряд недостатков, к которым можно отнести
необходимость настройки каждой отдельной системы коммутации, наличие
различий в синтаксисе команд операционных систем
коммутаторов/маршрутизаторов различных производителей (Cisco IOS,
Juniper JunOS и др.), вероятные проблемы конфликтов оборудования
различных вендоров, использующих помимо открытых стандартизованных
протоколов еще и собственные проприетарные разработки. Для владельца
инфокоммуникационной инфраструктуры, в том числе для операторов связи,
это означает необходимость содержания в штате большого количества
персонала с разнообразной специализацией и квалификацией. При внедрении
какого-либо нового сетевого сервиса (развертывании услуги) зачастую
требуется интеграция в существующую инфраструктуру новых устройств
вместо морально и физически устаревшего эксплуатируемого оборудования, в
результате чего срок вывода новой услуги составляет недели и месяцы.
Причем из-за возрастающей сложности сетевых устройств растёт и их
стоимость, а значит увеличивается срок окупаемости нового оборудования,
что приводит к снижению доходов оператора. Попытка операторов развитых
европейских стран увеличить прибыль за счет роста абонентской базы в
современных условиях не приводит к ожидаемым результатам, т.к. степень
информатизации и предоставления абонентам услуг широкополосного
доступа к сети и так довольно высокая. В Российской Федерации же
существует другая особенность – географическая протяженность страны, и
хотя реализуемая программа устранения цифрового неравенства регионов
21
приносит свои плоды и увеличивает степень проникновения информационных
технологий в жизнь населения, но с точки зрения оператора сети задача
предоставления услуг связи даже в самые отдаленные уголки страны не
предоставляет большой прибыли. Таким образом, операторы связи находятся
в поисках новых моделей ведения бизнеса, которые, как ожидается, способна
предоставить концепция ПКС.
1.2 Работы по стандартизации архитектуры программно-
конфигурируемых сетей
1.2.1 ONF TR-502
Open Network Foundation – это молодая некоммерческая организация,
основанная в 2011 году компаниями Deutsche Telekom, Facebook, Google,
Microsoft, Verizon, и Yahoo! с целью развития концепции ПКС и разработки
открытых стандартов. По состоянию на 2017 год в состав организации входит
порядка 150 компаний, среди которых как крупнейшие телеком-операторы и
производители сетевого оборудования, так малые инновационные
предприятия – стартапы. ONF отвечает также за разработку программ
сертификации оборудования на соответствие стандартам.
ONF в июне 2014 года представила свое видение архитектуры
программно-конфигурируемых сетей в документе ONF TR-502: SDN
Architecture [103].
Рисунок 6. Архитектура ПКС по версии ONF
22
В соответствии с рисунком 6, ONF выделяют в архитектуре три
плоскости: данных (data plane), управления (control plane) и приложений
(application). Плоскости данных и управления связаны с помощью интерфейса
D-CPI (Data-Control Plane Interface), плоскости приложений и управления –
интерфейсом A-CPI (Application-Control Plane Interface). Особенностью
данной архитектуры является выделение функций менеджмента в отдельный
компонент, расположенный поперёк трех плоскостей. Это связано с тем, что
каждая плоскость содержит некоторый собственный набор функций
менеджмента. Например, к функциям менеджмента плоскости данных можно
отнести первичную конфигурацию сетевого узла и назначение ему
контроллера, плоскости управления – определение подконтрольных сегментов
сети и мониторинг производительности, плоскости приложения – передача
требований об уровне обслуживания на плоскость управления.
Одной из основных целей ПКС является расширение возможностей сети
по удовлетворению потребностей абонента. В [102] определена базовая
модель обслуживания в программно-конфигурируемой сети. ONF при
описании этой модели оперирует двумя понятиями: услуга и ресурс. Под
ресурсом понимается всё, что можно использовать для доставки услуги.
Ресурсы могут быть физическими или виртуальными и во многих случаях
могут быть созданы, масштабированы или удалены поставщиком услуг в ответ
на запрос. Контроллер отвечает за виртуализацию физических ресурсов в
плоскости данных и предоставление виртуальных ресурсов потребителю
услуг. Любая услуга построена на определенном наборе ресурсов, функции и
интерфейсы которых настроены так, чтобы удовлетворить конкретную
потребность в получении услуги. Исходя из этой модели, ПКС-контроллер
испытывает управляющие воздействия через A-CPI, используя при этом D-CPI
для управления ресурсами плоскости данных.
23
Рисунок 7. Базовая модель обслуживания
Стоит отметить, что рекомендация ONF TR-502 не определяет
внутренний дизайн или реализацию ПКС-контроллера [103, с.24]. Контроллер
рассматривается как «черный ящик», определяемый его внешне наблюдаемым
поведением.
1.2.2 ITU-T Y. 3300
Работа в области стандартизации программно-конфигурируемых сетей
была начата сектором стандартизации электросвязи МСЭ (ITU-T) в
исследовательский период 2009-2012 гг. и поручена 13 рабочей группе (Study
Group 13 – Future networks & cloud), в область компетенции которой входят
сети будущего поколения, или сети пост-NGN. В июне 2014 года на свет
появилась рекомендация МСЭ-Т Y.3300: Framework of Software-Defined
Networking [92], описывающая эталонную архитектуру программно-
конфигурируемых сетей. В соответствии с рисунком 8, разработанная МСЭ-Т
архитектура содержит следующие три уровня: ресурсов (Resource layer),
управления ПКС (SDN control layer), приложений (Application layer).
24
Рисунок 8. Эталонная архитектура ПКС по версии МСЭ-Т
Под уровнем приложений понимается программное обеспечение (ПО),
определяющее правила функционирования сетевых ресурсов. Данное ПО,
взаимодействуя с уровнем управления ПКС посредством интерфейсов
контроля приложений (Application-control interface), обеспечивает
автоматизированную настройку параметров конфигурации сетевых ресурсов,
рассматриваемых при этом с определенной степенью абстракции
(высокоуровневого представления), что достигается путем использования
информационных моделей и моделей данных.
Задачей уровня управления ПКС является динамическое и
детерминированное управление поведением и конфигурацией сетевых
ресурсов в соответствии с инструкциями уровня приложений. Уровень
управления ПКС взаимодействует с сетевыми ресурсами и доставляет им
сигнальные сообщения через интерфейсы управления ресурсами (resource-
control interfaces). Конфигурация и/или свойства ресурсов, доступные уровню
приложений, абстрагируются с помощью информационных моделей и
моделей данных, при этом уровень абстракции варьируется в зависимости от
приложений и характера предоставляемых сервисов. На уровне управления
можно условно выделить три реализуемые ключевые функции:
25
– Поддержка приложения (application support) предоставляет
интерфейс управления приложением (application-control interface)
вышестоящему уровню;
– Оркестрация (orchestration) обеспечивает автоматическое
согласованное изменение конфигурации сетевых ресурсов в соответствии с
политикой и требованиями, предъявляемыми программным обеспечением
уровня приложений, что в конечном итоге позволяет выделить те ресурсы,
которые необходимы для доставки требуемой услуги для клиента;
– Абстракция (abstraction) необходима для взаимодействия с сетевыми
ресурсами и обеспечения высокоуровневого представления сетевых ресурсов,
включая их функционал и характеристики, для поддержки управления и
согласования физических и виртуальных сетевых ресурсов. Такая абстракция
зависит от стандартных моделей информации и данных и не зависит от
базовой транспортной инфраструктуры.
Уровень ресурсов представляет собой совокупность сетевых узлов,
выполняющих транспортировку и обработку пакетов данных в соответствии с
правилами, определенными уровнем управления ПКС и переданных на
нижележащий уровень через интерфейс управления ресурсами. На данном
уровне можно выделить две функции:
- Поддержка управления (control support) взаимодействует с уровнем
управления ПКС и реализует программируемость сетевых узлов через
интерфейсы управления ресурсами;
- Транспортировка и обработка данных обеспечивает пересылку
(forwarding) и маршрутизацию (routing) данных по установленным
вышестоящим уровнем правилам.
Стоит отметить, что уровень ресурсов может обеспечить как пересылку
данных, так и маршрутизацию. Дополнительные функции, в том числе
кодирование и сжатие данных, могут быть добавлены, удалены или
перенастроены для определенных пакетов данных, если этого требует уровень
приложения.
26
Функции многоуровневого управления включают в себя управление
отказами, конфигурацией, учетом, производительности и безопасности
(FCAPS) в соответствии с рекомендацией ITU-T M.3400 [91]. Примерами
такого функционала является обновление программного обеспечения,
оптимизация производительности, первоначальная конфигурация сетевых
ресурсов, ПКС-контроллеров и приложений.
Данные уровни в архитектуре МСЭ-Т эквивалентны плоскостям данных,
управления и приложений в архитектуре ONF.
1.2.3 IRTF RFC 7426
Своё видение архитектуры программно-конфигурируемых сетей в
январе 2015 года представила и Исследовательская группа интернет
технологий, опубликовав документ IRTF RFC 7426 Software-defined
networking (SDN): Layers and Architecture Terminology [128]. Под программно-
конфигурируемой сетью разработчики данного RFC понимают подход к
созданию программируемых сетей, поддерживающий разделение плоскостей
управления и пересылки данных с помощью стандартизованных интерфейсов.
Разработанная IRTF архитектура представлена на рисунке 9.
Рисунок 9. Архитектура ПКС по версии IRTF
27
В архитектуре ПКС также можно выделить три главных плоскости:
плоскость перенаправления/операционная плоскость (forwarding/operational
plane), плоскость управления/менеджмента (control/management plane) и
плоскость приложения (application plane). Однако архитектура по версии IRTF
имеет свои особенности, ключевая из которых заключается в разграничении
функций контроля и менеджмента, что в свою очередь приводит к четкому
функциональному делению внутри плоскости перенаправления/операционной
плоскости. Плоскость перенаправления в этой архитектуре отвечает за
пересылку данных в соответствии с правилами, установленными плоскостью
управления. Операционная плоскость предназначена для мониторинга и
отслеживания рабочего состояния сетевых устройств, таких как время работы,
количество доступных портов, состояние каждого порта и т.д. Плоскость
управления несет в себе функционал принятия решения о том, как именно
должен быть перенаправлен пакет и каким образом инструкции по обработке
пакета должны быть переданы на сетевое устройство. Плоскость менеджмента
предназначена для принятия решения о состоянии сетевого устройства на
основе данных мониторинга рабочего состояния, полученных от
операционной плоскости. Таким образом, лучше усвоить разницу между
плоскостями менеджмента и управления может помочь привязка к временной
шкале. Функционал управления должен осуществляться мгновенно, в
интервалах от миллисекунд до секунд, в то время как функционал
менеджмента может накапливать статистику минуты, часы и дни. В
традиционных сетевых устройствах функционал управления выполнялся
локально на каждом устройстве и являлся распределенным, в то время как
менеджмент осуществлялся централизованно и удаленно с некоторого
устройства; в программно-конфигурируемых сетях же эта граница
размывается. Такое функциональное деление приводит к тому, что
существуют различные южные интерфейсы: между плоскостями управления
и пересылки (CP southbound interface) и между плоскостями менеджмента и
операционной (MP southbound interface).)
28
Другой особенностью архитектуры IRTF является использование
многоуровневых абстракций, в связи с чем выделяют уровень абстракции
устройства DAL (англ. device abstraction layer) и уровень абстракции сервиса
SAL (англ. service abstraction layer, SAL) [128].
Согласно рассматриваемому документу, под сетевым устройством
понимается объект, который принимает пакеты на своих портах и выполняет
одну или несколько сетевых функций. Например, сетевое устройство может
переслать принятый пакет на другой порт, отбросить его, изменять заголовок
пакета и т. д. При этом сетевое устройство представляет собой совокупность
ресурсов: портов, центрального процессора, памяти и прочих. Ресурсы могут
являться простыми либо быть агрегированными для формирования сложных
ресурсов, которые можно рассматривать как один ресурс (например, агрегация
портов). Сетевое устройство само по себе является сложным ресурсом; в
качестве примеров можно привести как коммутаторы и маршрутизаторы, так
и устройства, функционал которых выше канального и сетевого уровней –
межсетевые экраны, балансировщики нагрузки. Сетевые устройства могут
быть программными или аппаратными, физическими или виртуальными. DAL
предоставляет абстракции ресурсов сетевых устройств в плоскости пересылки
и операционной плоскости; при этом DAL может абстрагировать как обе
плоскости, так и каждую в отдельности, а значит может взаимодействовать с
плоскостями управления и менеджмента как в совокупности, так и по
отдельности. DAL может быть выражен при помощи одной или нескольких
абстрактных моделей. Абстрактные модели для плоскости пересылки могут
быть созданы с помощью ForCES, OpenFlow, YANG, для операционной
плоскости – ForCES, YANG, SNMP MIB. SAL предоставляет абстракции
сервисов, которые могут быть использованы программным обеспечением
уровня приложений посредством интерфейсов сопряжения с плоскостью
управления/менеджмента, таких как RESTful API, NETCONF, RPC.
Приложение в контексте ПКС представляет собой программное
обеспечение, которое использует базовые службы для выполнения своей
29
функции. Приложение не предлагает никаких интерфейсов для других
приложений или служб [128].
Служба - программное обеспечение, которое выполняет одну или
несколько функций и предоставляет один или несколько интерфейсов
прикладного программирования API приложениям или другим службам,
чтобы использовать указанные функции.
1.2.4 Области дальнейшей стандартизации ПКС и перспективы
исследований
В приложении I рекомендации ITU-T Y .3300 перечислены ключевые
области ПКС, требующие стандартизации. И хотя по мнению самих
разработчиков данное приложение не является неотъемлемой частью
документа, обратить на него внимание полезно с точки зрения комплексного
представления о состоянии развития ПКС.
1.2.4.1 Вопросы межсетевого взаимодействия
Сеть в одном административном домене обычно контролируется и
управляется в соответствии с политиками и стандартами обслуживания
конкретного оператора или провайдера. Однако для функционирования сети с
интеграцией обслуживания необходимо обеспечивать согласованную работу
набора сетевых услуг, поддерживаемых каждым административным доменом
в отдельности. Для этого следует принять во внимание следующие моменты:
- необходимо обеспечение возможности обмена данными о
характеристиках сети (пропускной способности, задержки и т.д.) для
автоматизации управления различными административными доменами;
- каждый административный домен может иметь различный формат
пакета, вследствие чего актуальность приобретает обеспечение возможности
преобразования формата пакетов и корректировки характеристик сети
(например, пропускной способность и задержки) до или после того, как пакеты
войдут в другую сеть;
30
- наличие функционала аутентификации, авторизации и учета (AAA) для
операций межсетевого обмена.
1.2.4.2 Верификация приложений ПКС
Поскольку управление политиками безопасности, маршрутизации и
качества обслуживания выполняется приложениями, функционирующими
поверх ПКС-контроллера, важным является обеспечение согласованности
взаимодействия приложений между собой. Некорректно написанное
приложение или приложение с внедренным вредоносным кодом могут
привести к серьёзным проблемам в функционировании сети. При разработке
приложений для избегания двусмысленности, несогласованности
рекомендуется использование формальных методов - методов разработки
программного обеспечения, основанных на математическом представлении и
анализе программных продуктов. Эти методы могут быть использованы для
анализа спецификаций и проверки поведения ПКС-приложений, что позволит
свести к минимуму риск сбоя в работе сети. Операторы связи и провайдеры
услуг могут использовать формальные методы для проверки согласованности
и безопасности их сетевых конфигураций, топологии и ресурсов. Вопросам
исследования и разработки методов и средств для оценки свойств ПКС по
известной конфигурации её компонентов и проверке соответствия этих
свойств предъявляемым к сети требованиям посвящена работа [50].
1.2.4.3 Адаптация к крупномасштабным сетям
Крупномасштабная сеть включает в себя несколько ПКС-доменов
различных операторов связи, при этом каждый ПКС-домен имеет в своем
составе множество сетевых узлов. Количество сетевых узлов, которыми может
управлять один ПКС-контроллер, ограничено. В этой связи необходимо
учитывать масштабируемость. Один из способов обеспечения
масштабируемости состоит в том, чтобы ПКС-контроллеры были логически
централизованы, но физически распределены. В крупных сетях надежность
является особенно важной проблемой, в то время как ПКС-контроллер
является единственной точкой отказа. Контроллер может быть реплицирован
31
для повышения надежности. Данная проблематика рассматривается в работах
таких авторов, как D. Suh, S. Jang, S. Han [140], E. Sakic, W. Kellerer [131].
1.2.4.4 Абстрагирование ресурсов
Для упрощения и повышения эффективности разработки программного
обеспечения для ПКС требуется наличие стандарта для абстрактного описания
сетевых ресурсов. Важно, чтобы общая модель абстракций ресурсов
применялась к аналогичным сетевым ресурсам независимо от используемой
технологии, поскольку общая информационная модель упрощает
программирование ресурсов. Необходимо обеспечивать соответствующую
гранулярность абстракции, поскольку в одних случаях нецелесообразно
отображать все сетевые ресурсы и их характеристики для ПКС-приложения, а
в других - чрезмерная абстракция не позволяет приложениям максимально
использовать сетевые ресурсы. Поэтому важно, чтобы SDN обеспечивала
адекватную и сбалансированную детализацию абстракции.
На данный момент для решения задач абстрактного описания ресурсов
в ПКС набирает популярность язык моделирования данных YANG,
описанный в спецификации RFC 6020 [125].
1.2.4.5 Виртуализация сетевых ресурсов
Сетевые узлы, представляемые в виде абстрагированных ресурсов,
могут совместно использоваться несколькими ПКС-приложениями. Поэтому
необходимы механизмы виртуальной изоляции и виртуального объединения
ресурсов различных сетевых узлов с предоставлением единого интерфейса
доступа к ресурсам.
1.2.4.6 Многоуровневая программируемость
Требования ПКС-приложений могут быть весьма разнообразными, а
сами приложения для выполнения своих задач могут использовать функции
нескольких слоев OSI. Интерфейсы должны охватывать несколько уровней
OSI и работать унифицированным образом: многоуровневая
программируемость, которая охватывает слои OSI L1-L7, является важной
проблемой для ПКС [92].
32
1.3 Сетевые операционные системы программно-конфигурируемых
сетей
Согласно данным, опубликованным в исследовании 2014 года «SDN,
NFV, and open source: the operator’s view» аналитической компании Gigaom
Research большинство из 600 телекоммуникационных провайдеров Северной
Америки планировали начать внедрение программно-конфигурируемых сетей
в течение 2015–2017 годов [96, с. 12]. При этом около 95% опрошенных
желают использовать в своих сетях ПКС-решения с открытым исходным
кодом [96].
Рисунок 10. Популярные сетевые операционные системы с открытым
исходным кодом, внедренные в эксплуатацию (по результатам опроса SDx
Central)
Интернет-портал, специализирующийся на тематике ПКС - SDx Central
- в отчетах «2016 SDxCentral Network Virtualization (NV) and SDN Controller
Report» и «2017 Network Virtualization Report. SDN Controllers, Cloud
Networking and more» [136, 100] представил результаты собственных опросов,
направленных на выявление наиболее популярных сетевых операционных
систем (СОС) с открытым исходным кодом, внедренных в эксплуатацию.
Фокус-группой являлись телеком-операторы, провайдеры облачных сервисов
33
и различные организации, имеющие собственные корпоративные сети.
Респонденты могли выбрать несколько вариантов ответов, поэтому
суммарные показатели превышают 100%. Полученная аналитиками
статистика представлена в виде диаграммы, показанной на рисунке 10.
Согласно мнению респондентов, OpenDaylight является наиболее
популярной СОС с открытым исходным кодом (тип лицензии - Eclipse Public).
Она нашла применение в сетях таких компаний, как Orange, China Mobile,
AT&T, T-Mobile, Telefonica, China Telecom, Deutsche Telekom. Стоит отметить
рост популярности СОС ONOS (тип лицензии – Apache license 2.0) на
внушительные 13% за наблюдаемый период 2016-2017 гг. Однако данная СОС
все же существенно уступает OpenDaylight по показателю внедрения; одной
из причин данного факта может являться меньшее время присутствия на рынке
СОС для ПКС. Третьим по частоте использования в реальных сетях является
СОС OpenContrail (тип лицензии – Apache license 2.0), возникший как проект
с открытым исходным на базе Juniper Contrail. Стоит отметить потерю
позиций СОС Ryu (тип лицензии – Apache license 2.0) и Floodlight (тип
лицензии – Apache license). Данный факт, по мнению автора, вероятно
является следствием того, что эти СОС не обладают достаточным
функционалом и скоростью развития на фоне конкурирующих продуктов.
Исходя из приведенной статистики, в данной работе автором будет
рассматриваться именно СОС OpenDaylight. Кроме того, на выбор СОС
оказало существенное влияние наличие достаточно детальной технической
документации.
1.3.1 Архитектура сетевой операционной системы OpenDaylight
Проект OpenDaylight основан в 2013 году и был поддержан как Linux
Foundation, так и крупными производителями, среди которых Cisco, Citrix,
Juniper, IBM, Intel, HP, Huawei, VMWare и др. OpenDaylight развивается как
проект с открытым исходным кодом, где каждый желающий может внести
свой вклад в развитие СОС путем доработки программного кода,
34
документации или предложения идей в рамках общедоступных онлайн-
собраний.
СОС OpenDaylight – это кроссплатформенное программное
обеспечение, способное функционировать в среде любой операционной
системы или на аппаратной платформе, поддерживающей виртуальную
машину Java (JVM) [5, 43]. Первая версия данной СОС, получившая название
Hydrogen, вышла в феврале 2014 года и имела три редакции: Base,
Virtualization, Service Provider. На рисунке 11 представлена архитектура СОС
OpenDaylight Base Edition – редакции, предназначенной для тестирования
приложений и лабораторных исследований.
Рисунок 11. Архитектура OpenDaylight Hydrogen Base Edition
(источник: wiki.opendaylight.org)
Как видно из рисунка 11, архитектура СОС является модульной и
включает в себя следующие компоненты:
-Clustering Manager – модуль, управляющий общим кэшем экземпляров
контроллеров в кластере;
35
-Container Manager – модуль, управляющий сетевыми срезами (англ.
Network slices);
-Switch Manager – модуль обработки информации об устройствах на
южном интерфейсе;
-Statistic Manager – модуль сборки статистической информации;
-Topology Manager – модуль, отвечающий за построение топологии сети;
-Host Tracker – модуль, отслеживающий состояние подключенных
оконечных узлов;
-Forwarding Rules Manager – модуль установки потоков на
коммутационных узлах южного интерфейса;
-ARP Handler - модуль обработки ARP-сообщений;
-Forwarding Manager – модуль маршрутизации, вычисляющий маршрут
передачи данных.
Эти модули динамически связываются в так называемый Service
Abstraction Layer (SAL) – связующее программное обеспечение,
определяющее способы выполнения запросов приложений, поступающих с
северного интерфейса, и их преобразование в сообщения протоколов южного
интерфейса, отвечающего за взаимодействие с сетевым оборудованием. Это
обеспечивает защиту инвестиций в приложения, поскольку OpenFlow и другие
протоколы постоянно развиваются и дорабатываются, а SAL гарантирует, что
запросы конкретного приложения будут транслированы в команды, понятные
сетевым узлам. Для управления устройствами в вверенном ему домене,
контроллеру необходимо обладать информацией о сетевых узлах, их
возможностях, достижимости и т. д. Данная информация хранится и
обрабатывается при помощи модуля менеджера топологии (Topology
Manager). Прочие компоненты, такие как ARP handler, Host Tracker, Device
Manager, Switch Manager выполняют вспомогательные функции создания базы
данных топологии для Topology Manager.
Южный интерфейс (Southbound Interface), отвечающий за
взаимодействие с сетевой инфраструктурой, поддерживает множество
36
протоколов посредством плагинов. Редакция Base, как видно из рисунка 11,
имеет плагины OpenFlow 1.0, 1.3, OVSDB, NetConf.
Северный интерфейс взаимодействия с приложениями представлен в
виде REST API. Различные бизнес-процессы реализуются приложениями,
которые используя ресурсы контроллера запускают соответствующие услуги.
СОС обладает графическим интерфейсом. Графический интерфейс
пользователя реализован в виде приложения и использует REST API северного
интерфейса для взаимодействия с другими модулями СОС. Такая архитектура
гарантирует, что все возможности, предоставляемые посредством
графического интерфейса, также будут доступны и через REST API. Таким
образом, СОС может быть легко интегрирован в другие системы управления
или оркестрации.
Редакция Service Provider, как следует из названия, предназначена для
использования операторами связи [149]. Архитектура данной версии
представлена на рисунке 12.
Рисунок 12. Архитектура OpenDaylight Hydrogen Service Provider
Edition (источник: wiki.opendaylight.org)
37
Как видно из рисунка 12, в редакцию Service Provider включено
существенно большее количество модулей, расширяющих функционал СОС.
Так, южный интерфейс СОС в данной редакции снабжен дополнительными
плагинами для обеспечения лучшей совместимости с уже эксплуатируемыми
коммутаторами, не снабженными поддержкой протокола OpenFlow. В
частности, OpenDaylight Hydrogen Service Provider поддерживает SNMP-
плагин. Традиционные управляемые Ethernet-коммутаторы обладают
возможностью управления посредством протокола SNMP [121]. Имеющийся
плагин позволяет отслеживать состояние коммутаторов посредством SNMP-
trap, а также управление конфигурацией устройства посредством командной
строки CLI для тех случаев, когда возможностей протокола SNMP
недостаточно.
Еще одним поддерживаемым протоколом на южном интерфейсе
является LISP (Locator/ID Separation Protocol), описанный в RFC 6830 [126].
LISP предполагает использование двух адресных IP-пространств: EID
(Endpoint ID) и RLOC (Routing Locator). Адрес EID представляет собой не
маршрутизируемый в глобальной сети адрес, используемый для
идентификации конечного устройства. Адрес RLOC в свою очередь
маршрутизируется в глобальной сети и используется для создания тоннеля,
при этом адрес RLOC всегда принадлежит маршрутизатору. EID – пакет
представляет собой стандартный IP – пакет, который для передачи в
глобальную сеть инкапсулируется в UDP-дейтаграмму с адресами RLOC. На
приёмной стороне заголовки с адресами RLOC удаляются, и далее пакет
обрабатывается узлом как обычный IP-пакет. По замыслу разработчиков,
подобная схема адресации позволит сократить рост полной таблицы
маршрутизации протокола BGP в Интернет за счёт удаления из BGP таблиц
адресов, не поддающихся агрегации и замены их на крупные блоки,
соответствующие Classless Inter-Domain Routing (CIDR). В качестве частного
случая использования предлагается использование данного протокола в
приложениях наложенных сетей, например, в виртуализованных сетевых
38
функциях VNF. В этом случае EID будет использоваться для адресации
виртуальных машин, а RLOC – для реальных физических устройств.
Также заявлена поддержка южным интерфейсом протоколов BGP [122]
и PCEP [124].
На момент осуществления основных экспериментальных исследований
диссертационной работы актуальной версией СОС OpenDaylight являлся
четвёртый релиз Beryllium SR-1, выпущенный в марте 2016 года. Его
архитектура представлена на рисунке 13.
Рисунок 13. Архитектура OpenDaylight Beryllium (источник:
linuxfound.org)
Из рисунка 13 видно, что объем доработок, осуществленных за два года
развития СОС, весьма существенен. Так, среди поддерживаемых южным
интерфейсом протоколов появились протокол управления беспроводными
точками доступа CAPWAP [123], OpFlex, разработанный компанией Cisco
[117], протокол межмашинного взаимодействия CoAP [127] и многие другие.
Северный интерфейс также был доработан, в частности, была добавлена
поддержка Neutron API и интеграция с популярной платформой с открытым
исходным кодом для оркестровки облачных вычислений OpenStack [116].
Существенной переработке был подвергнут графический интерфейс,
39
обновленная версия которого получила наименование DLUX. Была повышена
стабильность работы и производительность, улучшена реализация механизма
кластеризации, появилась возможность размещать рабочие нагрузки на
хостах, которые запускаются на виртуальных коммутаторах, реализованных
при помощи набора библиотек обработки сетевых пакетов DPDK (Data Plane
Development Kit), разработанных компанией Intel и переданных в открытое
сообщество [68]. Использование DPDK позволяет повысить объемы трафика,
обрабатываемые одной виртуализованной сетевой функцией VNF на базе
аппаратных платформ с процессорами архитектуры x86 путем исключения
сетевого стека операционной системы из обработки пакетов и предоставления
VNF доступа к аппаратной платформе напрямую.
Но самые существенные изменения произошли в части SAL. Одной из
основных идей, которая закладывалась в OpenDaylight, являлась
независимость разработки приложения от спецификаций сетевых устройств,
т.е. стояла задача облегчить процесс написания приложения, предоставив
программисту возможность сосредоточиться на логике приложения и
реализуемых им бизнес-процессах, исключив вопросы изучения архитектуры
сетевых устройств и механизмы взаимодействия с ними. Для реализации этой
идеи, а именно для обеспечения абстракции с помощью общего набора API-
интерфейсов, которые обеспечивают все функции устройства, был разработан
API-ориентированный SAL (API-Driven SAL), который использовался в
первом релизе OpenDaylight Hydrogen. В такой реализации сетевые устройства
взаимодействуют с СОС OpenDaylight через соответствующие модули
протокола. Плагины протокола, в свою очередь, общаются с открытым API
уровня SAL. SAL преобразует язык, на котором взаимодействуют плагины
протокола, в API-интерфейсы приложений - все это время поддерживает
функциональность, требуемую бизнес-логикой приложения [135].
Использование интерфейса программирования приложений (API) или
иными словами набора готовых классов, процедур, функций,
предоставляемых для использования во внешних программных продуктах,
40
приводило к тому, что маршрутизация запросов статически определялась во
время компиляции. Когда какая-либо служба северного интерфейса
генерировала запрос на выполнение определенной операции на выбранном
сетевом узле, AD-SAL направлял запрос плагину южного интерфейса на
основе его типа. Однако довольно быстро стало очевидно, что недостатком
AD-SAL является статическое кодирование маршрутизации запросов и
адаптация данных для каждого плагина, что ограничивает функциональную
совместимость и быстроту развития [98].
На смену AD-SAL пришел MD-SAL. В MD-SAL все модели данных и
сервисы моделируются с использованием языка YANG [125, 113]. Если в AD-
SAL API-интерфейсы SAL запрашивают маршрутизацию между
потребителями и поставщиками (в терминах базовой модели обслуживания
ONF TR-502: SDN Architecture,) а адаптация данных статически определяется
при компиляции или сборке, то в MD-SAL API-интерфейсы SAL и запрос
маршрутизации между потребителями и поставщиками определяются из
моделей, а адаптация данных обеспечивается «внутренними»
адаптационными плагинами. Код API генерируется из моделей при
компиляции плагина. Когда пакет плагинов OSGI загружается в СОС, код API
загружается в СОС вместе с остальной частью плагина, содержащего эту
модель [113]. Сравнение двух типов SAL представлено на рисунке 14.
Рисунок 14. API-Driven SAL и Model-Driven SAL
AD-SAL обеспечивает маршрутизацию запроса (выбирает плагин
южного интерфейса на основе типа сервиса) и, при необходимости,
41
обеспечивает адаптацию службы, если API северного интерфейса отличается
от соответствующего API южного протокола. Маршрутизация запроса
основана на типе плагина: SAL знает, какой экземпляр узла обслуживается
каким плагином. MD-SAL обеспечивает маршрутизацию запросов и
инфраструктуру для поддержки адаптации службы, обеспечиваемой
плагинами. С точки зрения MD-SAL, плагин адаптации является обычным
плагином. Он предоставляет данные для SAL и потребляет данные из SAL
через API, созданные на основе моделей. Плагин Adaptation Plugin в основном
выполняет переводы модели с модели между двумя API. Запрос
маршрутизации в MD-SAL выполняется как по типу протокола, так и по узлам,
поскольку данные экземпляра узла экспортируются из плагина в SAL (данные
модели содержат информацию о маршрутизации). Простейшие API-
интерфейсы MD-SAL, созданные из YANG-моделей, функционально
эквивалентны API-интерфейсам функций AD-SAL. Кроме того, MD-SAL
может хранить данные для моделей, определенных плагинами. [113].
Структура API SAL в MD-SAL отличается от структуры в AD-SAL. AD-
SAL обычно обладает API как на северном, так и на южных интерфейсах. MD-
SAL позволяет плагинам как северного, так и южного интерфейсов
использовать один и тот же API, созданный с помощью модели; это устраняет
необходимость в определении двух разных API-интерфейсов.
Особенности AD-SAL:
-статичен;
-может использоваться с плагинами как южного, так и северного
интерфейсов;
-не хранит данные;
-ограничен только устройствами и услугами с поддержкой потока;
-приложения программируются как наборы OSGi bundle (встроенные
модули СОС), т.е. могут поставляться в виде части платформы OpenDaylight;
-программирование потока является реактивным, на основе
возникающих в сети событий.
42
Преимущества этой архитектуры связаны с удобством использования с
широким спектром классов и методов Java для обработки пакетов [71].
Особенности MD-SAL:
-имеет общий API REST для всех модулей;
-может хранить данные для моделей в API;
-поддерживает любые модели устройств или сервисов;
-приложения программируются вне СОС и не поставляются как наборы
OSGI bundle;
-программирование потока является проактивным и осуществляется по
запросу приложения через северный интерфейс
Подход MD-SAL предпочтительнее, если программисту необходимо
получить доступ к СОС с помощью внешнего приложения [71].
Возможна комбинация возможностей обоих типов SAL, например, для
разработки внешнего приложения, взаимодействующим с СОС через
северный интерфейс, но использующее при этом некоторый функционал
встроенных модулей СОС.
1.3.2 OpenDaylight как распределенная сетевая операционная система
Идея централизованного управления сетью как ключевая в архитектуре
ПКС не лишена недостатков. Очевидно, что, исходя из выполняемой роли,
ПКС-контроллер является критическим элементом всей системы и единой
точкой отказа. Таким образом, важность задачи обеспечения доступности
ПКС-контроллера не подвергается сомнению [11, 15, 44].
ПКС-контроллер, логически являясь центром управления сетью,
физически может быть представлен как одним, так и несколькими
устройствами, образующими кластер. Поэтому принято классифицировать
ПКС-контроллеры на централизованные и распределенные [22, 79, 94, 101].
Очевидно, что СОС должна иметь в своем составе механизмы (т.е. протоколы
и интерфейсы), обеспечивающие согласованное взаимодействие ПКС-
контроллеров в составе кластера.
43
Рисунок 15. Принцип организации кластера ПКС-контроллеров
На рисунке 15 показан общая принцип организации кластера с тремя
синхронизированными ПКС-контроллерами. На контроллерах
функционируют различные сетевые сервисы, а их сетевые состояния хранятся
в т.н. базе данных сетевых состояний NSDB (Network State Database). Для
обеспечения высокой масштабируемости, база данных сетевых состояний
разделяется на три раздела (то есть P1, P2, P3). Кроме того, для обеспечения
высокой доступности каждый раздел имеет две копии, и все реплики разделов
распределены по трем ПКС-контроллерам. Поскольку поддерживается
синхронизация между разделами базы данных, в кластере обеспечивается
согласованность информации о сетевом состоянии. Коммутаторы в плоскости
данных имеют несколько соединений с каждым контроллером в составе
кластера (основные и резервные), а модуль управления соединением в
контроллере восстанавливает основные соединения устройств при сбое
контроллера и выполняет балансировку нагрузки путем координации
основных соединений. При таком способе организации кластера могут быть
определены две области с ключевыми проблемами:
1) база данных - обеспечение разделения базы данных сетевых
состояний NSDB, синхронизации информации между копиями разделов базы,
выбор главного узла в кластере;
44
2) сеть - обеспечение выбора коммутатором главного контроллера и
восстановления соединения при отказе контроллера [27, 140].
OpenDaylight относится к классу распределенных СОС [43, 79, 94, 101].
Контроллер на базе СОС OpenDaylight поддерживает кластеризацию для
обеспечения высокой доступности: несколько физических ПКС-контроллеров
могут функционировать как один логический. При реализации кластеризации
за все действия, относящиеся к базам данных отвечает модуль СОС MD SAL
Clustering, построенный с использованием AKKA – библиотеки для создания
распределенных приложений на JVM, использующей акторную модель.
Каждый контроллер управляет подмножеством топологий. Сведения о
состоянии сетевой топологии хранятся в распределенном хранилище данных
(Distributed Data Store), основанной на принципе шардинга (sharding) – технике
масштабирования, суть которой состоит в разделении базы данных на
отдельные части (shard) таким образом, чтобы каждую из них можно было
вынести на отдельный сервер. Синхронизация данных о состоянии сети между
контроллерами в кластере выполняется специальным актором, реализующим
алгоритм решения задач консенсуса Raft [111]. За все действия, связанные со
взаимодействием с сетевыми узлами – коммутаторами, отвечает плагин
южного интерфейса, в частном случае OpenFlow-плагин.
Рисунок 16. Кластерная архитектура и компоненты OpenDaylight
45
Рассмотрим кластер контроллеров OpenDaylight в режиме
ведущий/ведомый, показанный на рисунке 17. В алгоритме Raft определены
два типа копии разделов хранилища данных (Data Store): главная (leader),
которая принимает на себя все операции чтения и записи, и ведомая (follower),
являющаяся копией главной и не выполняющая каких-либо операций чтения /
записи. Запросы на чтение / запись состояния топологии могут быть
обработаны только главной копией в экземпляре OpenDaylight 1. Если
экземпляр OpenDaylight 2 получил запросы на чтение топологии B, он
копирует соответствующие сведения о состоянии топологии, хранящиеся в
главной копии OpenDaylight 1, и отвечает на запрос. Если, например, в
топологии C произошли изменения, то экземпляр OpenDaylight 3 переправляет
соответствующий запрос на главную копию в OpenDaylight 1. После этого
главная копия запрашивает согласование обновлений от ведомых копий.
Таким образом гарантируется согласованность данных о топологии [140].
Для того чтобы обнаружить неисправность кластера, контроллеры на
базе СОС OpenDaylight обмениваются так называемыми heartbeat-
сообщениями, которые позволяют периодически следить за состоянием
каждого экземпляра кластера. Когда контроллер, который содержит главную
копию раздела, выходит из строя, доступ к данным в разделе запрещен во
время отсутствия главной копии. Если главная копия недоступна в течение
заранее определенного временного интервала, от подконтрольных устройств
отправляются запросы ведомым копиям для инициализации процедуры
выбора новой главной копии.
46
Рисунок 17. Кластер с одним ведущим контроллером и двумя ведомыми
(режим Master/Slave)
Рассмотрим реализацию кластера контроллеров OpenDaylight на базе
протокола OpenFlow версии 1.3 как наиболее старшей из поддерживаемых
версий. Согласно спецификации [115], коммутатор устанавливает соединения
с каждым контроллером в кластере, при этом определяя одну из следующих
возможных ролей контроллера:
-Master – главный (ведущий) узел в кластере, имеющий приоритетные
права записи/чтения на коммутаторах. Все асинхронные и симметричные
OpenFlow-сообщения отправляются коммутатором главному узлу кластера.
Контроллер с ролью master может быть только один в кластере;
-Slave – резервный (ведомый) узел в кластере, имеющий только права на
чтение информации с коммутатора. Нескольким контроллерам в кластере
может быть присвоена роль slave;
-Equal – роль, назначаемая по-умолчанию при первом соединении
контроллера к коммутатору. Контроллер, которому присвоена роль equal,
обладает полными правами к коммутатору на чтение/запись, как master. В этом
47
случае необходима синхронизация состояния между контроллерами в
реальном времени [27].
Роль Master схожа с Equal и предоставляет полный доступ к
коммутатору, разница состоит в том, что коммутатору гарантируется, что он
является единственным контроллером в этой роли. Коммутатор не может
самостоятельно изменять состояние контроллера, оно всегда изменяется в
результате запроса от одного из контроллеров. Коммутатор может быть
одновременно подключен к нескольким контроллерам с ролью Equal или Slave
и не более чем к одному контроллеру в роли Master. Роли Master и Equal
идентичны с точки зрения прав доступа к коммутаторам, но являются
взаимоисключающими. Невозможно организовать управление сетевым
доменом одновременно контроллерами с ролями Master и Equal, поскольку не
существует механизма для принудительного разделения ресурсов
коммутатора между этими контроллерами.
Для назначения роли контроллера в протоколе OpenFlow, начиная с
версии 1.2 [107], существует специальный вид сообщений Role-Request типа
контроллер-коммутатор (подробнее будет рассмотрен в главе 3).
В соответствии с таблицей 1, при использовании СОС OpenDaylight
возможно создание кластеров различного размера, определяемого числом
входящих в его состав контроллеров [143].
Таблица 1. Возможное количество узлов в кластере контроллеров на
СОС OpenDaylight
Размер кластера, шт. Возможное число отказавших узлов, шт.
2 0
3 1
4 1
5 2
6 2
7 3
48
Для взаимодействия контроллеров в кластере различные модули СОС
используются собственные порты, указанные в таблице 2.
Таблица 2. Используемые порты при организации кластера
контроллеров
Номер
порта
Модуль Признак закрытия порта
на стороне контроллера
Признак закрытия
порта на стороне узла
сети
2550 MDSAL
clustering
Невозможность установки
соединения между узлами
кластера с дальнейшей
остановкой контроллера
Коммутаторы не могут
установить соединения
с контроллером
6633 OpenFlow Контроллер не может
установить потоки на
коммутаторах
Коммутаторы не могут
установить соединения
с контроллером
6640,
6641
OVSDB Контроллер сможет
инициировать активное
соединение c OVS, но
ответы на ping-запросы
коммутатору доставлены
не будут
Коммутаторы не могут
установить соединения
с контроллером
8087 Neutron Neutron не может
установить соединение с
контролером
-
8080,
8181
RESTCONF,
Jolokia
Внешние инструменты,
использующие REST, не
смогут установить
соединения с
контроллером
-
Понимание используемых для организации кластера модулей СОС и
используемых ими портов необходимо для настройки узлов кластера [148].
49
Закрытие данных портов приведет к невозможности функционирования
кластера [120].
1.3.3 Коммерческие СОС на базе OpenDaylight
В уже упомянутом ранее отчете Gigaom Research «SDN, NFV, and open
source: the operator’s view» отмечается, что около 76% респондентов отдают
предпочтение коммерческим версиям open-source разработок для ПКС,
поскольку это позволяет объединять преимущества ПО с открытым исходным
кодом с технической поддержкой продукта от вендора [96, с. 24].
В таблице 3 приведены компании, разработавшие собственные
коммерческие СОС для ПКС-контроллеров. Таблица 3 составлена на основе
данных из отчета SDx Central [134].
Таблица 3. Производители коммерческих ПКС-контроллеров
Участники OpenDayligh
Foundationt
Лояльные OpenDaylight Конкурирующие
Brocade Cyan (поглощен Ciena) Big Switch
Cisco HP Juniper
Ericsson NEC Plexxi
Extreme networks Nuage Networks PLUMgrid
Hewlett Packard
Enterprise
Pluribus
Huawei Sonus
VMware NSX
В соответствии с таблицей 3, всех производителей ПКС-контроллеров
можно условно разделить на три группы:
1. Участники OpenDayligh Foundationt - производители, имеющие в
своей линейке продуктов СОС на основе OpenDaylight, осуществляют
финансовую поддержку проекта, являясь т.н. «платиновыми», «золотыми» и
«серебряными» спонсорами;
50
2. Лояльные OpenDaylight - производители, активно участвующие в
разработке OpenDaylight, но имеющие также собственные разработки не на
основе данного контроллера;
3. Конкурирующие - производители, предлагающие коммерческие
контроллеры, основанные на собственных разработках.
Среди упомянутых разработчиков коммерческих СОС присутствуют
традиционные вендоры телеком-оборудования, компании из смежных
сегментов (производители серверного оборудования, разработчики средств
виртуализации), малые инновационные предприятия (или стартапы) в сфере
ПКС [3, 13].
Рассмотрим технические спецификации коммерческих СОС на базе
OpenDaylight от следующих производителей: Brocade, Cisco, Ericsson, Extreme
Networks, Hewlett Packard Enterprise, Huawei. Параметрами сравнения
являются:
- версия OpenDaylight, на основе которой разработана коммерческая
СОС;
- сфера применения (позиционирование СОС вендором);
- набор протоколов северного и южного интерфейсов;
- возможность организации кластера ПКС-контроллеров;
- совместимые модели сетевых узлов;
- приложения, включенные в комплект поставки СОС (вендорские
приложения);
- рекомендуемая конфигурация аппаратной платформы сервера [3].
Таблица 4. Технические характеристики коммерческих версий СОС на базе
OpenDaylight
Производ
итель/
модель
Brocade
SDN
controller
Cisco Open
SDN
Controller
Ericsson
SDN
controller
Extreme
Networks
One
Controller
HPE
ContexNet
Huawei
Agile
Controller
Версия
OpenDayl
ight
Lithium Helium н/д Helium SR
1.1
Helium
SR3
н/д
51
Продолжение таблицы 4
Сфера
применен
ия
ЦОД,
корпоратив
ные сети,
WAN,
транспортн
ые сети
н/д ЦОД,
корпоратив
ные сети,
WAN,
транспортн
ые сети
ЦОД,
WAN,
транспортн
ые сети
ЦОД ЦОД,
корпоратив
ные сети
Протокол
ы
южного
интерфей
са
OpenFlow
1.0, 1.3,
NETCONF/
YANG
(RFC
6142/6020),
BGP-LS,
PCEP,
OVSDB
OpenFlow
1.0,
OpenFlow
1.3,
NETCONF/
YANG
(RFC6241/
6020),
BGP-LS,
PCEP,
OVSDB
OpenFlow,
OVSDB,
BGP,
NETCONF,
PCEP,
BGP-LS
OpenFlow
1.0,
OpenFlow
1.3,
NETCONF,
SNMP,
SOAP/XM
L
OpenFlow
1.3
OpenFlow,
NETCONF,
OVSDB
Протокол
ы
северного
интерфей
са
RESTful
API,
OpenStack
Neutron,
Python,
Ruby
RESTful
API
RESTful
API
RESTful
API, OSGi
RESTful
API
RESTful
API
Вендорск
ие
приложен
ия
Brocade
Topology
Manager,
Brocade
Flow
Optimizer
Cisco
OpenFlow
Manager,
Cisco PCEP
Manager,
Cisco
BGPLS
Manager,
Cisco
Inventory
Manager,
Model
Explorer,
Tags
Manager
Enhanced
Service
Control
Functionalit
y, Cloud
Networking
Extensions
&
applications
, Transport
Network
Control
extensions
and
planning
and
optimizatio
n
applications
- ContexMA
P,
ContexSwit
ch, Contex
Control
-
Кластери
зация
+ + + - + +
52
Продолжение таблицы 4
Совмести
мые
сетевые
устройств
а
Устройств
а Brocade,
заявлена
совместим
ость с
устройства
ми прочих
производи
телей,
поддержив
ающих
протоколы
южного
интерфейс
а
Cisco ASR
9000, Cisco
Nexus
3000, Cisco
Catalyst
4500X и
4500
Ericsson
Smart
Services
Router
8000,
Ericsson
Router
6000,
Ericsson
SPO, Ciena
6500,
любые
OpenFlow
1.3 -
коммутато
ры
Заявлена
поддержка
большинст
ва
существую
щих
OpenFlow-
устройств
Заявлена
поддержка
большинст
ва
существую
щих
OpenFlow-
устройств,
в том
числе на
базе
архитектур
ы x86
Huawei
Network
Switch, S-
серия, AR-
серия,
CloudEngin
e-серия,
USG серия,
устройства
сторонних
производит
елей
Рекоменд
уемая
конфигур
ация
аппаратн
ой
платформ
ы сервера
ЦП Intel
Xeon/Core
с 4 ядрами,
12 Гб ОЗУ,
64 Гб на
HDD,
Gigabit
Ethernet
ЦП Intel
Xeon или
Intel Core с
4 ядрами,
16 Гб ОЗУ,
требуемое
место на
жестком
диске 64
Гб
н/д Модель
OneC-A-
600 с 2 ЦП
Intel Xeon
с 24
ядрами, 32
Гб ОЗУ, 2
жесткими
дисками по
1 Тб в
режиме
RAID, 4
портами
GigabitEthe
rnet
HP BL 460
с ЦП Intel
Xeon E5-
2600 v3,
v4, до 2
ЦП по 22
ядра, до 2
Тб ОЗУ,
HP Pro
Liant DL
380 Intel
Xeon E5-
2600 v3,
v4, до 2
ЦП по 22
ядра, до 3
Тб ОЗУ,
10GigabitEt
hernet/40Gi
gabitEthern
et
2 ЦП Intel
Xeon E5-
2620 v3 2,4
ГГц, 6
ядер, 64 Гб
ОЗУ, 2
жестких
диска по
600 Гб
Как и версия с открытым исходным кодом рассматриваемой СОС,
коммерческие версии OpenDaylight предназначены в первую очередь для
сетей центров обработки данных. Однако модульная архитектура данной СОС
позволяет вендорам оптимизировать свои разработки под конкретную сферу
применения: так, Brocade SDN controller является наиболее универсальным
согласно позиционированию производителя. Коммерческие СОС отличаются
набором протоколов южного и северного интерфейсов, однако поддержку
53
OpenFlow и RESTful API обеспечивают все рассматриваемые СОС. Создание
кластера контроллеров не поддерживает только Extreme Networks
OneController.
Из рассматриваемых коммерческих СОС не все имеют в комплекте
поставки вендорские приложения, однако со временем их число однозначно
будет расти, поскольку это позволяет создать персонализированное
предложение для заказчика. Высокая активность вендоров по адаптации СОС
с открытым исходным кодом OpenDaylight придает уверенности
разработчикам ПКС-приложений в том, что их ПКС-приложения будет
востребовано на рынке. Приложения, работающие на открытой версии
OpenDaylight, с большой долей вероятности будут работать и на коммерческой
версии, что снижает риск несовместимости.
Производители заявляют о наличии достаточно широкой линейки
совместимых сетевых узлов, однако гарантируется работа ПКС-контроллера и
коммутатора одного и того же бренда. Как показывает опыт эксплуатации и
пилотных проектов заказчиков ПКС-решений [14, 48], проблема
совместимости устройств различных вендоров действительно имеет место
быть. Данный факт подтверждает необходимость тестирования ПКС-решений
в лабораторных условиях и дальнейшего развития стандартизации в сфере
ПКС. Стоит отметить, что конкретно для решения проблемы совместимости
коммерческие СОС имеют в своем арсенале техническую поддержку со
стороны вендора, чего лишена базовая open-source версия OpenDaylight.
Большинство вендоров поставляет заказчикам СОС только в виде
программного обеспечения. Однако на примере компании Extreme Networks
видно, что возможен вариант поставки в виде готового программно-
аппаратного комплекса (модель OneC-A-600), что представляет собой уже
готовый ПКС-контроллер.
Однако характерной особенностью использования лицензированной у
вендора версии СОС является некоторое отставание в темпах обновления от
open-source релизов OpenDaylight: на момент выхода Beryllium (четвертый
54
релиз) вендоры в основной массе предлагали СОС на базе Helium (второй
релиз).
Немаловажно, что согласно спецификациям рассмотренных СОС,
сервер, выступающий в роли аппаратной платформы ПКС-контроллера,
должен иметь многоядерный серверный ЦП Intel Xeon [3].
Таким образом, каждый контроллер занимает свою нишу на рынке, что
упрощает выбор СОС заказчикам, эксплуатирующим сети различных
размеров [3].
1.4 Выводы и результаты
В настоящее время международными организациями,
разрабатывающими технические стандарты в области связи и сетей передачи
данных, утверждены рекомендации, описывающие архитектуру программно-
конфигурируемых сетей. В первой главе рассмотрены документы трех
организаций – Международного союза электросвязи, Инженерного совета
Интернета, Open Network Foundation - описывающие архитектуру ПКС.
Анализ документов показал, что ключевой особенность архитектуры ПКС
является трехуровневая структура, подразумевающая физическое разделение
плоскостей пересылки данных, управления, приложений. Однако
присутствуют и довольно существенные отличия во взгляде на архитектуру
ПКС, прежде всего в области функционала менеджмента; наиболее сильно
отличается архитектура, предложенная IRTF. Стоит отметить, что
рассмотренные рекомендации не описывают внутреннюю организацию СОС
для ПКС-контроллера.
В главе 1 приводится обоснование выбора СОС с открытым исходным
кодом OpenDaylight и рассматривается его архитектура, функционал,
технические спецификации. На основании проведенного анализа делается
вывод о необходимости использования многоядерных центральных
процессоров в аппаратной платформе ПКС-контроллера.
55
2. АНАЛИЗ МНОГОЯДЕРНЫХ АППАРАТНЫХ
ПЛАТФОРМ ПКС-КОНТРОЛЛЕРОВ
2.1 Реализация параллелизма в современных центральных
процессорах
Одной из первых классификаций архитектур параллельных
вычислительных машин и одновременно наиболее часто упоминаемой на
сегодняшний день в литературе является классификация Майкла Флинна [73],
предложенная в 1972 году. В основу данной классификации положено
соотношение команд и обрабатываемых ими данных, или принцип
параллелизма на уровне данных. Выделяют следующие классы архитектур:
SISD (англ. Single Instruction - Single Data) или ОКОД (одна команда –
одни данные). К данному классу относятся обычные последовательные ВМ с
архитектурой фон Неймана, выполняющие только одну команду над одним
набором данных. Типичным представителем является ВМ с суперскалярными
и конвейерными процессорами [26, 29, 37, 47].
SIMD (англ. Single Instruction - Multiple Data) или ОКМД (одна команда
- много данных). К данному классу относятся ВМ, позволяющие выполнять
одну арифметическую операцию над многими наборами данных. Типичными
представителями класса являются векторные процессоры и обычные
современные процессоры с набором векторных расширений (например, SSE)
[26, 29, 37, 47].
MISD (англ. Multiple Instruction - Single Data) или МКОД (много команд
- много данных). В архитектуре такой ВМ присутствует множество
процессоров, обрабатывающих один и тот же набор данных. На сегодняшний
день не существует реальных примеров подобных ВМ, хотя рядом авторов [76,
77] предпринимались попытки классифицировать ВМ с конвейерными
процессорами как представителей MISD-архитектуры. Тем не менее, данная
точка зрения не стала общепринятой и на данный момент класс считается
пустым.
56
MIMD (англ. Multiple Instruction - Single Data) или МКОД (много команд
- много данных). Данный класс чрезвычайно широк и включает в себя
мультипроцессорные ВМ, ВМ с многоядерными и многопоточными
процессорами, а также кластеры ВМ [26, 29, 37, 47].
Рисунок 18. Архитектура вычислительных систем согласно классификации
Флинна: а) SISD; б) MISD; в) SIMD; г) MIMD
Классификация Флинна не предлагает инструмента для дальнейшей
детализации классов и соответственно не даёт исчерпывающего описания
различных архитектур класса MIMD, что является её недостатком.
В 1984 году К. Вангом и Ф. Бриггсом [80] были сделаны некоторые
дополнения к классификации Флинна, которые заключались в детализации
классов SISD, SIMD и MIMD.
57
Класс SISD разбивается на два подкласса:
архитектуры с единственным функциональным устройством;
архитектуры, имеющие в своем составе несколько
функциональных устройств.
В классе SIMD также вводится два подкласса:
архитектуры с пословно-последовательной обработкой
информации;
архитектуры с разрядно-последовательной обработкой.
Класс MIMD авторы подразделяют на:
вычислительные системы со слабой связью между процессорами
или системы с распределенной памятью;
вычислительные системы с сильной связью или системы с общей
памятью [10].
Вычислительные системы с сильной связью создаются путём
увеличения числа процессоров в ВМ.
Другим типом параллельной обработки данных является параллелизм на
уровне потоков. Основная идея такого типа обработки заключается в
обеспечении одновременной работы имеющихся функциональных блоков
процессора путем запуска нескольких вычислительных потоков [8], поскольку
одна задача не в состоянии полностью загрузить имеющиеся блоки
процессора. Для реализации необходимо продублировать некоторые
функциональные блоки процессора: регистры общего назначения, регистры-
указатели на очередную исполняемую инструкцию, некоторые управляющие
регистры и контроллер прерываний. Прочие ресурсы, такие как кэш-память,
исполнительные блоки, блоки предсказания переходов, контроллер шины
являются разделяемыми. При этом для операционной системы один
физический процессор предстает в виде нескольких логических.
Наиболее распространенным реализацией такого подхода является
архитектура с одновременным выполнением потоков или Simultaneous
58
Multithreading (далее SMT). Для аппаратной реализации SMT процессор
должен содержать:
-Счетчик команд для каждого потока;
-Средства ассоциации команд с потоком;
-Несколько стеков адресов возврата из подпрограмм;
-Дополнительную память процессора для удаления из буфера
выполненных внеочередных команд [8].
2.2 Аппаратные платформы на базе процессоров Intel Xeon E3 и
Xeon E5
Как отмечают аналитики, современный рынок серверных процессоров
на 96% состоит из процессоров с х86-совместимой архитектурой [145], при
этом единогласным лидером в этом сегменте является компания Intel [7, 18].
В выводах первой главы диссертационной работы отмечалось, что в
соответствии с рекомендациями производителей, аппаратные платформы для
коммерческих версий контроллера OpenDaylight должны быть снабжены
многоядерными процессорами Intel Xeon с числом ядер от 4 и выше.
Производимые компанией Intel серверные процессоры по критерию
масштабируемости и области применения можно разделить на следующие
категории:
однопроцессорные системы, включающие линейки Xeon E3 1200,
E5 1600. Область применения – сервера начального уровня для малого и
среднего бизнеса, рабочие станции [86];
двухпроцессорные системы, включающие линейки Xeon E5 2600
и Xeon E7 2800. Сервера на базе таких ЦП предназначены для широкого класса
задач, обладают расширенными возможностями виртуализации,
используются в центрах обработки данных и для построения программно-
определяемой инфраструктуры SDI [88];
четырехпроцессорные системы Xeon E5 4600, Xeon E7 4800 также
применяются в центрах обработки данных, но для задач, требующих больший
59
уровень производительности и виртуализации или с трудно прогнозируемой
нагрузкой [88];
восьмипроцессорные системы Xeon E7 8800 обладают
расширенными возможностями в плане обеспечения надежности и высокого
уровня производительности и предназначены для использования в
транзакционных системах реального времени OLTP, системах планирования
ресурсов предприятия ERP и прочих системах анализа Big Data [89];
однокристальные системы Atom C2000 предназначенны для
встраиваемых систем и микросерверов [84], а Xeon D1500 - для сетевых
хранилищ, коммутаторов и маршрутизаторов, устройств индустриального
Интернета вещей [21]. Отдельно отмечается преимущество линейки Xeon
D1500 над Atom C2000 в задачах, связанных с обработкой сетевых пакетов, в
том числе при использовании виртуализации сетевых функций (NFV-
решений) [21].
сопроцессоры Xeon Phi, поставляемые в виде отдельной платы
расширения с интерфейсом PCI Express x16, применяемые для ускорения
различного рода научных вычислений, таких как обучение нейросетей и
приложения с высокой степенью параллелизации. [141]
Рисунок 19. Классификация серверных процессоров Intel по критерию
масштабируемости
60
Таким образом, исходя из рекомендаций производителей контроллеров
и позиционирования семейств серверных процессоров Intel, рассмотрим далее
спецификации серверных аппаратных платформ на базе процессоров Intel
Xeon E3 и Xeon E5.
В период выполнения автором экспериментальных исследований,
актуальные x86-серверные платформы были основаны на процессорах Intel с
микроархитектурой Haswell-EP. Haswell – это кодовое наименование
микроархитектуры процессоров Intel Core четвертого поколения, Haswell-EP
же представляет собой вариацию этой микроархитектуры для серверного
сегмента. Микроархитектура Haswell достаточно подробно была
проанализирована в работах D. Kanter [90] и W. J. Carranza [57], а также в
официальной документации Intel [69]. Обобщённо конвейер исполнения
инструкции для процессоров микроархитектуры Haswell представлены на
рисунке 20.
Рисунок 20. Конвейер обработки процессоров с микроархитектурой Haswell
В процессорах Haswell можно выделить подсистему упорядоченной
предварительной обработки (In-Order Front End), отвечающую за выборку и
декодирование инструкций в предусмотренном программой порядке,
подсистему исполнения с изменением последовательности (Out-of-Order),
задачей которой является исполнение микроопераций в оптимальном порядке,
61
и подсистему упорядоченного завершения (In-Order Retirement), которая снова
переупорядочивает результаты исполнения в изначальном предусмотренном
программой порядке и подсистему кэш-памяти [57, 90, 142]. Исполнение
инструкции начинается со считывания и выборки её из кэша, откуда она,
проходя через буфер выборки инструкций (Fetch Buffer) и буфер инструкций
(Intsructions Queue), поступают для декодирования на блок декодера (µ-ops
Queue), преобразующий x86-инструкции в простейшие микрооперации.
Инструкции может соответствовать одна микрооперация (в этом случае
декодирование проводит декодер простых инструкций или simple decoder) или
несколько микроопераций (от 2 до 4 штук, декодирование осуществляется
декодером сложных инструкций или complex decoder). Стоит отметить
наличие выделенного кэша для микроопераций [57, 69, 90, 142].
После декодирования инструкций микрооперации и данные
помещаются в т.н. станцию-резервуар (Reservation Station) - специальный
буфер-диспетчер, определяющий оптимальный порядок исполнения.
Микрооперации могут быть выполнены во внеочередном порядке, если в
требуемый момент времени доступны необходимые им данные. Результаты
исполнения хранятся в буфере переупорядочивания микроопераций (Reorder
Buffer) до тех пор, пока программа не определит их готовность к удалению из
конвейера и не будет осуществлена т.н. процедура отставки (retire stage), в
ходе которой осуществляется сохранение результатов в кэш-память данных.
Однако если результат исполнения необходим для выполнения последующих
микроопераций – то он помещается в станцию-резервуар. Когда все стадии
конвейера пройдены (14-19 для Haswell), на вход конвейера подается
следующая инструкция. Порядок подачи инструкций определяется при
непосредственном участии блока предсказания ветвлений (Branch Predictors)
[57, 69, 90, 142].
Стоит отметить, что при реализации SMT, которая в случае с
процессорами Intel получила наименование Hyper-Threading (далее HT),
буферы подсистем упорядоченной предварительной обработки и
62
упорядоченного завершения являются теми ресурсами, которые требуется
физически продублировать. При этом доступ к подсистеме исполнения с
изменением последовательности, кэшу, блоку предсказания ветвлений
осуществляется в разделяемом режиме. Буфер переупорядочивания (ROB) при
активации HT также осуществляет координирование записей различных
логически процессоров. Важно обратить внимание, что все рассмотренные
выше блоки процессора составляют ядро.
По оценкам производителя, реализация технологии HT ведет к
увеличению площади кристалла всего лишь на 5% [130], хотя достигаемое
ускорение при этом может доставлять до 30%. Однако эффект от
использования HT не всегда положительный. В частности, для типа нагрузок,
характерного для баз данных, известны проблемы снижения
производительности при использовании HT в таких СУБД, как Microsoft SQL
Server [137], а при использовании отечественной системы 1С: Предприятие 8
не рекомендуется активировать HT при превышении показателя загрузки
процессора порога 80% [31]. В работах [60, 72, 75] исследуется поведение Java-
приложений на многоядерных процессорах с HT. Авторами отмечаются узкие
места производительности программ и предлагаются способы оптимизации
виртуальной машины JVM. Однако при использовании виртуализованных
сред HT дает ощутимый прирост производительности [30, 138]. В задачах
классификации сетевых пакетов использование многоядерных процессоров
дает весьма серьезный прирост ускорения, что показано в исследовании [148]
на примере процессора Tilera-Gx36, снабженного 36 ядрами, однако не
являющимся x86-совместимым. Кроме факторов производительности при
использовании многоядерных процессоров с HT, необходимо учитывать
модель лицензирования используемого программного обеспечения, поскольку
некоторые компании предлагают расчет стоимости лицензии исходя из числа
физических и логических процессоров в системе. Такую политику ведет
Microsoft при лицензировании операционных систем Windows Server или
63
отечественный производитель средств криптографической защиты
информации «Крипто-ПРО» (продукт КриптоПРО JCP 2.0).
В распоряжении автора находились серверные платформы, снабженные
процессорами Intel Xeon E3-1241 v3 и Xeon E5-2670 v3. Сравнение
технических характеристик приведено в таблице 5, составленной на основе
данных ресурсов [67] и [119].
Таблица 5. Сравнение спецификаций процессоров Xeon E3-1241 V3 и Xeon
E5-2670 v3
Процессор Intel Xeon E3-1241 v3 Intel Xeon E5-2670 v3
Дата выпуска Q2 2014 Q3 2014
Литография, нм 22 22
Тип разъёма (сокета) LGA 1150 LGA 2011-3
Количество разъёмов
(сокетов)
1 2
Поддержка Hyper-
Threading
+ +
Количество ядер 4 12
Количество потоков 8 24
Базовая тактовая
частота процессора,
ГГц
3,5 2,3
Максимальная тактовая
частота с технологией
TurboBoost, ГГц
3,9 3,1
Кэш-память 1 уровня
(на ядро), КБ
64 (32-данные, 32-
инструкции)
64 (32-данные, 32-
инструкции)
Кэш-память 2 уровня
(на ядро), КБ
256 256
64
Продолжение таблицы 5
Разделяемая кэш-
память 3 уровня, МБ
8 30
Пропускная
способность системной
шины, гигатранзакций/с
5 (DMI 2.0) 5 (DMI 2.0), 9,6 (QPI)
Максимальный объем
оперативной памяти, Гб
32 768
Тип оперативной
памяти
DDR3/ DDR3L-
1333/1600
DDR4 1600/1866/2133
Число каналов памяти 2 4
Число контроллеров
памяти
1 2
Пропускная
способность памяти,
ГБ/с
25,6 68,3
Каждое процессорное ядро имеет собственную кэш-память первого и
второго уровней. Остальные же ресурсы с точки зрения ядра являются общими
(разделяемыми), а значит, ядра конкурируют за доступ к ним. Так, в рамках
процессорного кристалла к разделяемым ресурсам, например, относятся
контроллер оперативной памяти, кэш-память третьего уровня, соединительная
шина. Упрощенно логическую схему устройства многоядерного процессора
можно представить, как показано на рисунке 21.
65
Рисунок 21. Разделяемые ресурсы процессора
Если сравнить схемы платформ Xeon E3-1200 v3 и Xeon E5-2600 v3,
представленные на рисунках 22 и 23, то можно выделить как общие
особенности реализации, так и различия, обусловленные различными
секторами использования платформ. В частности, контроллер памяти на обоих
процессорах является встроенным, поэтому материнская плата не снабжена
отдельной микросхемой, реализующей функционал северного моста.
Микросхема PCH (или контроллер-коммутатор платформы) выполняет роль
южного моста. Связь процессора с PCH обеспечивается с помощью шины DMI
2.0. Однако процессор Xeon E3 работает с оперативной памятью типа
DDR3/DDR3-L в двухканальном режиме и может оперировать объемом до 32
Гб, в то время как Xeon E5 – с памятью типа DDR4 в четырехканальном
режиме максимальным объемом 768 Гб [87].
66
Рисунок 22. Платформа Intel Xeon E3 1200 v3
Xeon E5 серии 2600 поддерживают многопроцессорные конфигурации,
канал межпроцессорного обмена реализован с помощью шины QPI. С точки
зрения используемых периферийных интерфейсов обе платформы
поддерживают идентичный набор, однако стоит отметить различия
встроенных LAN-контроллеров. Платформа для Xeon E3 снабжена
контроллером Gigabit Ethernet, в то время как платформа Xeon E5 может
включать в свой состав как контроллер с поддержкой стандарта Gigabit
Ethernet (в частности, в составе чипсета Intel 89xxCL), так и контроллер Intel
XL710, используемый в связке с чипсетом Intel C612 и поддерживающий
стандарты 10 Gigabit Ethernet / 40 Gigabit Ethernet [85]. Наличие у серверной
платформы Xeon E5 контроллера LAN с большей пропускной способностью
67
обусловлено позиционированием и сферой применения в центрах обработки
данных.
Рисунок 23. Платформа Intel Xeon E5 2600 v3 (в варианте для
двухпроцессорной конфигурации)
Если же рассматривать такие серверные платформы с точки зрения
дополненной классификации Флинна, то отнести их можно к MIMD системам
с общей памятью и реализацией SMT.
2.3 Метрики параллельных вычислений
Для оценки преимуществ, получаемых при параллельном решении
задачи на ВМ с n процессорами, по сравнению с последовательным решением
той же задачи на ВМ с одним процессором, используют метрики
параллельных вычислений [26]. Базисом для определения упомянутых метрик
являются следующие характеристики вычислений: n — количество
процессоров, используемых для организации параллельных вычислений; V(n)
— объем вычислений, выраженный через количество операций, выполняемых
68
n процессорами в ходе решения задачи; T(n) — общее время вычислений
(решения задачи) с использованием n процессоров. К основным метрикам
принято относить:
- Индекс параллелизма характеризует среднюю скорость параллельных
вычислений через количество выполненных операций:
( )( )
( )
V nPI n
T n ;
- Ускорение есть отношение времени, затрачиваемого на проведение
вычислений на однопроцессорной ВМ, ко времени решения той же задачи на
параллельной n-процессорной системе:
(1)( )
( )
TS n
T n ;
- Эффективность – характеризует целесообразность наращивания
числа процессоров:
( )( )
S nE n
n ;
- Утилизация – учитывает вклад каждого процессора при параллельном
вычислении в виде числа операций, выполненных ЦП в единицу времени:
( )( )
( )
V nU n
nT n ;
- Избыточность – отношение объема параллельных вычислений к
объему эквивалентных последовательных вычислений:
( )( )
(1)
V nR n
V ;
- Сжатие – величина, обратная избыточности.
(1)( )
( )
VC n
V n ;
- Качество – увязывает ускорение, эффективность и сжатие:
( ) ( ) ( ) ( ).Q n S n E n C n
Для рассмотренных метрик справедливо соотношение
69
( ) ( ) ( ) .Q n S n PI n n
2.4 Закон Амдала
Для оценки эффекта от параллелизации часто используют сравнение
полученного на практике результата с теоретическим верхним пределом, описать
который для многопроцессорных систем можно при помощи законов Амдала.
Для оценки работы программы на параллельной вычислительной системе
наиболее часто используют такие метрики параллелизма, как ускорение и
эффективность.
Обозначим через n - количество процессоров в вычислительной системе;
V - объем вычислительных операций; W - скорость вычислений одним
процессором; ( )T n - время выполнения задачи на n процессорах. Тогда время
выполнения вычислений на однопроцессорной системе может быть определено
по формуле:
(1)V
TW
. (1)
На практике ни одну из задач невозможно распараллелить полностью,
поскольку существуют фрагменты задачи, выполнить которые можно только
последовательно, например, ввод/вывод данных. Следовательно, любая
задача, выполняемая на многопроцессорной системе, имеет последовательную
и параллельную части. Пусть lp - доля линейных (последовательно
выполняемых) операций решаемой задачи, тогда pp - доля параллельных
операций. Очевидно, что 1pp lp . Тогда время выполнения вычислений на
n -процессорной системе можно определить:
( )lp V pp V
T nW nW
(2)
Тогда, согласно данному выше определению, ускорение определяется
как
70
(1)( )
( )
TS n
T n . (3)
Подставляя (1) и (2) в (3), получим выражение:
1( )
V
WS nlp V pp V pp
lpW n W n
(4)
Выражение (4) является математической записью закона Амдала [54,
55], полученного в 1967 г. Джинном Амдалом, известным архитектором
компьютерных систем. Стоит отметить, что данный закон имеет ряд
ограничений. Принимается допущение, что объем решаемой задачи
фиксирован (V const ), а выигрыш от дополнительных процессоров
заключается в снижении времени вычисления. В законе Амдала не учитывается
работа с памятью и издержки коммуникации между процессорами, а также он
применим для равночастотных ЦП одинаковой архитектуры [54, 55].
Если допустить, что число процессоров неограниченно, то получим
1limn
Slp
. (5)
Допустим, доля последовательной части составляет 50%. Тогда из (5)
следует, что теоретически невозможно получить ускорение более чем в два
раза при неограниченном числе процессоров.
2.4.1 Модель ускорения многоядерных ЦП на основе закона Амдала для
многоядерных систем
В 2008 году Марк Хилл и Михаэль Марти в работе «Amdahl's law in the
multicore era» [78] предложили математическую запись закона Амдала для
многоядерных процессоров и собственную методику классификации
конфигурации ЦП. Хилл и Марти ввели понятие «основной ядерный
эквивалент» (англ. Base Core Equivalent – BCE). В состав BCE входят все
функциональные блоки процессора, которые можно отнести собственно к
71
ядрам, а общие для ядер ресурсы в состав BCE не включаются. В зависимости
от способа группировки BCE на чипе, можно выделить процессоры
симметричной (гомогенной), асимметричной (гетерогенной) и динамической
конфигурации. Наиболее популярные серверные процессоры Intel Xeon можно
отнести к процессорам с симметричной конфигурацией, при которой каждое
ядро состоит из одного BCE [97]. Приводимый ранее в данной работе рисунок
21 достаточно точно отражает суть понятия «основной ядерный эквивалент» в
терминах Хилла и Марти.
Рассмотрим математическую запись закона Амдала для многоядерных
симметричных процессоров. Пусть k - общее число BCE, из которых могут
быть скомпонованы ядра; r - число BCE, составляющих ядро ЦП; /m k r
- число ядер ЦП; ( )perf r r - условная производительность одного BCE;
,lp pp - доли последовательных и параллельных операций решаемой задачи.
Закон Амдала в записи Хилла-Марти имеет следующий вид:
(1) 1 ( )( , , )
( )
( ) ( )
T perf rS m r lp
lp pp r ppT mlp
perf r perf r k m
(6)
Стоит сказать, что ограничения закона Амдала распространяются и на
его запись, предложенную Хиллом и Марти: в математическом выражении не
учитывается работа с памятью и издержки коммуникаций между ядрами, а
также разница тактовых частот ядер ЦП. При использовании одинаковых
равночастотных ядер коэффициент ( ) 1perf r .
Для расчёта линейной доли кода программы формула (6) преобразуется
в вид:
( )1
1
m perf r
Slpm
. (7)
72
Расчёт линейной доли кода имеет смысл осуществлять при 1m , т.к. в
случае использования одноядерного процессора значение ускорения 1S .
При использовании многоядерных процессоров симметричной конфигурации
с ядрами, состоящими из одного BCE каждое, коэффициент ( ) 1perf r .
Помимо ускорения, для оценки качества параллелизма весьма полезной
метрикой является эффективность использования ядер процессора,
определяемая как отношение ускорения к числу ядер:
( , , )( )
S m r lpE m
m . (8)
Стоит отметить, что в идеальном случае ускорение зависит только от
числа ядер ( , , )S m r lp m , т.е. зависимость имеет линейный вид.
Эффективность же должна стремиться к единице ( ) 1E m . Однако данные
показатели качества параллельных вычислений в некоторой степени
противоречат друг другу, поскольку с увеличением числа ядер ЦП можно
получить прирост ускорения при, как правило, снижении эффективности.
Используя выражение (6), можно теоретически рассчитать прирост
ускорения в зависимости от числа ядер процессора [6]. Покажем это на
примере модельного ряда серверных процессоров компании Intel серии Xeon
E5 v3, имеющих от 4 до 18 ядер [39]. Рассмотрены случаи, когда доля
последовательных операций составляет 5%, 15%, 30%, 50%, а также идеальное
линейное ускорение (доля последовательных операций равна нулю).
Результаты представлены на рисунке 24.
73
Рисунок 24. Рассчитанные значения ускорения при различной доле линейных
операций
Как видно из представленного графика, доля линейных операций,
является серьезным сдерживающим фактором, ограничивающим рост
ускорения при увеличении числа ядер процессора. Так, при доли линейных
операций 5% и увеличении числа ядер с 1 до 18, невозможно получить
ускорение более чем в 9,7 раз.
2.4.2 Модель ускорения многоядерных ЦП с поддержкой Hyper-
Threading
Для учета в записи закона Амдала (6) технологии Hyper-Threading
добавим коэффициент, описывающий ускорение от распараллеливания на
уровне потоков, рассчитываемый как отношение времени выполнения задачи
на ЦП без Hyper-Threading ко времени выполнения этой же задачи на ЦП с
Hyper-Threading при равном числе ядер [130]:
' mHT
mHT
TS
T (9)
74
Подставляя (9) в (6), получим запись закона Амдала для многоядерных
процессоров с Hyper-Threading:
'( )( , , ) ( , , )m
HT HT
mHT
T perf rS m r lp S S m r lp
ppTlp
m
. (10)
Исходя из такой записи закона Амдала будем в дальнейшем понимать
под долей параллельных операций pp ту часть программы, которую можно
выполнить параллельно на физических ядрах ЦП, не учитывая
распараллеливание на логические процессоры. Тогда технология Hyper-
Threading рассматривается как способ оптимизации выполнения операций на
одном ядре ЦП.
Стоит отметить, что поскольку на практике известны случаи
[31,60,72,75,137] снижения производительности системы от активации Hyper-
Threading, то в таком случае '0 1HTS .
Подставляя (10) в (8), получим формулу для расчета эффективности
использования ядер процессора с технологией HT:
( , , )( ) HT
HT
S m r lpE m
m . (11)
2.5 Выводы и результаты
Согласно классификации Флинна, современные процессоры Intel Xeon
можно отнести к классу MIMD с разделяемой памятью и поддержкой
одновременного выполнения потоков SMT. Исходя из позиционирования
линеек центральных процессоров самой компанией Intel, наиболее
подходящими моделями для программно-определяемой инфраструктуры
являются процессоры Xeon E5 2000 и 4000, поддерживающие работу в двух-
и четырёхпроцессорных конфигурациях соответственно.
Наиболее популярной метрикой для оценки эффекта от параллелизации
является ускорение. Теоретический верхний предел ожидаемого ускорения
можно описать с помощью закона Амдала. Данный закон показывает, что
ограничивающим прирост ускорения фактором является доля линейных
75
операций, которая всегда присутствует в любой программе. Данный закон
имеет вполне конкретную область применимости: принимается допущение,
что объем решаемой задачи фиксирован, а выигрыш от дополнительных
процессорных ядер заключается в снижении времени вычисления. В законе
Амдала не учитывается работа с памятью и издержки коммуникации между
ядрами, а также он применим для равночастотных ядер одинаковой
архитектуры.
В ходе выполнения данной главы диссертационной работы автором
проведен анализ моделей ускорения многоядерных процессоров на основе
законов Амдала и Хилла-Марти, а также предложена запись модели ускорения
для процессоров Intel с технологией HT.
76
3. РАЗРАБОТКА МОДЕЛИ ЗАДЕРЖКИ ОБРАБОТКИ
СЛУЖЕБНОГО ТРАФИКА В ПРОГРАММНО-КОНФИГУРИРУЕМЫХ
СЕТЯХ НА ОСНОВЕ ПРОТОКОЛА OPENFLOW
3.1 Протокол взаимодействия контроллера и коммутаторов
программно-конфигурируемой сети OpenFlow
OpenFlow и ПКС иногда используются как взаимозаменяемые понятия.
Тем не менее, следует понимать, что ПКС является архитектурой, а OpenFlow
–лишь один из протоколов, используемый для взаимодействия контроллера и
сетевой инфраструктуры, как показано на рисунке 25.
Рисунок 25. Взаимодействие контроллера ПКС с сетевой
инфраструктурой
Таким образом, контроллер общается на «языке протокола» OpenFlow с
совместимым сетевым оборудованием. OpenFlow является открытым сетевым
протоколом, который предназначен для централизованного управления
коммутационным оборудованием различных вендоров.
Спецификация протокола OpenFlow v1.0 утверждена Open Network
Foundation 31 декабря 2009 года [105]. Можно сказать, что под потоком в
терминологии OpenFlow понимается совокупность пакетов, характеризуемая
77
определенным набором полей. Записи о потоках хранятся в таблице потоков.
Для версии OpenFlow 1.0 таблица потоков состоит из следующего набора
записей: поле заголовка (header fields), счетчиков (counters) и действий
(actions). Фактически именно заголовок содержит поля, по которым возможно
назначить поток. Всего в соответствии со спецификацией протокола OpenFlow
1.0 существует 12 параметров, которые могут являться полями заголовка. Эти
параметры приведены в таблице 6.
Таблица 6. Поля Header fields OpenFlow v 1.0, определяющие поток
Поле Размер поля,
бит
Тип пакетов
Ingress Port 32 Все пакеты
Ethernet Source 48 Все пакеты на активных портах
Ethernet Destination 48 Все пакеты на активных портах
Ether Type 16 Все пакеты на активных портах
VLAN id 12 Все пакеты с Ethernet type 0x8100
VLAN priority 3 Все пакеты с Ethernet type 0x8100
IP Source 32 Все IP и ARP пакеты
IP Destination 32 Все IP и ARP пакеты
IP Protocol 8 Все IP и ARP пакеты
IP ToS bits 6 Все IP пакеты
TCP/UDP source port 16 Все TCP, UDP, ICMP
TCP/UDP destination port 16 Все TCP, UDP, ICMP
В поле счетчиков фиксируется появление совпадений. Потоки могут
соответствовать одному или более чем одному полям в таблице потоков. В
соответствии со спецификацией протокола OpenFlow 1.0, счетчики могут быть
определены для каждой таблицы (per table), потока (per flow), порта (per port)
или очереди (per queue). Список счетчиков приведен в таблице 7.
78
Таблица 7. Список счетчиков OpenFlow 1.0
Счетчик Количество бит
По таблицам
Reference Count 32
Packet Lookups 64
Packet Matches 64
По потокам
Received Packets 64
Received Bytes 64
Duration (seconds) 32
Duration (nanoseconds) 32
По портам
Received Packets 64
Transmitted Packets 64
Received Bytes 64
Transmitted Bytes 64
Receive Drops 64
Transmit Drops 64
Receive Errors 64
Transmit Errors 64
Receive Frame Alignment Errors 64
Receive Overrun Errors 64
Receive CRC Errors 64
Collisions 64
По очереди
Transmit Packets 64
Transmit Bytes 64
Transmit Overrun Errors 64
79
Поле действий служит для применения определенных действий к
пакетам при появлении совпадения. Выделяют два вида действий (actions) –
обязательные (required) и опциональные (optional). К обязательным действиям
относятся:
1) Отправка пакетов на физические или виртуальные порты
А) All – отправить пакет со всех интерфейсов, за исключением
входящего (порт, на который пакет прибыл);
Б) Local – отправить пакет на локальный порт;
В) Controller – отправить пакет контроллеру;
Г) In_Port – отправить пакет на входящий порт;
2) Сброс пакета в том случае, если с совпавшим правилом не
ассоциировано никакое действие.
К опциональным действиям относятся:
1) Отправка пакетов на виртуальные порты
А) Normal – обработка пакета с использованием коммутации второго и
третьего уровней L2 и L3, а также VLAN;
Б) Flood – рассылка пакетов по топологии связного дерева STP;
2) Enqueue – используется для обеспечения качества обслуживания
QoS, пересылает пакет через очередь на порту;
3) Modify Field – это опциональное действие, но оно позволяет во много
раз увеличить полезность протокола OpenFlow. С помощью данного действия
можно изменить VLAN или MAC-адрес источника/назначения, номер
TCP/UDP порта и т.д. Все возможные действия приведены в таблице 8.
Таблица 8. Действия по модификации полей в протоколе OpenFlow
Действие Ассоциированные
данные
Описание
Set VLAN ID 12 бит Добавляет новый заголовок,
содержащий VLAN ID и приоритет 0 или
80
Продолжение таблицы 8
замещает существующий заголовок с
VLAN ID.
Set VLAN
priority
3 бита Добавляет новый заголовок,
содержащий значение поля приоритет и
VLAN ID 0 или замещает в
существующем заголовке поле
приоритета.
Strip VLAN
header
- Отбрасывает заголовок VLAN
Modify Ethernet
source MAC
address
48 бит Замещает существующий MAC-адрес
источника на указанное значение
Modify Ethernet
destination
MAC address
48 бит Замещает существующий MAC-адрес
получателя на указанное значение
Modify IPv4
source address
32 бита Заменяет IPv4-адрес источника новым
значением и обновляет контрольную
сумму
Modify IPv4
destination
address
32 бита Заменяет IPv4-адрес получателя новым
значением и обновляет контрольную
сумму
Modify IPv4
ToS bits
6 бит Заменяет значение в поле ToS, только
для IPv4
Modify
TCP/UDP
source port
16 бит Заменяет TCP/UDP-порт источника
новым значением и обновляет
контрольную сумму
Modify
TCP/UDP
destination port
16 бит Заменяет TCP/UDP-порт получателя
новым значением и обновляет
контрольную сумму
81
Большинство производителей сетевого оборудования изначально стали
внедрять в свои устройства поддержку OpenFlow версии 1.0. Как показал опыт
эксплуатации, эта версия имела множество ограничений, делающих
невозможным реализацию преимуществ ПКС. В частности, первая версия
протокола OpenFlow делает невозможным выполнение более чем одного
действия с конкретным пакетом. Вторым существенным ограничением
является крайне небольшой объем памяти TCAM в недорогих коммутаторах,
которого хватает на 1-2 тыс. записей в таблице потоков.
В последующих версиях протокола OpenFlow функционал расширялся.
Кратко график выхода новых версий и ключевые изменения представлены на
рисунке 26.
Рисунок 26. Эволюция протокола OpenFlow
Версии 1.1 и 1.2 по сути являлись промежуточными и не были
поддержаны производителями сетевых устройств, хотя и содержали крайне
важные нововведения, такие как Multi-table, Group-table, позволяющие
применять к пакету более одного действия, полноценная поддержка VLAN и
MPLS [106], внедрение поддержки IPv6, возможности смены роли
контроллера в кластере (master/slave/equal), что увеличивало
отказоустойчивость [107]. Широкую поддержку получила версия 1.3 [108],
82
принесшая с собой такие нововведения, как Meters table для расширения
функционала QoS (DSCP-биты) и внедрения модели обслуживания DiffServ.
Ключевыми отличиями версии 1.4 [109] стали появившиеся механизмы
синхронизации таблиц и группировки связанных изменений состояния – т.н.
Bundle – которые полезны для подготовки и предварительной проверки
OpenFlow-сообщений для рассылки на множество коммутаторов. Версия
OpenFlow 1.5 [110] предлагает механизмы управления выходной очередью в
виде Egress table, а также вводит время выполнения для Bundle. В ходе
эволюции протокола OpenFlow изменениям подверглась структура полей
таблицы потоков. Так, количество полей таблицы потоков OpenFlow 1.5.1
увеличено в два раза в сравнении с версией 1.0: к уже существовавшим
добавились поля приоритет (priority), время жизни (timeouts) и cookie.
Совокупность сведений в поле соответствия и приоритета идентифицирует
уникальную запись потока в таблице потоков. Однако определяющие поток
данные, занесенные в поле заголовка/совпадения, фактически не претерпели
изменений в процессе развития протокола OpenFlow. Поток характеризуется
набором полей, содержащих сведения L1-L4 OSI, показанных на рисунке 27.
Рисунок 27. Поля, по которым может определяться поток OpenFlow
Протокол OpenFlow, независимо от версии, поддерживает три типа
сообщений:
контроллер-коммутатор;
асинхронные;
симметричные.
Сообщения типа контроллер-коммутатор инициируются контроллером
и используются для управления и контроля состояния коммутатора.
Сообщения данного типа могут использоваться контроллером для
установления и запроса параметров конфигурации OpenFlow коммутатора,
83
для сбора статистических данных с коммутаторов, для добавления, удаления
и модификации записей в таблицах потоков [44]. Для версии OpenFlow 1.0
существует шесть видов сообщений коммутатор-контроллер:
Read state - используется контроллером для чтения счетчиков
(counters) потоков (per flow), портов (per port) и очередей (queue);
Modify state – используется преимущественно для добавления,
удаления или изменения потоков в таблицах потоков на коммутаторе;
Send packet – используется для отправки пакетов из определенного
порта коммутатора;
Barrier request/replies – используется для получения
подтверждений о завершении операций коммутатором. Если коммутатор
получил сообщение о запросе блокировки от контроллера, то он должен
завершить все текущие задачи. Коммутатор может перейти к следующей
задаче только после завершения текущей. Как только коммутатор завершит
все задачи, он отправляет подтверждение блокировки контроллеру и начинает
выполнять следующую задачу;
Features – это сообщения, с помощью которых контроллер
запрашивает сведения о поддерживаемых коммутатором функциях;
Configuration – используется контроллером для получения и
установки параметров коммутатора.
В версии протокола OpenFlow 1.3 существует восемь видов сообщений:
Read state, Modify state, Barrier, Features, Configurations остались
без изменений;
Role-Request – используется для выбора роли контроллера в
кластере;
Packet out используется взамен Send packet и расширяет
возможности – данные сообщения используются контроллером для отправки
пакетов из указанного порта на коммутаторе и для пересылки пакетов,
полученных через сообщения Packet-in. Сообщения Packet out должны
содержать полный пакет или идентификатор буфера, указывающий на пакет,
84
хранящийся в коммутаторе. Сообщение должно также содержать список
действий, которые должны применяться в том порядке, в котором они
указаны;
Asynchronous-configuration - используется контроллером для
установки дополнительного фильтра для асинхронных сообщений или для
запроса этого фильтра. В основном используется при организации кластера
контроллеров.
Сообщение асинхронного типа инициируются коммутатором для
оповещения контроллера о сетевых событиях (прибытии пакетов или
удалении записи из таблицы по тайм-ауту), а также об изменениях состояния
коммутатора или ошибках. Они бывают четырех разных видов (как в версии
протокола 1.0, так и 1.3):
Port status – сообщения о любых изменениях статуса порта
отправляются контроллеру. Под изменением статуса порта понимается не
только отключение порта, но и изменение топологии связующего древа STP;
Packet in – это сообщение отправляется контроллеру только в тех
случаях, когда для входящего пакета на коммутаторе не найдено совпадений
в наборе записей (в этом случае пакет должен быть отправлен на контроллер)
или пакет соответствует правилу и должен быть отправлен на контроллер;
Flow removed – для наборов записей, добавленных в таблицу
потоков существует два тайм-аута: тайм-аут простоя (idle timeout) и жесткий
тайм-аут (hard timeout). Всякий раз при удалении потока из-за превышения
тайм-аута, коммутатор отправляет контроллеру сообщение об изменении
потока «flow removed»;
Error – отправляется коммутатором контроллеру для
информирования о любых ошибках.
Сообщения симметричного типа могут инициироваться коммутатором
или контроллером без запроса и используются при установлении соединения.
Помимо этого, такие сообщения могут также использоваться для измерения
85
задержек, пропускной способности соединения контроллер-коммутатор или
проверки состояния соединения. Выделяют три вида сообщений:
Hello – как и во многих других протоколах, обмен
приветственными сообщениями происходит между контроллером и
коммутатором при запуске;
Echo – эти сообщения служат для измерения задержек соединения
между контроллером и коммутатором;
Vendor – сообщения, несущие в себе информацию о
дополнительной функциональности коммутаторов.
В версии OpenFlow 1.3 сообщение Vendor заменено на Experimenter с
аналогичным функционалом.
3.2 OpenFlow-коммутатор
В ПКС-коммутаторе с поддержкой протокола OpenFlow можно
выделить следующие логические компоненты:
-OpenFlow канал – отвечает за связь с внешним ПКС-контроллером и
приём от него управляющих команд; по сути организует связь плоскостей
управления и данных;
-Таблица потоков;
- Групповая таблица;
-Таблица метрик;
-Порты.
Порты, таблицы потоков, групп, метрик (и прочие функции,
определяемые спецификацией протокола) являются элементами data plane.
В их задачи входит обеспечение продвижение пакета с входного на
выходной порт. Сами же таблицы программируются командами в ПКС-
контроллера.
86
Рисунок 28. Устройство ПКС-коммутатора с поддержкой OpenFlow
OpenFlow-совместимые коммутаторы делятся на два типа: чистые
OpenFlow коммутаторы и гибридные. Коммутаторы первого типа
поддерживают работу только по протоколу OpenFlow. В таких устройствах все
пакеты обрабатываются потоками OpenFlow и не могут быть обработаны
иначе.
Гибридные OpenFlow коммутаторы поддерживают оба режима работы:
OpenFlow и обычную Ethernet-коммутацию (традиционную L2-коммутацию,
VLAN, маршрутизацию и т.д.). Например, коммутатор может использовать тег
VLAN или входной порт пакета для принятия решения о его продвижении или
может направить все пакеты на обработку по протоколу OpenFlow. Этот
механизм классификации выходит за рамки данной спецификации. Гибридные
коммутаторы могут также пропускать пакеты от обработки OpenFlow к
нормальной обработке через обычные или потоковые зарезервированные
порты.
В спецификации OpenFlow определяется следующий набор стандартных
портов – physical, logical и reserved. Physical –физические порты коммутатора.
87
Логические (logical) порты напрямую не привязаны к физическим портам
оборудования (MPLS LSP, Null интерфейсы). Зарезервированные порты
зачастую используются в гибридных коммутаторах (OpenFlow +
традиционная сеть). Детальное описание типов и функционала портов
приводится в спецификациях протокола OpenFlow [105-110].
Любой OpenFlow-коммутатор, в зависимости от поддерживаемой
версии протокола, содержит одну или более таблиц потоков, каждая из
которых содержит множество записей потоков. Процессы обработки
OpenFlow определяют, как пакеты взаимодействуют с этими таблицами
потоков. Коммутатор OpenFlow нуждается хотя бы в одной входящей таблице
потоков. Поточная обработка на коммутаторе с единственной таблицей
потоков существенно упрощается. Таблицы потоков последовательно
нумеруются, начиная с нуля. Поточная обработка проходит в два этапа:
обработка на входе и выходе. Разделение этих двух этапов обозначается
первой выходной таблицей. Все таблицы, номера которых ниже первой
выходной таблицы должны использоваться как входные, а таблицы с
номерами выше либо равные первой выходной таблице, так же могут быть
использоваться как выходные.
На рисунке 29 представлена приблизительная блок-схема алгоритма
действий, совершаемых с пакетом внутри коммутатора с поддержкой
OpenFlow 1.5 [110] до момента его отправки через исходящий порт (т.н.
pipeline). Поточная обработка всегда начинается с входящей обработки на
первой таблице потоков: пакет должен сначала сопоставиться с записями
потоков таблицы под номером 0. Остальные входные таблицы могут быть
использованы исходя из результатов сравнения с первой таблицей. В
результате совпадения входной обработки пакет отправлен на выходной порт,
коммутатор может выполнить выходную обработку в контексте данного
выходного порта. Обработка исходящих данных не обязательна и коммутатор
может не поддерживать выходные таблицы или может не использовать их.
Если ни одна выходная таблица, не установлена как первая выходная таблица,
88
тогда пакет обязан быть обработан выходным портом и в большинстве случаев
отправлен. Если выходная таблица установлена как первая выходная, пакет
обязан быть сравнен с записями потоков этой таблицы и остальные выходные
таблицы могут быть использованы исходя из результатов сравнения пакета с
этой таблицей.
При обработке таблицей потоков, пакет сравнивается со всеми записями
потоков данной таблицы. Если запись найдена, применяется инструкция,
занесенная с этой записью. Эти инструкции могут строго направить пакет в
другую таблицу потоков, где тот же процесс повторится снова. Запись потока
может направлять пакет только в таблицы с большим номером, чем номер
таблицы, к которому она принадлежит. Если соответствующая запись потока
не отправляет пакеты к другой таблице, то на данном этапе конвейерная
обработка данных останавливается, пакет обрабатывается соответствующим
набором действий и, как правило, отправляется.
Если пакет не совпадает с записями потоков в таблице, коммутатор
расценивает данный процесс как несовпадение с данной таблицей потоков.
Поведение таблицы при несовпадениях зависит от конфигурации таблицы.
Инструкции, заложенные в отсутствующие записи потоков таблицы могут
гибко указывать как поступить с несогласованными пакетами. Полезными
опциями являются отбрасывание пакетов, проверка их с другой таблицей или
отправка пакетов на контроллер по каналу управления в качестве packet-in
сообщений.
Существует несколько случаев, когда пакет не полностью обработан
записью потока и поток обработки останавливается без установки действия
для пакета или направления его к другой таблице. Если не существует
несовпадений с таблицей, пакет отбрасывается. Если найдено недопустимое
значение TTL, пакет может быть отправлен на контроллер.
89
Рисунок 29. Блок-схема алгоритма обработки пакета на OpenFlow-
коммутаторе
3.3 Классификация задержек служебного трафика протокола ARP в
программно-конфигурируемых сетях
В традиционных локальных вычислительных сетях в процессе передачи
пакетов данных от одного узла к другому важную роль играет процесс
определения адресов, осуществляемый в соответствии с протоколом
определения адреса ARP, описанным в RFC 826 [129]. Однако механизм для
90
обработки ARP-запросов и ARP-ответов в программно-конфигурируемых
сетях отличается от данного механизма в традиционных сетях IP. В ПКС при
отсутствии на коммутаторах записей о направлении ARP-пакетов механизм
определения адресов должен быть выполнен, в первую очередь, на
контроллере — программно-аппаратной платформе, реализующей
интеллектуальные функции сети [42].
В работе Internet Draft «Address Resolution Delay in SDN» [118],
являющейся рабочим документом Инженерного совета Интернета (IETF) и
опубликованной в октябре 2014 года, определяются две метрики, которые
можно применить для характеристики задержки механизма определения
адреса:
1) Address Resolution Delay No Forwarding Flow Registrations ( ARDNFFR )
— задержка определения адреса без установки потока для передачи пакета на
коммутаторе;
2) Address Resolution Delay Forwarding Flow Registrations ( ARDFFR ) —
задержка определения адреса с установкой потока для передачи пакета на
коммутаторе.
Дадим определения этим величинам, основываясь на топологии сети,
представленной на рисунке 30, где С — контроллер; S — коммутатор; 0H и
1H — узлы в сети.
Рисунок 30. Логическая схема сети
91
Определение 1: Рассмотрим задержку ARDNFFR. Пусть узел H1
отправляет первый бит пакета ARP-запроса узлу H0 в момент времени 1HT ,
тогда H1 принимает первый бит ARP-ответа от H0 в момент времени 1H NFT d
при отсутствии требуемой ARP-записи в таблице потоков (кэше) коммутатора.
Получаем, что задержка ARDNFFR есть величина NFd . Единицами
измерения данного параметра являются миллисекунды. За эталонное значение
принимается время первого прохождения пакета по сети при отсутствии
установленных потоков на коммутаторах для ARP-пакетов [40, 74, 118].
С учетом определения 1 и топологии сети, представленной на рисунке,
предложим формулу для оценки данной метрики задержки:
,NF NF NFd L C S (12)
где L — задержка в каналах связи; NFC — задержка обработки на
контроллере; NFS — задержка обработки на коммутаторе без установленных
правил.
Очевидно, что с ростом размера сети и усложнением топологии значение
задержки определения адреса без установки потока для передачи пакета на
коммутаторе NFd будет расти.
Определение 2: Рассмотрим задержку ARDFFR. Пусть узел H1
отправляет первый бит пакета ARP-запроса узлу H0 в момент времени 1HT ,
тогда H1 принимает первый бит ARP-ответа от H0 в момент времени 1HT d
при наличии требуемой ARP-записи в таблице потоков (кэше) коммутатора.
Получаем, что задержка ARDFFR есть величина d . Единицами измерения
данного параметра являются миллисекунды. За эталонное значение
принимается время первого прохождения пакета по сети при наличии
установленных потоков на коммутаторах для ARP-пакетов [40, 74, 118].
С учетом определения 2 и топологии сети, представленной на рисунке
30, предложим формулу для оценки данной метрики задержки:
,d L S (13)
92
где L — задержка в каналах связи; S — задержка обработки на коммутаторе
с установленными правилами.
Очевидно, что с ростом размера сети и усложнением топологии значение
з
а
д
е
р
ж
к
и
о
п
р
е
д
е
л
е
н
и
я
а
д
р
е
с
а
с
у
Исходя из определений 1 и 2, а также формул (12), (13) можно сделать
вывод, что задержка механизма определения адресов в ПКС будет превышать
значения задержки в аналогичной традиционной сети с коммутацией пакетов
только в том случае, когда на коммутаторе отсутствует запись в таблице
потоков.
Применение d вместо NFd обусловлено следующими факторами:
– определение адреса с установленными потоками на коммутаторах
является основной формой механизма определения адреса в ПКС;
– когда время жизни ARP-таблиц на коммутаторе заканчивается, узел
должен вновь инициировать механизм определения адреса, а значит и
установку потока на коммутаторах.
Высокое значение параметров d и NFd может свидетельствовать о
проблемах на одном или более сегментах сети, а значит, данный параметр
может быть использован для диагностики программно-конфигурируемой сети
в целом [40].
Рассмотрим возможность использования двух перечисленных
параметров для оценки программно-конфигурируемых сетей.
Введем следующие обозначения:
1,0H H — сетевые узлы;
0C — контроллер;
iT — временной интервал, в течении которого на коммутаторах
существуют записи о потоках, с;
0 , fT T — временные границы рассматриваемого интервала, с;
λ — интенсивность потока, 1/с.
93
В [118] выдвинуто предположение, что поток ARP-пакетов можно
рассматривать в качестве Пуассоновского. Имея значения 0 , fT T и λ, можно
описать псевдослучайный Пуассоновский процесс на временном интервале
0 , fT T с интенсивностью поступления пакетов λ. В каждый момент времени
iT значением задержки для первого процесса механизма определения адреса
является параметр NFd , а для последующих процессов механизма
определения адреса — значения параметра d Далее можно получить
значение параметров NFd и d на промежутке от 0T до fT c интервалом iT .
Согласно [16], поток событий — последовательность событий,
происходящих одно за другим в случайные моменты времени.
Пуассоновский поток — это поток, обладающий двумя свойствами —
ординарностью и отсутствием последействия.
Поток называется ординарным, если для малого интервала t
выполняется условие
1 1( , ) ( , ),P t t P t t (14)
где 1( , )P t t — вероятность того, что за t произойдёт одно событие, 1( , )P t t
— вероятность того, что за t произойдёт более одного события.
Таким образом, поток можно считать ординарным, если за малый
промежуток времени может произойти не более одного события (или ни
одного события, вероятность чего обозначим 0( , ).P t t Для любого t
справедливо
0 1 1( , ) ( , ) ( , ) 1,P t t P t t P t t (15)
так как составляющие формулы (15) определяют полную группу
несовместных событий.
Для ординарного потока
0 1( , ) ( , ) 1,P t t P t t (16)
потому что 1( , ) 0( ),P t t t где 0( )t — величина, порядок малости которой
выше чем t [16], т. е.
94
Δt 0
0( )lim = 0.
t
t
(17)
Рассмотрим интервал 0 , ,f iT T mT представленный на рисунке 31.
Рисунок 31. Рассматриваемый интервал 0 , fT T
Отсутствие последействия — свойство, когда для двух
неперекрывающихся интервалов времени число событий, попадающих в один
интервал, не зависит от того, сколько событий попало в другой [16].
Воспользуемся формулой распределения Пуассона для оценки
вероятности возникновения k-запросов от коммутатору к контроллеру на
установление правила на временном интервале 0 , .f iT T mT Получим
λ(λ ).
!i
NF
mTid
mTP e
k
(18)
Тогда вероятность возникновения n -событий в режиме
функционирования с установленными правилами на коммутаторе будет
определяться формулой
1 .NFd dP P (19)
Таким образом, согласно [118], общая задержка ,D возникающая при
функционировании механизма определения адреса может быть вычислена как
,NFD l d n d (20)
где l и n — число временных интервалов, к которым применимы параметры
задержки NFd и d соответственно.
Из полученных результатов исследования можно сделать ряд выводов.
1. Если величина iT стремится к бесконечности, то параметр d будет
преобладать над NFd . В противном случае может практически не быть d .
95
2. Если величина λ стремится к бесконечности, то параметр NFd
ничтожно мал на фоне d поскольку только одно из всего множества событий
на интервале iT будет соответствовать режиму функционирования сети без
установленных потоков на коммутаторах. В противном случае, если λ
слишком мала, вероятность возникновения ARP-запросов на интервале
0 , f iT T mT может стремиться к нулю.
Полученные формулы оценки задержек в программно-
конфигурируемых сетях имеют практическую ценность, поскольку позволяют
сетевому инженеру получить конкретные значения времени обработки
пакетов на каждом из устройств сети. В случае если величина задержки на
контроллере весьма велика, системный администратор может сделать вывод о
необходимости оптимизации работы ПКС-контроллера либо путем
перенастройки установленных правил, либо путем модернизации аппаратной
части.
3.4 Среда моделирования Mininet
Mininet представляет собой эмулятор сети, который может
использоваться исследователями ПКС и разработчиками программного
обеспечения для ПКС для создания моделей сети, функционирующей на
основе протокола OpenFlow [99]. Данный эмулятор поставляется в виде образа
виртуальной машины, который может быть запущен с помощью VirtualBox.
Mininet позволяет создавать модели сети, включающие несколько устройств и
рабочих станций-хостов, соединённых сетевыми интерфейсами, с
возможностью включать-выключать сетевые интерфейсы, генерировать
трафик и иметь возможность просматривать и снимать дампы пакетов как на
хостах, так и на транзитных интерфейсах. Разработанная сеть может быть
представлена в виде виртуальной машины, следовательно, другие
разработчики могут легко воспользоваться смоделированным сегментом сети.
96
Mininet поставляется вместе с ПКС-контроллером NOX, но также
имеется возможность использования сторонних контроллеров. Эмулятор
может создавать различные базовые топологии, например single, linear, tree.
Топология single состоит из одного коммутатора и позволяет создавать
различное число абонентских сетевых узлов. Топология linear позволяет
создавать линейную топологию, задавая при этом число коммутаторов и
абонентских узлов. Топология tree – древовидная топология с различным
числом уровней. Каждый коммутатор связан с контроллером по протоколу
OpenFlow. Базовые топологии представлены на рисунке 32.
Mininet позволяет моделировать любые сетевые топологии с
использованием Python API. Разработанная модель позволяет получить такие
данные о сети, как полоса пропускания, задержка, очереди, а также
просматривать состояние коммутаторов, их интерфейсов, таблиц потоков
OpenFlow на коммутаторах и т.д. Кроме того, создание прототипа сети в
mininet может быть полезно и для тестирования разработанного приложения
для ПКС-контроллера, после чего возможно практически без изменений в коде
протестировать приложение на реальном сегменте сети. Данная система
моделирования имеет достаточно подробную документацию.
Рисунок 32. Базовые топологии mininet
97
3.5 Экспериментальное установление алгоритма обработки ARP-
запросов
Для исследования служебного трафика в ПКС был создан
экспериментальный стенд с использованием среды mininet и контроллера под
управлением СОС OpenDaylight Hydrogen со стандартным приложением для
коммутации «Simple Forwarding». Схема стенда показана на рисунке 33.
Тестовый стенд запускался на ПК, снабженном центральным процессором
Core i5-520M 2,4 ГГц (4 ядра), ОЗУ 4Гб, Windows 7 32 bit. В среде mininet была
смоделирована топология single, состоящая из одного коммутатора и двух
хостов. Коммутатор для взаимодействия с контроллером использовал
протокол OpenFlow 1.0. С хоста H1 с помощью команды ping генерировались
ICMP-запросы до хоста H0. С помощью сниффера пакетов Wireshark были
проанализированы пакеты служебного OpenFlow-трафика, которые возникали
в ходе данной процедуры определения адреса [74].
Рис. 33. Исследуемая топология в эксперименте 1
По результатам анализа дампа трафика была построена диаграмма
сообщений, представленная на рисунке 34.
98
Рисунок 34. Диаграмма обмена сообщениями при работе протокола ARP
Рассмотрим подробнее данную диаграмму. Для успешного прохождения
ICMP-запроса узел H1 должен узнать MAC-адрес узла H0, для чего
отправляется ARP-запрос коммутатору S. Этот запрос коммутатор
инкапсулирует в OpenFlow-сообщение асинхронного типа Packet_in и далее
отправляет контроллеру C, поскольку для входящего пакета на коммутаторе
не найдено совпадений в наборе записей. Контроллер с помощью OpenFlow-
сообщения типа контроллер-коммутатор Flow_mod даёт команду
коммутатору запомнить расположение узла H1. Следующим шагом
контроллер рассылает ARP-запрос, инкапсулированный в сообщение
Packet_out, только на те порты коммутатора, к которым подключены узлы.
Узел, обнаруживший совпадение искомого MAC-адреса с собственным,
отправляет в сеть ARP-ответ, который ретранслируется коммутатором на
99
контроллер. Контроллер теперь знает расположение узла H0 и устанавливает
соответствующее правило в таблице потоков коммутатора, после чего ARP-
ответ отправляется узлу H1. После обновления ARP-таблицы, узел H1 может
отправлять IP-пакеты узлу H0 (в нашем эксперименте – ICMP-пакет). Далее
узлу H0 потребуется отправить ответный ICMP-пакет узлу H1. Особенностью
механизма определения адреса по протоколу ARP в ПКС является тот факт,
что заголовки Source IP/MAC перенаправляемого контроллером ARP-ответа
будут иметь значения, принадлежащие IP и MAC самого ПКС-контроллера. А
значит, сгенерированный узлом H0 ARP-запрос будет передан коммутатором
контроллеру в виде сообщения Packet_in. Далее контроллер с помощью
сообщения Packet_out установит правило для коммутатора, который в свою
очередь отправит ARP-ответ узлу H0. Узел H0 обновит свою ARP-таблицу и
сможет отправить ICMP-пакет узлу H1 [41].
Описанный выше процесс установления соединения для двух сетевых
элементов можно условно представить в виде двух этапов:
1) Этап установления соединения от корневого сетевого элемента H1 до
искомого H0;
2) Этап установления соединения от искомого сетевого элемента H0 до
корневого H1 [41].
3.6 Экспериментальное выявление зависимости задержки передачи
служебного трафика от задержки контроллера
Для выявление зависимости между задержкой передачи служебного
трафика и задержкой контроллера в сети, функционирующей с
использованием протокола OpenFlow в среде mininet была смоделирована
древовидная топология, показанная на рисунке 35. Число коммутаторов
последовательно задавалось равным 3, 7, 15 и 31. Выполнялась команда ping с
узла H1 до H2, после чего с использованием Wireshark выполнялась
фильтрация трафика и высчитывалась задержка NFd , задержка коммутатора
NFS и задержка контроллера NFС , представленные в формуле (12). При этом
100
задержка коммутатора NFS считалась как среднее арифметическое по всем
OpenFlow- коммутаторам.
Рисунок 35. Исследуемая топология в эксперименте 2
Результаты измерений, сделанных в ходе теста занесены в таблицу 9.
Таблица 9. Экспериментальные значения задержек
Количество
коммутаторов в сети, шт.
Задержка NFd
, мс
Задержка NFS ,
мс
Задержка NFС ,
мс
3 9,868 0,184 4,688
7 12,236 0,240 7,433
15 16,252 0,431 6,847
31 23,881 1,870 11,441
По результатам проведенного исследования был построен график,
показанный на рисунке 36.
101
Рисунок 36. Зависимость задержек от количества коммутаторов в сети
Исходя из характера кривых на графике, была выдвинута гипотеза о
наличии зависимости (корреляции) между исследуемыми параметрами. Для
проверки этого предположения были осуществлен расчет коэффициентов
корреляции попарно для экспериментальных массивов значений NFd и NFС ,
NFd и NFS согласно следующему уравнению:
2 2 2 2
( )( )
( ) ( )
xy x yr
n x x n y y
. (21)
Полученные значения ( , ) 0,935NF NFr d C , ( , ) 0,951NF NFr d S
указывают на наличие положительной линейной корреляции между
исследуемыми параметрами, т.е. с ростом/уменьшением значения одного из
них параметров будет расти/уменьшаться и другой. Таким образом, показано,
что снижение величины задержки, вносимой ПКС-контроллером, приведёт к
снижению задержки передачи служебного трафика ПКС.
102
3.7 Выводы и результаты
В данной главе были рассмотрены существующие спецификации
протокола OpenFlow, выявлены отличия между версиями, дано понятие
потока. Показано, что протокол OpenFlow 1.0 имеет ряд ограничений,
затрудняющих его использование в реальных сетях: невозможность
выполнения более чем одного действия с конкретным пакетом и крайне
небольшой объем памяти, хранящей таблицы потоков. Сделан вывод о том,
что для практического развертывания ПКС необходимо оборудование с
поддержкой OpenFlow 1.3. Рассмотрено устройство OpenFlow-коммутатора и
процесс обработки пакета.
Представлена модель задержки обработки служебного трафика в сетях,
базирующихся на протоколе OpenFlow, показан её вывод на основе принципа
работы протокола ARP. На основе исследования полученной модели можно
сделать вывод о том, что существует положительная линейная зависимость
между задержкой передачи служебного трафика NFd , составляющими ее
задержкой коммутатора NFS , задержкой ПКС-контроллера NFС . В случае
высокого уровня задержки служебного трафика ее можно понизить путем
снижения задержки коммутаторов либо контроллера. Задержка, вносимая
коммутаторами, определяется такими факторами, как производительность
коммутационной матрицы, размером буфера и наличием очередей пакетов на
интерфейсах.
Задержка, вносимая контроллером, зависит как от производительности
его аппаратной платформы, так и от эффективности оптимизации
программного кода СОС контроллера и приложений. Для снижения задержки
контроллера рекомендуется выбирать аппаратную платформу сервера с
максимальной производительностью и оптимизировать работу приложений,
выполняющих функции управления трафиком, что в свою очередь может
привести к снижению пакетной нагрузки на систему.
103
4. ИССЛЕДОВАНИЕ МАСШТАБИРОВАНИЯ
ЗАДЕРЖКИ ПКС-КОНТРОЛЛЕРА НА АППАРАТНЫХ
ПЛАТФОРМАХ С МНОГОЯДЕРНЫМИ ЦЕНТРАЛЬНЫМИ
ПРОЦЕССОРАМИ
4.1 Разработка методики проведения тестирования
В настоящее время международными стандартизирующими
организациями ведётся работа по созданию рекомендаций,
регламентирующих процесс тестирования различных параметров
производительности и отказоустойчивости программно-конфигурируемых
сетей. В частности, Open Network Foundation в ноябре 2016 года опубликовала
документ ONF TR-539 «OpenFlow Controller Benchmarking Methodologies»
[104], в котором предлагаются методологии тестирования канала контроллера
и процесса установки контроллером потоков на управляемых коммутаторах.
Методология тестирования задержки ПКС-контроллера, используемая в
данной работе, опирается на рекомендации пункта 10 «Controller Message
Processing Latency» [104, c.54-57].
В проекте рекомендации IETF draft Benchmarking Methodology for SDN
Controller Performance [81] в пункте 5.1.2 «Asynchronous Message Processing
Time» даётся определение задержки контроллера в следующем виде:
«Задержка есть время, необходимое контроллеру на обработку одного
асинхронного сообщения, отправляемого для установки нового потока на
коммутаторе. Единицами измерения являются миллисекунды. Чем меньше
задержка, тем выше производительность контроллера». В этом же пункте
предлагается способ расчёта задержки контроллера и формат вывода
результатов теста.
В качестве тестового трафика рекомендуется использовать запросы на
установку новых потоков на коммутаторах, генерируемые тестовым
эмулятором (системой-нагрузчиком). В документе отмечается, что контроллер
может устанавливать как зашифрованный канал связи с ПКС-узлами, так и
104
канал без поддержки шифрования. Так же ПКС-контроллер и ПКС-узлы могут
поддерживать различные версии протоколов южного интерфейса, например,
OpenFlow 1.0 и OpenFlow 1.3. В подобном случае рекомендуется при
осуществлении тестирования предусматривать следующие способы установки
соединения контроллер-коммутатор:
- Установление незащищённого канала связи между контроллером и
коммутатором с использованием одинаковых версий протокола южного
интерфейса;
- Установление незащищенного канала связи с использованием разных
версий протокола южного интерфейса:
(1) Запуск на контроллере актуальной версии протокола, а на
коммутаторе устаревшей;
(2) Запуск на контроллере устаревшей версии протокола, а на
коммутаторе актуальной;
- Установление защищённого канала связи между контроллером и
коммутатором с использованием одинаковых версий протокола южного
интерфейса;
- Установление защищенного канала связи с использованием разных
версий протокола южного интерфейса:
(1) Запуск на контроллере актуальной версии протокола, а на
коммутаторе устаревшей;
(2) Запуск на контроллере устаревшей версии протокола, а на
коммутаторе актуальной.
При проведении тестирования рекомендуется подключать ПКС-
контроллер напрямую к нагрузчику, минуя промежуточные узлы, которые
способны внести искажения в результаты измерений.
Точность измерений зависит в том числе и от точки съёма параметров.
Разработчиками рекомендации указано, что следует снимать значения
измеренных параметров на стороне нагрузчика, а не тестируемой системы,
105
если иное прямо не указано в методологии тестирования конкретного
параметра контроллера.
В Benchmarking Methodology for SDN Controller Performance также
отмечается, что для повышения достоверности получаемых измерений
следует повторять каждый тест минимум 10 раз [81]. Проект рекомендации
предлагает и форму отчета о тестировании, который должен включать в себя
следующие параметры:
- Название и версия ПКС-контроллера;
- Протоколы северного интерфейса и их версии;
- Протоколы южного интерфейса и их версии;
- Режим резервирования контроллера: одиночный или кластерный;
- Тип установленного канала связи контроллер-коммутатор:
защищенный или незащищенный;
- Тип сетевой топологии;
- Тип коммутатора: аппаратный (физический), виртуальный или
эмулируемый;
- Количество коммутаторов;
- Количество каналов в сети;
- Тип тестового трафика;
- Описание системы ПКС-контроллера: ЦП, ОЗУ, версия ОС,
пропускная способность сетевых адаптеров.
4.2 Анализ программного обеспечения для тестирования ПКС-
контроллера
Таким образом, используемые при тестировании ПКС-контроллера
утилиты должны позволять проводить измерение задержки в соответствии с
предлагаемыми указанными рекомендациями методологией измерения
параметра и выводить данные в соответствующем формате. На данный момент
существует весьма ограниченный перечень утилит тестирования ПКС-
контроллеров, которые можно условно классифицировать на платные
106
коммерческие продукты и свободно распространяемые [20]. К категории
коммерческих утилит можно отнести следующие программные средства:
- PktBlaster от компании Veryx Technologies;
- IxNetwork SDN Test Solution от компании Ixia Networks;
- Twister Test Automation Framework от компании Luxoft.
Среди свободно распространяемых утилит можно выделить:
- Cbench benchmarking tool – первая специализированная утилита,
разработанная группой специалистов из Университета Торонто, Nicira
Networks, Big Switch Networks во главе с Робертом Шервудом, считается
«классическим» стандартным программным средством оценки
производительности ПКС-контроллера [58];
- CtlTest - набор скриптов, разработанный в российском ЦПИКС для
автоматизации тестирования с использованием Cbench [66];
- WCbench, представляющий собой надстройку над Cbench в виде
скриптов, позволяющих автоматизировать процесс тестирования, обработки
информации и построения графиков с результатами [147];
- OFC Benchmarking Tool, разработанный коллективом из Университета
Вюрцбурга в Германии, и также основанный на Cbench, позволяет
дополнительно оценивать загрузку ЦП, ОЗУ ПКС-контроллера [114].
Выбор программного обеспечения для исследования осуществлялся из
числа свободно распространяемых утилит. Автором было принято решение
использовать утилиту Cbench по ряду причин:
- наличие достаточно широкой базы имеющихся результатов
тестирования по причине высокой популярности средства у других
исследователей, с которыми можно сопоставить собственные данные;
- наличие большого числа справочного материала с описанием решения
технических проблем на форумах.
Однако выбранное средство имеет ряд недостатков, среди которых
поддержка ключевым является однопоточность, приводящая к необходимости
запуска нескольких экземпляров утилиты для эффективного использования
107
многоядерных процессоров. Также Cbench способен создавать только одно
соединение с контроллером для всех эмулируемых коммутаторов и
осуществляет сбор статистики со всех коммутаторов, но не с каждого в
отдельности, в результате чего отсутствует возможность установить, каким
коммутаторам адресованы ответы контроллера (возможна ситуация, при
которой все ответы контроллера адресованы одному коммутатору).
4.3 Экспериментальный стенд и методология исследования
В соответствии с рекомендациями производителей коммерческих
версий СОС, базирующихся на OpenDaylight [3], для экспериментального
стенда были выбраны серверы, снабженные ЦП Intel Xeon E3-1241v3 и Xeon
E5-2670v3, имеющие 4 и 12 вычислительных ядер соответственно. Автором
использовалась опробованная ранее методология тестирования [4, 17]. Схема
стенда представлена на рисунке 37.
Рисунок 37. Схема экспериментального стенда
Для испытываемого ПКС-контроллера и нагрузчика Cbench
использовались различные аппаратные платформы, таким образом эти
системы физически разделены. В качестве СОС выступал OpenDaylight, релиз
108
Beryllium-SR1, версия Java 8.0 (платформа Java SE 1.8.0_101-b13), объем
памяти, выделяемый JVM, составлял 8 Гб.
На сетевых интерфейсах контроллера и сервера-нагрузчика назначены
IP-адреса 192.168.1.1 и 192.168.1.2 соответственно.
Подробно процедура установки и настройки СОС OpenDaylight
приведена в приложении В.
Нагрузочная утилита Cbench запускалась в виртуальной машине Oracle
Virtual Box 5.0.20 в среде операционной системы Ubuntu 14.04. Виртуальной
машине были выделены 4 ядра процессора и 24 Гб оперативной памяти
сервера-нагрузчика. Оба сервера соединены каналом с пропускной
способностью 1 Гбит/с. Для фиксации тактовой частоты ЦП и соблюдения
условий выполнения закона Амдала технология динамического повышения
тактовой частоты ЦП Intel TurboBoost была отключена в BIOS. Замеры
проводились как для случая активной технологии Hyper-Threading, так и
деактивированной в BIOS.
Жесткий диск Western Digital Blue WD10EZEX SATA (7200
оборотов/мин, буфер 64 Мб, объем 1 Тб) с операционной системой Ubuntu
Server 14.04, установленной СОС OpenDaylight, платформой Java переносился
физически с ПКС-контроллера 1 на ПКС-контроллер 2 для исключения
влияния скорости дисковых операций чтения/записи и различий в
установленных версиях программного обеспечения.
Конфигурация аппаратных платформ компонентов тестового стенда
приведена в таблице 10.
Таблица 10. Компоненты тестового стенда и их аппаратная конфигурация
Компонент
стенда
ЦП Объем
ОЗУ, Гб
Операционная
система
ПКС -
контроллер 1
Intel Xeon CPU E3-1241 v3 3,5
ГГц (4 ядра, 8 логических
процессоров)
16 Ubuntu Server
14.04
109
Продолжение таблицы 10
ПКС -
контроллер 2
Intel Xeon CPU E5-2670 v3
2,3 ГГц (12 ядер, 24
логических процессора)
128 Ubuntu Server 14.04
Сервер-
нагрузчик
Intel Core i5 4590 3,3 ГГц
(4 ядра)
32 Windows 7 Professional
x64 + Oracle VirtualBox
5.0.20 Ubuntu 14.04
Для снижения времени обработки массива экспериментальных данных
и автоматизации тестирования было разработано собственное программное
средство «Программа автоматизации тестирования контроллеров
программно-конфигурируемых сетей на базе протокола OpenFlow» [38],
представляющее собой набор скриптов на языке Python. Графическое
изображение алгоритма тестирования представлено на рисунке 38. Код
программы приведен в приложении А.
Скрипт setting.ini содержит описание параметров тестирования: IPv4-
адрес и порт ПКС-контроллера, количество имитируемых утилитой Cbench
OpenFlow-коммутаторов, количество МАС-адресов в памяти коммутатора,
длительность теста, количество тестов, паузу между тестами, а также число
активных ядер ЦП. Скрипт run_test.py осуществляет запуск утилиты Cbench с
заданными в setting.ini параметрами, calc.py – осуществляет расчет средней
задержки по результатам теста(ов) и сохраняет результаты в файл results.txt.
Дальнейшая обработка результатов осуществляется путем импортирования
файлов results.txt в табличный редактор MS Excel.
110
Рисунок 38. Блок-схема алгоритма работы разработанного
программного средства
111
4.4 Экспериментальное сравнение масштабирования задержки
ПКС-контроллера на аппаратных платформах с ЦП Xeon E3 и Xeon E5
В данном эксперименте была смоделирована сеть из 16 коммутаторов, в
памяти каждого коммутатора находилось 510 МАС-адресов, проведено 10
серий замеров по 10 тестов в каждой серии при длительности одного теста 10
секунд, пауза между тестами составляла 30 секунд. Результатом серии замеров
является среднее значение задержки. Несмотря на данную в [81]
рекомендацию измерять задержки в миллисекундах ( 310 с), для удобства
восприятия далее в работе будут приводиться значения в микросекундах ( 610
с). Полученные в ходе эксперимента значения приведены в приложении Г.
Рисунок 39. Зависимость задержки от числа ядер ЦП
Как видно из графика на рисунке 39, величина задержки ПКС-
контроллера на платформе с ЦП Xeon E5 ниже, чем на Xeon E3. При четырех
активных ядрах ПКС-контроллер OpenDaylight на аппаратной платформе с
процессором Xeon E3-1241 v3 обеспечил задержку на уровне 62 мкс, в то
112
время как на платформе Xeon E5-2670 v3 – 32 мкс. Активация технологии HT
позволяет достичь максимального снижения задержки с использованием Xeon
E3 на 15%, с использованием Xeon E5 – на 33%, однако при увеличении числа
ядер Xeon E5 свыше 6 штук получаемый выигрыш по задержке в среднем
составляет всего 1,167 мкс.
Рисунок 40. Получаемое ускорение от увеличения числа ядер ЦП
Ускорение при деактивированной HT рассчитывалось по формуле (6) на
основе полученных экспериментально значений задержки:
( )( , , )
perf rS m r lp
pplp
m
,
где (1)T - задержка на одноядерной конфигурации ЦП, ( )T m - задержка на
конфигурации ЦП с m ядрами, lp и pp – доли последовательных и
параллельных операций.
113
Для случая активной технологии HT ускорение рассчитывалось по
формуле (10) на основе полученных экспериментально значений задержки:
' ( )( , , )HT HT
perf rS m r lp S
pplp
m
.
Как видно из рисунка 40, без активации HT наилучшего значения
ускорения в 2,65 раз удалось добиться при 7 активных ядрах ЦП Xeon E5, при
использовании технологии HT – те же 2,65 раз при 5,7,8 и 10 активных ядрах
ЦП.
Однако экспериментальные значения не достигают идеального
линейного ускорения, являющегося следствием из закона Амдала при
допущении, что все операции выполняются параллельно. Данную ситуацию
иллюстрирует график на рисунке 41.
Рисунок 41. Сравнение экспериментальных кривых ускорения с линейно
возрастающей функцией, соответствующей идеальному случаю
114
Наблюдаемое отклонение говорит о существовании определенной доли
последовательных операций – параметра, ограничивающего рост ускорения.
Для расчета применялось выражение (7):
( )1
1
m perf r
Slpm
.
Поскольку ранее было оговорено, что под долей параллельных операций
понимается та доля, которая может параллельно выполняться именно на
физических ядрах ЦП, то для технологии HT в данном случае расчет не
осуществляется. Результат представлен на рисунке 42.
Рисунок 42. Зависимость доли линейных операций от числа ядер ЦП
Из представленного на рисунке 42 графика видно, что при 16
коммутаторах в сети минимальное значение доли последовательных операций
составляет порядка 0,53 при использовании процессора Xeon E3 и 0,27 на Xeon
E5. При этом можно отметить интересный факт – после достижения
минимального значения, доля последовательных операций начинает расти с
115
увеличением числа ядер. Данную особенность может объяснить
возникновение накладных расходов [1, 12, 17, 52], порождаемых как самой
операционных системой, так и процессами взаимодействия между ядрами,
синхронизацией параллельных потоков [52, с. 17].
Рисунок 43. Зависимость эффективности от числа ядер ЦП
Эффективность параллелизации определялась по формулам (8) и (11)
для случаев с активной и неактивной технологией HT, результаты
представлены на рисунке 43. Аппаратная платформа с процессором Xeon E5
обеспечивает большую эффективность параллелизации по сравнению с Xeon
E3 при равном количестве ядер, что видно из графика на рисунке 43. Однако
и на платформе E5 при использовании 12 ядер ЦП значение эффективности
составляет всего лишь 0,19. Активация HT позволяет повысить эффективность
при малом числе ядер на обеих моделях процессоров, но при использовании 6
116
и более ядер Xeon E5 можно получить только незначительный прирост
эффективности.
4.5 Экспериментальная апробация способа применения модели
ускорения многоядерных ЦП для оценки уровня задержки обработки
служебного трафика при масштабировании размера сети
В ходе эксперимента была использована аппаратная платформа с ЦП
Xeon E5 как показавшая больший выигрыш от параллелизации. С помощью
Cbench смоделирована сеть из 2𝑛 коммутаторов (где 𝑛 последовательно
принимает значения 0,1,2,3,4,5,6,7), память каждого коммутатора содержала
510 МАС-адресов, проведено 10 серий замеров по 10 тестов в каждой серии при
длительности одного теста 10 секунд, пауза между тестами 30 секунд.
Результатом серии замеров является среднее значение задержки, получаемое
при постоянном числе ядер ЦП, количество же управляемых OpenFlow-
коммутаторов последовательно изменялось программой автоматизации
тестирования. После этого через BIOS изменялось число активных ядер
процессора, осуществлялось включение/отключение HT и цикл замера
повторялся. Экспериментально полученные значения задержки представлены
в табличном виде в приложении Г. Для удобства представления информации
в графическом виде на рисунках 44-51 показаны результаты для 1, 8, 32 и 128
коммутаторов.
При малом числе коммутаторов, согласно рисунку 44, увеличение числа
процессорных ядер приводит к росту задержки ПКС-контроллера, активация
HT только усугубляет положение.
117
Рисунок 44. Зависимость задержки ПКС-контроллера от числа ядер ЦП
и активации HT при 1 и 8 коммутаторах
Положительных эффект наблюдается в случае управления
контроллером сегментов сети из 16 OpenFlow-коммутаторов, что показано на
рисунке 45: увеличение числа ядер с 1 до 12 способствует снижению задержки
с 96 мкс до 23 мкс. Положительный эффект усиливается с дальнейшим ростом
размера сегмента управляемо сети: при 128 коммутаторах задержка падает с
337 мкс при 1 активном процессорном ядре до 71 мкс при 12 ядрах, активация
HT позволяет при 12 активных ядрах дополнительно снизить задержку до 56
мкс.
118
Рисунок 45. Зависимость задержки ПКС-контроллера от числа ядер ЦП
и активации HT при 32 и 128 коммутаторах
Далее были рассчитаны ускорение и доля последовательных операций.
Результаты представлены в виде графиков на рисунках 46 и 47.
Рисунок 46. Зависимость ускорения от числа ядер ЦП и работы HT при 1 и 8
коммутаторах
119
Рисунок 47. Зависимость ускорения от числа ядер ЦП и работы HT при 32 и
128 коммутаторах
Увеличение числа OpenFlow-коммутаторов позволяет достичь больших
значений ускорения при увеличении числа процессорных ядер, доступных
ПКС-контроллеру. Однако достигнутое в максимальной конфигурации
процессора Xeon E5 ускорение, составившее 4,7 раз при 128 коммутаторах,
меньше, чем получаемое в идеальном случае по линейному закону значение
12. Активация HT в этом случае позволяет достичь ускорения в 6 раз при
использовании 12 ядер, что показано на рисунке 47.
Дальнейшему росту ускорения препятствуют последовательные не
распараллеливаемые операции, при 128 коммутаторах и 12 активных ядрах
ЦП доля которых составляет порядка 0,13 от общего числа совершаемых
операций, как видно из рисунка 48. Начиная с 6 ядер доля линейных операций
меняется достаточно слабо, в диапазоне от 0,17 до 0,13 при 128 коммутаторах
и от 0,2 до 0,14 при 32 коммутаторах. На графике это выглядит как колебания
120
«хвоста» функции в небольших пределах. В этом случае большего значения
ускорения при фиксированном числе ядер можно достичь за счет увеличения
вычислительной сложности решаемой задачи, т.е. увеличения числа
коммутаторов в управляемом ПКС-контроллером сегменте сети.
Рисунок 48. Изменение доли последовательных операций при 32 и 128
коммутаторах
При малом числе коммутаторов в управляемом сегменте сети доля
последовательных операций имеет вид, показанный на рисунке 49. Рост
данного параметра при 1 коммутаторе обусловлен низкой сложностью
решаемой задачи, в следствие которой растут издержки параллелизации. В
такой ситуации также рационально увеличивать вычислительную сложность
решаемой задачи.
121
Рисунок 49. Изменение доли последовательных операций при 1 и 8
коммутаторах
Рисунок 50. Зависимость эффективности параллелизации от числа
процессорных ядер, активации HT при 1 и 8 коммутаторах
122
Рисунок 51. Зависимость эффективности параллелизации от числа
процессорных ядер, активации HT при 32 и 128 коммутаторах
Рассчитанное из экспериментальных данных значение эффективности,
представленное на рисунках 50 и 51, говорит о том, что увеличение размера
сети наряду с использованием технологии HT способствует росту
эффективности применения многоядерных процессоров. Как показывает
рисунок 51, с увеличением числа физических ядер процессора наблюдается
снижение эффективности. Hyper-Threading позволяет увеличить
эффективность использования многоядерных процессоров при постоянном
числе физических ядер процессора. При размере сети в 128 коммутаторов и 12
ядрах ЦП эффективность составляет 0,395, активация HT позволяет повысить
это значение до 0,501, таким образом наблюдаемый прирост эффективности
составляет 1,26 раз. Среднее значение эффективности при 128 коммутаторах,
учитывая все возможные конфигурации ядер ЦП с Hyper-Threading,
составляет 0,76, а в конфигурации без HT – 0,59, и таким образом среднее
значение прироста эффективности от активации HT составляет 1,28 раз. Если
же ПКС-контроллер управляет сетью из 32 коммутаторов, то при 12 ядрах ЦП
123
активация HT не дает прироста эффективности. Однако среднее значение
эффективности при всех возможных конфигурациях физических ядер ЦП
ПКС-контроллера и 32 коммутаторах составляет 0,51, активация Hyper-
Threading повышает это значение до 0,62, средний прирост эффективности
составляет 1,22 раза. Таким образом, эффективность использования
многоядерных процессоров может быть увеличена путем использования
технологии логической многопоточности Hyper-Threading при достаточном
размере сегмента сети (сложности вычислительной задачи).
4.6 Выводы и результаты
Наращивание числа процессорных ядер приводит к ощутимому
ускорению и снижению уровня задержки ПКС-контроллера при достаточно
большом размере сети. Аппаратные платформы, снабженные ЦП Xeon E5,
показывают лучшие значения по задержки обработки пакетов, чем платформы
с младшими линейками процессоров. Фактором, ограничивающим рост
производительности, является доля линейных операций, осуществляемых
ПКС-контроллером. Математическая запись модели ускорения многоядерных
ЦП позволяет на основе экспериментальных данных вычислить долю
линейных операций, что может быть использовано для оценки ожидаемого
уровня задержки обработки пакетов ПКС-контроллером при планировании
модернизации аппаратной платформы.
Исходя из экспериментальных данных, можно сделать вывод, что
рационально использовать технологию HT при достаточно больших размерах
сети с точки зрения числа коммутаторов. Однако необходимо так же
учитывать и озвученный ранее во второй главе аспект лицензирования
программного обеспечения. Поскольку исследуемый контроллер
OpenDaylight является кроссплатформенным, то он может быть запущен не
только на сервере под управлением ОС семейства Linux, но и Windows Server.
В этом случае необходимо учитывать увеличение стоимости лицензировании
124
серверной ОС с увеличением числа логических процессоров и сопоставлять с
получаемым выигрышем в плане снижения задержки.
Увеличение размера управляемого контроллером сегмента сети также
является способом увеличения эффективности использования многоядерных
ЦП. Однако количество управляемых OpenFlow-коммутаторов является
величиной конечной для конкретного контроллера и указано в его
технических спецификациях. Стоит отметить, что при проведении
тестирования с 256 коммутаторами в работе OpenDaylight Beryllium
наблюдались сбои, контроллер периодически переставал отвечать на запросы
packet_in от Cbench
Для дальнейшего снижения доли последовательных операций, роста
эффективности параллелизации и снижения задержек, по мнению автора,
существует несколько возможных способов, не рассмотренных в данной
работе:
1) Оптимизация работы СОС ПКС-контроллера. Для СОС на основе
Java, к которым относится и рассматриваемый в данной работе OpenDaylight,
можно использовать различные техники оптимизации Java-приложений [60];
2) Внесение изменений во внутреннее устройство ЦП, позволяющих
снизить степень конкуренции к разделяемым ресурсам. Например, новый
класс технологий для процессоров, получивший название platform quality of
service. Intel начала внедрять технологии данного класса начиная с
микроархитектуры Broadwell, пришедшей на смену Haswell, на которой
основаны ЦП, использованные в данной работе. К таким технологиям
относятся [83]:
Cache Allocation Technology (CAT) - позволяет системным
администраторам назначать больше емкости кэша L3 для отдельных
виртуальных машин, что приводит к более низкой задержке и более высокой
производительности для высокоприоритетных рабочих нагрузок, таких как
приложения NFV, реального времени и видео по требованию.
125
Cache Monitoring Technology (CMT) – может использоваться для
мониторинга использования последнего уровня кэша (LLC) потоками
приложений. Благодаря этой информации администраторы могут более
эффективно балансировать рабочие нагрузки для повышения
производительности приложений и использования физических ресурсов. В
частности, CMT может использоваться для уменьшения влияния проблемы
так называемого «шумного соседа» в средах центров обработки данных, когда
важна возможность изолированно обслуживать различных клиентов в рамках
одного сервиса. Проблема «шумного соседа» - это ситуация, при которой одна
виртуальная машина активно использует кэш-память и вытесняет из него
данные второй виртуальной машины, тем самым замедляя её работу. Как
показывают исследования [146], использование CMT позволяет снизить
среднюю задержку в виртуализированных средах на величину от 47% до 92%,
а максимальную – от 49% до 98%.
Memory Bandwidth Monitoring (MDM) - позволяет системным
администраторам определять насыщенность полосы пропускания памяти,
которая может быть вызвана несколькими виртуальными машинами,
работающими на одном хосте. Выполнение корректирующих действий, таких
как перенос виртуальных машин на другой хост, повышает масштабируемость
и производительность.
Аналогичные разработки - Platform QOS Enforcement и Platform QOS
Monitoring существуют и в арсенале компании AMD [53].
126
ЗАКЛЮЧЕНИЕ
В диссертационной работе решены следующие задачи:
1. Проведен анализ стандартов в области сетевых архитектур ПКС,
анализ архитектуры и технических спецификаций сетевой операционной
системы ПКС-контроллера.
2. Проанализирована модель ускорения многоядерных процессоров на
основе закона Амдала, определены границы её применимости, выявлены
факторы, способные ограничивать рост ускорения.
3. Разработана модель задержки обработки служебного трафика
протокола OpenFlow.
4. Осуществлено экспериментальное исследование задержки обработки
OpenFlow-пакетов ПКС-контроллером.
5. Разработан способ применения модели ускорения многоядерных
процессоров для оценки уровня задержки обработки служебного трафика при
изменении размера сети.
В ходе работы были получены новые научные результаты:
1. Показана возможность использования закона Амдала для описания
ускорения ПКС-контроллера на многоядерных ЦП.
2. Разработана модель задержки обработки служебного трафика
программно-конфигурируемых сетей на базе протокола OpenFlow для
обеспечения их эффективного функционирования. Выявлена зависимость
задержки обработки служебного трафика от задержки ПКС-контроллера.
3. Разработан способ определения числа ядер платформы ПКС-
контроллера, при котором рационально увеличение управляемого сегмента
сети.
4. Показано, что эффективность использования многоядерных
процессоров может быть увеличена путем использования технологии
логической многопоточности Hyper-Threading при достаточной сложности
вычислительной задачи.
127
Разработанный способ применения модели ускорения многоядерных
ЦП может быть использован на практике. В частности, по мнению автора, для
операторов связи может оказаться полезной система мониторинга и
диагностики программно-конфигурируемой сети, осуществляющая контроль
её качества функционирования на основе таких метрик, как задержка,
джиттер, коэффициент потери пакетов. Подобная система может быть
снабжена блоком расчета оптимальной аппаратной конфигурации, который в
случае превышения сетевой задержки критического уровня предложит
возможные пути снижения задержки.
Перспективное направление дальнейших исследований может быть
связано с разработкой техник оптимизации СОС с использованием нового
класса технологий ЦП platform quality of service или адаптация СОС для
GPGPU-платформы на основе графических процессоров.
128
ТЕРМИНЫ И АББРЕВИАТУРЫ
ACL (Access Control List) – список контроля доступа.
A-CPI (Application-Control Plane Interface) – интерфейс для связи плоскости
приложений и управления в архитектуре ONF.
ASIC (Application-Specific Integrated Circuit) – интегральная микросхема
специального назначения.
API (Application Programming Interface) – интерфейс программирования
приложений.
BCE (Base Core Equivalent) - основной ядерный элемент процессора или ядро
процессора.
CPU (Central Processor Unit) – центральный процессор.
DAL (Device Abstraction Level) – уровень абстракции устройства в архитектуре
IRTF.
D-CPI (Data-Control Plane Interface) – интерфейс для связи плоскостей данных
и управления в архитектуре ONF.
HT (Hyper-Threading) – технология процессоров Intel, реализующая
Simultaneous multithreading.
IDS (Intrusion Detection System) – система обнаружения вторжений.
JVM (Java Virtual Machine) – виртуальная машина Java.
IRTF (Internet Research Task Force) – Исследовательская группа Интернет-
технологий, подразделение Internet Architecture Board, одна из
стандартизирующих организаций.
ITU-T (International Telecommunication Union - Telecommunication sector) –
Сектор стандартизации элекстросвязи Международного союза электросвязи.
129
MIMD (Multiple Instruction Multiple Data) – одна из архитектур параллельных
вычислительных машин согласно классификации Флинна.
MISD (Multiple Instruction Single Data) – одна из архитектур параллельных
вычислительных машин согласно классификации Флинна.
NAT (Network Address Translation) – протокол трансляции сетевых адресов.
NFV (Network Function Virtualization) – виртуализация сетевых функций.
NPU (Network Processor Unit) – сетевой процессор.
SDN (Software Defined Networks) – программно-конфигурируемые сети.
SDI (Software Defined Infrastructure) – программно-определяемая
инфраструктура.
SMT (Simultaneous multithreading) - архитектура ЦП с одновременным
выполнением потоков.
ONF (Open Network Foundation) – организация, занимающаяся вопросами
стандартизации ПКС.
OSI (Open System Interconnection) – модель взаимодействия открытых систем
PDU (Protocol Data Unit) – обощенное название фрагмента данных на разных
уровнях модели OSI.
SAL (Service Abstraction Level) – уровень абстракции сервиса в архитектуре
IRTF.
SIMD (Single Instruction Multiple Data) – одна из архитектур параллельных
вычислительных машин согласно классификации Флинна.
SISD (Single Instruction Single Data) – одна из архитектур параллельных
вычислительных машин согласно классификации Флинна.
130
Аппаратная платформа – совокупность процессора, его микро и
макроархитектуры, а также набора микросхем (чипсета) и шин обмена
данными.
МКОД (Много Инструкций Одни Данные) – то же, что и MISD.
МКМД (Много Инструкций Много Данных) – то же, что и MIMD.
ПКС – программно-конфигурируемая сеть, то же, что и SDN.
ОКОД (Одна Инструкция Одни Данные) – то же, что и SISD.
ОКМД (Одна Инструкция Много Данных) – то же, что и SIMD.
Поток - в терминологии OpenFlow понимается совокупность пакетов,
характеризуемая определенным набором полей.
Пайплайн (от англ. “Pipeline”) – термин, которым принято описывать
определенную последовательность действий, совершаемых с пакетом внутри
сетевого устройства до момента его отправки через исходящий порт.
ПКС-контроллер – программно-аппаратный комплекс, представляющий
собой сетевую операционную систему, функционирующую на аппаратной
платформе с архитектурой x86, который выполняет роль центра управления
политиками безопасности, маршрутизации и качества обслуживания в
программно-конфигурируемых сетях.
СОС – сетевая операционная система, программная составляющая ПКС-
контроллера.
Таблица потоков - в терминологии OpenFlow понимается таблица
коммутатора, хранящая сведения о потоках.
ЦП – центральный процессор.
131
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Багдасаров, Г.А. Измерение производительности и
масштабируемости программного комплекса MARPLE3D / Г.А. Багдасаров,
С.В. Дьяченко, О.Г. Ольховская // Препринты ИПМ им. М.В. Келдыша. – 2012.
– № 37. – 22 с. – URL: http://library.keldysh.ru/preprint.asp?id=2012-37 (дата
обращения 06.05.2018).
2. Владыко, А.Г. Тестирование SDN контроллеров на базе модельной
сети / А.Г. Владыко, Н.А. Матвиенко, М.И. Новиков, Р.В. Киричек //
Информационные технологии и телекоммуникации. – 2016. – Т. 4. – № 1. – С.
17-28.
3. Галич, С.В. Аналитический обзор коммерческих ПКС-
контроллеров на основе OpenDaylight / С.В. Галич, М.С. Деогенов, А.О.
Пасюк, Е.С. Семенов // Огарев-online. – 2016. – № 18. – URL:
http://journal.mrsu.ru/arts/analiticheskij-obzor-kommercheskix-pks-kontrollerov-
na-osnoveopendaylight (дата обращения: 28.04.2018).
4. Галич, С.В. Исследование производительности ПКС-контроллера
OpenDaylight на сетях разных масштабов / С.В. Галич, М.С. Деогенов, В.Г.
Карташевский, А.О. Пасюк, Е.С. Семенов // Известия ЮФУ. Технические
науки. – №9. – 2016. – С. 121-133. DOI: 10.18522/2311-3103-2016-9-121133
5. Галич, С.В. Обзор архитектуры SDN-контроллера OpenDaylight /
С.В. Галич, И.К. Сердюкова, О.Е. Сафонова // Проблемы передачи
информации в инфокоммуникационных системах: сборник докладов и тезисов
VI Всероссийской научно-практической конференции, 18 мая 2015 г. –
Волгоград: изд-во ВолГУ, 2015. – С. 18-25.
6. Галич, С.В. Теоретическая оценка максимально достижимого
масштабирования производительности ПКС-контроллера на многоядерной
аппаратной платформе / С.В. Галич, Р.А. Юртаев // Сборник докладов и
тезисов VII Всероссийской научно-практической конференции «Проблемы
передачи информации в инфокоммуникационных системах», г. Волгоград, 20
мая 2016 г. – Волгоград: изд-во ВолГУ, 2016. – С. 26-35.
132
7. Ганьжа Д. На серверном рынке без перемен? [Электронный
ресурс] // Журнал сетевых решений/LAN. – 2017. – №4. – URL:
https://www.osp.ru/lan/2017/04/13051896/ (дата обращения: 29.04.2018).
8. Горшенин, А.К. Параллелизм в микропроцессорах / А.К.
Горшенин, С.В. Замковец, В.Н. Захаров // Системы и средства информатики. –
2014. – Т.24. – №1. – С. 46-60.
9. ГОСТ Р ИСО/МЭК 7498-1-99 Информационная технология (ИТ).
Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая
модель. - М. : Стандартинформ, 2006. – 62 с.
10. Дополнения Ванга и Бриггса к классификации Флинна
[Электронный ресурс] // Parallel.ru. – URL:
http://parallel.ksu.ru/computers/taxonomy/briggs.html (дата обращения:
29.04.2018).
11. Егоров, В.Б. Некоторые вопросы практической реализации
концепции SDN / В.Б. Егоров // Системы и средства информатики. – 2016. – Т.
26. – №1. – C. 109-120.
12. Еремин, Е.А. К вопросу об оценке ускорения программы при
изучении эффекта от параллельных вычислений / Е.А. Еремин // Вестник
Пермского государственного гуманитарно-педагогического университета.
Серия: Информационные компьютерные технологии в образовании. – №11. –
2015. – С. 5-13.
13. Ефимушкин, В.А. Обзор решений SDN/NFV зарубежных
производителей / В.А. Ефимушкин, Т.В. Ледовских, Д.М. Корабельников, Д.Н.
Языков // T-Comm: Телекоммуникации и транспорт. – 2015. – Том 9. – №8. –
С. 5-13.
14. Ефимушкин, В.А. Роль технологий SDN/NFV в инфраструктуре
цифровой экономики. Опыт тестирования и внедрения / В.А. Ефимушкин, Т.В.
Ледовских, А.Б. Иванов, В.А. Шалагинов // Электросвязь. – №3. – 2018. – С.
27-36.
133
15. Захаров, А.А. Аспекты информационной безопасности
архитектуры SDN / А.А. Захаров, Е.Ф. Попов, М.М. Фучко // Вестник
СибГУТИ. – 2016. – № 1. – С. 83-92.
16. Карташевский В.Г. Основы теории массового обслуживания:
учебник для вузов / В.Г. Карташевский. — М. : Горячая линия-Телеком, 2013.
— 130 с.
17. Карташевский, В.Г. Оценка масштабируемости задержки ПКС-
контроллера на параллельной вычислительной системе / В.Г. Карташевский,
С.В. Галич, Е.С. Семенов, Н.И. Кирьянова // Инфокоммуникационные
технологии. – Том 15. – №2. – 2017. – С. 163-170.
18. Кириллов И. Серверные процессоры: новые технологии и борьба
за рынок [Электронный ресурс] // Сети и бизнес. – 2017. – №1. – URL:
http://sib.com.ua/sib-1-92-2017/12-servernye-processory.html (дата обращения:
29.04.2018).
19. Кодачигов В. На одного абонента в России приходится больше
гигабайта мобильного трафика [Электронный ресурс] // Ведомости. – URL:
https://www.vedomosti.ru/technology/articles/2017/07/07/712840-bolshe-
gigabaita-trafika
20. Колечкин, А.О. Программное обеспечение для тестирования
контроллеров программно-конфигурируемых сетей / А.О. Колечкин, А.Г.
Владыко // Материалы Девятнадцатой международной научной конференции
«Распределенные компьютерные и телекоммуникационные сети: управление,
вычисление, связь (DCCN-2016)». — М. : РУДН, 2016. — С. 256-263.
21. Краткое описание семейства процессоров Intel Xeon D-1500
[Электронный ресурс] // Intel. — URL:
https://www.intel.ru/content/www/ru/ru/processors/xeon/xeon-processor-d-
brief.html (дата обращения: 30.04.2018).
22. Логинов, С.С. Об уровнях управления в программно-
конфигурируемой сети (SDN) / С.С. Логинов // T-Comm: Телекоммуникации и
транспорт. – 2017. – Том 11. – №3. – С. 50-55.
134
23. Малахов, С.В. Теоретическое и экспериментальное исследование
задержки в программно-конфигурируемых сетях / С.В. Малахов, В.Н. Тарасов,
И. В. Карташевский // Инфокоммуникационные технологии. – 2015. – Т. 13. –
№ 4. – С. 409-413.
24. Малахов, С.В. Экспериментальные исследования
производительности сегмента программно-конфигурируемой сети / С.В.
Малахов, В.Н. Тарасов // Интеллект. Инновации. Инвестиции. – 2013. – №2. –
С. 81-85.
25. О приоритетных научных задачах, для решения которых требуется
задействовать возможности федеральных центров коллективного пользования
научным оборудованием [Электронный ресурс] // Правительство Российской
Федерации. – URL: http://government.ru/orders/selection/405/10326/ (дата
обращения: 16.09.2016).
26. Орлов С. Я., Цилькер Б. Я. Организация ЭВМ и систем: Учебник
для вузов. 2-е изд. – СПб. : Питер, 2011. – 688 с.
27. Осетров, С.П. Анализ режимов кластеризации ПКС-контроллера
OpenDaylight / С.П. Осетров, С.В. Галич // Современные проблемы
радиоэлектроники. – Красноярск : Сибирский Федеральный Университет,
2017. – С. 636-639.
28. Осетров, С.П. Механизм отказоустойчивости в кластере
Master/Slave контроллеров OpenDaylight / С.П. Осетров, С.В. Галич //
Материалы XXI научно-практической конференции молодых ученых,
аспирантов и студентов Национального исследовательского Мордовского
государственного университета им. Н. П. Огарёва. Ч. 1: Технические науки. –
Саранск : Изд-во Мордов. ун-та, 2017. – C. 516-523.
29. Паттерсон Д., Хеннесси Дж. Архитектура компьютера и
проектирование компьютерных систем. Классика Computers Science. 4-е изд. –
СПб. : Питер, 2012. – 784 с.
135
30. Про Intel Hyper-Threading и производительность виртуальных
машин [Электронный ресурс] // Habr. — URL: https://habr.com/post/251163/
(дата обращения: 05.06.2018).
31. Проектирование сервера под нужды «1С:Предприятие 8» для
среднего и крупного бизнеса [Электронный ресурс] // IXBT.com. — URL:
http://smb.ixbt.com/articles/primery-vnedrenij/2016-12-10/proektirovanie-servera-
pod-nuzhdy-1spredprijatie-8-dlja-srednego-i-krupnogo-biznesa (дата обращения:
05.06.2018).
32. Разделение control и data plane в сетевом оборудовании
[Электронный ресурс] // Habr. — URL:
https://habrahabr.ru/company/cbs/blog/301000/ (дата обращения: 20.04.2018).
33. Ромасевич, П.В. Метод оценки возможности применения
коммутаторов на уровнях иерархии пакетных телекоммуникационных сетей //
Проблемы передачи информации в телекоммуникационных системах:
материалы IV регион. науч.-практ. конф., г.Волгоград, 22 мая 2012 г. —
Волгоград: Изд-во ВолГУ, 2012. - С. 51-54.
34. Ромасевич, П.В. Оценка влияния параметров
телекоммуникационной системы на среднее время задержки в условиях
самоподобного трафика // Инфокоммуникационные технологии. — 2005. —
№3. — С.21-26.
35. Ромасевич, П.В. Оценка памяти ввода/вывода маршрутизаторов
Cisco с интерфейсами множественного доступа в телекоммуникационных
сетях с интенсивным трафиком // Инфокоммуникационные технологии. —
2004. — №4. — С. 36-40.
36. «Ростелеком» протестировал возможности мультивендорной
транспортной SDN-сети [Электронный ресурс] // Ростелеком. – URL:
https://www.rostelecom.ru/press/news_ir/news/d441421/ (дата обращения:
16.03.2018).
136
37. Рыбальченко М.В., Глушань ВМ. Основы организации
компьютерных систем: Учебное пособие. – Таганрог : Изд-во ТТИ ЮФУ,
2009. – 53 с.
38. Свидетельство о государственной регистрации программы для
ЭВМ № 2017663192 «Программа автоматизации тестирования контроллеров
программно-конфигурируемых сетей на базе протокола OpenFlow» / С. В.
Галич ; правообладатель С. В. Галич ; заявл. 26.07.2017 ; зарегистр. 27.11.2017.
- 1 с.
39. Семейство процессоров Intel® Xeon® E5 v3 [Электронный ресурс]
// Intel. — URL: https://ark.intel.com/ru/products/series/78583/Intel-Xeon-
Processor-E5-v3-Family (дата обращения: 02.05.2018).
40. Семенов, Е.С. Анализ и классификация задержек, возникающих
при работе протокола ARP в программно-конфигурируемых сетях / Е.С.
Семенов, С.В. Галич, Д.А. Тюхтяев // Вестник государственного университета
морского и речного флота им. адмирала С.О. Макарова. – 2015. – №5 (33). –
С.217-228.
41. Семенов, Е.С. Исследование функционирования ARP-протокола в
программно-конфигурируемой сети / Е.С. Семенов, М.С. Деогенов, С.В.
Галич, Д.А. Тюхтяев, Д. И. Чадаев, А. В. Харченко // Вестник Ростовского
государственного университета путей сообщения. – 2016. –№3. – С.55-61.
42. Семенов, Е.С. Оптимизация IP сети с использованием
программно-конфигурируемых сетей / Е.С. Семенов, М.С. Деогенов, С.В.
Галич, Д.А. Тюхтяев, А.О. Пасюк // Инфокоммуникационные технологии. –
Т.13. – №4. – 2015. – С. 414-419.
43. Семеновых, А.А. Сравнительный анализ SDN-контроллеров / А.А.
Семеновых, О.Р. Лапонина // International Journal of Open Information
Technologies. – Vol. 6, №7. – 2018
44. Смелянский, Р.Л. Программно-конфигурируемые сети
[Электронный ресурс] // Открытые системы. СУБД. – 2012. - №9. – URL:
https://www.osp.ru/os/2012/09/13032491/ (дата обращения: 01.05.2018).
137
45. Смелянский, Р.Л. Современные проблемы обеспечения
безопасности в SDN / Р.Л. Смелянский, П.Л. Пилюгин //
Телекоммуникационные устройства и системы. — 2017. — Т.7. — №4. —
С. 523-526.
46. Статистика отрасли [Электронный ресурс] // Министерство
цифрового развития, связи и массовых коммуникаций Российской Федерации.
— URL: http://minsvyaz.ru/ru/pages/statistika-otrasli/#section-403 (дата
обращения: 15.04.2018).
47. Таненбаум Э., Бос Х. Современные операционные системы. 4е изд.
– СПб. : Питер, 2015. – 1120 с.
48. Телеком и ИТ [Электронный ресурс] // А. Шалагинов. – URL:
https://shalaginov.com/2016/11/27/операторы-отчитали-вендоров-на-sdn-world-
forum-в-г/ (дата обращения: 05.06.2018).
49. Учебное пособие: коммутаторы локальных сетей D-Link. Четвертое
издание. –М. :2006.
50. Чемерицкий, Е.В. Исследование методов контроля
функционирования программно-конфигурируемых сетей : дис. … канд. физ.-
мат. наук : 05.13.11 : защищена 25.09.2015 : утверждена : – М., 2015. – 200 с.
51. Advanced study of sdn/openflow controllers / A. Shalimov, D. Zuikov,
D. Zimarina et al. // Proceedings of the 9th Central & Eastern European Software
Engineering Conference in Russia. — ACM International Conference Proceeding
Series. — Moscow; Russian Federation; 2013. DOI:10.1145/2556610.2556621.
52. Akhter S., Roberts J. Multi-Core Programming. Increasing
Performance through Software Multi-threading. – Intel Press, 2006. – 336 с.
53. AMD64 Technology Platform Quality of Service Extensions
[Электронный ресурс] // AMD. – URL:
https://www.amd.com/system/files/TechDocs/56375_Quality_of_Service_Extensio
ns.pdf (дата обращения: 10.06.2018)
54. Amdahl, G.M. Computer Architecture and Amdahl's Law // Computer.
– 2013. – Vol. 46. – №. 12. – С. 38-46. DOI:10.1109/MC.2013.418
138
55. Amdahl, G.M. Validity of the Single Processor Approach to Achieving
Large-scale Computing Capabilities // Proc. Joint Computer Conf. American
Federation of Information Processing Societies (AFIPS 67). – ACM. – 1967.
DOI:10.1145/1465482.1465560.
56. Applications in the Junos Architecture [Электронный ресурс] //
Juniper Networks. – URL:
https://www.juniper.net/documentation/en_US/junos/topics/concept/sdk-
architecture-overview.html (дата обращения: 20.04.2018).
57. Carranza, W.J. Fourth Generation Intel Core Processor
Microarchitecture [Электронный ресурс] // Academia. – URL:
https://www.academia.edu/4994161/Fourth_Generation_Intel_Core_Processor_Mi
croarchitecture (дата обращения: 30.04.2018).
58. Cbench [Электронный ресурс] // Github. – URL:
https://github.com/mininet/oflops/tree/master/cbench (дата обращения:
06.05.2018).
59. Chao H.J., Liu B. High performance switches and routers // Wiley-
IEEE Press. – 2007. – 634 с.
60. Chen, K.-Y., Multithreading in Java: Performance and Scalability on
MultiCore Systems / K.-Y. Chen, J.M. Chag, T.-W. Hou // IEEE Transactions on
Computers, December 02, 2010. – P. 1521-1534. DOI: 10.1109/TC.2010.232
61. Cisco 4000 Series Integrated Sevices Routers Data Sheet
[Электронный ресурс] // Cisco. – URL:
https://www.cisco.com/c/en/us/products/collateral/routers/4000-series-integrated-
services-routers-isr/datasheet-c78-732542.html (дата обращения: 05.04.2018).
62. Cisco NPU: cетевой процессор с производительностью 400 Гбит/с
[Электронный ресурс] // Servernews. – URL: https://servernews.ru/958639 (дата
обращения: 20.04.2018).
63. Cisco Router Architecture [Электронный ресурс] // Cisco. – URL:
https://www.cisco.com/networkers/nw99_pres/601.pdf (дата обращения:
20.04.2018).
139
64. Cisco Visual Networking Index: Forecast and Methodology, 2016–
2021 [Электронный ресурс] // Cisco. – URL:
https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-
networking-index-vni/complete-white-paper-c11-481360.html (дата обращения:
15.04.2018).
65. Clark D. The Design Philosophy of the DARPA Internet Protocols //
Symposium Proceedings on Communications Architectures and Protocols,
(SIGCOMM ’88). – ACM, 1988. – Pp. 106–114.
66. Collection of tests for OpenFlow controllers testing [Электронный
ресурс] // Github. – URL: https://github.com/ARCCN/ctltest (дата обращения:
06.05.2018).
67. CPU-World [Электронный ресурс]. - URL: http://www.cpu-
world.com/ (дата обращения: 02.05.2018).
68. Data Plane Development Kit [Электронный ресурс]. – URL:
http://dpdk.org/ (дата обращения: 25.04.2018).
69. Desktop 4th Gen Intel Core Processors Datasheet, Vol. 1
[Электронный ресурс] // Intel. – URL:
https://www.intel.ru/content/www/ru/ru/processors/core/4th-gen-core-family-
desktop-vol-1-datasheet.html (дата обращения: 02.05.2018).
70. Dijkstra, E.W. A note on two problems in connexion with graphs //
Numer. Math – Springer Science+Business Media, 1959. – Vol.1, Iss.1. – P. 269-
271.
71. El-Geder S., Performance Evaluation using Multiple Controllers with
Different Flow Setup Modes in the Software Defined Network Architecture. PhD
dissertation. Department of Electronic and Computer Engineering, College of
Engineering, Design and Physical Sciences, Brunel University, London, January
2017.
72. Femminella, M. Performance Management of Java-based SIP
Application Servers / M. Ferminella, E. Maccherani, G. Reali // Proceedings of the
140
12th IFIP/IEEE International Symposium on Integrated Network Management, May
23-27, 2011. – Dublin, Ireland, 2011.
73. Flynn, M. Some Computer Organisations and Their Effectiveness //
IEEE Transactions on Computers. – 1972. – V.21, № 9. DOI:
10.1109/TC.1972.5009071
74. Galich, S. V. Control traffic parameters analysis in various software-
defined networking topologies / S.V. Galich, M.S. Deogenov, E.S. Semenov // 2017
International Conference on Industrial Engineering, Applications and
Manufacturing (ICIEAM), St. Petersburg, Russia. – 2017. DOI:
10.1109/ICIEAM.2017.8076439
75. Guerin, X. Evaluation of Multi-core Scalability Bottlenecks in
Enterprise Java Workloads / X. Guerin, W. Tan, Y. Liu, S. Seelam, P. Dube //
Proceedings of the 2012 IEEE 20th International Symposium on Modeling, Analysis
and Simulation of Computer and Telecommunication Systems, August 07-09, 2012.
– P. 308-317. DOI:10.1109/MASCOTS.2012.43
76. Handler, W. On Classification Schemes for Computer Systems in the
Post von Neumann Era // Lecture Notes in Computer Science. – 1975.
77. Higbie, L.C. Supercomputer architecture // Computer. – Vol. 6. – № 12.
– 1973. – P. 48–56.
78. Hill, M.D. Amdahl's Law in the Multicore Era / M.D. Hill, M.R. Marty
// Computer. - 2008. – Volume 41 Issue 7. – С. 33-38. DOI: 10.1109/MC.2008.209
79. Hoang, D.B. On software-defined networking and the design of SDN
controllers / D.B. Hoang, M. Pham // Proceeding 6th International Conference on
the Network of the Future (NOF), 2015. DOI:10.1109/nof.2015.7333307
80. Hwang K., Briggs F.A. Computer Architecture and Parallel Processing.
– New York : McGraw-Hill, 1985.
81. IETF draft Benchmarking Methodology for SDN Controller
Performance [Электронный ресурс] // IETF.org. – URL:
https://tools.ietf.org/html/draft-ietf-bmwg-sdn-controller-benchmark-term-00 (дата
обращения: 06.05.2018).
141
82. IMT Vision – Framework and overall objectives of the future
development of IMT for 2020 and beyond [Электронный ресурс] / ITU-R M.2083-
0 // ITU-R. – URL: https://www.itu.int/rec/R-REC-M.2083-0-201509-I (дата
обращения: 16.03.2018).
83. Increasing Platform Determinism with Platform Quality of Service for
the Data Plane Development Kit White Paper [Электронный ресурс] // Intel. –
URL: https://www.intel.com/content/dam/www/public/us/en/documents/white-
papers/increasing-platform-determinism-pqos-dpdk-paper.pdf (дата обращения:
10.06.2018).
84. Intel Atom Processor C2000 for Microserver Performance: Brief
[Электронный ресурс] // Intel. – URL:
https://www.intel.ru/content/www/ru/ru/processors/atom/atom-c2000-family-
brief.html (дата обращения: 30.04.2018).
85. Intel Ethernet Controller X710/ XXV710/XL710 Datasheet
[Электронный ресурс] // Intel. – URL:
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xl710
-10-40-controller-datasheet.pdf (дата обращения: 02.05.2018).
86. Intel Xeon Processor E3-1200 v3 Product Family [Электронный
ресурс] // Intel. – URL:
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v3-
brief.html (дата обращения: 30.04.2018).
87. Intel Xeon Processor E3-1200 v3 Product Family Datasheet
[Электронный ресурс] // Intel. – URL:
https://www.intel.ru/content/www/ru/ru/processors/xeon/xeon-e3-1200v3-vol-1-
datasheet.html (дата обращения: 02.05.2018).
88. Intel Xeon Processor E5-2600 Product Family [Электронный ресурс]
// Intel. – URL: https://www.intel.com/content/www/us/en/processors/xeon/xeon-
e5-brief.html (дата обращения: 30.04.2018).
89. Intel Xeon Processor E7-8800/4800 v3 Product Families: Brief
[Электронный ресурс] // Intel. – URL:
142
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v3-family-
brief.html (дата обращения: 30.04.2018).
90. Intel’s Haswell CPU Microarchitecture [Электронный ресурс] // Real
World Technologies. – URL: https://www.realworldtech.com/haswell-cpu/ (дата
обращения: 30.04.2018).
91. ITU-T M.3400 TMN management functions [Электронный ресурс] //
ITU. – URL:https://www.itu.int/rec/T-REC-M.3400/en (дата обращения:
20.04.2018).
92. ITU-T Y.3300 Framework of software-defined networking
[Электронный ресурс] // ITU. – URL: https://www.itu.int/rec/T-REC-Y.3300/en
(дата обращения: 20.04.2018).
93. Ivashchenko, P. High performance in-kernel sdn/openflow controller /
P. Ivashchenko, A. Shalimov, R. Smeliansky // Proceedings of the 2014 Open
Networking Summit Research Track, USENIX, March 3-5. – Santa Clara, USA,
2014.
94. Kreutz, D. Software-Defined Networking: A Comprehensive Survey /
D. Kreutz, F.M.V. Ramos, P.E. Verissimo C.E. Rothenberg, S. Azodomolky, S.
Uhlig // Proceedings of the IEEE. – Vol.103, Is.1. – P.14-76.
DOI:10.1109/jproc.2014.2371999
95. Kurose J., Ross K. Computer Networking: A Top-Down Approach (7th
Edition) // Pearson Highter Education. – 2016.
96. Leary M., SDN, NFV, and open source: the operator’s view
[Электронный ресурс] // Gigaom Research. – 2014. – URL:
http://ftp.tiaonline.org/Technical%20Committee/CCSC/2014.04.29/ (дата
обращения: 20.04.2018).
97. Martin C. Multicore processors: challenges, opportunities, emerging
trends // Proc. Embedded World Conference 2014. – Nuremberg, Germany: 2014. –
P. 1–9.
98. Medved J. OpenDaylight: Towards a Model-Driven SDN Controller
Architecture / J. Medved, R. Varga, A. Tkacik, K. Gray // Proceeding of IEEE
143
International Symposium on a World of Wireless, Mobile and Multimedia Networks
2014. – 2014. DOI: 10.1109/WoWMoM.2014.6918985
99. Mininet [Электронный ресурс]. – URL: http://mininet.github.com/
(дата обращения: 15.05.2018).
100. Network Virtualization Report 2017. SDN Controllers, Cloud
Networking and more. // SDNCentral, LLC. – 2017.
101. Oktian, Y. E., Lee, S., Lee, H., & Lam, J. (2017). Distributed SDN
controller system: A survey on design choice. Computer Networks, 121, 100–111.
doi:10.1016/j.comnet.2017.04.038
102. ONF TR 521 [Электронный ресурс] // Open Networking Foundation.
– URL: https://www.opennetworking.org/images/stories/downloads/sdn-
resources/technical-reports/TR-521_SDN_Architecture_issue_1.1.pdf (дата
обращения: 20.04.2018).
103. ONF TR-502: SDN Architecture [Электронный ресурс] // Open
Networking Foundation. – URL:
https://www.opennetworking.org/images/stories/downloads/sdn-
resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf (дата
обращения: 20.04.2018).
104. ONF TR-539 OpenFlow Controller Benchmarking Methodologies
[Электронный ресурс] // Open Network Foundation. – URL:
https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-
content/uploads/2014/10/TR-
539_OpenFlow_Controller_Benchmarking_Methodologies_v1.pdf (дата
обращения: 06.05.2018).
105. ONF TS-001 OpenFlow Switch Specification version 1.0.0 (wire
protocol 0x01) [Электронный ресурс] // Open Network Foundation. – URL:
https://www.opennetworking.org/wp-content/uploads/2013/04/openflow-spec-
v1.0.0.pdf (дата обращения: 04.05.2018).
106. ONF TS-002 OpenFlow Switch Specification version 1.1.0 (wire
protocol 0x02) [Электронный ресурс] // Open Network Foundation. – URL:
144
https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-
content/uploads/2014/10/openflow-spec-v1.1.0.pdf (дата обращения: 04.05.2018).
107. ONF TS-003 OpenFlow Switch Specification version 1.2. (wire
protocol 0x03) [Электронный ресурс] // Open Network Foundation. – URL:
https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-
content/uploads/2014/10/openflow-spec-v1.2.pdf (дата обращения: 04.05.2018).
108. ONF TS-006 OpenFlow Switch Specification version 1.3.0 (wire
protocol 0x04) [Электронный ресурс] // Open Network Foundation. – URL:
https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-
content/uploads/2014/10/openflow-spec-v1.3.0.pdf (дата обращения: 04.05.2018).
109. ONF TS-012 OpenFlow Switch Specification version 1.4.0 (wire
protocol 0x05) [Электронный ресурс] // Open Network Foundation. – URL:
https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-
content/uploads/2014/10/openflow-spec-v1.4.0.pdf (дата обращения: 04.05.2018).
110. ONF TS-025 OpenFlow Switch Specification version 1.5.1 (wire
protocol 0x06) [Электронный ресурс] // Open Network Foundation. – URL:
https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-
content/uploads/2014/10/openflow-switch-v1.5.1.pdf (дата обращения:
04.05.2018).
111. Ongaro D., Ousterhout J. In Search of an Understandable Consensus
Algorithm // Proceedings of USENIX Annual Technical Conference (ATC) 2014. –
Philadelphia, PA, June 2014.
112. Open Signal Reports [Электронный ресурс] // Open Signal. - URL:
https://opensignal.com/reports/ (дата обращения: 15.04.2018).
113. OpenDaylight Controller:MD-SAL:FAQ [Электронный ресурс] //
wiki.opendaylight.org. - URL:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:FAQ (дата
обращения: 27.04.2018).
145
114. OpenFlow Controller Benchmarking Tool [Электронный ресурс] //
Github. – URL: https://github.com/No6things/ofc-benchmark (дата обращения:
06.05.2018).
115. OpenFlow Switch Specification version 1.3.0 [Электронный ресурс]
// Open Network Foundation – URL: https://www.opennetworking.org/ (дата
обращения: 25.04.2018).
116. OpenStack [Электронный ресурс]. - URL:
https://www.openstack.org/ (дата обращения: 25.04.2018).
117. OpFlex: An Open Policy Protocol White Paper [Электронный ресурс]
// IETF.org. - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-
virtualization/application-centric-infrastructure/white-paper-c11-731302.html
(дата обращения: 25.04.2018).
118. Pan X. Internet-Draft Address Resolution Delay in SDN / X. Pan, W.
Sun [Электронный ресурс] // IETF.org. — URL: https://tools.ietf.org/html/draft-
pan-ippm-sdn-addr-resolv-perf-00 (дата обращения: 30.04.2018).
119. Product Specifications [Электронный ресурс] // Intel. - URL:
https://ark.intel.com/ (дата обращения: 02.05.2018).
120. Red Hat OpenDaylight Installation and Configuration Guide
[Электронный ресурс] // Red Hat. - URL:
https://access.redhat.com/documentation/en-
us/red_hat_openstack_platform/13/html/red_hat_opendaylight_installation_and_co
nfiguration_guide/high-availability-and-clustering-with-opendaylight
121. RFC 1157 A simple network management protocol (SNMP)
[Электронный ресурс] // IETF.org. – URL: https://www.ietf.org/rfc/rfc1157.txt
(дата обращения: 25.04.2018).
122. RFC 4271 A Border Gateway Protocol 4 (BGP-4) [Электронный
ресурс] // IETF.org. – URL: https://tools.ietf.org/html/rfc4271 (дата обращения:
25.04.2018).
146
123. RFC 5415 Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification [Электронный ресурс] // IETF.org. - URL:
https://tools.ietf.org/html/rfc5415 (дата обращения: 25.04.2018).
124. RFC 5440 Path Computation Element (PCE) Communication Protocol
(PCEP) [Электронный ресурс] // IETF.org. – URL:
https://tools.ietf.org/html/rfc5440 (дата обращения: 25.04.2018).
125. RFC 6020 YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF) [Электронный ресурс] // IETF.org. - URL:
https://tools.ietf.org/html/rfc6020 (дата обращения: 20.04.2018).
126. RFC 6830 The Locator/ID Separation Protocol (LISP) [Электронный
ресурс] // IETF.org. – URL: https://tools.ietf.org/search/rfc6830 (дата обращения:
25.04.2018).
127. RFC 7252 The Constrained Application Protocol (CoAP)
[Электронный ресурс] // IETF.org. - URL: https://tools.ietf.org/html/rfc7252 (дата
обращения: 25.04.2018).
128. RFC 7426 Software-Defined Networking (SDN): Layers and
Architecture Terminology [Электронный ресурс] // IETF.org. - URL:
https://tools.ietf.org/html/rfc7426 (дата обращения: 20.04.2018).
129. RFC 826 An Ethernet Address Resolution Protocol or Converting
Network Protocol Addresses [Электронный ресурс] // IETF.org. – URL:
https://tools.ietf.org/html/rfc826 (дата обращения: 07.05.2018).
130. S. D. Casey How to Determine the Effectiveness of Hyper-Threading
Technology with an Application [Электронный ресурс] // Intel. – URL:
https://software.intel.com/en-us/articles/how-to-determine-the-effectiveness-of-
hyper-threading-technology-with-an-application (дата обращения: 05.06.2018)
131. Sakic E., Kellerer W. Response time and availability study of RAFT
consensus in distributed SDN control plane // IEEE Transactions on Network and
Service Management. DOI 10.1109/TNSM.2017.2775061.
132. Salman O., Elhajj I. H., Kayssi A., Chehab A. SDN controllers: A
Comparative Study // 18th Mediterranean Electrotechnical Conference MELECON
147
2016, April 18-20, 2016. – Limassol, Cyprus, 2016.
DOI:10.1109/MELCON.2016.7495430.
133. SDN architecture overview version 1.0 [Электронный ресурс] // Open
Network Foundation. – URL:
https://www.opennetworking.org/images/stories/downloads/sdn-
resources/technical-reports/SDN-architecture-overview-1.0.pdf (дата обращения:
25.04.2018).
134. SDN Controllers Report 2015 Edition [Электронный ресурс] //
SDNCentral, LLC. – 2015. – URL: https://www.sdxcentral.com/reports/sdn-
controllers-report-2015/ (дата обращения: 25.04.2018).
135. SDN Series Part Six: OpenDaylight, the Most Documented Controller
[Электронный ресурс] // TheNewStack. - URL: https://thenewstack.io/sdn-series-
part-vi-opendaylight/ (дата обращения: 25.04.2018).
136. SDxCentral Network Virtualization (NV) and SDN Controller Report
2016 // SDNCentral, LLC. -2016.
137. Sen R., Ramachandra K. Characterizing resource sensitivity of database
workloads // 2018 IEEE International Symposium on High Performance Computer
Architecture (HPCA), 24-28 February 2018, Vienna, Austria. DOI:
10.1109/HPCA.2018.00062.
138. Shah S. Improve Performance and Throughput of VMs for Scientific
Workloads in a Cloud Enviroment / S. Shah, A. Jaikar, S. Bae, S. Noh // 2016
International Conference on Platform Technology and Service (PlatCon), 15-17
February, 2016, Jeju, South Korea. DOI: 10.1109/PlatCon.2016.7456802
139. Software-Defined Networking Promises Competitive Advantage
[Электронный ресурс] // Cisco. - URL:
https://www.cisco.com/c/dam/en/us/solutions/collateral/switches/catalyst-6500-
series-switches/telecom_italia_v3cs.pdf (дата обращения: 15.04.2018).
140. Suh D., Jang S., Han S., Pack S., Kim T., Kwak J. On performance of
OpenDaylight Clustering // 2016 IEEE NetSoft Conference and Workshops, June 6-
10, 2016. DOI:10.1109/NETSOFT.2016.7502476.
148
141. The Intel Xeon Phi Product Family Highly-Parallel Processing for
Unparalleled Discovery [Электронный ресурс] // Intel. - URL:
https://www.intel.com/content/dam/www/public/us/en/documents/product-
briefs/high-performance-xeon-phi-coprocessor-brief.pdf (дата обращения:
30.04.2018).
142. Tian Y. The performance model of Hyper-Threading technology in
Intel Nehalem microarchitecture / Y. Tian, C. Lin, K. Hu // 2010 3rd International
Conference on Advanced Computer Theory and Engineering, 20-22 August 2010,
Chengdu, China. DOI: 10.1109/ICACTE.2010.5579564
143. Toghraee R. Learning OpenDaylight // Packt Publishing. – 2017. –
p.221
144. Tootoonchian A. On Controller Performance in Software-Defined
Networks / A. Tootoonchian, S. Gorbunov, M. Casado, R. Sherwood // Proceedings
of Hot-ICE'12 Proceedings of the 2nd USENIX conference on Hot Topics in
Management of Internet, Cloud, and Enterprise Networks and Services, April, 2012.
145. TrendForce Finds x86 Processors Continues to Corner Server Market
This Year With Global Shipment Share Estimated at 96% [Электронный ресурс]
// DRAMeXchange. - URL:
https://www.dramexchange.com/WeeklyResearch/Post/2/4794.html (дата
обращения: 29.04.2018).
146. Veitch P., Curley E., Kantecki T. Performance Evaluation of Cache
Allocation Technology for NFV Noisy Neighbor Mitigation // 2017 IEEE
Conference on Network Softwarization (NetSoft), 3-7 July, 2017, Bologna, Italy.
DOI: 10.1109/NETSOFT.2017.8004214
147. WCbench [Электронный ресурс] // Github. – URL:
https://github.com/dfarrell07/wcbench (дата обращения: 06.05.2018).
148. Wei L. An online flow-level Packet Classification Method on Multi-
core Network Processor / L. Wei, Y. Xiufen // 2015 11th International Conference
on Computational Intelligence and Security (CIS), 19-20 December, 2015,
Shenzhen, China.
149
149. wiki.opendaylight.org [Электронный ресурс]. - URL:
https://wiki.opendaylight.org/view/Release/Hydrogen/Service_Provider/User_Guid
e (дата обращения: 25.04.2018).
150. Zhao Y. On the Performance of SDN Controllers: A Reality Check / Y.
Zhao, L. Iannone, M. Riguidel // 2015 IEEE Conference on Network Function
Virtualization and Software Defined Network, November 18-21, 2015. - San
Francisco, USA, 2015. DOI: 10.1109/NFV-SDN.2015.7387410
150
ПРИЛОЖЕНИЕ А.
Программа автоматизации тестирования контроллеров
программно-конфигурируемых сетей на базе протокола
OpenFlow
Файл setting.ini – задаёт параметры тестирования
[general]
server= #IP-адрес ПКС-контроллера в формате IPv4
port= #порт
switches=[] #количество управляемых коммутаторов
cbench_folder=/root/oflops/cbench #директория расположения утилиты
cbench
test_length= #длительность теста (милисекунды)
loops= #количество тестов
cores= #число активных ядер ЦП, при котором осуществляется
тестирование
pause= #пауза между тестами (секунды)
Файл run_test.py – осуществляет запуск утилиты Cbench с заданными в
setting.ini параметрами
#!/usr/bin/env python3
# -*- coding: utf8 -*-
from configparser import ConfigParser
import sys
import os
import subprocess
from time import sleep
import calc
config = ConfigParser()
config.read("settings.ini")
CONTROLLER = config["general"]["server"]
151
PORT = config["general"]["port"]
SWITCHES_LIST = config["general"]["switches"].replace("[",
"").replace("]", "").split(",")
CBENCH_FOLDER = config["general"]["cbench_folder"]
TEST_LENGTH = config["general"]["test_length"]
LOOPS_NUM = config["general"]["loops"]
CORES = config["general"]["cores"]
FILENAME = "result_{}_{}.txt"
FINAL_FILENAME = "c{}_final_result.txt".format(CORES)
MODES = ["latency", "throughput"]
PAUSE = int(config["general"]["pause"])
def make_command(c, s):
return c.format(CBENCH_FOLDER, CONTROLLER, PORT, LOOPS_NUM,
TEST_LENGTH, s)
def print_output(p):
while True:
s = p.stdout.readline()
if not s: break
print(s,)
def make_test(base_command, mode):
m = mode[0]
for s in SWITCHES_LIST:
PIPE = subprocess.PIPE
comm = make_command(base_command, s)
if mode == "throughput":
comm = comm + " -t"
comm = comm + " > " + "results/" + FILENAME.format(m, s)
print("Start test for {} mode and s={}".format(mode, s))
p = subprocess.Popen(comm, shell=True, stdin=PIPE,
stdout=PIPE,
stderr=subprocess.STDOUT, close_fds=True)
p.wait()
152
#print_output(p) # Uncomment for cbench output test
print("End test")
sleep(PAUSE)
def write_results_to_file(result_list):
rows = []
rows.append("cores;switches;min;max;avg;stdev;latency\n")
for el in result_list:
rows.append(";".join(el) + "\n")
with open(FINAL_FILENAME, "w") as out_file:
out_file.writelines(rows)
def sort_result_list(l):
"""Sort list by switches"""
sorted_switches_list = sorted([int(i) for i in SWITCHES_LIST])
sorted_l = []
for sw_num in sorted_switches_list:
for el in l:
if int(el[1]) == sw_num:
sorted_l.append(el)
return sorted_l
if __name__ == "__main__":
base_command = "{}/cbench -c {} -p {} -l {} -m {} -s {}"
for mode in MODES:
make_test(base_command, mode)
lat_results_list = []
tp_results_list = []
for file in list(os.walk("results"))[0][2]:
153
if file[7] == "l":
avg_lat = calc.get_latency_result(file)
lat_results_list.append((CORES, file.replace(".txt",
"")[9:], str(avg_lat)))
lat_results_list = sort_result_list(lat_results_list)
elif file[7] == "t":
avg_tp = calc.get_throughput_result(file)
if avg_tp == None:
continue
tp_results_list.append((CORES, file.replace(".txt",
"")[9:], *[str(s) for s in avg_tp]))
tp_results_list = sort_result_list(tp_results_list)
result = []
for n, el in enumerate(lat_results_list):
result.append(tp_results_list[n] + (el[2],))
write_results_to_file(result)
Файл calc.py – осуществляет расчет задержки и пропускной способности
ПКС-контроллера по результатам теста(ов)
#!/usr/bin/env python3
# -*- coding: utf8 -*-
import os
RESULTS_FOLDER = "results"
def latency_file_format(file):
results_list = []
for line in file:
line = line[line.find("sec:") + 6:]
line = line[:line.find("total") - 3]
results_list.append(line)
154
*result, last = results_list
num_list = [[int(s) for s in l.split(" ")] for l in result]
return num_list
def throughput_file_format(file):
for line in file:
pass
last = line
if last == "": return None
last = last[last.find("=") + 1:]
last = last[:last.find("responses") - 1]
results = last.split("/")
return list(map(float, results))
def average(results_list):
averages = []
for row in results_list:
averages.append(sum(row) / len(row))
return sum(averages) / len(averages)
def get_latency_result(file):
with open(RESULTS_FOLDER + "/" + file, "r") as f:
# Exclude first and last row of results
first, *results, last = latency_file_format(f)
return round(1 / average(results) * 1000, 3)
def get_throughput_result(file):
with open(RESULTS_FOLDER + "/" + file, "r") as f:
return throughput_file_format(f)
if __name__ == "__main__":
pass
155
ПРИЛОЖЕНИЕ Б
Копия свидетельства о государственной регистрации
программы для ЭВМ
156
ПРИЛОЖЕНИЕ В
Процедура установки и настройки СОС OpenDaylight
Для возможности запуска и функционирования СОС OpenDaylight
необходимо, чтобы в операционной системе имелась установленная среда
выполнения Java (Java Runtime Environment, JRE), включающая в себя
библиотеку Java-классов и виртуальную машину Java Virtual Machine (JVM).
В среде операционной системы Ubuntu 14.04 установить JRE можно,
выполнив указанную в данном приложении последовательность действий.
Шаг 1. Обновляем список пакетов:
apt-get update
Шаг 2. Проверяем, имеется ли в операционной системе установленная
версия Java:
java -version
Если консоль возвращает результат «The program java can be found in the
following packages», то Java в системе не установлена.
Для установки необходимо выполнить команду:
sudo apt-get install default-jre
Снова проверяем версию Java. В результате выполнения команды java –
version консоль вернет результат вида:
java version “1.8.0_101”
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot (TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
Шаг 3. Установка переменной окружения JAVA_HOME необходима
для определения места установки Java в системе.
Для начала необходимо узнать путь к установленной Java:
update-alternatives --config java
В результате выполнения команды в консоль вернётся путь, который
необходимо скопировать. Далее редактируем файл среды в каталоге etc с
помощью любого текстового редактора (например, nano):
sudo nano /etc/environment
157
JAVA_HOME="_путь_к_Java_"
После сохранения внесенных изменений, необходимо убедиться в том,
что они были применены с помощью команды:
source /etc/environment
Проверить путь к JAVA_HOME можно с помощью команды:
echo $JAVA_HOME
В результате выполнения в консоль должен быть выведен путь к
переменной.
Шаг 4. Установка Apache Maven.
OpenDaylight использует Apache Maven – инструмент для сборки
программного обеспечения на языке Java: компиляции, создания jar, создания
дистрибутива программы, генерации документации.
Установить последнюю версию Maven можно используя менеджер
пакетов:
apt-get install maven
Проверить наличие Maven в системе можно с помощью команды:
mvn -version
В результате выполнения команды консоль вернет строку следующего
вида:
Apache Maven 3.3.9
Maven home: /usr/local/apache-maven-3.3.9
Java version: 1.8.0_101, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: ru_ru, platform encoding: UTF-8
OS name: "linux", version: "4.2.0-42-generic", arch: "amd64", family: "unix"
Шаг 5. Загрузка дистрибутива СОС OpenDaylight.
Необходимо загрузить дистрибутив СОС с официального сайта
https://www.opendaylight.org/. В ОС Ubuntu это можно сделать с помощью
консоли:
wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/
158
integration/distribution-karaf/0.4.1-Beryllium/distribution-karaf-0.4.1-
Beryllium.tar.gz
Далее необходимо разархивировать загруженный файл:
tar -xvf distribution-karaf-0.4.1-Beryllium.tar.gz
В результате выполнения команды получим папку distribution-karaf-
0.4.1-Beryllium, содержащую СОС OpenDaylight в виде karaf-контейнера. Karaf
- это контейнер, который позволяет разработчикам помещать все необходимое
программное обеспечение для распространения в одну папку. Такой подход
упрощает установку или переустановку программного обеспечения (в нашем
случае - СОС OpenDaylight) при необходимости, потому что все находится в
одной папке. Karaf также позволяет программам поставлять программное
обеспечение с дополнительными модулями, которые могут быть установлены
при необходимости.
Запустить СОС OpenDaylight можно перейдя в папку и запустив karaf-
контейнер:
cd distribution-karaf-0.4.1-Beryllium
./bin/karaf
На экране появится консоль управления СОС OpenDaylight, как
показано на рисунке.
Рисунок – Консоль СОС OpenDaylight
159
Посмотреть перечень всех модулей СОС можно с помощью команды
feature: list, а список установленных модулей - с помощью команды feature:
list –i.
С использованием консоли для СОС необходимо установить
следующие модули:
feature:install odl-l2switch-switch
feature:install odl-l2switch-switch-ui
feature:install odl-openflowplugin-all
feature:install odl-openflowplugin-drop-test
dropallpacketrsrpc on
160
ПРИЛОЖЕНИЕ Г.
Экспериментально измеренные задержки ПКС-контроллера и рассчитанные на основе них
значения ускорения, эффективности и доли линейных операций
Задержки ПКС-контроллера на аппаратных платформах с ЦП Xeon E3 и Xeon E5 при 16 OpenFlow-коммутаторах
Число ядер ЦП, штук
Задержка ПКС-контроллера, мкс
Xeon E3 Xeon E5 Xeon E3 HT Xeon E5 HT
1 89 53 79 63
2 68 52 64 35
3 63 35 56 26
4 62 32 53 22
5 24 20
6 22 21
7 20 20
8 21 20
9 22 21
10 22 20
11 23 21
12 23 22
161
Рассчитанные значения ускорения на аппаратных платформах с ЦП Xeon E3 и Xeon E5 при 16 OpenFlow-коммутаторах
Число ядер ЦП, штук
Ускорение, раз
Xeon E3 Xeon E5 Xeon E3 HT Xeon E5 HT
1 1 1 1.13 0.84127
2 1.3 1.019231 1.393 1.514286
3 1.39 1.514286 1.608 2.038462
4 1.43 1.65625 1.674 2.409091
5 2.208333 2.65
6 2.409091 2.52381
7 2.65 2.65
8 2.52381 2.65
9 2.409091 2.52381
10 2.409091 2.65
11 2.304348 2.52381
12 2.304348 2.409091
162
Рассчитанные значения эффективности аппаратных платформ с ЦП Xeon E3 и Xeon E5 при 16 OpenFlow-коммутаторах
Число ядер ЦП, штук
Эффективность
Xeon E3 Xeon E5 Xeon E3 HT Xeon E5 HT
1 1 1 1.13 0.84127
2 0.65 0.509616 0.696 0.757143
3 0.463333 0.504762 0.536 0.679487
4 0.3575 0.414063 0.419 0.602273
5 0.441667 0.53
6 0.401515 0.420635
7 0.378571 0.378571
8 0.315476 0.33125
9 0.267677 0.280423
10 0.240909 0.265
11 0.209486 0.229437
12 0.192029 0.200758
163
Рассчитанная доля линейных операций на аппаратных платформах с ЦП Xeon E3 и Xeon E5 при 16 коммутаторах
Число ядер ЦП, штук
Доля линейных операций
Xeon E3 Xeon E5 Xeon E3 HT Xeon E5 HT
1 1 1 1.13 0.84127
2 0.65 0.509616 0.696 0.757143
3 0.463333 0.504762 0.536 0.679487
4 0.3575 0.414063 0.419 0.602273
5 0.441667 0.53
6 0.401515 0.420635
7 0.378571 0.378571
8 0.315476 0.33125
9 0.267677 0.280423
10 0.240909 0.265
11 0.209486 0.229437
12 0.192029 0.200758
164
Задержки ПКС-контроллера на аппаратных платформt с ЦП Xeon E5 при
различном числе OpenFlow-коммутаторов
Задержка, мкс
Число
OpenFlow-
коммутат
оров,
штук
Число ядер ЦП, штук
1 2 3 4 5 6 7 8 9 10 11 12
1 31 28 32 38 33 39 33 38 42 42 46 45
1, HT 31 34 34 36 36 42 42 42 45 42 49 47
2 26 28 32 31 32 35 34 38 39 38 40 37
2, HT 29 32 32 32 33 34 34 37 40 35 46 39
4 21 26 23 26 28 28 30 32 33 34 35 34
4, HT 25 28 29 28 30 31 29 32 32 35 35 38
8 30 32 23 21 20 22 24 25 24 24 24 26
8, HT 36 22 21 20 22 22 21 25 23 24 25 28
16 53 52 35 32 24 22 20 21 22 22 23 23
16, HT 63 35 26 22 20 21 20 20 21 20 21 22
32 96 78 62 48 39 32 30 25 24 22 24 23
32, HT 96 55 41 33 29 25 22 22 22 22 22 23
64 177 122 99 72 63 57 52 45 41 36 38 37
64, HT 153 90 67 57 50 42 37 39 37 34 32 30
128 337 211 159 117 111 106 94 84 79 75 73 71
128, HT 246 149 119 99 91 79 69 73 69 63 59 56
165
Рассчитанные значения ускорения на аппаратной платформе с ЦП Xeon E5 при
различном числе OpenFlow-коммутаторов
Ускорение, раз
Число
OpenFlow-
коммутат
оров,
штук
Число ядер ЦП, штук
1 2 3 4 5 6 7 8 9 10 11 12
1 1
1.107
143
0.968
75
0.815
789
0.939
394
0.794
872
0.939
394
0.815
789
0.738
095
0.738
095
0.673
913
0.688
889
1, HT 1
0.911
765
0.911
765
0.861
111
0.861
111
0.738
095
0.738
095
0.738
095
0.688
889
0.738
095
0.632
653
0.659
574
2 1
0.928
571
0.812
5
0.838
71
0.812
5
0.742
857
0.764
706
0.684
211
0.666
667
0.684
211 0.65
0.702
703
2, HT
0.896
552
0.812
5
0.812
5
0.812
5
0.787
879
0.764
706
0.764
706
0.702
703 0.65
0.742
857
0.565
217
0.666
667
4 1
0.807
692
0.913
043
0.807
692 0.75 0.75 0.7
0.656
25
0.636
364
0.617
647 0.6
0.617
647
4, HT 0.84 0.75
0.724
138 0.75 0.7
0.677
419
0.724
138
0.656
25
0.656
25 0.6 0.6
0.552
632
8 1
0.937
5
1.304
348
1.428
571 1.5
1.363
636 1.25 1.2 1.25 1.25 1.25
1.153
846
8, HT
0.833
333
1.363
636
1.428
571 1.5
1.363
636
1.363
636
1.428
571 1.2
1.304
348 1.25 1.2
1.071
429
16 1
1.019
231
1.514
286
1.656
25
2.208
333
2.409
091 2.65
2.523
81
2.409
091
2.409
091
2.304
348
2.304
348
16, HT
0.841
27
1.514
286
2.038
462
2.409
091 2.65
2.523
81 2.65 2.65
2.523
81 2.65
2.523
81
2.409
091
32 1
1.230
769
1.548
387 2
2.461
538 3 3.2 3.84 4
4.363
636 4
4.173
913
32, HT 1
1.745
455
2.341
463
2.909
091
3.310
345 3.84
4.363
636
4.363
636
4.363
636
4.363
636
4.363
636
4.173
913
64 1
1.450
82
1.787
879
2.458
333
2.809
524
3.105
263
3.403
846
3.933
333
4.317
073
4.916
667
4.657
895
4.783
784
64, HT
1.156
863
1.966
667
2.641
791
3.105
263 3.54
4.214
286
4.783
784
4.538
462
4.783
784
5.205
882
5.531
25 5.9
128 1
1.597
156
2.119
497
2.880
342
3.036
036
3.179
245
3.585
106
4.011
905
4.265
823
4.493
333
4.616
438
4.746
479
128, HT
1.369
919
2.261
745
2.831
933
3.404
04
3.703
297
4.265
823
4.884
058
4.616
438
4.884
058
5.349
206
5.711
864
6.017
857
166
Рассчитанные значения эффективности аппаратной платформы с ЦП Xeon E5
при различном числе OpenFlow-коммутаторов
Эффективность
Число
OpenFlow-
коммутат
оров,
штук
Число ядер ЦП, штук
1 2 3 4 5 6 7 8 9 10 11 12
1 1
0.553
571
0.322
917
0.203
947
0.187
879
0.132
479
0.134
199
0.101
974
0.082
011
0.073
81
0.061
265
0.057
407
1, HT 1
0.455
882
0.303
922
0.215
278
0.172
222
0.123
016
0.105
442
0.092
262
0.076
543
0.073
81
0.057
514
0.054
965
2 1
0.464
286
0.270
833
0.209
677
0.162
5
0.123
81
0.109
244
0.085
526
0.074
074
0.068
421
0.059
091
0.058
559
2, HT
0.896
552
0.406
25
0.270
833
0.203
125
0.157
576
0.127
451
0.109
244
0.087
838
0.072
222
0.074
286
0.051
383
0.055
556
4 1
0.403
846
0.304
348
0.201
923 0.15 0.125 0.1
0.082
031
0.070
707
0.061
765
0.054
545
0.051
471
4, HT 0.84 0.375
0.241
379
0.187
5 0.14
0.112
903
0.103
448
0.082
031
0.072
917 0.06
0.054
545
0.046
053
8 1 0.5
0.333
333 0.25 0.2
0.166
667
0.142
857 0.125
0.111
111 0.1
0.090
909
0.083
333
8, HT
0.833
333
0.681
818
0.476
19 0.375
0.272
727
0.227
273
0.204
082 0.15
0.144
928 0.125
0.109
091
0.089
286
16 1
0.509
615
0.504
762
0.414
063
0.441
667
0.401
515
0.378
571
0.315
476
0.267
677
0.240
909
0.209
486
0.192
029
16, HT
0.841
27
0.757
143
0.679
487
0.602
273 0.53
0.420
635
0.378
571
0.331
25
0.280
423 0.265
0.229
437
0.200
758
32 1
0.615
385
0.516
129 0.5
0.492
308 0.5
0.457
143 0.48
0.444
444
0.436
364
0.363
636
0.347
826
32, HT 1
0.872
727
0.780
488
0.727
273
0.662
069 0.64
0.623
377
0.545
455
0.484
848
0.436
364
0.396
694
0.347
826
64 1
0.725
41
0.595
96
0.614
583
0.561
905
0.517
544
0.486
264
0.491
667
0.479
675
0.491
667
0.423
445
0.398
649
64, HT
1.156
863
0.983
333
0.880
597
0.776
316 0.708
0.702
381
0.683
398
0.567
308
0.531
532
0.520
588
0.502
841
0.491
667
128 1
0.798
578
0.706
499
0.720
085
0.607
207
0.529
874
0.512
158
0.501
488
0.473
98
0.449
333
0.419
676
0.395
54
128, HT
1.369
919
1.130
872
0.943
978
0.851
01
0.740
659
0.710
97
0.697
723
0.577
055
0.542
673
0.534
921
0.519
26
0.501
488
167
Рассчитанная доля линейных операций на аппаратной платформе с ЦП Xeon E5
при различном числе OpenFlow-коммутаторов
Доля линейных операций
Число
OpenFlow-
коммутат
оров,
штук
Число ядер ЦП, штук
1 2 3 4 5 6 7 8 9 10 11 12
1 1
0.252
226
0.207
715
0.129
575
0.161
721
0.177
448
0.158
754
0.142
009
0.138
724
0.136
169
0.138
279
0.138
926
2 1
0.378
531
0.338
983
0.209
04
0.194
915
0.186
441
0.176
083
0.147
7
0.135
593
0.114
878
0.136
158
0.137
134
4 1 0.625
0.468
75
0.333
333
0.257
813 0.2
0.197
917
0.154
762
0.156
25
0.143
519 0.175
0.170
455
8 1
0.962
264
0.490
566
0.471
698
0.316
038
0.298
113
0.273
585
0.309
973
0.341
981
0.350
105
0.377
358
0.382
504
16 1
1.133
333 0.65 0.6
0.583
333 0.68
0.766
667
0.809
524 0.775
0.777
778 0.78
0.854
545
32 1
1.476
19
1.142
857
1.317
46
1.416
667 1.4 1.5
1.598
639
1.642
857
1.687
831
1.733
333
1.675
325
64 1
1.153
846
1.346
154
1.256
41
1.288
462
1.415
385
1.358
974
1.527
473
1.562
5
1.512
821
1.592
308
1.461
538
128 1
0.806
452
1.048
387
1.301
075
1.080
645
1.309
677
1.075
269
1.258
065
1.399
194
1.394
265
1.532
258
1.492
669
168
ПРИЛОЖЕНИЕ Д.
Акты о внедрении результатов работы
169