Інформаційна система ефективної передачі трафіка для комп’ютерних мереж

КОРІНЕНКО, Володимир

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9405

Title:	Інформаційна система ефективної передачі трафіка для комп’ютерних мереж
Authors:	МИРОНЕЦЬ, Ірина КОРІНЕНКО, Володимир
Issue Date:	2022
Abstract:	Мета і завдання роботи. Мета кваліфікаційної роботи – дослідження алгоритмів побудови маршрутів, розробка та оптимізація їх швидкості виконання для програмно-конфігурованих мереж. У ході роботи поставлено наступні завдання:  аналіз проблем побудови маршрутів у програмно-конфігурованих мережах;  дослідження інструментальних засобів для реалізації, емуляції та тестування алгоритмів на базі програмно-конфігурованих мереж;  проектування алгоритму та тестування на емульованому сегменті програмно-конфігурованої мережі. Методи дослідження. Для вирішення поставлених у роботі завдань використовувалися теорія алгоритмів, теорія оптимізації, імітаційне та емуляційне моделювання. Емуляційне моделювання проводилося на базі модельної програмно-конфігурованої мережі. Імітаційне моделювання виконувалось за допомогою інструментальних засобів з відповідними пакетами обробки даних. Практична значимість. Розроблений алгоритм прогнозування навантаження на контролер програмно-конфігурованої мережі, дозволяє реалізовувати моніторинг навантаження та його прогноз на рівні додатків програмно-конфігурованої мережі. Це у свою чергу дозволяє уникнути залежності моніторингових рішень від виробника контролера програмно-конфігурованої мережі та операційної системи, на якій розгорнуто програмне забезпечення контролера.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9405
Appears in Collections:	123 Комп’ютерна інженерія (Комп'ютерні системи та мережі)

Files in This Item:

File	Description	Size	Format
Робота_Коріненко_Друк-merged.pdf Restricted Access		1.87 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему: «Інформаційна система ефективної
передачі трафіка для комп’ютерних мереж»
ЧДТУ.222106.004 ПЗ
Виконав: студент 2 курсу, групи КМС-2055
спеціальності 123 – «Комп’ютерна інженерія»
освітньої програми – «Комп’ютерні системи та
мережі»
Володимир КОРІНЕНКО
Керівник
к.т.н., доцент Ірина МИРОНЕЦЬ
Рецензент
комерційний директор ТОВ «Техпродсервіс»
Владислав ЧЕРЕДНІЧЕНКО
«ЗАХИСТ ДОЗВОЛЯЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор ______ Володимир РУДНИЦЬКИЙ
Черкаси 2022 року
ЗМІСТ
ВСТУП..........................................................................................................................3
1 АНАЛІТИЧНИЙ ОГЛЯД ПРОЕКТУВАННЯ ПРОГРАМНО-
КОНФІГУРОВАНИХ МЕРЕЖ...................................................................................6
1.1 ГОЛОВНІ ОСОБЛИВОСТІ ПРОГРАМНО-КОНФІГУРОВАНИХ МЕРЕЖ...................6
1.2 ОСНОВНІ ВЛАСТИВОСТІ ПОБУДОВИШЛЯХІВ В МЕРЕЖІ................................16
1.3 ІНСТРУМЕНТАЛЬНІ ЗАСОБІВ РЕАЛІЗАЦІЇ СЕГМЕНТА ПРОГРАМНО-
КОНФІГУРОВАНИХ МЕРЕЖ..................................................................................18
2 ІНФОРМАЦІЙНА МОДЕЛЬ ЕФЕКТИВНОЇ ПЕРЕДАЧІ ДАНИХ ДЛЯ
ПРОГРАМНО-КОНФІГУРОВАНИХ МЕРЕЖ...................................................... 26
2.1 ПРОБЛЕМА МОНІТОРИНГУ КОНТРОЛЕРІВ В МЕРЕЖАХ ..................................26
2.2 СПОСІБ ОПТИМІЗАЦІЇ НАВАНТАЖЕННЯ НА КОНТРОЛЕРИ ПРОГРАМНО-
КОНФІГУРОВАНИХ МЕРЕЖ..................................................................................28
2.3 ЗАСТОСУВАННЯ НЕЙРОННОЇ МЕРЕЖІ ДЛЯ ОПТИМІЗАЦІЇ НАВАНТАЖЕННЯ
НА КОНТРОЛЕР SDN...........................................................................................37
3 АЛГОРИТМ ОПТИМІЗАЦІЇ НАВАНТАЖЕННЯ НА КОНТРОЛЕРИ
ПРОГРАМНО-КОНФІГУРОВАНИХ МЕРЕЖ...................................................... 40
3.1 СТРУКТУРА ЕФЕКТИВНОГО АЛГОРИТМУ ОПТИМІЗАЦІЇ ТРАФІКУ..................40
3.2 АПРОБАЦІЯ АЛГОРИТМУ ОПТИМІЗАЦІЇ ТАРФІКУ ..........................................46
3.3 ТЕСТУВАННЯ АЛГОРИТМУ ОПТИМІЗАЦІЇ НАВАНТАЖЕННЯ В МЕРЕЖІ .......... 48
ВИСНОВКИ...............................................................................................................57
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ..................................................................59
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат
Розробив Коріненко а
В.Ю.. Інформаційна система Літ. Лист. Листів
Керівник Миронець І.В. ефективної передачі 2 62
Рецензент Чередніченко
В. трафіка для Кафедра ІБ та КІ
Н.Контроль Гресько С.О. комп’ютерних мереж гр. КМС-2055
Затвердив Рудницький В.М. Пояснювальна записка
ВСТУП
Актуальність дослідження. У 21 столітті постійне зростання підключених
пристроїв до мережі Інтернет спричинив експоненційне зростання
загальносвітового трафіку. Цей різкий стрибок стимулював розвиток нових
швидших та інноваційних комп'ютерних мереж під назвою програмно-
конфігуровані мережі. Нове покоління мереж мало важливу перевагу у вигляді
збільшеної пропускної спроможності кожного передавального пристрою, проте
головним недоліком даних мереж став час створення нового з'єднання, який
збільшився більш ніж двічі. Проблеми викликані складністю побудови маршрутів
на великих сегментах підконтрольних мереж, в яких кількість підключених
передавальних пристроїв понад 300 штук. [14]
Теорія побудови найкоротших шляхів на графах має величезний вплив на
сучасний світ. Завдяки своєму широкому спектру наданих можливостей, вона
останнім часом інтенсивно розвивається, разом із покращенням вже розроблених
методів – винаходяться принципово нові. Пошук шляхів є важливим завданням,
яке використовують у різних областях та сферах. Правильно розрахований
маршрут, може заощадити засоби на одиничну або групову доставку, великий
обсяг даних буде швидше доставлений користувачеві, штучний інтелект у
комп'ютерних іграх покаже більш цікаву поведінку та маршрут для вашого
автомобіля буде побудований ефективно з погляду витраченого часу на шлях.
Проблемою пошуком шляхів почали займатися ще у 19 столітті. Сьогодні
дана задача є класичною для комбінаторики та пошуку маршрутів. Починаючи з
1969 року, комп'ютерні мережі почали розвиватися. Спочатку в першій мережі під
назвою ARPANET було з'єднано суперкомп'ютери того часу. Завдяки цій мережі
випробувана маршрутизація пакетів за допомогою протоколу IP, який
використовується і в наші дні. Починаючи з 1990 року складність комп'ютерних
мереж зростає в геометричній прогресії стаючи все більш об'ємними та
заплутаними. В сучасних комп'ютерних мережах пошук шляху здійснюється на
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 3
а
два кроки вперед, тому що повний пошук шляху може зайняти велику кількість
часу, однак такий «швидкий» пошук не дозволяє завжди збудувати самий
оптимальний та швидкий маршрут [17]. Через збільшену складність сучасних
мереж їм на зміну розробляють програмно-конфігуровані мережі. Мета яких
полягає в тому, щоб винести логіку побудови маршрутів з передавальних
пристроїв та залишити пристроям лише саму передачу даних. Для того, щоб це
реалізувати необхідно використовувати швидкий та ефективний алгоритм
побудови маршруту, який враховуватиме навантаження на кожний окремий
пристрій, щоб досягти максимальної продуктивності мережі.
Актуальність розробки ефективного алгоритму оптимізації трафіку для
програмно-конфігурованих мереж обумовлена небажанням частини експертів ІТ
ринку переходити на нове покоління мереж у зв'язку з великими затримками під
час створення з'єднань. Тому на даний день дуже важливо розробити швидкий та
ефективний алгоритм для побудови маршруту за допомогою якого затримки при
створенні нового з'єднання суттєво знизяться.
Мета і завдання роботи. Мета кваліфікаційної роботи – дослідження
алгоритмів побудови маршрутів, розробка та оптимізація їх швидкості виконання
для програмно-конфігурованих мереж.
У ході роботи поставлено наступні завдання:
 аналіз проблем побудови маршрутів у програмно-конфігурованих
мережах;
 дослідження інструментальних засобів для реалізації, емуляції та
тестування алгоритмів на базі програмно-конфігурованих мереж;
 проектування алгоритму та тестування на емульованому сегменті
програмно-конфігурованої мережі.
Методи дослідження. Для вирішення поставлених у роботі завдань
використовувалися теорія алгоритмів, теорія оптимізації, імітаційне та емуляційне
моделювання. Емуляційне моделювання проводилося на базі модельної
програмно-конфігурованої мережі. Імітаційне моделювання виконувалось за
допомогою інструментальних засобів з відповідними пакетами обробки даних.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 4
а
Практична значимість. Розроблений алгоритм прогнозування
навантаження на контролер програмно-конфігурованої мережі, дозволяє
реалізовувати моніторинг навантаження та його прогноз на рівні додатків
програмно-конфігурованої мережі. Це у свою чергу дозволяє уникнути залежності
моніторингових рішень від виробника контролера програмно-конфігурованої
мережі та операційної системи, на якій розгорнуто програмне забезпечення
контролера.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 5
а
1 АНАЛІТИЧНИЙ ОГЛЯД ПРОЕКТУВАННЯ ПРОГРАМНО-
КОНФІГУРОВАНИХМЕРЕЖ
1.1 Головні особливості програмно-конфігурованих мереж
Проблема затримки перед створенням з'єднання для програмно-
конфігурованих мереж є найголовнішим фактором, який зупиняє їхнє поширення
по всьому світу. Пов'язано це з тим, що сервер, який називається програмно-
конфігурований контролер, проводить прокладку маршруту у складних сегментах
мережі, в яких кількість вузлових пристроїв в даний момент може сягати
1000 штук. Ціна даних прокладок набагато вища ніж у класичних мережах, в них
середній час прокладання маршруту в складному сегменті мережі займатиме
порядку 14-20 мікросекунд, а в програмно-конфігурованих 200 і більше
мікросекунд. Для вирішення цієї проблеми потрібна розробка нового алгоритму.
[15]
Програмно-конфігуровані мережі (ПКС) – це нове покоління комп'ютерних
мереж, у яких ключовою відмінністю є винесення логіки маршрутизації за межі
пристрою на окремий виділений сервер. Поява цього покоління пов'язана з
експоненційним зростанням трафіку та падінням ефективності поточних
комп'ютерних мереж [20].
У ПКС рівні управління мережею та передачі даних поділяються за
допомогою винесення функцій управління (комутаторами, маршрутизаторами
тощо) у додатки, що працюють на виділеному сервері, який називається
контролер. Перші концепції таких мереж сформульовані фахівцями університетів
Стенфорда та Берклі ще в 2006 році, а проведені ними дослідження отримали
схвалення не лише у наукових колах, а й у сфері бізнесу. Ці ідеї тепло зустріли
такі виробники мережного обладнання як, як Cisco, HP та інші [10]. В березні
2011 року засновано консорціум Open Networking Foundation (ONF).
Засновниками цієї спільноти є ряд великих та впливових компаній у сфері IT.
Цими компаніями були: Verizon, Yahoo, Microsoft, Google, Deutsche Telekom та
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 6
а
Facebook. Склад ONF швидко поповнився і іншими не менш відомими
компаніями, такими як Marvell, Citrix, IBM, NEC, Brocade, Oracle, HP, Dell,
Ericsson та інші. Найперша практична реалізація ПКС запропонована компанією
Nicira, яка недавно стало частиною VMware.
Інтерес ІТ-компаній до ПКС викликаний тим, що така технологія дозволяє
підвищити ефективність мережного обладнання на 25-30%, знизити на 30%
витрати на експлуатацію мереж, що дозволяє перетворити управління мережами з
проектування в інженерію, підвищити захищеність мережі та дозволити
користувачам самостійно, за допомогою програм, створювати нові сервіси,
оперативно завантажувати та використовувати їх на мережевому обладнанні.
У більшості напрацювань та досліджень ключові моменти у ПКС пов'язані з
програмою Global Environment for Network Innovations (GENI) – дослідження
майбутнього Інтернету, що включає в себе близько 40 провідних університетів
США. Діяльність об'єднаного центру Стенфорда і Берклі, що створює різні
дослідження, експерименти та напрацювання в галузі Internet2; а також з Сьомою
рамковою програмою досліджень Європейського Союзу Ofelia та проектом
FEDERICA. [18]
Основні концепції ПКС:
 винесення процесу управління даних із передавального пристрої на
виділений сервер, а процеси передачі даних залишити на передавальних
пристроях;
 уніфікований та незалежний інтерфейс між рівнем управління та рівнем
передачі даних;
 логічно централізоване управління мережею, яке здійснюється за
допомогою контролера з встановленою мережевою операційною
системою та реалізованими поверх мережевими додатками;
 віртуалізація фізичних ресурсів мережі;
Головна проблема поточних комп'ютерних мереж у тому, що приблизно 20-
25% продуктивності передавальний пристрій витрачає на прокладку маршруту за
сегментом мережі. Концепція програмно-конфігурованих мереж полягає в тому,
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 7
а
щоб прибрати логіку побудови маршрутів із пристрою передачі даних та
залишити йому тільки передачу даних. Новий тип мереж пропонує розміщувати
логіку передачі на спеціальних серверах, званих програмно-конфігурованими
контролерами, на яких відбувається обчислення маршруту у межах сегмента
мережі. Дані мережі насамперед націлені на центри обробки даних, адже саме
вони відповідають за великий медіаконтент, що надається на різних ресурсах. [12]
За рахунок централізованості керування сегментом мережі, дана мережа
пропонує ряд серйозних переваг:
 зниження вартості обладнання за рахунок спрощення обладнання;
 більш детальне керування мережею;
 дуже низька ймовірність несанкціонованого доступу до ресурсів мережі;
 можливість розробки чи доопрацювання існуючих інструментів
програмно-конфігурованих мереж для керування ресурсами мереж та
потоками даних.
У рамках розвитку концепції даної технології розроблено спеціальний
протокол передачі OpenFlow. Цей протокол базується на концепції управління
обробки потоків даних. Принцип роботи протоколу простий, якщо комутатор
отримує дані для певного потоку, він дивиться на спеціальні таблиці потоків,
іменовані як flow tables, в яких зазначені дії, що необхідно зробити у випадку
отримання даного потоку. Якщо він є новим, тоді комутатор запитує інформацію
у контролера, потім контролер створює новий маршрут і заносить його у таблиці
потоків пристроїв.
Головне проблемою даного підходу є величезна кількість інформації про
просування пакетів, що називається forwarding state explosion. Через це
навантаження на контролер дуже велике, багато сегментів мережі, що включають
більше 1000 передавальних пристроїв – непосильна ноша з точки зору затримок
та стабільності інфраструктури. [9]
Архітектура програмно-конфігурованих мереж
В архітектурі ПКС (software-defined network) існує три рівні управління
мережею (рис. 1.1.):
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 8
а
1. інфраструктурний рівень, що надає набір мережевих пристроїв, таких як
комутатор та канали передачі даних;
2. рівень управління, що включає мережеву операційну систему, яка
забезпечує додатки мережевими сервісами та програмним інтерфейсом
для управління мережевими пристроями та мережею;
3. рівень мережевих додатків для гнучкого та ефективного управління
мережею.
Рисунок 1.1 – Архітектура програмно-конфігурованих мереж
Перший пункт дозволяє швидко змінювати та модифікувати інфраструктуру
мережі без перебудови всього сегмента мережі.
Другий пункт вирішує проблему недостатньо ефективного використання
ресурсів передавальних пристроїв передачі даних.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 9
а
Третій пункт дає широкі можливості для керування доступом до мережі,
управління передачею даних, модифікації генерації маршрутів та інших
можливостей. [5]
Найбільш перспективним і сучасним популярним стандартом для ПКС є
протоколом OpenFlow. Це відкритий протокол взаємодії, розроблений спеціально
для ПКС, в якому описуються вимоги, які пред'являються до комутатора, що
підтримує протокол OpenFlow для дистанційного керування. [3]
За допомогою сучасних маршрутизаторів скрізь виконуються дві головні
задачі: передача даних – передача пакета з вхідного порту на деякий вихідний
порт та управління даними – обробка пакета та ухвалення рішення про те, куди
його передавати далі, на основі поточної завантаженості маршрутизатора та
інших факторів. [7] Це відображає рівень передачі даних, на якому об'єднані
засоби передачі, різні лінії зв'язку, каналоутворювальне обладнання,
маршрутизатори, комутатори та рівні управління станами засобів передачі даних
(рис. 1.2.).
Рисунок 1.2 – Традиційні та програмно-конфігуровані мережі
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 10
а
Розвиток маршрутизаторів, на сьогоднішній день, рухався в напрямку
об'єднання цих рівнів, однак зі ставкою на передачу, включаючи різні апаратні
прискорення, удосконалювалося ПЗ і впроваджувалися нові функціональні
можливостей для збільшення швидкості обробки кожного пакета, в той же час
рівень керування залишався досить примітивним і спирався на непрості
розподілені алгоритми маршрутизації та складні інструкції з налаштування та
конфігурування мережі.
В силу складності програмного забезпечення маршрутизаторів, у яких
розроблено рівень управління, компанії розробники пристроїв закривали вихідний
код. [22]
Відповідно до специфікації стандарту OpenFlow, спілкування програмно-
конфігурованого контролера з комутатором здійснюється засобами протоколу
OpenFlow – у якому будь-який комутатор повинен містити як мінімум одну
таблицю потоків та групову таблицю, а також підтримувати канал OpenFlow для
зв'язку з віддаленим контролером, що є центральним сервером.
Специфікація не описує внутрішній пристрій та архітектуру контролера, а
також API для його внутрішніх програм. Будь-яка таблиця потоків усередині
комутатора повинна містити набір записів з інформацією про потоки чи правила
маршрутизації. Будь-яка із записів складається з полів-ознак, лічильників та
набору інструкцій. [23]
Механізм роботи комутатора OpenFlow дуже простий. У кожного нового
вхідного пакета забирається заголовок, який є бітовим рядком певної довжини.
Далі проводиться пошук правила в таблицях потоків для даної бітової маски. У
разі знаходження збігу, над пакетом та його заголовком виконуються різні
перетворення, визначені деяким набором інструкцій у знайденому правилі.
Інструкції, асоційовані з кожним записом таблиці, описують дії, пов'язані з
відправкою пакета, модифікацією його заголовка, обробкою в таблиці груп,
обробкою в конвеєрі та відправкою пакета на певний порт комутатора. Інструкції
конвеєра обробки дозволяють відправляти пакети в наступні таблиці для
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 11
а
подальшої обробки та у вигляді метаданих передавати інформацію між
таблицями. Інструкції також визначають правила модифікації лічильників, які
можуть бути використані для збору різноманітної статистики. [27]
Якщо потрібне правило не знайдено, то пакет інкапсулюється і
відправляється контролеру, той у свою чергу формує необхідне для обробки
правило. Сформоване правило для певного типу пакетів завантажується в
комутатор або групу підконтрольних комутаторів. Також невідомий пакет може
бути скинутий при установці відповідного налаштування на комутаторі. [13]
Запис про потік може повідомляти про відправку пакета до певного
фізичного, зарезервованого чи віртуального порту. [10] Зарезервовані віртуальні
порти можуть визначати спільні дії пересилання такі як: відправка контролеру,
широкомовне розсилання або пересилання без використання протоколу
OpenFlow. Віртуальні порти, визначені комутатором, можуть точно визначати
групи об'єднання каналів, тунелі або інтерфейси зі зворотним зв'язком. [19]
Записи про потоки можуть також зберігати інформацію про групи, в яких
існує додаткова обробка. Групи є набором дій для широкомовного розсилання.
Також набори дій можуть являти собою пересилки зі складною семантикою,
наприклад, агрегування каналів чи зміна маршруту.
Механізм груп дозволяє ефективно змінювати однакові вихідні дії потоків.
Таблиця груп зберігає в собі записи про групи, що в свою чергу зберігають список
контейнерів дій з особливою семантикою, що залежить від типу групи. Дії в
одному або декількох контейнерах дій застосовуються до пакетів, що
надсилаються до групи. [8]
Розробники комутаторів можуть вільно реалізовувати будь-яку внутрішню
начинку, проте процедура перегляду пакетів та семантика інструкцій мають бути
загальними для всіх. Наприклад, тоді як потік може використовувати всі групи
для пересилання в кілька портів, розробник комутатора може вибрати для
реалізації цього функціоналу єдину бітову маску всередині великої апаратної
таблиці маршрутизації.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 12
а
Ще одним прикладом є процедура перегляду таблиць: конвеєр фізично
може бути реалізований з використанням деякої кількості апаратних таблиць.
Встановлення, оновлення та видалення правил у таблицях потоків комутатора
здійснюються тільки контролером. Правила можуть встановлюватися реактивно
(у відповідь на пакети, що прийшли) або проактивно (наперед, до приходу
пакетів). Управління даними в OpenFlow здійснюється на рівні їх потоків, а не
лише на рівні окремих пакетів. Правило у комутаторі OpenFlow прописується за
участю контролера лише для першого пакета, а всі інші пакети потоку – його
використовують у подальшому. Наявні на сьогоднішній день фізичні комутатори
ПКС відповідають поки що специфікації OpenFlow 1.0 і містять лише одну
таблицю потоків. [18]
Протокол OpenFlow
Ідея розробки ПКС полягає у розробці узагальненого та незалежного
мережевого обладнання, яке має єдиний інтерфейс взаємодії між передавальним
середовищем мережі та контролером. Ця концепція є основною в протоколі
OpenFlow. Він дозволяє користувачам самостійно контролювати та визначати, за
яких умовах, які вузли та з якою якістю можуть взаємодіяти в мережі між собою.
Протокол підтримує три типи повідомлень: контролер-комутатор, асинхронні та
симетричні. [16]
Повідомлення типу контролер-комутатор ініціюються контролером і
використовуються для керування та відстеження стану комутатора. Повідомлення
цього типу можуть використовуватися контролером для завантаження
конфігурації комутатора, для вивантаження статистики, для додавання, видалення
та модифікації записів у таблицях потоків.
Асинхронні повідомлення ініціюються комутатором сповіщення контролера
про різні мережеві події, наприклад, отримання пакетів, видалення запису з
таблиці потоків у зв'язку спливу тайм-ауту. Також вони можуть повідомляти про
різні зміни стану комутатора та помилки в результаті роботи комутатора. [12]
Симетричні повідомлення можуть ініціюватися комутатором або
контролером без запиту та використовуються при встановленні з'єднання. Також
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 13
а
використовуються для вимірювання пропускної здатності з'єднання контролер-
комутатор, затримок або для перевірки стану з'єднання.
Мережеві операційні системи в ПКС
Логічно-централізоване управління даними у мережі передбачає винесення
функцій управління мережею з передавальних пристроїв на окремий сервер, який
називається програмно-конфігурованим контролером (ПКК), що перебуває під
контролем адміністратора сегменту мережі. ПКК може керувати одним або
декількома OpenFlow комутаторами. Також містить у собі спеціальну мережеву
операційну систему, що надає мережеві сервіси та уніфіковані інтерфейси з
низькорівневого управління мережею, сегментами мережі та моніторингу за
станом мережевих елементів, а також програми, що здійснюють високорівневе
управління мережею та потоками даних. [25]
Мережна ОС (СОС) є спеціальною обгорткою над низькорівневим
протоколом. За допомогою вбудованого API надає додаткам інструменти для
доступу до управління лінією мережі, а також виконує моніторинг зміни засобів
мережі. На відміну від традиційного тлумачення терміну ОС, під СОС
розуміється програмна система, що забезпечує моніторинг, доступ та управління
ресурсами усієї мережі, а не її конкретного вузла. [11]
Подібно до класичної ОС, СОС забезпечує програмний інтерфейс для
додатків управління мережею та реалізує механізми управління таблицями
комутаторів: додавання, видалення, модифікацію правил та збір різноманітної
статистики. [14] Таким чином, фактично розв'язання задач управління мережею
виконується за допомогою програмного забезпечення, розробленого на базі API
мережної операційної системи.
Цей інструментарій дозволяє створювати додатки на рівні високорівневих
абстракцій, наприклад, ім'я хоста та ім'я користувача, а не низькорівневих
параметрів конфігурації, наприклад, MAC-і IP-адрес. Це дозволяє виконувати
управляючі команди незважаючи на базову топологію мережі, однак необхідно,
щоб СОС підтримувала відображення між високорівневими абстракціями та
низькорівневими конфігураціями.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 14
а
У кожному контролері зберігається як мінімум одна програма для
керування підключеними комутаторами. Також програмне забезпечення формує
модель підконтрольної топології фізичної мережі, завдяки цьому централізується
управління. [13] Представлення топології мережі містить у собі топологію
комутаторів, розташування хостів і користувачів та різноманітних сервісів
мережі. Представлення також містить у собі зв'язок між іменами та адресами,
тому однією з найважливіших завдань, що вирішуються СОС, є постійний
моніторинг мережі.
Це дозволяє СОС створювати програми у вигляді централізованого ПЗ, з
використанням високорівневих імен, на основі різних алгоритмів, наприклад,
алгоритму Дейкстри пошуку найкоротшого шляху у графі, замість складних
розподілених алгоритмів на кшталт алгоритму Беллмана–Форда, в термінах
низькорівневих адрес, які використовуються в сучасних маршрутизаторах. [18]
Рисунок 1.3 – Альтернативний підхід до побудови розподіленого масштабованого
контролера
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 15
а
На даний момент є велика кількість реалізацій мережевих ОС для
програмно-визначених мереж. Одними з найвідоміших на сьогоднішній день є:
RUNOS, BigSwitch, Beacon, POX, Maestro, FloodLight, NOX та Trema.
Для контролерів у ПКС важливою вимогою є те, щоб усі програми одного
контролера в будь-який момент часу повинні бути синхронізовані та мати
однакове уявлення про топологію мережі. Проте перехід від розподіленого
управління мережею до централізованого містить у собі ряд недоліків.
Наприклад, зниження надійності, відмовостійкості та масштабованості. [1]
Сьогодні активно розвиваються три підходи для побудови розподіленого
масштабованого контролера. Вони називаються Kandoo, HyperFlow та Onix. В
рамках досліджень виявлено, що найбільш перспективним є альтернативний
підхід, представлений на рис. 1.3. В силу того, що будь-який контролер може бути
з'єднаний з декількома комутаторами, а кожен комутатор може бути з'єднаний з
кількома контролерами, тому є можливість об'єднати контролери у груповий
контролер (ГК).
Група контролерів, об'єднаних у ГК повинні мати синхронізоване подання
підконтрольної топології сегмента мережі. Як бачимо на рис. 1.3, С1-С3 –
контролери, S1-S4 – комутатори, а V1-V3 – фрагменти мережі, до яких забезпечує
доступ комутатор S1, S2, S3 відповідно. Тоді ГК1 утворюють контролери C1 і C2,
ГК2 – С2 і С3, а всі додатки в ГК1 повинні мати узгоджене представлення про
топологію V1 і V2, всі додатки в ГК2 про топологію V2 і V3. У разі виходу з ладу,
наприклад, контролера С1 його може замінити С2, взявши на себе управління V1.
Уявлення про стан відповідної частини мережі, контролери можуть погоджувати
або через комутатор S4, або через S1, S2 та S3. [31]
Такий принцип побудови розподіленого контролера вирішує проблему
масштабованості та підвищує відмовостійкість ПКС.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 16
а
1.2 Основні властивості побудови шляхів в мережі
Найчастіше найкоротший шлях розглядається за допомогою математичного
об'єкта, який називається графом. Існують три найбільш ефективні алгоритми
знаходження найкоротшого шляху:
 алгоритм Дейкстри (використовується для знаходження оптимального
маршруту між двома вершинами);
 алгоритм Флойда (для знаходження оптимального маршруту між усіма
парами вершин);
 алгоритм Йена (для знаходження k-оптимальних маршрутів між двома
вершинами).
Основним завданням даної науково-дослідної практики є програмна
реалізація алгоритму пошуку найкоротшого шляху між двома будь-якими
вершинами графа. [19]
Програма повинна працювати так, щоб користувач вводив кількість вершин
та довжини ребер графа, а після обробки цих даних, на екран виводився
найкоротший шлях між двома заданими вершинами та його довжина. Необхідно
передбачити різні результати пошуку, щоб програма не видавала помилок та
працювала правильно.
Ця програма може використовуватися в дискретній математиці для
дослідження графів або як наочний посібник, що демонструє застосування
алгоритму Флойда практично.
Граф – це система, яка інтуїтивно може бути розглянута як множина вузлів і
множина ліній, що з'єднують їх, геометричний спосіб задання графа
представлений на рис. 1.4. Вузли називаються вершинами графа, лінії зі стрілками
– дугами, без стрілок – ребрами. Граф, в якому напрямок ліній не виділяється,
тобто всі лінії є ребрами, називається неорієнтованим; граф, у якому напрямок
ліній важливий, тобто лінії є дугами, називаються орієнтованими.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 17
а
Рисунок 1.4 – Наочне представлення графа
Теорія графів може також розглядатися як розділ дискретної математики, а
якщо точніше, то теорія множин і формальне визначення графа є наступним: якщо
задана кінцева множина X, що складається з n елементів (X = {1, 2,..., n}), які
називаються вершинами графа, та підмножина V декартового добутку, яка
називається множиною дуг, тоді орієнтованим графом G називається сукупність
(X,V), неорієнтованим графом називається сукупність множини X і множини
невпорядкованих пар елементів, кожен з яких належить множині X. Дугу між
вершинами i і j позначатимемо (i,j). Число дуг графа позначатимемо
m (V = (v1, v2,..., vm)).
Мова графів є зручною для опису багатьох фізичних, технічних,
економічних, біологічних, соціальних та інших систем. В рамках теорії графів
зазвичай вирішуються транспортні та технологічні завдання.
«Транспортні» задачі – величезний спектр логістичних завдань, у яких
вершинами графа є пункти, а ребрами – дороги або інші транспортні маршрути.
Іншим прикладом є мережі постачання. У них вершинами є пункти виробництва
та споживання, а ребрами – можливі маршрути переміщення. Відповідний клас
задач оптимізації потоків вантажів, розміщення пунктів виробництва та
споживання, іноді називається задачами забезпечення або задачами про
розміщення. Їх підкласом є задачі вантажоперевезення.
«Технологічна» задача – граф, в якому вершини відображають виробничі
елементи заводів, верстатів і т.д., а дугами є потоки сировини, матеріалів та
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 18
а
продукції між ними. Мета цих завдань полягає у визначенні оптимального
завантаження всіх виробничих елементів.
1.3 Інструментальні засобів реалізації сегмента програмно-
конфігурованих мереж
З моменту розвитку програмно-конфігурованих мереж, з'явилося багато
контролерів, які іноді називають мережеві операційні системами, однак, не всі ці
контролери досить хороші. Одними з тих, що себе зарекомендували, є
контролери: RUNOS, HP Virtual Application Networks ПКС Controller та POX.
Нижче буде проведено докладний огляд контролерів з метою виявити слабкі та
сильні сторони кожного з них. [26]
RUNOS
Починаючи з 2013 року, центр прикладних досліджень комп'ютерних мереж
почав розробку контролера RUNOS. За заявами центу це найшвидший на сьогодні
контролер у порівнянні з існуючими аналогами. Цей контролер дуже ефективно
використовує обчислювальні ресурси управління мережею. Пропонує величезний
набір мережевих програм, можливість фільтрації трафіку, роботу з мережевими
протоколами та інше.
На сьогоднішній момент є однією з найшвидших і ефективних мережевих
ОС, за невеликою середньою швидкістю генерації нового з'єднання – 45 мкс та
підтримкою 1 тисячі комутаторів одноразово.
В RUNOS реалізовано балансування навантаження, узгоджене бачення всієї
мережі, робота з розподіленими мережними додатками, безпека та протидія
зовнішнім навантаженням.
Головні характеристики:
 опрацювання 30 мільйонів потоків за секунду;
 час на встановлення нового з'єднання – 45 мкс;
 підтримка 1000 комутаторів;
 можливість керування з графічного інтерфейсу.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 19
а
Розробники запевняють, що це найшвидший ПКС-контролер у світі. Його
продуктивність досягається за рахунок використання можливостей багатоядерних
та багатопроцесорних систем. В ньому задіяний набір мережевих додатків – як зі
світу традиційних мереж, так і нових: L2/L3-маршрутизація з урахуванням якості
обслуговування, багатопотокова маршрутизація, фільтрація трафіку, робота з
мережевими протоколами (ARP, DNS, DHCP, BGP), трансляція адрес (NAT),
балансування навантаження, віртуалізація мереж, анти-DDoS, верифікація мережі,
інтеграція із системою управління даних.
RUNOS насамперед орієнтований на корпоративний сегмент. Його
споживча аудиторія – мережеві адміністратори та інженери, сервіс-провайдери, а
також студенти за напрямом «комп’ютерні мережі», дослідників та розробники
перспективних мережевих технологій. [11]
HP Virtual Application Networks SDN Controller
Цей контролер для програмно-конфігурованих мереж розробляється
компанією HP. Він платний, проте має можливість роботи з декількома
протоколами програмно-конфігурованих мереж.
Компанія дотримується своєї політики відсутності прив'язки програмного
забезпечення до апаратних засобів та з цієї причини їх контролер забезпечує
можливість взаємодії з будь-яким мережевим обладнанням, яке підтримує
протоколи програмно-конфігурованих мереж.
Головні характеристики:
 максимальна кількість підтримуваних пристроїв – 4000;
 максимальна кількість підключених комп'ютерів – 30000;
 максимальна кількість потоків за секунду – 2,3 мільйона;
 час на встановлення з'єднання – 50-60 мкс.
Як видно, даний контролер є потужним інструментом, однак, час на
встановлення з'єднання та максимальна кількість потоків залишає бажати
кращого. [19]
NOX
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 20
а
NOX був розроблений інженерами Nicira Networks паралельно з протоколом
OpenFlow. Спочатку був розроблений з підтримкою двох мов: C++ та Python. У
2008 р. NOX опубліковано під ліцензією GPL та з тих пір цей контролер є базовим
для багатьох науково-дослідних груп, які лише приступають до вивчення ПКС.
NOX орієнтований на дистрибутиви Linux (зокрема Ubuntu, але також можливе
використання на Debian та RHEL). Містить послуги для побудови топології
мережі та L2-L3 комутації.
У процесі тестування з'ясувалося, що підтримка двох мов сильно
позначається на продуктивності, тому частина, що відповідає за Python,
відокремили до окремого проекту, який пізніше назвали POX. [16]
POX
Контролер POX є «молодшим братом» NOX. Якщо при розробці NOX
основною метою була висока продуктивність, то POX насамперед спрямований на
навчання та дослідження. За своєю суттю POX – це платформа для швидкої
розробки та прототипування ПЗ управління мережею. Цей контролер написано на
Python, його легко запустити на Window, Linux та MacOS. Наприклад,
дослідницька група у Стенфорді використовує POX для дослідження ключових
проблем ПКС. Він є досить продуктивним контролером, поширюється
безкоштовно та підтримує останню версію протоколу OpenFlow. POX
знаходиться в стадії активного розвитку: всі вдалі ідеї постійно переміщуються з
лабораторних експериментів в офіційні релізи контролера POX (принаймні так
стверджують його розробники зі Стенфорда).
Головні характеристики:
 максимальна кількість пристроїв – 3000;
 максимальна кількість потоків за секунду – 1 мільйон;
 час на встановлення з'єднання – 90 мкс;
POX підтримує ті ж компоненти, графічний інтерфейс, засоби візуалізації,
як і NOX. [28]
Beacon
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 21
а
Це досить швидкий, кросплатформовий модульний OpenFlow контролер на
Java. Цей контролер розроблявся понад два роки. Beacon використовується в
багатьох науково-дослідних проектах та тестових упровадженнях/розгортаннях.
Beacon застосовується в експериментальному центрі Стенфорда, в якому він
керує 100 віртуальними та 20 фізичними комутаторами. Beacon написаний на Java
і працює на багатьох платформах, починаючи від високопродуктивних
багатоядерних Linux-серверів до смартфонів Android. Розробник контролера –
Девід Еріксон, учень Ніка МакКеона, Стенфорд.
Maestro
Maestro – це операційна система, розроблена у Rice University. Maestro
надає інтерфейси для реалізації модульних програм управління мережею для
доступу та зміни стану мережі, а також координації їхньої взаємодії. Незважаючи
на те, що цей проект спрямований на створення OpenFlow контролера, Maestro не
обмежується тільки OpenFlow-мережами. Середовище програмування Maestro
надає інтерфейси для додавання нових користувацьких компонентів управління
мережею.
Крім того, Maestro намагається використовувати паралелізм у межах однієї
машини, що поліпшує пропускну спроможність системи. Розробники заявляють
основні властивості
Maestro – портативність та масштабованість. Maestro розроблена на Java (і
сама платформа, і її компоненти), є універсальною для різних ОС та архітектур.
[25]
В результаті аналізу мережевих ОС виявлено, що для реалізації алгоритмів
найкраще підходить RUNOS завдяки швидкості роботи, суттєвого обсягу
одночасно підтримуваних потоків та швидкості відгуку.
Огляд засобів для емуляції програмно-конфігурованої мережі
На даний момент існує велика кількість засобів для емуляції програмно-
конфігурованих мереж. Найвідомішими та визнаними спеціалістами є: ns-3
Network Simulator, OPNET, NetSim та Mininet. При виборі засобу для емуляції
варто звернути увагу на функціональні можливості, підтримку необхідних
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 22
а
протоколів, переваги і недоліки. Також, варто врахувати значущість недоліків
емулятора для поставлених завдань.
ns-3 Network Simulator
ns-3 Network Simulator є проектом з відкритим кодом, розповсюджується за
ліцензією GNU GPL. Ціль, яку поставили перед собою розробники – створити
безкоштовний симулятор побудови комп'ютерних мереж, за допомогою якого
можна створювати різні дослідження щодо роботи комп'ютерних мереж без
необхідності будувати реальні.
Перша версія ns з'явилася в далекому 1997 році, тоді симулятор був досить
слабким, незважаючи на досить швидке ядро, написане на C++, через сценарії,
засновані на TCL, сильно гальмувалась робота.
Трохи пізніше, DARPA, Xerox та ряд інших зацікавлених компаній та
організацій почали допомагати у розробці такого програмного забезпечення,
через кілька років з'явився ns-2, який став більш продуктивним і кращим з
погляду налаштувань.
Починаючи з 2006 року розпочалася розробка третьої версії програми, дана
версія має істотну перевагу в порівнянні зі старими версіями, змінився
скриптовий двигун, тепер використовувані скрипти пишуться на мові Python, яка
проста в освоєнні. Крім цього забезпечена зворотна сумісність із другою версією.
Реліз третьої версії відбувся у червні 2008 року, після цього проект
доопрацьовувався до дуже стабільної версії, в 2010 році, вийшла досить стабільна
версія, щоб повністю замінити другу версію, таким чином у 2010 році, підтримка
ns-2 припинилася. [13]
Найголовнішими перевагами даного емулятора є можливість створення
топології, конфігурування вузлів та з'єднань, аналіз навантаження та візуалізація
даних.
Найголовнішим недоліком є відсутність підтримки протоколів програмно-
конфігурованих мереж.
OPNET
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 23
а
OPNET це пропрієтарне програмне забезпечення, розроблене компанією
OPNET Technologies. Перша версія програми представлена у 2000 році. Основна
аудиторія даного продукту є комерційні компанії, яким необхідно розробити дата-
центр, центр обробки даних або значну локальну мережу. Їхній інструмент надає
зручний інтерфейс при роботі з емульованим середовищем, за допомогою такої
програми дуже просто та швидко будується мережа будь-якої складності.
OPNET містить бібліотеки, завдяки яким здійснюється формування
телекомунікаційних мереж, та полегшується вивчення моделі шляхом
підключення різних типів вузлів, з використанням різних видів зв'язку. [2]
Редактором вузлів є редактор, який використовується для створення
моделей вузлів та вказівки їх внутрішньої структури. Ці моделі використовуються
для створення вузлів у середині мережі.
Внутрішні вузли моделі мають модульну структуру, яка визначається як
вузол підключення декількох модулів з пакетом потоків та кабелів. Це з'єднання
дозволяє обмінюватися інформацією та пакетами між ними. Кожен модуль має
певну функцію у вузлу, таку як: створення пакетів, склеювання, процес або
передача та прийом.
У цьому редакторі елементи доступні як чорні ящики, які можуть бути
налаштовані. Кожен із них представляє функцію у вузлі. Також має потужний
редактор моделі з'єднань. Редактор дає можливість створювати нові типи об'єктів
зв'язку. Кожен новий тип з'єднання може мати різні атрибути та представлення.
Типи підтримуваних редактором з'єднань: всі з'єднання, які можна
підтримувати на сьогоднішній день. Цими з'єднаннями є: точка-точка, дуплекс
точка-точка, шина та болт. [30]
Процесори представляють об'єкти у цьому редакторі. Їхня поведінка
визначається у процесі редагування. Існують попередньо налаштовані моделі, такі
як джерела даних, поглиначі і т.п. Найголовнішими перевагами даного емулятора
є: простота використання, підтримка всіх протоколів. Найголовнішим недоліком –
ціна даного товару.
NetSim
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 24
а
Програмне забезпечення розроблене компанією TETCOS. Розробку
розпочато у червні 2002 року. Це програмне забезпечення підтримує сучасні
протоколи, забезпечує можливість емуляції бездротових мереж. [6]
Проект створено мовою C, що робить симулятор дуже швидким. Даний
симулятор є чудовим інструментом для розробки архітектури складних мереж. В
силу своєї ефективності та гнучкості, даний інструмент є складним у освоєнні та
використовується лише професіоналами. Цей продукт має велику вартість, що є
його основним недоліком.
Mininet
Симулятор мережі Mininet є безкоштовним програмним забезпеченням
створений співтовариством програмістів, які, є прихильниками безкоштовного
програмного забезпечення.
Mininet спроектований таким чином, щоб можна легко та просто
створювати віртуальні програмно-конфігуровані мережі. Крім цього розроблено
спосіб підключення віддаленого контролера, який дозволяє тестувати будь-які
програмно-конфігуровані контролери. Цей емулятор з'явився в першу чергу через
швидко зростаючий інтерес до програмно-конфігурованих мереж. Має функції
генерації даних, дозволяє тестувати отриману мережу на предмет продуктивності
і відразу виявляти слабкі місця спроектованої топології. [9]
Вся емуляція відбувається лише на рівні ядра. За допомогою зручного API,
дозволяє швидко будувати складні топології, які можуть зберігати не одну тисячу
пристроїв.
У ході аналізів виявлено, що Mininet є лідером серед емуляторів за рахунок
наданих можливостей та безкоштовного поширення.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 25
а
2 ІНФОРМАЦІЙНАМОДЕЛЬ ЕФЕКТИВНОЇ ПЕРЕДАЧІ ДАНИХ ДЛЯ
ПРОГРАМНО-КОНФІГУРОВАНИХМЕРЕЖ
2.1 Проблема моніторингу контролерів в мережах
З метою забезпечення досить високих вимог щодо якості послуг, у тому
числі в такому класі мереж, як мережі зв'язку з дуже малими затримками та
надійністю, необхідно забезпечити стійкість систем управління в мережах. Як уже
раніше наведено, основними мережевими технологіями опорних мереж, згідно з
рекомендаціями Міжнародного Союзу Електрозв'язку, є технології Програмно-
конфігурованих мереж (SDN) та віртуалізації мережевих функцій (NFV). У SDN
керуючим головним функціональним елементом є контролер, реалізує логіку та
протоколи взаємодії. У тому числі такі протоколи, як OF-Config та OpenFlow для
керування SDN-комутаторами. У системах віртуалізацією мережевих функцій
таким елементом є оркестратор NFV. В рамках даної роботи особливо досліджено
питання моніторингу та прогнозування навантаження на контролери програмно-
конфігурованих мереж.
За час розвитку концепції програмно-конфігурованих мереж виконано
багато досліджень (у тому числі комерційними компаніями, що розробляють
рішення SDN, або займаються їх використанням) різного тестування, зокрема
стресові тести. Варто відзначити, що в більшості випадків метою досліджень у
таких роботах є визначення межі роботи контролера SDN за обслуговуванням
потоків OpenFlow, оцінка переваги однієї програмної архітектури контролера
перед іншою, а також знаходження найшвидшого контролера, що має більш
широкий функціонал. Таким чином, знання про навантаження контролера
програмно-конфігурованої мережі дозволяє оцінити працездатність мережі
загалом.
Враховуючи даний факт, прогнозування поведінки контролера програмно-
конфігурованої мережі є одним з першочергових завдань. В даному напрямку
дослідження одним з підходів є розробка спеціального програмного забезпечення
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 26
а
під операційну систему, на якій будуть використовувати контролер SDN.
Наприклад – Linux Debian/Ubuntu тощо. Дане ПЗ звертається до операційної
системи через виклики системних функцій (регламентовані в рамках відповідної
ОС та її версії) та запитує значення параметрів апаратної частини (потоки в
процесорі та їх навантаження, оперативна пам'ять, що використовується, постійна
пам'ять, активність ядер процесора тощо).
Отримані дані можливо первинно обробити та передати далі в аналітичну
систему/платформу по мережному API, яка може бути розташована віддалено,
щодо самої ОС з розгорнутим контролером програмно-конфігурованої мережі.
Однак, у цьому випадку варто відзначити ряд недоліків такої архітектури
розв'язання:
 залежність від апаратної частини контролера SDN;
 залежність від типу та версії ОС, так звана «вендорська голка» від
виробника ПЗ та залежних бібліотек та фреймворків;
 залежність від оновлень системних утиліт, які досить часто
оновлюються розробниками ОС з метою забезпечення безпеки, стійкості
та ін.;
 внесення додаткових процесів для процесора контролера SDN;
 складність у переносності на інші рішення та швидкого розгортання
даного моніторингового ПЗ;
 у разі стороннього ПЗ (типу Zabbix) існує залежність від його функцій
насамперед, а по-друге, це ПЗ спочатку не враховує специфіку роботи
контролера SDN. А також з огляду на вектор розвитку технологій
штучний інтелект в системах управління мережами зв'язку і
моніторингове ПЗ має виконувати вимоги до модулів такого класу
службових додатків мереж зв'язку та, зокрема, SDN.
Варто також зазначити, підвищення ймовірності виведення контролера
програмно-конфігурованих мереж з ладу при некоректній роботі даного
моніторингового ПЗ у разі його розміщення на одному рівні з ОС контролера. В
результаті, враховуючи наведені вище недоліки такого методу організації
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 27
а
моніторингу контролера програмно-конфігурованої мережі, виникає завдання з
розробки нового методу аналізу та оптимізації навантаження на контролери
програмно-конфігурованої мережі. У цій роботі пропонується новий метод
моніторингу та оптимізації навантаження на контролер SDN, заснований на
проведенні аналітики метаданих лише суми службових потоків, що надходять від
комутаторів OpenFlow на контролер програмно-конфігурованої мережі.
Такий метод дозволить вирішити вище зазначені проблеми/недоліки і в
тому числі проблему залежності від апаратної частини та операційної системи, на
яких розгорнуть контролер програмно-конфігурованої мережі.
Враховуючи особливості отримуваних статистичних даних протоколу
OpenFlow, у цій роботі проведено аналіз існуючих математичних методів
прогнозування даних, також проведено багатопараметричний кореляційний
аналіз, результат якого показує наявність залежності активності службових
потоків протоколу OpenFlow та навантаження апаратної частини контролера SDN.
У процесі цієї роботи створено додатковий програмний модуль до сервера
моніторингу та аналізу службових потоків у програмно-конфігурованій мережі.
Варто зазначити, що отримані результати підтверджують реалізованість
запропонованого методу оптимізації навантаження контролера SDN у мережах.
2.2 Спосіб оптимізації навантаження на контролери програмно-
конфігурованих мереж
До поточного моменту розвитку технологій програмно-конфігурованих
мереж існує чимало робіт, спрямованих на дослідження та розробку різних
методів тестування контролера, у тому числі так зване стресове тестування. Як
уже зазначено, у цій роботі розглядається можливість реалізації моніторингу
навантаження контролера SDN за допомогою моніторингу та інтелектуальної
аналітики метаданих лише групи службових потоків OpenFlow. Для перевірки
працездатності запропонованого підходу використовувалася модельна програмно-
конфігурована мережа з працюючим сервісом «Video-on-Demand» на рівні
передачі даних мережі SDN.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 28
а
Аналітична система (далі – службовий додаток мережі), частиною якої є
модуль прогнозування активності службових потоків OpenFlow, розроблена у
вигляді WEB-сервера, що працює на основі моделі проектування MVC (Model-
View-Controller). Дане ПЗ працює поверх програмного інтерфейсу API контролера
SDN модельної мережі.
Як контролер мережі SDN, в даній модельній мережі використовується
OpenDaylight Beryllium SR4. Рівень передачі даних побудований на основі
комутаторів Mikrotik із підтримкою протоколу OpenFlow. Загальна архітектура
сегмента відображена на рис. 2.1. На даному рисунку також крім основних
елементів модельної мережі відображені об'єкти дослідження та їх параметри
(метадані на основі структури OpenFlow – таблиць).
Рисунок 2.1 – Архітектура сегмента з об'єктами дослідження
Для формування досліджуваних наборів даних програма моніторингу
надсилала REST-запити кожну секунду на контролер програмно-конфігурованої
мережі через API. Наступною стадією була додаткова фільтрація отриманих
таблиць потоків таким чином, щоб далі на обробку надсилалися дані лише
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 29
а
службовими потоками OpenFlow. Далі оброблений набір даних проходив
необхідну додаткову обробку для формування наборів даних з метою побудови
аналітичних моделей.
Раніше помічено можливість складання метаданих потоків на основі двох
глобальних частин таблиці потоків SDN-комутатора, а саме: Match Field та
Actions. Однією з важливих особливостей цих даних є те, що на основі
лічильників «Byte Count» та «Packet Count» не можна точно визначити точну
довжину пакета у потоці. Тому що за один момент часу лічильники можуть бути
рівні: «Byte Count» –1500, «Packet Count» – 3. Відповідно, на основі цих даних не
можна точно визначити довжину кожного з пакетів, зареєстрованих у потоці за
проміжок часу: ΔT = 1 [с].
Варто також зазначити, що лічильники відображають сумарне значення
параметрів [«Byte Count», «Packet Count»]. Проте крім даних лічильників, у
таблиці потоків SDN-комутаторів існує ще один параметр «Time Stamp», який
дозволяє оцінити в кожний момент часу миттєве значення [ByteCount_delta] та
[PacketCount_delta].
Нехай, PacketCount_delta – PCdelta, ByteCount_delta – BCdelta, a
TimeStamp_deltas – TS = 1 [sec.] = const, тоді:
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 30
а
Таким чином, за довільний період часу ΔT, маючи величину значень [Byte
Count], [Packet Count], [TimeStamp] можна скласти набір даних із встановленою
структурою даних, де кожен відлік відображає миттєве значення [ByteCount_delta]
та [PacketCount_delta]. Значення [Byte Count], [Packet Count], [TimeStamp] –
формуються щомиті шляхом запитів на контролер мережі SDN через програмний
інтерфейс REST API. Структура формується на основі запитів DataSetRQ з
«сирими» даними та формула його перетворення на необхідний формат DataSetML
з миттєвими значеннями наведено нижче.
При цьому розрахунок сумарних значень параметрів за встановлений
проміжок часу, що проводиться за такими формулами:
Поточні структури описують потоки рівня управління в програмно-
конфігурованих мережах.
Рисунок 2.2 – Принципова схема моделі дослідження
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 31
а
В рамках даних досліджень необхідно спочатку перевірити наявність
залежності між активністю потоків OpenFlow (зміни метаданих) та зміною
навантаження апаратної частини контролера SDN На рис. 2.2 відображено схему
дослідження.
Для перевірки залежності між зміною активності службових потоків
OpenFlow (зміни метаданих) та навантаження апаратної частини SDN контролера
розроблено дві системи «OS App» та «Аналітична програма». «OS App» –
програма-сервер для операційної системи Linux, на якій розгорнуть контролер
SDN OpenDaylight Beryllium SR4. Цей додаток запитує значення параметрів
апаратної частини (ядра процесора, оперативна пам'ять) у операційній системі
Linux Ubuntu через системну утиліту. Значення показників доступні через REST
API цієї програми стороннім додаткам по службовій мережі. «Аналітичний
додаток» – цей додаток розроблено також у вигляді сервера, але вже працюючого
поверх інтерфейсу контролера REST API. Даний додаток запитує значення
параметрів у «OS App» через його API по службовій мережі рівня управління, та
зрештою формує набір даних параметрів для оцінки їхньої залежності.
Провівши аналіз існуючих математичних методів для оцінки залежності між
параметрами, запропоновано використовувати багатопараметричний
кореляційний аналіз Відповідно до теорії багатопараметричного кореляційного
аналізу визначається ряд даних для порівняння та формується багатовимірна
матриця даних (X), яка в подальшому приводиться до типової U-матриці.
Потрібно зауважити, що рядки такої матриці відповідають результатам реєстрації
всіх спостережуваних параметрів об'єктів (потік OpenFlow та апаратна частина
SDN-контролера) в одному експерименті, а стовпці містять результати
спостережень за одним параметром (фактором) у всіх експериментах.
Для визначення рядів позначимо кількість параметрів через m де (m>1), а
кількість спостережень – через n. У матриці елемент xij відповідає значенню j-ого
параметра в i-му спостереженні. При цьому допускається наявність порожніх
значень деяких елементів, наприклад, які можуть виникнути через перепустки в
реєстрації значень параметрів. У контексті даного завдання реєстрація параметрів
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 32
а
відбувається кожну секунду. Однак для багатовимірного аналізу бажано усунути
пропущені значення.
Для цього існує два підходи: видалення відповідних рядків матриці чи
занесення середніх значень замість відсутніх. У цій роботі вхідні ряди даних
піддаються нормуванню перед безпосереднім кореляційним аналізом на основі
механізму занесення середніх значень замість відсутніх.
Подальші методи обробки матриці X засновані на наступному припущенні:
якщо об'єкт дослідження піддати новому обстеженню і отримати іншу матрицю
даних, то після її обробки за допомогою тих самих методів будуть одержані
результати, близькі до результатів першої матриці. Це припущення ґрунтується на
статистичній гіпотезі формування матриці.
Таким чином, об'єктом дослідження у багатовимірному аналізі є
багатовимірна випадкова величина, представлена вибіркою скінченного обсягу.
Варто також зазначити, що параметри, що характеризують об'єкт дослідження,
мають різний фізичний сенс, і матриця даних суттєво змінюється, якщо
змінюються шкали, де вимірюються вибрані параметри.
Відповідно матриця даних приводиться до стандартного вигляду, тобто
стандартизуються значення параметрів (варіант). Як уже зазначалося раніше,
стандартизовану матрицю позначатимемо через U.
Матриця X, згідно з рядом параметрів, побудована на основі матриці
DataSetML, виглядає так:
Перетворення матриці X, сформованої на основі вибраних параметрів
потоку та додаткових даних про навантаження контролера у процентному
значенні кожного, до стандартизованої матриці U відбувається наступним чином:
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 33
а
За кожним досліджуваним параметром j = 1, 2, ... ,4 обчислюються зважені
оцінки за формулою:
.
У формулі використовуються наступні два параметри, а саме математичне
очікування ��1(����) та дисперсія ��2(����), які розраховуються за наступними
формулами:
.
Таким чином, розрахувавши елементи «������» складається матриця-U, яка стає
наступним об'єктом обробки.
Варто зазначити, що вплив загальних факторів, а також наявність
об'єктивних закономірностей у поведінці досліджуваних об'єктів призводять лише
до появі так званої статичної залежності.
Статичною називають залежність, при якій зміна однієї з величин тягне за
собою зміну розподілу інших, і ці величини, як відомо, набувають деяких значень
з певними ймовірностями.
Існує також окремий випадок статичної залежності, яка більш підходить до
моделі, що розглядається в даній роботі, а саме кореляційної залежності, яка у
свою чергу характеризує взаємозв'язок значень одних випадкових величин із
середнім значенням інших. Варто відзначити, що кореляційна залежність описує
зазвичай причинну залежність між значеннями параметрів досліджуваної
аналітичної моделі.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 34
а
Таким чином, кореляційна залежність визначається різними параметрами,
серед яких найбільшого поширення набули показники, які характеризують
взаємозв'язок двох випадкових величин (так звані – парні показники):
 кореляційний момент,
 коефіцієнт кореляції.
Оцінка кореляційного моменту (коефіцієнта коваріації) двох варіантів xj і xk
обчислюється за вихідною матрицею – Х:
.
Коефіцієнт коварації ������ нормованих випадкових величин називають
коефіцієнтом кореляції, та його оцінка розраховується за наступною формулою:
.
При цьому коефіцієнт кореляції залежить не від значень випадкових
величин, а від їх варіацій, тож якщо значення величини збільшується на порядок,
то коефіцієнт не зміниться. При цьому значення коефіцієнта кореляції лежить в
межах від -1 до +1. Якщо випадкові величини Uj та Uk незалежні, то коефіцієнт ������
обов'язково дорівнює нулю, проте зворотне твердження неправильне. Коефіцієнт
кореляції ������ характеризує значимість лінійного зв'язку між випадковими
величинами (параметрами):
 при ������ = 1 значення uij та uik повністю збігаються, тобто значення
параметрів набувають однакових значень. Інакше кажучи, має місце
функціональна залежність, тобто знаючи значення одного параметра,
можна однозначно вказати значення іншого параметра;
 при ������ = -1 величини uij та uik набувають протилежних значень. І у цьому
випадку також має місце функціональна залежність;
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 35
а
 при ������ = 0 величини uij та uik практично не пов'язані один з одним
лінійним співвідношенням. Однак у такому разі, не означає відсутності
якихось інших (наприклад, нелінійних) зв'язків між параметрами;
 при |������|>0 і |������|<1 однозначного лінійного зв'язку величин uij та uik
немає. І чим менша абсолютна величина коефіцієнта кореляції, тим
меншою мірою за значеннями одного параметра можна передбачити
значення іншого.
Раніше згадана так звана функціональна залежність, яка, по суті, відображає
зв'язок аналізованої величини з однією або безліччю інших величин, якщо ця
величина залежить тільки від цієї множини факторів.
Однак у даному випадку варто враховувати те, що функціональні зв'язки є
більше математичними абстракціями, тому що в реальних ситуаціях існує
нескінченно велика кількість властивостей самого об'єкта та зовнішнього
середовища, що впливають один на одного. Тому, говорячи про можливу
функціональну залежність варто враховувати те, що вибраний ряд параметрів, на
основі яких проводиться безпосередній кореляційний аналіз є обмеженим. При
цьому ряд параметрів визначається в кожній конкретній практичній задачі.
Таким чином, у задачі (вивчення залежності між активністю службових
потоків та навантаження контролера SDN), аналітичним додатком провадиться
розрахунок наступних показників.
Приймемо наступні умовні позначення:
 ByteCount – BtCt;
 PacketCount – PcCt;
 CPU value – Cpu;
 RAM value – Ram.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 36
а
В матрицях у першому рядку відображається відношення параметрів між
якими розрахований відповідний показник (кореляційний момент чи коефіцієнт).
2.3 Застосування нейронної мережі для оптимізації навантаження на
контролер SDN
Аналіз актуальності застосування інструментів штучного інтелекту
сучасних та перспективних мереж зв'язку досить детально наведений в багатьох
роботах. При цьому нейронна мережа запропонована в розробленому методі
ідентифікації трафіку в мережах зв'язку на основі метаданих потоків на рівні
передачі даних. Останнім часом нейронні мережі досить широко
використовуються для вирішення різних завдань із різних галузей
життєдіяльності людини. Наприклад, такі завдання, як розпізнавання тексту,
мови, прогнозування складних моделей здебільшого на даний момент вирішують
за допомогою нейронних мереж, досягаючи при цьому високих результатів.
Широко в побуті використовуються і голосові помічники, які стали відображати
новий вид інтерфейсу між людиною та ІТ-системою.
Існують три загальні парадигми навчання: «з вчителем», «без вчителя»
(самонавчання) та змішана. У першому випадку нейромережа має у своєму
розпорядженні правильні відповіді (виходи мережі) на кожен вхідний приклад.
Ваги налаштовуються так, щоб мережа виробляла відповіді найбільш близькі до
відомих правильних відповідей. Навчання без вчителя не вимагає знання
правильних відповідей на кожен приклад навчальної вибірки. У цьому випадку
розкривається внутрішня структура даних та кореляція між зразками в навчальній
множині, що дозволяє розподілити зразки по категоріях. При змішаному навчанні
частина ваг визначається за допомогою навчання зі вчителем, у той час як інша
визначається за допомогою самонавчання.
За способом навчання поділяють навчання за входами і за виходами. При
навчанні за входами навчальний приклад є тільки вектором вхідних сигналів, а
при навчанні за виходами до нього входить і вектор вихідних сигналів, який
відповідає вхідному вектору. За способом подання прикладів розрізняють
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 37
а
подання одиночних прикладів і «сторінки» прикладів. У першому випадку зміна
стану нейронної мережі (навчання) відбувається після подання кожного прикладу.
У другому – після подання «сторінки» (множини) прикладів на підставі аналізу
одразу усіх їх. За особливостями моделі нейрону розрізняють нейрони з різними
нелінійними функціями.
Рисунок 2.3 – Архітектура нейронної мережі
На даний момент існує великий різновид нейронних мереж. У даній роботі
використовується нейронна мережа для прогнозування навантаження.
Архітектура розробленої нейронної мережі зображена на рис. 2.3.
Робота нейронної мережі: на вхідний шар нейронів (так звані плейсхолдери)
подається потік даних із сформованого DataSetML. Плейсхолдери з'єднані з
першим шаром нейронної мережі пов'язаною структурою. Вихідними є два
нейрони, які генерують ряд (набір даних) передбачених значень.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 38
а
Нейронна мережа отримує на вхід дані фіксованої довжини, для цього
початковий набір даних поділяються на сегменти по 200 рядків. Також вихідний
набір даних поділяється на два набори даних: навчальний та практичний
(тестовий), у співвідношенні 8:2. Архітектура нейронної мережі є повністю
рекурентною та містить 4 пов'язаних вкладених рівня нейронів, кожен з яких
складається з 10 нейронів (рис. 2.3).
Параметри навчання нейронної мережі:
 оптимізатор: Adam;
 кількість епох: 20;
 кількість зразків на ітерацію: 1024;
 швидкість навчання 0.0025.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 39
а
3 АЛГОРИТМ ОПТИМІЗАЦІЇ НАВАНТАЖЕННЯ НА КОНТРОЛЕРИ
ПРОГРАМНО-КОНФІГУРОВАНИХМЕРЕЖ
3.1 Структура ефективного алгоритму оптимізації трафіку
Суть ефективного алгоритму оптимізації трафіку полягає у тому, щоб
знизити затримки створення з'єднання. Насамперед варто звернути увагу на
визначення терміну потоки в рамках програмно-конфігурованих мереж. Потік
даних – це маршрут, який прокладається всередині сегмента мережі між
комутатором A та комутатором B, щоб n-а кількість пакетів досягла деякий вузол
мережі.
У програмно-конфігурованому контролері використовується стандартний
алгоритм Дейкстри для побудови маршруту на графі, що не є дуже швидким
рішенням, так як застосовується універсальна версія алгоритму з використанням
складних структур даних. У разі його модифікації можна зробити покращення
продуктивності в рамках даної задачі.
Алгоритм Дейкстри не гарантує знаходження шляху на графі, для
вирішення цієї проблеми необхідно додатково розробити механізм відновлення
маршруту з цільової вершини, що не потрапила до маршруту. Таким чином
отримуємося, що алгоритм буде розбитий на дві підзадачі перша це розробка
модифікація алгоритму Дейкстри на графах для прискорення створення нових
маршрутів у рамках даного завдання, друге це розробка швидкого алгоритму
відновлення маршруту від кінцевої вершини до стартової в рамках побудованого
алгоритмом Дейкстри шляху. Алгоритм генерації маршрутів завжди має будувати
оптимальний маршрут, щоб виключити ситуацію, необґрунтованого
навантаження одного комутатора по відношенню до інших, якщо це можливо.
Проектування та реалізація алгоритму побудови маршрутів на базі
простих структур даних
RUNOS є контролером з відкритим вихідним кодом, отже можемо вільно
модифікувати вихідні файли. В першу чергу слід зазначити, що спочатку
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 40
а
використовувалася бібліотека boost для розрахунку маршруту за алгоритмом
Дейкстри, але є багато недоліків, таких як надмірно складна структура зберігання
даних та повністю універсальна реалізація алгоритму. [27] Це викликано тим, що
бібліотека boost є вкрай універсальною у своїх реалізаціях, тому з її допомогою не
завжди можна отримати максимальну продуктивність. [14]
Перше, на що варто звернути увагу — це структура зберігання даних, вона є
складною з не найшвидшою швидкістю доступу. Класичною структурою даних
для роботи з графами є двовимірний масив (рис. 3.1). Головною відмінністю є
константний час доступу до будь-якого осередку даних, і воно дуже низьке, чого
не скажеш про складні структури даних. Завдяки цій перевазі масиви дозволяють
швидко модифікувати зв'язки між окремими вузлами мережі. При розрахунку
маршруту є ряд складнощів, і найголовніша полягає в тому, що для повного
обходу всіх можливих ребр одного вузла, потрібно здійснити O(n) операцій, де n –
кількість комутаторів, а в найгіршому випадку – O(n2). Переваги масивів даних в
тому, що їх простіше ініціалізувати та використовувати, ніж складні структури
даних.
Рисунок 3.1 – Подання двовимірного масиву
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 41
а
Проблему обходу можна вирішити за допомогою розробки спеціальної,
простої структури даних, яка дозволить швидко оминати всі ребра певної точки,
завдяки тому, що в ній зберігатимуться лише реальні зв'язки. Крім переваг у
швидкості розрахунків, ще одна важлива перевага, це займана пам'ять, в
більшості випадків вона буде меншою, ніж у масиву, винятком буде ситуація,
коли у кожного комутатора буде більше 50 з'єднань з іншими пристроями.
Важливим недоліком такої структури буде швидкість модифікації такої
структури.
Для простої взаємодії з масивом необхідно розробити обгортку з методами,
що дозволяють робити різні дії з масивом, такі як ініціалізація масиву, додавання
або видалення зв'язку між вузлами, збільшення або зменшення лічильника
потоків. Також усередині обгортки має бути реалізація пошуку маршруту. Цю
логіку реалізують такі методи: addLink, ВикористовуйтеLink, incrementFlows,
decrementFlows і computeRoutes. Метод addLink виконує генерацію зв'язку між
двома вузлами.
Метод додавання виявився великим насамперед через те, що з програмно-
конфігурованих мереж отримуємо дані у вигляді структури switch_and_port, через
це необхідно спочатку знайти відповідність між ідентифікатором та
ідентифікатором у рамках протоколу OpenFlow, а потім зробити встановлення
самого з'єднання. Метод removeLink виконує знищення зв'язку між двома
вузлами.
Метод знищення зв'язку виявився великим через те, що з програмно-
конфігурованих мереж отримуємо дані як структури switch_and_port, в яких
зберігається ідентифікатор у рамках протоколу OpenFlow, після знаходження
ідентифікатора у масиві відбувається знищення зв'язку.
Метод incrementFlows виконує збільшення лічильника потоків, які
проходять через з'єднання комутатора. Метод decrimentFlows виконує зменшення
лічильника потоків, які проходять через цей комутатор.
Сам пошук шляху розбитий на кілька невеликих підзадач. Перша підзадача
– це побудова самого маршруту за допомогою алгоритму Дейкстри, у разі
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 42
а
знаходження мінімального маршруту до потрібного комутатора – завершуємо
пошук. Другий етап – це відновлення шляху з кінцевої точки до стартової.
Для об'єднання повторюваних операцій розроблено кілька допоміжних
функцій, перша це облік мінімальних відстаней до певних вузлів, що має назву
setMinVals і findNextMinId для пошуку наступної точки з якої необхідно
проводити наступний пошук. Метод setMinVals набуває мінімальних значень і
сканує вагу ребер та здійснює визначення того, наскільки далеко перебуває
наступна точка. Метод findNextMinId проводить пошук наступного не відвіданого
комутатора, у якого найменша відстань від стартової точки.
Для відновлення маршруту використовується спеціальний алгоритм, в
якомуу повідомляється ідентифікатор кінцевого вузла та з нього алгоритм будує
маршрут.
У результаті вивчення особливостей роботи алгоритму Дейкстри виявлено
важливу закономірність, що з будь-якої кінцевої точки можна знайти маршрут до
початкового. Оскільки в ході алгоритму кожній точці проводиться призначення
мінімальної відстані від початкової точки, яке є сумою ваг всіх з'єднань, можемо
побачити, що якщо будемо брати кожне ребро графа та віднімати його вагу і
перевіряти значення мінімальної відстані, то побачимо, що це мінімальна відстань
збігається тільки в тому випадку, коли рухаємось у бік нашої початкової позиції.
Реалізовані наступні оптимізації алгоритму Дейкстри, реалізованого у
програмно-конфігурованому контролері RUNOS:
1. Завершення алгоритму відбувається одразу після знаходження
мінімального маршруту до кінцевої точки. При генерації випадкових
з'єднань, оптимізація дозволяє зберегти велику кількість часу, у
середньому 10 мс від початкового часу.
2. Перехід на просту структуру двовимірного масиву для зберігання даних.
При операціях побудови маршрутів відбувається приріст продуктивності
за рахунок гарантованої швидкості доступу до кожного ребру та вузлу у
вигляді O(1). За рахунок цього вдається виграти від 5 до 10 мс залежно
від розміру сегмента.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 43
а
3. Оптимізовано зберігання вже відвіданих вершин у вигляді масиву
значень. Цей масив створюється лише один раз при старті програми.
Таке рішення зроблено для прискорення роботи, адже операція генерації
та видалення масиву займає багато часу. Спочатку цей масив
генерувався всередині роботи алгоритму, після аналізу продуктивності
за допомогою профайлера виявлено, що 2 мс витрачається на створення
та видалення цього масиву і прийнято рішення створювати його лише
один раз.
Оптимізований алгоритм Дейкстри розбитий на кілька етапів: ініціалізація
даних, пошук мінімальних маршрутів із стартової позиції, поновлення маршруту.
Після успішної ініціалізації відбувається виконання першого кроку циклу. При
першому кроці проводиться пошук мінімальних відстаней з початкової точки до
всіх доступних. Далі основний цикл повторює той самий крок, доки виявить
збудований маршрут до кінцевої точки. Як тільки це відбувається, виконується
вихід з алгоритму.
Після побудови маршруту виконується відновлення маршруту у форматі
зрозумілому для програмно-конфігурованого контролера Runos. Як можна
бачити, основні кроки збереглися, у першому кроці відбувається початковий
пошук відстаней до інших вершин. Слідом запускається цикл, у якому
проводиться пошук мінімальної відстані до інших вершин. Як тільки буде
знайдено відстань до кінцевої вершини буде проведено вихід із циклу з
наступним відновленням маршруту.
Оптимізація роботи алгоритму побудови маршрутів на базі простих
структур даних за допомогою OpenMP. На жаль алгоритм Дейкстри є
рекурентним алгоритмом і не дозволяє провести обчислення маршрутів
паралельно, проте при детальному розгляді реалізації побачимо, що даний
алгоритм має одне місце, яке можна розпаралелити. Це місце знаходиться у
методі setMinVals. У ньому відбувається простий нерекурентний перебір ребр та
розрахунок нових значень мінімального маршруту.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 44
а
Паралелізм залежно від сегмента може як прискорити, так і сповільнити
роботу. Для маленьких сегментів мережі, у яких менше 100 комутаторів, робота
уповільнюється на 5 мс. При роботі з великими сегментами, від 500 до 1000
вузлів, спостерігається прискорення продуктивності роботи алгоритму на 3-5 мс.
Емуляція тестових сегментів мережі
В рамках першого розділу розглянуті різні інструменти для емуляції
сегментів комп'ютерних мереж, під час аналізу виявлено, що інструмент Mininet є
чудовим варіантом для тестування алгоритм побудови маршрутів.
Mininet дозволяє конфігурувати топології за допомогою скрипта. Це
дозволяє генерувати сегменти зі випадковими зв'язками будь-якої складності та
розмірності.
Клас з назвою Mininet, що знаходиться у просторі імен mininet.net
використовується для емуляції мережі із логічними комп'ютерами. Бібліотека
mininet.node зберігає опис класів, які відповідають за контролери та комутатори.
Бібліотека mininet.topo необхідно використовувати для коректної роботи
топології сегмента мережі До завдань цієї бібліотеки входить: зберігання
інформації про вузли, створення/видалення/модифікація підключень між вузлами.
Бібліотека mininet.log є допоміжною бібліотекою за допомогою якої
проводиться логування налагоджувальної інформації, виведення тих чи інших
помилок. Це дуже корисна бібліотека на етапі налагодження та тестування, так як
допомагає виявляти проблеми практично одразу.
Бібліотека mininet.cli необхідна для конфігурації та виконання різних
команд вже після запуску засобів для емулювання, за допомогою командного
рядка.
Створення підключення до програмно-конфігурованого контролеу RUNOS
відбувається наступним чином:
runos = RemoteController('b0', ip='127.0.0.1')
Для створення власної топології необхідно успадковувати клас Topo і після
цього можна модифікувати його роботу. Після створення топології необхідно
створити та зробити запуск мережі, для цього необхідно додати всі логічні
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 45
а
комутатори до мережі, а після з'єднання їх у випадковому порядку для коректної
роботи мережі. Після генерації топології необхідно зробити створення та запуску
екземпляра Mininet. Для запуску мережі спочатку необхідно створити екземпляр
топології DeikstraTopo. Наступним кроком буде передача необхідних параметрів
для створення екземпляра мережі. Наприкінці потрібно зробити побудову та
запуск мережі. Після запуску необхідно викликати консольну оболонку CLI, яка
прийматиме різні команди від користувача, за допомогою яких під час виконання
можна вносити різні зміни у роботу створеної мережі. Увімкнення Mininet
проводиться за допомогою спеціальної консольної команди. У вхідних
параметрах вказуємо, де знаходиться файл скрипта для запуску та яку топологію
використовувати.
3.2 Апробація алгоритму оптимізації тарфіку
Після розробки алгоритму для програмно-конфігурованої мережі на базі
мережної операційної системи RUNOS, зроблена емуляція різних складних
сегментів мережі, для визначення ступеня досягнення поставлених цілей та
завдань.
Загалом проведено 2 групи тестів. На основі тестів отримані дані про
продуктивність існуючого, паралельно реалізованого алгоритму та однопоточного
алгоритму. Складені діаграми продуктивності для більш зрозумілого
відображення результату виконаної роботи. На цих діаграмах можна побачити
різницю по швидкості виконання побудови маршруту на різних розмірах
сегментів програмно-конфігурованих мереж.
Метою тестів першого етапу було виявити, наскільки ефективними є різні
реалізації алгоритму Дейкстри, на основі різних структур даних та оптимізації.
Отримані дані відображають сильні та слабкі сторони того чи іншого підходу.
Схема проведення тестів була різною, перша група тестів була націлена виключно
на дослідження часу генерації з'єднань. Для дослідження часу розрахунку
маршруту на тестовому сегменті кожні 100 мс створювався запит на передачу
даних з одного випадкового комутатора до іншого. Кожен тест цієї групи
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 46
а
проводився протягом 24 годин. Між тестами змінювався лише розмір сегмента та
реалізація алгоритму. Результати тестування представлені на рис. 3.2.
Як видно в рамках результату тестування, зі збільшенням кількості вузлів у
мережі графік зростає не лінійно для класичної реалізації та однопоточної
оптимізованої реалізації. Проте реалізація багатопоточного оптимізованого
алгоритму Дейкстри за часом виконання трохи програє на невеликих сегментах
мережі, через збільшені витрати на створення потоків, для роботи в
багатопоточному режимі.
Рисунок 3.2 – Результати першого етапу тестування
Як можна побачити, на сегменті у розмірів 100 вузлів, оптимізований
алгоритм Дейкстри працює трохи швидше, ніж класична реалізація, використана в
мережевому ОС RUNOS.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 47
а
Починаючи з 200 вузлів, багатопотокова версія оптимізованої реалізації
починає працювати швидше, так як кількість опрацьованих даних збільшується та
разом з цим зростає ефективність роботи паралельної версії алгоритму.
Другий етап тестів був націлений на тестування продуктивності програмно-
конфігурованої мережі за умов передачі маленьких файлів розміром 1 –
1024 байти. Результати другого етапу тестування представлені на рис. 3.3.
Варто звернути увагу, що в рамках даного тесту порівнювалася
ефективність роботи не лише між різними реалізаціями алгоритмів, а ще й між
класичними мережами. Як можна бачити, на маленьких обсягах даних програмно-
конфігуровані мережі не є дуже ефективним рішенням. Також варто зауважити,
що будь-який створений шлях у програмно-конфігурованих мережах зберігається
деякий час і якщо відбувається повторний запит на відправку в те саме місце, то
шлях не генерується повторно.
Рисунок 3.3 – Результати другого етапу тестування
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 48
а
На жаль, протестувати працездатність розроблених реалізацій алгоритму на
реальному сегменті мережі не має можливості, у зв'язку з тим, що у місті Черкаси
відсутні програмно-конфігуровані мережі.
3.3 Тестування алгоритму оптимізації навантаження в мережі
Практичні випробування запропонованої моделі моніторингу та
прогнозування навантаження на контролер програмно-конфігурованої мережі
розділені на дві стадії. Першою стадією є проведення дослідження з метою
підтвердження встановленої гіпотези про прямий вплив активності потоку (зміни
метаданих) службових повідомлень OpenFlow на контролер від комутаторів SDN
та відповідно на його апаратну частину.
Другою ж частиною практичних випробувань, при отриманих позитивних
результатах першої частини є розробка та навчання штучної нейронної мережі з
метою моніторингу та побудови прогнозів активності службових потоків
OpenFlow.
Для проведення практичних випробувань зібрано модель, структуру та опис
якого наведено у розділі 2. Для розрахунку показників залежності між
досліджуваними параметрами використано програмне забезпечення контролерів
програмно-конфігурованих мереж. Дане програмне забезпечення спочатку
формує набір даних, структура якого відображена в розділі 2 даної
кваліфікаційної роботи, після чого провадить розрахунок відповідних показників
���� та ����.
Як зазначено раніше при обґрунтуванні вибору даного математичного
методу, кореляційний момент має певну особливість, а саме залежить від одиниць
виміру незалежних величин, що не дає в повній мірі оцінити рівень кореляції двох
величин.
Для цього початкова матриця приводиться до виду нормованої за
формулами, зазначених вище. На основі даної матриці побудований також
точковий графік розподілу оцінок.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 49
а
Отриманий графік будувався за вибіркою 100 значень із загального набору
даних та відображено на рис. 3.4 - 3.5
На рисунках відображені найважливіші результати щодо взаємозв'язку
ByteCount та навантаження CPU. На рис. 3.4 відображено природна залежність
між двома параметрами, які безпосередньо пов'язані, як приклад оцінки
параметрів.
На рис. 3.5 відображено розподіли виважених оцінок вже різних параметрів,
які необхідно оцінити з точки зору залежності змін і можна зробити висновок, що
згідно з графіком, існує залежність між змінами параметра ByteCount суми
службових потоків і навантаження на центральний процесор контролера
програмно-конфігурованої мережі.
Рисунок 3.4 – Точковий графік розподілу оцінок PacketCount
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 50
а
Рисунок 3.4 – Точковий графік розподілу оцінок CPU
Для оцінки рівня корелювання досліджуваних величин розраховується
коефіцієнт кореляції. У таблиці 3.1 наведено розраховані показники кореляції ����
між величинами, що відображаються на графіках рис. 3.4-3.5.
Таблиця 3.1 – Матриця коефіцієнтів кореляції
�� ��������|�������� ��������|������
значення 0.98 0.89
Для аналізу отриманих даних, відображених у таблиці 3.1, звернемося до
властивостей показника коефіцієнта кореляції, що були відображені раніше при
описі способу. Усі отримані значення коефіцієнтів кореляції задовольняють
наступну властивість |������|>0 и |������|<1. На основі цієї властивості можливо зробити
такий висновок: існує зв'язок між досліджуваними параметрами, і при цьому чим
більша величина коефіцієнта кореляції, тим більшою мірою за значеннями одного
параметра можна побудувати прогноз значення іншого.
З отриманих значень у цій роботі цікавить значення коефіцієнта кореляції
між ��������|������ рівний 0,89 відповідно. Значення цього показника дозволяє зробити
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 51
а
висновок про існування залежності між активністю службових потоків OpenFlow
та навантаженням апаратної частини SDN-контролера. При цьому варто
відзначити, що явної лінійною залежності між ними немає.
При цьому отриманий результат дозволяє зробити висновок про те, що
запропонований метод моніторингу та прогнозування навантаження на контролер
може ефективно працювати. І відповідно, для оцінки роботи/навантаження
контролера програмно-конфігурованої мережі може бути побудовано прогнозну
аналітичну модель суми службових потоків OpenFlow, де сумарні лічильники
групи службових потоків (метадані) є прогнозованим параметром.
Для проведення другої частини практичного дослідження, модель була
модернізовано щодо першої частини практичних випробувань. Друга частина
практичних випробувань полягала у навчанні розробленої штучної нейронної
мережі, архітектура та параметри якої наведено у розділі 2 кваліфікаційної
роботи.
За отриманим набором даних DataSetML побудована діаграма розкиду
значень. Діаграма наведена рис. 3.6. На цій діаграмі візуально можна виділити
кілька областей (кластерів) розподілу точок в області яких переважає відповідне
значення середнього значення довжини пакета в потоці (виділені овалами).
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 52
а
Рисунок 3.6 – Точкова діаграм розкиду значень набору даних ������������������
Протягом навчання штучної нейронної мережі (оцінки точності
прогнозування нейронної мережі), як параметр оцінки роботи, спостерігався
параметр MSE – Mean Square Error (з англ. середньоквадратична помилка). Зміна
значення параметра MSE наведено на рис. 3.7.
MSE оцінюється за наступною формулою:
,
де Y-вектор значень прогнозованої змінної, що спостерігається,
�� ̂�� – вектор зпрогнозованих значень.
Іншими словами, MSE це середнє квадратів помилок прогнозу. Дана оцінка
є простою і досить часто застосовується в подібного виду задачах.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 53
а
Рисунок 3.7 – Процес зміни значення параметра MSE
На рис. 3.7 наведено два графіки, які йдуть близько один до одного.
Червоною пунктирною лінією відображається зміна параметра MSE при роботі
мережі на навчальному наборі даних, зеленим відображається зміна параметра
MSE на робочому (реальному) наборі даних. З графіка видно, що обрана
архітектура та параметри нейронної мережі задовольняють формування
прогнозування навантаження. В підсумку, вийшли наступні параметри:
���������������� = 3.56 ∗ 10−6,
������ −5
�������� = 1.6 ∗ 10 .
Також у процесі навчання нейронної мережі відстежувався процес її
навчання для формування прогнозів. Для наочності процесу, будувався графік
реальних та зпрогнозованих значень нейронної мережі на проміжку даних 20 тис.
відліків. На рис. 3.8-3.11 наведено декілька знімків екрану у процесі навчання
нейронної мережі, що відображають її прогрес.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 54
а
У кожній із областей (графіки), наведених на рис. 3.8-3.11, є два графіки
синього та зеленого кольору, що відображають реальні значення та прогнозовані.
Рисунок 3.8 – Реальні та прогнозовані значення для мережі з першим прогнозом
Рисунок 3.9 – Реальні та прогнозовані значення для мережі з Batch=50
Графік на першій лінії рис. 3.8 з підписом (Epoch 0, Batch 0) відображає
реальний та перший прогноз. На графіку видно, що прогнозовані значення сильно
відрізняються від реальних. Тобто графік зеленого кольору значно нижчий
основного – синього графіка.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 55
а
Графік на першій лінії рис. 3.9 з підписом (Epoch 0, Batch 50) відображає
наступний прогноз нейронної мережі після першого. З графіку видно (зелений),
що тепер прогнозовані значення перевищують реальні, графік досить сильно
завищений.
Рисунок 3.10 – Реальні та прогнозовані значення для мережі з Batch=250
Нижні два графіки (рис. 3.10-3.11), з підписами (Epoch 19, Batch 250),
(Epoch 19, Batch 300) відповідно відображають останні кроки мережі. За даними
графіками видно, що штучна нейронна мережа навчилася і тепер може коректно
прогнозувати активність суми службових потоків OpenFlow у реальній
програмно-конфігурованій мережі на рівні управління.
Видно, що на останньому (рис. 3.11) реальний графік візуально збігається з
прогнозованим. В результаті після того, як штучна нейронна мережа навчилася,
програмне забезпечення зберігає її стан архітектури та параметри так, щоб з
іншого програмного модуля сервера «Аналітична програма» можна завантажити
її стан.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 56
а
Рисунок 3.11 – Реальні та прогнозовані значення для мережі з Batch=300
Далі, програмний модуль, який завантажить стан навченої нейронної мережі
зможе формувати прогнозні дані на тестові дані, що надходять, які нейронна
мережа отримує на вхідні нейрони (плейсхолдери).
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 57
а
ВИСНОВКИ
В кваліфікаційній роботі бакалавра досліджено алгоритми побудови
маршрутів, розробка та оптимізація їх швидкості виконання для програмно-
конфігурованих мереж. Проаналізовано дану проблему, встановлено важливість
та актуальність даного напряму.
Проведений докладний аналіз різних інструментальних засобів для
розробки програмного забезпечення контролерів, мережевих операційних систем,
різних систем емуляції В результаті аналізу виявлено, що для використання у
програмно-конфігурованих мережах найкраще використовувати мережеву
операційну систему RUNOS та емулятор Mininet.
Наводиться висновок про необхідність проведення моніторингу та
прогнозування навантаження на контролери SDN з метою забезпечення стійкості
системи в умовах жорстких рамок якості обслуговування послуг, у той час як
контролери SDN є найуразливішою частиною цього типу мереж. Навіть
враховуючи системи мультиконтролерної взаємодії та резервування подібних
систем, аналітика з метою збереження стійкості керуючої системи є однією з
найактуальніших та важливих завдань. У рамках дослідження розкрито питання
архітектурних підходів до організації моніторингу серверних систем, до яких
належить і контролер SDN. В результаті наведено негативні сторони
«стандартного» підходу до моніторингу навантаження сервера, якщо проводити
оцінку через призму розгортання та супроводу роботи контролера програмно-
конфігурованої мережі.
Для вирішення проблемних питань при розглянутому звичайному підході
до моніторингу навантаження контролера SDN через системний рівень отримання
даних, в роботі запропонований метод моніторингу та прогнозування
навантаження на контролер SDN шляхом аналітики метаданих суми службових
потоків OpenFlow рівня управління. З метою підтвердження гіпотези щодо
можливості прогнозування навантаження на обчислювальні ресурси контролера
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 58
а
SDN на основі метаданих суми службових потоків рівня управління
запропонований спосіб перевірки через застосування багатопараметричного
кореляційного аналізу.
Проведено розробку оптимізованого алгоритму Дейкстри, за допомогою
спрощених структур зберігання та усічення зайвих кроків алгоритму в рамках
програмно-конфігурованих мереж. Зроблено дослідження працездатності
алгоритму на основі емульованих сегментів мережі різного розміру, для
виявлення переваг та недоліків розробленого оптимізованого алгоритму.
Таким чином, завдання вирішені повністю, мета роботи досягнута.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 59
а
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Agouros K. Software Defined Networking / K. Agouros – Berlin: De Gruyter,
2019. – 268 p.
2. Azodolmolky S. Software Defined Networking with OpenFlow – Second Edition
/ S. Azodolmolky – Birmingem: Packt Publishing, 2018. – 312 p.
3. Chou E. Mastering Python Networking: Your one stop solution to using for
network automation, DevOps, and SDN / E. Chou – Birmingem: Packt
Publishing, 2019. – 446 p.
4. Doherty J. SDN and NFV Simplified: A Visual Guide to Understanding Software
Defined Networks and Network Function Virtualization / J. Doherty – Boston:
Addison-Wesley Professional, 2020. – 320 p.
5. Duan Q. Network as a Service for Next Generation Internet / Q. Duan, Wang S. –
Stevenide: The Institution of Engineering and Technology, 2019. – 440 p.
6. Duan Q. Virtualized Software-Defined Networks and Services / Q. Duan, Toy M.
– Norwood: Artech House, 2021. – 334 p.
7. Dumka A. Innovations in Software-Defined Networking and Network Functions
Virtualization (Advances in Systems Analysis, Software Engineering and High
Performance Computing) / A. Dumka – Hershy: IGI Global, 2021. – 364 p.
8. Goransson P. Software Defined Networks, A Comprehensive Approach /
P. Goransson – New-York: Morgan Kaufmann, 2020. – 436 p.
9. Gorobets N. N. Multiband pyramidal norm antennas with identical main lobe
widthes of the directional patterns / N. N. Gorobets, A. A. Yelizarenko //
Telecommunications and radio engineering. Volume 73, Number 9, 2019. –
C.757–766.
10. Gray K. Network Function Virtualization / K. Gray – New-York: Morgan
Kaufmann, 2021. – 270 p.
11. Guang Y. Optimal path planning for unmanned air vehicles with kinematic and
tactical constraints. Decision and control: Proceedings of the 41th IEEE Conf.,
Las Vegas, Nevada, USA, 10–13 Dec., 2020. Vol. 2. – P. 101–106.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 60
а
12. Gummadi R. Understanding and mitigating the impact of RF interference on
802.11 networks (ACM SIGCOMM’20). New York, NY, USA: ACM, 2020. –
P. 85–96.
13. Hamburger V. Building VMware Software-Defined Data Centers / V. Hamburger
– Birmingem: Packt Publishing, 2020. – 432 p.
14. Hata M. Empirial fomula for propagation loss in land mobile radio services /
M. Hata // IEEE Trans. Venicular Technology, 2020. – Vol.29, №3 – P.17-25.
15. Hopfield J. J. Neural networks and physical systems with emergent collective
computational abilities. – Proceedings of the National Academy of Sciences of
the United States of America. 2020. Vol. 79. – P. 554–558.
16. Khondoker R. SDN and NFV Security: Security Analysis of SoftwareDefined
Networking and Network Function Virtualization (Lecture Notes in Networks
and Systems) / R. Knodoker – Berlin: Springer, 2021. – 134 p.
17. Krainyk Y. Hardware-oriented turbo-product codes decoder architecture.
Intelligent data acquisition and advanced computing systems: technology and
applications (IDAACS – 2017): Proceedings of the 2017 IEEE 9th Int. Conf.,
Bucharest, Romania, 21–23 Sept., 2017. Vol. 1. – P. 151–154.
18. Lee G. Cloud Networking: Understanding Cloud-based Data Center Networks /
G. Lee – New-York: Morgan Kaufmann, 2020. – 238 p.
19. Liyanage M. Software Defined Mobile Networks (SDMN): Beyond LTE
Network Architecture (Wiley Series on Communications Networking &
Distributed Systems) / M. Liyanage – Hoboken: Wiley, 2020. – 438 p.
20. Morraele P. A. Software Defined Networking: Design and Deployment /
P. A. Morraele – Boka Ratone: CRC Press, 2019. – 186 p.
21. Nadeau T. SDN: Software Defined Networks / T. Nadeau – New-York: O'Reilly
Media, 2018. – 384 p.
22. Robertazzi T. G. Introduction to Computer Networking / T. G. Reobertazzi –
Berlin: Springer, 2019. – 154 p.
23. Shukla V. Introduction to Software Defined Networking – OpenFlow & VxLAN /
V. Shukla – Seatle: CreateSpace Independent Publishing Platform, 2020. – 114 p.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 61
а
24. Subramanian S. Software Defined Networking (SDN) with OpenStack /
S. Subramanian – Birmingem: Packt Publishing, 2019. – 216 p.
25. Taheri J. Big Data and Software Defined Networks (Computing and Networks) /
J. Taheri – Stevenide: The Institution of Engineering and Technology 2019. –
504 p.
26. Tiwari V. SDN and OpenFlow for beginners with hands on labs / Tiwari V. –
Seatle: Amazon Digital Services LLC, 2020. – 119 p.
27. Werners B. Alternative fuzzy approaches for efficiently solving the capacitated
vehicle routing problem in conditions of uncertain demands. Complex Systems:
Solutions and Challenges in Economics, Management and Engineering Part of the
Part of the Studies in Systems, Decision and Control (SSDC): book series.
Vol. 125. Springer, Oct. 31, 2017. – P. 521–543.
28. Абрамов В. О. Базові технології комп’ютерних мереж: навч. посіб. 2-ге вид.
Київ: А.С.К., 2018. – 248 с.
29. Боровльова С. Ю. Бенчмаркінг ефективності організації ітераційних
процесів у багатоядерному процесорі. Могилянські читання-2017. / Чорном.
нац. ун-т ім. Петра Могили: тези доп. XX Всеукр. наук.-метод. конф.,
Миколаїв, 13–17 листоп. 2017. – С. 57–60.
30. Єлізаренко А. О. Удосконалена статистична модель для розрахунку
характеристик каналів зв’язку / А. О. Єлізаренко // Інформаційні керуючі
системи. – 2021, №2. – С.37–42.
31. Жерегі О. М. Дослідження та розробка програмного забезпечення абонентів
моніторингових мереж на мобільній платформі. Інтелектуальні
інформаційні системи – 2018: Вид-во Чорном. держ. ун-ту ім. Петра
Могили, 2018. Т. 1. – С. 150–152.
32. Квасніков В. П. Способи побудови аналогових інтерфейсів інформаційно-
вимірювальних систем механічних величин. – Вимірювальна та
обчислювальна техніка в технологічних процесах. 2017. № 1. – С. 164–169.
33. Комп’ютерні мережі: навч. посіб. / О. Д. Азаров, С. М. Захарченко,
О. В. Кадук та ін. Вінниця: ВНТУ, 2020. – 371 с.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 62
а
34. Digital Mobile Radio (DMR) Systems. Part 1: DMR Air Interface (AI) protocol
[Електронний ресурс]. – ETSI TS 102 361-1 V1.4.1. – European
Telecommunications Standards Institute, 2006. – Режим доступу:
https://www.etsi.org/deliver/etsi_ts/102300_102399/10236101/01.04.01_60/ts_10
236101v010401p.pdf.
35. Мірошник М. А. Розробка засобів захисту інформації в розподілених
комп'ютерних системах та мережах. Інформаційно-керуючі системи на
залізничному транспорті: наук.-технічн. журн. 2019. № 1. – С. 18–25.
36. Фісун М. Т. Інтеграція даних мережевого трафіку мультісервісної
корпоративної мережі з класами постреляційної СКБД Caché. Наукові праці:
наук. журн. / Чорном. держ. ун-т ім. Петра Могили. 2021. Т. 173, Вип. 161. –
C. 105–110.
Лист
ЧДТУ.222106.004 ПЗ
Змн. Арк. № докум. Підпис Дат 63
а

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets