CC BY
37
УДК 004.75
Ю.А. Ушаков, кандидат технических наук, доцент кафедры геометрии и компьютерных наук, ФГБОУ ВО «Оренбургский государственный университет»
А.Л. Коннов, кандидат технических наук, доцент кафедры управления и информатики в технических системах, ФГБОУ ВО «Оренбургский государственный университет»
П.Н. Полежаев, преподаватель кафедры компьютерной безопасности и математического обеспечения информационных систем, ФГБОУ ВО «Оренбургский государственный университет» e-mail: andrey_konnov@mail.ru
МОДЕЛИРОВАНИЕ КОРПОРАТИВНОЙ СЕТИ, ПОСТРОЕННОЙ НА ОСНОВЕ ПРИНЦИПОВ ПРОГРАММНО-КОНФИГУРИРУЕМОЙ ИНФРАСТРУКТУРЫ И ВИРТУАЛИЗАЦИИ
СЕТЕВЫХ ФУНКЦИЙ
Предмет: исследование корпоративных сетей.
Цели: создание моделей корпоративной сети, построенной на основе принципов программно-конфигурируемой инфраструктуры.
Актуальность. Одной из сложных, и в то же время мало представленных в готовых системах моделирования областей является виртуализация сетевых функций и протоколы программно-конфигурируемой сети. Поэтому исследователи, решившие создать адекватную модель таких сетей, сталкиваются с отсутствием готовых математически определенных закономерностей в поведении трафика.
Методология. Подход состоит в использовании при моделировании аппроксимационных методов с учетом первых двух-трех моментов распределений параметров трафика.
В результате была разработана модель, показывающая схожее по форме поведение при нагрузках, коррекцию можно вносить после доработки модели для конкретной реализации сети в виде поправочных коэффициентов после первых прогонов.
Выводы. Созданный подход позволяет с высокой точностью повторять поведение оборудования при различных режимах работы в рамках одной модели при условии корректировки для конкретной будущей реализации.
Ключевые слова: программно-конфигурируемые сети, NFV-сети, мониторинг сети.
Введение
Создание модели телекоммуникационной сети организации достаточной детализации и точности всегда представляет собой сложную инженерную задачу. Множество современных протоколов, топологий, подходов к построению сети делает эту задачу сложнее с каждым годом. Сейчас некоторые особенности поведения сети быстрее исследовать на натурных стендовых моделях, поскольку сложность моделирования поведения протоколов только повышается.
Одной из сложных и в то же время мало представленных в готовых системах моделирования областей является виртуализация сетевых функций (NetworkFunctionVirtualization, NFV) и протоколы программно-конфигурируемой сети (Software-DefinedNetworks). Исследователи, решившие создать адекватную модель таких сетей, сталкиваются с отсутствием готовых математически определенных закономерностей в поведении трафика при управлении SDN контроллером. Каждый контроллер имеет свои модули расчета оптимальных деревьев коммутации, путей маршрутизации, алгоритмы работы с очередями QoS и перебалансировки трафика. В результате описать статистически по-
ведение коммутатора, управляемого контроллером SDN, бывает крайне сложно.
Для создания подобных моделей все чаще прибегают к первоначальному созданию прототипа, на основе которого получают предельные и статистические зависимости и характеристики. На основе этих характеристик исследуют один статический срез топологии сети. Такой подход позволяет провести серию испытаний со срезами сети и получить закономерности поведения оборудования и трафика в условиях постоянно меняющейся топологии. Однако такой подход сопряжен с большой трудоемкостью и требует высокой квалификации для создания прототипа.
Методика синтеза моделей
Для создания точных моделей сети необходимо максимально адекватно описать статистические закономерности поведения трафика как внутри активных устройств, так и в сетях устройств. Наиболее точные модели можно получить при помощи имитационного моделирования и при использовании аппроксимационных методов с учетом первых двух-трех моментов распределений параметров трафика (например, времени между пакетами).
На рисунке 1 показана схема типичного виртуального коммутатора OpenvSwitch (OVS) [1].
Remote
Kemel space
Рисунок 1. Схема виртуального коммутатора
При получении пакета (стрелка 1) его поля проверяются в кэше Datapath, который формируется автоматически на каждую таблицу OpenFlow. При точном совпадении коммутация происходит в ядре, не выходя в Userspace. Максимальный размер кэша в коммутаторах на основе OpenvSwitch - 8912 записи на каждый процесс OVS. При несовпадении начинается многоуровневый процесс поиска пути следования. Второй уровень очередей передает пакет классификатору трафика (один на каждый Datapath, стрелка 2), где по алгоритму Tuple Space Classifier (TCS) происходит поиск совпадений правил (проверки на совпадения могут быть с нечеткими или широкими условиями, например, с подстановочными символами). В таблице может быть до 65535 строк, которые разбиваются на под-таблицы в соответствии с приоритетом каждой записи. При совпадении пакет передается обратно вместе со структурой данных о дальнейшей судьбе пакета (стрелка 5). Если данные не найдены, наступает очередь OpenFlow таблиц (до 255 штук), которые работают аналогично таблице второго
уровня, но могут содержать ссылки на переход в другие таблицы OpenFlow. При отсутствии подходящих правил в таблицах OpenFlow посылается запрос на контроллер (стрелка 3), после чего полученное от него правило записывается в таблицу OpenFlow (стрелка 4), в таблицу Datapath (стрелка 6) и в кэш. Стрелка 7 соответствует выходу пакета из OpenvSwitch.
Если в обычном коммутаторе L2 время поиска информации о коммутации можно описать вероятностными характеристиками, в коммутаторе L3 достаточно скорректировать закон распределения в соответствии с временем поиска маршрута при первой коммутации пакета. В OpenFlow коммутаторе при достижении алгоритмом поиска действий в таблицах OpenFlow (стрелки 2 и 3) время такого поиска прямо зависит от оптимальности построения таблиц правил, суммирования строк и использования подстановочных символов.
На рисунке 2 показана схема прохождения трафика через инфраструктуру для достижения виртуального модуля NFV [9,10].
"virtuall- ч Virtual module
Input ' Output
Рисунок 2. Трафик к виртуальному модулю NFV
При работе совместно с возникают проблемы маркировки трафика (для этого используется УХЬАК), проблемы дублирования пакета (пакет вышел такой же, как и вошел). Для модели это не имеет значения, но прототип может не заработать с такими ограничениями.
При синтезе модулей модели необходимо учитывать вероятность перехода по различным веткам
алгоритма коммутации OpenFlow, вероятность коммутации в конкретные виртуальные модули, вычислительную сложность каждой ветви алгоритма поиска пути.
В системах имитационного моделирования встречаются модули симуляции процессов. Например, в №3 можно использовать даже настоящий контроллер, которому будет приходить сообщения
о пакете или использовать настоящий виртуальный коммутатор, куда отдавать синтезированный пакет. В ОМ№Т++ используется более простая модель сложных процессов.
Реализация OpenFlow в системах моделирования происходит по-разному. Возьмем за основу систему ОМ№Т++. Для моделирования коммута-
тора с внешним управлением обычно используется слегка измененный коммутатор [2]. При получении пакета коммутатор с некоторой вероятностью отсылает пакет в контроллер, который представлен как обычный узел с определенными параметрами производительности и ее законом распределения (рисунок 3).
Рисунок 3. Схема простейшей модели OpenFlow
При моделировании переход пакета на контроллер о суще ствляется с вероятно стью p(openflow) и локальная обработка с вероятностью p(datapath)=1-p(openflow). Производительность (интенсивность) обработки пакетовкэшем Datapath - ц(.datapath), контроллера - ju(openflow), модифицированной для
кешатаблицей CAM коммутатора - ц(САМ). Для более сложного моделирования требуется собрать схему контроллера с несколькими обслуживающими линиями, которые распределяют задержку по разным законам и/или с разными параметрами (рисунок 4).
Рисунок 4. Схема более точной модели коммутатора OpenFlow
При входе пакета он с вероятностью p(drop1) удаляется из очереди (моделирование потери пакетов), или с вероятностью 1-p(drop1) переходит на первое действие. Производительность узла 1 - ^1(openflow). Из первого узла с вероятностью p(openflow1) пакет идет на выход и с вероятностью 1-p(openflow1) во второй узел. Цепочка состоит из трех узлов обработки, каждая со своей интенсивностью обслуживания. За счет управления вероятностями переходов и интенсивностью обслуживания пакетов можно моделировать довольно сложное поведение коммутатора. Пакет, не обработанный даже в третьем узле, отбрасывается.
Расчет вероятностей переходов внутри контроллера осуществляется или статистическим анализом правил в совокупности с матрицей вероятностных переходов всей сети в целом или планируется эксперимент с изменением в каких-либо пределах доли трафика, попадающего в различные части контроллера.
Самая точная модель контроллера получается при переносе в модель схемы принятия решений и переходов между модулями, которая используется в настоящих NFV системах[9,10], интегрированных с OpenFlow (рисунок 5).
Далее необходимо удостовериться, что эта схема наиболее точно отражает реальный контроллер OpenFlow. Для этого проведем эксперимент с моделью и сравним показатели с реальным котроллером RYU в системе OpenStack и коммутатором OVS. Планирование эксперимента Эксперимент будет состоять из двух частей. Первая часть будет состоять из получения задержек и выборочных законов распределения для собранного прототипа. Вторая часть - из моделирования аналогичной схемы в OMNeT++ и сравнения результатов.
Прототип будет состоять из узла виртуализации под управлением OpenPlatformforNFV (OPNFV), на котором будут запущены два узла (рисунок 6). В качестве коммутатора будет выступать
NAT-FIB Table (28)
NAPT-FIB Table 47
Inbound NAPT Table 44
DNAT Table 25
Outbound NAPT Table (46) Match Miss
LFIB Table 20 Match mpls label
External tunnel/TST Table 38
Рисунок 5. Модули коммутации NFV
Table 0 Int. Tunnel of-port ExL Tunnel of-port VM Port VM OF Port
DHCP Ext Tunnel
Table f 181 DHCP mateh Table miss
DHCP
_Tahla (16)_
DHCP mateh Table miss
SNAT NAPT Group
Match
Miss
FIB Table 21
Default Route
Subnet Route
Local NH ARP Match
Remote NH Miss
Table miss
Unknown DMAC Table 52
ELAN DMA С Table 51
Miss Local BC Group
Match
ELAN BC
ELAN SM А С Group
Table miss Filter Equal table
Match (OF Port out)
OpenvSwitchv2.5, SDN контроллера - RYU 4.11. Прототип был собран по типовой схеме, как показано в [3,7].
Для реализации были взяты три однотипных узла, соединенных цепочкой. На каждом узле есть еще один интерфейс для управления.
Рисунок 6. Схема прототипа
На узлах установлен AlpineLinux с пакетами OpenSSH, tcpdump (снифер), flowgrind (генератор трафика). Генерация трафика будет проходить в соответствии с экспоненциальным распределением и распределением Вейбулла [8,9] для соответственно интервалов времени между пакетами и их размеров. Для этого используется утилита flowgrind на обоих хостах. Параметры законов будут меняться через SSH целью построения зависимостей от нагрузки и автоматизации эксперимента.
Для расчета времени прохождения через коммутатор будут использоваться дампы tcpdump с параметром «-tttt» для записи времени пакета с точностью до микросекунд. Поскольку время на хостах синхронизировано, можно будет рассчитать время прохождения каждого пакета. Для отличия пакетов друг от друга каждый следующий будет отправляться на другой номер порта.
Для модели OMNeT++ был выбран фреймворк ofomnet [4], который ответвляет трафик на контроллер SDN. Контроллер был реализован как несколько линий задержек с заданными вероятностями переходов по портам [5]. На рисунке 7 показана реализация сетевой части контроллера в OMNeT++ вместе с модулем статистических переходов, основанном на ProFiDo модуле и управляющем блоке arrivalProcess. Каждая линия задержки основана на ProFiDo модуле и выглядит так, как показано
на рисунке 8. Параметры задаются через параметр arrivalProcess.model, например, exponential (0.5s) или через вероятности перехода на нужное направление.
В данном эксперименте параметры экспоненциального закона вероятности перехода были взяты из выборочной статистики после обработки данных прогона прототипа.
Вход осуществляется в узел I, выход в узел O. Вероятности переходов задаются в файлахХМЬ (узлы на связях) на каждую связь отдельно.
Эксперимент
Первый исследуемый показатель - время задержки при минимальном и максимальном сценарии поиска маршрута OpenFlow. Минимальное время обеспечивается работой кэша datapath, для этого правила каждого потока предустанавливаются в коммутатор (режим proactive). Для максимальной задержки каждый пакет опрашивает контроллер (режим reactive). На рисунке 9 показаны задержки коммутатора (первый момент распределения) в зависимости от количества потоков в корпоративной сети. По выборке был проведен анализ распределения полученных значений для значения количества потоков.
Как видно из графиков (рисунок 10), закон распределения может варьироваться при изменении нагрузки, переходить к неэкспоненциальным и составным распределениям. Поэтому оптималь-
eth [SEedrfiethgJI
Рисунок 7. Модель одного процесса в OMNeT++
XML-MAP
LP:map3-0.xml
Рисунок 8. Модель одного контроллера в модуле ProFiDo ОМ№Т++
18 16 с 14
м
Ü" О 1 О
5 10 20
Кол-во потоков
■Задержка мин.мс
-Задержка макс.мс
Рисунок 9. Задержка OVS при наращивании количества потоков
Рисунок 10. Распределение плотности вероятности времени задержки OVS при наращивании количества потоков
нее всего задавать закон распределения первыми двумя моментами и коэффициентом вариации, как показано в [6].
По полученным данным первых моментов и коэффициента вариации была построена модель с двумя состояниями OpenFlow контроллера - про-активным и реактивным. Вероятности перехода устанавливались для двух режимов: только первый
Рисунок 11. Результаты
Как видно, в режиме OpenFlow имеется расхождение при больших нагрузках. Модель занижает показания, поскольку не учитывается влияние нагрузки сервера на отклик контроллера, на накладные расходы по генерации и обработки трафика, на переключение ядер внутри сервера между задачами. В общем случае, разработанная модель показывает схожее по форме поведение при нагрузках, коррекцию можно вносить после доработки модели для конкретной реализации сети в виде попра-
узел задержки и только все узлы последовательно. Вероятности ответвления устанавливались в ноль. Задержку и распределение времени между пакетами можно получить из сырых данных, записанных в файл журнала, для этого надо активировать запись по фильтру на требуемых интерфейсах. На рисунке 11 показаны результаты эксперимента после обработки.
вочных коэффициентов после первых прогонов.
Выводы
Созданный подход позволяет с высокой точностью повторять поведение оборудования при различных режимах работы в рамках одной модели при условии корректировки для конкретной будущей реализации. Полученные результаты будут использованы для автоматизации создания подобных моделей с помощью NFV платформ, MANO платформ и Docker/LXC машин.
Литература
1. Карташевский, И.В. Исследование реального трафика в телекоммуникационных и компьютерных сетях / И.В. Карташевский, В.Н. Тарасов // «Инфокоммуникационные технологии». - Т. 8. - № 4. - 2010. [Электронный ресурс] - Режим доступа: https://elibrary.ru/ download/elibrary_15619473_13059365.pdf -(дата обращения: 21.06.2017).
2. Чупахина, Л.Р. Анализ характеристик систем массового обслуживания при передаче непуассоновского трафика методом аппроксимации функций распределения. Автореферат диссертации канд. техн. наук. -Самара, ПГУТИ. 2013. - 16 с.
3. Dominik Klein. An OpenFlow extension for the OMNeT++ INET framework [Electronic resource] // ResearchGate, 2013. - Access: https://www.researchgate.net/publication/256471159256471159_An_OpenFlow_ extension_for_the_OMNeT_INET_framework - (reference date: 21.06.2017).
4. Jan Kriege Simulating Stochastic Processes with OMNeT++. Simulating Stochastic Processes with OMNeT++ [Electronic resource] / Semantic Scholar, 21.03.2011. - Access: https://pdfs.semanticscholar.org/4cd8/ bea6c26d9c4465b4f642ae13269177a38e85.pdf - (reference date: 21.06.2017).
5. Jan Scheurich. OvS-DPDK performance optimizations to meet Telco needs [Electronic resource] / Open vSwitch 2016 Fall Conference, 2016. - Access: http://openvswitch.org/support/ovscon2016/8/1400-gray.pdf -(reference date: 21.06.2017).
6. Justin Pettit. OVS Deep Dive [Electronic resource] / Open vSwich, 07.11.2013. - Access: http://openvswitch. org/slides/OpenStack-131107.pdf - (reference date: 21.06.2017).
7. Obraczka, Katia. SDN, NFVand their role in 5G.IEEE SIGCOMM 2016 [Electronic resource] / KatiaObraczka, Christian Rothenberg, Ahmad Rostami. - Access: http://www.dca.fee.unicamp.br/~chesteve/ppt/SIGCOMM16 - Tutorial- 5G-SDN-NFV-part1.pdf - (reference date: 22.06.2017).
8. OpenFlow Extension for the OMNeT++ INET Framework [Electronic resource] - Access: https://github. com/lsinfo3/ofomnet - (reference date: 21.06.2017).
9. Paul Emmerich. Performance Characteristics of Virtual Switching [Electronic resource] / Paul Emmerich, Daniel Raumer, Florian Wohlfart // IEEE 3rd International Conference on Cloud Networking (CloudNet). -2014. - Access: https://www.net.in.tum.de/publications/papers/Open-vSwitch-CloudNet-14.pdf - (reference date: 22.06.2017).
10. Steve Gordon. OpenStack Enhancements to Support NFV Use Cases [Electronic resource] / Intel Open Source, 2015. - Access: https://01.org/sites/default/files/enhancing_openstack_as_a_framework_for_nfv_v010_0. pdf - (reference date: 21.06.2017).
Исследование проведено при поддержке Правительства Оренбургской области и РФФИ (грант №1629-09639 и №17-47-560046), Президента Российской Федерации, стипендии для молодых ученых и аспирантов (СП-2179.2015.5).
